Random Hackers - Are you prepared?

[bgriff]

Which sip_??.conf file in FreePBX?

Does the alwaysauthreject=yes need to go in sip_custom.conf or sip_general_custom.conf in freePBX? Does it matter?

 

[SpaethCo]

Does the alwaysauthreject=yes need to go in sip_custom.conf or sip_general_custom.conf in freePBX? Does it matter?

As sip.conf gets parsed, it defines the [general] context, then loads the following conf files in order:

sip_general_additional.conf
sip_general_custom.conf
sip_registrations_custom.conf
sip_registrations.conf
sip_custom.conf
sip_additional.conf

The alwaysauthreject directive should go under the [general] context, so technically you are correct that sip_general_custom.conf would be the better place to put it. That said, most folks don't seem to do any new context definitions until sip_additional, so in the vast majority of cases you are still under the [general] context by the time sip_custom gets parsed.

I'm guilty of keeping everything in sip_custom and ignoring the use of sip_general_custom just so I only have a single sip custom file to mess with. I rank this in the same category of "you should never unplug a device by yanking on its cord." I think most people understand why it might not the ideal approach, but given that 99.9999% of the time nothing bad happens people keep doing it.

 

[JRoque]

Hi,

Got the guy hacking into my box yesterday. I only noticed it after seeing the CPU shoot up to 90% utilization. He had about 4K SIP sessions trying to open. Here's what I did.

- First, I closed the SIP and IAX ports on my firewall/router. At this point, he's already blocked.

- Then I set up all of my trunks to nat=yes and qualify=yes. That's to keep the NAT port open to that trunk provider so they can call inbound to me.

- All internal extensions were set to host=x.x.x.x, their fixed IP address, and SIP registration for those was turned off. I haven't had a chance to confirm this but in theory, this should stop rogue extensions from registering as it would be the case when someone tries to hack in. Indeed, I had one extension already set this way and for that the server rejected registration attemps from the hacker saying the extension was not 'dynamic' is it was not supposed to register.


- I do have an external extension using an ATA that lives in a DHCP environment which means I can't fix the host IP address. That extension does SIP register and is set to nat=yes, qualify=yes. I changed the port for that extension to a non-standard, non-voip port. That should make it a bit more difficult to break in as they would need to change the scanning/hacking script just for me. Not impossible but a deterrent.

If you decide to go down this route, here's a port scan service to help you see what your firewall is doing:
https://www.grc.com/x/ne.dll?bh0bkyd2.

The downside of the above changes is that I won't be able to receive voip calls directly to my box. While it might have been good to allow direct voip calls from anyone, it's becoming less safe to do so. My voip provider allows for free incoming and outgoing sip to sip calls so I publish their inbound gateway people can use to call me directly. While on topic, I also changed ENUM to use my provider's inbound gateway rather than my direct address.

Regards,
JR

 

[wardmundy]

Still not convinced there's not a better way to block these creeps. Could you post just a snippet of the Asterisk log showing these attempts. Rather than waiting to read the log, perhaps we need something to watch the Asterisk CLI. That would be almost instantaneous. :tankb:

 

[JRoque]

Hey Ward, here's part of the log. They tried 9999 times. See other logs posted in this thread.

[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9907"<sip:9907@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9908"<sip:9908@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9909"<sip:9909@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9910"<sip:9910@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9911"<sip:9911@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9912"<sip:9912@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9913"<sip:9913@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9914"<sip:9914@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9915"<sip:9915@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9916"<sip:9916@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9917"<sip:9917@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9918"<sip:9918@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9919"<sip:9919@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found
[Jun  5 04:50:43] NOTICE[2577] chan_sip.c: Registration from '"9920"<sip:9920@my-pbx-ip-address>' failed for '216.245.200.107' - No matching peer found

Regards,
JR

 

[patrick_elx]

I had a few attacks from a TW ip address that was presenting a "asterisk" <asterisk> caller id.
I tried to make an inbound route specially for them, but freepbx refused alphanumeric in the CID for the inbound route.

Is it a freepbx or an asterisk limitation?

 

[tabbertmj]

So I had someone trying this too. My fail2ban never caught it even though it went on for some time. It does catch SSH-piaf logon attempts. Why did it miss this attack?

 

[SpaethCo]

How much time passed between the first event and last event? I've seen 1000+ SIP registrations come in within the span of a second.

Since the traffic is UDP it doesn't have the natural throttle of the TCP 3-way handshake that something like SSH would have. Basically the script can just fire packets as quickly as the host machine can generate them.

 

[SpaethCo]

Still not convinced there's not a better way to block these creeps. Could you post just a snippet of the Asterisk log showing these attempts. Rather than waiting to read the log, perhaps we need something to watch the Asterisk CLI. That would be almost instantaneous.

What would you think about rate-limiting some of the SIP traffic allowed per IP?

I'm thinking something like this in iptables might be effective:

-A INPUT -p udp -m hashlimit --dport 5060 --hashlimit 500/sec --hashlimit-mode srcip,dstport --hashlimit-name siphash -j ACCEPT

I'm not sure what the right value would be to the PIAF audience at large, but 500 SIP packets from a single IP address in a second seems pretty generous for a small/medium business with a handful of channels to be setting up calls.

 

[tabbertmj]

It started at 3:37:29 and ran to 3:39:02 with the error of No matching peer found. That was 10000 tries.

Then 3:39:05 to 3:39:37 with the error of Wrong password. That looks like it ran for a few thousand tries.

I am just surprised that the first attack didn't get stopped.

 

[angoyr]

SpaethCo,

That approach is a step in the right direction. As I've been preaching for a long time, we need to stop them in their tracks. Three to five attempts and they're BANNED. that would make everybody happy. I have a vague recollection of something I saw on the man page of iptables where you can do something about x number of attempts to login in x seconds. I don't recall if it was just packets as you proposed. Since I'm no expert in that area, I didn't want to mess with it. We need something that would frustrate them to no end. As I mentioned in an earlier post, 10,004 attempts in 122 seconds is giving them too much excitement and us too much stress. WE have to go on the offensive.

Thanks again for that bit of input. I'm sure many will adopt it.

Robin A.

 

[wardmundy]

That looks like roughly 100 attempts per second from one IP address. Anybody know how many sip packets that would be? 100? If it's 1-for-1, then I would think a number more like 5 in IPtables might suffice. We're talking per IP address, correct? And 5060 only carries the call setup. RTP packets handle the call itself.

This approach wouldn't ban the creeps, just slow them down to a crawl. My guess is that with that much traffic, the server process to check the logs was completely shut down.

 

[tabbertmj]

It was all from one IP address.
My maxretry is set to 2 already for [asterisk-iptables].

 

[SpaethCo]

That looks like roughly 100 attempts per second from one IP address. Anybody know how many sip packets that would be? 100? If it's 1-for-1, then I would think a number more like 5 in IPtables might suffice. We're talking per IP address, correct? And 5060 only carries the call setup. RTP packets handle the call itself.

That should be roughly 1 packet per registration attempt. 5 might be shaving it a bit too thin. I'm thinking you'd eat up at least that many packets from an outside extension, no?

1) INVITE, initially will fail without auth?
2) INVITE w/ credentials
3) OK
4) TRYING / RINGING
5) SESSION INFO immediately if connection to something like an 800 number.

Conceivably that could all hapen within the scope of a second.

Maybe something like 20-30/second is a safer number?

This approach wouldn't ban the creeps, just slow them down to a crawl. My guess is that with that much traffic, the server process to check the logs was completely shut down.

I'm thinking this will give fail2ban more time to work. I agree with you though, fail2ban should be inserting a block rule within a second or two of seeing the event in the log. Nothing should be able to go on for minutes if things are configured & working properly.

 

[wardmundy]

Lest we blow everyone's systems out of the water, I guess we need a few folks to test this with a setting of 20-30 and make sure your normal PBX activity continues without interruption.