SIP Attacks From Amazon EC2 Cloud Continue

Attacks from the cloud.

Just over a month ago, we reported that SIP attacks from the Amazon EC2 cloud were on the rise. While the attacks we received last month were limited to “extension only” registration attempts, one of the attacks we received this morning included what we assume was a standard dictionary attack.

The first attack came from 204.236.245.101. In less than 60 seconds, this IP attempted more than 11,500 registrations against our server. Most of these were 4 digit extensions (download the log (zipped) here). The second attack came from 184.73.4.183. In less than 90 seconds, this IP attempted more than 21,000 registrations against our server; including what we think is a standard dictionary attack complete with root, postmaster, pixadmin, etc. (download the log (zipped) here).

From past experience, Amazon will simply not do anything about these attacks. The only way to contact Amazon to report abuse is through their web form, which results with Amazon either completely ignoring you or sending a delayed response asking for the exact information you have already sent (and then ignoring you).

So, I’m looking for more ideas from the community on how we can get Amazon to help us stop their network from leveraging a very powerful attack against little ol’ SIP servers.

We are currently deploying a custom perl script to block these attackers via iptables (which is why the attacks registration attempts “stopped”).

Thanks for reading and we’ll be updating this as soon as more information comes in!

Update #1

The first response from Amazon:

Thank you for submitting your abuse report.

We have completed an initial investigation of the issue and learned that the IP address you reported did indeed belong an Amazon EC2 instance. These intrusion attempts that you report were not, however, initiated by Amazon.

One of the biggest advantages of Amazon EC2 is that developers are given complete control of their instances. While the IPs may indicate that the network is Amazon’s, our developer customers are the ones controlling the instances. You may learn more about EC2 at http://aws.amazon.com/ec2

That said, we do take reports of unauthorized network activity from our environment very seriously. It is specifically forbidden in our terms of use. We’ve already contacted the Amazon EC2 customer who controlled the instance in question and informed them that they are required to terminate their unauthorized interaction with your network, failing which we will terminate their instance. In cases of egregious abuse or as we otherwise deem appropriate, we will immediately terminate all their instances and suspend their account.

If you have blocked this address range, please be aware that usage on the address range is transient and new users may soon be operating from those addresses and may not be able to reach you; once you have confirmed that the activity has been ceased by our customer, you should open your filters to re-allow traffic.

Thanks again for alerting us to this issue.

Original report:

* Source IPs: 204.236.245.101
* Abuse Time: Sun May 16 08:53:00 UTC 2010
* NTP: Y

How can I send a message to the EC2 customer?
Complete and submit the web form here.

How can I contact a member of the Amazon EC2 abuse team?
Send an e-mail to ec2-abuse@amazon.com to contact a member of the Amazon EC2 abuse team.

Please note: This e-mail message was sent from a notification-only address that cannot accept incoming e-mail. Please do not reply to this message.

Amazon Web Services

If you feel you are receiving this email in error and do not wish to receive further notifications, send an e-mail to ec2-abuse@amazon.com.

Amazon Web Services LLC is a subsidiary of Amazon.com, Inc. Amazon.com is a registered trademark of Amazon.com, Inc. This message produced and distributed by Amazon Web Services, LLC, 1200 12th Ave South, Seattle, WA 98144.

I really don’t need a sales pitch in my abuse response.

Additional Information:

This entry was posted in tech, VoIP and tagged , , , by Fred. Bookmark the permalink.

About Fred

The reason this site exists can be found in two words... Patrick and Fred. Fred Posner designs and implements VoIP solutions through Team Forrest and LOD.com. Favoring Open Source solutions (such as Asterisk, FreeSWITCH, and Kamailio), Fred enjoys working with organizations to increase productivity while reducing cost. If you’d like to contact Fred, please do so through QXORK.com. You should also check out Dream Day Cakes.

