Hello.
Last 4 days, my pbx is getting attention by brute forcers that spoof their source ip by using my pbx’s as source.
After inspecting a live attempt, the only way to catch original src ip is with sip trace.
Thing is Fail2Ban doesnt detect this.
Has anyone a solution on how to catch those kind of attempts??
Any help will be appreciated.
Is this a distribution installation? It seems to me that you aren’t actually seeing a spoofed IP, and as far as I know the IP level source address should appear in the security log, and that should be an input to fail2ban.
(The IP addresses in the SIP URIs in the request don’t have to reflect the source IP address, and I believe that some ITSPs require that they do not.)
no its not SNG distro.
Its FPBX14 Asterisk 13 on ubuntu system.
In the log i see :
chan_sip.c: Failed to authenticate device sip:[email protected];tag=1122624451
Where X.X.X.X is my pbx public IP.
While investigating sip debug it shows the true reply address of the attacker.
I think you are looking at the full log, not the security log. This might help: Working fail2ban for Asterisk (security log) – Klim Server Blog
Public IP? You’re behind a nat router? If so, it’s possible your router has been exploited or is otherwise allowing attacker to proxy thru it. There have been rare reports of this.
Nope im not behing a router. Its a hosted pbx with its own public IP.
Again no.
In the security log there were no similar occurencies.
I was on a daily monitoring and i saw the bruteforce. A typical bruteforce has the attackers address after the “@” – > sip:6000@attacker.(whether its public or local IP)
That was the odd thing. Only by SIP tracing i could see the original src-address of the attacker which i manually blocked .
It appears there are more incidents of this type of attack.
Anyone whos facing the same attacks, use sngrep bin so you can easily analyze sip debug logs and find the attackers source ip.
I can’t see why it wouldn’t be normal for an attacker. There is no reason why the From header should even contain an IP address, as against a domain name, and if you don’t want direct return calls (most SIP systems are configured to reject direct calls), there is no reason for the domain part to be valid, as most people will try to use the user part as a phone number, rather than as part of a fully fledged SIP URI.
In fact, it would seem that a large proportion of users, including FreePBX itself, configure Asterisk to ignore even contact and via headers, using options designed to cope with bad NAT setups, which send local addresses, instead.
It does look like, for some strange reason, chan_sip might only includes the address in the security log for INVITE and not for REGISTER, but chan_sip is no longer supported, anyway, so the correct solution is to upgrade. I also note that the version of Asterisk you are using is at least three months beyond full end of life (and Ubuntu are probably using an even older sub-version), so there will, almost certainly, be actual unpatched vulnerabilities, not just limitations to the reporting of successful defences. p->recv contains the address.
case SIP_INVITE:
res = handle_request_invite(p, req, addr, seqno, recount, e, nounlock);
if (res < 9) {
sip_report_security_event(NULL, &p->recv, p, req, res);
}
res = handle_request_register(p, req, addr, e);
sip_report_security_event(p->exten, NULL, p, req, res);
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.