Topic: My server is under brut force attacks on Port 5060

[chris burnat]

Over the past three days, I have experienced a large number of scans of my new 2.5 Sail system.  At the moment, I have someone from Taiwan Education Dpt hammering the server from port 5097 onto my external IP on Port 5060. Its been going on for 3 days now at 450 kbit/sec incoming.  At one stage, I had three of them hammering me, total incoming was over 1100kbit/sec.  At this rate, I am going to go into D.O.S...

I have blocked the offending IP and now cannot see it in Asterisk messages, but Iptraf still records incoming traffic to port 5060 from the attacking IP at 450kbit/sec+. 
How to fix this problem? 

More generally, we really need to "hide" Asterrisk to prevent these type of problems, can it be done?

#Blocking:
mkdir -p /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/
pico -w /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/40DenyRiffRaff

[/sbin/iptables -A INPUT -s 163.21.59.10/32 -j DROP]

/sbin/e-smith/expand-template /etc/rc.d/init.d/masq
/etc/init.d/masq restart

[SARK devs]

Hello Chris

What tends to happen with SIP atacks is that they will attack for a while and then move on to some other target once they realize they can't get in.  What you have looks different. 

You can't stop them from sending packets, but usually if you drop them in the firewall (as you have done) they'll stop sending when they realize that they're not getting anything back.  If it really is a DOS attack then the packets are going to come anyway.  Your only recourse then I think is to contact the ISP concerned.

You can't hide Asterisk in the sense that if you want to have Internet calls arriving and departing then the good guys have to be able to find you and that means that the bad guys can also find you.   You could move Asterisk off port 5060 to some other port but you'd have to check with your VoIP carriers to see if they can handle it and you will have to reset your phones to use the new port.  Might be an option though.

Did you set the alwaysauthreject=yes field we discussed?  It seems to work OK and it confuses the "tame" attack robot we have here (we use it internally for testing Asterisk).

We've also been playing with OSSEC and it works well (at least for us) in catching SIP attacks early.  It automatically updates the firewall to drop packets from the offender (it also reports it so you have the option to permanently block the IP manually in the same way you've done it).  You might want to give it a try.   It won't stop a true DOS attack but I'm not sure what will, other than contacting the ISP.

Best

Jeff

[chris burnat]

Hello Jeff,

You can't stop them from sending packets, but usually if you drop them in the firewall (as you have done) they'll stop sending when they realize that they're not getting anything back.  If it really is a DOS attack then the packets are going to come anyway.  Your only recourse then I think is to contact the ISP concerned.

A: Done this, was hillarious.  Ended up with a Mr Chen who asked me for the IP and could not undertand number in English. I wrote to him 3-4 times, no action to date, so I moved the server onto another IP address earlier tonight.  I do not think its a DOS attack, its just a very stubben script kiddy wanting to make a name for himself. The trouble is , he got plenty of bandwidth.

You can't hide Asterisk in the sense that if you want to have Internet calls arriving and departing then the good guys have to be able to find you and that means that the bad guys can also find you.   You could move Asterisk off port 5060 to some other port but you'd have to check with your VoIP carriers to see if they can handle it and you will have to reset your phones to use the new port.  Might be an option though.

A: Yes.  I still wonder if we could not block access to 5060 to all except one of more IP address (we need to cater for multiple trunks - right?).  Problem is I do not know how to do this....   This way, they may not "see" an asterisk server?  When scanning, the first thing they see using sipvicious is:

[chris@canopus sipvicious-0.2.4]$ ./svmap.py  <IP range>
| SIP Device          | User Agent   | Fingerprint                         |
----------------------------------------------------------------------------
| 60.242.xxx.xxx:5060 | Asterisk PBX | Asterisk / Linksys/PAP2T-3.1.15(LS) |

Bingo, thery know an Asterrisk box is there, and can start serious scanning.  If 5060 was blocked to all except my ISP, they may not see the signature above, and go away?

-------------------------------------------------------------------------------

Did you set the alwaysauthreject=yes field we discussed?  It seems to work OK and it confuses the "tame" attack robot we have here (we use it internally for testing Asterisk).

A:  Yes, the  version of of 2.5 I installed a while back has this by default.

