Re: hardening openbsd firewall
On Tuesday 07 March 2006 23:42, Peter wrote: Hi. I've set up several firewalls with OpenBSD but I have yet to go to any extremes regarding hardening. So far I have updated the source (stable), recompiled the system kernel, removed the source code, turned off inetd, and set up a tight pf.conf. I have been reading up on an interesting strategy of removing tons of executables, storing them on a cd, and setting up symlinks to the cd mount point so they can be accessed when needed. Of coarse now when you have a problem and need your diagnostic tools. Or for that matter if need to apply a security patch you are going to have lots of fun updating the system. Restrict connections to the localhost to only absolutly necessary services, restrict sshd access (and use ssh-keygen to create keypairs), and of coarse only give access to the console to trusted persons. Doing this, as well as keeping up to date on the security patches, will keep your system's risk to a minimum. Don't forget that if someone is good enough to gain access to your system, odds are they are smart enough to copy the code and complier that they need to completely root the system. Tim Donahue
Re: hardening openbsd firewall
On Tue, Mar 07, 2006 at 11:42:23PM -0500, Peter wrote: Hi. I've set up several firewalls with OpenBSD but I have yet to go to any extremes regarding hardening. So far I have updated the source (stable), recompiled the system kernel, removed the source code, turned off inetd, and set up a tight pf.conf. I have been reading up on an interesting strategy of removing tons of executables, storing them on a cd, and setting up symlinks to the cd mount point so they can be accessed when needed. My firewall will be providing internet access (NAT) to a small office lan (not mine). What strategies are others using in this area? As mentioned, restrict sshd(8). Ideally, turn it off, but that's not usually necessary/possible. Depending on how far you're willing to deviate from base, some other tricks: 1. Use sudo exclusively - set an empty or nonsense root password 2. Use public key authentication only for sshd(8), and restrict which users can log in. 2a. If you really need something password-like, use S/KEY. 2b. If neither is feasible, audit the passwords (use John the Ripper for existing passwords; some schemes exist to act when setting new passwords) 3. Restrict the use of ports, and research into the security of a program before installing. mail/postfix is unlikely to open too many holes; www/php5 is best left alone, if security is the goal [1]. 4. Audit suid/sgid executables - quite a few are not needed on a minimalist system, but again - breaking stuff will lead to other stuff breaking. (Where 'audit' will typically mean 'remove any that are not needed' - the other end, a full source audit, is very, very time-consuming and difficult.) 5. Monitor the appropriate lists (did you know about the pf DoS problems in 3.8-rel? They are not in the patches, and very unlikely to cause trouble, but it's good to know what not to do). Actually, regarding 1 - I find myself wondering whether logging in as root, where no suspicious stuff in my own account can reach me, is not preferable to using sudo (which is trivially subverted with a single line in .profile). Does anyone have a good opinion on this? (Yes, I know that root is not to be used for trivial matters, and yes, I know when to log out.) Of course, sudo does have the invaluable side effect of producing quite informative log files. Removing (non-s*id) binaries and sources, while annoying to an attacker, is also quite annoying to the system administrator and will not stop a knowledgeable attacker anyway. Joachim [1] Of course, PHP is quite often impossible to avoid - it *is* the biggest in what it does, after all.
Re: hardening openbsd firewall
* Joachim Schipper [EMAIL PROTECTED] [2006-03-08 12:13]: 1. Use sudo exclusively - set an empty or nonsense root password Stupid - if there is only one user with sudo-ability then this is the same as just having root. if there are more, there are now two passwords out there to get root instead of just one. Don't get me wrong, I love using sudo, and use it in lots of places but view it as a tool for selectively openeing up security, not tightening it down. 2. Use public key authentication only for sshd(8), and restrict which users can log in. So they can expose their key on a bazillion remote systems instead of the password on this system ? :) This is a tradeoff, universal statements like this are frequently shit. allowing public keys means you're now accepting the security of every machine an idiot ssh's from as good enough. My most secure machines do not permit public keys. They also use pf.os to encourage people not to ssh to them from less secure choices of operating system. 2a. If you really need something password-like, use S/KEY. 2b. If neither is feasible, audit the passwords (use John the Ripper for existing passwords; some schemes exist to act when setting new passwords) Don't audit using John, users just cycle between shitty ones. check them. (see passwordcheck in login.conf(5)) 3. Restrict the use of ports, and research into the security of a program before installing. mail/postfix is unlikely to open too many holes; www/php5 is best left alone, if security is the goal [1]. 4. Audit suid/sgid executables - quite a few are not needed on a minimalist system, but again - breaking stuff will lead to other stuff breaking. (Where 'audit' will typically mean 'remove any that are not needed' - the other end, a full source audit, is very, very time-consuming and difficult.) 5. Monitor the appropriate lists (did you know about the pf DoS problems in 3.8-rel? They are not in the patches, and very unlikely to cause trouble, but it's good to know what not to do). Actually, regarding 1 - I find myself wondering whether logging in as root, where no suspicious stuff in my own account can reach me, is not preferable to using sudo (which is trivially subverted with a single line in .profile). Does anyone have a good opinion on this? (Yes, I know that root is not to be used for trivial matters, and yes, I know when to log out.) My most secure machines do not use sudo - there is only root. (on most of my machines however, I do use sudo). I use sudo to make a machine a measured amount less secure (by allowing more people high level access) than more secure. -Bob
Re: hardening openbsd firewall
On Wed, Mar 08, 2006 at 01:58:18PM -0700, Bob Beck wrote: * Joachim Schipper [EMAIL PROTECTED] [2006-03-08 12:13]: 1. Use sudo exclusively - set an empty or nonsense root password Stupid ... 2. Use public key authentication only for sshd(8), and restrict which users can log in. So they can expose their key on a bazillion remote systems instead of the password on this system ? :) This is a tradeoff, universal statements like this are frequently shit. allowing public keys means you're now accepting the security of every machine an idiot ssh's from as good enough. My most secure machines do not permit public keys. They also use pf.os to encourage people not to ssh to them from less secure choices of operating system. So what do you use? Personally, I have one main workstation which has the private key to get into everything; one secondary workstation which can get into the primary; and no access between the rest. For logins from untrusted machines, S/KEY will have to do. It's much better than password authentication, as keyloggers are all too common. And yes, I am aware of the failings of S/KEY, especially when in an untrusted environment - it will not stop someone who has taken care to crack it. It will, however, defeat general-purpose loggers and passive network taps. Yes, disallowing access from Windows or even Linux makes some sense, but it is not always feasible. Besides, stupid users are, to some extent, neither a technical problem nor solvable by technical means. And since we were originally talking about a firewall, it seems reasonable that the users can be trusted to be somewhat responsible. 2a. If you really need something password-like, use S/KEY. 2b. If neither is feasible, audit the passwords (use John the Ripper for existing passwords; some schemes exist to act when setting new passwords) Don't audit using John, users just cycle between shitty ones. check them. (see passwordcheck in login.conf(5)) A very good idea, but one that falls under the latter category - i.e., it doesn't help for existing accounts. 3. Restrict the use of ports, and research into the security of a program before installing. mail/postfix is unlikely to open too many holes; www/php5 is best left alone, if security is the goal [1]. 4. Audit suid/sgid executables - quite a few are not needed on a minimalist system, but again - breaking stuff will lead to other stuff breaking. (Where 'audit' will typically mean 'remove any that are not needed' - the other end, a full source audit, is very, very time-consuming and difficult.) 5. Monitor the appropriate lists (did you know about the pf DoS problems in 3.8-rel? They are not in the patches, and very unlikely to cause trouble, but it's good to know what not to do). Actually, regarding 1 - I find myself wondering whether logging in as root, where no suspicious stuff in my own account can reach me, is not preferable to using sudo (which is trivially subverted with a single line in .profile). Does anyone have a good opinion on this? (Yes, I know that root is not to be used for trivial matters, and yes, I know when to log out.) My most secure machines do not use sudo - there is only root. (on most of my machines however, I do use sudo). I use sudo to make a machine a measured amount less secure (by allowing more people high level access) than more secure. Yes, you are right about this. Joachim
hardening openbsd firewall
Hi. I've set up several firewalls with OpenBSD but I have yet to go to any extremes regarding hardening. So far I have updated the source (stable), recompiled the system kernel, removed the source code, turned off inetd, and set up a tight pf.conf. I have been reading up on an interesting strategy of removing tons of executables, storing them on a cd, and setting up symlinks to the cd mount point so they can be accessed when needed. My firewall will be providing internet access (NAT) to a small office lan (not mine). What strategies are others using in this area? -- Peter Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
