Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 50

Thread: UNIX - Linux - BSD Security Tips

  1. #11
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Washington D.C. area
    Become very familiar with the following two things:

    GUID and SUID.

    If configured properly, no one will be able to pwn you.

    As already mentioned, be sure that you make separate partitions because if you run out of disk space your box will topple over. At VERY least, make a separate VAR partition. A major bank came to a grinding halt because they did not follow this very basic rule. Turned out that the log files in VAR ate all the disk space and their pretty Solaris boxes choked.

    Implement LEAST privilage.
    Use TCP Wrappers for SSH sessions and everything else that does not require global connection audiences.

    Change the sshd.conf file to use protocol 2. This should be self explanitory to anyone who's been around for a while.

    Create a user account. Do not use the admin account as a user account. The best thing ever is to see someone jump on IRC as user:root. Can you say pwned?

    Just a quick few off the top of my head.

    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  2. #12
    An entire book could be written on custom *nix security mods, but i'll just try to cover the high points...P.S...Im specifically talking about OpenBSD here, but the principles should apply to almost any POSIX complaint system.

    Most importantly the kernel is copied to a read only media (like a CDROM). /etc/boot.cfg is configured to boot the kernel from a cdrom that is specifically used for this purpose. As long as your /dev permissions are setup correctly, this is a great way to prevent someone from modifying your kernel.

    Default OpenBSD installations need a little tweaking on some of the file permissions (like /etc/security, /etc/pf.conf, /etc/daily, /etc/weekly, /etc/monthly, ...among others) because some of these are world readable when their really is no reason to be...just use the "find / -perm *" command to search for these types of files...

    Any installations of MySQL, Apache, *GASP* Sendmail, or anything else high-risk ; should be run in a chroot jail. Inside the jail are the bare minimum files needed for the application to run. Everything should have the proper permissions and kernel flags are set on files that should never be written to, and log files are made append only. For added security the jail is called by systrace, thus protecting everything at the kernel call level. This can be a real pain to setup, but when done correctly is very secure.

    File auditing is configured using the mtree command...Mainly you will want to watch important binaries and configuration files...

    Again...This is by no means complete, just some important steps...I'll be more then happy to elaborate on the specifics if any one cares to know...
    We are a generation without a middle. We have no great war or depression. Our war is a spiritual one, our depression is our lives. We were all raised to believe that we\'ll all be millionaires and rockstars - But we won\'t.
    And we are slowly learning this fact...And we are VERY pissed off about it!

  3. #13
    Senior Member gore's Avatar
    Join Date
    Oct 2002
    Just to pop in on What TheHorse said:

    In a scale of 10, permissions done wrongly, SUID, and GUID would probably be a 9 on the uh oh.

    And I myself has accidently got on IRC as root, which some people may remember, the only thing I said was "oops" then /quit lol.

    Going on IRC as root is like going to 8 Mile in Detroit with a Mercedes Benz and leaving everything un-locked.


    Free BSD, when you install it, if you tell it to use Auto, it makes partitions for every file systems seperate. This is something that may help someone out who isn't sure.

  4. #14
    Senior Member
    Join Date
    Oct 2002
    Personally, I have a firewall set up right now running from a Slackware box, although I'll likely move that to BSD soon enough. I've found that using smoothwall/ipcop and the like just provides you with a fancy GUI and a default firewall ruleset. Beyond that, there's really no advantage to running boxed firewalls. Any custom software I install on those boxes inevitably ends up interfering with the default installation, and makes upgrades a nightmare.

    I take a look at common firewall rulesets for these distributions every so often, make sure my firewall rules do at least what theirs do. I also have a few extra standard rules thrown in to make me a bit more secure. First of all, the first connection attempt from any one address is dropped on the floor. There is a 3 second delay after that before allowing any connection. This has proven to me to be very effective in keeping worms from finding my network. It effectively blocks around 90% of all worms from ever targeting me in the first place.

    The firewall does have a compiler accessible on it, however, any compilers and/or script interpreters, save for bash, have been moved a a CD and simlinked to it. This way, there are no compilers accessible on the box unless I physically put the CD in the drive. In front of that, any ssh access to the box is forced to first pass through a chroot environment before connecting via loopback to the root filesystem. This provides a smaller doorway with which to monitor any intrusions or attempted intrusions.

    The server machine, which is running the webserver, file server, mysql server, squid proxy, and a bunch of other stuff (I'd have to look up exactly what) also has the same precautions in place for ssh access. I must first pass through a chroot doorway.

    The firewall box is running snort, with bleeding snort rules updated daily via a cron job. I then have my own thresholding and/or suppression rules in place to tune down the false positive rate, and an awk script which is used to tune those rules a little further to suit my needs. Snort is also chrooted to its own filesystem, and is physically located on every local segment as there are 5 NICs in the box, 2 of them without a valid address. Port spanning is then used to allow Snort to see all the traffic on the network.

    Snort logs to a mysql database on the server, which is managed and configured with a BASE console (and yes, the webserver is also running chroot). Obviously, the snort logs are inspected daily (well, okay, maybe bi-daily) for any intrusion attempts. The number of SSH bruteforce attempts I log when I turn off TCP wrappers is disgusting. I really do need to write an automated reporting script to send the reports for me, or at least write them.

    I find that a major advantage to chrooting all my services in this manner is that I prevent local services from directly communicating with each other. This communication can now be far more easily controlled and monitored at a firewall level, instead of a filesystem/kernel level --- far simpler I find.

    Any SSH connections are forwarded to the server (not the firewall). The firewall does not allow connections from the Internet. I tried turning off SSH entirely for a while on the firewall, but found it to be more trouble than it was worth. So now the firewall will only allow SSH connections from the internal network, and even then, only after passing through a chroot doorway first. Root access into this doorway (I like to think of it as the mantrap in high security buildings, or just the space between the two sets of doors in shopping malls) is prohibited via PAM.

    Well now I must be missing something...

    Well that's what I can think of in terms of network security. There's also a few things done at a host level. First thing I do after installing the base operating system is to run a complete suid/sgid search through the entire filesystem. Very few services actually need this. Ping, for example is suid by default; I have no reason to leave it like this. All it does for me that way is provide another way to access root permission, another vector with which to compromise me. Any unnecessary suid/sgid permissions are removed. The webserver is not permitted write access to its own filespace. Instead, all files it needs to access are are owned by the httpd group and the root user. The httpd group is given read access, but not write access. It has its own /tmp directory to which it has write access to. MySQL is secured in much the same manner. Aside from the normal password policies, it is only allowed write access to the /var/mysql directory, and only by group membership.

    I have installed PAM support to the box, and added mysql support to the nss switch. Pam is used to authenticate against the mysql database via the channels provided by pam_mysql. Since pam_mysql can only be used for authentication, and has no mechanisms by which to modify the information, nss_mysql is used, and the PAM stacks have been modified to search the mysql database before checking local files for users. With PAM, I am allowed far greater control of how the authentication and authorization processes on the box are performed. There are a gazillion pam modules written for just about anything I want them to do. Unfortunately, this requires me to compile everything with PAM support on, as Slackware does not yet include PAM support.

    I have AIDE running on the box, checking the filesystem daily for any modifications. The trusted list of hashes is stored at another location on the Internet (used a VMS box for it to teach myself the basics of VMS). AIDE compares its calculated sums to those stored elsewhere. In this manner, the list of hashes cannot be modified locally, although it would not be a big deal to change the AIDE scripts to always report a clean system. It does provide limited extra protection though, and was a decent challenge to set up and run properly. Any file differences it finds are saved to a text file which I can access locally on the webserver. Logwatch is also run, with a few extra modules installed for it. It as well records any activity it sees to a directory off the webserver root, to allow me to more easily check the logs. Logwatch is also run again for the chroot shell environment.

    I have all services logging to a chrooted syslog daemon, by creating a /dev/log entry in each of the chrooted filesystems. I have recently been toying with the ulogd services being written by Harald Welte. It shows great promise IMHO, but is nowhere near complete yet. With it, firewall rules can be logged individually to separate text files. There are logs in place for connections to each individual server, The webserver has one, the sql server has one, bla bla bla, all in separate log files. Any other connection attempts are logged to an incoming connections log file. There are log files in place for invalid (both in terms of state and flag combinations) packets, source routed packets, spoofed packets (as can be determined by either having an incoming RFC1918 address, an incoming address matching my network address, or any incoming address not in use by IANA). There are a few iptables extensions used as well. I have the passive fingerprinting module running, and it generates a log of operating systems that either I connect to or that connect to me. I periodically look through this file and report what I can know to the developers to help build the database. The iptables portscan match is also used to try to log any portscans. It is also used to bring up additional defenses in the event of a suspected attack (as much as can be learned from a portscan, anyway).

    I have been playing with a few other iptables matches and extensions. The MIRROR target is great fun, it switches the source and destination addresses on a packet and resends it. I get to watch skiddies try to crack their own boxes. Great Friday night entertainment. The TARPIT module, modeled after LeBrea tarpits, can slow portscans to a crawl when deployed effectively. I'm still working on figuring it out completely. I am slowly integrating the nflog target as it is developed to co-operate with the ulog target and the logging system I have in place. The nth target is fun to play with as well, I used it to build a portscan defense that throws back random static when portscans are detected. The random match is even better, although requires slightly more overhead. I send back random replies to connection attempts between icmp destination unreachable, allowing the connection, and RST packets. Building that was a great exercise in firewall management and construction. Geoip is fun as well, I can block the entire country of Belgium, for example, and that keeps evil people like Negative and Shrekkie off my server. Not much use to me, but fun to play with. There are also ipsec patches to provide additional netfilter hooks for ipsec traffic, and although they show promise, I haven't had a chance to play with them yet.

    I'm working on a php solution which can effectively condense the information I have in all these log files, or at least provide a convenient GUI for them. The big problem with having so many log files to monitor is that although they provide a wealth of information when I need it, just navigating through them can be a nightmare. A nice web page would be a major plus if I could get one written.

    That's what I can think of in terms of the steps I take beyond the standard close-all-services, check-all-permissions, put-a-firewall-up steps and what has been previously mentioned in this thread. May be a bit much, but it's more academia than function.

    This is what a portscan looks like to ShieldsUp:
    Government is like fire - a handy servant, but a dangerous master - George Washington
    Government is not reason, it is not eloquence - it is force. - George Washington.

    Join the UnError community!

  5. #15
    Senior Member IKnowNot's Avatar
    Join Date
    Jan 2003
    I am not going to go into it too far, but gore started this thread with a specific purpose in mind. Be that as it may, I watched, saw a lot of useful information to those managing a *nix box, but waited until I could provide something constructive, . I hope it is useful.
    An entire book could be written on custom *nix security mods, ...
    I think I have read several, with hundreds more out there I haven't read.

    In a scale of 10, permissions done wrongly, SUID, and GUID would probably be a 9 on the uh oh.
    I would rate it a 10, but that is me ... why waist time on file permissions if it can be overridden?

    The firewall box is running snort, with bleeding snort rules updated daily via a cron job.
    I would never run SNORT on the same box as a firewall. Is that what was meant? Most ( unlike me ) can afford a separate commercial firewall solution, but in any case, they should be separate. ( Depending on the network design, several SNORT boxes my be necessary. )

    I have been playing with a few other iptables matches and extensions. The MIRROR target is great fun, ...
    As I have stated before, yes, it is GREAT fun, but could lead to problems, including a Dos attack. One must know what they are doing before implementing this filter. If you do, HAVE FUN WITH IT!

    One of the reasons I don't use any of the freely available firewall packages is because any serious firewall will not have a GUI enabled ( x-windows ). If this is an externally facing device, why have anything enabled that does not absolutely have to be running?

    With that in mind, my contribution to this thread is this:

    How many of you, on a firewall, DNS box, etc., allow GPM ( general purpose mouse) to run?

    If so, WHY ? It is enabled by default by all the distros I have encountered, but is unnecessary. Just another avenue to exploit.

    Just my opinion.
    " And maddest of all, to see life as it is and not as it should be" --Miguel Cervantes

  6. #16
    Senior Member gore's Avatar
    Join Date
    Oct 2002
    Originally posted here by IKnowNot
    How many of you, on a firewall, DNS box, etc., allow GPM ( general purpose mouse) to run?

    If so, WHY ? It is enabled by default by all the distros I have encountered, but is unnecessary. Just another avenue to exploit.

    Just my opinion.
    It's not on at all with default SUSE.

  7. #17
    Senior Member gore's Avatar
    Join Date
    Oct 2002
    One more tip for Samba:

    This is true on FreeBSD, though I can't say for sure on anything else:

    Ennrypted passwords are generally a given, but on the server end, it's actually a risk. Here is why:

    The Encrypted passwords for Samba that are stored in the /usr/local/private/smbpassd file, are the same sent over the wire. Encrypted Samba passwords therefore, are almost the same as passwords stored in clear text. If an intruder broke in and got access to this file, they would be abel to log in as ANY user, even root.

    The files in /etc/master.passwd actually have to be cracked. Gaurd /usr/local/private/smbpassd the same if not more than the /etc/master.passwd file.

    (*Translated from FreeBSD Unleashed Second Edition*) I highly recommend this book. I didn't copy and paste or type the exact tip it had, but I felt some of it would be of use here for this thread.

  8. #18
    They call me the Hunted foxyloxley's Avatar
    Join Date
    Nov 2003
    3rd Rock from Sun
    Just a quick question, bearin in mind I'm MS windows orientated, and a complete new start in any open OS you may care to think of

    SO :
    question ......
    The best thing ever is to see someone jump on IRC as user:root. Can you say pwned?
    could someone elaborate on this please
    is it akin to surfing in windows as admin ? [stop th elaughing out there PLEASE ]

    I am aware of the 'importance' of root, as opposed to 'user'
    but a short outline would be of help
    so now I'm in my SIXTIES FFS
    WTAF, how did that happen, so no more alterations to the sig, it will remain as is now

    Beware of Geeks bearing GIF's
    come and waste the day :P at The Taz Zone

  9. #19
    Senior Member
    Join Date
    Feb 2002
    is it akin to surfing in windows as admin
    Yes. The root user in Unix systems has complete control of the system. He/she can make system wide changes--up to and including deleting the system itself If someone is able to achieve root on a Unix system, they are able to do anything they want with it.

    See this link.
    For the wages of sin is death, but the free gift of God is eternal life in Christ Jesus our Lord.
    (Romans 6:23, WEB)

  10. #20
    Senior Member gore's Avatar
    Join Date
    Oct 2002
    I've had a good responce from this thread, and quite a few people have thanked me saying it was some of the best stuff they've read in a while.

    So, to help keep it going longer:

    Thought for the most part it's been things you alone use yourself, if you find a good tip somewhere else, as I have done in here quoting some of the books I own, go ahead and post those too. Just be sure to quote sources.

    I think I forgot to add this so here is another that I know for a fact works on Linux and I think BSD:


    Edit that file and comment out everything except /dev/tty1

    What have you done? Well, you've now told your system you don't want root to be able to log into ANYTHING except the physical consol TTY1. TTY2 and so on won't allow root log ins and neither will X. It's not fool proof... However it's great for a machine you have with you at all times.

Posting Permissions

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