Block layer 4 traffic for destination blocked on URL filtering

Reply
Highlighted
L0 Member

Block layer 4 traffic for destination blocked on URL filtering

We have a very peculiar situation. There is Azure public PaaS environment connected over express route and we have a Palo inline. Now the destination ip/subnet range is dynamic but we just end to allow few specific URLs. It was all fine where we had url filtering allowing the required destinations and blocked everything while testing from a web browser. However, when tested from any non-browser tool (eg namp), we were able to connect with the destinations over tcp/80 or tcp/443, even though these destinations are blocked under url filtering. Is there anyway to allow access to specific destinations and block (layer 4) everything else ? I tried it with FQDN security rules and it worked.  But the destinations dns records have TTL value in range if seconds to 1 minutes. So fqdn based policy is not a good option for us.

Tags (1)
Highlighted
Cyber Elite

Hi @Biswa 

For the URL filtering approach you have to keep in mind how a PaloAlto firewall is able to allow traffic based on URLs. So in order to see the URL, the firewall needs to allow traffic until the first http get or TLS client hello. This means at least the TCP handshake neds to be allowed generally to even see the packet required for the URL filtering. So actually even when nmap is able to connect, a complete connection to anx website shouldn't be possible. What you could do is keep the URL profile and also add one or more IP ranges for the PaaS service to further restrict the connection.

Highlighted
L0 Member

Hi @vsys_remo ,

 

I do have URL profile, however, minimizing the destination IP range doesn't actually help. Reason is we need to allow whole PaaS IP range as these ranges are not fixed per organisation. The problem with getting tcp/80 or 443 being allowed is that even though I can't do much at application layer still I was able to pass on good amount data (tested with a 250meg txt file) and firewall was allowing this as we didn't have deny rule for unknown-tcp. The other thing I noticed is that firewall was able to change the app-id from web-browsing to unknown-tcp after 3.2k data transmission. So even if I add deny rule for unknown-tcp, someone can still pass on 3.2k of data.

 

Palo App-id.png

Highlighted
Cyber Elite

Got it. But using the whole PaaS IP range is probably still a lot better than 'any'. And as you saw it correctly by further restrictions that only allow ssl/web-browsing you should getting closer to what you want. In general it is not easy with such dynamic services ...

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!