Securing servers
| (34 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| − | Eventually we'll need sections or subarticles on various different security contexts: | + | Eventually we'll need sections or subarticles on various different security contexts. In the meantime, this is a start. See [http://www.freebsd.org/cgi/man.cgi?query=security&apropos=0&sektion=0&manpath=FreeBSD+5.4-stable&format=html the security man page] for ways to keep your system secure. |
| − | == | + | ==First Impressions Are Everything== |
| − | + | Login banners are useful sometimes, but since you'll likely already know what system you're logging into and what you're going to be using it for, will probably be unnecessary, and any extraneous information that they give when you login will usually be worthless to you but potentially useful to an attacker. If you want to change it (or remove it,) you'll need to: | |
| + | 1. edit /etc/motd (make it blank or put in a warning like you're<br> being logged or authorized access ONLY or something) | ||
| + | 2. [[touch]] /etc/COPYRIGHT and | ||
| + | 3. add ''update_motd="NO"'' to /etc/rc.conf. | ||
| + | 4. reboot to verify that the changes are made and effective. | ||
| − | ==Security in | + | ==Security in a local user context== |
| − | + | If your system has multiple users that have access to the box, you might want to restrict who can log on locally as well as over the network. | |
| − | + | First, let's block anyone from logging into the machine as root -- this is default when logging in via [[ssh]] but let's make local users (at the console) log in with a regular account and then [[su]] to [[root]] if they want [[root]] access. Edit /etc/ttys and replace all the values marked "secure" with "insecure" in the tty sections. You can do this with [[sed]] if you like, but be ''very careful'' with this file, as a typo means you'll break logins. Consider making a backup of it, using something like this: | |
| − | + | samizdata# sed s/secure/insecure/ /etc/ttys > /etc/ttys_new | |
| − | + | samizdata# mv /etc/ttys /etc/ttys.bak && mv /etc/ttys_new /etc/ttys | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | samizdata# | + | |
| − | + | You can also disallow logins from non-local consoles, or logins that are not from a specific domain or IP by editing the very well commented /etc/login.access file. | |
| − | + | There is another way to disallow logins. Let's say you have a user that left, and you don't want to keep their account open because it's a potential hole (or just because you don't trust them), but you don't want to delete the account or its files just yet. Go to [[ /etc/master.passwd]] and change their password -- the second field, right after their '''username:''' field -- and delete it, replacing it with "*". Since no password hash will ever match "*", they'll never be able to login by authenticating against the password. However, you also have to be careful to either delete or move their [[ssh]] keys, since if you have [[sshd]] running, a user may still be able to authenticate against the '''keys''' without ever having to type in a password. Since we're going to be blocking the user, we might as well run [[chsh]] and change their shell from a valid login shell to something that you can't login with, like /sbin/nologin or another [[invalid shell]]. Note that this will break some programs -- some ftp daemons will not let you connect if you don't have a valid login shell, for example. (Also note that for this reason, if you need a lot of ftp-only users, it's best to pick an FTP daemon that can be configured to avoid this behavior.) | |
| − | + | ||
| − | + | For more about controlling logins (locally or over the network), check /etc/login.access and see the excellent article by Michael W. Lucas at http://www.onlamp.com/pub/a/bsd/2001/06/28/Big_Scary_Daemons.html | |
| − | |||
| − | |||
| − | + | '''things needed here:'''(cover common gotchas and SNAFUs concerning local security; ie preventing valid shell users from obtaining privileges they aren't supposed to have or doing damage they shouldn't be able to do. [[sudo]] is clearly a must with this one, as is some discussion of running daemons under special user accounts, and the dangers of overusing "nobody" to run daemons. a quick rundown of system files that permissions should be double-checked on, like /etc/passwd, /etc/master.passwd, /etc/group, and the databases associated with them should also be covered.) | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | == | + | ==Security in an internet context== |
| − | + | '''what's listening?''' | |
| + | We'll want to know what ports are open and listening. If you didn't follow the installation instructions and installed IPv6 support when you installed the system (like me), you'll want to check for IPv6 sockets as well as IPv4; become [[root]] and run [[sockstat]] with -46 as an argument; this will let you know the socket status for both IPv4 and IPv6 sockets (in this context, a socket = port + protocol). For more details, see the [[sockstat]] entry's section on security. Any services that don't ''need'' to be running should be disabled or uninstalled completely, if possible. | ||
| + | |||
| + | '''who's connecting?''' | ||
| + | Consider allowing only specific machines to connect to your system at all, or trusted networks only. Make changes in your hosts.allow and hosts.deny files as appropriate. Consider securing what users can log in at all by altering which shells they can use -- see [[chsh]] for how to do this. | ||
==Authentication, Encryption and You== | ==Authentication, Encryption and You== | ||
FreeBSD encrypts passwords. Unfortunately, it doesn't do it the strongest way possible by default. The reason being that stronger encryption takes more effort to perform and can sometimes be slow. But if you're serious about making your machine harder to crack, you'll want to switch your password encryption from md5 to the blowfish algorithm. Blowfish has the benefit of being both fast and strong (military-grade strong.) This is a 4-step process. | FreeBSD encrypts passwords. Unfortunately, it doesn't do it the strongest way possible by default. The reason being that stronger encryption takes more effort to perform and can sometimes be slow. But if you're serious about making your machine harder to crack, you'll want to switch your password encryption from md5 to the blowfish algorithm. Blowfish has the benefit of being both fast and strong (military-grade strong.) This is a 4-step process. | ||
| − | + | ||
| + | 1. edit /etc/login.conf and change the passwd_format entry to | ||
:passwd_format=blf:\ | :passwd_format=blf:\ | ||
| − | + | 2. rebuild the login.conf database with | |
samizdata# '''cap_mkdb /etc/login.conf''' | samizdata# '''cap_mkdb /etc/login.conf''' | ||
| − | + | 3. change all your user's passwords (or get them to change 'em by [[expiring_passwords|expiring their passwords]]) by running passwd for everyone (''INCLUDING ROOT''): | |
samizdata# passwd | samizdata# passwd | ||
| − | + | 4. you'll want to change the configuration file that the [[adduser]] program calls to use blowfish automagically. Do this by changing the ''crypt_default=md5'' line in [[/etc/auth.conf]] to ''crypt_default=blf'' so that any new accounts you make on the system use it from the get-go. | |
| − | + | ||
==Security in a local area network context== | ==Security in a local area network context== | ||
| Line 77: | Line 51: | ||
==Security through better logging== | ==Security through better logging== | ||
| − | + | Setting up your system to log actions, changes and logins is a good idea. Of course, it usually only occurs to an administrator after problems have started. Don't be that admin, go learn about [[Setting up logging]] and [[NTP]] (because if you can't trust the timestamps your logs have, they're useless -- both from a security and forensic perspective and from a legal perspective) before problems start. Consider setting up [[tripwire]] (or another [[IDS]] such as [[ACID]] or [[SNORT]] so you can also keep track of file changes. | |
| − | + | ||
| − | + | ==Making life difficult for intruders== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | One school of thought says that once production systems that are exposed to the internet should not have any compilers or tools that are potentially abusable by intruders -- either remove them from the server after they've served their function (compiling programs etc), or never have them on the server itself, instead building your packages on another staging server and then copying the binaries over to the new server. The other school of thought on the matter says not to bother -- once an intruder is on your system, it's trivial for them to install the things they want/need themselves. One way to avoid this is to create firewall rules to explicitly deny connections FROM your machine (as well as TO) that are not strictly necessary. It's hard to download a rootkit from a server you can't contact. Be careful when doing this that you do not break your server's function, of course. | |
| − | |||
[[Category:Common Tasks]] | [[Category:Common Tasks]] | ||
[[Category:Configuring FreeBSD]] | [[Category:Configuring FreeBSD]] | ||
| + | [[Category:Securing FreeBSD]] | ||
Latest revision as of 11:38, 13 August 2012
Eventually we'll need sections or subarticles on various different security contexts. In the meantime, this is a start. See the security man page for ways to keep your system secure.
Contents |
[edit] First Impressions Are Everything
Login banners are useful sometimes, but since you'll likely already know what system you're logging into and what you're going to be using it for, will probably be unnecessary, and any extraneous information that they give when you login will usually be worthless to you but potentially useful to an attacker. If you want to change it (or remove it,) you'll need to:
1. edit /etc/motd (make it blank or put in a warning like you're
being logged or authorized access ONLY or something) 2. touch /etc/COPYRIGHT and 3. add update_motd="NO" to /etc/rc.conf. 4. reboot to verify that the changes are made and effective.
[edit] Security in a local user context
If your system has multiple users that have access to the box, you might want to restrict who can log on locally as well as over the network.
First, let's block anyone from logging into the machine as root -- this is default when logging in via ssh but let's make local users (at the console) log in with a regular account and then su to root if they want root access. Edit /etc/ttys and replace all the values marked "secure" with "insecure" in the tty sections. You can do this with sed if you like, but be very careful with this file, as a typo means you'll break logins. Consider making a backup of it, using something like this:
samizdata# sed s/secure/insecure/ /etc/ttys > /etc/ttys_new samizdata# mv /etc/ttys /etc/ttys.bak && mv /etc/ttys_new /etc/ttys
You can also disallow logins from non-local consoles, or logins that are not from a specific domain or IP by editing the very well commented /etc/login.access file.
There is another way to disallow logins. Let's say you have a user that left, and you don't want to keep their account open because it's a potential hole (or just because you don't trust them), but you don't want to delete the account or its files just yet. Go to /etc/master.passwd and change their password -- the second field, right after their username: field -- and delete it, replacing it with "*". Since no password hash will ever match "*", they'll never be able to login by authenticating against the password. However, you also have to be careful to either delete or move their ssh keys, since if you have sshd running, a user may still be able to authenticate against the keys without ever having to type in a password. Since we're going to be blocking the user, we might as well run chsh and change their shell from a valid login shell to something that you can't login with, like /sbin/nologin or another invalid shell. Note that this will break some programs -- some ftp daemons will not let you connect if you don't have a valid login shell, for example. (Also note that for this reason, if you need a lot of ftp-only users, it's best to pick an FTP daemon that can be configured to avoid this behavior.)
For more about controlling logins (locally or over the network), check /etc/login.access and see the excellent article by Michael W. Lucas at http://www.onlamp.com/pub/a/bsd/2001/06/28/Big_Scary_Daemons.html
things needed here:(cover common gotchas and SNAFUs concerning local security; ie preventing valid shell users from obtaining privileges they aren't supposed to have or doing damage they shouldn't be able to do. sudo is clearly a must with this one, as is some discussion of running daemons under special user accounts, and the dangers of overusing "nobody" to run daemons. a quick rundown of system files that permissions should be double-checked on, like /etc/passwd, /etc/master.passwd, /etc/group, and the databases associated with them should also be covered.)
[edit] Security in an internet context
what's listening? We'll want to know what ports are open and listening. If you didn't follow the installation instructions and installed IPv6 support when you installed the system (like me), you'll want to check for IPv6 sockets as well as IPv4; become root and run sockstat with -46 as an argument; this will let you know the socket status for both IPv4 and IPv6 sockets (in this context, a socket = port + protocol). For more details, see the sockstat entry's section on security. Any services that don't need to be running should be disabled or uninstalled completely, if possible.
who's connecting? Consider allowing only specific machines to connect to your system at all, or trusted networks only. Make changes in your hosts.allow and hosts.deny files as appropriate. Consider securing what users can log in at all by altering which shells they can use -- see chsh for how to do this.
[edit] Authentication, Encryption and You
FreeBSD encrypts passwords. Unfortunately, it doesn't do it the strongest way possible by default. The reason being that stronger encryption takes more effort to perform and can sometimes be slow. But if you're serious about making your machine harder to crack, you'll want to switch your password encryption from md5 to the blowfish algorithm. Blowfish has the benefit of being both fast and strong (military-grade strong.) This is a 4-step process.
1. edit /etc/login.conf and change the passwd_format entry to
:passwd_format=blf:\
2. rebuild the login.conf database with
samizdata# cap_mkdb /etc/login.conf
3. change all your user's passwords (or get them to change 'em by expiring their passwords) by running passwd for everyone (INCLUDING ROOT):
samizdata# passwd
4. you'll want to change the configuration file that the adduser program calls to use blowfish automagically. Do this by changing the crypt_default=md5 line in /etc/auth.conf to crypt_default=blf so that any new accounts you make on the system use it from the get-go.
[edit] Security in a local area network context
(probably the shortest of the categories - specific things to watch for in an un-firewalled and extremely-high-bandwidth mostly-trusted environment.)
[edit] Security through better logging
Setting up your system to log actions, changes and logins is a good idea. Of course, it usually only occurs to an administrator after problems have started. Don't be that admin, go learn about Setting up logging and NTP (because if you can't trust the timestamps your logs have, they're useless -- both from a security and forensic perspective and from a legal perspective) before problems start. Consider setting up tripwire (or another IDS such as ACID or SNORT so you can also keep track of file changes.
[edit] Making life difficult for intruders
One school of thought says that once production systems that are exposed to the internet should not have any compilers or tools that are potentially abusable by intruders -- either remove them from the server after they've served their function (compiling programs etc), or never have them on the server itself, instead building your packages on another staging server and then copying the binaries over to the new server. The other school of thought on the matter says not to bother -- once an intruder is on your system, it's trivial for them to install the things they want/need themselves. One way to avoid this is to create firewall rules to explicitly deny connections FROM your machine (as well as TO) that are not strictly necessary. It's hard to download a rootkit from a server you can't contact. Be careful when doing this that you do not break your server's function, of course.