20 thoughts on “SIP Attacks From Amazon EC2 Cloud Continue

  1. Time to start blocking these IP ranges at the boarder of your networks. As an ITSP / ISP I have the luxury of beefy routers and firewalls, however the loan PBX at the customer prem is in trouble. Even with firewall rules in place odds are the little routers will simply fail under the load of traffic coming from EC2.

    Time for people to start complaining to there ISP’s and let us start contacting Amazon and blocking the attacks upstream before they reach your PBX’s.

    For reference, Current amazon EC2 IP ranges.

    US East (Northern Virginia):
    216.182.224.0/20 (216.182.224.0 – 216.182.239.255)
    72.44.32.0/19 (72.44.32.0 – 72.44.63.255)
    67.202.0.0/18 (67.202.0.0 – 67.202.63.255)
    75.101.128.0/17 (75.101.128.0 – 75.101.255.255)
    174.129.0.0/16 (174.129.0.0 – 174.129.255.255)
    204.236.192.0/18 (204.236.192.0 – 204.236.255.255)
    184.73.0.0/16 (184.73.0.0 – 184.73.255.255)
    184.72.128.0/17 (184.72.128.0 – 184.72.255.255)

    US West (Northern California):
    204.236.128.0/18 (216.236.128.0 – 216.236.191.255)
    184.72.0.0/18 (184.72.0.0 – 184.72.63.255)

    EU (Ireland):
    79.125.0.0/17 (79.125.0.0 – 79.125.127.255)

    Asia Pacific (Singapore)
    175.41.128.0/18 (175.41.128.0 – 175.41.191.255)

  2. Pingback: Tweets that mention SIP Attacks From Amazon EC2 Cloud Continue | VoIP Tech Chat -- Topsy.com

  3. If we all start blocking Amazon IP addresses to the point amazon starts loosing business, perhaps they will start to listen. Or, perhaps a few well placed lawsuits against amazon for damages would get their attention…

    Either way, As an ISP, I have no problem blocking ALL amazon IP addresses and telling our customers “Too bad, Amazon doesn’t care so neither do we”

    Fred…

  4. Pingback: Fred Posner

  5. Pingback: Bill Tozier

  6. Pingback: Michael S. White

  7. Pingback: regnordman

  8. Pingback: Dave Michels

  9. Pingback: TC Blog » Blog Archive » Die dunkle Macht der Wolke – VoIP-Angriffe über Cloud-Services

  10. Pingback: Attacking VOIP From the Cloud – Upland Strategy Group, LLC

  11. Pingback: David A. Bryan

  12. Pingback: David A. Bryan

  13. Pingback: Garrett Smith - VoIP

  14. Time to start blocking these IP ranges at the boarder of your networks. As an ITSP / ISP I have the luxury of beefy routers and firewalls, however the loan PBX at the customer prem is in trouble. Even with firewall rules in place odds are the little routers will simply fail under the load of traffic coming from EC2.

    Time for people to start complaining to there ISP’s and let us start contacting Amazon and blocking the attacks upstream before they reach your PBX’s.

    For reference, Current amazon EC2 IP ranges.

    US East (Northern Virginia):
    216.182.224.0/20 (216.182.224.0 – 216.182.239.255)
    72.44.32.0/19 (72.44.32.0 – 72.44.63.255)
    67.202.0.0/18 (67.202.0.0 – 67.202.63.255)
    75.101.128.0/17 (75.101.128.0 – 75.101.255.255)
    174.129.0.0/16 (174.129.0.0 – 174.129.255.255)
    204.236.192.0/18 (204.236.192.0 – 204.236.255.255)
    184.73.0.0/16 (184.73.0.0 – 184.73.255.255)
    184.72.128.0/17 (184.72.128.0 – 184.72.255.255)

    US West (Northern California):
    204.236.128.0/18 (216.236.128.0 – 216.236.191.255)
    184.72.0.0/18 (184.72.0.0 – 184.72.63.255)

    EU (Ireland):
    79.125.0.0/17 (79.125.0.0 – 79.125.127.255)

    Asia Pacific (Singapore)
    175.41.128.0/18 (175.41.128.0 – 175.41.191.255)

  15. My system as just been attacked again. Sent the details to AmazonWS and their response was:

    “Thank you for submitting your abuse report.
    There was no single customer using the source IP address(es) during the time you provided.
    This may be due to the fact that we do not own the IP address(es), the time or time zone you provided was incorrect, or there were multiple customers with instances running during the time and IP address(es) you specified.
    You may try re-submitting your report with a different time if you wish.”

    Uh, sorry but it was one of your servers!

    dig +short -x 204.236.207.65
    ec2-204-236-207-65.compute-1.amazonaws.com.

  16. Hopefully the IP restrictions and lawsuits will send the right message.

    For the moment, it appears that, Mr. Bezos’ loyalty rests with paying AWS customers (aka attackers) and not the victims of abuse.

  17. Pingback: I’ll have clear skies, personal conversation, and hold the technology, please. | VoIP Tech Chat

  18. As a VoIP service provider, we find most attacks currently coming from China. On top of the router blocking suggested above, we install “fail2ban” and configure it to 5 attempts and the IP address is blocked.

    It helps, but the real answer is for ISPs to be notified and them being responsible enough to shut down the attackers.

    The question is how do we get ISPs, even Amazon, to listen and act?

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>