Topic: Block SSH attacks

[bobgmail]

I have recently been having stacks of trouble with attacks being launched against my server.

I have SSH enabled and I use passwords. I have the need to access the server from places where I do not always have the option of using certificates.

Whilst in the office I monitor /var/log/messages but the attacks tend to hit about 3am UK time.

Having checked for options, and ideas I could not find anything that would easily stop ssh from responding. To this end I have created a small shell script which runs on the cron, and scans /var/log/messages for failed attempts. After more than a set amount of failed attempts it blocks the IP address from connecting via IPTABLES.

If anyone would like this script I'll make it available.

[Smitro]

I think there may be a couple here interested as this problem comes up oftern. Don't forget to say what version it's for.

[raem]

bobgmail

They are not attacks, just unauthorised access attempts, and you further say they are "failed attempts".
Just make sure your passwords are strong and that you have not unneccessarily enabled command line access for users.

You can disable remote & enable local only ssh access, and then VPN to the server and establish a local ssh session.


I'm sure others would like your script, although there are other ways to do it.
I think one of the contribs available already has that functionality eg snort/acid I think.

Gordon Rowell also recently posted a command to limit the remote connection host to a specified IP or IPs. That may or may not suit your situation.

see
http://forums.contribs.org/index.php?topic=27855.msg115824#msg115824

[bobgmail]

Smitro

Good point.

Any version from 5.5 upwards. The script will use either IPTABLES or IPCHAINS.


Bob

[bobgmail]

Ray

Cheers for the links.

Like I said I have to allow access, and generally speaking the failed logins relate to brute force attacks on root. Although they then tend to change tact and guess random names and passwords.

Attack: Synonyms: attack, bombard, assail, storm, assault, beset
These verbs mean to set upon, physically or figuratively. Attack applies to offensive action, especially to the onset of planned aggression: The hacker attacked the outpost at dawn.

Bob

The script will work for any version running IPTABLES or IPCHAINS.

[Black]

I get it alot also because I need access to the server from work. I've recently began greping an address and if somes up more then 10 times I whois and send and email to the abuse or admin of the network. sometimes I probe them to see if it's another windowz zombie or not.

[Jáder]

I have one of my servers (on a client!) which is being attacked at ssh. I run this command to watch who/how many times :

grep "Failed password" /var/log/messages | sed -e 's/.*from //g;s/ port.*//g' | sort | uniq -c | sort -nr

Here is the result from today:
   1950 200.155.21.125
    228 202.109.73.145
    146 64.241.169.34
    107 60.191.29.126
     40 24.57.105.164
     13 24.4.255.24
     11 83.16.67.6
      8 202.132.40.29
      2 83.103.156.17
      1 201.35.79.171
      1 200.25.142.63

I´m thinking about to block this IPs on iptables or firewall.

[mrjhb3]

Why not change the port that ssh is listening on.  The majority of the attacks/failed attempts/etc are to port 22.  Changing to something other than 22, should help a bit.  It's not an end all solution by no means, but does help.

JB

[raem]

This is how to stop "attacks" by limitimg the IP addresses you can ssh from. Copied from Gordon Rowells post mentioned earlier.


If you have e-smith-packetfilter-1.15.0-03 or above installed, you can do the following:

/sbin/e-smith/db configuration setprop sshd TCPPort 22
/sbin/e-smith/db configuration setprop sshd AllowHosts <list>
/sbin/e-smith/signal-event remoteaccess-update


where <list> is a comma separated list of IP addresses and/or netmasks (e.g. 16.17.18.19,203.14.64.0/24).

Ssh will then only be allowed from those IP addresses. The firewall code will drop ssh connections from any other hosts.

BTW: Changing the listen port is only a minor deterrent and (IMO) provides a false sense of security.

[mrjhb3]

BTW: Changing the listen port is only a minor deterrent and (IMO) provides a false sense of security.

False sense it may be. But, if you're out at a customer location and need to get something from your server, or need to look at another customer's setup, etc, and every location is using DHCP, you won't know what IP addresses to set for access because they could change.  So, if I use your advice and set my IP address to be allowed to get to my customer's server so I can service them, when my IP address changes, I am no longer allowed in.  Changing the listening port is one way to solve this.  It also helps curb the issue of being attacked/scanned on port 22.  I've had mine changed for 2 years.  I see no attacks to port 22 and the logs prove it as well.  I'm sure they're coming in, but it's getting dropped.  Since, I am not listening on port 22, I am currently not concerned with the dropped traffic.  We can agree to disagree, and do the point counterpoint all night long.  My point was that changing the listening port can curb these attacks.  If someone wants to brute force you or DOS you, then, with enough resources, they can and will.

John Bennett