We've also been playing with OSSEC and it works well (at least for us) in catching SIP attacks early.  It automatically updates the firewall to drop packets from the offender (it also reports it so you have the option to permanently block the IP manually in the same way you've done it).  You might want to give it a try.   It won't stop a true DOS attack but I'm not sure what will, other than contacting the ISP.

OK< I would like to find out more about this, where do I go?  Is this included in latest software for 2.5?? 
I think that deploying Asterisk server is becoming more problematic given the availability of cracking tooks (sipvicious et al, there are a few now...)

Thanks for you time Jeff.
Best
chris

[CharlieBrady]

We've also been playing with OSSEC and it works well (at least for us) in catching SIP attacks early.  It automatically updates the firewall to drop packets from the offender...

Be  very careful about such approaches. They can often make a DoS trivial.

[SARK devs]

Charlie

Can you clarify - I'm not sure I understand

Kind Regards

Jeff

[CharlieBrady]

Can you clarify - I'm not sure I understand

Any "active response" lockdown system is vulnerable to DoS abuse if it does not reliably detect the source of the attacks. e.g. responding to port-scans by blocking the apparent source IP address allows me to block all access to your IP address if I send a port scan with your IP address forged into the source IP of the attack packets. Similarly, locking accounts after N incorrect passwords can lead to DoS, if I can attempt to login using your username.

I don't know any details of OSSEC - I'm just urging caution.

[SARK devs]

Ah OK - I think I understand.  Good advice. 

We've been playing with OSSEC which is basically a clever log analyser.  You can set thresholds and trigger alarms (usually just emails) based upon regexs which you define for each log you wish to scan. 

However, you can also, optionally, trigger an action based upon a particular event/number of occurences.  For example we currently have a trigger set that will fire if we receive more than 6 declined SIP registration attempts from the same IP in a short period of time (the timers are adjustable).  When this happens, OSSEC will temporarily shut the firewall, just to the originating address, for a few minutes and send a warning to the site administrator via email.

This seems to work well for us and it has successfully blocked several SIP dictionary attacks but we are still very much in a learning curve with the software and your comments about spoofing are well taken. 

Kind Regards and thanks

Jeff   

[Teviot]

This OSSEC look interesting. Where can we get more information about it?

[CharlieBrady]

This OSSEC look interesting. Where can we get more information about it?

The OSSEC website.

[chris burnat]

Another monster attack today, I noticed it because all phones had stopped working, and the network was a bit slaggish. The IP address points to a fiber service in the US.  I do not mean to sound alarmist unecessarely, but it is getting worse - this one is coming to me at around 160kbyte/sec.  I got rid of it by changing IP.

We may have a problem here: had I not noticed this (just lucky), it would have continued all weekend and possibly longer before anyone noticed an issue. At the moment, I would be extremely reluctant deploying a system to a paying customer, or a good mate, because of the potential hussles etc.   Note that the last attack I reported was so severe it chewed a fair amount of my download quota, with the result that my ISP sent me a warning...

Is anyone else experiencing this sort of stuff? 

What can be done to "hide" systems from these idiots? 
This is what this one was doing - getting noway for over 6 hours of hammering as follows:
[Jul 31 16:31:01] NOTICE[4860] chan_sip.c: Registration from '"156" <sip:156@60.xxx.xxx.xxx>' failed for '67.23.126.132' - No matching peer found
[Jul 31 16:31:01] NOTICE[4860] chan_sip.c: Registration from '"156" <sip:156@60.xxx.xxx.xxx>' failed for '67.23.126.132' - No matching peer found
[Jul 31 16:31:01] NOTICE[4860] chan_sip.c: Registration from '"qwerty1" <sip:qwerty1@60.xxx.xxx.xxx>' failed for '67.23.126.132' - No matching peer found
[Jul 31 16:31:01] NOTICE[4860] chan_sip.c: Registration from '"qwerty1" <sip:qwerty1@60.xxx.xxx.xxx>' failed for '67.23.126.132' - No matching peer found
[Jul 31 16:31:01] NOTICE[4860] chan_sip.c: Registration from '"156" <sip:156@60.xxx.xxx.xxx>' failed for '67.23.126.132' - No matching peer found
[Jul 31 16:31:01] NOTICE[4860] chan_sip.c: Registration from '"156" <sip:156@60.xxx.xxx.xxx>' failed for '67.23.126.132' - No matching peer found

[repeated ad nauseatum - did not even try another extension number or password....]

