Not so much a question as an observation on port rule security. I have a Linux VM with iptables blocking and logging everything except for the exact things I need, and I have noticed that whenever I start the VM, add/modify/remove a port rule, or just sit there long enough the Azure "firewall" appears to drop for a significant enough period of time that my Linux host starts getting scanned. Here are the logged and dropped packets from the Linux host's iptables, since starting the VM: Packets that made it through Azure's firewall and hit the host's firewall.

It looks like there were no effective external protections in place for about 3-5 minutes after the VM started, where 4 external hosts (with negative reputations on AbuseIPDB) attempted service enumeration. Changing port rules has about the same effect - a few minutes of exposure to the world.

The packets that make it through the Azure firewall when I am just sitting there, watching the dropped packet log, seem to be ACK-RST scan attempts, though I can't seem to force this to happen (by throwing ACK-RST's at the external IP with nmap, from another external host; can't get any packets in, per how I set up Azure's port rules). My Azure Network Port Rules.

Anyways, I'm not sure how this is possible and why this is happening. Surely Microsoft knows that dropping all firewall rules, during VM deployment and/or when modifying rules, is bad, though I may be missing something obvious with my configuration. Any suggestions or help is appreciated, and thanks in advance.

  • when you say "Azure Firewall" do you mean Network Security Group? – 4c74356b41 Jul 19 '18 at 18:07
  • Yes, the inbound/outbound port rules for the Network Security Group. – user1676402 Jul 19 '18 at 18:20

As far as I know, you are right. In Azure Network Security Group, there is something existed about the rules.

If you use some impressible port in the rules and the rules will be existed just for a while, and then they will be dropped, the ports such as 22,3389,443 and so on. Because the ports are easy to attack from the Internet.

So, from a safety perspective, the suggestions are that you can replace the impressible ports instead of common ports, such as 2244.


enter image description here

You can see the rule about port 22 and the warning. And the rule about 65522 that I changed the SSH port with the warning.

  • I'm not sure this is coming from a legitimate MSFT employee, because this is 1. hard to understand; 2. the poster seems unsure about his own answer. 3. this doesnt really answer the OP question. – 4c74356b41 Jul 20 '18 at 6:03
  • Why not sure? I test and get the same result. I post the reason and suggestion that I also test. If you do not trust you can test yourself and you will get the similar result. – Charles Xu Jul 20 '18 at 6:38
  • you didnt post a reason. you posted something which is hard to understand and with no proofs. – 4c74356b41 Jul 20 '18 at 7:16
  • Yeah, I will post a test picture. – Charles Xu Jul 20 '18 at 8:33
  • I am a bit confused by some of the words you used, but I think you're telling me to lock down well-known ports. Per one of my pictures, I have an explicit allow rule for one inbound port (a random high port), so that one host can SSH in through that port, to the internal Linux host's IP. The SSH daemon on the Linux host has also been modified to listen on this random high port. – user1676402 Jul 20 '18 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.