Don’t let the acronyms and the word “Encryption” scare you, its actually very easy to enable TLS/SSL in Apache. So basically it sounds more complicated than it is — like these last two sentences for example.
First you should probably know what TLS and SSL are. Well according to Wikipedia …”Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the internet”
I am going to assume here that you have already installed and started Apache, I will also assume that you have SELinux configured properly, as well as IPTables.
So next step is to install mod_ssl
# yum -y install mod_ssl
Once install a new config file, called ssl.conf will be installed in /var/www/html/conf.d. Inside that file are a couple of configuration items that you need to be aware of.
# Point SSLCertificateFile at a PEM encoded certificate. If
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
If you are replacing the test cert with a signed one you will need to drop it in /etc/pki/tls/certs and modify the lines in the section above to point to your new cert and your new key file.
If you are anything like me you would rather not have anything to do with Sendmail or Postfix, however unfortunately it can be required learning in some circles. That being said this is my second postfix post in what I call my “Postfix: Nasty!” series. The first one can be read here, and I will be the first to admit that its not very good. However I chock this up to the fact that I really don’t know much about Postfix at all and I’m writing these posts as part of the process of figuring out how to do what with Postfix.
Specifically this post outlines and defines the standard roles that a postfix server can serve. Below are three common roles and their characteristics. You should get to know each of these and how to configure them.
Null Client:
Only runs Postfix as a local MTA (mail transfer agent… think sendmail and postfix) for the purpose of forwarding to a centralized mail server
Does not accept local delivery
Inbound-Only Mail Server:
Handles all inbound mail for a site
Passes inbound email to an MDA (mail delivery agent) such as Dovecot or Procmail
Forwards outbound mail to a centralized mail server, just like a Null Client Does
Outbound Mail Relay:
Also called a Smarthost
Accepts outbound messages
Should be configured to forward mail for authorized clients only. Avoid being an Open Relay
Today on the fatmin we are going to setup an ftp server on RHEL6 that accepts anonymous uploads. We are going to do so with SELinux support and will be making modifications to iptables as well. Sounds fun, right?
Installation:
First and formost we need to install vsftpd
# yum -y install vsftpd && service vsftpd start && chkconfig vsftpd on
Our anonymous upload directory will be /var/ftp/anon, and we need to change group ownership to the ftp group and then change permissions so that the members of that group can write to it. Note that no one other than root can read or execute anything under /var/ftp/anon.
Next we need to configure SELinux support and assign the correct context to the /v1 directory and its future contents. Note -a is add -t is type.
# semanage fcontext -a -t public_content_rw_t ‘/var/ftp/anon(/.*)’
Now lets go ahead and apply the new context. Note -vv is verbose, -F force and R is recursive
# restorecon -vvFR /var/ftp/anon
Now we need to get and set the allow_ftpd_anon_write boolean
# setsebool -P allow_ftpd_anon_write=1
Now lets check to make sure the setting “stuck”.
# getsebool -a | grep allow_ftpd_anon_write
allow_ftpd_anon_write –> on
Configure Vsftpd:
Now vi /etc/vsftpd/vsftpd.confand ensure that the following configuration values are set and un-commented. Note that I had to add the last line to my config file.
anonymous_enable=YES
anon_upload_enable=YES
chown_uploads=YES
chown_username=daemon
anon_umask=077
Configure iptables:
Add the following to /etc/sysconfig/iptables-config. In my case I only needed to add the ip_nat_ftppart to the line
IPTABLES_MODULES=”nf_conntrack_ftp ip_nat_ftp”
Now you are going to want to make sure that these two lines exist in /etc/sysconfig/iptables.
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp –dport 21 -j ACCEPT
Now restart iptables
Addendum:
Note that I ran into issues with the semanage command below.
# semanage fcontext -a -t public_content_rw_t ‘/var/ftp/anon(/.*)’
It seems that the context assigned to the /var/ftp/anon directory was not changing correctly from public_content_tto public_content_rw_t.
# ls -Zd /var/ftp
drwxrwxrwx. root root system_u:object_r:public_content_t:s0 /var/ftp
However when I checked the file_contexts file all looked correct.
So I ran the chon command seen below and did not run the restorecon command. This worked as afterwards the context on the directory /var/ftp/anon was correct.
ISCSI is scsi (Small Computer System Interface) over IP. Where SCSI is the protocol and IP is the transport mechanism. This is going to be a quick and dirty overview of how to login to and mount an iscsi disk. This will not be an overview of how to share out a disk via iscsi. I may get around to writing that post, but it will not be today.
Before we get started we need to understand a few simple terms.
ISCSI Initiator – the client that needs access to the ISCSI disk.
ISCSI Target – the remote disk.
ISCSI Target Portal – the server that is providing the Target to the Initiator
IQN – The “ISCSI Qualified Name” or more simply a unique name for the Initiator and the Target
Now lets get down to business.
First on the Target you must install the ISCSI utils.
>yum -y install iscsi-initiator-utils.x86_64
Then discover the any ISCSI targets provided by the Target Portal. In this case the IP address of my target portal will be 192.168.0.55.
>iscsiadm -m discovery -t st -p 192.168.0.55.
In the example above -m puts iscsiadm is discovery mode, -t st tells iscsiadm to look for a SCSI target, and -p is the target portal. The output of the above command will be the IQN of the target disk.
Access Control Lists or ACLs provide more controll over file permissions than standard linux file permissions (UGO — user, group, other). For example lets say that you want all members of the group "students" to have the ability to read a file, however you want to allow one user in that group the ability to write to the file, well ACLs can help you do this.
First thing that you need to know is that you cannot just start using ACLs right away, first you have to make sure that your filesystem is mounted so that ACLs are availible. This means adding ACL to the mount options in /etc/fstab.
Now to view the permissions and ACLs on a file use the getfacl command, below i am checking the file RangerRick.jpg in /root/Pictures. In the example below there are no ACLs assigned, btw.
Lets give all users in the group "students" the ability to write to the file, since they may want to modify it and add a photochop their faces over the dear old racoon's face.
But oh no, user "bert" in the group "students", has decided to modify the file RangerRick.jpg in an in appropriate way, so lets remove his permissions altogether.
[root@fedora15 Pictures] setfacl -x u:bert
Lets say that we want to allow the user "chris" to be able to modify all existing and newly created files in the Pictures directory where the Ranger Rick picture lives.
Note that when a file has ACLs assigned to it, a plus "+" sign will appear in the output of an 'ls-l'
-rw-rw-r–+ 1 root root 148011 Oct 12 15:06 RangerRick.jpg
Honestly you will probably never need to use ACLs, but they are handy to have availible if you run into some sort of situation where you need to grant very particular permissions to files and directories.
Don’t let the acronyms and the word “Encryption” scare you, its actually very easy to enable TLS/SSL in Apache. So basically it sounds more complicated than it is — like these last two sentences for example.
