If I understand correctly, by default Asterisk uses port 5060 when dealing with SIP communications, and that’s why this port should be opened/redirected in IPTables/Router configuration. But my question is this: if my Asterisk only deals with Outbound calls (that is, I only want to make calls, but not to receive any call), is it mandatory (or at least, recommendable) to keep that port opened? I mean, since Asterisk is the one who will always initiate calls from inside my network/computer, do I really need to allow access to that port from the outside?
I’m asking this because I’m pretty tired of finding hackers trying to register into my system using that port, and although Fail2Ban + Strong passwords have manage the situation quite well, I would prefer to close that port if possible.
I have performed a basic test without opening that port and calls seem to be OK, but I don’t know if there will be any side effect when using this configuration in a real environment (calls dropped, bad sound…).
Yes, you still need a port opened - which by default, is 5060.
When Asterisk sends an INVITE request to establish an outbound call, the remote UA that receives the INVITE request has to notify Asterisk via a response that it is ringing, that it accepts the call, rejects it, etc. When it does so, it has to send that response back to an open port. That doesn’t have to be 5060, but it does mean that Asterisk has to be listening on something.
Scanners are, unfortunately, a fact of life in the VoIP world. While it doesn’t obviate the need for good security practices, having Asterisk bind to a port other than 5060 will dramatically lessen the spam you get from scanners.
No you don’t need port 5060 opened. Just change it to something else in sip.conf. It’s a bit inconvenient because then you have to change the default port on all your sip devices and trunks and firewalls. You can’t use alternate ports with IP authenticated trunks as far as I know. Should work fine with user/pass authenticated trunks.
So it’s a bit more hassle which is why most people don’t bother doing it.
Thanks for the answers, now I have a better idea of how this works.
However, during my test I found an interesting behaviour. I have the following IP Tables configuration:
Chain INPUT (policy DROP 4183 packets, 314K bytes)
pkts bytes target prot opt in out source destination
74 6156 ACCEPT all – lo * 0.0.0.0/0 0.0.0.0/0
102 23064 ACCEPT all – * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT udp – eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:10000:20000
11 492 ACCEPT icmp – eth0 * 192.168.0.0/21 0.0.0.0/0 state NEW icmp type 8
0 0 ACCEPT udp – eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT udp – * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:514
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 88 packets, 19573 bytes)
pkts bytes target prot opt in out source destination
As you can see, the default policy for INPUT packets is DROP and there is not an additional rule for port 5060 (I removed it for the test), however, calls work just fine. How is this possible? I noticed that if I remove the 10000-2000 port rule, calls are made but there is no sound (which makes sense since RTP uses that port range), but it seems like removing port 5060 rule has no effect.
P.D. Of course, I’m using port 5060 as SIP port. Maybe it’s because of the Established rule that it works?
You are probably establishing new connections from the server end so the RELATED, ESTABLISHED rule takes over after that. It’s not a proper configuration you can consistently rely on though. You must add a port 5060 rule.