Block layer 4 traffic for destination blocked on URL filtering

[Biswa]

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.

[Remo]

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.

[Biswa]

Hi @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.

[Remo]

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 ...