Interesting SIP Scanning

[subterfubd]

Experienced some interesting SIP scanning traffic today and thought I would share.. This SIP scanner seems to have specifically calibrated the timing of his probes along with changing IP addresses to defeat the default settings of the FreePBX IDS.

Of course this will take ages to complete probing for a large number of extension but it exhibits how attackers adapt to current defenses.

 

[wardmundy]

@Tonyclewis: Looks like this was specifically engineered to get around the FreePBX firewall design.

 

[dicko]

As I have always said, these guys are way cleverer than you (or me) and they are very far from 400lb gamesters sitting in their mum's basement, they are state/mob backed entities just patiently waiting to eat your lunch . . . .

Just a thought, "How about just effing STOP RESPONDING TO UDP/5060 !!"

 

[kenn10]

Just a thought, "How about just effing STOP RESPONDING TO UDP/506Indee

Indeed. A properly white listed, non-public IncrediblePBX never sees attacks like this. It is invisible to them. If you go with the public install, all bets are off but voipbl helps a lot.

Those IP's are from Amazon AWS so I'd be sending emails to them regarding hacking attempts.

 

[Halea]

... This SIP scanner seems to have specifically calibrated the timing of his probes along with changing IP addresses to defeat the default settings of the FreePBX IDS.
...

I don't think so. What you're seeing is simply simultaneous probes coming from 4 different IP addresses. They are all being logged as they occur. Simultaneity causes mixing of the traffic and even out of order logging, which gives you the impression that there is some pattern.
Those 4 addresses are from Amazon cloud in North America. Someone is probably running bots on multiple VPSes or Multi IP VPSes.

 

[dicko]

That you 'don't think so' is just your opinion, mine is that without doubt these guys are using a 'Command and Control' system that duck's and dives identification, (think botnet), what you are seeing is just today's throwaway 'mules' IP's which are cheaper if bought by the bunch .

So far it's not worth their effort to look further than UDP/5060 , that's called the 'low hanging fruit' and where many of you un-illuminated guys are hanging, (do you still have sshd on 22? ) .

So, if you guys are still using UDP/5060? I will 99.99% guarantee that you will continue with that \ problem. If on the other hand you don't you will no longer experience this stuff.

As the doctor said to the patient saying "It hurts every time If do that" with " Then stop doing that"

(Just try it . . .)

 

[Samot]

@Tonyclewis: Looks like this was specifically engineered to get around the FreePBX firewall design.

For the record, fail2ban is the actual IDS. All versions of FreePBX have that. Only the distro has the firewall.

 

[dicko]

Actually no version of FreePBX 'have that', you can however easily install it as a current version by an included script perhaps , or have the 'distro' install a very old unsupported version and call it IDS ;-)

 

[islandtech]

I have two systems with users running the clearly anywhere app, since then they are under probes.
Both are hit over and over with different extensions. Block the ip and they return with a different ip.

system 1 is Incredible pbx 2020.1 (non public) asterisk 16.13.0 Incredible gui 15.0.12.37

[2021-03-26 01:30:19] NOTICE[19386] res_pjsip/pjsip_distributor.c: Request 'INVITE' from '<sip:101@-server-ip>' failed for '103.145.13.71:64761' (callid: 916916322-296669361-836411247) - Failed to authenticate
[2021-03-26 01:30:19] NOTICE[18614] res_pjsip/pjsip_distributor.c: Request 'INVITE' from '<sip:101@-server-ip>' failed for '103.145.13.71:64761' (callid: 916916322-296669361-836411247) - Failed to authenticate

system 2 is Incredible pbx2020.1 (non public) asterisk 16.13.0 Incredible gui 15.0.12..51

[2021-03-26 00:26:33] NOTICE[24717] res_pjsip/pjsip_distributor.c: Request 'REGISTER' from '"922229" <sip:-server-ip>' failed for '193.107.216.86:5093' (callid: 1749970209) - No matching endpoint found after 6 tries in 3.395 ms
[2021-03-26 00:28:20] NOTICE[24717] res_pjsip/pjsip_distributor.c: Request 'REGISTER' from '"4262529557" <sip:4262529557@-server-ip>' failed for '193.107.216.90:5597' (callid: 1906873778) - No matching endpoint found after 5 tries in 3.048 ms

My other systems (non public) don't experience this, only the 2 above after allowing clearly anywhere through the router

 

[Samot]

True. Havent done a lot of installs of it, let alone manual ones in a while. My bad.

 

