How can the Palo Alto control the age-old URL filtering bypass of typing in the IP address of a site, rather than the hostname?
As an example, some of our students last week did:
1. www.minecraft.net via web browser is blocked (category: games)
2. do an nslookup or dig for www.minecraft.net
3. type IP address into browser and then get through
When Palo Alto saw this, the IP address was in URL Filtering category 'unknown'. Disabling unknown would cause too many false positives with lots of different sites.
Now in some cases, the IP address does resolve to a particular category and this isn't a problem. It's only when it comes back as 'unknown' that we have an issue.
Does anyone have a solution to this? Is it possible to block access to any IP address URL, unless it is in a valid URL category?
Edit: oh yes, we're on PA-4050s, 5.0.2, using the PAN-DB URL Filtering module.
I think in cases where the IP addresses resolve to unknown, the only way to filter in those situations will be to have FQDN address objects for those URLs and add those FQDN objects in a security rule that is a clone of the original rule and deny access to the destination addresses that resolve to those urls.
Make sure to add this cloned rule on top of the existing rule. I know this does not seem like a feasible option as it can get tedious with more and more urls but unfortunately there isn't another way to do it, not that I can think of at least.
Thanks for your thoughts, yes that can certainly be done once we identify that students are going to a particular site. But then once we block that site they will just move on to the next site.
Other web filtering products have default rules like 'block any URLs with IP addresses', which is sort of what I'm looking for, although it would be good to allow known safe URL categories to still be allowed, even with that rule.
##Does anyone have a solution to this? Is it possible to block access to any IP address URL, unless it is in a valid URL category?
For the HTTPS /SSL the traffic category resolution is based on the Certificate Common Name so this catch should not affect SSL traffic as Both IP address and URL would fetch the same Certificate. <Assumption: No SSL Decryption Used>
For the HTTP traffic there would be no way for the firewall to differentiate between the IP address based URL typed by User and Browser referenced IP address URL (actual URL) in the GET Request.
Also a large number of CDN (content distribution network) servers and Media servers do use the IP address based URL ,so this implementation would affect their access, adversely.
Actually there is a way (or several)...
This might break stuff so you need to test it first with the most common urls you use but you can create a signature which force use of "Host:" in the http-request and in combination with this disallow "Host: <ipv4>" (dont forget ipv6 aswell).
Something like (if I get the logic right :smileysilly:):
http-request: host must exist AND not (host eq <ipv4> OR host eq <ipv6>)
<ipv4> in this case would be a regexp (or such) that identifies *.*.*.* where the * is numbers 0-255.
Another method would be to put a webproxy and do the filtering regarding ip-based requests in there.
The best method I think is to simply disallow "unknown". This way you will also avoid new uncategorized malware-sites aswell. The drawback (as already mentioned) is that you need to setup a method so you can easily take complains from clients and add uncategorized sites to a whitelist (that is a client complain that they cannot reach a specific site - then you can manually allow this url until its being categorized (perhaps at the same time send a hint to PA to put this url into PANDB)).
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!