Yesterday I noticed some suspicous activity when running netstat | grep http on my Azure Ubuntu VM:
There were over 60 lines like this:
tcp 0 0 ser:http hosted-by.blazing:29248 SYN_RECV
tcp 0 0 ser:http hosted-by.blazingf:59438 SYN_RECV
tcp 0 0 ser:http 8.8.8.8:7057 SYN_RECV
# [SNIP]
I am guessing this is a SYN flood attack, and given the presense of 8.8.8.8 possibly some IP Spoofing? I don't have any DDOS protection from Azure, just a standard Ubuntu VM. I tried a few things:
Uncommented the line net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf and ran sysctl -p but the above packets continued.
I already have my own iptables script in place, to lock the server down a bit. Whilst checking over this script, I noticed some unrelated lines in /var/log/syslog:
INFO Exception processing GoalState-related files: [ProtocolError]
[Wireserver Exception] [HttpError] [HTTP Failed]
GET http://168.63.129.16/machine/?comp=goalstate -- IOError
timed out -- 6 attempts made
Some investigation into this IP, shows that it's part of Azure's infastructure, so I went ahead and added this to my firewall script, to allow outgoing traffic to this IP on port 80.
Suddenly the earlier SYN traffic stopped.
UPDATE
Okay, some further investigation shows that Azure provides a basic level of DDOS protection:
Basic: Automatically enabled as part of the Azure platform. Always-on traffic monitoring, and real-time mitigation of common network-level attacks, provide the same defenses utilized by Microsoft’s online services. The entire scale of Azure’s global network can be used to distribute and mitigate attack traffic across regions. Protection is provided for IPv4 and IPv6 Azure public IP addresses.
I guess my question now, for someone in the know: Would allowing outgoing HTTP traffic to 168.63.129.16 be a critical part of this protection, and explain the behaviour I've seen?
No comments:
Post a Comment