[Samot]

I have two systems with users running the clearly anywhere app, since then they are under probes.
Both are hit over and over with different extensions. Block the ip and they return with a different ip.

system 1 is Incredible pbx 2020.1 (non public) asterisk 16.13.0 Incredible gui 15.0.12.37

[2021-03-26 01:30:19] NOTICE[19386] res_pjsip/pjsip_distributor.c: Request 'INVITE' from '<sip:101@-server-ip>' failed for '103.145.13.71:64761' (callid: 916916322-296669361-836411247) - Failed to authenticate
[2021-03-26 01:30:19] NOTICE[18614] res_pjsip/pjsip_distributor.c: Request 'INVITE' from '<sip:101@-server-ip>' failed for '103.145.13.71:64761' (callid: 916916322-296669361-836411247) - Failed to authenticate

system 2 is Incredible pbx2020.1 (non public) asterisk 16.13.0 Incredible gui 15.0.12..51

[2021-03-26 00:26:33] NOTICE[24717] res_pjsip/pjsip_distributor.c: Request 'REGISTER' from '"922229" <sip:-server-ip>' failed for '193.107.216.86:5093' (callid: 1749970209) - No matching endpoint found after 6 tries in 3.395 ms
[2021-03-26 00:28:20] NOTICE[24717] res_pjsip/pjsip_distributor.c: Request 'REGISTER' from '"4262529557" <sip:4262529557@-server-ip>' failed for '193.107.216.90:5597' (callid: 1906873778) - No matching endpoint found after 5 tries in 3.048 ms

My other systems (non public) don't experience this, only the 2 above after allowing clearly anywhere through the router

Please don't hijack threads. Create a new one for this considering it is not on topic to this thread

 

[dicko]

I have two systems with users running the clearly anywhere app, since then they are under probes.
Both are hit over and over with different extensions. Block the ip and they return with a different ip.

system 1 is Incredible pbx 2020.1 (non public) asterisk 16.13.0 Incredible gui 15.0.12.37

[2021-03-26 01:30:19] NOTICE[19386] res_pjsip/pjsip_distributor.c: Request 'INVITE' from '<sip:101@-server-ip>' failed for '103.145.13.71:64761' (callid: 916916322-296669361-836411247) - Failed to authenticate
[2021-03-26 01:30:19] NOTICE[18614] res_pjsip/pjsip_distributor.c: Request 'INVITE' from '<sip:101@-server-ip>' failed for '103.145.13.71:64761' (callid: 916916322-296669361-836411247) - Failed to authenticate

system 2 is Incredible pbx2020.1 (non public) asterisk 16.13.0 Incredible gui 15.0.12..51

[2021-03-26 00:26:33] NOTICE[24717] res_pjsip/pjsip_distributor.c: Request 'REGISTER' from '"922229" <sip:-server-ip>' failed for '193.107.216.86:5093' (callid: 1749970209) - No matching endpoint found after 6 tries in 3.395 ms
[2021-03-26 00:28:20] NOTICE[24717] res_pjsip/pjsip_distributor.c: Request 'REGISTER' from '"4262529557" <sip:4262529557@-server-ip>' failed for '193.107.216.90:5597' (callid: 1906873778) - No matching endpoint found after 5 tries in 3.048 ms

My other systems (non public) don't experience this, only the 2 above after allowing clearly anywhere through the router

UDP/5060 perhaps?

 

[islandtech]

@Samot looks on topic to me!

 

[islandtech]

5060 is blocked in the router

 

[Samot]

@Samot looks on topic to me!

Yeah, it was a bit muddled but I see it now.

 

[dicko]

Ah, the Icelandic/Dutch/East European Botnet.

sngrep?, (see the ports used )

 

[islandtech]

installed sngrep showing my normal sip traffic at the moment

the address in the op are from skyetel

 

[dicko]

only leasing them ;-) the ASN is good old Amazon


whois -h whois.cymru.com " -v 52.8.201.128"
AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name
16509 | 52.8.201.128 | 52.8.0.0/16 | US | arin | 1991-12-19 | AMAZON-02, US

I was looking at your two , first the one I referenced

whois -h whois.cymru.com " -v 103.145.13.71"
AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name
213371 | 103.145.13.71 | 103.145.13.0/24 | IN | apnic | 2019-11-07 | SQUITTER-NETWORKS, NL


then our Palastinian friends