Logs:
[root@affa ~]# ls -lah /var/log/asterisk/messages
-rw-r--r--  1 root root 233M Jul 31 16:46 /var/log/asterisk/messages

LOL.

[SARK devs]

Hi Chris

This is a general SIP issue.  If you have 5060 open on the Internet then you will get attacks like this. It is no different, in principle, to the attacks you will get if you have SSH listening on port 22.   If it is open to the Internet then someone will attempt to subvert it.

In our experience SIP attacks tend to fall away after a few failed attempts but they will still occur from time to time. Are you able to simply restrict inbound access to just your SIP carrier and no one else?  If you can then this may be the simplest solution.  Have you tried running with 5060 closed?  This will often work OK if your carrier is running a session border controller.  If your SME/Asterisk box is also your firewall you can close the sip ports by doing

Code: [Select]

config setprop SIP status disable
signal-event remoteaccess-update
Otherwise, you can simply close 5060 on your modem/router.

If you are not able to run with 5060 closed then you might want to try OSSEC. It will watch your logs and email you if it sees an attack developing.  In its passive mode this will allow you to take manual action at your firewall.  You can also run OSSEC in the active mode in which case you can have it automatically close ports on the firewall.  There are some potential issues with this (see Charlie's comments on the subject), but we do use it in this mode and it works OK for us.

It's pretty easy to install and as long as you modify the asterisk logger (ec/asterisk/logger.conf) to use syslog, it all just works.  There's nothing to define because OSSEC already knows about Asterisk.


Kind Regards

Jeff   

[chris burnat]

Thanks Jeff!

I think you will find that you have  a slight typo in the command you provided:

Code: [Select]

config setprop SIP status disabled
signal-event remoteaccess-update
that is disabled. I tested this with two of my trunks, one being PennyTel - they both appear to be running a session border controller.  I can dial out OK and receive calls.

Scanning for asterisk with sipvicious yields:

# Before disabling SIP:
[chris@canopus sipvicious-0.2.4]$ ./svmap.py 60.xxx.xxx.xxx
| SIP Device          | User Agent   | Fingerprint                         |
----------------------------------------------------------------------------
| 60.242.xxx.xxx:5060 | Asterisk PBX | Asterisk / Linksys/PAP2T-3.1.15(LS) |

After disabling SIP:
[chris@canopus sipvicious-0.2.4]$ ./svmap.py 60.xxx.xxx.xxx
WARNING:root:found nothing

This looks a lot better, thanks again!

You also asked me if I am able to simply restrict inbound access to just a SIP carrier and no one else.  I do not know how to do this, asked in the forum, no reply... Do you know how to do it for individual carrier, using they ip address? 

All good
Best regards
chris

[markleman]

We have been scanned a lot recently and one got through! Fortunately OPAL telecom fraud dept rang me before the damage was too bad, well done to them but it's still £100 down the pan 

Have done:

Code: [Select]

db configuration setprop SIP AllowHosts xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx
signal-event remoteaccess-update
To block all port 5060 UDP traffic except from a few approved IP addresses.

Here are a few commands I used to take a peek at what had been going on.

Count hack attempts:

Code: [Select]

grep -r "Wrong password" /var/log/asterisk/messages* | wc -l

Find IP addresses of hackers:

Code: [Select]

grep -r "Wrong password" /var/log/asterisk/messages*  | sed -e 's/  / /g' | cut -f12 -d' ' | sort -u

Find extensions which have been attempted to hack:

Code: [Select]

grep -r "Wrong password" /var/log/asterisk/messages*  | sed -e 's/  / /g' | cut -f8 -d' ' | sort -u

Regards, Mark Leman

[chris burnat]

We have been scanned a lot recently and one got through! Fortunately OPAL telecom fraud dept rang me before the damage was too bad, well done to them but it's still £100 down the pan 

You done well mate, I got done for over $AU2,000 between me and a client I had to pay for....
Thanks for posting your fix for blocking 5060, and other info!
Cheers
chris

[markleman]

You done well mate, I got done for over $AU2,000 between me and a client I had to pay for....

Commiserations  I did try telling Opal that if they accepted the money they billed us they would be 'handling the proceeds of crime' but they did not want to accept this argument and they were prompt in telling us about the problem so it's £100 down to experience

Regards, Mark Leman