Unix vs. security
The book's analogy: Security as a mouse infestation
My analogy: car theft
Categories of security problems
Special file permissions
What to do if you're attacked
- Unix was not designed to be secure
- Some examples from history
- sendmail used to include a "debug" mode for easier debugging. Various commands could be run from debug mode, and since sendmail often runs as root, this enabled people to run commands as root that they weren't supposed to.
- The famous "Morris Internet worm" of 1988 exploited sendmail's debug mode
- The command passwd -f can be used to change your GECOS information, but in the past, it failed to check its input for "bad" characters like newlines and colons, so people could create password entries that just happened to be UID 0.
- Unix was designed by researchers to be an easy, friendly way to conduct and share research
- "Easy" and "friendly" are usually the opposite of "secure"
- Unix permissions are pretty much "all-or-nothing" -- root vs. everybody else
- More secure systems have multiple levels of administrative authority
- This makes them more secure (and less convenient)
- Many Unix administrative functions are in programs external to the kernel, able to be inspected by the world
- Remember that breaking into a computer is a crime. People have been and will be prosecuted and sent to jail for it, so don't get tempted to try it.
- One example recently regarding a break-in at WSU.
- The perpetrator was sentenced (for another break-in) to 15 months in jail, restitution charges, and may not I a computer for 3 years. He'll be a convicted felon for the rest of his life. All this for changing web pages to "prove his love" for a girl.
- If you discover a security problem, you should
- Alert your system administrators (if you aren't the administrator)
- Alert the vendor of your version of Unix
- Inform the Computer Emergency Response Team (CERT )
- Seven things you might do for a mouse infestation, and how they compare to computer security.
- Don't leave mouse temptations out on the counter. Put your food away, preferably in sealed containers.
- Don't put sensitive or tempting files on your computer. Trade secrets, personnel files, payroll data, etc. could all be very tempting.
- Plug the holes that mice are using to get into the house.
- Plug security holes on your Unix system. Apply vendor patches when they are available.
- Don't provide nesting sites for the mice.
- Don't provide places for hackers to "nest" on your system -- world-writable directories, accounts with weak passwords, etc.
- Set mouse traps.
- Set basic Unix traps, like tripwire, crack, and COPS.
- Check the traps daily, and re-bait them as necessary. Dispose of dead mice. A full trap doesn't catch many mice.
- Monitor the reports from your security tools, and do something about what they say.
- Don't use poison bait. It just gives you dead mice inside your walls.
- Don't waste money on a fancy "security consultant". Teach yourself about security. Good old-fashioned basic security will go a long way.
- Get a cat!
- "Prowl" your system looking for unusual things. The better you know your system, the better you'll notice when something is unusual.
- If someone really wants to steal your car, they can.
- We've all seen the demonstrations on TV where professional car theives strip a car clean in 30 seconds, or steal the car no matter how much security is installed.
- Locking your car, however, is still a good idea.
- If nothing else, it makes the joyriding kid in the parking lot steal the next car.
- If someone really wants to break into your Unix system on the internet, they can.
- Setting up basic security, however, is still a good idea.
- If nothing else, it makes the "script kiddies" use another system for their games.
- It will also help you catch and deal with break-ins that do occur.
- Security problems generally fall into three categories
- The least reliable part of any system
- Users can often easily be tricked into giving sensitive information (including passwords) to strangers
- Software bugs
- Holes are being found all the time.
- All you can really do is keep current with patches as they're released
- Open doors
- Unfortunately, more Unix systems have a default configuration that leaves them "wide open."
- A lot of information is available on how to configure systems securely, to avoid this last problems (as much as possible)
- Have no accounts without passwords.
- There may sometimes be accounts with no passwords, like CTue Aug 28 21:12:53 2001 and sync. Make sure they don't run a shell or shell script. They should only run a program that does one thing and then exits.
- You might want to disable them anyway.
- /etc/passwd and /etc/group should be 644, or 444
- The shadow passwd file (wherever it is) should be 600
- On a BSD system, /etc/master.passwd should be 600
- Avoid accounts with weak passwords.
- Put in a replacement for the passwd program that enforces good passwords.
- As a minimum, your replacement should prohibit using the login name, the login name backwards, and common words (including foreign words and words like "xyzzy" that are common only in computer culture).
- Spellings that substitute numbers for letters should be avoided, too, as that is easily cracked (things like "k3wl," "31337" ("eleet" -- i.e. "elite"), etc.)
- npasswd is a readily-available replacement.
- Solaris includes a set of rules in /etc/default/passwd for what the passwd command will allow.
- Other systems have similar capabilities
- Shadow your passwords.
- If at all possible, use shadow passwords.
- Normally, Unix puts the encrypted password in the /etc/passwd file, ready for the bad guys to attempt to crack them.
- "Way back when" the encryption was enough, because computers were slow enough.
- In 1995, a supercomputer could discover all six-character passwords in a few days, and all seven-character passwords in a few months.
- The current edition suggests that a special-purpose computer in the $1 million price range could decrypt any 56-bit DES key in just a few hours
- The crack program can find many passwords quickly on a Pentium-class machine.
- Read "many" as "a frightening number of"
- "shadow passwords" put the passwords in a separate file, readable only by root.
- The passwd file must be world-readable to allow mapping between UIDs and names for programs like ls
- Avoid shared accounts.
- You lose accountability.
- Even sharing the root login is not encouraged.
- Change passwords regularly
- In particular, the root password should be changed on a regular basis.
- And should definitely be changedwhen someone who knows the root password leaves.
- Whether on friendly terms or on unfriendly terms
- For your sake and theirs!
- Most systems have some sort of "password aging" feature, which you can use to require users to change their passwords regularly
- The downside is that this often annoys users, and may force them to use a less secure password
- A shell script should never be used as the "shell" (last field of the passwd file) for any passwdless login.
- Beware of extra entries in your passwd file that are UID 0, or any other suspicious entries.
- A common way to break into a Unix system is to exploit a problem in a setuid program.
- Keep an eye on vendor security bulletins and the BUGTRAQ mailing list.
- Monitor your systems for new setuid programs, and for changes to setuid programs
- Don't write setuid shell scripts
- You don't have enough control inside a shell script
- If something needs to be setuid, try to make it setuid to a pseudo user specific to that purpose, rather than setuid to root.
- Some files and directories must have particular permissions to work properly. But you should never give more permissions than are necessary.
- /dev/kmem (which maps kernel memory) should not be world-readable
- /etc/passwd and /etc/group should not be world-writable (for obvious reasons)
- Make them mode 644, owner root
- Do not have world-writable anonymous ftp directories
- They will become warez and/or pornography sites before you know it.
- By the way, make sure the passwd file in the ftp directory contains no passwords!
- Give no "world" permissions to disk device files
- Permissions on the disk device are essentially permissions on every file on the disk
- It's a really, really good idea to use remote logging
- Some systems can be configured to have root only allowed to log in on certain "secure" terminals.
- Be very careful with /etc/hosts.equiv and .rhosts files
- Anything that contains a '+' should be removed
- It's best just to disable rsh, rlogin, rexec, rcp
- A really insecure way to run commands on another system
- Don't use it
- Needed by some applications, but don't use it if you don't need it
- Finger can give info on your accounts to remote people. Bad idea. Turn it off.
- The word "security" should never be used in the same sentence as the subject system for distributing password information.
- NIS+ isn't a whole lot better.
- Be careful about world-exports via NFS
- See the NFS chapter for more details
- Have them!
- They can help you recover from an incident, or compare to find out what has or hasn't changed
- The other side:
- Backups may contain sensitive information (like, your shadow files).
- Keep them secure.
- trojan horses
- Always be careful of what you run on a system
- Espeically what you run as root
- Watch mailing lists, Usenet, web sites, etc. If a trojan surfaces, word gets out pretty quickly.
- Note, for a comprehensive site on computer security, including an archive of these and many other tools, check out COAST , the Computer Operations, Audit, and Security Technology project at Purdue University. Another good site is SecurityFocus.
- Scans hosts for open ports
- Can help you find out what a system is running
- Turn off what you don't need
- A general security scanner than will uncover many common problems
- Tries to guess passwords by using dictionary words, and various transformations of dictionary words, encrypting them, and comparing with the encrypted password
- If you find crackable accounts, disable them until the password can be changed
- tcp_wrapper (tcpd)
- "Intervenes" between inetd and various internet services (telnetd, rlogind, etc.)
- Allows you to selectively block hosts and provides logging of all connections via syslog
- A portion of this functionality is built in to HP/UX's inetd
- COPS -- Computer Oracle and Password System
- COPS does many scans for common security problems on Unix systems.
- Warns you of problems. You have to fix them.
- Notifies you of changes to important system files
- The book has a lot to say about various cryptographic tools
- ssh is the one I want to highlight
- It keeps network connections from taking place "in the clear"
- A firewall can be very useful by keeping much of your internal network from being visible from outside
- Best approach is "block everything" then turn on what you find out is broken
- If you have a firewall, that doesn't remove the need for everything else discussed here. It just helps reduce the pressure on your hosts
- Distribute announcements about security issues
- Have advice on dealing with incidents
- Extensive resources on news, tools, articles
- Also runs the BUGTRAQ mailing list
- The System Administration, Networking, and Security Institute
- Lots of advice and resources
- Don't panic
- The damage has probably been done, and the intrusion has probably been happening for some time
- Decide on your response
- Try to keep management (or others) from overreacting
- Hoard all available information
- You'll want to pick through all sorts of things, so save it all
- Assess your exposure
- Figure out what's been compromised, and what you're going to do about it
- Pull the plug
- Disconnect the affected machine from the network (or close off all outside access) to stop the attack
- Devise a recovery plan
- Again, thinking things through is important
- Don't blame -- it won't change the situation
- Communicate the recovery plan
- Let people know what's going on and what you're going to do about it
- Implement the recovery plan
- Report the incident
- CERT has a reporting form (which is great to fill out, because it asks you questions you might not have thought about)
- CERT tracks incidents and may be able to advise you, or use your experience to help others avoid or deal with a similar attack
Part of the CptS 302 Website
Source Modified: Tue Apr 24 21:05:26 2001
HTML Generated by WML 2.0.6 (25-Oct-2000): Tue Aug 28 21:12:52 2001