|
(Old content; kept as still useful)
There are several ways in which you to harden a system. This is presented in Unix terms, but the underlying principles apply to all operating systems.
Against network attacks
- Disable all unused services.
- Restrict administrative services to trusted addresses, and use encrypted protocols like ssh.
- Turn off many ICMP features - redirects, timestamp requests, netmask requests, etc. Consider whether you need pings.
- Configure services not to advertise their type and version in their banner, headers or in response to queries like help, syst or version.bind.
- Install a firewall, although for a well-configured device this doesn't give as much protection as generally hyped.
- Have a message like "authorised users only" in your banners - this will make it easier to prosecute a hacker.
- Don't use rhosts authentication.
Against Denial-of-Service attacks
- Limit number of connections per IP address per second, also ICMP replies, etc.
- Limit number of processes per user, memory and CPU time per process, etc.
- Turn on disk quotas.
- Take care not to provide remote disk-filling services - log files, root mailboxes, etc.
Against malicious local users
This may be an attacker who has already hacked a non-root service.
- Where possible, turn the setuid/gid bit off binaries e.g. ping, making them usable only by root.
- Restrict access to /proc and other sensitive locations to root.
- Turn off users' access to cron, sendmail, etc.
- Disable ptrace
- The best protection is to keep all users inside a chroot that contains no device nodes or setuid binaries.
- FreeBSD can go one step further and do a chroot jail which restricts network access, as well as file system access.
Against legitimate users' clumsiness
- Use a password checker to stop people using weak passwords.
- Don't let administrators use the same password for admin services as they do for unencrypted things like POP3.
- Make users home directories root owned, with permissions 770, so the user can still write to their home directory, but they cannot accidentally change the permissions to let others in.
- Gives users a strict default umask, e.g. 077.
Against software bugs
- Use library functions to escape HTML, SQL, etc.
- Avoid PHP register_globals.
- One tmp directory per user, instead of a system-wide one.
- Some steps can be taken to reduce the exploitability of buffer overruns. OpenBSD takes the best approach - making the heap and stack non-executable, and using a token to check stack integrity.
Against a hacker who has broken one service
- Don't run services as root.
- Consider running services inside a chroot.
- The best solution is to run each service on a separate computer.
- A close emulation of this on a single computer is to run each service in a separate user-mode Linux.
Against an attacker who has gained root
- secure level / capabilities
- Use chflags to make logs append-only, or use a central log server.
- mount file systems read-only where possible
Against physically-local attacks
- Password protected single-user maintenance mode, and the boot loader (to stop anyone entering kernel parameters).
- Set BIOS to only boot off the hard drive, and password protect the BIOS.
- Padlock the case. Most cases are able to do this, though you may have to fit the attachment.
- Disable serial consoles and ctrl-alt-delete.
- Don't leave the console logged in!
- The best protection against physically-local attacks is to use an encrypted file system, where the key is entered at boot-time and only stored in memory. As soon as the box is powered down or reset, the information is safe.
Detecting an attack
- Crank up logging
- tripwire
- port scan detector
|