whois -h whois.cymru.com " -v 193.107.216.90"
AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name
201814 | 193.107.216.90 | 193.107.216.0/24 | HK | ripencc | 2018-05-04 | PL-SKYTECH-AS, PL


feel free to block bad guys at the BGP Prefix level

 

[subterfubd]

That you 'don't think so' is just your opinion, mine is that without doubt these guys are using a 'Command and Control' system that duck's and dives identification, (think botnet), what you are seeing is just today's throwaway 'mules' IP's which are cheaper if bought by the bunch .

So far it's not worth their effort to look further than UDP/5060 , that's called the 'low hanging fruit' and where many of you un-illuminated guys are hanging, (do you still have sshd on 22? ) .

So, if you guys are still using UDP/5060? I will 99.99% guarantee that you will continue with that

That you 'don't think so' is just your opinion, mine is that without doubt these guys are using a 'Command and Control' system that duck's and dives identification, (think botnet), what you are seeing is just today's throwaway 'mules' IP's which are cheaper if bought by the bunch .

So far it's not worth their effort to look further than UDP/5060 , that's called the 'low hanging fruit' and where many of you un-illuminated guys are hanging, (do you still have sshd on 22? ) .

So, if you guys are still using UDP/5060? I will 99.99% guarantee that you will continue with that \ problem. If on the other hand you don't you will no longer experience this stuff.

As the doctor said to the patient saying "It hurts every time If do that" with " Then stop doing that"

(Just try it . . .)

l
\ problem. If on the other hand you don't you will no longer experience this stuff.

As the doctor said to the patient saying "It hurts every time If do that" with " Then stop doing that"

(Just try it . . .)

I think some people missed the point of my post. we all know that having SIP exposed is a bad idea and changing it to a non standard port will greatly cut down the amount of scans. it might not be obvious in the screenshot, but the logs reveal there is a specific time duration between probes and IP's. by default, the freepbx "intrusion detection system" sets a "max retry" value of 8 seconds and a "find time" of 600 seconds. if a remote machine attempts to connect more than 8 times within 10 minutes, they will be banned for 180 seconds.

if you saw the full logs, you'd see that the probes came from a large amount of ip addresses in the 52.X.X.X range. the probes were not random, they came from a large group of IP addresses in a specific repeating sequential order.

my point is that given the amount of IP space, timing and pattern used in this scan, it is easily to defeat the default settings used with the current freepbx intrusion detection system module.

I agree with dicko, there is a definite command and control server being used to control and aggregate the collected data. it's not like there are 200 machines independently scanning at random.

this is far more calculated than the typical "spray and pray" port scans seen with a default configuration of sipvicious.

as network defenders develop new ways to defend, adversaries are constantly retooling and adapting new tactics, techniques and procedures.

That you 'don't think so' is just your opinion, mine is that without doubt these guys are using a 'Command and Control' system that duck's and dives identification, (think botnet), what you are seeing is just today's throwaway 'mules' IP's which are cheaper if bought by the bunch .

So far it's not worth their effort to look further than UDP/5060 , that's called the 'low hanging fruit' and where many of you un-illuminated guys are hanging, (do you still have sshd on 22? ) .

So, if you guys are still using UDP/5060? I will 99.99% guarantee that you will continue with that \ problem. If on the other hand you don't you will no longer experience this stuff.

As the doctor said to the patient saying "It hurts every time If do that" with " Then stop doing that"

(Just try it . . .)

 

[Halea]

That you 'don't think so' is just your opinion, mine is that without doubt these guys are using a 'Command and Control' system that duck's and dives identification, (think botnet), what you are seeing is just today's throwaway 'mules' IP's which are cheaper if bought by the bunch .

...

Any time you organize a data transfer or probing mechanism there is a "Command and Control" system as part of it; that goes without saying.
As for my opinion, I have reasons for saying what I said.
See, I have been in data collection and transmission system design business for a long time. What I saw in that short excerpt that the OP included is no different from data that I see in the log files from, for instance, telemetry stations that transfer periodic hydrologic data measurements in the northern territories of Canada. Each station is programmed to transfer one set of data every so often with slight timing randomization to soften the peaks. When the data from dozens and dozens of stations gets logged in a linear log file it looks exactly like that.

Don't get me wrong, I agree that someone has been probing as the OP stated, and that in itself is an issue.
What I also said/meant was; I was doubtful that it was a sophisticated method with the express goal of defeating the IDS system specific to FreePBX. It's just a dumb probing outcome, that's all!