Shouldn’t those SIP invites be blocked by the firewall in front of the phone?
All depends on your firewall. Your phone pokes a hole through firewall to talk with the PBX and they are coming through the poked hole.
But the hole should only let traffic through that’s coming from the public IP of my server.
The IP addresses those invites are coming from are not known to us.
Yes I would think so but that is a question for your firewall manufacture.
Hi!
So it doesn’t access port 5060 or has it opened through/from the Internet?
What firewall (or firewalls) are you using?
It sounds like they are directly contacting your phone…
There’s one thing I don’t get here, it sounds like the phone is directly accessing port 5060 (and opening a hole back to it in the firewall) but isn’t it supposed to access your PBX through OpenVPN so why should it do that?
Sounds like you have the same problem that is described here:
(Crappy firewalls which open holes back to them when they access an outside server without restricting the traffic to only the IP of the server they contacted…)
They probably don’t know that they are accessing a phone and are simply trying to do toll fraud…
Good luck and have a nice day!
Nick
Surely a well formed software firewal/IDS would trap such attempts that penetrate the hardware “crappy firewall”, what are you using for that?
Dicko, is there anything he can use (software-wise) if the fraudster is trying to hack the phone (not knowing it is one) and not the PBX?
There’s one thing I don’t get if the phone is indeed the target… If he is using a VPN to communicate between the phone and the PBX then no hole for port 5060 should be opened, no???
Have a nice day!
Nick
Well the obvious solution for this is to NEVER listen on UDP/5060 for connections. there will be then a little more than a (muchlessthan1)/64000 chance they will get through, 5000-6000 should never be used as the scripts scan all those ports, for recalcitrant VSP’s you can firewall/pnat a solution. and you should be in control of your external endpoints as to port to use.
Your firewall/IDS should have a VERY rigorous port scan policy, there is no reason to accept more than one failed attempt except for dumbshit users.fumblefingereing (ok, make that 5), and never more than one port attempt, if that is noticed, then send them to the bitbucket
The phone talks to the server on port 5060, but not via port forwarding on the firewall that sits in front of the PBX.
The phone connects to the PBX network via VPN.
My PBX is behind a NAT firewall, port 5060 is open, but not for the purpose of remote phones connecting, but for SIP trunk providers and other SIP trunks to remote offices. Those IP addresses are whitelisted, so port 5060 is not wide open to the public internet.
Vanilla OpenBSD, which is pf.conf
Yes, I am guessing that the remote phone is behind a crappy firewall.
Don’t know which one it is, might be a Verizon Mifi device.
Thanks for the link, that’s exactly my problem.
It’s a Yealink phone and I will enable “Accept Sip Trust Server Only” option.
Again, only open 5060 for your dumb VSP. If they can’t/won’t change it , you can then Masquerade their particular IP connections on UPD/5060 to an internal safer UDP port that you users will use otherwise for all your other trusted endpoints, which you can cautiously open to all comers
It is a single/very-few rules in your firewall to do that
Correct. Port 5060 is not opened for that purpose, but for another one. But that’s on my OpenBSD firewall in front of my PBX, which is no contributing to the because the bad SIP invites are not coming trough that firewall. It’s indeed a problem with the firewall where the remote phone is. I don’t know what device it is.
Still, changing the SIP port in general is a good idea as Dicko is suggesting. I will look into that.
In My Humble Opinion, If you ever open UDP/5060 EVER on any interface , you are just asking for trouble, why in god’s world does nobody here understand this?
Just look at all the attempts on your tcp/22 if you are not a wise virgin there will be hundreds, exactly the same applies to SIP/5XXX
Even if it’s only open to trusted IP addresses?
Why do you trust those, in this case that connection has obviously already been penetrated by other actors.
Again you guys , what is this fetish with wanting to use 5060? It is bad “mojo” because every one in China, Palastine .Eastern Europe knows that they can F*&K you there
Not in my case above.
The problem is with the firewall in front of the remote phone, which doesn’t have any ports open at all, but still seems to let undesired traffic through. I do not control that device, it’s some consumer grade home firewall, the standard thing a residential user would get from his ISP.
My OpenBSD firewall protecting my PBX is fine. No bad traffic coming through there. That is where I have UDP/5060 open to Vitelity’s IP addresses.
Then if you don’t have a problem there do the ostrich thing
There’s something that doesn’t add up…
If this connect through VPN then the port should not be opened…
Could that firewall where the phone is have some sort of SIP helper/alg on that might open that port by default (but there’s still the problem of having the traffic routed to the phone…) or is the phone in a (home router definition of a) DMZ?
Why would the port be opened and the traffic routed to the phone if the phone doesn’t actually talk directly to the Internet?
We are talking home router here with most likely multiple devices being NATed behind the same address and apparently no port implicitly forwarded…
Good luck and have a nice day!
Nick
Cause that is where all SIP service providers in the world want to send their traffic to.
There is just some confusion going on.
No port on the firewall where the phone is is open.
It’s just a standard consumer level device, that is apparently doing something it shouldn’t do, which is what a user in the thread you linked to describes as:
“When the phone communicates to the outside the cheap firewall is opening 5060 to the outside and allowing any traffic back in rather than limiting the traffic to only from the single destination.”