Brute Force Sip Attacks

[thirdhatch]

In recent days I have seen an increasing number of brute force sip attacks on some of my servers. When we notice them, we block the IP Addresses through iptables, but we cannot monitor the asterisk log all the time to perform blocking.

Keeping in mind that we cannot block by default because we use the call server for external clients, are there any other solutions for blocking abuse?

Would I need a monitoring server like nagios or is there a simpler solution?

Thanks in advance!

[Michael_N]

Use VPN

[williamconley]

We have a NEW system that allows a LOCKDOWN single page web to be the ONLY public facing access on port 81 with a "link required" filename (ie: if you don't know the name of the logon page, you'll never see anything ... if you use a port other than 81 you'll get a black hole, no response). After the agents log on via this web page, THEN they will have full access to the system.

We've just developed this system. Went yesterday morning, Beta testing this week.

It allows for a full reset of all dynamic IP addresses nightly.

The only change for the agents is that they log in on a different page.

(Also: they log on with their USER/PASS first instead of their PHONE/PASS and the PHONE/PASS is then prepopulated because it was easy ).

We will also shortly be adding "phone ips" from the Admin->Phones table to be populated into the whitelist automatically, but this would really only be necessary if the phone were on a different IP from the user (we have a client who has this situation using WiMax in Miami).

[thirdhatch]

Michael, VPN only adds to the complexity of setup. Also, depending on the location could make running VOIP less feasible because of the increased overhead.

William, will this new system prevent phone registrations unless the login screen has been activated somehow? Otherwise, I can't see how it would help me block sip attacks. I'm not having a problem with people trying to authenticate through the web portal, but rather registration attempts through this sip ports.

Thanks!

[williamconley]

this system blocks EVERYTHING until after authentication unless they are pre-authenticated (hard list in conf file or individual listing in sql table, depending on the installation).

yes i said EVERYTHING. black hole.

you don't exist to any unauthorized IP except for port 81 which has no visible pages unless they actually know the name of the page (and there's only ONE page, no deeper directories or images, just ONE page).

similar to the first Server2003 terminal logins that required first login to verify virus checking before allowing true login (so you cannot infect the server!)

[thirdhatch]

This seems particularly useful.

When it's ready will this be a package we could purchase and install?

[williamconley]

already available, we are charging $100 for the Beta participation to install it on Vicibox systems. I'm not sure what our full-release pricing will be, it may go up or down depending on what the bookkeeper says we have into it and how complex the installation was.

as far as I know, at present the only issue is that a mid-day reboot will "dump" today's auth'd entries and they'll have to re-login (and their phones will refuse to register until they do ... so calling a remote agent on their phone becomes impossible until they notice they are "off" the system and log back in, LOL).

otherwise, no complaints as yet. i expect to run the beta for at least another week to see if any other "issues" arise.

[okli]

Fail2Ban does the job for us, every day we get a few IPs banned. Plus a little change in iptables not allowing flood. Not a perfect solution, but works for now.

http://www.google.com/search?sourceid=m ... 4ac32ef934

Or just Google "asterisk sip brute force", there are plenty of tips and tricks.

Code: Select all

-A INPUT -p udp --dport 5060 -m recent --set --name ASTERISK
-A INPUT -p udp --dport 5060 -m recent --update --seconds 15 --hitcount 10 --name ASTERISK -j DROP

Changing SIP port is also quite good idea, if possible in your setup.

[williamconley]

we have had a few clients who had been set up on that. false positive from a bad soft phone password entry ... and an entire room suddenly loses access to the system.

also, after the "bots" realize they CAN try, they'll hammer away even after fail2ban locks them out (and the result is a Denial of Service).

so we like the whitelist system. pure stealth.

so far, we've never had a single problem with a site that launched with the whitelist in place already. and for those added later, within a week all the problems have gone away. (usually within a day, and often immediately)

so far.

[okli]

we have had a few clients who had been set up on that. false positive from a bad soft phone password entry ... and an entire room suddenly loses access to the system.

also, after the "bots" realize they CAN try, they'll hammer away even after fail2ban locks them out (and the result is a Denial of Service).

so we like the whitelist system. pure stealth.

so far, we've never had a single problem with a site that launched with the whitelist in place already. and for those added later, within a week all the problems have gone away. (usually within a day, and often immediately)

so far.

Fail2ban can whitelist IPs or ranges of IPs, so no worries at this part for us, in our scenario. Plus this way we also monitor apache and several other logs.

As for the DoS - happens not that often and the few iptables rules should help a bit.

Of course, what you developed could be far better solution.
Just giving another, easily implemented option.

[williamconley]

I hear ya. Just that those who have "easily" implemented fail2ban ... have easily locked themselves out doing it. pure whitelist has resolved it. if you already have pure white list ... fail2ban is redundant.

i DO recommend fail2ban for public accessible systems, but vicidial servers do not ordinarily fall into that category.

for boards, blogs, anything with a public login/signup, it's a beautiful solution. but for vicidial ... the losses from a single day of DOS are huge, and you cannot stop them once begun without changing the IP address or getting cute and limiting their access (which requires GIVING them access with bandwidth monitoring).

vicidial = stealth in my book. and in many cases, if you just lock down vicibox (turn off ALL ports/allowed services in yast firewall) the only thing you need to open after that is a whitelist for each offsite room and carrier. everything else is "auto-allowed" as being something the vicidial server "reaches out to". the opensuse built-in firewall is quite nice and robust, actually.

[thirdhatch]

Thanks Okli and William.