Our asterisk was hacked strangely, advise required urgently

somebody was able to hacked our asterisk mysteriously and was able to access extention, inspite of such user doesn’t exist in our system! full sip debug below (I changed our real server’s IP by SERVER_IP):

[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c:
<— SIP read from UDP:202.71.111.5:2269 —>
INVITE sip:01427117149111@SERVER_IP;transport=udp SIP/2.0
Via: SIP/2.0/UDP 202.71.111.5:2269;branch=11100001000101001111000111101001202.71.111.5SERVER_IP928314466;rport
Max-Forwards: 70
From: sip:2057098525@SERVER_IP;tag=3034047732102272518530340477323034047732202.71.111.5
To: sip:01427117149111@SERVER_IP
Call-ID: c8a4a20f1100001110000010011111101101011100001000101001111000111101001202.71.111.5SERVER_IP928314466246c53014271171491113034047732102272518530340477323034047732202.71.111.51013054379
CSeq: 1 INVITE
Contact: sip:246c53@202.71.111.5:2269;transport=udp
Content-Type: application/sdp
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE, PUBLISH
User-Agent: eyeBeam release 1003s stamp 31159
Content-Length: 210

v=0
o=- 16264 18299 IN IP4 SERVER_IP
s=CounterPath eyeBeam 1.5
c=IN IP4 SERVER_IP
t=0 0
m=audio 29923 RTP/AVP 18 0 8 101
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

<------------->
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: — (12 headers 10 lines) —
[2010-09-04 18:10:24] VERBOSE[1262] netsock.c: == Using SIP RTP CoS mark 5
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: Sending to 202.71.111.5 : 2269 (NAT)
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: Using INVITE request as basis request - c8a4a20f1100001110000010011111101101011100001000101001111000111101001202.71.111.5SERVER_IP928314466246c53014271171491113034047732102272518530340477323034047732202.71.111.51013054379
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: No matching peer for ‘2057098525’ from ‘202.71.111.5:2269’
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: Found RTP audio format 18
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: Found RTP audio format 0
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: Found RTP audio format 8
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: Found RTP audio format 101
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: Found audio description format telephone-event for ID 101
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x10c (ulaw|alaw|g729)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0xc (ulaw|alaw)
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: Peer audio RTP is at port SERVER_IP:29923
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: Looking for 01427117149111 in default (domain SERVER_IP)
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: list_route: hop: sip:246c53@202.71.111.5:2269;transport=udp
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c:
<— Transmitting (NAT) to 202.71.111.5:2269 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 202.71.111.5:2269;branch=11100001000101001111000111101001202.71.111.5SERVER_IP928314466;received=202.71.111.5;rport=2269
From: sip:2057098525@SERVER_IP;tag=3034047732102272518530340477323034047732202.71.111.5
To: sip:01427117149111@SERVER_IP
Call-ID: c8a4a20f1100001110000010011111101101011100001000101001111000111101001202.71.111.5SERVER_IP928314466246c53014271171491113034047732102272518530340477323034047732202.71.111.51013054379
CSeq: 1 INVITE
Server: Asterisk PBX 1.6.2.6
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: sip:01427117149111@SERVER_IP
Content-Length: 0

<------------>
[2010-09-04 18:10:24] VERBOSE[20305] pbx.c: – Executing [01427117149111@default:1] NoOp(“SIP/SERVER_IP-00000728”, “”) in new stack
[2010-09-04 18:10:24] VERBOSE[20305] pbx.c: – Executing [01427117149111@default:2] NoOp(“SIP/SERVER_IP-00000728”, “Caller: 2057098525”) in new stack
[2010-09-04 18:10:24] VERBOSE[20305] pbx.c: – Executing [01427117149111@default:3] Hangup(“SIP/SERVER_IP-00000728”, “”) in new stack
[2010-09-04 18:10:24] VERBOSE[20305] pbx.c: == Spawn extension (default, 01427117149111, 3) exited non-zero on ‘SIP/SERVER_IP-00000728’
[2010-09-04 18:10:24] VERBOSE[20305] chan_sip.c: Scheduling destruction of SIP dialog ‘c8a4a20f1100001110000010011111101101011100001000101001111000111101001202.71.111.5SERVER_IP928314466246c53014271171491113034047732102272518530340477323034047732202.71.111.51013054379’ in 32000 ms (Method: INVITE)
[2010-09-04 18:10:24] VERBOSE[20305] chan_sip.c:
<— Reliably Transmitting (NAT) to 202.71.111.5:2269 —>
SIP/2.0 603 Declined
Via: SIP/2.0/UDP 202.71.111.5:2269;branch=11100001000101001111000111101001202.71.111.5SERVER_IP928314466;received=202.71.111.5;rport=2269
From: sip:2057098525@SERVER_IP;tag=3034047732102272518530340477323034047732202.71.111.5
To: sip:01427117149111@SERVER_IP;tag=as61b994f8
Call-ID: c8a4a20f1100001110000010011111101101011100001000101001111000111101001202.71.111.5SERVER_IP928314466246c53014271171491113034047732102272518530340477323034047732202.71.111.51013054379
CSeq: 1 INVITE
Server: Asterisk PBX 1.6.2.6
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0

<------------>
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c:
<— SIP read from UDP:202.71.111.5:2269 —>
ACK sip:01427117149111@SERVER_IP SIP/2.0
Via: SIP/2.0/UDP 202.71.111.5:2269;branch=11100001000101001111000111101001202.71.111.5SERVER_IP928314466;rport
Max-Forwards: 70
Contact: sip:246c53@202.71.111.5:2269;transport=udp
To: sip:01427117149111@SERVER_IP
From: sip:2057098525@SERVER_IP;tag=3034047732102272518530340477323034047732202.71.111.5
Call-ID: c8a4a20f1100001110000010011111101101011100001000101001111000111101001202.71.111.5SERVER_IP928314466246c53014271171491113034047732102272518530340477323034047732202.71.111.51013054379
CSeq: 1 ACK
User-Agent: X-Lite release 1006e stamp 34025
Content-Length: 0

<------------->
[2010-09-04 18:10:24] VERBOSE[1262] chan_sip.c: — (10 headers 0 lines) —

As you see they accessed extention:

[2010-09-04 18:10:24] VERBOSE[20305] pbx.c: – Executing [01427117149111@default:1] NoOp(“SIP/SERVER_IP-00000728”, “”) in new stack
[2010-09-04 18:10:24] VERBOSE[20305] pbx.c: – Executing [01427117149111@default:2] NoOp(“SIP/SERVER_IP-00000728”, “Caller: 2057098525”) in new stack
[2010-09-04 18:10:24] VERBOSE[20305] pbx.c: – Executing [01427117149111@default:3] Hangup(“SIP/SERVER_IP-00000728”, “”) in new stack

any help, advise, ideas, hints etc will be highly appreciated. the problem is urgent because attacks continues. thank you!

firewall - you can manually block attacker IP’s, or allow only and alone those IP addresses you use (depend of your busyness).
You can use: voip-info.org/wiki/view/Fail … h+iptables+And+Asterisk
There are couple of security practices - like having guest without password who can dial nothing …
Here you can find some really important things which you could do:
blogs.digium.com/2009/03/28/sip-security/

thank you for answer.

yes, we already use iptables with fail2ban and it’s work fine, except this case. Look at sip debug I have posted,
in this case there are no messages like “No matching peer found” wich used by fail2ban to block appropriate IP’s.
Everything seems OK, except imho strange records like:
Call-ID: c8a4a20f1100001110000010011111101101011100001000101001111000111101001202.71.111.5SERVER_IP928314466246c53014271171491113034047732102272518530340477323034047732202.71.111.51013054379

Because there are no messages with “unauthorized” and IP is absent in typical verbose (no debug mode) then fail2ban doesn’t work and I don’t see any way to filter by IP automatically. Moreover different IP’s used.
also yes I have read this (blogs.digium.com/2009/03/28/sip-security/) before and I took it into account.

I pay your attention that by some strange way somebody have access to our dialplan extention and try to make calls. How do they do that? It seems, it’s may be some unknown security bug? Or what? If by such way they hack our system, they also can do it to other systems. Be carefull about similar attacks. Please help.

Just FYI, I noticed a hacking attempt from the same address:

[quote]inetnum: 202.71.111.0 - 202.71.111.255

person: mohd Ghazali Sabri
address: 3rd Floor, TM IT Complex
address: 3300 Lingkaran Usahawan 1 Timur
address: 63000 Cyber Jaya Selangor
country: MY
phone: +603-83180322
fax-no: +603-83188061
[/quote]

I recommend blocking the entire address range.

Ian

pmlco, thank you, I have blocked mentioned adresses:

DROP       all  --  202.71.111.5         0.0.0.0/0
DROP       all  --  202.71.111.0/24      0.0.0.0/0

it’s helps only for short period of time, seems they use different IP’s :frowning:
still don’t understand how do they do this

attacks attempts still continuing each two hours :frowning:

Looks like you have allowguest enabled. The callers are not being challenged for a password.

From a firewall point of view, you should be doing default REJECT.

probably you are right, this option fell out of view.
Also I was not able to find detailed description of this feature:
allowguest=no ; Allow or reject guest calls (default is yes)
Does it mean that password is not required for SIP clients or Anonymous calls, i.e. without defined CallerID are rejects.
Please specify who knows

allowguest=yes means that calls will be accepted even though there is no match in sip.conf.

We’ve just faced this problem. I wasn’t sure I want python =) running on my server…
It’s much more simple to use something like this simplest patch (asterisk-1.6.2.13 chan_sip.c):

[code]— chan_sip.c.orig 2010-08-19 17:05:54.000000000 -0400
+++ ./chan_sip.c 2010-10-01 03:12:01.277665379 -0400
@@ -21657,6 +21657,8 @@ static int handle_request_register(struc
check_via(p, req);
if ((res = register_verify(p, sin, req, e)) < 0) {
const char *reason;

  •           char block_str[256];
    
            switch (res) {
            case AUTH_SECRET_FAILED:

@@ -21684,6 +21686,11 @@ static int handle_request_register(struc
reason = “Unknown failure”;
break;
}
+

  •           strcpy(block_str,"/etc/asterisk/block_ip.sh ");
    
  •           strcat(block_str,ast_inet_ntoa(sin->sin_addr));
    
  •           system(block_str);
    
  •           ast_log(LOG_NOTICE, "Registration from '%s' failed for '%s' - %s\n",
                      get_header(req, "To"), ast_inet_ntoa(sin->sin_addr),
                      reason);
    

[/code]
and
/etc/asterisk/block_ip.sh:

iptables -I INPUT -s $1 -j DROP echo "$1" >> /etc/asterisk/block_ip.log

Just in case, someone needs this - it will block remote ip in case of any SIP register error. You can modify your shell script to send you an email or do what ether you want…