On Mon, Mar 28, 2005 at 04:25:57PM -0500, Malcolm Ferguson wrote: > With your suggestions and those from others, I have some more ideas > about how to harden this machine. I've also been looking (again) at the Some more suggestions (some are redundant, but are included just for fun), since it's evident the crack went through SSH: - don't use passwords, use public key authentication if possible - if you have to use password, routinely crack them offline and block users with insecure (or empty!) passwords. John can help you do this, the standard task in Debian will mail you when it cracks a password but it could be easily modified to block the user at the same time. - use per-IP blocking (either at the firewall that NATs you, or locally with tcp-wrappers or iptables rules or both) to limit exposure. Even if you don't know what IP addresses your users will come in from since they use an ISP that dynamically assigns IP address, you could still add the IP blocks from the ISP. You are not as exposed if only users of ISP A in country X can attack yor SSH server than if users from all over the world can attack it. You can even use the GeoIP database to add the IP blocks for a given country if you can't tell which ISP your users will possibly use (it's not 100% accurate, however, unless you pay for it) - move your SSH server to a non-standard port (say, 1022? :-) that will defeat most worms, but not somebody going for you since a simple port scan (+ application fingerprinting) would determine where your SSH server is. Fortunately, worms currently don't portscan their targets (that would slow them down). If you _need_ port 22 access (other firewalls in between will filter other ports), then setup knockd and setup a port pattern people need to use to open it up from the outside through the firewall (or locally). That's actually like having a double password to access the system (one is the port combination needed to open up knockd, which is known by all users, the other is the user's passwords). - if your users don't need full system access lock them through a chroot (using pam_chroot, for example) or use vserver. Better yet, run an ssh server in a bochs/plex86/vmware environment if you have the CPU power for that. That would prevent an SSH compromise from compromising the whole system (or make it even more difficult). Granted, kernel bugs would still succeed, but the attacker would need to break out of the chroot jail to have any effect in the system (if he is a script kiddie using an standard rootkit he might not even now what 'chroot' is) - implement stricter SSH usage limits through PAM. For example, add pam_time to SSH's PAM configuration and configure /etc/security/time.conf so that SSH access is only allowed in work hours (from 9am to 7pm): --------------------- sshd;*;*;!Al1900-0900 --------------------- That would have prevent the worm from infecting you out of office hours (when you are probably not looking at the box logs or when you cannot answer to an IDS alarm that goes off). From your system logs, it looks like all happened in a matter of hours. Probably the guy had already detected your SSH server (ssh probes are _very_ common these days) and you were the target of the dictionary that day. - implement additional safety measures to detect system changes earlier. This includes running a integrity checker locally in the system and logging out of the system (through e-mail, or syslog) so that you are warned when somebody changes the system binaries. There's a lot of people out there looking for wide-open SSH access for a good reason: it's a very common administrative tool opened out to the world and it provides direct local access. Even _if_ a cracker cannot elevate access to the superuser, a direct access to a network through an SSH server poses a serious risk. In your case, your SSH box was NATed so, unless there was another firewalling system between your SSH box and your internal network, even a local user (not root) could have break havoc in your internal network. Typically, internal networks are even less secure than systems opened up to the Internet: sniffable telnet access, internal systems with easy passwords (admin/admin anyone?), unhardened systems (mail service open to the world in UNIX systems, NetBIOS null access in Windows systems, etc.), etc. An internal user can certainly do a lot of damage even if he does not 0wn the box. That's why you should do all your best to prevent remote code execution through SSH from the Internet. Any hurdle you add keeps the bad crackers further away.... it also increases the chance of you detecting the issue (and banning the guy or its ISP) before things get worst. > securing Debain manual, but I think some of it is out of date (written > for Debian 2.2???). Well, I'm the main author, content of the manual usually applies to the _released_ version (and that would be 3.0 currently) but most of it applies to testing/unstable too. If you find content that is way out of date please let me know. Regards Javier PS: I took a few minutes to add the information I wrote in pam-chroot's README on how to use pam-chroot to chroot users in OpenSSH to the manual (see "Chroot environment for SSH" in the Appendix)
Attachment:
signature.asc
Description: Digital signature