Security Best Practices
Results 1 to 7 of 7

Thread: Security Best Practices

  1. #1
    Junior Member
    Join Date
    Jul 2002
    Posts
    14

    Question Security Best Practices

    I have been given a task of putting together some standard security best practicesfor our Unix Servers. We use RedHat on our machines. Would anyone care to share some of the security steps that you would recommend when setting up a unix server. Obviously unplugging it is the best security feature, however, that is not going to deliver the email or web pages.

    We have done things such as disabling telnet and using ssh instead. We dropped the wuftpd package and replaced it with proftpd, however, I am still not convinced that is a big plus.

    We installed tripwire and that seems to be informative, however, it stands to reason that once you see the tripwire report that tells you that files were changed it is too late.

    I look forward to hearing your responses.

    Dave

  2. #2
    Member
    Join Date
    Jul 2002
    Posts
    38
    Have you considered running an IDS on your servers? In order for someone to do anything to your servers, chances are, they will have to do something to trigger an IDS alert. Snort works great for network IDS and there are some pretty good commercial host-based IDS systems out there.

    I have plenty of experience in this arena and IDSs work great to see if someone is knocking at the door or manages to get past the first level of defenses.

    ...aberration...
    [shadow]
    \"The most beautiful thing we can experience is the mysterious. It is the source of all true art and science.\"
    ~ Albert Einstein ~ [/shadow]

  3. #3
    Junior Member
    Join Date
    Jul 2002
    Posts
    8
    A few suggestions:

    1) Use Sudo to limit who can access root via su and execute programs

    2) Use Shadopasswords: type pwconv on the commandline in root there is
    a few more security steps by the way on the commandline in /ect do
    the following:

    chattr +i shadow
    chattr +i group
    chattr +i gshadow
    chattr +i passwd
    chattr +i passwd.bak

    btw to change any passwords you have to unchattr
    these files the same way

    3) In ect chattr +i the service file to protect it against
    someone modifying this file and adding services you didn't ok.

    4) If you have printers make sure there not broadcasting or
    open to connection Hackers will detect like port 515 or>>> cups
    you can restrict the printer to local only cd/ect/cups/cupsd.conf replace
    port 631 with something like this: listen 127.0.0.1:631 and you can do the
    same for lan IP and port 80......... then you have to update cups
    cd/rc.d/init.d on the commandline type: ./cups restart (that's what I do
    with my printers)

    6) Change the default shell from bash to tcsh at least for root
    because bash isn't secure

    7) Fix the permissions of the init.d directory: chmod -R 700 /ect/rc.d/init.d/*
    one more thing I'd suggest is restrict anyone from doing /locate root

  4. #4
    Junior Member
    Join Date
    Jul 2002
    Posts
    14
    Great! Thanks for the input.

    On the subject on IDS what is the most popular? We have tried tripwire. I am going to try snort to see how that works. Any other programs I should look at?

  5. #5
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    I'm currenting testing snort at work with our sysadmin guys. Like any IDS, it needs tuning but is useful.

    As far as securing your boxes is concerned, all the normal rules apply:

    - Turn off all (network) services, then
    - Turn back on things as you need them
    - Block services by IP if possible, otherwise be very careful

    - Don't install too much unnecesarry stuff esp if it uses set uid binaries

    Do not chattr +i /etc/shadow. That is stupid.

    You will only make it hard for yourself to change passwords. Anyone who can get root to write to /etc/shadow in the first place can do an awful lot of damage without being about to write to shadow. Also they can chattr it back again easily.

    chattr +i /etc/shadow is like closing the stable door after the horse has bolted.

  6. #6

    chattr +i /etc/shadow can be good

    Just a note, if you change the attributes on /etc/shadow to immutable "chattr +i /etc/shadow"
    its not necessarly a bad thing.

    If your host is a garden variety web server or router for example, you have added all the users you intend to add, then chattring /etc/shadow isnt that bad of an idea. If you wont be adding any new users that is.

    basically if you have added all the users you intend to have on the box then sure, go ahead
    and try it, you can only learn from any / all mistakes you make anyway, so its all good regardless. Plus someone said you can just change the attributes back...sure you can, but
    every layer of security helps.

    Also someone said you can just change the attributes back, their are a few problems with that statement.

    1. some script kiddies wouldent figure out that /etc/shadow had the immutable bit set.
    2. some generic "local and or remote root exploits" require writing to /etc/shadow, setting this bit can even stop some exploits.
    3. if you (like i do) remove "chattr" and "lsattr" from the machine, then the users cant even check to see if the immutable bit has been set, if they figure out its been set, they have to download the package, install it, and then remove the attribute that way, alot of work for the average ./script kiddie.

    point of the point - DEFENCE IN DEPTH, every little bit helps, as long as you know what your doing and you can find some common ground between security and usability.


    p.s - try removing chattr and lasttr after your box is ready, it makes the script kiddies life harder, and thats always fun.


    p.s.s - here's a better idea for chattr. Use it in conjunction with tripwire / md5sum to add further protection to your system binaries located in /bin /sbin/ etc.. and your system libraries as well.

    chattr -R +i /bin/* /sbin/* /usr/bin/* /usr/sbin/* /lib/*
    chattr -R -a /var/log/*

  7. #7
    Junior Member
    Join Date
    May 2002
    Posts
    23
    Use postfix over sendmail.

Posting Permissions

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

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides