July 14th, 2002, 03:42 AM
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.
July 14th, 2002, 05:04 AM
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.
\"The most beautiful thing we can experience is the mysterious. It is the source of all true art and science.\"
~ Albert Einstein ~ [/shadow]
July 14th, 2002, 05:53 AM
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
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
July 14th, 2002, 06:59 PM
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?
July 21st, 2002, 10:41 PM
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.
July 22nd, 2002, 01:23 AM
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/*
July 28th, 2002, 08:44 AM
Use postfix over sendmail.