Tightening firewall while using TLS

I am trying to enable TLS on my endpoints.

I currently have a variety of iptables rules to drop scanners and such, like these:

-A INPUT -j LOG -p udp --dport 5060 -m string --string "sipvicious" --algo bm --log-prefix "SIP sipvicious received "
-A INPUT -j DROP -p udp --dport 5060 -m string --string "sipvicious" --algo bm

Since I will be opening up TCP ports 5060 and 5061 to the server (for TLS endpoints), do I need to make two more copies of these rules for tcp instead of udp, and port 5061? E.g.:

-A INPUT -j LOG -p tcp --dport 5060 -m string --string "sipvicious" --algo bm --log-prefix "SIP sipvicious received "
-A INPUT -j DROP -p tcp --dport 5060 -m string --string "sipvicious" --algo bm
-A INPUT -j LOG -p tcp --dport 5061 -m string --string "sipvicious" --algo bm --log-prefix "SIP sipvicious received "
-A INPUT -j DROP -p tcp --dport 5061 -m string --string "sipvicious" --algo bm

Also, is TCP port 5060 ever used, or is that always only UDP?

Thanks!

You will need to add rules for port 5060. Port 5061 is used for TLS, so the contents will already be encrypted at the point where the user agent would appear, so there is no point in trying to match it on port 5061. Theoretically, you could even get false positives.

TLS will prevent the iptables kernel module from reading the cleartext content of the packets.

The iptables rules covering TCP 5060 & 5061 are useless for any attempts to block/log based on the attempting to scan for cleartext strings within a TLS wrapped session.

See ya…

d.c.

Thanks, all – makes sense. @david551 – are you saying that I should have rules for both UDP and TCP on 5060? What is the scenario for TCP using 5060 – is that a thing that happens sometimes? (I always see it mentioned when people talk about firewall rules for asterisk but I’ve never understood when it might happen.) Or is it just UDP = 5060, TCP-over-TLS = 5061?

Is there any method within Asterisk for blocking the scanners? Asking since the scanners could connect over TLS on 5061 to do their scanning, right? It seems I can enable TLS for better endpoint security, but then I open myself up to scanners that can now evade the firewall via TLS.

Same question re: fail2ban – allowing TLS means it will also be less effective, since SIP attempts can be made under cover of TLS, right?

People do use TCP, because it can behave better in the face of complex NAT situations, and issues with fragmentation. Also to some extent because it isn’t currently attacked so much.

TLS is often not used fully on VoIP, because it is administratively difficult, but if you are in a position to use verify client and verify server it should give very strong protection. I’m not completely clear what those options check, on Asterisk, but if it is possible to check the signature, without checking that the subject matches, and you only enable an enterprise CA it should be possible to block everything outside your organisation. As I said, I’m not sure that Asterisk allows you to validate signatures but not check subject names.

(I think many people, including big company marketing people (who will outsource parts of their site but try to hide the fact) fail to understand that TLS requires authentication, to avoid man in the middle attacks.)

Thanks! – so if I understand you correctly, you’re saying that I could put a duplicate client cert on all the endpoints and enable a setting in asterisk to require a client cert, and then no strangers could successfully connect to TCP/TLS 5061 to try login/passwords ad infinitum. But you’re saying that asterisk verification might require that the “subject” of the cert match the actual source IP the endpoint is coming from, and if so, it won’t work (since different endpoints are in different locations). So this will only work if I can figure out how to have asterisk match the cert but not require the subject to also match. Do I have that right?

I assume “require_client_cert” and “verify_client” are the options in question… I’m not seeing any options to loosen up the verification re: the “subject” of the client cert, though… guess I can test it to see.

Alternately I could generate a custom client cert for every endpoint, and verification should should work, yeah? But if their IP ever changes it would break?

This is a small private PBX with no upstream VOIP provider – just phones calling each other within this little network, so verify_server doesn’t seem relevant – do I have that right? I assume that’s for verifying connections to upstream servers?

Having two options makes it more likely that one can verify the signer, but I’m still not certain of what verify client controls.

Thanks – and was I otherwise understanding you correctly?

IP addresses are not normally used as subject names. It is possible that they work, but that would have to be tested. I’m fairly sure browsers won’t use them, but SIP over TLS might be more forgiving.

Basically I think it is common to not validate clients and to rely on the client validating the server, and then use a password over an encrypted connection. That is almost the only way it is done in the web browser world, but TLS capable browsers all allow the installation of client certificates.

Thanks, that’s the direction I’m currently headed.

So the “subject” of the client cert would typically be a resolvable DNS name?

Replies inline…

Use IPTables rules to block the ports that are not using TLS. Cleartext SIP packets (i.e. non-TLS wrapped SIP packets) are the only packets that the IPTables kernel module can look into to try and find the “sipvious” string you use for detecting if it is a scan. But, the rule you are using only looks for sipvisious scans. It can be easily bypassed by the scanner simply by removing the “UA-Agent: sipvious” in the SIP packet.

fail2ban reads logfiles and journals generated by the running application (in this case, Asterisk). Since the failed authentication log message are generated by Asterisk, it does not matter if you are using TLS or not. fail2ban doesn’t look at the packets…only the logfiles generated by Asterisk.

See ya…

d.c.

Thanks, yeah, I am aware. Hopefully I still catch the ones lazy enough to not bother.

D’oh, right, of course, sorry for the brain lapse. :slight_smile: