OpenBSD Journal

Linux lockdown for BSD admins

Contributed by jose on from the lost-in-Linux-land dept.

(null) writes:
"Whilst this is not directly related to OpenBSD, I was wondering whether OBSD journal readers had found themselves in similar circumstances. We have recently added a Linux box to our otherwise exclusively BSD server farm. Not through choice, but because we have to run a commercial app only available for RH. Our BSD lockdown policy is very clear cut and refined. However, many BSD security mechanisms are not available on Linux (secure levels, file flags, systrace, the minimalist install model etc.). We would like to get the RH boxes host security as near to that of our BSD boxes. Can any of your readership offer hints and tips on such ?"
I came to OpenBSD from Linux, and now I'm utterly lost. Anyone reccomend a good set of resources for a clueful OpenBSD admin to quickly secure a Linux box? I know that with a lot of digging and work it can be done, but what about an efficient system?

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    What app? Most work under linux emulation.

    Comments

    1. By anonymouse () on

      >What app? Most work under linux emulation.

      Yeah, but I can't imagine getting any vendor support if you did that.

    2. By Anonymous Coward () on

      Cold Fusion server. You can barely get sane support under their supported platforms (RH 7.2).

      Comments

      1. By Not Really Anonymous () on

        Why don't you use Windows?




        ...

        Just kidding, thought I would lighten things up :).


        Have you looked into the Linux Bastille project?

  2. By zil0g () on

    I do believe that Linux has file flags, and they should be 'overridable' in single user...

    there are several 'bastion-host'-like scripts and such for linux, especially for RH... but my experience with them tells me they should be avoided at all cost.
    how to lock down RH from the network:
    [root@localhost]# find /etc/rc.d/ -type l |xargs rm -f

    ;)

  3. By sulla () sulla@cert.org on mailto:sulla@cert.org

    Probably you want to take a look at grsecurity .
    • linking restrictions
    • fifo restrictions
    • random pids
    • enforcing nproc on execve()
    • restricted dmesg
    • random ip ids
    • enforced chdir(>random tcp source ports
    • altered ping ids
    • failed fork logging
    • time change logging
    • signal logging
    • deny mounts in chroot
    • deny double chrooting
    • deny mknod in chroot
    • deny fchdir out of chroot
    • deny pivot_root in chroot
    • denied open of /dev/kmem
    • /proc restrictions with special gid set to 10 (usually wheel)
    • address space layout randomization
    • additional /proc restrictions
    • chmod restrictions in chroot
    • no signals, ptrace, or viewing processes outside of chroot
    • capability restrictions in chroot
    • priority restrictions in chroot
    • segmentation-based implementation of PaX
    • mprotect restrictions
    • removal of /proc//[maps|mem]
    • kernel stack randomization
    • mount/unmount/remount logging

  4. By Anonymous Coward () on

    we have to run a commercial app only available for RH

    lemme guess - oracle? oh, no, i think that has SuSe support too. RealServer maybe?

    there is an article on hardening linux in the most recent linux journal. i havent had a chance to read it and i left it at my moms (well it *is* hers) so i cant tell you if its any good, but that should give you some pointers.

    otherwise, all standard rules apply - mount options, file permissions (as mentioned, no chflags though), minimal install (yes its possible, they give you lots of options during install, but it will take a lot of work to not include stuff which has SO many dependencies), firewalling (also on by default), and of course the most important: keep up with patches (up2date is a decent patch managing system).

    oh, actually backups are the most important. dont forget those.

    depending on the app, an approach other than one-server-doing-it-all might be more secure as well (e.g. for a web server, content on nfs mount on bsd box)

    Comments

    1. By Anonymous Coward () on

      Hey is your mom single? How old is she? A mom who read Linux Journal just turns me on! Time to recharge the kinetic watch...

  5. By ka () on

    Just put it behind an OpenBSD firewall, and make it so that only the SINGLE app you need access to, and only your internal network (or better yet, only one host) has SSH access.

    If you're not sure how to best secure it, just limit the shit out of it -- I think thats better than guessing and putting a lot of work into something that can be circumvented easily.

    If your App is Oracle, just allow that port + ssh port for a select few hosts. Same for any other app.

    Good luck.

  6. By homerclese cares not for beans () on

    I built a redhat box, tweaked it according to the following and used it as a border nat/fireball for a year with no probs.

    http://www.tldp.org/LDP/LG/issue54/stoddard.html
    http://www.tldp.org/LDP/LG/issue55/stoddard.html

    This is always a good read as well:

    http://www.interphaze.org/bits/spicegrrlsguide2security.html

    Some sort of host based intrusion detection is also a good idea. It wouldn't hurt to compile a monolithic/non-modular kernel as well, if your app can live without loading modules.

  7. By Isak Lyberth () ily@simpel-it.dk on http://simpel-it.dk

    how about installing WINE and running the IIS lockdown tool?

  8. By djm () on

    Come on, BSD and Linux are not _that_ different!

    Most of the things on that list do exist on Linux. The only one not really there is systrace, which is in beta.

    secure levels -> system capabilities
    file flags -> file flags (chattr)
    minimalist install model -> "rpm -e"

    wrt the "minimalist install model": because of Redhat's fine-grained package management - you can probably get more minimal than a base.tgz-only OpenBSD install. It will probably still take up more room though :)

    Comments

    1. By Anonymous Coward () on

      The standard RedHat install includes a tcl/tk midi keyboard. They have no concept of a minimalist install.

    2. By Anonymous Coward () on

      1. Root system
      2. chrattr -ia *
      all done remotely

      obsd:
      you have to be at the console (physically) to boot single user (no network) to raise to securelevel in order to reset the flags..

      Comments

      1. By djm () on

        Running init from setpcaps is a preety close equivalent for securelevel

    3. By im-b-cille () on

      redhat minimal install more minimal than openbsd?

      you havent exactly ~tried~ both have you?

      if you want a more minimal linux distro try trinux, tomsrbt... etc etc

      or if ya wanna go the bsd route the freebsd folks have their pico...

      as far as redhat "fine grained control" what does rpm do that pkg_add cant?

      Comments

      1. By zil0g () on

        or rm, rather...

  10. By Noryungi () n o r y u n g i @ y a h o o . c o m on mailto:n o r y u n g i @ y a h o o . c o m

    To secure a standard RH installation:

    1. Run Bastille Linux

    2. Make sure you update religiously your installation with the patches available from Red Hat. They have a number of mechanisms for this, including several security-related mailing lists and their up2date service.

    3. Do whatever else is recommended by the other readers. There is a number of How-To manuals available for Red Hat security as well.

  11. By Anonymous Coward () on

    rm -rf / would work nicely

    Comments

    1. By Claer () postmaster@[127.0.0.1] on mailto:postmaster@[127.0.0.1]

      Sorry, but this method is definitively not a good solution to erase your system.

      the rm command will stop after erasing some libs.

      try
      dd if=/dev/udandom of=/dev/hda bs=5120

      much more efficient :)

  12. By Strog () on

    You can use tripwire, a good IDS and iptables to lockdown most of the external issues. You can do nearly all the same lockdowns as OpenBSD but the process might have a few differences.

    Do a few minimal install and watch the security/app mailing lists for everything you do have installed. The lockdown on the apps should be very similar as what you are used to. Make sure you have a good border firewall solution and put a transparent bridging one between this Linux box and the rest world if you are still worrying about it.

  13. By E-Town () djetown@hotmail.com on mailto:djetown@hotmail.com

    I recently ran into the same problem here at my office when I had to implement a backup server capable of handling both OBSD and Netware machines. No backup solutions that I've found will do this on OpenBSD (anybody know of one that I missed?) so I ended up building a redhat box for the job.

    The first step I did in securing the box was to remove all the unnecessary packages from the machine. This took me a couple of hours and I really don't have a good recomendation on how to do this quicker, all I can say is that the kickstart function is great if you need to do this more than once.

    The next thing that I did (and always do) is set as many partitions as possible read-only. Basically, /boot and /usr. Just remember to remount them before updating.

    Now we come to the crazy part, the RH init scripts. From a security standpoint these scripts are total garbage, the default setting for most daemons is that if it is installed run it. Not exactly what we're looking for. So I pretty much ran through the startup scripts commenting out anything that I deemed unnecessary for my application.

    Now to make all that work unnecessary, I then parked this machine behind my OBSD firewall and gave it absolutely no access to the real world. So once again the biggest security hole that I have is that damn MS Terminal Server that the administration love so much.

    Hope this helps on some level. Good luck.

    Comments

    1. By Anonymous Coward () on


      One backup solution that comes to mind, for both OpenBSD and Netware is Arkeia version 5.

      However, their software is still pretty much beta-grade right now, so you should wait for a few months and see if it has become more stable...

      Oh yeah, OpenBSD and Netware are 'client only': you still need a Linux server to be able to backup both.

      Comments

      1. By E-Town () djetown@hotmail.com on mailto:djetown@hotmail.com

        Yeah, I've tried Arkeia 5 but the Linux server is still a problem and the Netware Support is limited to Version 5.2. Sure is better than my current solution (NovaNet) but not quite ready for prime time.

        Thanks

      2. By chkconfig () on http://sucs.org/~sits/

        Why not just use chkconfig servicename off to turn off the services you don't want to run?

    2. By Matt Ostiguy () mostiguy at netnumina dot com on mailto:mostiguy at netnumina dot com

      Opening terminal services thru a firewall is a bad thing. Some people are actively working on a TS brute forcer. Email me if you would like a link or two

      Comments

      1. By E-Town () djetown@hotmail.com on mailto:djetown@hotmail.com

        Yeah, I know. Not really my choice, the admin staff here really got pissed off when I suggested it would be just as easy to forward the service using SSH. But thanks for the heads up.

  14. By Anonymous Coward () on

    Try Titan . It's a set of scripts that do a whole bunch of lock down stuff. You may want to go through them first and see exactly what you need - perhaps they will give you more ideas.

    There are versions for severral *nix OSes - including Linux and FreeBSD.

    Another set of scripts can be found at the Bastille Linux project.

    Comments

    1. By shabashah () on

      security is in the ways of the moose...

      dont run linux.... dont run openbsd...

      run the one true secure os.. 386 bsd!

      Comments

      1. By the_men_with_nets () on

        ok now shabashah... who let you out of your cage?

  15. By Anonymous Coward () on

    Eh? Why the BSD-bigotry? All those features are available for Linux as well. Look at SELinux. That lockdown model probably more advanced than what you are looking for, but you will have no problem locking down your box at least as much as with OpenBSD.

    Comments

    1. By bUff00n () on

      ahh... funny but im not so sure SELinux is "standard" in linux distributions...

      the nsa might have ~just a little~ to do with it

      sure you can add extra security .. key word being ADD



  16. By Tycho Fruru () tycho@fruru.com on http://www.fruru.com/

    in some random order :

    - grsecurity (nonexecutable stack/heap, ACLs, race condition elimination, almost too much :-)
    - rsbac (Role Set Based Access Control ... the real stuff, not even in OBSD)
    - SELinux (another MAC implementation)
    - LIDS (ACLs, privilege limitation)

    OBSD is cool
    Linux is cool
    Use the tool most suited for the job.

  17. By Jason () jason@ironlizard.org on http://www.ironlizard.org

    I don't find that security OpenBSD and Linux differ that greatly. There's a lot of "ultra secure" scripts out there, but if you use common sense and a little work, you'll be just fine.

    First off is recognize the fundamental differences between a default OpenBSD and default RedHat (or Linux in general) installation. The major basic differece is that OpenBSD ships with things turned off (e.g. inetd) or bound only to the localhost adapter (e.g. sendmail) whereas Linux leaves most things on by default. Here's the first common-sense step TURN IT OFF! With RedHat I normally disable inetd, lpd, nfs, portmap, nfslock, rhnsd, and xfs (and httpd/ftp if you installed those - they're not standard).

    The next step is determine how you're going to be using the box. If it's a server for web apps, then you can forgoe some of the steps like ACLs and other operations designed to secure a multi-user system. Determine what you need to provide your service and concentrate on that. If you're using RH, look at the Redhat Network. It's an easy way to download updates to the OS. If you do a lot of RH boxes, consider mirroring the updates.redhat.com as well as the rawhide tree on ftp.redhat.com. Keep an eye on your favorite vulnerability reporting site/list and patch as needed.

    I"ve been running Linux and OpenBSD in a production environment for 2 1/2 years and 1 year respectively. Ironically, the only "break in" I've had in that time was on an OpenBSD box that had SSH open to the outside and someone guessed a user password.

    Keeping Linux and OpenBSD secure are essentially the same once you initially secure Linux.

    Comments

    1. By zil0g () on

      the main diff is that OBSD ships with things turned off??
      'scuse me but WTF?

      so if I put an OBSD box right next to a RH box and start those services on the OBSD box, it will be as insecure as the totally un-audited-gnu-for-brains Linux box?

      and whats this about httpd/ftpd is not standard?
      (I can't remember if inetd was off in 3.1 but it wasen't in 3.0 hmpf)

      basically it sounds as if the WHOLE IDEA of OBSD is missed here, I might as well run RH - gosh then I could even play UT2 on my servers! yippie!

      bleh bleh

      Comments

      1. By Jason () jason@ironlizard.org on http://www.ironlizard.org

        That's not what I meant and I guess I could see how you could take that from what I posted. My only gripe is with people automatically decrying Linux as a insecure and ready to be hacked.

        I totally agree with OpenBSD's philosophy an audited code and how secure the OS is. I run it myself for several jobs that it's very good at. My point is that just because this person has to use Linux for whatever application s/he purchased doesn't mean that suddenly the security is out the window.

        The person asked about securing their Linux box and I shared my experiences. OpenBSD is fundamentally more secure and I'm not disputing that. A fundamental difference is that OpenBSD ships with many things deactivated and Linux does not. But that's not he ONLY difference. OpenBSD's code has an extensive audit process and I think their OS is first-rate. I wasn't meanting to disparage OpenBSD at all.

  18. By gotroot () on

    the NSA has most of the stuff looking for to lock down a linux at http://www.nsa.gov/selinux/index.html
    take a look at it cool stuff

  19. By Sub--Zero () subzero@xena.utcluj.ro on mailto:subzero@xena.utcluj.ro

    Take a look at projects like LIDS , openwall, grsecurity , RSBAC ... or search on freshmeat 'security projects' ... there are many ..or use a secure distribution like Immunix ,Openwall , Castle Linux ...a secure Slackware Distro will be up soon too

    Happy hacking ,
    Sub--Zero

  20. By AnotherAnonymous () on

    There is one security auditing tool I know of that takes care of some very sloppy defaults in RedHat. You can find it at http://www.cisecurity.org/. It basically scans your system for suid binaries, checks usermasks, services etc. On a fresh install the security "score" on a RedHat box is generally about 6.00 or something, the highest possible being 10.00. It also comes with a manual that describes in detail (+sample scripts) on how to correct security issues it discovers. Personally I wouldn't rely on this tool too much but you will be surprised how much it finds and with it you can get the RedHat system in pretty good shape (security wise) quite fast. When you have reached a score of 10.00 I'd suggest you install Bastille on top, After that you might be able to get _some_ sleep ;)

  21. By Dichque () dichque@indiatimes.com on mailto:dichque@indiatimes.com

    http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/index.html

    http://tldp.org/HOWTO/Security-Quickstart-Redhat-HOWTO/index.html

  22. By Anonymous Coward () on

    Look at www.grsecurity.net

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]