Server under attack, and firewall blacklist not working

[dcxm]

Hi

My server is under attack for the last 2 hours... this is what i get at the CLI:


[Nov 1 10:58:13] NOTICE[3129]: chan_sip.c:16835 handle_request_register: Registration from '"8011" <sip:8011@200.87.126.218>' failed for '198.61.215.181' - No matching peer found
[Nov 1 10:58:13] NOTICE[3129]: chan_sip.c:16835 handle_request_register: Registration from '"8011" <sip:8011@200.87.126.218>' failed for '198.61.215.181' - No matching peer found
[Nov 1 10:58:13] NOTICE[3129]: chan_sip.c:16835 handle_request_register: Registration from '"8011" <sip:8011@200.87.126.218>' failed for '198.61.215.181' - No matching peer found
[Nov 1 10:58:13] NOTICE[3129]: chan_sip.c:16835 handle_request_register: Registration from '"8011" <sip:8011@200.87.126.218>' failed for '198.61.215.181' - No matching peer found
[Nov 1 10:58:13] NOTICE[3129]: chan_sip.c:16835 handle_request_register: Registration from '"8011" <sip:8011@200.87.126.218>' failed for '198.61.215.181' - No matching peer found

this is constantly happening every second i have one of the line above... well so I decided to block that IP, went to System/Network -> Firewall -> Block list and I added:

5 -A INPUT xxx.xxx.xxx.xxx REJECT Y

But I'm still getting this attacks!

Hope you can help me!

[gers55]

There is a patch to fix a bug in Goautodial firewall i beleive.

As a temprary fix you could change your sip bindport as almost all break in attempts are done on port 5060.

Got to etc/asterisk and edit the sip.conf bindport = 5060 to a port of your choice.

add the port you have chosen to the goautodial firewall ruleset and double check it is set to Y active after adding.

reboot and remember to change the port number on the proxy settings on your sip phone.

[williamconley]

After a sip client has successfully connected through sip, it is often stored in the sip registry. Then a "good" firewall will allow the connection to that IP address based on the existing "relationship" (a bad firewall, of course, doesn't take this into account ...). This can be resolved through wiping of the sip registry table and rebooting the machine (which will clear the "relationship" from the iptables firewall).

Code: Select all

 asterisk -rx "database deltree SIP/Registry"

Another method we've used for "during an attack" is to invoke immediate packet drop for both inbound and outbound to ensure no packets will ever be exchanged between your server and theirs (if a reboot is not possible, this is a viable temporary solution). This stops sip requests from arriving at Asterisk, by dropping them at the firewall. It does not reduce your network usage, but does stop excess asterisk attempts.

Code: Select all

iptables -I INPUT 1 -s 202.126.32.0/24 -p all -j DROP

This will add the drop command as the first "check" during inbound packet routing, before any other rules. The /24 means "any ip address starting with these three digits" (ie 202.126.32.XX where XX is anything from 0 - 256). This can avoid the attacker switching to a new ip on the same subnet to get past the block. If the address block is chinese, we generally block the entire reported block (since we have no chinese clientele or carriers) by checking somewhere like "domaintools.com/202.126.32.XX" where XX is the actual IP attacking. Domaintools.com will show you the owned ip range and you can use a subnet mask tool to calculate the mask to use to kill the entire range.

This same command works on the outbound iptables chain (stopping your asterisk service from sending any packets to the attacker as a result of a prior registration). If you are not sure what chains you are using, try iptables-save (this does not actually save anything, it merely spills it to the screen so you can see it ...).

This is also why "blacklists" are not viable. Whitelist is a requirement because they will merely change to a new IP address and attack you again.

If you require dynamic access (for agents and managers whose IP addresses change ...) we have a dynamic solution that allows iPads and roaming agents to authenticate on a different (still secure) port before allowing them to contact the regular ports. Those regular ports stays closed and you don't get attacked.

[gers55]

If you require dynamic access (for agents and managers whose IP addresses change ...) we have a dynamic solution that allows iPads and roaming agents to authenticate on a different (still secure) port before allowing them to contact the regular ports. Those regular ports stays closed and you don't get attacked.

I am interested in hearing about this solution William.It is an issue i am facing with managers in the field wanting access to reports.

[williamconley]

First we set up a pure whitelist IP, then we open a port (other than 80) with only a single web page on it, that cannot be accessed without knowing it's name. No "index" and no browsing. No other possible access through this port. If you don't know the name of the page ... you get page not found and nothing else.

You send a link to the page to all the agents (and change the name of the page in a timely manner if you need to). The agent uses this page to authenticate and is forwarded to the regular page. Upon successful authentication, they are granted access to the regular page via iptables and their soft phone registers. For the rest of the day, their IP address is authorized. The system forgets these entries at reboot.

$200 to install whitelist with this "Dynamic Good Guys" addition in a Vicibox or GoAutoDial .iso installed system.

The method itself is quite simple and works nicely. The key is that the ipt_recent module is used for a non-static good guys list (forgotten upon reboot) which can be managed via php, perl, or even bash.