Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Unusual traffic from Loopback to Unused ARIN address

Published: 2009-10-17
Last Updated: 2009-10-18 15:05:17 UTC
by Rick Wanner (Version: 1)
0 comment(s)

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, which used to be IANA reserved but recently was allocated to ARIN, but is currently not in use.

13:02:52.012656 IP (tos 0x7,CE, ttl 255, id 29423, offset 0, flags [none], proto: Options (0), length: 20) > ip 0
13:02:52.012699 IP (tos 0x7,CE, ttl 255, id 29423, offset 0, flags [none], proto: Options (0), length: 20) > ip 0
13:02:52.012743 IP (tos 0x7,CE, ttl 255, id 29423, offset 0, flags [none], proto: Options (0), length: 20) > ip 0
13:02:52.012788 IP (tos 0x7,CE, ttl 255, id 29423, offset 0, flags [none], proto: Options (0), length: 20) > ip 0

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.

Anybody who knows anything about this traffic and can provide insight please contact me via our contact page.


-- Rick Wanner - rwanner at isc dot sans dot org

Keywords: bogon loopback
0 comment(s)

Cyber Security Awareness Month - Day 17 - Port 22/SSH

Published: 2009-10-17
Last Updated: 2009-10-17 15:01:20 UTC
by Rick Wanner (Version: 2)
0 comment(s)

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.



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.

Ned maintains a securing SSH page over at the CentOS wiki.  It describes in detail how to implement some of the ideas presented here and more.

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.

-- Rick Wanner - rwanner at isc dot sans dot org

0 comment(s)

Mozilla disables Microsoft plug-ins?

Published: 2009-10-17
Last Updated: 2009-10-17 13:46:36 UTC
by Rick Wanner (Version: 2)
2 comment(s)

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?


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.

-- Rick Wanner - rwanner at isc dot sans dot org

2 comment(s)
Diary Archives