Security is one of the major things to consider on each server. Therefore I’m happy to hear that you are thinking the same way as I do. But if you really want to have serious security, you should start at the very beginning and mustn’t open potentially unnecessary ports. I know, that’s primarily an asterisk part - but you are now working for the same company … .
This isn’t an idea option for anyone running a real PBX system. It doesn’t do anything but make a PJSIP transport “not listen” on the port. Which since you have your users and your trunks I can’t see where you would need a “non-listening” transport.
Also how did you come to the conclusion that the PJSIP listening port is unnecessary?
1 Like
@dirk2358 I think your edge case would lead to a lot of folks misconfiguring their systems thinking they don’t need the listener, whereas in almost every case except for maybe SIP Outbound you do need to be listening for return traffic… certainly if you are using UDP. Personally I would be quite against adding this configuration to FreePBX. Advanced configuration options available to Asterisk don’t need to be exposed in FreePBX.
Did you follow the link? There is an example explaining the use case for a non listening port.
Do you know, that for trunks, you are registering to, using tcp/tls e.g., you most probably don’t need any listener, because the complete communication is handled through the same ongoing connection, initiated by the client (asterisk) starting with the first Register to the ISP? This connection lasts until you do an unregister. Even Invites coming in are sent through this connection by the ISP - there isn’t any new connection opened. You don’t need any listener!
As of today, you are forced to use additional means to seal off this useless listener. From a security point of view, it’s the worst thing you can do.
Do you really think it’s more easy for users, who don’t know what they are doing to just open as much ports as possible? Yes, you’re right, it’s “working” - but on what terms? They have systems with useless open ports and some times later they are wondering why they are hacked … .
Most users stop their activities after something is “working” from their point of view - they don’t care why and how it’s working and what’s additionally “working” they don’t know and they have no idea about.
Security shouldn’t be relying on easiness. Easiness and security are most of the time contradictory.
As of today, it’s even impossible to use it in asterisk, because it’s not there.
This feature could be easily added to FreePBX (after it’s implemented in asterisk) in trunk configuration (it makes no sense in extension configuration). There should be additionally a suggestion telling the users, that they should use primarily TLS or at least TCP. UDP shouldn’t be used any more nowadays. You should drop ISPs not providing TLS for SIP.
In the present day this is an unrealistic requirement - maybe in 10 years. Also, what you are saying requires the PBX operator to use SIP registration. If you have a static IP you may not want to use registration, so I maintain that what you’re discussing is kind of an edge case.
3 Likes
Not to mention that all a registration does is give the other side a location to use so it knows where to send new requests. SIP registration doesnt mean an ongoing connection between the two sides.
You still need to be listening to receive inbound calls. As @billsimon pointed out this will only be viable for a use case with zero incoming requests to the server. Honestly, in those cases it can be solved at firewalls.
I was thinking this should be split off at a minimum to its own place
1 Like
There seems to be some oversimplification here. I can drop my server in a DMZ and that doesn’t make a difference. You aren’t going to leave port 88 open and suddenly someone is connecting via SSH. This isn’t leaving a window open in your house. If nothing is responding on a port then it is pointless. The only risk is if whatever is listening on that port has the ability to do bad things. So what is the risk of a pjsip port listening with nothing on it? Unless there is a CVE there is likely no risk. Most “hacks” these days are done by script kiddies and they use software that exploits known vulnerabilities. If your software is kept up to date and you are using sane practices there is very minimal risk
Minimal risk isn’t no risk, isn’t it? I don’t know of any software without (security) errors. As long as you don’t need a listener, you mustn’t open it - any other behavior at least is careless. If you need one - it’s ok. But not, if you don’t need one. There are use cases for both scenarios. From what I have seen so far, many people believe they would need a listener - but in fact, they really don’t need one. They just don’t know better.
There is no such thing as no risk. Even encased in concrete at the bottom of a volcano there is a non-zero risk.
Who uses trunk registration? I certain try to avoid it at all times, if at all possible.
2 Likes
Also, least we forget registration is a mechanism for inbound traffic. The only real use it has is to tell the other side where to send requests. Which means you are expecting incoming traffic so therefore you need to be listening.
1 Like
It’s ok if you don’t need it. Others need it because they have other use cases. You are not alone on this world. If you are using FreePBX to connect your private or even (not so) small business telephone system to your public ISP (trunk) or any other ISP, you most of the time need to register to their phone systems. You may read here just as one example of many.
Yes - that’s right. On base of your argumentation, I fear you and some others here just don’t know, too, how things can work based on tcp/tls registration.
Do you know the exact technical difference between an open listener port and an open connection between asterisk and the provider? I don’t think so - otherwise you wouldn’t argue like that. As I already wrote above: Using tcp/tls for registration, one connection is opened by the registering client and this connection is held until the client unregisters or the ISP drops this tcp/tls connection. All Requests go through this connection - regardless of direction. There is no other SIP traffic between you and ISP!
Maybe think about this connection like a static encrypted tunnel between you and your SIP ISP. All SIP traffic goes through this “tunnel”, regardless of direction and if it’s one call or many calls in parallel. All Option requests, Notifies, Updates, ReInvites, ReRegisters, … .
It would be way to resource-intensive or time consuming with TLS to always create a new connection (which would mean to always do the TCP and TLS handshake) for each request. There is a huge difference between udp and tcp/tls! And it’s pretty unsecure to do it like you and others describe it here on base of udp. Thank god, the developers of pjsip know there job and how SIP basically can work, too. Why do you think, they provide a client transport only? Because it’s not needed?
Saying, udp as base of SIP would last another 10 years - yes, because there are peoples ignoring security issues. I don’t know of any serious phone company not providing tcp/tls here - since years. UDP shouldn’t be used any more since 10 years or more.
Don’t misunderstand me - I don’t want to completely switch off the server transport - that’s not my goal, because there are scenarios you absolutely need it. But there are scenarios, too, where you don’t need any server functionality at all - that’s why asterisk and FreePBX must care about it to gain a lot more security and to get things more easy. It’s about time for asterisk and FreePBX, to comply with “modern” / actual requirements (since years).
No, we’re actually fearing that you don’t understand because so far everything you’re saying is showing that.
This is completely wrong, on many levels. REGISTRATION != INVITE. INVITE != REGISTRATION. These are two different things that don’t require each other. They also do not use the “same tunnel” for requests, transactions or dialogs. So let’s have a little school session now.
When you do SIP Registration the process is as follows:
- You send the REGISTER to the registrar server. There’s no auth data.
- The registrar sends back a 401 Unauthorized challenge (perhaps a 407 Proxy Authentication depending on their setup)
- You send back a new REGISTER (the CSeq increases by 1) this time with auth digest/data.
- They accept the register request, store the location data (IP/Port/transport) along with the Expiration time sent by you. If that Expiration is for 120 seconds, that’s how long the registrar will hold the location before expiring it. If a new REGISTER isn’t sent within that Expiration time, your location is removed and new incoming requests are no longer sent to the device.
At no point is there a continuous open connection like that with FTP or HTTP. The connection last as long as that above process needs to take place. With UDP its a bunch of connections as it’s fire/forget. With TCP that will be a single connection doing all that until completed. Afterwards there is no connection.
Yes, we all know that. You’re not telling us anything new.
Funny, you are saying UDP is insecure yet major providers still do it and those that do offer a TLS option charge more for it. Do you know why that is? Because TLS causes more resources to be used, it is more intensive that way. Each and every SIP packet needs to be decrypted in order to be processed and then replies have to be encrypted when sent back. Also considering that the PSTN is not 100% IP based carriers will also have to decrypt the TLS connection to send calls over the PSTN.
OK so PJSIP, itself, has been around for just as long as Asterisk or close to it. It is like many other SIP stacks out there meaning that multiple transport methods can be used. I’m not sure where you’re getting a “client side transport” as like anything else you need to configure what IPs, ports and transport methods you want to use.
What scenarios are you talking about? What scenarios don’t require any server functionality at all? Non IP scenarios? That sentence and what followed it does not make any sense at all.
Take a look at your Asterisk server when you have TLS endpoints connected. What he’s describing is exactly what they do: they start a TLS session with a SIP REGISTER request and then hold the socket open, which is later used in either direction to send requests.
Here’s a screenshot from mine (with IP addresses covered up, but you can get the idea).
OK, I stand corrected on that. Haven’t used TLS with registrations in years. Any TLS I do is IP based. @dirk2358 So you were right on that case, I apologize.
1 Like
What you are perfectly describing is the old fashioned method of doing SIP based on udp.
No SIP connection, but a tcp/tls connection. You have to distinguish those.
[2021-02-19 22:31:48] DEBUG[2963] pjproject: tlsc0x7f4cf03816a8 TLS client transport created
[2021-02-19 22:31:48] DEBUG[2963] pjproject: tlsc0x7f4cf03816a8 TLS transport 46.13.27.15:48663 is connecting to tel.t-online.de:5061...
[2021-02-19 22:31:48] DEBUG[2962] pjproject: tlsc0x7f4cf03816a8 TLS transport 46.13.27.15:48663 is connected to tel.t-online.de:5061
[2021-03-07 19:18:19] DEBUG[2962] pjproject: tlsc0x7f4cf03816a8 TLS connection closed
[2021-03-07 19:18:19] DEBUG[2962] pjproject: sip_transport.c Transport tlsc0x7f4cf03816a8 shutting down, force=0
[2021-03-07 19:18:25] DEBUG[2962] pjproject: tlsc0x7f4cf03816a8 TLS transport destroyed with reason 470006: EVP libThat’s an example call during this time (unfortunately doesn’t asterisk log the local IP and port in the trace - take a look at the rport reported by the provider and compare it to the above log from pjsip):
The end of the tcp/tls connection was because of an unregister of mine (pjsip send unregister trunkname). All SIP requests in the meantime are going through exactly this “tunnel”, regardless of direction. There is exactly one TCP and one TLS handshake at the beginning (starting with the first register - all reRegisters and ending with the unregister) - nothing more. You even don’t need qualify packages (Options) because of the existing “TLS ping” (~ 90s default). Therefore it’s even great for NAT usage.
If you don’t believe it: take a look at the source code of actual pjsip version - you will find it there.
Or at the moment (with one inbound running call):
# netstat -tulpn | grep asterisk
That's the listener for the internal phones, registering to asterisk (-> therefore a listener)
tcp 0 0 192.168.13.27:5060 0.0.0.0:* LISTEN 12836/asterisk
for RTP/RTCP (to lokal)
udp 0 0 192.168.6.170:10010 0.0.0.0:* 12836/asterisk
udp 0 0 192.168.6.170:10011 0.0.0.0:* 12836/asterisk
(to provider)
udp 0 0 192.168.6.170:10018 0.0.0.0:* 12836/asterisk
udp 0 0 192.168.6.170:10019 0.0.0.0:* 12836/asterisk
The static TLS-tunnels to the provider for the SIP traffic (I'm registering 4 different numbers)
# conntrack -L -o extended --src-nat 2>/dev/null| grep tcp | grep 217
ipv4 2 tcp 6 431939 ESTABLISHED src=192.168.13.27 dst=217.0.20.195 sport=35867 dport=5061 src=217.0.20.195 dst=59.18.10.10 sport=5061 dport=35867 [ASSURED] mark=0 use=1
ipv4 2 tcp 6 431939 ESTABLISHED src=192.168.13.27 dst=217.0.20.195 sport=35993 dport=5061 src=217.0.20.195 dst=59.18.10.10 sport=5061 dport=35993 [ASSURED] mark=0 use=1
ipv4 2 tcp 6 431939 ESTABLISHED src=192.168.13.27 dst=217.0.20.195 sport=52705 dport=5061 src=217.0.20.195 dst=59.18.10.10 sport=5061 dport=52705 [ASSURED] mark=0 use=2
ipv4 2 tcp 6 431939 ESTABLISHED src=192.168.13.27 dst=217.0.20.195 sport=46383 dport=5061 src=217.0.20.195 dst=59.18.10.10 sport=5061 dport=46383 [ASSURED] mark=0 use=1
For RTP of the stream from and to provider
# conntrack -L -o extended --src-nat 2>/dev/null| grep udp | grep 217
ipv4 2 udp 17 179 src=192.168.13.27 dst=217.0.135.5 sport=10018 dport=37510 src=217.0.135.5 dst=59.18.10.10 sport=37510 dport=10018 [ASSURED] mark=0 use=1
ipv4 2 udp 17 179 src=192.168.13.27 dst=217.0.135.5 sport=10019 dport=37511 src=217.0.135.5 dst=59.18.10.10 sport=37511 dport=10019 [ASSURED] mark=0 use=1Accepted!
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.