I have an outward facing ssh box at work that is currently being attacked. somebody's going through a dictionary attack of usernames; currently he or she is on abl. I can't block the IP Address because the ip is different with each username. Does anybody have any good ideas on how to stop this? I'm probably going to move the ssh port to some random high number to get rid of this, but I don't know yet if anybody else ssh's in besides me. Thanks in advance -- Eric Martin Key fingerprint = D1C4 086E DBB5 C18E 6FDA B215 6A25 7174 A941 3B9F
Do you know the IP addresses of the users that ARE authorized to SSH into the system? If so, add them to /etc/hosts.allow. Tal -----Original Message----- From: wlug-bounces@mail.wlug.org [mailto:wlug-bounces@mail.wlug.org] On Behalf Of Eric Martin Sent: Tuesday, September 30, 2008 1:44 PM To: Worcester Linux Users Group Subject: [Wlug] SSH problems I have an outward facing ssh box at work that is currently being attacked. somebody's going through a dictionary attack of usernames; currently he or she is on abl. I can't block the IP Address because the ip is different with each username. Does anybody have any good ideas on how to stop this? I'm probably going to move the ssh port to some random high number to get rid of this, but I don't know yet if anybody else ssh's in besides me. Thanks in advance -- Eric Martin Key fingerprint = D1C4 086E DBB5 C18E 6FDA B215 6A25 7174 A941 3B9F
On Tue, 30 Sep 2008, Tal Cohen wrote:
Assuming you have TCP Wrappers built into your server of course. Maybe it's built in by default there days. I haven't built an SSH Server from source in a long time. But if you do have it installed I believe you can add the offending IP in /etc/hosts.deny which would be much easier. And even better-er, if the attacker is coming from one IP and you have a firewall it would be more efficient to stop them there before they reach the SSH service. -- Gary
Tal Cohen wrote:
I like it, but I might need access from some random place. Granted I could always vpn into work and then ssh from that known ip... I'll think about it, thanks for the idea! -- Eric Martin Key fingerprint = D1C4 086E DBB5 C18E 6FDA B215 6A25 7174 A941 3B9F
On Tue, Sep 30, 2008 at 01:43:46PM -0400, Eric Martin wrote:
You could always just ignore it. Especially if you turn off password authentication and require users to use SSH RSA keys. Then no matter what dictionary attack it attempted, it will never work. I got sick of hearing my hard drive logging all the failed attempts and finally resorted to moving the SSH port.
<clueless_newbie>just out of curiosity. Could this be an attack from some sort of botnet? would that explain the different IPs? or is he forging packets? </clueless_newbie> On Tue, Sep 30, 2008 at 1:43 PM, Eric Martin <freak4uxxx@gmail.com> wrote:
This might be of interest: http://www.fail2ban.org/wiki/index.php/Main_Page Basically, it detects hack attempts and locks off the offending IP address for about five minutes by modifying firewall rules. I've only started looking at it myself, but I know others that use it and it seems to work well. Bill Smith Fall River, MA Charter Member of LOPSA On Tue, Sep 30, 2008 at 8:03 PM, Alex Camilo <alex.camilo@gmail.com> wrote:
William Smith wrote, on Sep 30, 2008 at 21:47 EDT:
I've actually been using fail2ban for several years now one a few servers, with great success. .. except in the scenerio where it's unique IPs. I've actually been seeing a small amount of that today, as well, on one of my boxen, and as far as I can see, there's very little to no duplication of IPs, so fail2ban would not help at all in this case. fail2ban works for ssh attempts, where one IP fails login, for example, 3 times within 600 seconds, and also has rules for other daemons like bind, apache, exim, &c. Over the past month, it's been quiet the last couple weeks, but the beginning of September was *very* busy, and fail2ban saved me several headaches. -- Aaron Haviland 34 Wayne Ave, Dudley, MA home: [508] 943 - 7974
It most definitly is. If you expose a box with default ports for any amount of time you'll see all sorts of fun stuff taking a wack at it. If you need to connect from random places, and you can keep your keys safe, going key only and then moving the port is probably going to keep you pretty safe. On 9/30/08, Alex Camilo <alex.camilo@gmail.com> wrote:
-- Sent from Gmail for mobile | mobile.google.com I am weary of the allegiances of any politician who refers to their constituents as "consumers".
Eric> I have an outward facing ssh box at work that is currently being Eric> attacked. somebody's going through a dictionary attack of Eric> usernames; currently he or she is on abl. I can't block the IP Eric> Address because the ip is different with each username. Does Eric> anybody have any good ideas on how to stop this? I'm probably Eric> going to move the ssh port to some random high number to get rid Eric> of this, but I don't know yet if anybody else ssh's in besides Eric> me. I've been running 'denyhosts' python script on both debian and FreeBSD boxes I own. I don't like moving the SSH port because that's really just security through obscurity. And if your users have good passwords, it's unlikely that a dictionary attack is going to work as well. denyhosts works well, blocks hosts making multiple attempts, etc. It's hard to block attacks where they do one attempt/per IP, but hopefully it's going to take them long enough to run a useful sweep that the won't get in. Fail2ban looks to be another good option as well, though I haven't touched it. John
John Stoffel wrote:
I'm not looking for extra security, I'm looking for clearing my logs and keeping the script kiddies away. I'm using real security, but it's nice to be able to read through your logs...
And if your users have good passwords, it's unlikely that a dictionary attack is going to work as well.
Turned off password / pam / challengeresponse, just using PKI
I also want to look into fail2ban but I haven't had a chance yet. -- Eric Martin Key fingerprint = D1C4 086E DBB5 C18E 6FDA B215 6A25 7174 A941 3B9F
Eric - one way to stop the attacks is to let them in.... Time for a honeypot! IIRC a very simple C program can keep these guys occupied for hours.. Suggestion - move your ssh access port, and run THP Tiny Honeypot Quote: Wouldn't it be nice if every single unsolicited connection attempt tied up the attacker who launched it by appearing to actually work, all the while providing a little insight into their motives and intents? thp appears to listen on all ports otherwise not in legitimate use, providing a series of phony responses to attacker commands. Some are very simple, others are somewhat more interactive. The goal isn't to fool a skilled, determined attacker...merely to cloud the playing field with tens of thousands of fake services, all without causing unreasonable stress on the thp host. * Changelog: http://www.alpinista.org/files/thp/thp-0.4.4/CHANGELOG * Download: http://www.l0t3k.net/tools/Honeypot/thp-0.4.6.tar.gz * Home: http://www.alpinista.org/ * License: GNU General Public License * MD5SUM: 227ef8a3cedb49a1c634298f71a5832b * Platform(s): Linux --
Alex Camilo wrote:
Yeah, please don't run honeypots. I get enough problems without people deliberately making new ones. Phil -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Phil Deneault "We work in the dark. We do what we can. deneault@wpi.edu We give what we have. Network Security Officer Our doubt is our passion, Network Operations and our passion is our task. Worcester Polytechnic Institute The rest is the madness of art." http://www.wpi.edu/~deneault/ - Henry James -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
participants (11)
-
Aaron Haviland -
Alex Camilo -
Chuck Anderson -
Eric Martin -
Gary Hanley -
Jeff Kinz -
John Stoffel -
Phillip Deneault -
Tal Cohen -
Tim Keller -
William Smith