Intro to securing Free BSD
Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Intro to securing Free BSD

  1. #1
    AO BOFH: Luser Abuser BModeratorFH gore's Avatar
    Join Date
    Oct 2002
    Location
    Michigan
    Posts
    7,177

    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.
    Kill the lights, let the candles burn behind the pumpkins’ mischievous grins, and let the skeletons dance. For one thing is certain, The Misfits have returned and once again everyday is Halloween.The Misfits FreeBSD
    Cannibal Holocaust
    SuSE Linux
    Slackware Linux

  2. #2
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,403
    Nice read but not a a lot of FreeBSD info. You can use this text for any un*x type OS.

    With a subject like that I was kind of hoping to see something about securitylevels, jails, LKMs, stripping the base OS etc.. Or did you save that for part 2? I'd be glad to help
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  3. #3
    In And Above Man Black Cluster's Avatar
    Join Date
    Feb 2005
    Posts
    912
    Very nice read .... nice introduction .... I hope there is something in the row afterward ... like an intermediate and advanced tutorial .... just expectations ....

    Anyways thanks .....
    You must spread your AntiPoints around before giving it to gore again.
    Cheers mate
    \"The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts\".....Spaf
    Everytime I learn a new thing, I discover how ignorant I am.- ... Black Cluster

  4. #4
    Senior Member
    Join Date
    Dec 2004
    Posts
    137
    Where is the part about raiseing security level of Kernel????

    echo 'kern_securelevel_enable="YES"' >> /etc/rc.conf
    echo 'kern_securelevel="3"' >> /etc/rc.conf

    though you may not want to use 3 per se.

    :-)

  5. #5
    Banned
    Join Date
    May 2003
    Posts
    1,004
    Make sure to include FBSD's joke of a mandatory access control system

    And ignore SirDice's suggestion of writing about LKMs.

    Oh and do a tutorial on jail, so I can do a responding tutorial on why NT's jail equiv is better.

    cheers,

    catch

  6. #6
    AO BOFH: Luser Abuser BModeratorFH gore's Avatar
    Join Date
    Oct 2002
    Location
    Michigan
    Posts
    7,177
    Originally posted here by catch
    Make sure to include FBSD's joke of a mandatory access control system

    And ignore SirDice's suggestion of writing about LKMs.

    Oh and do a tutorial on jail, so I can do a responding tutorial on why NT's jail equiv is better.

    cheers,

    catch
    If you're seriouse we can have a little friendly competition. I used to do this with my teacher all the time. We would see who wrote better essays on tech stuff. So if you want, hell yea, I'm up for it, you right some on NT and I'll do Linux and BSD.
    Kill the lights, let the candles burn behind the pumpkins’ mischievous grins, and let the skeletons dance. For one thing is certain, The Misfits have returned and once again everyday is Halloween.The Misfits FreeBSD
    Cannibal Holocaust
    SuSE Linux
    Slackware Linux

  7. #7
    Senior Member IKnowNot's Avatar
    Join Date
    Jan 2003
    Posts
    792
    Interesting. I know a lot has been written already, but how about including a short understandable comparison on "jail" in a normal *Nix environment vs. FreeBSD ?

    Nothing I've seen lately is recent.
    " And maddest of all, to see life as it is and not as it should be" --Miguel Cervantes

  8. #8
    AO BOFH: Luser Abuser BModeratorFH gore's Avatar
    Join Date
    Oct 2002
    Location
    Michigan
    Posts
    7,177
    Sure, I can try for something like that in one of the next ones. I'll do the "jail" one for you
    Kill the lights, let the candles burn behind the pumpkins’ mischievous grins, and let the skeletons dance. For one thing is certain, The Misfits have returned and once again everyday is Halloween.The Misfits FreeBSD
    Cannibal Holocaust
    SuSE Linux
    Slackware Linux

  9. #9
    Senior Member IKnowNot's Avatar
    Join Date
    Jan 2003
    Posts
    792
    This is timely because just today I e-mailed a friend attempting to explain it and what do you know, the e-mail was longer then the first page of your tut! Imagine that, me long-winded!
    " And maddest of all, to see life as it is and not as it should be" --Miguel Cervantes

  10. #10
    AO BOFH: Luser Abuser BModeratorFH gore's Avatar
    Join Date
    Oct 2002
    Location
    Michigan
    Posts
    7,177
    Yea I thought it was short too, but it's really because I've never written a multi part tutorial before, like ever, and I wasn't sure how much to put into it, and to me an intro tutorial should explain a few things, go over a small amount of information, and then end before the reader loses interest.

    I'm not lazy, I just wanted it to be short because as I said, an intro should be. If I wrote it out to be 5 pages or more, it's not an intro at all, and makes it very hard to make everythin in order.
    Kill the lights, let the candles burn behind the pumpkins’ mischievous grins, and let the skeletons dance. For one thing is certain, The Misfits have returned and once again everyday is Halloween.The Misfits FreeBSD
    Cannibal Holocaust
    SuSE Linux
    Slackware Linux

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •