search

MicrosoftDocs / azure-docs

Open source documentation of Microsoft Azure
https://docs.microsoft.com/azure
Creative Commons Attribution 4.0 International
10.31k stars 21.48k forks source link

Azure Firewall rules not working as expected #21504

Closed ekramyelnaggar closed 5 years ago

ekramyelnaggar commented 5 years ago

Hello, as per this article : https://docs.microsoft.com/en-us/azure/firewall/rule-processing , Azure Firewall rule processing logic is as follows :

Network rules are applied first, then application rules. The rules are terminating. So if a match is found in network rules, then application rules are not processed. If there is no network rule match, and if the packet protocol is HTTP/HTTPS, the packet is then evaluated by the application rules. If still no match is found, then the packet is evaluated against the infrastructure rule collection. If there is still no match, then the packet is denied by default.

But this is not what I saw till the moment , let me explain :

I created an ILB ASE and used NSGs to secure the ASE Subnet , but in order to completely secure the outbound connections you have to use Azure firewall along with the NSGs , and I did this by following this article : https://docs.microsoft.com/en-us/azure/app-service/environment/firewall-integration

but the problem is I found that the Firewall is allowing all outbound traffic , for example : from the Kudu console of one of the ASE Apps I executed the following command :

tcpping www.google.com >> I can get response that the connection was made without any issues as follows : Connected to www.google.com:80, time taken: 46ms Connected to www.google.com:80, time taken: <1ms Connected to www.google.com:80, time taken: <1ms Connected to www.google.com:80, time taken: <1ms Complete: 4/4 successfull attempts (100%). Average success time: 11.5ms

But if I make a Network rule to deny a specific internet IP , then and only then I cannot connect to it from the App.

In a nutshell Application rules are not making any effect , I even created an application rule to deny http/https traffic from the ASE subnet to www.google.com , and I still able to connect to www.google.com as explained earlier !!

can anyone support me here what is missing or what is wrong ? thanks :)

SubhashVasarapu-MSFT commented 5 years ago

@ekramy-elnaggar Thanks for the feedback! We are currently investigating and will update you shortly.

vhorne commented 5 years ago

@ekramy-elnaggar

Your test might not be valid. Application rules operate on HTTP/HTTPS traffic, and your tcpping test probably generates just TCP packets to test the TCP three-way handshake on the port (no HTTP/HTTPS packets generated). If your tcpping utility has a an HTTP mode, try that. Or, try browsing to www.google.com from a web browser to generate HTTP/HTTPS traffic.

ekramyelnaggar commented 5 years ago

@vhorne thanks for your reply , I will check alternative method and feedback.

yairt1974 commented 5 years ago

@ekramy-elnaggar - this is just an artifact of the current implementation, but no traffic is getting to www.google.com. Azure Firewall has a transparent proxy listening on 80/443 to return a custom error message (currently done only for HTTP). Tcpping doesn't get a response from www.google.com - this response is from the transparent proxy. We plan to change this implementation and not respond to any syn packets in future. At any case, there is no security impact here. You can test with a web client and see the payload or simply run tcpdump to see it.

ekramyelnaggar commented 5 years ago

@yairt1974 : thanks a lot for your valuable reply , it explained the situation completely :)

SubhashVasarapu-MSFT commented 5 years ago

@ekramy-elnaggar We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

hugoro commented 5 years ago

I was having the exact same issue as @ekramy-elnaggar. However, I'm not pinging. I'm running curl and other websites rather than the ones authorized on the application rule are sending back an HTML response. E.g. Expected, no results from running over a different port: @vm-tests-fw:~$ curl http://portquiz.net:8080

Not expected, using 443 allowing only .azmk8s.io,auth.docker.io,,*cloudflare.docker.io,registry-1.docker.io:

@vm-tests-fw:~$ curl http://portquiz.net:443 `<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

400 Bad Request

Bad Request

Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.

Apache/2.4.18 (Ubuntu) Server at 127.0.0.1 Port 443
` I guess this is not a return from the proxy @yairt1974 has mentioned. Basically, after allowing ports 80 and 443 in the network rules, all traffic is allowed no matter what is in the application rules.
hugoro commented 5 years ago

Found the issue.. I was having a network rule allowing ports 80 and 443.

According to Azure Firewall rule processing logic:

Therefore, the network rule was getting a match all the time bypassing the application rules. I haven't seen any reasonable help from Microsoft stating this needs to be checked first.

Hope this post helps to mitigate that and save you time troubleshooting.

EmFl commented 2 years ago

@yairt1974 Sorry to barge in more than 2 years later but it looks like that transparent proxy is still in place today as testing open ports via telnet still give a connected status on 80 and 443 where curl calls are failing. Do you know if this new implementation is tracked somewhere so that we can follow progress ? Or is there a documentation which explicitly mentions this "limitation" so that I can point people doing network test to it ? Thanks!