ALERT Amazon EC2 Security Issue

[msatt]

Just recently installed PIAF Green on Amazon (thank you Ward).
Using TM3 plus some of my own security ;-)
Noticed occasional attempts to register non existent extensions and wondered where or how these were getting through the firewall.
Upon investigation, I can see that the iptables understandably has entries for private networks :-

-A INPUT -s 10.0.0.0/8 -j ACCEPT
-A INPUT -s 127.0.0.0/8 -j ACCEPT
-A INPUT -s 172.16.0.0/12 -j ACCEPT
-A INPUT -s 192.168.0.0/16 -j ACCEPT

On Amazon they use 172 addresses to create your own private network between other servers. Is this a potential source for the false registrations / hacks ?

As a safety issue, I have removed these private IP address ranges (left 127.0.0.0/8).

 

[wardmundy]

Could be an issue. We've removed 172.16 from the default WhiteList for future Travelin' Man 3 installs. Thanks for the heads up.

For existing Amazon EC2 users, here's the fix:

sed -i 's|-A INPUT -s 172.16.0.0/12 -j ACCEPT|#-A INPUT -s 172.16.0.0/12 -j ACCEPT|' /etc/sysconfig/iptables
iptables-restart

 

[msatt]

And thanks for the fast update.
Have not seen any further 'hacks' since removing the 172.16.0.0/12 private address range.

For Amazon users, it would make sense removing the
-A INPUT -s 192.168.0.0/16 -j ACCEPT
as it is not used. The
-A INPUT -s 10.0.0.0/8 -j ACCEPT
address could be used by Neorouter so best left but perhaps strengthen the subnet mask.

 

[wardmundy]

Those are non-routable IP addresses so there should be no issue with the 192.168 and 10.0 subnets. 172.16 becomes a problem because Amazon apparently is routing them internally between their public servers which is a no-no at least in our security book.

 

[rcoates]

If I wanted to be able to "travel around" with Traveling Man, wouldn't I need to allow traffic from all IPs in the EC2 Security Groups? I think AWS EC2 Security Groups can only allow specific IPs or a range of IPs, not a dynamic DDNS URL.

 

[wardmundy]

Yep. That's a major advantage with RentPBX and Digital Ocean.

 

[wardmundy]

After some further discussion with rcoates, I'm not sure removing just the 172.16 subnet is sufficient. Amazon apparently lets anyone set up a private subnet of their choice. They then can roam around Amazon's networks using their private subnet address. If you have not blocked these subnets, then they can visit your server at will (masquerading with their private IP address) even though you are not on the private subnet yourself. See this article: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario3.html

This is obviously a huge security hole that Amazon has manufactured for its law-abiding users. We will send them a note.

 

[wardmundy]

TO: [email protected]

We have a number of users that have deployed PBX in a Flash on Amazon EC2 servers to create communications servers. As part of our default firewall setup, we typically allow LAN traffic on private subnets to access PBX in a Flash systems. We have been receiving reports of attacks on these communications systems by other EC2 users who have created their own private subnets as outlined in this Amazon tutorial: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario3.html. Apparently with this setup, a malicious user is free to roam Amazon's servers looking for other services that have not blocked private subnet access. This is true whether the unsuspecting victim has actually deployed a private subnet of their own or not. Stated another way, so long as the malicious attacker announces his presence with a private subnet address, ALL Amazon servers treat the attacker as being on their private LAN. The security vulnerabilities this creates for anyone believing that private subnet addresses are non-routable should be clear. We trust you will take the necessary steps to insulate other EC2 users from malicious attackers masquerading with private subnet addresses. Thanks for your assistance.