Am I being hacked?

General Help
1

I have found this in my Asterisk log file and it constantly repeats.

Does this indicate that I am being hacked or just paranoid?

[2018-12-28 13:09:06] VERBOSE[3986][C-00000022] pbx.c: Executing [s@from-sip-external:7] Answer(“PJSIP/anonymous-00000022”, “”) in new stack
[2018-12-28 13:09:06] VERBOSE[3986][C-00000022] pbx.c: Executing [s@from-sip-external:8] Wait(“PJSIP/anonymous-00000022”, “2”) in new stack
[2018-12-28 13:09:06] VERBOSE[3869][C-00000020] pbx.c: Spawn extension (from-sip-external, s, 11) exited non-zero on ‘PJSIP/anonymous-00000020’
[2018-12-28 13:09:06] VERBOSE[3869][C-00000020] pbx.c: Executing [h@from-sip-external:1] Hangup(“PJSIP/anonymous-00000020”, “”) in new stack
[2018-12-28 13:09:06] VERBOSE[3869][C-00000020] pbx.c: Spawn extension (from-sip-external, h, 1) exited non-zero on ‘PJSIP/anonymous-00000020’
[2018-12-28 13:09:08] VERBOSE[3986][C-00000022] pbx.c: Executing [s@from-sip-external:9] Playback(“PJSIP/anonymous-00000022”, “ss-noservice”) in new stack
[2018-12-28 13:09:08] VERBOSE[3986][C-00000022] file.c: <PJSIP/anonymous-00000022> Playing ‘ss-noservice.ulaw’ (language ‘en’)
[2018-12-28 13:09:10] VERBOSE[3924][C-00000021] pbx.c: Executing [s@from-sip-external:10] PlayTones(“PJSIP/anonymous-00000021”, “congestion”) in new stack
[2018-12-28 13:09:10] VERBOSE[3924][C-00000021] pbx.c: Executing [s@from-sip-external:11] Congestion(“PJSIP/anonymous-00000021”, “5”) in new stack
[2018-12-28 13:09:13] VERBOSE[3986][C-00000022] pbx.c: Executing [s@from-sip-external:10] PlayTones(“PJSIP/anonymous-00000022”, “congestion”) in new stack
[2018-12-28 13:09:13] VERBOSE[3986][C-00000022] pbx.c: Executing [s@from-sip-external:11] Congestion(“PJSIP/anonymous-00000022”, “5”) in new stack
[2018-12-28 13:09:15] VERBOSE[3924][C-00000021] pbx.c: Spawn extension (from-sip-external, s, 11) exited non-zero on ‘PJSIP/anonymous-00000021’
[2018-12-28 13:09:15] VERBOSE[3924][C-00000021] pbx.c: Executing [h@from-sip-external:1] Hangup(“PJSIP/anonymous-00000021”, “”) in new stack
[2018-12-28 13:09:15] VERBOSE[3924][C-00000021] pbx.c: Spawn extension (from-sip-external, h, 1) exited non-zero on ‘PJSIP/anonymous-00000021’
[2018-12-28 13:09:17] VERBOSE[2615] pbx_variables.c: Setting global variable ‘SIPDOMAIN’ to ‘203.40.47.143’
[2018-12-28 13:09:17] VERBOSE[3988][C-00000023] pbx.c: Executing [953014763000942@from-sip-external:1] NoOp(“PJSIP/anonymous-00000023”, “Received incoming SIP connection from unknown peer to 953014763000942”) in new stack
[2018-12-28 13:09:17] VERBOSE[3988][C-00000023] pbx.c: Executing [953014763000942@from-sip-external:2] Set(“PJSIP/anonymous-00000023”, “DID=953014763000942”) in new stack
[2018-12-28 13:09:17] VERBOSE[3988][C-00000023] pbx.c: Executing [953014763000942@from-sip-external:3] Goto(“PJSIP/anonymous-00000023”, “s,1”) in new stack
[2018-12-28 13:09:17] VERBOSE[3988][C-00000023] pbx_builtins.c: Goto (from-sip-external,s,1)
[2018-12-28 13:09:17] VERBOSE[3988][C-00000023] pbx.c: Executing [s@from-sip-external:1] GotoIf(“PJSIP/anonymous-00000023”, “1?setlanguage:checkanon”) in new stack
[2018-12-28 13:09:17] VERBOSE[3988][C-00000023] pbx_builtins.c: Goto (from-sip-external,s,2)
[2018-12-28 13:09:17] VERBOSE[3988][C-00000023] pbx.c: Executing [s@from-sip-external:2] Set(“PJSIP/anonymous-00000023”, “CHANNEL(language)=en”) in new stack
[2018-12-28 13:09:17] VERBOSE[3988][C-00000023] pbx.c: Executing [s@from-sip-external:3] GotoIf(“PJSIP/anonymous-00000023”, “1?noanonymous”) in new stack
[2018-12-28 13:09:17] VERBOSE[3988][C-00000023] pbx_builtins.c: Goto (from-sip-external,s,5)
[2018-12-28 13:09:17] VERBOSE[3988][C-00000023] pbx.c: Executing [s@from-sip-external:5] Set(“PJSIP/anonymous-00000023”, “TIMEOUT(absolute)=15”) in new stack
[2018-12-28 13:09:17] VERBOSE[3988][C-00000023] func_timeout.c: Channel will hangup at 2018-12-28 13:09:32.925 AEDT.
[2018-12-28 13:09:17] WARNING[3988][C-00000023] func_channel.c: Unknown or unavailable item requested: ‘recvip’
[2018-12-28 13:09:17] VERBOSE[3988][C-00000023] pbx.c: Executing [s@from-sip-external:6] Log(“PJSIP/anonymous-00000023”, "WARNING,"Rejecting unknown SIP connection from “”) in new stack
[2018-12-28 13:09:17] WARNING[3988][C-00000023] Ext. s: "Rejecting unknown SIP connection from "

