Sysadmin:Security
From UGCS
(Difference between revisions)
(→Policies) |
|||
| (23 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | =Known Problems= | + | __TOC__ |
| + | |||
| + | [[Sysadmin:Security_Todo|Security To-Do list]] | ||
| + | ==Known Problems== | ||
*Users could DoS our kerberos admin server by using the newacct-creator keytab to create lots of new principals. Minor severity | *Users could DoS our kerberos admin server by using the newacct-creator keytab to create lots of new principals. Minor severity | ||
| + | * Symlink attack possible to gain access to Apache Kerberos service keytab for Poseidon | ||
| + | * If too much spam comes in, it can overload slapd on zeus causing mail to softbounce and the load on zeus to go way up. The solution is to set the ldap database to readonly temporarily. | ||
| − | =Probable Problems= | + | ==Probable Problems== |
| − | * All the python we wrote needs to be double-checked | + | * All the python we wrote needs to be double-checked- particularly the new account creator because the password is easily crackable |
| − | * | + | * Machines need to be [[Software Update|kept up to date]] at minimum once a week (every 3 days is preferable if time available) |
| − | + | * We need to check for reconnaissance- see if we can spot people trying to recon our systems before they break in | |
| − | * | + | * Physical security issues, esp with server closet |
| − | * | + | |
| − | =Possible problems= | + | ==Possible problems== |
* Cfengine can be used to break into machines | * Cfengine can be used to break into machines | ||
| + | * Also need to check the perl wrapper script for the webserver | ||
| − | = | + | ==Reconnaissance== |
| + | * We have a lot of information about us available online. Specifically, rwho/ruptime could provide quite a bit of information in making an attack. Do we want to restrict access to this information? | ||
| − | == | + | ==Possible attack vectors== |
| − | * | + | * Directly hack zeus or hera |
| − | * | + | ** How to detect: ?? |
| + | *** Possible Detection Method: Network sniffing and traffic analysis? There's going to be packets that are presumably "obvious" that they're malformed. Any implementation we could setup, though, would run counter to the relative openness of the cluster... [[User:Ckennelly@ugcs.caltech.edu|Ckennelly@ugcs.caltech.edu]] 22:43, 29 November 2007 (PST) | ||
| + | *** So we have Snort running, unfortunately almost all of the traffic to and from hera/zeus is encrypted (ldap-ssl, ssh, and kerberos). Snort can look for some buffer-overflow packets, but doesn't do much good against stuff that's encrypted. [[User:Jdhutchin@ugcs.caltech.edu|Jdhutchin@ugcs.caltech.edu]] 11:24, 30 November 2007 (PST) | ||
| + | *** We do run sniffing and traffic analysis - charon runs snort; its logs go to /var/log/snort/alert or can be summarized by running grind_snort. --[[User:Elizabeth@ugcs.caltech.edu|Elizabeth@ugcs.caltech.edu]] 06:42, 30 November 2007 (PST) | ||
| + | ** Solution: [[Sysadmin:Disaster|Disaster]] | ||
| + | * Hack a login machine and steal sysadmin's credentials | ||
| + | ** Part of this damage is mitigated by requiring passwords for sudo on core servers; however, it doesn't fix afs system:administrator problems | ||
| + | ** How to detect: check logs for root accesses on login machines- there shouldn't be many because we don't use sudo on them that much | ||
| + | ** Solution: reboot the machine and change the sysadmin's password (this will invalidate any old credentials) | ||
| + | *** Also check logs to see what they were able to do on other machines | ||
| + | * AFS server gets hacked | ||
| + | ** Hack the AFS server and get system:administrator access to AFS | ||
| + | ** How to detect: Process accounting on AFS servers | ||
| + | ** Solution: [[Sysadmin:Disaster|Disaster]] | ||
| + | * NFS image server gets hacked | ||
| + | ** Someone hacks the NFS image server and adds a rootkit to our login root image | ||
| + | ** How to detect: Tripwire | ||
| + | ** Solution: rebuild the image or restore from known good backup | ||
| + | * Sysadmin account getting pwned | ||
| + | ** How to detect: Better access log monitoring | ||
| + | ** Solution: Use accounting stuff and see what was changed, particularly rootkit checks | ||
| + | * Users can produce symlink attacks to cause overwriting of critical system files since many applications predictably name files (e.g. /tmp/krb5cc_PID); we need to apply libpam-tmpdir whenever convenient | ||
| + | |||
| + | ==Fixed problems== | ||
| + | * Credit to sle from OCF: possible race condition in cgi-wrapper and php-wrapper - need to perform chdir after dropping privileges | ||
| + | * Kerberos security holes that need to be patched urgently | ||
| + | ** krb5-admin-server: up to date on zeus and that's all we need to worry about in terms of major major exploits at the moment --[[User:Elizabeth@ugcs.caltech.edu|Elizabeth@ugcs.caltech.edu]] 05:56, 26 September 2007 (PDT) | ||
| + | * linux-2.6: CVE-2007-4571 and CVE-2007-4573 - local privilege escalation vulnerabilities, extremely serious on amd64. working on backporting a fix and getting it compiled by hephaestus. --[[User:Elizabeth@ugcs.caltech.edu|Elizabeth@ugcs.caltech.edu]] 05:56, 26 September 2007 (PDT) | ||
| + | ** Fixed by installing the debian linux-2.6.18-5-dpkg package (forget when)- Joshua | ||
| + | * CVE-2007-4995 openssl vulnerability - need to upgrade all core servers | ||
| + | ** Note: debian's automated install does NOT auto-restart impacted services, so an lsof is needed to check for 'path inode' values indicating use of replaced library | ||
Latest revision as of 17:12, 10 December 2007
Contents |
Known Problems
- Users could DoS our kerberos admin server by using the newacct-creator keytab to create lots of new principals. Minor severity
- Symlink attack possible to gain access to Apache Kerberos service keytab for Poseidon
- If too much spam comes in, it can overload slapd on zeus causing mail to softbounce and the load on zeus to go way up. The solution is to set the ldap database to readonly temporarily.
Probable Problems
- All the python we wrote needs to be double-checked- particularly the new account creator because the password is easily crackable
- Machines need to be kept up to date at minimum once a week (every 3 days is preferable if time available)
- We need to check for reconnaissance- see if we can spot people trying to recon our systems before they break in
- Physical security issues, esp with server closet
Possible problems
- Cfengine can be used to break into machines
- Also need to check the perl wrapper script for the webserver
Reconnaissance
- We have a lot of information about us available online. Specifically, rwho/ruptime could provide quite a bit of information in making an attack. Do we want to restrict access to this information?
Possible attack vectors
- Directly hack zeus or hera
- How to detect: ??
- Possible Detection Method: Network sniffing and traffic analysis? There's going to be packets that are presumably "obvious" that they're malformed. Any implementation we could setup, though, would run counter to the relative openness of the cluster... Ckennelly@ugcs.caltech.edu 22:43, 29 November 2007 (PST)
- So we have Snort running, unfortunately almost all of the traffic to and from hera/zeus is encrypted (ldap-ssl, ssh, and kerberos). Snort can look for some buffer-overflow packets, but doesn't do much good against stuff that's encrypted. Jdhutchin@ugcs.caltech.edu 11:24, 30 November 2007 (PST)
- We do run sniffing and traffic analysis - charon runs snort; its logs go to /var/log/snort/alert or can be summarized by running grind_snort. --Elizabeth@ugcs.caltech.edu 06:42, 30 November 2007 (PST)
- Solution: Disaster
- How to detect: ??
- Hack a login machine and steal sysadmin's credentials
- Part of this damage is mitigated by requiring passwords for sudo on core servers; however, it doesn't fix afs system:administrator problems
- How to detect: check logs for root accesses on login machines- there shouldn't be many because we don't use sudo on them that much
- Solution: reboot the machine and change the sysadmin's password (this will invalidate any old credentials)
- Also check logs to see what they were able to do on other machines
- AFS server gets hacked
- Hack the AFS server and get system:administrator access to AFS
- How to detect: Process accounting on AFS servers
- Solution: Disaster
- NFS image server gets hacked
- Someone hacks the NFS image server and adds a rootkit to our login root image
- How to detect: Tripwire
- Solution: rebuild the image or restore from known good backup
- Sysadmin account getting pwned
- How to detect: Better access log monitoring
- Solution: Use accounting stuff and see what was changed, particularly rootkit checks
- Users can produce symlink attacks to cause overwriting of critical system files since many applications predictably name files (e.g. /tmp/krb5cc_PID); we need to apply libpam-tmpdir whenever convenient
Fixed problems
- Credit to sle from OCF: possible race condition in cgi-wrapper and php-wrapper - need to perform chdir after dropping privileges
- Kerberos security holes that need to be patched urgently
- krb5-admin-server: up to date on zeus and that's all we need to worry about in terms of major major exploits at the moment --Elizabeth@ugcs.caltech.edu 05:56, 26 September 2007 (PDT)
- linux-2.6: CVE-2007-4571 and CVE-2007-4573 - local privilege escalation vulnerabilities, extremely serious on amd64. working on backporting a fix and getting it compiled by hephaestus. --Elizabeth@ugcs.caltech.edu 05:56, 26 September 2007 (PDT)
- Fixed by installing the debian linux-2.6.18-5-dpkg package (forget when)- Joshua
- CVE-2007-4995 openssl vulnerability - need to upgrade all core servers
- Note: debian's automated install does NOT auto-restart impacted services, so an lsof is needed to check for 'path inode' values indicating use of replaced library
