End of the road for Cisco CSA
Cisco announces the end-of-sale and end-of life dates for the Cisco Security Agent. There is no replacement available for the Cisco Security Agent at this time.
http://www.cisco.com/en/US/
(Sales end this December, Maintenance the following December, and it will no longer be supported after December 2013).
Thanks Brian!
Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
Distributed SSH Brute Force Attempts on the rise again
SSH brute force attempts seem to be on the rise again, at the SANS Internet Storm Center we have received a number of reports that a number of networks are seeing them. The source IP addresses vary with each new attempted username in the wordlist, which would indicate that the attempts are distributed through botnet(s). It only takes a single user with a weak password for a breach to occur, then with that foothold escalation and further attacks are likely next. This is certainly not a new phenomenon, however I think it is a good time to raise awareness about it once again.
Reader xemaps wrote in with this log snippet:
"Whole day my server has been targeted by a botnet, attacker also changed ip each new dictionary user."
Jun 17 23:02:03 pro sshd[17444]: Invalid user mailer from 217.37.x.x
Jun 17 23:03:24 pro sshd[17460]: Invalid user mailer from 87.66.x.x
Jun 17 23:05:27 pro sshd[17617]: Invalid user mailman from 89.97.x.x
Jun 17 23:09:30 pro sshd[17639]: Invalid user mailtest from 62.2.x.x
Jun 17 23:15:44 pro sshd[17894]: Invalid user maker from 83.236.x.x
Jun 17 23:16:47 pro sshd[17925]: Invalid user mama from 84.73.x.x
Reader Ingvar wrote in with a similar pattern:
"On my home system I have seen these login attempts that start with user "aaa" and goes on alphabetically from over 1000 different hosts around the world (judging from the DenyHosts reports). Normally I only see single-digit attempts per day."
Jun 17 02:14:56 MyHost sshd[808]: error: PAM: authentication error for illegal user aaa from 151.100.x.x
Jun 17 02:23:11 MyHost sshd[870]: error: PAM: authentication error for illegal user aabakken from 150.254.x.x
Jun 17 02:24:57 MyHost sshd[875]: error: PAM: authentication error for illegal user aapo from 173.33.x.x
Jun 17 02:35:23 MyHost sshd[885]: error: PAM: authentication error for illegal user abakus from 121.160.x.x
Jun 17 02:37:32 MyHost sshd[895]: error: PAM: authentication error for illegal user abas from 190.200.x.x
Jun 17 02:38:18 MyHost sshd[900]: error: PAM: authentication error for illegal user abc from 193.251.x.x
Last year ISC Handler Rick wrote up a diary for Cyber Security Awareness Month - Day 17 - Port 22/SSH about SSH brute force attempts and some safeguards that can be implemented. Here is a brief summary:
- Deploy the SSH server on a port other than 22/TCP
- Deploy one of the SSH brute force prevention tools
- Disallow remote root logins
- Set PasswordAuthentication to "no" and use keys
- If you must use passwords, ensure that they are all complex
- Use AllowGroups to limit access to a specific group of users
- Use as a chroot jail for SSH if possible
- Limit the IP ranges that can connect to SSH
If you have any comments, additional examples of safeguards, or additional information please let us know here.
Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
IMPORTANT INFORMATION: Distributed SSH Brute Force Attacks
Based on an analysis of the logs for my SSH honeypot, it appears that this latest spate of SSH brute force attacks are using keyboard-interactive authentication, rather than the standard password authentication.
2010-05-21 19:29:11+0000 203.185.xxx.xxx trying auth password
2010-05-23 19:31:57+0000 200.175.xxx.xxx trying auth password
2010-05-25 01:02:57+0000 122.155.xxx.xxx trying auth password
2010-05-25 01:09:06+0000 75.156.xxx.xxx trying auth none
2010-05-25 01:09:07+0000 75.156.xxx.xxx trying auth password
2010-05-25 05:08:07+0000 68.40.xxx.xxx trying auth password
2010-05-29 14:39:51+0000 122.226.xxx.xxx trying auth password
2010-06-02 06:27:31+0000 217.25.xxx.xxx trying auth password
2010-06-03 11:32:22+0000 62.83.xxx.xxx trying auth none
2010-06-03 11:32:24+0000 62.83.xxx.xxx trying auth password
2010-06-11 08:44:52+0000 222.173.xxx.xxx trying auth password
2010-06-11 15:42:46+0000 220.163.xxx.xxx trying auth password
2010-06-13 22:14:15+0000 67.228.xxx.xxx trying auth password
2010-06-15 01:21:39+0000 211.254.xxx.xxx trying auth password
2010-06-15 02:09:01+0000 202.98.xxx.xxx trying auth password
2010-06-15 19:53:49+0000 89.128.xxx.xxx trying auth none
2010-06-15 19:53:51+0000 89.128.xxx.xxx trying auth password
2010-06-15 20:10:45+0000 89.133.xxx.xxx trying auth password
2010-06-16 18:20:54+0000 165.98.xxx.xxx trying auth keyboard-interactive
2010-06-16 18:33:35+0000 64.122.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:05:53+0000 59.124.xxx.xxx trying auth password
2010-06-16 19:06:47+0000 220.73.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:28:54+0000 219.159.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:47:52+0000 80.94.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:57:57+0000 203.15.xxx.xxx trying auth keyboard-interactive
2010-06-16 20:18:00+0000 119.161.xxx.xxx trying auth keyboard-interactive
2010-06-16 20:27:40+0000 82.91.xxx.xxx trying auth keyboard-interactive
2010-06-16 20:47:02+0000 190.12.xxx.xxx trying auth keyboard-interactive
2010-06-16 21:27:00+0000 200.40.xxx.xxx trying auth keyboard-interactive
2010-06-17 16:59:36+0000 210.82.xxx.xxx trying auth password
Understand: If you have disabled password authentication in your ssh_config by uncommenting the line:
PasswordAuthentication no
that *WILL NOT* protect you against this latest round of attacks.
In order to disable keyboard-interactive logins, you must also uncomment the line:
ChallengeResponseAuthentication no
NOTE: DO NOT DO THIS unless you understand what you're doing and know that it will not break anything (I don't want a bunch of emails saying "I got in trouble because I did what Liston said...")
To test if your server is configured correctly, log in using the command line version of ssh with the "-v" option. That will spit out a whole bunch of debugging information. The important line is this:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
If you see something like that, then you're not only vulnerable to standard password brute force attacks, but this newer keyboard-interactive attack as well.
Tom Liston
Handler - SANS Internet Storm Center
Senior Security Analyst - InGuardians, Inc.
Comments