Intro to securing Free BSD
This is an introduction to security in Free BSD and is most likely going to be multi-part. It's only the intro as of right now, I just finished this and have more planned but when I get time is when I will do it. Enjoy:
Intro to Network security in Free BSD
Written by : gore
This is a small intro to security in Free BSD. It's no where near everything, as entire books have been written on the security of an OS. This won't teach you everything, but you can get a good idea of things to look for and how to get a better understanding of it for your own boxes.
Making an OS secure is one of the most important jobs any Admin has to do for his job. It doesn't matter if you're using Windows, A commercial big iron Unix, or Free BSD.
Before I start, I think some information should be presented in the area of Operating systems. Free BSD is considered a true Unix, but to me this is a pointless arguement in picking an OS.
Unix stopped being an OS in the early 1980s and to me, Unix is no longer an OS, but a type of OS, or standard. There are more than 100 types of Unix, and some are free, some are very expensive.
Linux and BSD are the two best known OSs when it comes to getting free quality software. Not all BSD OSs are free though.
BSD/OS is based on the original code base for BSD, and is not freely available, but you can get Free BSD, Net BSD, Open BSD, and Dragonfly BSD all for free. Free BSD is the one closest to BSD/OS but this is all one or another form of Unix. Linux was written from scratch by Linus Tovalds. Contrary to popular belief, Minix was NOT the inspiration for it.
Linus made Linux because he wanted something like he was using at the university, which was SunOS. The early inspirations for Linux were to be more like SunOS. Linus says this in the movie Revolution OS, from his own mouth.
Back on topic:
There are more books about security for OSs than probably any other subject in computing, and for a good reason. The security of an OS is very complex, and has a lot to it.
Choose a Security Model based on your security risks:
Remember than Network security has to comply with the network you're using it on. A security model / policy for a small business environment is probably not going to work well in a huge corporate environment.
A huge corporate security policy may not work well on a home LAN.
The internet as it is now, is not a friendly place. Worms come out all the time and now we are dealing with Spyware and Malware which wasn't even a thought in the heads of the BSD team who created TCP/IP.
New security updates and holes are found at an astonishingly high rate, and it can be hard to keep up. How do you know the new security patch isn't going to break something else on there?
You don't, and that is why you should ALWAYS have a test bed of machines that are a mirrir image of the production machines. That way when a new security patch is released, you can first install it on the test bed and make sure it's going to work in the set up you use and not break something.
If all is well, and it works good and hasn't broek anything, then you know installing it on your production machines won't be a problem.
Another thing to add to this, you should NEVER rely on an OS's firewall to defend your network. You should buy either a firewall appliance, or get something where you have a router with a built in firewall. This way you add another layer the process known as security.
This also can really become helpfull when you see a new security update for the OS, but haven't had time to test it, the hardware firewall can stand gaurd while you test out the security fix.
That is why most corporations have Firewalls that cost thousands of dollars and don't run on the servers.
A good admin should be ready, and prepare for the worst even if it hasn't happened yet. This can include off site back ups and storage places, and having another server ready in case you have a problem with the ones in use.
This helps decrease downtime.
Always assume your systems are being probed by attackers looking for weakness in your system. More than likely they have been already. Your defense is to keep up to date on patches, security fixes, and act on new security advisories when they are published.
Educate yourself and your users.
A look at common security models you may use:
I trust everybody on the Internet:
This isn't recommended for anything. I don't think I need to explain why, this is one of the least secure of them all, and shockingly is actually used a lot.
I trust anybody in my system's network:
This model is common in small enterprise networks where the server is protected from the general internet by a firewall, and the internal network is made up of employees of a single company or department at a university.
In this model, malicious users on the internal network are rare, especially if the organization is small, so the system ca afford to provide unencrypted services, give accounts to anybody who asks for them, and even have disabled login security and passwords.
Unfortunately, in large organizations, it has become the case that attacks on servers maintained under this mnodel- attacks from within the network, by people who aresupposed to be trustworthy- Are more frequent than attacks from the outside.
If your organization is large, you must assume that you cannot trust everybody on your system's network, and instead choose a different security model.
I trust my local users:
Admins who use this tend to be a bit more secure than the one before, but it's still quite stupid. I wouldn't trust my users any farther than they would fall from the top story of the building when they accidently fell form the roof after rooting one of my systems... OK so the BOFH part is only for fun...
This model generally has a characterization for tight security policy :
Screening of users before new accounts are granted
Encrypted Network services (Either encouraged or required)
Unused services turned off
And hard to crack passwords
This is great but users generally are allowed to access internet services, see sensitive information (such as encrypted password strings)... The list goes on.
The idea behind this one is that once users are approved for accounts, they are allowed to do as they please. Even though a common threat is account removal, I don't like this model either.
Not many times in your life are you going to have a system where this policy works well. Only very low risk web sites should be using this policy like a fan web site, or community email service.
Although some high profile commercial Internet servers where only a few trusted people actually even have accounts. But as I said before, this is not good enough.
I trust only myself and other admins:
This model is favored by security consious people, as it has not only tight network security as the preceding model, but tight local security as well.
Regular users are denied access to system, configuration files, and server side program code through carefully crafted permissions.
Admin has to watch each user carefully to make sure nothing unauthorized is going on, and special measures (Such as custom shells, chroot jails, and disabling of certain commands (An example would be top, which can display what the admin is doing and if he is idle) are often taken to restrict each user's access to the system's resources.
This is a good model and is used in things like web hosting, or email services like Yahoo! and Hotmail.
After you have decided which model is best for you, you need to look at what rissk you're going to face:
The security risks you face:
Perfect security is a myth that vendors came up with to make you buy the crap they put out. Since you can't get perfect security, you can at least try and decide where the risks in your system are and how to combat them.
Security risks for a network server can be grouped into three major areas:
Root compromise -
An attacker takes advantage of unencrypted transmissions or known programming weaknesses in server software and in the input boundary checking in server software and then gains super-user / admin / root access at the machine.
Generally they then try and install something to help conceal the fact that they are even around and may even install cracked back doored versions of tools such as ps, last, and top, and then can use your system for larger or government targets.
Privacy compromise -
If traffic in and out of your network isn't encrypted ( example: Telnet), an attacker can easily view any of it, watching passwords, credit card numbers, and other sensitive information.
Denial of service -
An attacker can use brute force methods such as sending your server large amounts of traffic bringing your server to it's knees trying to answer all the requests, and stopping it from being able to answer legitimate requests from valid users.
Most of these problems can be stopped with a proper knowledgeable admin, and most of these start because of one or more of the following:
Insecure and weak passwords - passwords that can be guessed or found in a dictionary or password cracker app. You should always check passwords against a password cracker.
Clear text services -Services which don't encrypt traffic like Telnet. Use SSH instead.
Un-needed services that are exploit prone - If you don't need to provide a service, then don't.
Open SMTP relaying - Allowing spammers to use your server for sending spam mail.
No firewall on Network access - Run a firewall to prevent unauthorized traffic from getting into your machine.
Outdated and vulnerable software - The older a software program gets the better chance there is that it has had a security flaw you don't have the patch for. Stay updated.
