Fail2Ban and unauthorized invites

Asterisk Asterisk Support
1

Someone is trying to place calls from my Asterisk box. They are trying to brute-force extensions.

Example log:

[code]<— SIP read from UDP:155.94.64.250:5078 —>
INVITE sip:999900972595183136@MY_ASTERISK SIP/2.0
To: 999900972595183136sip:999900972595183136@MY_ASTERISK
From: 100sip:100@MY_ASTERISK;tag=5e3e6e24
Via: SIP/2.0/UDP 155.94.64.250:5078;branch=z9hG4bK-8bbc1963772ea7d4e0e9b53028509008;rport
Call-ID: 8bbc1963772ea7d4e0e9b53028509008
CSeq: 1 INVITE
Contact: sip:100@155.94.64.250:5078
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, BYE
User-Agent: sipcli/v1.8
Content-Type: application/sdp
Content-Length: 283

v=0
o=sipcli-Session 1486506575 1460040688 IN IP4 155.94.64.250
s=sipcli
c=IN IP4 155.94.64.250
t=0 0
m=audio 5079 RTP/AVP 18 0 8 101
a=fmtp:101 0-15
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=sendrecv
<------------->
— (12 headers 13 lines) —
Sending to 155.94.64.250:5078 (no NAT)
Sending to 155.94.64.250:5078 (no NAT)
Using INVITE request as basis request - 8bbc1963772ea7d4e0e9b53028509008
No matching peer for ‘100’ from ‘155.94.64.250:5078’

<— Reliably Transmitting (no NAT) to 155.94.64.250:5078 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 155.94.64.250:5078;branch=z9hG4bK-8bbc1963772ea7d4e0e9b53028509008;received=155.94.64.250;rport=5078
From: 100sip:100@MY_ASTERISK;tag=5e3e6e24
To: 999900972595183136sip:999900972595183136@MY_ASTERISK;tag=as74036dec
Call-ID: 8bbc1963772ea7d4e0e9b53028509008
CSeq: 1 INVITE
Server: Asterisk PBX 11.16.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“MY_ASTERISK”, nonce="7ca35cf2"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘8bbc1963772ea7d4e0e9b53028509008’ in 32000 ms (Method: INVITE)
Retransmitting #1 (no NAT) to 155.94.64.250:5078:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 155.94.64.250:5078;branch=z9hG4bK-8bbc1963772ea7d4e0e9b53028509008;received=155.94.64.250;rport=5078
From: 100sip:100@MY_ASTERISK;tag=5e3e6e24
To: 999900972595183136sip:999900972595183136@MY_ASTERISK;tag=as74036dec
Call-ID: 8bbc1963772ea7d4e0e9b53028509008
CSeq: 1 INVITE
Server: Asterisk PBX 11.16.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“MY_ASTERISK”, nonce="7ca35cf2"
Content-Length: 0[/code]

However, this does not get logged very well in security/notice/warning. Best I can see is this:

[code]SECURITY[3465] res_security_log.c: SecurityEvent=“ChallengeSent”,EventTV=“1431085132-271760”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID=“sip:100@MY_ASTERISK”,SessionID=“0x7ff2c8030a78”,LocalAddress=“IPV4/UDP/MY_ASTERISK/5060”,RemoteAddress=“IPV4/UDP/155.94.64.250/5071”,Challenge=“54fbbac8”

WARNING[3853] chan_sip.c: Timeout on 00c515da631bbb644a6c5c056dcb0f8c on non-critical invite transaction.
[/code]

How would I go about catching IP (and others to come) automatically with Fail2Ban? Thanks for any help in advance.

2

Sorry I can’t answer your question, I’m posting more details as I was about to post the same. However, I’m posting part of log instead. There is nothing in there for fail2ban to “grab” on. Wonder if anyone know what it is and how to get it stopped…

I’m about to give up here and instead create “white” list on router/firewall

