# what to do with US hackers

## coolsnowmen

I've decided to deal with the barrage if sshd brute force attempts I get on a daily basis.  

It seems to be doable to block all access from India/Korea/China/Japan.  I realize that I can't do anything about them.

What surprises me is that I get a decent amount of attempts from inside the US (where I live).  Now by itself a failed brute force attempt isn't damaging, but is there something I can do about it.  Tell their ISP? the FBI? does anyone care or do anything about this.

Or is tattle-tale'ing frowned upon?

----------

## bunder

 *coolsnowmen wrote:*   

> I've decided to deal with the barrage if sshd brute force attempts I get on a daily basis.  
> 
> It seems to be doable to block all access from India/Korea/China/Japan.  I realize that I can't do anything about them.
> 
> What surprises me is that I get a decent amount of attempts from inside the US (where I live).  Now by itself a failed brute force attempt isn't damaging, but is there something I can do about it.  Tell their ISP? the FBI? does anyone care or do anything about this.
> ...

 

if you want you can report them to their isp, but most of the time the ones you get from north america come from hosting providers, some don't care, some do...  take your pick, i got fed up with a few of them that i just started blocking them as well...

----------

## coolsnowmen

I've been testing various solutions for automatic blocking of US based IPs, do you have any suggestions?

I'm not sure if I like the general limiting of: http://www.debian-administration.org/articles/187

I've been looking at something else like using the logs to add dynamicall to iptables

like: http://blinkeye.ch/mediawiki/index.php/SSH_Blocking

----------

## alunduil

A tool I've had great success with is fail2ban. It's a simple python daemon that monitors for ssh brute force attacks (you can specify time period, how many failures, etc). Works great, and it's very simple.

Regards,

Alunduil

----------

## pteppic

You can quite simply block multiple connections within a certain time frame with iptables

```
$IPTABLES -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH 

 $IPTABLES -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 --rttl --name SSH -j DROP
```

I've used blinkeye's script with great success also.

----------

## Suicidal

Blinkeye's script would be even better if it sent an e-mail to abuse@$(offendersdomain).com since abuse seems to be a pretty standard contact on whois lookups.

----------

## coolsnowmen

 *pteppic wrote:*   

> You can quite simply block multiple connections within a certain time frame with iptables
> 
> ```
> $IPTABLES -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH 
> 
> ...

 

@pteppic that is exactly like the link I posted above...

Please correct me if I'm wrong.  It looks like that is not a very good solution.  It looks like that will only block that ip for a small time with in that same time.  I would want something like

if there have been X failed attempts in the last Y min, block for Z hours.

The above really only seems to reduce DOSing and would only slow brute force sshing.

----------

## Dammital

 *coolsnowmen wrote:*   

> I've decided to deal with the barrage if sshd brute force attempts I get on a daily basis.

 

Check out denyhosts.

----------

## DarKRaveR

 *coolsnowmen wrote:*   

>  *pteppic wrote:*   You can quite simply block multiple connections within a certain time frame with iptables
> 
> ```
> $IPTABLES -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH 
> 
> ...

 

It works perfectly well. of course it can't do such complex things as you ask for, since netfilter hardly knows anything about your ssh daemon.

What you can do: Set up ssh to drop the connection after 3 failed attempts, if you set hitcount to 3, andd esconds to an equivalent of i.e. 5 Minutes, it implies the following. After 3 connections (with 3 tries each = 9 attempts) reject all new connections for 5 minutes, if a new connection is tried anyway, the counter RESTARTS. So a script woud have to back off for 5 minutes, then try again.

Now, you can do the math and think about how many script do such a thing and how effective a bruteforce can be this way. for the given example 3 hits, 5 minutes this would come down toapprox 2400 tries per day, if and only if, the attacking script does an exact backoff.

----------

## Black

What I did is the other way around: I block everyone except my laptop's public IP, which I can find using DYNDNS, and a script that runs every 10 minutes. The drawback is that when I change location, I have to wait up to 10 minutes before I can ssh home.

----------

## pteppic

 *Suicidal wrote:*   

> Blinkeye's script would be even better if it sent an e-mail to abuse@$(offendersdomain).com since abuse seems to be a pretty standard contact on whois lookups.

 I've actually written most of that, it first looks for abuse@valid.domain in the whois entry and emails there if it can, then looks for any valid email in the whois if the abuse@ fails. I need to alter blinkeye's script to accomodate it, but his coding style is very different to mine and I haven't had a chance to re-write his stuff to make the *whole* thing 'nice' yet. I wanted to do the whole 'pipe to an application with syslog' instead of logtail too.

I wanted to try and stop it sending to abuse@iana.org and similar, but need a clue on where to get the list from?

----------

## yodawg

The problem is, most of this traffic will be coming from bots who are scanning 24/7 and start bruting on successfull ssh connections. Reporting them to their ISP might make the botnet a bit smaller but you are probably wasting your time.

----------

## DarKRaveR

Let me put it this way:

Autogenerated mails I recieve (abuse whtsoever) are considered as spam (by policy) and are thus rejected DURING) transfer. You can do the math what this implies   :Wink:  .

----------

## coolsnowmen

So its a been a while, but I just wanted to update anyone who was watching.

I loved the ease of hosts.deny, but it only took ip blocks in IP/SUB.NET.MASK, while the websites I found had everything in IP/CIDR.

So I wrote a program to convert them.  If anyone is interested, I will post it; perhaps noone else had this problem.

----------

## danomac

Can't you set up port knocking? This way the port would be closed until you "knock" a specific sequence of port, then port 22 would be available.

----------

## coolsnowmen

As cool as the idea of port knocking is, it is not possible because I am not the only user.  And while I can ask users who want to ssh to use a password, asking them to setup port knocking is prohibitive and annoying.  Many people access their files via sftp only interfaces like fish or ssh/sftp clients for windows.  I truly am ok with Staticly blocking the worst offending countries, and dynamically blocking obvious brute force attempts.

Edit: if I were that paranoid about security, shared key alone or shared key with password would be far enough. These computers don't get hit enough for the resource drain of brute force to be a problem.

----------

## danomac

You can always set sshd to listen on a port other than 22. I did this and people hammering it stopped immediately. Might not be an option either, though.

----------

## bunder

 *danomac wrote:*   

> You can always set sshd to listen on a port other than 22. I did this and people hammering it stopped immediately. Might not be an option either, though.

 

that's almost as burdensome as port knocking...  (having to remember what port ssh runs on, etc)

----------

## danomac

I picked a port I could remember. Then all you have to do is pound the new port number in other people's heads.   :Wink: 

----------

## overkll

Ditto.  One only needs to add "-p 2222" (whatever port sshd is listening on) to your ssh command.  I do this on the external interface only.  The internal interface still listens on port 22.

IMHO its the easiest way.

----------

## gimpel

 *overkll wrote:*   

> Ditto.  One only needs to add "-p 2222" (whatever port sshd is listening on) to your ssh command.  I do this on the external interface only.  The internal interface still listens on port 22.
> 
> IMHO its the easiest way.

 

Not even that.

You can define that per host in ~/.ssh/config

----------

