Security Planning
Config Changes to Tighten Security
Ideas from June 26 meeting:
- Firewall changes, see SystemInstallChecklist
- See below...implement SSH timer (see below)
- Remove C compilers where not needed (+SPM Compilers may be needed as part of ATLAS software install/testing)
- More Kerberos Tickets, SSH keys. Less passwords (+SPM All Tier-2/Tier-3 users should havve SSH keys)
- Stricter limits on ssh (+SPM We already have a timer setup for SSH...brute force shouldn't work. TODO: Add example of iptables timer config for SSH)
- Add the following to
iptables
. Note use '-i ethX' where 'ethX' is the public port on the node.
#+SPM Added January 31 2008
# Block brute force attacks
# Drop repeated ssh connection attempts within 20 seconds interval
-A INPUT -p tcp -m tcp -m state -m recent -i eth1 --dport 22 --state NEW -j DROP --rcheck --seconds 20 --name THROTTLE --rsource
# Accept ssh connection if not attempted within past 20 sec.
-A INPUT -p tcp -m tcp -m state -m recent -i eth1 --dport 22 --state NEW -j ACCEPT --set --name THROTTLE --rsource
# End of January 31 2008 addition +SPM
- Sudo vs. lots of root logins (+SPM I think it is OK to disallow password root access but we need to be careful. Problems which prevent user login and require 'root' to fix come to mind...)
- We need to disable
root
logins via the network. Unfortunately we can a) Disable ALL root logins or b) Only allow key'ed logins (no passwords) but not both. This means that we have to choose. Ideally we want users to be able to use passwords to login via SSH but not root
. Can't seem to have it both ways.
Tools to Maintain Config
Need to be about to update config. Possible tools include Cfengine (
http://www.cfengine.org), Node Configuration Management (
http://quattor.web.cern.ch/quattor/) (
+SPM Presumably this is for our non-ROCKS systems)
* Better syslog-ng setup (
+SPM What things are missing now?)
- Port scanning cluster (+SPM We have this capability now (Nessus) but haven't been using it)
-
- Packet logging / snort --- good for investigating network trouble or suspicious activity (+SPM SNORT and IDS tools have been on ATGRID for a while...not configured for our use however)
- Tripwire wasn't mentioned...good for identifying damage after the fact.
- Protecting 'root' is most critical. Limiting password 'ssh' to most system to be within our known systems seems very useful. On publicly exposed systems we should dis-allow 'root' password ssh logins.
- Encourage (require) all users to get SSH keys and use them.
- The 'iptables' setup must be tuned/reviewed. Do we need to implement out-bound filters as well? Primary issue here is introduction of problems with our services that must be supported.
--
TomRockwell - 26 Jun 2008