[2015-05-16 21:56:49] WARNING[2645] chan_sip.c: Timeout on be4213423f7329e7a8a8357aeadb3d18 on non-critical invite transaction. [2015-05-16 21:57:05] WARNING[2645] chan_sip.c: Timeout on 11b22eb2b49ca8a20e356b67a6d5e92b on non-critical invite transaction. [2015-05-16 21:57:07] WARNING[2645] chan_sip.c: Timeout on 3bbd4df9308b25e81e102d6079c33ab9 on non-critical invite transaction. [2015-05-16 21:57:21] SECURITY[2650] res_security_log.c: SecurityEvent="ChallengeSent",EventTV="2015-05-16T21:57:21.447-0500",Severity="Informational",Service="SIP",EventVersion="1",AccountID="sip:as100@x.x.x.n",SessionID="0x7ff25c024938",LocalAddress="IPV4/UDP/23.114.87.129/5060",RemoteAddress="IPV4/UDP/23.92.80.40/5074",Challenge="25e290f7" [2015-05-16 21:57:53] WARNING[2645] chan_sip.c: Timeout on 3b5ddc8db0fcc31cc10708770fc32a83 on non-critical invite transaction. [2015-05-16 22:11:33] SECURITY[2650] res_security_log.c: SecurityEvent="ChallengeSent",EventTV="2015-05-16T22:11:33.126-0500",Severity="Informational",Service="SIP",EventVersion="1",AccountID="sip:2101@x.x.x.n",SessionID="0x7ff25c024938",LocalAddress="IPV4/UDP/x.x.x.n/5060",RemoteAddress="IPV4/UDP/155.94.64.74/5070",Challenge="231916ec" [2015-05-16 22:12:05] WARNING[2645] chan_sip.c: Timeout on cbf29b7ea945d88c87b99be74f069f66 on non-critical invite transaction. [2015-05-16 22:15:38] SECURITY[2650] res_security_log.c: SecurityEvent="ChallengeSent",EventTV="2015-05-16T22:15:38.812-0500",Severity="Informational",Service="SIP",EventVersion="1",AccountID="sip:6001@x.x.x.n",SessionID="0x7ff25c024938",LocalAddress="IPV4/UDP/x.x.x.n/5060",RemoteAddress="IPV4/UDP/192.111.149.58/5079",Challenge="039fe0a5" [2015-05-16 22:16:10] WARNING[2645] chan_sip.c: Timeout on 195bb63382d8b9a5e124d7541f2aa947 on non-critical invite transaction. [2015-05-16 22:18:42] SECURITY[2650] res_security_log.c: SecurityEvent="ChallengeSent",EventTV="2015-05-16T22:18:42.885-0500",Severity="Informational",Service="SIP",EventVersion="1",AccountID="sip:6001@x.x.x.n",SessionID="0x7ff25c024938",LocalAddress="IPV4/UDP/x.x.x.n/5060",RemoteAddress="IPV4/UDP/192.111.149.58/5078",Challenge="676db5ea" [2015-05-16 22:19:14] WARNING[2645] chan_sip.c: Timeout on 955c75e6742c410cf089c0ccaf414d87 on non-critical invite transaction. [2015-05-16 22:21:54] SECURITY[2650] res_security_log.c: SecurityEvent="ChallengeSent",EventTV="2015-05-16T22:21:54.243-0500",Severity="Informational",Service="SIP",EventVersion="1",AccountID="sip:6001@x.x.x.n",SessionID="0x7ff25c024938",LocalAddress="IPV4/UDP/x.x.x.n/5060",RemoteAddress="IPV4/UDP/192.111.149.58/5087",Challenge="4a795df6" [2015-05-16 22:22:26] WARNING[2645] chan_sip.c: Timeout on 44c5d6c9a81dedc5831761d0ee5402bc on non-critical invite transaction.

3

RemoteAddress field isn’t?

4

I suspect the problem is that 401s are normal, so it would end up blocking local users. If you know the addresses that can legitimately try to authenticate, you don’t need fail2ban, as you can configure the firewall to block all others.

