1

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?

v25
  • 764
  • 1
  • 6
  • 14

1 Answers1

3

The 168.63.129.16 is used for your VM to communicate with internal Azure resources like monitoring, guest agent heartbeat, load balancer probes and to signal to the platform the VM ready state. I've not been able to find a definitive list of everything that uses that IP to communicate, but your experience in Azure will be reduced if you don't allow access, so I would recommend you do so.

Whether it is required for DDOS protection, I suspect it is probably not, as most of the DDOS protection will be done at the network level before it reaches your VM, however, it's possible that some of the monitoring data sent over that route may be used.

Sam Cogan
  • 38,736
  • 6
  • 78
  • 114
  • Thanks for your answer. I'd also been trying to find a definative list. Although not perfect, the closest I got was [service tags](https://docs.microsoft.com/en-us/azure/virtual-network/security-overview#service-tags) which links to downloadable lists, in JSON. However these appear to be for portal-based policies. There doesn't seem to be specific guidance on how to configure the firewall on a VM. – v25 Nov 13 '18 at 20:22
  • Service tags are focussed around network security group restrictions rather than on the VM itself, but they can be used to provide greater control – Sam Cogan Nov 13 '18 at 20:23