2

Not hacked per se but they are trying to relay calls through you which the PBX is not allowing.

3

Hi Tom,

Thanks for your reply.

What would be considered best practice to block them out?

4

If you’re running the System Firewall, blacklist them. If you’re not, then iptables to drop them.

5

Problem I have is that I can’t see what IP address they are coming from. Any idea’s?

6

Turn up the verbosity and see if that helps or do pjsip set logger on to look at the SIP packets.

7

I increased verbosity in the logging to 10 and now have this:

[2018-12-28 14:24:57] WARNING[9759][C-000000a8] func_channel.c: Unknown or unavailable item requested: ‘recvip’
[2018-12-28 14:24:57] VERBOSE[9759][C-000000a8] pbx.c: Executing [s@from-sip-external:6] Log(“PJSIP/anonymous-000000a8”, "WARNING,"Rejecting unknown SIP connection from “”) in new stack
[2018-12-28 14:24:57] WARNING[9759][C-000000a8] Ext. s: "Rejecting unknown SIP connection from "
[2018-12-28 14:24:57] VERBOSE[9759][C-000000a8] pbx.c: Executing [s@from-sip-external:7] Answer(“PJSIP/anonymous-000000a8”, “”) in new stack
[2018-12-28 14:24:57] VERBOSE[2614] res_rtp_asterisk.c: 0x336d150 – Strict RTP learning after remote address set to: 192.168.1.83:25282
[2018-12-28 14:24:58] VERBOSE[9759][C-000000a8] pbx.c: Executing [s@from-sip-external:8] Wait(“PJSIP/anonymous-000000a8”, “2”) in new stack
[2018-12-28 14:24:58] VERBOSE[9758][C-000000a7] pbx.c: Spawn extension (from-sip-external, s, 11) exited non-zero on ‘PJSIP/anonymous-000000a7’
[2018-12-28 14:24:58] VERBOSE[9758][C-000000a7] pbx.c: Executing [h@from-sip-external:1] Hangup(“PJSIP/anonymous-000000a7”, “”) in new stack
[2018-12-28 14:24:58] VERBOSE[9758][C-000000a7] pbx.c: Spawn extension (from-sip-external, h, 1) exited non-zero on ‘PJSIP/anonymous-000000a7’
[2018-12-28 14:25:00] VERBOSE[9759][C-000000a8] pbx.c: Executing [s@from-sip-external:9] Playback(“PJSIP/anonymous-000000a8”, “ss-noservice”) in new stack
[2018-12-28 14:25:00] VERBOSE[9759][C-000000a8] file.c: <PJSIP/anonymous-000000a8> Playing ‘ss-noservice.ulaw’ (language ‘en’)
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.380+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff408880d60”,LocalAddress=“IPV4/TCP/0.0.0.0/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/56970”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.380+1100”
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.383+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff414003010”,LocalAddress=“IPV4/TCP/0.0.0.0/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/56974”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.383+1100”
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.391+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff404024830”,LocalAddress=“IPV4/TCP/0.0.0.0/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/56958”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.391+1100”
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.392+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff40c014b60”,LocalAddress=“IPV4/TCP/0.0.0.0/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/56966”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.392+1100”
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.392+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff400003ad0”,LocalAddress=“IPV4/TCP/0.0.0.0/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/56962”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.392+1100”
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.406+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x2425430”,LocalAddress=“IPV4/TCP/0.0.0.0/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/56954”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.406+1100”
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.440+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff3f80031c0”,LocalAddress=“IPV4/TCP/0.0.0.0/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/56950”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.440+1100”
[2018-12-28 14:25:05] VERBOSE[9759][C-000000a8] pbx.c: Executing [s@from-sip-external:10] PlayTones(“PJSIP/anonymous-000000a8”, “congestion”) in new stack
[2018-12-28 14:25:05] VERBOSE[9759][C-000000a8] pbx.c: Executing [s@from-sip-external:11] Congestion(“PJSIP/anonymous-000000a8”, “5”) in new stack
[2018-12-28 14:25:07] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:07.003+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff4100009a0”,LocalAddress=“IPV4/TCP/0.0.0.0/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/56978”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:07.003+1100”
[2018-12-28 14:25:09] VERBOSE[2614] pbx_variables.c: Setting global variable ‘SIPDOMAIN’ to ‘203.40.47.143’
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [949204763000942@from-sip-external:1] NoOp(“PJSIP/anonymous-000000a9”, “Received incoming SIP connection from unknown peer to 949204763000942”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [949204763000942@from-sip-external:2] Set(“PJSIP/anonymous-000000a9”, “DID=949204763000942”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [949204763000942@from-sip-external:3] Goto(“PJSIP/anonymous-000000a9”, “s,1”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx_builtins.c: Goto (from-sip-external,s,1)
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [s@from-sip-external:1] GotoIf(“PJSIP/anonymous-000000a9”, “1?setlanguage:checkanon”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx_builtins.c: Goto (from-sip-external,s,2)
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [s@from-sip-external:2] Set(“PJSIP/anonymous-000000a9”, “CHANNEL(language)=en”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [s@from-sip-external:3] GotoIf(“PJSIP/anonymous-000000a9”, “1?noanonymous”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx_builtins.c: Goto (from-sip-external,s,5)
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [s@from-sip-external:5] Set(“PJSIP/anonymous-000000a9”, “TIMEOUT(absolute)=15”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] func_timeout.c: Channel will hangup at 2018-12-28 14:25:24.382 AEDT.
[2018-12-28 14:25:09] WARNING[9893][C-000000a9] func_channel.c: Unknown or unavailable item requested: ‘recvip’
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [s@from-sip-external:6] Log(“PJSIP/anonymous-000000a9”, "WARNING,"Rejecting unknown SIP connection from “”) in new stack
[2018-12-28 14:25:09] WARNING[9893][C-000000a9] Ext. s: "Rejecting unknown SIP connection from "

I’m at a bit of a loss and not sure what to do to stop them.

8

One solution is to just NOT listen on udp/5060, with any channel driver, EVER.
Through personal experience, I would expand that to suggest that you don’t listen on any port between 5000 and 5999 for SIP INVITES , you are your own “king of the castle” with all your extensions, but many vsp’s only allow 5060 , no problem, you just add firewall port forwarding rules so your various vsp’s use of 5060 is remapped to the servers listening port, better yet use IP authentification. Even better , only allow traffic to named domains.

1 Like
9

Hi Dicko,

Thanks for your reply.

So if I use a port forward, say for example 12345 external to 5060 internal, this won’t have any effect on calls?

10

There is no requirement that SIP uses 5060. It can bind to any port (generally choose anything between 1025 and 63000 odd that is non conflicting). vsp’s that insist on using 5060 can be redirected to 12345 or whatever if you need to, but port and host can also be defined in the trunk definitions and registration strings if you use them. The theory is that if you only ‘pin hole’ udp/5060 to the minimum. Then most if not all ‘drive-bys’ will not see you. That usually means that your firewall will need a much less complex/possibly leaky set of rules

11

There is no best practice, regardless of port, that says you need to allow access to your SIP port from anywhere you don’t know about unless you allow people to connect to your PBX from random locations. You need to block access to your SIP port to EVERYONE and then allow extremely specific addresses access to that port.

One caveat: if you have people that connnect to your PBX from “random” locations (like the local McDonalds) or from phones that get new addresses every day. With these, using Dynamic DNS services, UCP, or VPN configurations are “better” practices, with VPN being the best.

There is no excuse to allow a SIP port to be visible to bad guys any more. There just isn’t. As a community, we have worked out at least four different ways to solve this problem for you - all you need to do is use the one that best suits your needs. To reiterate. there is no excuse for leaving your SIP ports open to the world. Pick a solution and set it up. Look at the FreePBX Wiki (under the Firewall entries for example) to get more information. If you still need more help, ask.

12

Strange because anonymous inbound calls via PJSIP are not allowed by default, anyway how about to increased security by using ACL (IP based allow/deny) and fail2ban?

13

Perhaps I can expand on my previous “possibly leaky” statement, any of Allow/deny/fail3ban/iptables are indeed “leaky”. That your system rejects them but doesn’t drop them unfortunately leaves a breadcrumb that the “investigator” now knows you provide SIP services, these guys are really not stupid, your IP addresses are collected and possibly sent to “second level” systems that are more aggressive . The concept that all and any ports CAN be compromised is indeed true, but in reality I have never seen SIP attacks outside 5000-5999. Quite reasonably, if you don’t respond on the major targets (5060 for asterisk et al but and increasingly 5080 for FreeSwitch and ironically a lot more on 5160 :slight_smile: ) then you cannot be but less exposed.

Absolutely, use firewalls as all sorts of ports are likely at least half-open 22,5038,8***,443, 3306 (aggressively nmap your box from outside if you don’t believe it, it is often used to provide a “fingerprint” of what you are likely running) but if you simply hide SIP and implement a rudimentary port-scanning policy your exposure is unsurprisingly a lot less ( and I mean a lot :wink: )

JM2CWAE and be mindful of probably not wanting to be an ostrich

14

I have never been a fan of using “non-standard” SIP ports as a primary method of “SIP security” but if it works it works. However, to think that probes happen in the 5XXX range is not entirely true as many regions around the world already block “external access” for SIP along the most common ranges. I’ve had customers in the past out of India, Iran, etc and those required me to have non-standard ports listening for SIP. Ports that in some cases where standards for other protocols. I’ve had to have 80, 443, etc all listening on SIP for these special cases because their regional firewalls let those through.

Honestly, in most business PBX deployments have a Deny All by default firewall and only letting what you need in is the best course of action. In some rare cases there are “remote” users and you might need to run some filtering/rate limiting to let them in but those are IBC’s for sure.

For someone like me that has end users connecting from all over US/Canada I took a little more pragmatic approach. I have customers that exist in one Regional Internal Registry, ARIN. I have no need to allow any access from the other four RIR’s so those are automatically blocked. Now all I have to do is deal with those within the ARIN ranges and that makes life a lot easier since they are more manageable and regulated. Case in point, my firewall caught someone in the same Data Center as me trying to hack my network. Whoever they were, no longer in my DC due to me filing complaints and logs.

Right now I got a system using these rules and in the last 75 days (since it was brought up) over 250K packets dropped from non-ARIN sources and over 100 ARIN ips dropped after they broke rules. In most cases they pretty much stop and move on once they start getting dropped constantly.

So really, security measures put into place should meet the requirements and need of your deployment. Since those are different for everybody some best practices are wise to follow but you’ll need to tweak it to meet your needs.

15

There is another function of Asterisk which also greatly improves security (but little used) if you use UDP/5060 (the target of 99.99% of the bad guys) .For chan_sip , just add

domain=your.dns.name
domain= 127.0.0.1 ;If you have t38modems or the like

to either

/etc/asterisk/sip_general_additional.conf

or in the gui to extra sip settings in the GUI.

For chan_pjsip, I’m sure there is an equivalency in your AOR setup to reject any IP based URI’s

That would trigger something like a message

[2018-12-29 12:41:12] NOTICE[13726] chan_sip.c: Registration from ‘“301” sip:301@yourip’ failed for ‘185.53.88.6:5616’ - Not a local domain

that a well configured fail2ban asterisk regex will capture and ban at iptables but even so Neither SIP REGISTER nor INVITES nor OPTION would be accepted nor processed.

This particular attacker is in Iceland, so RIPE, I will note that most of the Chinese Universities (also not stupid) have moved their attack servers to ARIN cloud servers, they are still there though

Just have your phones register to your dns name and not the IP. There are possibly some problems with some VSP’s requiring them to use names not IP’s but none of mine have a problem here.

(Watching sngrep is very informative as to WTF is going on)

2 Likes
16

Kind of an edit to the the last line of my previous post about sngrep.

So as not confuse, sngrep is like tcpdump, it runs on raw packet capture so will nicely show traffic before it hits iptables, this means that it will reveal ALL SIP like traffic arriving (and departing) on your internet interface (by default) so if the ‘Msgs’ column is greater then 1, then the traffic reached your VOIP server, INVITES and REGISTER packets will reveal the ip source address, but hopefully if your firewall is well constructed it wont get through iptables, current fail2ban asterisk jails will catch the “not local” and eventually ban them, adding the domain=your.dns.name should trip fail2ban , if your using older versions of fail2ban, such bans are “forgotten” on a restart so make sure fail2ban is current.

As a side note, many attackers are working in a cluster, so jailing the host is inefficient, they just use another IP address, I prefer to ban the entire underlying subnet , iptables can get very big , so look at using ipsets in your “deny” lists and look to a python script like ipwhois_cli.py available at

which derives the “route” from the ip address and add the result to you iptables drop list.

Be aware that that process is aggressive so the result of

ipwhois_cli.py --addr 68.14.211.4 --json 2>/dev/null |jq "[.entities[0],.objects[].contact.name][1],.network.cidr,.network.name",.null|tr '\n' '\t'|sed -e 's/null/\n/g'

would be

"Cox Communications Inc." "68.14.208.0/20" "NETBLK-PH-CBS-68-14-208-0"

Possibly a badly configured extension that got caught, but works very well for Palestine and other bad actors , many cloud providers like OVH should be considered as bad actors as no matter how much you complain, the culprits are never kicked out.

(you can install jq from most repos)

Of course most of this isn’t be necessary if you don’t use 5060 :wink:

I have scripted it (for csf), but I am not allowed to post bash scripts here.

JM2CWAE and IWFM

17

So, may I ask how many of those 250K+ well intercepted packets, ARIN or not, were directed to any port but udp/5060 and how many to anything but your servers IP address ?

18

Well all the servers I deal with are on public IPs so it’s 100% my servers IP that is being hit. As for how many are 5060 UDP, don’t know. Those places don’t need access to those servers for anything so I block them completely. There are other types of attacks to consider since these systems are generally full LAMP systems so why risk anything else being hit?

As for the ARIN based IPs, I’ve blocked over a hundred individual IPs in that time frame. Those are 100% on 5060 UDP because they get past the main firewall and I let my SIP firewalls/proxies deal with them. Since all my end users should be using FQDN’s one of my rules is to block any SIP request that has pure IPs in the From, To or RURI’s that alone has dropped most of those individual IPs which in turn reduces the amount of INVITE’s/REGISTER’s I get against the network.

Like I said, a lot of the real security measures that will need to be taken will be based on the individual needs of those implementing them. If every source IP is static, known and trusted then your firewall rules and measures are going to be different than those that have to let dynamic IPs in and thus open themselves up more to the world. Some may choose to use iptables alone and rate limiting others, like myself, employ proxies to help deal more granular levels of security.

Even my allowed IPs from end users or valid FQDNs still have User Agent validation, auth rates limits, call rate limits because a phone or PBX could be compromised at a location and sending requests from valid IPs, FQDN’s and the extra layers of checks are there as a safety net in case something like that was to happen.

But even with me, I have a few small providers I do this for and they each have their own business needs for their services/systems so while I re-use many of the core logic/structure it has to be tweaked for each network that it is being implemented on.

1 Like
19

Ah, so my posts were about not using 5060 which you are appaently not a fan of , you said

"As for how many are 5060 UDP, don’t know. "

Would that not be germane to this thread for you to glean that data , as would knowing whether the intrusions are directed to your IP or domain name?

as I suggested you can easily reject IP only traffic. Some say “the proof of the pudding is in the eating”, I invite you to taste it :slight_smile:

20

I think you are misunderstanding what I am saying. I have a network that is more than just Asterisk/FreePBX boxes. I have web servers, database servers, proxies, DNS, XMPP servers, SMTP Gateways, et al running on my network. As I have no end users or clients based in non-ARIN IP spaces, I don’t have any expectation or need for non-ARIN IPs to have any access to my network. So no, I cannot tell you how many non-ARIN IPs are hitting port 5060 over UDP because I’m flat out denying them to avoid any other issues or attacks to protect my network overall.

In regards to ARIN based IPs, I said I blocked over 100 IPs in the last couple months. Those IP’s where blocked by my system by hitting 5060 UDP and hitting me with IP based URIs. I have deeper checks if they get passed that but generally they do not because they aren’t trying to figure out the over 2 dozen FQDN’s I have in play (because the domains handle routing) they hit the IP. Since I’ve been running this network (few years now) I’ve had one instance where an attack and fraud attempts where made with valid FQDN’s on my network. That was due to the end user’s network being 100% compromised but my deeper checks alerted and stopped it.

I’ve been working at or with ITSP’s and LECs for 15+ years doing SIP for very large scale networks and users bases. In all those times we did not ever deploy the “use non-standard SIP ports” as a security measure. Did we see attempts over 5060 all the time, hell yes but proper firewall rules, SIP rules, etc do wonders to mitigate and manage those things.

I’ve dealt with this pudding and tasted it for a long time. So I’m well aware of what pudding recipes are bad and what can be good. As I keep saying, there are various ways to make the pudding and you have to give it the flavor layers that meet your tastes.