If this is an attack, he needs fail2ban to detect 401s that are not followed up by a valid authentication.

However, it seems strange to me that anyone would hack without going through to the password stage, or at least the ACK stage, so I think it is more likely that there is a misconfigured system somewhere and he should be trying to inform the sender of their problem.

The non-standard port number may be why the dialogue never completes. If you really want to let fail2ban learn this, opening the firewall to any outbound destination port may allow the dialogue to get as far as the invalid password. If he actually needs fail2ban, it seems strange that he would restrict replay ports, as the port number for remote user phones is very unlikely to come in as 5060. He should know the address range for his ITSP, so, if he doesn’t have remote users, he should simply be dropping all addresses outside that range and forgetting fail2ban.

5

fail2ban wont help you in this case… It doesnt provide any protection against unauthorized invites. It just blocks IP address after X amount of failed register request, a better suggestion would be disable allowguest calls on your sip.conf file, iptables and other security practices

this document has some useful information xorcom.com/files/mktgdocs/pr … ebinar.pdf

6

If these are invites they are not guest ones as Asterisk is challenging for authentication. In any case, I would hope that f2b could be made to recognize an authentication failure on an invite. I thought it just pattern matched the log files.

7

But where is failure? There is no record of this in Asterisk log. Maybe those “Timout on non-critical…” messages relate to those? Maybe they need to be expanded little bit further?

I doubt f2b will ever be able to do any logic on multi-lines. As you said it is just pattern matching lines. It only looks at time and “match/not match”. There is no way to build logic like “every invite record should have follow up auth record”.

In my case (I’m not OP) - I can allow traffic to known IP’s only, but they change time to time and it will be PITA. If I decide that people can use soft phones remotely - it is not possible to close it on firewall. Maybe VPN? But I’m not sure if VOIP traffic over VPN is a good idea.

8

There is no authentication failure because things break down before the authentication is attempted. That is not because it is an invite, rather than a register. (You can register without a password.)

It is not clear whether the timeouts are the result of a misconfiguration or an attacker cutting their losses when they find there is a password. I think most attackers do try common passwords, so I think it is more likely that there is a misconfiguration.

9

Where do you think misconfiguration happen? On other side? Because those request pretty regular and come from many different IP’s. Hard to believe there is dozens of misconfigured systems magically found my public IP

My system is pretty “virgin” in a way that I control all clients and I can disable/disconnect all and observe this behavior. So, I’m pretty sure those timeouts tied in to those invites. I think if we had more info (like source remote IP) on those timeouts - we could eliminate those attackers.

10

If you are getting them from multiple addresses, I would suggest that you don’t have a valid return route to them, so they never see the 401 and don’t continue with the password attempt.

11

Can you explain what “no return route” means? Maybe it’s related to the problem I have with Cisco phone (another topic)? On a router SIP ALG disabled. But there might be something else I’m not aware of. Just need some pointers so my network guy can take a look at router.

Cisco phone in another topic randomly connects for the short periods of time. And there is no system to it… As far as Asterisk and phone - I think I tried all settings I can and variations of them.

12

The attacker is sending INVITE from a particular address. You are sending 401 back to that address. By no return route, I mean that there is no way for the response packet to reach that address.

(As the attacker never sees the 401, they do not know how to authenticate, and, in particular, don’t know the value of the random challenge used, so they are unable to continue and try a password.)

If you have no return route to a valid SIP client, you should see as series of repeats of the INVITE at increasing intervals until the client gives up. You should not see an ACK. You might get the no replay to critical response message. Again, if the client is authenticated it will stall at the 401 stage.

13

I didn’t have time to deal with this for a while.

It does seem that there’s some kind of misconfiguration on my part. Using netcat from my Asterisk box, I can’t establish a connection to the attacker. Using netcat from my own machine, it works. Iptables is not the case here; there’s some DNS magic going on for some reason.

The system works fine otherwise (10 peers calling daily). Guess I’ll fix this and hopefully the attackers will start trying some passwords and eventually get banned.

