I think the responsive firewall is not working as it should. I see thousands of lines in the log, all day long. It should be rate limiting the attacks and then blocking it but it does not look like it’s doing that. I have opened a ticket as well.
[2016-12-13 15:01:06] NOTICE[5875] chan_sip.c: Registration from ‘100 sip:[email protected]’ failed for ‘85.25.207.74:60164’ - Wrong password
[2016-12-13 15:01:16] NOTICE[5875] chan_sip.c: Registration from ‘100 sip:[email protected]’ failed for ‘85.25.207.74:45594’ - Wrong password
…
[2016-12-13 18:13:01] NOTICE[5875] chan_sip.c: Registration from ‘01234 sip:[email protected]’ failed for ‘85.25.207.74:45882’ - Wrong password
[2016-12-13 18:13:08] NOTICE[5875] chan_sip.c: Registration from ‘01234 sip:[email protected]’ failed for ‘85.25.207.74:39041’ - Wrong password
I see 834 failed registration attempts over the course of 3 hours. Maybe the threshold could be tweaked a bit?
According to the documentation, the responsive firewall is supposed to allow only a very “limited” amount of registration attempts before rate limiting starts. I think remote endpoints would still be able to register if the threshold is a bit more conservative.
In that case responsive firewall isn’t in effect. At a guess it’s because you have SIP or PJSIP available to ‘External’, or, the interface the attacker is arriving on is treating traffic as ‘Trusted’.
Edit: I think I’m going to remove the ability for people to allow SIP, PJSIP, or IAX access to ‘External’. If they REALLY want to allow unfiltered access to those protocols, they’ll have to create a custom rule to do so.
I wish it was that simple. PJSIP is not enabled at all. CHAN_SIP is not set to external and only managed by the responsive firewall. The system interface is set external and the attacker IP(s) are not defined anywhere in the firewall (see screenshots). Maybe it is below the threshold?
Hi, pardon me for injecting here - but how about implementing - in the Responsive Firewall but, with some Asterisk interaction - a kind of ‘tarpit’ procedure?
I know ‘normal’ tarpit is at TCP protocol level, and SIP is (most of the time) UDP; that’s why some Asterisk-level interaction is required;
(for those actually using SIP/TCP, the below could be actually replaced with TCP tarpit target in firewall itself)
For those using UDP protocol, maybe even worth starting up another, bare as possible, jailed Asterisk instance, with some special dialplan, all that it would do is ask the attackers to wait (inject as many and as long delays into the SIP dialogue as technically possible) - and then the responsive firewall would only redirect the packets to and from the tarpit when the scan is recognized;
Or if possible to integrate into same Asterisk instance, maybe some special context / dialplan behavior for those found in a list fed by the responsive firewall?
(the wikipedia article https://en.wikipedia.org/wiki/Tarpit_(networking) contains a cool description of how the SMTP tarpit works - maybe the ‘special’ Asterisk instance could be really tasked with nothing else but doing something similar, and be ‘sandboxed’, have no ‘disk writing’ rights etc. )
I just think the threshold parameters should be much more aggressive. The idea behind the responsive firewall is to allow VALID remote endpoints to register with the PBX. That means they must have correct authentication. They would not be scanning the system as such, fishing for a passcode.
So … what you wrote does not directly contradict what I wrote (in fact makes the SIP TARPIT idea more attractive) : if they do as you wrote (scan and try to fish for passcode) - let them believe they succeeded, but only send them delay packets with random timeouts, until they back off or realize the error of their ways, without allocating any real resources of the server to serve these - but taking a lot of resources of the attacker(s) ?
