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
    hours.

    Stu

  • 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 82.101.63.5 and 132.68.58.60
    are rather busy tonight…

    hw

  • 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
    busy.

    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
    way.

  • 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
    ports.

  • 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?

    Thanks,

  • 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
    ACT USA

  • 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
    device:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Regards
    Brian

  • 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?

    Gordon

  • 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.

    -M

  • 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.

    j

  • 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)

    hw

  • 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?

    sean

  • 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 :

    http://www.teamforrest.com/blog/171/asterisk-no-matching-peer-found-block/

    Regards,
    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?

    thanks
    adam