14

If you are using Asterisk10+, you can activate “security” logger in asterisk and point fail2ban to that log file. Security log logs those unauthorized invites.

15

If you lockout on unauthorised INVITEs you won’t be able to log legitimate phones into the system.

16

I’ve found a solution!
it’s not best - but at least it works for this case.

we can capture IP from by this line:

[color=#4000FF]o=sipcli-Session 1486506575 1460040688 IN IP4 155.94.64.250[/color]

For that, add a pattern ( failregex ) to fail2ban filter.d/asterisk.conf:

[size=85]( I would recomend adding separate fail2ban filter (lets say asterisk-sipcli.conf ), and define fail2ban to block the remote IP atonce after first attempt , since we do not want to answer anything to sipcli , right ? )[/size]

Enable sip debug in /etc/asterisk/sip.conf :

reload asterisk, and make sure sip debug messages are generated to /var/log/asterisk/full (or where you have your logs configured)

optionally, add log rotation to avoid out of disk space issue (SIP debug generates tons of output)
add file /etc/logrotate.d/asterisk with text:

/var/log/asterisk/full /var/log/asterisk/debug /var/log/asterisk/messages /var/log/asterisk/*log { missingok rotate 10 notifempty daily size 1000k create 0640 asterisk asterisk postrotate /usr/sbin/asterisk -rx 'logger reload' > /dev/null 2> /dev/null endscript }

also, configure fial2ban to send even emails to keep track of the situation,
I have 3-5 banned IP every day on asterisk!

if anyone need tech support regarding asterisk security issues and fail2ban setup,
contact me directly by mail: george dog a4business.com

17

Returning again to question: “How to block sipcli scaner on my asterisk” …

Fail2ban requires formatted date-time on the log line beginning, which actually is missed in SIP debug log message. And was getting in fail2ban.log message :

"Found a match for u'o=sipcli-Session 967920817 590946010 IN IP4 37.157.241.124' but no valid date/time found for u'o=sipcli-Session 967920817 590946010 IN IP4 37.157.241.124'"
Here is another way to block it, using iptables .

iptables -I INPUT -p udp -m udp --dport 5060 -m string --string "o=sipcli-Session" --algo kmp -j LOG --log-prefix "SIP CLI RTSP received " iptables -I INPUT -p udp -m udp --dport 5060 -m string --string "o=sipcli-Session" --algo kmp -j DROP iptables -I INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: sipcli" --algo kmp -j LOG --log-prefix "SIP sipcli UserAgent received " iptables -I INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: sipcli" --algo kmp -j DROP

First - it logs the packet (usually to /var/log/messages), then blocks it.
hope it may help to someone!

18

Just found a great article on voipfraud.org/, which describes everything:

voipfraud.org/secure_asterisk.php

19

Hi.

In case someone is still interested in this, I found another solution for fail2ban block the invites.
In fail2ban there is a rule for block in file /etc/fail2ban/filter.d/asterisk.conf, like this:

^%(__prefix_line)s%(log_prefix)s Call from ‘[^’]’ (:\d+) to extension ‘[^’]’ rejected because extension not found in context

With this line you can block an attempt to call a number in a context from a peer. So I configure sip.conf with allowguest=yes, and the context=jail (for example, you can call it as you want). The context jail I don’t even have in my dialplan, so it would never be an issue of security (at least that’s what I think), and with the allowguest in yes, the invites now will log something like this:

NOTICE[1507][C-0003bd32]: chan_sip.c:26414 handle_request_invite: Call from ‘’ (62.210.251.156:60528) to extension ‘962548221530036’ rejected because extension not found in context ‘jail’.

So now fail2ban can block this. Of course you could (and should) modify the filter to just block the calls failing in context jail for example, so the users will not be blocked if call a wrong number.

Another thing is to have enable some default codecs in sip.conf, because if you have configured disallow=all in the general section, the log will be just a " No compatible codecs, not accepting this offer!" with no ip.

It works for me, hope it will help someone else.