Intro to securing Free BSD Part 3
Intro to securing Free BSD part 3
A bit about Kerberos -
Kerberos was developed at MIT as a centralized login management system at the Athena cluster at MIT. Kerberos pretty much allows users to authenticate themselves with a server on a net and of course be issused tickets for tasks like FTP, Pop3, Telnet and NFS.
Doing this makes it so you don't have to log on each time.
As long as the hosts on your network between which you're running traffic do support the system, and subscribe to the master server, the system takes care of all authentication for you.
Free BSD allows you to set up a Kerberos server, or just use it where it is already at.
I'm only listing this all for the curious, this is NOT a security system, or have much to do with network security really, but in a pure Unix environment, it can help get rid of a lot of work.
A lot of enterprises use Kerberos to provide encrypted log in services, and Windows 2000's security model is largely based on Kerberos (Though it is a moded version) it's becoming an important part of networks again.
Enabling Kerberos for Free BSD -
in /etc/rc.conf :
kerberos_server_enable="yes"
This starts up the services needed in a master Kerberos server.
If you're already Using it, just un-comment the lines /etc/pam.conf to enable centralized authentication for the services that support it. Here is an example which is probably in a lot of docs:
login auth sufficient pam_kerberosIV.so try_first_pass
More information about Kerberos -
RTFM :)
Avoiding problems with clear text services -
Transmissions between your machine and the server in things like HTTP, Telnet, and even FTP and Email may seem secure because your passwords are hidden and things are transmitted in packets along with a whole lot of other packets.
Who would have the painstaking mindset to actually sit there and try to get the network wiretap and actually put all of this tegother for something interesting like your Username and password? Or maybe you Social Security Number or credit card number?
It's a shame users actually believe this to be true. To all the newbies and users that believe this, think about this:
If no one actually enjoyed putting a puzzle together, stores wouldn't sell so many of them. Youo're not safe, the ARE watching you, and you should be ashamed of that net traffic you pervert.
Security doesn't exist in clear text services and security through obscurity, the notion that you're safe because no one is interested in what you're doing, is very very false. ALWAYS assume that a person with intent to do harm to your network, is always watching. They probably are.
If you're not paranoid enough start smoking weed. THAT is how you realise the importance of security. And hey, you're work creativity would sure sky rocket.
Monitoring traffic -
I was going to do a section here about this subject, but I liked this one better by IronGeek:
http://www.antionline.com/showthread...hreadid=265710
This is going in here because it shows how easy it really is to monitor traffic and the things you can find. A lot of Unix based OSs come with a lot of network tools and a lot of sniffers and traffic things that make this even easier.
The section I was going to do for this was going to be with tcpdump, but as I said, IronGeek already did it and I liked it. No point in reinventing the wheel.
Adding security with encrypted protocols -
Now that you have read IronGeek's very good tutorial and doing some of my work for me in writing that ;) You should have an idea just how someone can listen to what you're doing online and over the network. What can you do to fight that? Well, most protocols have an encrypted version or replacement that you can use which I will discuss now:
First, I want to give a short list that is no where or any where, close to complete:
Telnet is not encrypted, everything sent over it, is done so in clear text. SSH gives you the same experience but is encrypted.
HTTP isn't encrypted, HTTPS is.
FTP was not meant for security, SCP was.
The data in the tcpdump isn't encrypted, at all. It only takes a small amount of effort to get a look into everything sent. Tools like tcpflow, tcpshow, and Etherpeek even do the work for you in showing the full packet. If the packets you get are log in information, your username and password now belongs to an attacker.
Safegaurding against the use of these applications is especially important in systems where passwords and other sensitive information can be transferred. Protecting communication is as much a security concern as it is a privacy concern.
You can combat sniffer tools quite easily. The Free BSD installation contains a lot of tools that can be used instead of insecure clear text services like Telnet. SSH is right on the Free BSD installation media, and SSL can be used for HTTP and other services. Securing clear text services is quite easy, knowing is half the battle, and knowing these tools exist for Free BSD wins that half. Hopefully GI Joe doesn't sue me for that line, but hey, it's not like anyone watches or buys their stuff anymore... Right? ;)
Secure Shell -
A lot of people log into machines remotely to work. Doing so over rlogin and Telnet is not a good idea, something better exists called SSH. This comes with Free BSD and Linux and most copies of Unix I've used. OpenSSH was originally developed on Open BSD. Open SSH allows you to have an encrypted tunnel to the server, or your workstation. Some users such as I, use it and allow the service to run so if X freezes up for some reason, you can log in and kill it over SSH.
This allows you to combat the problem with tapped networks as no one can read the information going over the network.
The SSH Server, or Daemon, SSHd runs on port 22 as a stand alone server. Like Apache, it spawns off a new process for each incoming connection and to enable the SSH server in Free BSD you just simple add a line to /etc/rc.conf:
sshd_enable="YES"
Now you can either reboot, or type sshd.
SSH doesn't actually give you the prompt of the remote machine, it has it's very own and then when you type in your information, it then send it all, encrypted, to the remote host.
From here on though, it is very much like telnet.
Users who have Windows or old Mac machines have more work to do as no command line SSH client is installed. MacSSH and Putty should be downlaoded and installed so they can use SSH as well.
This is all fine but users never listen to the admin. Go to /etc/inetd.conf and comment out the line here:
telnet stream tcp nowait root /usr/libexec/telnetd telnetd
Just make it look like this:
#telnet stream tcp nowait root /usr/libexec/telnetd telnetd
Then restart the inetd process:
# killall -HUP inetd
A bit the lack of security in Email services -
POP3 and IMAP are argueably worse than Telnet security wise. If users set their E-Mail clients to check the mail every couple minutes, you now have clear text passwords being sent over the network, which is bad, and worse, it's every couple minutes which is giving an attacker a road map on when to sniff, so this is really bad.
The IMAP-UW software package for Free BSD can do something similar to Qpopper with the SSL which can encrypt POP3 connections. You can enable SSL in Free BSD to encrypt POP3, which is maybe the wrong word choice here, let me rephrase it if that doesn't catch you right:
You can use the same method to secure IMAP, employing the IMAP-UW software package. You can enable SSL support in IMAP-UW by generating a certificate with a certifying authority. If you have a certificate generated already for a service like Qpopper, you can use the same certificate for IMAP-UW. Check out http://www.washington.edu/imap to get info.
The stunnel program provides an alternative way to encrypt both IMAP and POP3. stunnel manages Certificates centrally and doesn't use a service's SSL support.
Stunnel allows you to set up a universal SSL tunnel for any service on the system that you choose. And of course stunnel is part of the Free BSD port collection :
/usr/ports/security/stunnel
If you install it from here, the default script /usr/local/etc/rc.d/stunnel.sh.sample starts a listening process on the machine, port 993 and port 995. 993 is for IMAP and 995 is for POP3 which should be listed as the secured versions of these ports in /etc/services.
Make sure you rename the file stunnel.sh.sample to stunnel.sh as the .sample part is to make sure you look at the file and make sure the patrhs to .pem cert files are in fact the correct ones.
If you choose to use stunnel, you will need to generate a cert just as you did with IMAP-UW. The stunnel certificate should be placed in /usr/local/etc/stunnel.pem
Once you have it there, your POP3 and IMAP clients should be able to connect to the right ports to establish a secure connection which is 993 for IMAP instead of the usual 143, and 995 for POP3 instead of 110.
A lot of pop email clients (Pop as in popular, not Post Office Protocol ;) ) support SSL on POP3 and IMAP, but others may only support one of the two, or neither.
In some clients, support is even incomplete or optional. Requiring these may make some users switch Email clients. Microsoft Outlook does in fact support both so if they use Windows boxes with Office, you shouldn't worry. And yes that is the only time you'll have me recommeding an Outlook style Email Client.
Stunnel is NOT a replacement for IMAP or POP3.
So for other things, this means yes you do in fact need the regular IMAP and POP3 service enabled. You will need a bit about IPFW if you want to close of these ports and only allow the secured version from anything but localhost which I will talk about in another.
