Lode sent in some unusual traffic he is seeing from one of his servers. The traffic is Protocol 0 (IPv6 Hop by Hop), originates from a Loopback address and is destined to 108.22.0.0, which used to be IANA reserved but recently was allocated to ARIN, but is currently not in use.

Some searching shows references to this traffic from Solaris (this server is Debian Linux) systems dating back to at least 2002, but I couldn't find any concrete solutions. One reference suggests this traffic might be related to a misconfigured rootkit.

Welcome to CSAM Day 17! Today is brought to you by Secure Shell (SSH) commonly deployed on port 22/TCP.

SSH has become ubiquitous as a mechanism for command line access to *nix systems, and is sometimes deployed on Windows systems as well. As the Dshield graph for port 22 shows, it is a popular target for attackers. These attacks usually take the form of attempts to brute force root accounts and other accounts with weak passwords.

My primary method of protecting SSH servers is threefold:

Deploy the SSH server on a port other than 22/TCP. It appears that the SSH probes on the Internet at this time are focusing their interest on the standard SSH port. My personal server is deployed on a non-standard port and I have not had any attempts to login in over two years.

Deploy one of the SSH brute force prevention tools like DenyHosts, fail2ban, blockhosts, etc. On one of the servers I run where I have to deploy on the standard SSH port DenyHosts has blocked 65 IPs which have attempted brute force attacks in the last month.

Disallow remote root logins. Most SSH servers provide a mechanism to disallow the ability to login to a root account using SSH. In OpenSSH this is done by setting PermitRootLogin to "no" in the /etc/ssh/sshd_config file. This forces users to login using a user account and escalate privilege using su or sudo to become root.

What strategies do you use to secure SSH?

Do you have any strategies for protecting SSH servers deployed on Windows?

Please submit your suggestions through our contact form or via the diary comment system. I will summarize throughout the day.

UPDATES:

Faisal pointed out that I was remiss in not mentioning SSH keys. If you use keys for authentication and disable password authentication via SSH then SSH brute force attacks cannot succeed. In OpenSSH password authentication can be turned off by setting PasswordAuthentication to "no".

Joanne points out that there are alternatives to using brute force prevention tools. In her case she uses the iptables firewall to only permit one SSH connection, successful or not, every three minutes. Joanne also points out that if you must use passwords at least make sure the users use good ones.

Sven sent a number of strategies. First he suggested using AllowGroups to limit access to a group of people. He also recommended that if users only require file transfer capability alternative shells like scponly can be utilized. He also points to ChrootDirectory which can be used as a chroot jail for SSH.

Gerard is a fan of sshdfilter. It is another of the anti-brute forcing tools, but it is an sshd wrapper and doesn't use tcpwrappers for blocking but rather creates iptables or ipfw rules to facilitate the blocking.

Michael suggests that if you know which IP ranges need to access your SSH server that you can limit the IP ranges using the built in iptables firewall. I have in the past used TCPWrappers, which is wrapped around most implementations of openSSH to do the same thing. A good tutorial on how to implement either of these strategies to limit which IPs can connect to your servers is available over at the Debian Administration pages.

A couple of readers have indicated that this evening when they started Firefox it disabled the Microsoft plug-ins Windows Presentation Foundation and Microsoft .NET Framework Assistant 1.1. These plug-ins have been the source of some controversy since it was revealed earlier this week that Microsoft had patched them as part of patch Tuesday.

While the people over at Mozilla have recommended disabling these plug-ins, their is no indication over at the Mozilla Blogs of why this action was taken.

Anybody have any details of what is going on?

UPDATE:

Since the diary went up last evening there is now information on the Mozilla Blog. It appears that Mozilla and Microsoft agreed jointly on this action. The Mozilla blocklist has also been updated to reflect.