Unexpected Network Traffic Reaching VM Despite NSG Configuration in Azure

Hi @nma

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

Please go through the below troubleshooting steps:

• First make sure that the NSG is correctly associated with the VM's network interface or subnet. You can verify this in the Azure portal by navigating to the VM's networking settings or the subnet's associated NSGs and diagnose the network security rules by using NSG Diagnostic in Network watcher.
• Next, verify if there are any other NSGs applied to the VM or subnet that might be allowing the traffic. Check the priority of the NSG rules to make sure that the deny rule for port 80 has a higher priority than any allow rules.
• If an allow rule has a higher priority, it will override the deny rule, allowing traffic on port 80. When creating NSG rules, it's crucial to space the priority numbers to allow for future rule additions without requiring renumbering of existing rules.
• Examine the NSG for any application rules or service tags that might be allowing the traffic. Application rules allow traffic based on predefined application types, while service tags represent groups of IP address prefixes for Azure services. If any of these rules or tags allow traffic on port 80, it will bypass the deny rule.
• Determine if there are any virtual network appliances or other network devices that might be bypassing the NSG. Some appliances might have their own routing or filtering mechanisms that could override NSG rules Additionally, check for UDRs that might be overriding traffic destined for private endpoints and potentially bypassing NSG rules. UDRs provide a way to customize network traffic routing, and if misconfigured, they can interfere with NSG functionality. 
• Analyze network logs for insights into the traffic flow and identify the source of the incoming traffic. Azure Network Watcher provides tools like NSG flow logs, which capture information about traffic flowing through an NSG, and IP flow verify, which helps you determine whether a specific NSG rule is blocking traffic. You can also use Connection Troubleshoot to diagnose connectivity issues between a VM and another endpoint.
• To isolate whether UFW is causing any conflicts with the NSG rules, temporarily disable it on the VM If the traffic stops after disabling UFW, review your UFW rules to ensure they align with your NSG configuration.
• Otherwise temporarily remove all other NSGs and ASGs (if possible) to isolate the issue. Create a single, simple "deny all on port 80" rule at the network interface level. This will help you determine if the problem is with the NSG itself or a conflict.

Kindly let us know if the above helps or you need further assistance on this issue.

Hi,

Thank you for your detailed response.

I have verified that the only Network Security Group is the one applied directly to the VM, and no other NSGs are present at the subnet level. The NSG is configured to allow only ports 443 and 8443, with all other traffic implicitly denied by default.
besides the NSG diagnostics confirm that DenyAllInBound is denied

Additionally, I have Packetbeat running inside the VM, which shows packets arriving on port 80, but they are being blocked by UFW. This traffic should not reach the VM in the first place, as the NSG default deny rule should have blocked it.

Also please note that it is impossible for me to send requests on this port 80 unless I whitelist my IP, as it is blocked by the NSG. However, I am seeing successful attempts to bypass the NSG from malicious IPs.

I appreciate your help in understanding this behavior.

Thank you.

Hi @nma

I can see that the NSG is still allowing traffic on port 80, even though a Deny rule has been created. This is due to the following condition:

1. If an NSG rule is created with a deny action, the source is the internet or IP address. If the source is set to "Internet," traffic within the same VNet will still be allowed by default because of the AllowVNetInBound rule at priority 65000.

To block port 80 traffic from any source, explicitly set the Deny rule's source to "Any" from all sources or "VirtualNetwork" to ensure traffic within the same VNet. Follow the Ms Doc for more details.

You can check the source of incoming traffic to your virtual machine using NSG Flow Logs. These logs provide detailed insights into network traffic, including source and destination IPs, ports, and whether the traffic was allowed or denied by the NSG rules. Follow the MS Doc about NSG flow log creation.

I hope this helps to resolve your query.

If the above is unclear and/or you are unsure about something, add a comment below.

Hi @@******@vneuron.com

I just wanted to follow up and see if you had a chance to review my response in the comment to your question. Please let us know if it was helpful, and feel free to reach out if you have any further queries.

Hi @@******@vneuron.com

I just wanted to follow up and see if you had a chance to review my response in the comment to your question. Please let us know if it was helpful, and feel free to reach out if you have any further queries.