Port 6346

Several people wrote in today suggesting that the increase in traffic on tcp/6346 is due to increased Gnutella activity since many schools have started this week and more students are online with high-speed connections.

Improved Signature for Trojan Win32/Small.AR

nnposter submitted an additional Snort signature for the Win32/Small.AR trojan. He wrote:

"The following revision of the presented rule for Win32/Small.AR has substantially smaller processing overhead while generating fewer false positives:


alert tcp any any -> any 80 (msg:"Win32/Small.AR outbound activity"; flow:to_server,established; uricontent:"/zosman/cia/index.php"; classtype:trojan-activity; sid:5000824; rev:2;)

Further optimization can be achieved by replacing 'any' with $INTERNAL_NET and/or $EXTERNAL_NET but this would be dependent on deployment specifics."

Clarification on SSH Advice for Repeated Hack Attempts

In yesterday's diary, the suggestion was made that to reduce the amount of connection probes to your SSH daemon being made by the current series of automated scanners, you could configure it to listen on a non-default port.

Many folks wrote into today with opinions about "security through obscurity" and indicating that they thought the recommendation was a bad idea.

If you look at the last paragraph of Bill's suggestion from yesterday, you will see he said:

"The above is aptly described as 'security through obscurity', and generally discouraged as the _sole_ protective measure for a system. Moving ssh to a different port doesn't absolve us from performing all the other security steps (patching, firewall, locking down ports, services and users, etc). It does make it harder for the casual prober, though, and that might be enough to handle the issue if the ISP won't."

We fully agree with everyone that there are many other improvements that can be made to better secure your SSH connections. Some of those improvements are:

- use tcp_wrappers/iptables/ipfw/etc to restrict who is allowed to connect to the port on which you are running sshd.

- set "PermitRootLogin no" in the sshd_config file to disallow people from logging in directly as root through an SSH connection.

- set "PasswordAuthentication no" in the sshd_config file to disallow the use of local passwords. This would require the use of SSH public/private keypairs or an additional two-factor authentication method.

- if you use local passwords, ensure that your users are using strong passwords.