Under heavy attack

Home » Asterisk Users » Under heavy attack
Asterisk Users 42 Comments

My main asterisk server is under unusual heavy attack, and so far Fail2Ban
has blocked about 30 IPs, from various different countries. At this time it
is blocking about 1 IP address every few minutes.

Just wondering if anybody else is also experiencing unusually increased hack
attempts today?

Zeeshan A Zakaria

42 thoughts on - Under heavy attack

  • Me too.

    href=”mailto:asterisk-users-bounces@lists.digium.com”>asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Zeeshan Zakaria
    Sent: Saturday, October 30, 2010 11:29 AM

    My main asterisk server is under unusual heavy attack, and so far Fail2Ban has blocked about 30 IPs, from various different countries. At this time it is blocking about 1 IP address every few minutes.

    Just wondering if anybody else is also experiencing unusually increased hack attempts today?

    Zeeshan A Zakaria

  • Hash: SHA256

    We are also seeing an increase in attacks. And yes, there is a benefit
    to blocking them. They tend to go away if you have them restricted,
    where if you let them go at it, they will sit on your host for sometimes


  • any registry of abusers like for spam ?
    any list of complete ip ranges for countries where abuse is rampant to
    block ?

    I am getting sick of the one offs and ready to start blocking big chunks
    of address space.

  • Just 30 ?

    I got 1593 different IP’s on my personal blacklist who constantly are
    looking if i may lower my guards. Though and
    are rather busy tonight…


  • We have about 8-10 boinking us. They generally run a 1-9999 peer attack and
    a few alphas like common words or “eieio” We use large, complex peer IDs
    and passwords, so they have a long way to go. I am happy to help keep them

    I also send messages to their network abuse address.

    Cary Fitch

  • Regardless of any threat from those attacks succeeding, they completely
    saturated the uplink in our ADSL-connected office.

    What are they after, anyway? Merely cheap international calls?

  • No. It seems that opening up some sort of automatic blocking could cause an attacker forging packets to block legitimate endpoints. It also seems like they won’t get in with good passwords, so it isn’t actually accomplishing something to worry about the script kiddies if you have good passwords. And this blocking won’t actually stop someone with a zero day attack or who is sophisticated and can attack from many IP addresses – these are the real threats for people with good passwords.

    The CPU usage is trivial to deny them. As is the bandwidth usage, if you are not sitting on a slowish broadband connection.

    Sure blocking doesn’t hurt, but does the help it provides exceed the downsides (effort and risk of blocking legitimate users)? I suspect it doesn’t…if you have strong passwords. If you have weak passwords, you should fix that.

    It also seems that the only way to make blocking effective is to block everything by default except known endpoints. Blocking the door knickers doesn’t protect against a bad guy finding (not through brute force) valid credentials.

    For me, monitoring outbound call volume makes a lot more sense. I would love to see an easy to use, out of the box method to alert me if more than “x” number of erlangs* are exceeded within a five minute, sixty minute, and one day time period. For me, I would want alerting on more than 10 erlangs over five minutes, 8 over an hour, and 2 over a day. Exceeding these would likely indicate fraud for my installation. Smaller sites would use smaller numbers, larger ones would use bigger ones.

    *erlang: one erlang represents full utilization of a single call path over the monitoring period. The monitoring period is usually one hour, but can be anything (5, 60, or 1440 minutes in this case).

  • My count has reached 100 for the day. The server serves doesn’t serve
    international calls anyways, I wonder how would it benefit any hacker in any

  • Ah, that makes sense – I probably would restrict to only known endpoints by IP address if I has only DSL bandwidth. But blocking attackers makes sense if that isn’t an option.

    Yes, they are after cheap calls.

  • I’m guessing free PSTN access. They don’t want to DoS you. The scans
    are an attempt to collect valid extensions for later password guessing
    attempts. Every one I’ve seen has used svwar (from SIPVicious), which
    by default will give up if it can’t tell the difference between trying
    to register (or invite) an unknown peer and a known one. This is why
    “alwaysauthreject = yes” is so effective, even though it bends RFC3261
    a bit.

    But keep using fail2ban, too. “svwar.py –force” will cause it to scan
    regardless of response code.

  • They have agreements for termination to locations with high rates.
    These types of attacks happen on servers that fit a digital signature.
    With certain ports or certain versions of software on those ports.
    Yes the Art of War is required reading for todays systems
    administration professionals… Change your signature, change your

  • To me it seems the real question is “What is going on today?”. I normally get eight to ten asterisk-related fail2ban alerts a day between a few client sites – today I’ve received at least 10 times that many attacks on just one site. These are all coming in from different ip addresses, a new one every few minutes. These addresses are located all across the globe. This seems like some kind of coordinated assault – maybe someone is activating a ‘bot-net’ for sip attacks?


  • Hash: SHA256

    We are seeing the same thing… It could be a bot-net, but it is a very
    poorly organized attack. If is was a single bot-net, you would assume
    that the systems would each pick a group of addresses, not all attack
    the same addresses.

    It could be an attempt to get a large number of systems blacklisted. If
    someone was to spoof 1000s of addresses that cause operators to
    black-list those addresses, they could knock quite a few systems off the
    map. This could cause legitimate operators to get blocked, or, discredit
    the current method used to detect and block SIP brute force attacks.

    Just my two cents…

    Stuart Sheldon

  • s/slow/assymetric/

    Unless you have people on the road.

    Or unless you have people who want to actually use the peer-to-peer
    nature of SIP and call your SIP address.

    I suspect even munin would provide you such options. Not to mention any
    more capable monitor.

  • Good Morning.

    Certainly some kind of very slow DDOS attack.

    I’m blocking at IPTABLES level.

    Strange thing is even after I DROP the REGISTER attempts they keep on trying
    which is unusual.

    We have a number of Asterisk & Kamailio boxes on the same subnet and it’s
    only targeting 1 Asterisk box.

    IP’s so far if anyone wants to block them before they start on your SIP

    2010-10-30 18:20:19,023

    2010-10-30 18:29:41,251

    2010-10-30 18:29:53,296

    2010-10-30 18:30:06,047

    2010-10-30 18:35:05,356

    2010-10-30 18:35:17,588

    2010-10-30 18:35:19,995

    2010-10-30 19:09:35,223

    2010-10-30 19:10:37,108

    2010-10-30 19:10:54,011

    2010-10-30 19:11:06,779

    2010-10-30 19:11:09,739

    2010-10-30 19:12:29,671

    2010-10-30 19:15:28,303

    2010-10-30 19:17:44,548

    2010-10-30 19:19:39,432

    2010-10-30 19:20:59,923

    2010-10-30 19:22:41,063

    2010-10-30 19:24:57,283

    2010-10-30 19:29:39,523

    2010-10-30 19:33:19,096

    2010-10-30 19:40:51,324

    2010-10-30 19:43:02,567

    2010-10-30 19:47:46,323

    2010-10-30 19:54:07,564

    2010-10-30 19:54:51,155

    2010-10-30 20:01:32,615

    2010-10-30 20:01:53,215

    2010-10-30 20:02:31,448

    2010-10-30 20:05:24,203

    2010-10-30 20:06:40,431

    2010-10-30 20:09:00,668

    2010-10-30 20:09:13,907

    2010-10-30 20:09:52,135

    2010-10-30 20:11:46,719

    2010-10-30 20:22:10,947

    2010-10-30 20:23:10,176

    2010-10-30 20:23:18,336

    2010-10-30 20:25:56,932

    2010-10-30 20:26:26,155

    2010-10-30 20:37:26,400

    2010-10-30 20:37:33,024

    2010-10-30 20:39:26,968

    2010-10-30 20:44:27,968

    2010-10-30 20:48:48,715

    2010-10-30 20:52:12,431

    2010-10-30 20:54:51,031

    2010-10-30 20:55:42,639

    2010-10-30 20:56:19,243

    2010-10-30 20:58:24,979

    2010-10-30 20:58:49,720

    2010-10-30 20:59:40,959

    2010-10-30 21:06:31,700

    2010-10-30 21:10:27,811

    2010-10-30 21:15:42,452

    2010-10-30 21:34:23,343

    2010-10-30 21:42:25,575

    2010-10-30 21:43:10,184

    2010-10-30 23:03:41,419

    2010-10-30 23:46:20,651

    2010-10-30 23:49:53,023

    2010-10-30 23:52:02,279

    2010-10-31 00:02:12,511

    2010-10-31 00:11:01,491

    2010-10-31 00:13:20,399

    2010-10-31 00:13:36,963

    2010-10-31 00:16:00,563

    2010-10-31 00:26:21,299

    2010-10-31 00:34:34,524

    2010-10-31 00:41:35,760

    2010-10-31 00:46:44,755

    2010-10-31 00:50:50,995

    2010-10-31 00:58:23,220

    2010-10-31 00:59:01,476

    2010-10-31 01:04:01,403

    2010-10-31 01:15:13,300

    2010-10-31 01:18:14,979

    2010-10-31 01:19:07,572

    2010-10-31 01:23:30,527

    2010-10-31 01:32:22,339

    2010-10-31 01:51:35,576

    2010-10-31 02:00:01,131

    2010-10-31 02:00:02,403

    2010-10-31 02:00:03,281

    2010-10-31 02:00:04,184

    2010-10-31 02:07:17,011

    2010-10-31 02:15:02,887

    2010-10-31 02:22:27,803

    2010-10-31 02:25:47,031

    2010-10-31 02:35:08,059

    2010-10-31 02:47:15,984

    2010-10-31 02:52:05,876

    2010-10-31 06:25:08,147

    2010-10-31 06:25:08,764

    2010-10-31 06:25:09,781

    2010-10-31 06:25:10,084

    2010-10-31 06:25:14,303

    2010-10-31 06:25:27,251

    2010-10-31 06:36:19,591

    2010-10-31 07:40:12,855

    2010-10-31 07:41:29,783

    2010-10-31 07:41:42,671

    2010-10-31 07:42:41,911

    2010-10-31 07:42:52,792

    2010-10-31 07:44:10,831

    2010-10-31 07:45:46,755

    2010-10-31 07:50:09,999

    2010-10-31 07:51:36,471

    2010-10-31 07:52:08,684

    2010-10-31 07:55:10,723

    2010-10-31 07:55:33,595

    2010-10-31 07:55:45,735

    2010-10-31 07:57:32,575

    2010-10-31 07:57:48,483

    2010-10-31 07:59:16,335

    2010-10-31 07:59:54,187

    2010-10-31 08:04:48,071

    2010-10-31 08:04:54,300

    2010-10-31 08:05:56,551

    2010-10-31 08:29:51,783

    2010-10-31 08:33:05,652

    2010-10-31 08:33:22,880

    2010-10-31 08:34:08,119

    2010-10-31 08:34:21,063

    2010-10-31 08:36:01,300

    2010-10-31 08:38:46,528


  • They want them to sell on.

    Ever wondered about all that spam you get offering you cheap routes to
    1000’s of destinations… Where do you think they’re getting the cheap
    routes from…

    From my own experiences and discussions with others, I’ve seen 2 kinds of
    uses for the compromised accounts – one is to get to expensive
    destinations – e.g. mobiles in eastern european/african destinations, and
    the other would appear to be pure fraud – e.g. 10 concurrent calls to what
    looks like a mobile in a country with a dubious telecom infrastructure –
    which is obviously a destination that charges a high interconnect fee, so
    one theory is that it’s the terminating telco themselves that are stealing
    the accounts and placing calls into their own network…

    (This was a popular scam with mobile phone theft in the UK a few years
    back – stories abounded with tales of rooms full of mobiles, calling
    premium rate numbers belonging to the thieves, and so on)

    Anyway, SV is easy to thwart with good practices and tools like fail2ban,
    svcrash.py, sites like http://www.infiltrated.net/voipabuse/ and so on.

    As far as I’m concerned, it’s history. It’s understood and with a few
    simple procedures we can protect ourselves against it. It’s yesterdays
    news. Why are we still bleating on about it?


  • A 1mb/s uplink is slow nowadays. I suspect a symetrical 1mb/s SDSL line
    would also be having trouble with lots of registrations.

    But regardless, that’s why I don’t use ADSL for call paths, unless the ADSL
    is 100% within a corporate network (terminates on an ATM line in some
    corporate office, not in a public provider) – to easy for bad guys to send
    enough traffic at you to disrupt your calls.

    If you did have fast enough downlink to not be a victim of this, then you
    just need QoS – VoIP signalling (registration/registration-fail messages)
    should always be a lower priority than the VoIP media stream – and it’s
    possible even on ADSL internet connections to control what you send to your
    provider and in what order you send it. Media packets should always be sent
    before signaling on that uplink. Even fair queuing (so long as your router
    recognizes the UDP traffic flows as flows) would help (and would let your
    legitimate users register quickly even during an attack).

    Agreed. But I would host that in a datacenter with adequate bandwidth, not
    on the end of an ADSL or other connection that is easy to DOS.

    If these are mobile users, I hope they never use any public networks
    (hotels, starbucks) where other subscribers can do things like ARP attacks
    to do MITM (and steal your calls; it might not be happening today, but it
    will be happening soon – as the social networking attacks demonstrate). If
    you do have truly roaming users, I hope you use HTTPS (with validation of
    certs turned on) or a VPN (likely not an option of connecting to an ADSL
    site, due to bandwidth concerns).

    Once again, I’d use a border gateway at a datacenter or other location with
    significant bandwidth (not an ADSL line). Even for a small shop.

    I already have a monitor (tied into nagios, which pages me if my fraud
    thresholds are exceeded), but I feel that is probably beyond the abilities
    of most of the people experiencing call fraud. The people who know what
    they are doing with Unix and Asterisk are generally not the victims of
    this. It would be nice if there was something built into Asterisk to alert
    on fraud – something that an end user with little Asterisk (or Unix)
    experience could utilize to be alerted to call fraud, which is easily
    detectable almost 100% of the time (too many calls for the organization ==
    call fraud). And that is really what this is about – keeping someone from
    getting a $30,000 phone bill. It certainly should be the part of any
    commercial offering.

    I stand by my statements. Blocking people who were already denied access
    will not stop call fraud on systems with secure authentication. You need to
    worry about the guy that has the trojan on the computer with the soft phone
    – the hacker who now has legit credentials (and will never be flagged by
    fail2ban when he uses them). It’s the bad guy you don’t know about, not the
    bad guy you stopped, that is a danger. As for bandwidth issues, I would
    never use an ADSL-based internet connection for VoIP – too easy for the bad
    guy to make a mess of things (or even just a misconfigured endpoint). But
    if I did, I’d agree that some sort of fail2ban-like system would be helpful
    if you couldn’t implement QoS.

    People can take or leave my advice, but it is sound. Practice security
    theater or actual security.

  • Can you explain why VPN is not an option for ADSL? (Open)VPN overhead
    is not that high. ~70 bytes per packet if I remember correctly.


  • This only tells you after it is way too late that you now have upstream
    bills to wrangle with your carriers about, or (like in my case) that your
    balance is now depeleted, if it trips anything at all.

    In my very recent case only FIVE calls, all placed at the same time,
    caused charges of over US$8K as they stayed connected for over two days.
    This would not have tripped any erlang threshold, and you don’t even know
    that it is affecting your balance until the calls cease.


  • We’re not using it for calls but do have a huge openvpn infrastructure
    connecting wifi access controllers and there is not a ton of overhead at
    all, and it runs on endpoints with very limited resources. What might
    need lots of tweaking is how the sip packets get converted to vpn
    packets and transmitted, since there could be a lot of fragmenting and
    reassembly. If phones came with it built in, the manufacturer would
    presumably have figured this all out for them. PPTP is another option
    thats widely supported but I don’t have much personal experience with it.

  • It would have alerted me within 24 hours, which would have been 1/2 the cost. Of course I have an average erlong much lower than 5 over 24 hours.

    How did they get in? Did they guess a password to get in? Was the password a good, complex password? Or did they get in a different way?

    That said (thinking out long), I might need to add a trigger for long-lived calls. Even one long lived call to the wrong destination would cost significant money. Maybe I should notify on any call longer than 3 hours during the day, 2 hours long at night? I’ll have to look through my CDRs to see how often this would trigger in my environment.

  • I can’t remember how big OpenVPN’s overhead is, but RTP packets are very small (I want to say a 128 byte payload for G711 codecs and 20ms sample per packet). So that overhead is much more significant than it would be for, say, HTTP. It also increases latency for that packet (longer packets take longer) and often jitter (this is a bit more complex, but basically the shorter all the packets are the more manageable jitter is for QoS). RTP over VPN will have lower quality, assuming you deal with any non-QoS links (such as the internet).

  • Like I said before RUBBISH.
    One should just ban/block IPs that are attacking you and not let them
    connect at all. Not just protect against them with fancy passwords.
    BTW, even your fancy passwords are breakable, can’t wait for the day
    that you’ll wake up and smell the coffee.

    RUBBISH RUBBISH RUBBISH and RUBBISH again. If you have someone
    attacking you just block him.

    Cute idea and should be done maybe for other reasons but nothing to do
    with attacks, if you are being attacked block the IP.

    Why is a datacenter harder to DOS? The fact that there is more
    bandwidth doesn’t in any way make it harder to DOS. BTW, most
    datacenter in the US do charge based on 95th%

    RUBBISH again, what is true is that fail2ban should be implemented ALL
    the time, and something like QoS is helpful. You are living in some
    cocoon wake up buddy.

    No its NOT, like I said you live in a cocoon.

  • I’ll package it up next week and make it available.

    Basically, I use nrpe to call a shell script that looks at the last five minutes, 60 minutes, and 1440 minutes of a “asterisk -rx ‘core show channels'” output that I run from cron every minute (I count the number of paid channels in use [I ignore channels that have no cost associated with them, such as users calling other users]). If any of these thresholds exceeds my error threshold, I signal a nagios “CRITICAL” alert. Otherwise I return “OK”.

  • To guess an 8 character (which is short) password that consists of random upper case, lower case, numbers, and 10 symbols (there are more you can use if you want), the average number of passwords that you would have to try to get in is:

    (72^8) / 2 = 361,102,068,154,368 guesses

    Over a 10 mb/s ethernet link, assuming no latency, if it takes 100 bytes (it actually takes more), with each byte being 8 bits, of traffic sent by the attacker to Asterisk per password guessed, and the attacker knows you use 8 character passwords, then someone would need to do this for 28,888,165,452 seconds, or over 908 years of continuous guessing while saturating a 10 mb/s ethernet link. If the attacker is unlucky, it might take twice as long. It would be “only” 9 years if you could fill a 1 gigabit link. If this is too short, add one character (9 total) and it will now take 72 times longer. Two characters, and 5,184 times.

    (math is: ((361,102,068,154,368 * 100bytes) * 8bits) / 10,000,000 bit/s) = 28,888,165,452 seconds)

    This assumes the attacker knows the peer name (I’m assuming everyone has set their asterisk to not let the attacker know if an peer name is valid).

    It’s actually quicker to crack modern encryption algorithms than to guess good passwords.

    If you have passwords that are shorter, contain less characters, or are obvious (such as matching extension numbers), then it could take less time. That’s why good passwords are important. Good passwords should be truly random, contain a lot of characters, and include as many different classes of character as possible. If you do easy passwords, you’ll probably get hacked with or without blocking attackers, if you allow SIP registrations from the internet.

    I don’t think blocking attackers is bad, just not something that actually improves security against fraud. I don’t do it – the risk of blocking legitimate users is too high, but others would make different choices, which is fine. I just think it’s a false sense of security if you think it makes a difference in preventing fraud. Good passwords do prevent fraud. Monitoring contains fraud.

  • So don’t block they IP/s but let them choke your bandwidth.

    Agreed to certain extend as more sophisticated attacks will not do a
    simple brute force starting at 0 and ending at z or !.

    While in design you might be right that it doesn’t improve security,
    it is something that should be implemented as a number one step for
    security as it blocks the attacks. It’s actually better than good
    passwords. In fact one could use weak passwords if they use fail2ban,
    although I wouldn’t recommend it.
    The risk of blocking legit user is almost non existent and should
    never be the reason to allow attacks to continue against an
    unprotected machine.

    A good example, a previous poster said that a call took a few days and
    was therefore not detected by a monitoring system. To which you
    replied that you will be adding more detectors. While fraud – and this
    specific type of fraud – could have come from a legit user (by legit I
    mean with a legit username/pass) which means that fail2ban would have
    not helped and what you have in place is a must, and with your new
    rules will be detected. If however the attack would have been from a
    compromised username/pass fail2ban would have detected it before you
    added your new detectors. BECAUSE it could block legit users, in other
    words because its way to broad blocking technique.

  • ok thanks.

    btw – on the subject of nrpe – anyone got a version that runs stable on
    windows ?
    we have one but it randomly locks up (without failing the service) every
    week or so on various windows servers, service down detection in windows
    sees it up, and nagios can’t use nrpe to restart it with a command since
    that is what is down. annoying when its 3am.
    on the linux boxes, works perfectly.

  • It’s been an extremely busy day for the exploiters. I moved my phone
    system from one circuit that I have (10Mb) to another that is behind a
    firewall (100Mb) and the fail2ban alerts are all gone.
    I’m not really concerned that someone will determine the passwords, as
    I use the phones serial numbers to determine that. But still, very
    irritating to see so many attempts at exploiting my phone system.
    fail2ban is nice, but I recommend you put your system behind a
    firewall and only allow necessary connections. pfsense is doing the
    trick for me. – Niles

  • Perhaps this is good enough reason for starting to use SIP-s (using TLS)
    with large >= 2K) keys. Should be safe enough, i think.
    Snom seems to be capable of handling it, so can asterisk 1.6.x

    Any unsuccesfull register attempt should add the offending address to
    your own blacklist (for iptables)


  • Unsuccessful attempts are recorded, however SIP-s is not easily doable on
    asteridk 1.4. I tried once without any success. Maybe somebody who has
    successfully implemented it can write a little how-to on it.

    Zeeshan A Zakaria

  • …………

    Well it’s beyond my capabilities. How do you do this? For instance, how
    do you monitor international calls? Get a warning that > X calls/day?


  • I just wanted to add my voice to this “attack”. I saw the morning that I had 200+ distinct ips since the weekend. I used a small perl script that blocks failed usernames and passwords at iptables level I found thei morning :


    My main asterisk server is under unusual heavy attack, and so far Fail2Ban has blocked about 30 IPs, from various different countries. At this time it is blocking about 1 IP address every few minutes.
    Just wondering if anybody else is also experiencing unusually increased hack attempts today?

    Zeeshan A Zakaria

  • Hi guys,

    i’ve seen this too, nagios woke me up because it was an extremely high
    volume of tries.

    I took a peek into the logs and saw that the attacker’s script was
    trying extensions from 1 to 9999 and then random names. I can see the
    log in the messages file that several attempts failed because there was
    no such extension.

    I see no log entries for extensions that actually exist. My passwords
    are okay, so i’m not worried, i’m jusy courious, why can’t i see a log
    message for the matching peer extensions with a ‘bad password’ (or
    similar) message?