I actually run SSH on the standard port on my servers, but add a very simple port knocking mechanism to prevent SSH scanners from being able to determine this:
Here is the iptables code I use (you need to replace ## with a port number, like 8765 for example). Also note that my code is log-heavy, because I keep extremely detailed logs via syslog (that's why I use log-level DEBUG): #Port Knocking - SSH to port ## before port 22 is open to you -N KNOCKSTART -A KNOCKSTART -m recent --name KNOCK --remove -A KNOCKSTART -m recent --name PORTKNOCK --set -A KNOCKSTART -m limit --limit 5/minute -j LOG --log-prefix "SSH KNOCK:" --log-tcp-options --log-ip-options --log-level DEBUG -N KNOCKWIN -A KNOCKWIN -m state --state ! RELATED,ESTABLISHED -m limit --limit 5/minute -j LOG --log-prefix "SSH ALLOW:" --log-tcp-options --log-ip-options --log-level DEBUG -A KNOCKWIN -j ACCEPT -N KNOCKFAIL -A INPUT -p tcp -m tcp --dport 22 -m recent --rcheck --name PORTKNOCK --seconds 300 -j KNOCKWIN -A KNOCKFAIL -p tcp -m tcp --dport 22 -m state --state RELATED,ESTABLISHED -m recent --rcheck --name PORTKNOCK -j KNOCKWIN -A KNOCKFAIL -m limit --limit 5/hour -j LOG --log-prefix "SSH DROP:" --log-tcp-options --log-ip-options --log-level debug -A KNOCKFAIL -j DROP -A INPUT -p tcp -m tcp --dport ## -m recent --set --name KNOCK -A INPUT -p tcp -m tcp --dport ## -m recent --rcheck --name KNOCK -j KNOCKSTART -A INPUT -p tcp -m tcp --dport 22 -j KNOCKFAIL If you prefer to rate limit SSH brute force attacks, you can use this code to temporarily ban IPs for a period of time after they surpass a threshold: #SSH Temporary Ban for Brute Force #If some jagon tries to brute force login to SSH, BAN their IP for 1 hour #and log it, so I can laugh about how smart I am later -A INPUT -m tcp -p tcp --dport 22 -m state --state NEW -m recent --rcheck --hitcount 3 --name HOURBAN -j LOG --log-prefix "SSHLOG: HOURBAN: " --log-tcp-options --log-ip-options --log-level debug -A INPUT -m tcp -p tcp --dport 22 -m state --state NEW -m recent --update --hitcount 4 --name HOURBAN --seconds 7200 -j DROP -A INPUT -m tcp -p tcp --dport 22 -m state --state NEW -m recent --set --name HOURBAN Personally, I prefer the port knocking, since if you fatfinger your password with the temporary ban, you may have to wait an hour before connecting again. Of course, you could also whitelist yourself. Hope that helps, On Fri, Mar 12, 2010 at 11:07 AM, PJ McGarvey <[email protected]> wrote: > Not sure if anyone mentioned port knocking as a solution as well. However I > guess you're limited by the client's ability to support the knock sequence - > such as on a smart phone, though I just googled and there is a port knocker > app for iPhones. > > PJ > > ________________________________ > From: [email protected] > To: [email protected] > Date: Thu, 11 Mar 2010 07:26:02 -0800 > CC: [email protected] > Subject: Re: [Pauldotcom] Ssh break in attempt > > I'm sure with a simple grep and awk I could pull all the user names. But > they're in order, and fairly large. > I've implemented denyhosts, and I've changed the default ssh port. There > were no successfull logins from that ip. > I'm still surprised at the attack from perdue.edu i would have thought they > would have an internal firewall preventing people from doing things like > this. > > Sent from my iPhone > On Mar 11, 2010, at 7:04, Dimitrios Kapsalis <[email protected]> wrote: > > I have seen similar on my home pc as well. Running ssh on a windows box so > the invalid login attempts are being saved in the Event log. > > Any way to harvest these user names? To see what is being used by the > attackers, skimming through the event log it definitely looks to be > dictionary based. > > > > On Wed, Mar 10, 2010 at 11:22 PM, Matt Erasmus <[email protected]> > wrote: > > I wouldn't worry too much about SSH brute force attempts. There are > many many of these attacks happening daily and unless you have some > stupid user account like "bob" with "bob123" as your password, you > should be alright. > > If you really want to be a little more proactive, take a look at > Denyhosts [1] which will help stem the tide. There are also iptables > rules which you can use to throttle back the attacks. I'll see if I > can dig these up for you. > > As for logged in users, check your last log or even > auth.log/secure.log depending on distro. You could probably script > something to alert you should there be a login from elsewhere. But > honestly, once that happens it's game over. The time frame from > successful login to complete rooting of the server is very very low. > > For Apache, you should be checking your access/error logs. I haven't > had a chance to really look into this though... > > While I'm thinking about it, check out OSSEC [2]. Very very cool HIDS > which runs on Linux/Windows. It'll help a lot with most of your > issues. > > </0.02c> > > [1] http://denyhosts.sourceforge.net/ > [2] http://www.ossec.net > > On 11 March 2010 01:49, Brett <[email protected]> wrote: >> I realized I haven't checked my logs on my new server ( bad me ). But >> I figured I wouldn't find anything, it's only my personal server. I >> checked the logs today to find thousands of login attempts. Most tried >> to brute my root password, though I don't have a root user. There were >> a bunch of user name attempts for what looked like a name dictionary >> attack. Some were from busness static ip's and there were even some >> from perdu.edu >> >> Now for my questions. What should I look for to find out if they >> actually got in? Parse the auth log for those ip's for a successfull >> login? I also run a web server on that machine, is there something I >> can look for to see If they got into that? Also is there any recourse >> I have? Or should I just let it go and harden my server even more? > > > > -- > Matt > @z0nbi > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com > > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com > > ________________________________ > Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up > now. > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com > -- -- Benjamin C. Greenfield bcg [at] struxural.com Domains and Hosting for Less from Struxural: http://www.struxural.com _______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
