A 'secret' domain name as a principal PBX security measure


#1

I agree 100% with @dicko – hiding behind a ‘secret’ domain name is virtually 100% effective at not only blocking random attackers, but also keeping them from learning that you even have a PBX. Random attempted attacks don’t get logged, so you can see important stuff and take it seriously.

I’ve been running a test system this way for several months. It intentionally has ports 80, 443 and 5060 open to the world. Fail2ban is not running. The logs do not contain any authentication failures or SIP identification failures at all, except for those caused by my own tests and mistakes.

IMO this is a very simple yet extremely powerful security technique and is is a real shame that the official FreePBX firewall does not include it.

Of course, it’s not a magic bullet. A competitor trying to steal your customer list or other trade secrets can probably learn the domain name easily, e.g. via phishing. A disgruntled employee or former employee already knows it. So, additional restrictions are needed for good security. However, keeping out all the random scanners with a few simple steps makes managing the system much easier.

You don’t need e.g. mypbx2473.com; mypbx2473.mydomain.com is sufficient. Assuming that you already have mydomain.com (for other aspects of your business), you get a letsencrypt cert and don’t have to purchase anything.

That is not quite true. Thanks to SNI, your computer passes xrobau.com as part of the handshake. If you try to connect to my IP address (or a name other than my PBX name that maps to my IP address), you get a dummy self-signed cert with no useful clues. You can’t see the real cert without knowing the name.


(Rob Thomas) #2

That is irrelevant, and is only really used for web servers. Your machine is accessible via public IP address. Whatever DNS records are pointing to that public IP address makes no difference.

Attackers do not scan by DNS. They scan by IP address. And the connection that is made to 1.2.3.4 is exactly the same, no matter if the attacker tries to connect to sip://1.2.3.4 or sip://xrobau.com

This is WORSE than security by obscurity. This is a fundamental misapprehension on how internet traffic works, and I’m shocked and amazed that people who should know better are trying to say this is not only POSSIBLE, but RECOMMENDED.

This is not a thing. Just like SIP over ICMP. Or Pepsi over Coax. This is not a thing. I don’t know how to make this any clearer.

Edit: Whoops, minor mistake - Kamailio DOES understand SNI. Nothing else does that I can see.


(Rob Thomas) #3

I don’t think I’ve made myself quite clear in the previous post:

This is WILDLY WRONG. Massively, terribly, and 100% incorrect.

Then you’re not logging correctly (edit: Or, you’re using the default firewall config of your OS, which is more likely)

It takes, on average, about 6 hours for a new sip server, appearing anywhere on the internet to start to get scanned. This has nothing to do with DNS, this has to do with many many attackers continuously scanning every IP address on the internet for devices responding on port 5060.

The longest it’s taken has been about 3 days, which was when I started advertising a /24 that had not been visible on the internet for more than 10 years, and put one SIP device on a random IP in the middle of that range.

So please. PLEASE. Stop spouting this. This is so fundamentally wrong that it scares me.


#4

Again and again and again 5060 comes up anywhere that anyone one with an intrusion problem has, how in any way is this “massively incorrect” to even suggest just plain not using it ?


#5

We were discussing TLS, as would be used to protect assets such as the FreePBX admin GUI, UCP and provisioning. SIP UDP is protected differently, with two iptables rules: one that accepts packets containing the domain name, and one that accepts ‘established’ and ‘related’ packets. See

Now, I admit that the TLS case would be vulnerable to an Apache bug that allowed an unauthenticated attacker to take over a dummy site that always returned a 403, or an iptables bug that allowed an attacker to bypass an arbitrary rule. However, such bugs would not be limited to PBXes and would affect all linux servers, perhaps 100 million machines, and would be quickly publicized and patched.


#6

In the UDP SIP case, packets not containing the domain name are dropped. Of course, running tcpdump or similar will show them. This was intentional; I can monitor how many attack packets arrive, from how many unique IPs, etc. There are far fewer than seen on systems using fail2ban.


(Tony Lewis) #7

Stewart

In your first post you said 5060 is wide open to the world and no attempts ever logged at authentication. This is why Rob said it was impossible. Now you change your stance and say 5060 Is locked to domain name and established connections. This is a big change from your stance above and of course would stop Asterisk from seeing the authentication attempts to IP since IPTables drops it. But that is not how you stated things were setup at first.


(Tony Lewis) #8

Dicko

Nothing in this thread says he is changing SIP port. He actually says he is still using 5060. I agree people should change to a random port and why years ago we made it easy in FreePBX to change SIP ports.


#9

Sorry that my ‘I hide everything behind a domain name’ was not clear. By ‘open to the world’, I simply meant that I can use a browser, SIP app or IP phone on any network in any country and access SIP, admin GUI, UCP and provisioning without making any settings changes.

Of course, my simple system assumes that no one is attacking me specifically.


(Tony Lewis) #10

Ok but that is not how it came across to me atleast and others I am sure.

Secondly you are still getting hack attempts on SIP but they are not making it to Asterisk. You are blocking them at IPTables so saying no attempts is incorrect. They are still attempting just logged in messages not Asterisk logs since IPTables is blocking it. Again wording is everything and how it comes across.


#11

And yet nobody does it, and then they run around like a headless chicken when the fox comes visiting. Go figure . . .


(Tom Ray) #12

Alright, let’s get into this. This idea that obfuscating your stuff with non-standards ports is the #1 method to stopping getting pwned is just word salad BS. Does it help? Sure it helps. Is it a 100% success, no not at all. Why? Because other ports are still scanned, may not be in the same level as the default ports but they are still scanned. So many people will go “Oh I changed my SIP ports to something non-standard so why did this happen?!” still.

