OpenWrt Forum Archive

Topic: What to do with SIP and/or SSH spammers/hackers?

The content of this topic has been archived on 2 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I have SIP spammers from China trying to crack my OpenWRT( to make free calls using my Asterisk PBX system I guess).
I already lost $10 because of this (my PBX was open to all in these days, so I can't complain much)

But now they are sometimes making my router crash by trying to register with a random username (such as "caller") and trying a lot of passwords. Is there something I can do to block these? Preferably I would not change the port number because the default is convenient.

How about blocking their attempts after a few (presumably failed) cracks, in /etc/firewall.user?

iptables -A input_wan -p udp --dport 5060 -m state --state NEW -m recent \
  --name SIP --update --seconds 600 --hitcount 3 --rsource -j DROP
iptables -A input_wan -p udp --dport 5060 -m state --state NEW -m recent \
  --name SIP --set --rsource -j ACCEPT

Let us know whether this helps...

Thanks, I will try it. I couldn't figure a so complex rule myself. This shouldn't block anything else (such as real phone calls), right? Also since these spammers are really aggressive, I guess, so maybe I could lower that number of seconds to 30?

Also I guess these rules would work for SSH?

iptables -A input_wan -p tcp --dport 22 -m state --state NEW -m recent --name SSH --update --seconds 30 --hitcount 10 --rsource -j DROP
iptables -A input_wan -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set --rsource -j ACCEPT

Also do I need specific packages such as iptables-mod-extra? I didn't get any error message so I guess it works without? However I was able to login 15 times in less than 30 seconds with SSH.

(Last edited by zorxd on 27 Oct 2010, 18:17)

In sip.conf you could add to every ' type=peer' section:
deny=0.0.0.0/0.0.0.0
permit=<your sip provider address>

and for every sip phone in 'type=friend' section
deny=0.0.0.0/0.0.0.0
permit=192.168.0.0//255.255.0.0

so that only your provider(s) and your sip clients can register

Thanks but is denying their IP address in Asterisk really better than rejecting their request because they have a non existent user name (the default behavior)?

My fear isn't that they crack my password (they won't), it is that they crash my router. Yesterday I could barely type any command (CPU usage was probably 100%) until the router rebooted.

Do you have your Asterisk PBX System hosted on your main NAT/Firewall router? If not, then don't do any ports forwarding to your Asterisk PBX System. If your Asterisk PBX System is hosted on your main NAT/Firewall router, at least heed the suggestions by rAndy to block others from trying to crack your Asterisk PBX System.

Both my Asterisk and FreeSWITCH PBX Systems are hosted on a Netgear WGT634U and a Seagate DockStar, respectively, They both run on a self-built OpenWRT firmware and are connected to my main NAT/Firewall router (a Linksys WRT54GS v3 flashed with a DD-WRT firmware) without any ports forwarding. To this day, I have yet to encounter any crackings on both my Asterisk and FreeSWITCH PBX Systems.

Yes Asterisk runs on my OpenWRT router/nat/firewall/etc. WNDR3700.
The ports are open since I actually receive phone calls from the outside of my NAT.
I don't know how they found me but the fact is that they found me and that my IP address is static so I have to deal with them. They still didn't find one of my usernames (and I don't see them succeed in the future), so I don't see what blocking their IPs in each of my peers would change to that. Wouldn't asterisk still reply them with "invalid user X" anyway? Isn't this exactly what Asterisk does by default?

also I have
alwaysauthreject = yes

So they don't know if the username they try exists or not.

I also found the global "contactdeny" and "contactpermit" settings that seems to offer the same functionality as rAndy's solution, but globally instead of for each peer/friend.

zorxd wrote:

Thanks but is denying their IP address in Asterisk really better than rejecting their request because they have a non existent user name (the default behavior)?

My fear isn't that they crack my password (they won't), it is that they crash my router. Yesterday I could barely type any command (CPU usage was probably 100%) until the router rebooted.

If asterisk rejects requests evaluating ip addresses, it doesn't even come so far to check username/password, so this shouldn't be an issue.

If you're flooded with requests, setting complex iptables rules lets your router sweat (because it has to evaluate packets). So i think it's better to let packets through, asterisk reject them later. Remember that iptables is just a tool to set kernel filtering rules and kernel code runs with higher priority than user space programs.

For what it's worth, I used code very similar to what buildster had above for blocking ssh and a few other ports that hackers tried to hit.  If they're already pounding on your router trying to get into Asterisk, they may eventually start trying to get into the router itself, so it may be a good idea to set up the above rules for at least port 22 or any open ports you do have so that unreasonable numbers of connections get blocked quickly.

JimWright wrote:

For what it's worth, I used code very similar to what buildster had above for blocking ssh and a few other ports that hackers tried to hit.  If they're already pounding on your router trying to get into Asterisk, they may eventually start trying to get into the router itself, so it may be a good idea to set up the above rules for at least port 22 or any open ports you do have so that unreasonable numbers of connections get blocked quickly.

I agree completely. I administer several web hosts, and they're all pretty regularly hit by SSH hackers. I, too, have been using the code that cuts them off after several bad attempts - my usual setting is 5 hits in 90 seconds - and it's made a big improvement. I highly recommend that approach.

Nobody has explicitly said this, but those rules require the "ipt_recent" module, which is in the iptables-mod-extra package.  No big deal, you just need it installed before those rules will work.

whbjr wrote:

I agree completely. I administer several web hosts, and they're all pretty regularly hit by SSH hackers. I, too, have been using the code that cuts them off after several bad attempts - my usual setting is 5 hits in 90 seconds - and it's made a big improvement. I highly recommend that approach.

Something like fail2ban?

What about hosts.deny or a whitelist hosts.allow?

Hello zorxd and every one

I have the same problem, and to solve that I did write a progam that monitoring system logs and when it match syslog message with some rule in configuration file and match count reach the max fail seted trigger some script writen by user that can block ip or do whatever.

Well you can get the sources from http://code.google.com/p/x-wrt/source/checkout, name of package is "logtrigger", when you have the package in your buildroot to select it you need select it in Utilities/logtrigger, make your new image or only a package.

In /etc/config/logtrigger you can see some examples of configuration for it.

To make pattern
%b - mean Block that done when find the first charater after "%b"
%s - mean word like printf
%d - mean digits
%x
%X - mean Exadecimal digits
%o - mean Octal digits

I did commit this package to X-Wrt today, so in next days you can find it in package repositories

I hope this program can be usefull

fofware wrote:

I hope this program can be usefull

Hi fofware,

just compiled on backfire 10.03 and YES it is very usefull!!!
Thank's a lot for this one.

The only thing I am missing is some documentation on the configuration.
I do understand the examples (at least I think I did...) but would there be a rule for the following scenario:

Hacker use ssh-client from openssh, after 3 login failures ssh-client will disconnect and will be started by the hacker for the next 3 guesses.
In this case, the pid of dropbear would change after three failures (the source port as well most likely), and the maxfail counter in rule SSH_WrongPass would never reach 5.

Is there a way to only restrict the rule to the originating IP?
How would the corresponding pattern look like?

Thanks a lot for that (close to) perfect tool,

Isabella ;-)

Hi Bella
Thanks Bella about yours words.

I´m sorry about documentation.
I have not time at this moment, I will try to write something soon.
Any way source code is in http://code.google.com/p/logtrigger/ and if some one want wrtie some howto please paste it and I commit in this site.

bella wrote:

Hacker use ssh-client from openssh, after 3 login failures ssh-client will disconnect and will be started by the hacker for the next 3 guesses.
In this case, the pid of dropbear would change after three failures (the source port as well most likely), and the maxfail counter in rule SSH_WrongPass would never reach 5.

Is there a way to only restrict the rule to the originating IP?
How would the corresponding pattern look like?

I guess you can use this rule

config rule
    option name "SSH_WrongPass"
    option pattern ": bad password attempt for '%s' from %s:%d"
    option fields "user ip port"
    option script "/etc/logtrigger/blockiporport.sh"
    option maxfail "5"
    option enabled "1"

So no matter with pid number and you can reduce maxfail too, and inside your script you can check full log message and be sure it is from dropbear.

If this don't work please paste log messages and I will try to write a rule for you.

Bella
Sorry the right rule is this

config rule
    option name "SSH_WrongPass"
    option pattern ": bad password attempt for '%s' from %s:"
    option fields "user ip port"
    option script "/etc/logtrigger/blockiporport.sh"
    option maxfail "5"
    option enabled "1"

Without port too

To help you to see what happend when program work, you can run it with -D 5 options
logtrigger -D 5

fofware wrote:

Bella
Sorry the right rule is this

config rule
    option name "SSH_WrongPass"
    option pattern ": bad password attempt for '%s' from %s:"
    option fields "user ip port"
    option script "/etc/logtrigger/blockiporport.sh"
    option maxfail "5"
    option enabled "1"

Without port too

To help you to see what happend when program work, you can run it with -D 5 options
logtrigger -D 5

Hi fofware,

just figured this one with the missing port myself ;-)
Now it is working as I need it with an almost identical ruleset (different fail-count, ...) as you just posted.

Thanks once again, and keep up your excellent work,

Isabella ;-)

Hi Bella
Thanks very much

This program is like fail2ban, isn´t?
It is in the normal openwrt-Trunk and i am trying it now, but it does not work. What dependencies does logtrigger have?

Hi PsychoMantis
Yes is like fail2ban, It don't have dependencies...

Do you get some error?

If run from console with -D 5 what you see?

The discussion might have continued from here.