Common *nix Security Practice's
Page 1 of 3 123 LastLast
Results 1 to 10 of 28

Thread: Common *nix Security Practice's

  1. #1
    King Arana: Super Moderator
    Join Date
    Oct 2002
    Posts
    4,055

    Common *nix Security Practice's

    Greetz AO'er's. This tutorial is going to be an overview and some information on common and even uncommon Linux/Unix security practice's. Throughout this guide, you'll learn how to "harden" your box by performing a few common security practice's. Let's not waste time and jump into some common Unix security practice's.

    Unix Security Practice's: What You Should Do

    -- If you have root access to your system, it's best if you rarely (if ever) use that account. The more you do, the more and longer you leave yourself susceptible to an attack which would compromise the account. Instead, create an account similiar to root with root-level privledges and rename it.

    -- If you wanna feel safer, block login's to root. As stated, rename it something different to confuse hacker's and so they won't know which to go for if they wanna "root" your box.

    -- Limit or Eliminate su access to root.

    -- Password security is a must, make sure your password's are very difficult to crack and should be mixed character's. Don't forget to make it something you can remember, like perhaps your nephew's birthday or something (for example, Jack61690 would be a good password) would be great. Even scrambling mixed character's make's it a great password, just tough to remember (i.e jg859jo59fk). It might even be noted that you should change your password often.

    -- Honeypot's/Firewall's are a must for any system in today's world. Constant port probe's and random vulnerability scanning can lead to your system being a target. Be sure to install a honeypot or a firewall shortly after install. Moniter the logs and test your setting's. Configuration is key when installing a firewall, so read the installation instruction's carefully.

    -- As with any system, backup your file's every so often in the event of an intrusion. Always, ALWAYS have backup's.

    -- A/V software is key to any Unix system administrator or even a home Linux user. It is vital to download one after installation. Always keep up with the update's and download them as soon as release. Be wary of what you download off the internet. There will always be new worm's and new virii all the time so keeping this updated is critical.

    -- As with any other system, ALWAYS be on the lookout for the latest updates and patches for your Unix/Linux machine. One of the worst thing's to have to worry about is to have a hacker hack your OS because of a non-patched bug. Always download the latest patches and keep up with the newest modification's in your OS.

    -- IDS system's and other tool's of the like work wonder's. Use them to your advantage and if your capabilities extend that far.

    -- Common logic about email attachment's: Use Common Sense. If you don't know the person and they want you to open a file on your computer, chances are it's something malicious and harmful.

    -- When it comes to securing your system and Computer Security in general, paranoia is a good thing.

    -- Be careful of user access and file permission's on your system. Create user level's with permission's that you feel are needed, don't make any that is not needed.

    -- Turn off/shutdown any service's or server's you don't need or use. All it does is open more holes into your system for a hacker to exploit. Close any port's that you don't need open.

    -- Perform weekly or daily virus scan's for infected software. Even if you have auto-detect on, it's still a good choice to scan anyways.

    -- Use chmod to your liking and how you want file permission's to be set.

    -- If on a network (or even home, as it could happen) be sure to not let any user rm -rf as you don't want your files and everything deleted because of something as silly and stupid as that.


    Well, those are my tip's and practice's on securing your *nix box. Hopefully you found this tutorial helpful and you'll apply these tip's to your system, as it's designed to secure it. Remember, your box is only as secure as you make it to be
    Space For Rent.. =]

  2. #2
    -- Download Spyware Protection. Spyware/Malware/Adware has quickly and quietly become a problem in the security world and has grown more and more annoying as time progresses. Save yourself alot of hassles by simply downloading spyware protection.
    I didn't know marketers targeted *nixer's....

    Is there a *nix spyware scanner?

  3. #3
    King Arana: Super Moderator
    Join Date
    Oct 2002
    Posts
    4,055
    Ahh good point, I was thinking of security in general at the time.
    Space For Rent.. =]

  4. #4
    Senior Member
    Join Date
    May 2004
    Posts
    519
    its a good outline of what needs to be done, often little things like renaming "root" can be overlooked

    I know i have seen heaps of people who use the "root" account as their general account .......

    little practices like you have outlined are awesome to get into .. welldone

  5. #5
    King Arana: Super Moderator
    Join Date
    Oct 2002
    Posts
    4,055
    Thanks Yeah, well I created a smaller account for me to do my general stuff on while on the FreeBSD box. One of the main rule's of security (IMO) is to rarely use the superuser account (whichever it may be, whether *nix, Window's, etc) at all and to create another account to use as the general one.
    Space For Rent.. =]

  6. #6
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    Ok, my recommendations:

    1. DO NOT under any circumstances, install any honeypot software anywhere near a production machine. Honeypots are for fun and catching attackers; they need to be installed with great care and in a very sterile carefully prepared environment. And nowhere near a production machine. Remember that not all honeypot software is free from vulnerabilities itself.

    2. Don't rename root. It is pointless and may break stuff. For starters, renaming root instantly breaks most of "inetd" services. DO disallow non-local root logins via sshd, FTP etc.

    I think that limiting your usage of the root account is mainly for safety rather than security. If someone compromises your user account, they only need to trojan "su" (which can be done with shell script), and they have root too.

    IDS are nontrivial to maintain, and use up a lot of system resource (as well as the administrator's time). If you don't have time to spare to take care of your IDS properly, don't install one as it will be counter productive. If after two weeks you have 10Gb of logs, you aren't going to bother sifting through them to find the 10 lines caused by attackers in the 100million caused by worms.

    Obviously if you start having IDS on a production system, it can also use up CPU time and fill your disc with logs.

    IMHO, the jury is out of Unix AV software - if your preferred vendor has a sufficiently mature package - by all means go for it.

    Unix AV software is still in its infancy, and while most vendors provide an on-demand version of their AV for Unix, few do on-access (due to the difficult of interfacing with the range of Unix kernels). Also bear in mind the performance hit caused by on-access virus scanning, this is pretty severe on some Windows versions.

    Not all servers need AV software either. If they aren't handling windows files on a regular basis, there is no real possibility of getting viruses, therefore it's unnecessary. For example, with a database server you could find that the overhead of an on-access virus scanner decreases performance a lot - and even if the database contains win32-based files - would the AV even find them buried inside the DB?

    Slarty

  7. #7
    Good work, but I have a few beefs with some of these:

    -- If you have root access to your system, it's best if you rarely (if ever) use that account. The more you do, the more and longer you leave yourself susceptible to an attack which would compromise the account. Instead, create an account similiar to root with root-level privledges and rename it.
    Rename it? No, that would defeat the entire point of the saftey of root anyways. Why? Because not only would you have one account with full system access, but two. And as stated already, renaming root kills a lot of services because of how deeply the root account is embedded into the UNIX tradition. Only one super user, period. For users that you want to allow root access via su root, place them in the wheel group. Adding a second super user only means a second chance to be broken into.

    -- If you wanna feel safer, block login's to root. As stated, rename it something different to confuse hacker's and so they won't know which to go for if they wanna "root" your box.
    Remote login to root is fine to block. Block local, and you may end up having a ton of problems because su root, in some cases, simply won't cut it. Especially if that user's home directory is corrupted. And as I stated above, renaming the root account will have SEVERE system consequences.

    -- Limit or Eliminate su access to root.
    While a good idea, that's something that could effectivly ruin your system. Let's say you want to check logs? Modify services? Lock down the firewall.sh? Modify the rc.local file? root needs to do that, and that means your normal user has to use su root, meaning they need su to modify the system so they won't login as root. See why it's bad to give another user root in my statement above.

    -- Password security is a must, make sure your password's are very difficult to crack and should be mixed character's. Don't forget to make it something you can remember, like perhaps your nephew's birthday or something (for example, Jack61690 would be a good password) would be great. Even scrambling mixed character's make's it a great password, just tough to remember (i.e jg859jo59fk). It might even be noted that you should change your password often.p
    NIX password handling goes beyond that, including special chars and encouraging to include lower and upper case. Here is a very good password example: 0MfG_4Ev@_

    1. It's longer than 8 letters, beating a lot of commonly used brute force password crackers.
    2. By including special chars (@ and _) that opens up an entire new range of characters that require brute force, and a ton of extra time.
    3. The combination of upper and lower doubles the possibility checks.
    4. Even if they got the entire part up to the _, if the password cracker stopped there they would still not be able to get in because they would not have expected a special char after the commonly used internet phrase "4eva"

    -- Honeypot's/Firewall's are a must for any system in today's world. Constant port probe's and random vulnerability scanning can lead to your system being a target. Be sure to install a honeypot or a firewall shortly after install. Moniter the logs and test your setting's. Configuration is key when installing a firewall, so read the installation instruction's carefully.
    This was discussed above, but running one is haphazord as it is basically inviting people to give your server a shot. This is not meant for security issues, but usually placed on the outside of the network to entice crackers to get that instead of the real network, thus trapping the cracker. And... the key to UNIX security is to not run things that are not absolutley requires. Having a honeypot service running opens you up to the DoS of that honeypot as well.

    -- A/V software is key to any Unix system administrator or even a home Linux user. It is vital to download one after installation. Always keep up with the update's and download them as soon as release. Be wary of what you download off the internet. There will always be new worm's and new virii all the time so keeping this updated is critical.
    AV software? Just don't run things in root, and only su root when the event requires it and you fully understand the event.

    -- IDS system's and other tool's of the like work wonder's. Use them to your advantage and if your capabilities extend that far.
    An IDS can be quite a load on hardware and software alike. For a simpler solution, monitoring of each and every packet is not needed. Why? Just monitor the logs that the services you are running create. If you see suspicous logs in apache, ssh, and smtp, then you know something is going on. However, trying to sift through 20 gigs of log files when you really are only going to have 5k of suspicous files and 19 gigs of work and ACK requests.... ouch

    -- Common logic about email attachment's: Use Common Sense. If you don't know the person and they want you to open a file on your computer, chances are it's something malicious and harmful.
    This is really only windows specific, since NIX doesn't use exe's, and the user (shouldn't) be running in root to allow any possible virus to spread beyond /home.

    -- Perform weekly or daily virus scan's for infected software. Even if you have auto-detect on, it's still a good choice to scan anyways.
    Once agian, moreso windows specific, but I get what you mean.

    -- If on a network (or even home, as it could happen) be sure to not let any user rm -rf as you don't want your files and everything deleted because of something as silly and stupid as that.
    No, never ever do this. If a user wants to rm -rf gaim-0.7 in their home directory they need to be able to do that. Removing the rm -rf function is something that doesn't need to be worried about. If chmod settings and permissions are done correctly, they can't rm it anyways. But.. wow.. to deny that simple function that not only helps a user clean out his home directory.. but is REQUIRED to delete folders... please don't do this to your users. Just ensure proper permissions are set

  8. #8
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,883
    Honestly, this "tutorial", should be removed from the site. I'm not trying to be mean or nasty but it is about 90% rubbish. There are plenty of sharp people here who wont be misled by the information, however, there are many more that could easily bust up a production web server (or any number of other services) by doing the things suggested by the poster. Security does not equal inoperability, which is exactly what will happen to *any* unix system you do these things to.

    --TH13
    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

  9. #9
    I'm going to have to agree with horse on this. We aren't trying to be mean or hurtful, but the information provided here is inaccurate for nix systems, to a dangerous degree. This does need to be removed or at least allow the author time to make major modifications so that we can still honor his attempt.

    In fact, this makes a MUCH better Windows security tutorial, as almost every point is much better focused towards a windows point of view.

    The danger we see (so parent poster knows we aren't just trying to be jerks) is that, if someone who is unlearned in the art of *nix does take this as insight into server security then they risk opening their system up in ways that severly make their entire network insecure. Tutorial writing comes, I feel, with a responcibility that the information you provide may be used somewhere in reality and applied to every letter you wrote down. This means the fame as well as the tears.

    Keep that in mind

  10. #10
    Just a Virtualized Geek MrLinus's Avatar
    Join Date
    Sep 2001
    Location
    Redondo Beach, CA
    Posts
    7,324
    Moved from Security Tutorials to *Nix Security Discussions. Spyder32, perhaps look at the comments and give another try again.
    Goodbye, Mittens (1992-2008). My pillow will be cold without your purring beside my head
    Extra! Extra! Get your FREE copy of Insight Newsletter||MsMittens' HomePage

Posting Permissions

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