Another thing to point out, every major carrier and provider use port 5060 and no domain setups, purely IP based connections. So are they getting hacked and pwned every which way till Sunday? No? Why? Oh yeah, security measures.

I’ll be honest, I got hit in July by fraud. Not by them compromising my systems but by someone compromising the Cisco SPA112 the user had. Just a little side note, for the first time in almost 3 years, the Cisco SPA112 has had two releases for firmware this year alone to fix to security holes that can give sensitive information to the hacker.

So now they had proper user/password, oh and they had the DOMAIN because I use FQDNs for everything. Luckily, I had other levels of checks and only some of it got through. Right there highlights how your network could be compromised without them touching your network. They got everything they needed.

And as much as we are going on about the PBX/server side, how many times do you get calls from your customers about strange calls (sometimes from themselves because they are that extension) that have no one on the other side and just keep calling them. Oh yeah, that’s the location being SIP scanned through freaking NAT. So now you have to deal with the fact your end users could have really crapping routers/firewalls, they may have horrible NAT rules and of course their devices are most likely listening on 5060 for the main line.

So you can sit there and lock down your network all you want, if you don’t account for your end users security (or lack of it) then you’re just leaving yourself open still. Because it’s never the large customers I see a problem from or weird attempts from. It’s always those little one line Resi/SOHO accounts that have ATA’s or a single IP phone with no actual network and just plug into the ISP’s modem/router combo.

Just to recap:

— Changing standard ports. Workable solution. Must be used with others to be fully effective.
— Using FQDN’s vs straight IPs. Workable solution. Should be used with others.
— Using TLS. Workable. A huge resource hog for a red herring since the PSTN doesn’t have TLS and it would require all the calls to be decyrpted/encrypted constantly. Again, not a lone solution.

Those three things are great when used together and with other things. Using them just alone is still leaving you open because none of those take into account what I pointed out earlier. Your end users being pwned on their side. So while those steps are great to block those that have no real clue on how requests should be formatted for your network, once they get your end users details they have exactly how the request should be formed.

You still need extra layers to account for when valid users are compromised and their information is being used. I still have flooding and tracking for how many INVITEs, REGISTERs, etc are being sent in X amount of time. I still have rules about what source IPs can actually connect to the network.

I also have various multi-factor auth methods. Such as, they can lock down requests to only be accepted from the end users IP plus auth creds. Since 99% of the compromises are straight up calls (they don’t register because that gives them away) so they must have a valid registration in order to make calls. Or they have to have a valid registration, it must come from their allowed source IP AND must still auth.

Much like an onion your security should have many layers.


(TheJames) #13

The only way to be 100% secure is to turn off your server, put it in an incinerator. This for most is expensive and not practical.

Security through obscurity typically only deters script kiddies and generic attacks. It will NOT do anything for a focused attack. If someone can in any manor fingerprint your system they can then port scan and apply a focused attack. You can only follow best practices and keep an eye on things.

Don’t expose your system to the public network.

  • This can be impractical as well.
  • This does NOT protect you from “internal” threats

If you MUST have your system on a public network only expose the minimum number of ports needed and only to a whitelist. For remote workers use a VPN. Note using a VPN could also expose you to attacks. ALL software has bugs. The more popular the application, the more eyes looking to compromise it.

Use strong passwords. No matter what your bank says, your password is probably not as strong as you think it is.

Use a password manager, don’t reuse passwords, change them often.

No matter how secure YOU are the upstream provider may also be an attack vector. If I get access to your upstream service by way of password or other means even turning your server in to a pile of molten metal doesn’t keep you secure.


#14

Oops, I just discovered that the domain name format I had been recommending (pbx2473.mydomain.com), once the bad guys catch on, would provide no security at all! See
https://medium.com/@linasvaliukas/by-the-way-the-list-of-ssl-tls-certificates-issued-to-you-including-subdomains-is-public-5537ef1f11f5

I’m not yet sure what to suggest as a substitute. A wildcard cert e.g. *.mydomain.com is bad news – if the PBX did get hacked and the cert stolen, the attacker could cause a lot of damage unrelated to phones.

*.pbx.mydomain.com would work, but that advertises that you have a PBX; even though the attacker wouldn’t be able to discover the secret name, there might be another vulnerability he could exploit.

*.zzxgwq.mydomain.com seems ok, but a legitimate user might get it wrong, e.g. when trying to access UCP from his browser.

*.zzxgwq.com is a bit easier, though that’s another domain to purchase and administer.


(Tom Ray) #18

It’s also against RFC standards. No *.domain.com should be used. It should always be exact.


#19

Well,its not as bad as it sounds, public records are just that, much like your driving record or any criminal record ,

crt.sh itself does not support wild card lookups so they would have to guess your exact domain first, then they would then have much the same info they already had under the https:// bit on your address bar and it would divulge it if it was a wildcard issue. now its true that RFC6125 disccourages its use but it does accept its existance and does not dis-allow its use and if you have many domains it makes it just a tad easier but with caveats given everywhere as to why you shouldnt use them

Personally I use acme.sh and DNS01 method, its nicely automated into systemd on installation (mostly set it and forget it) and if using DO or many other registrar/DNS services that have an API to create txt records, it WILL negotiate a wild card cert from lets-encrypt but it will equally handle dozens or more subdomains with alacrity. Adding a new subdomain becomes trivial. It doesn’t even have to physically or virtually exist yet.

A very deep diving checker at

https://www.ssllabs.com/ssltest/analyze.html

and add a DNS CAA record.

JM2CWAE


#20

It just suddenly dawned on me, If anyone thinks that TLS certification is for YOUR protection, it is NOT, it is to protect the rest of the world from YOU :wink: ) You will still need .htaccess , perhaps fail2ban apache-noscript and anything else that works for you to keep you comfy at night. . . .


(system) closed #21

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.