Is there a way to log connect attempts that fail the TLS handshake?
Had one box getting hit pretty hard. Other measures eventually blocked, but the asterisk logs were silent.
Probably missing something obvious and will feel foolish.
I do that by proxying TLS (and http(s)) , the proxy server logs the traffic .
Thought that would be your answer.
You may make a convert of me yet, but asterisk probably should make failed attempts visible in the logs.
I prefer that failed attempts never get through in the first place, that way you wont need to see them 
(or filter them or ban them.)
1 Like
I get errors like these in my full log:
[2021-04-11 10:14:00] WARNING[21315] pjproject: SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <336151570> <SSL routines-ssl3_read_bytes-sslv3 alert bad certificate> len: 0
Looks like warning level should catch them.
and pretty sure these are from port probes:
[2021-04-13 07:08:53] WARNING[21315] pjproject: SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <336130315> <SSL routines-ssl3_get_record-wrong version number> len: 0
[2021-04-13 07:08:53] WARNING[21315] pjproject: SSL 6 [SSL_ERROR_ZERO_RETURN] (Read) ret: 0 len: 32000
Not everyone will run a proxy.
The Distro firewall should handle these pretty well, but anyone port forwarding at the edge and expecting fail2ban to kick on bad attempts will be disappointed.
Probably “mostly harmless,” but I could see DoS potential.
Yeah, I got those as well, but nothing that is fail2ban friendly. Adding a source IP would be nice.
Not a big deal for our ruleset, I had looked into it briefly way-back-when but moved on. Recent activity brought it up again.
hehe, apparently nobody will even bother trying to.
opensips + rtpengine will get you a SIP and RTP proxy that will also act as terminator of both the TLS and the SRTP encryption, which is particularly nice if you want to do RTP-capture-based recording within your network.
mostly I don’t need to proxy the (s)rtp traffic as yet , my primary interest is to only allow legitimately certified traffic and dropping without leaking anything of interest, any ip based connection attempts or asking for the wrong certificate on the wrong port.
I believe we are all looking for prophylaxis, it’s at what point in the chain we choose to apply it. I also believe that earlier is more efficient and less likely to open down-line frailties . fail2ban works better with current versions but still needs well constructed regexes yet even then is retroactive with a high latency .
If you are following along, you can get a domain for less than $5 a year for your provisioning and TLS certs from
https://www.namecheap.com/domains/registration/gtld/cyou/
and domain names can be 64 character long.
I agree, but for now hits on the port are not at the threshold it’s worth adding the additional application.
But I will go ahead and set a box or two up to start testing.
Want to write it up?
I pm’d you
edit: hmm, at least I thought I had.
when I get home I will.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.