Blocking/Alerting on Web Sessions to IP Address Formatted URLs

[TSilverline]

One of my customers has asked if it is possible to block and/or alert upon HTTP or HTTPS connections that are made directly to an IP address instead of a dns name.  The specific IP addresses or DNS name is not defined, they would just like to alert upon this behavior any time it is seen since some malware can be hard-coded with IP addresses and users can potentially use this to bypass URL filtering.

I opened a case with support and was told this is not supported but I wanted to double check, as I vaguely remember this being discussed in a previous training that I attended.

Assuming no encryption has been applied to simplify the use case, is there any way to block or alert upon such behavior?  Can a Regex string be used to match the URI in an HTTP header or something of the sort?  Or is this not possible with Palo Alto firewalls?

Thanks.

[bradk14]

in theory, your plan should work. however there are several caveats, the main one being that when it comes to creating a custom threat object, PA requires a minimum of 7 bytes/characters that are fixed, presumably to minimize the potential of false positives.

I don't see any method of detecting the traffic where you have the required minimum of known characters.

beyond that, there are additional caveats such as that you won't see any it on HTTPS traffic unless you have SSL decryption.

I also feel like while every little bit helps, it may lead into a sense of false security. most malware AFAIK does in fact use domain names, often they are even 'dynamically' generated.

My advice would be to opt instead for the use of EDL/DBL lists and credible threat intelligence feeds and security policies to block them. Many feeds will provide IP based lists in addition to domains, although blocking IPs vs domains has its own caveats to be considered.

[TSilverline]

Thanks for the input.

I am a little confused on how you think it will work if PA requires a minimum of 7 characters that are fixed.

I tried creating a custom signature to match the regex expression \b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b but it keeps telling me pattern invalid no matter how I try to enter it.

I guess this is due to the restriction you mention above, but there is no indication in the alert saying what is wrong.  Can you confirm this is the case?

I do understand this is probably not the best way to block traffic to prevent threats, but I can also appreciate the customer's desire to be alerted upon this slightly suspicious behavior.

[bradk14]

sorry if I was confusing, bottom line is I _don't_ think it will work because of the 7 character non-regex minimum.

you can try something even as basic as .*[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+.* which won't do any IP validation (but arguably http://999.9999.999.999 wouldn't work anyway), but you'll get the 7 byte error.

this is from the tech doc:

1. Every pattern you create must contain at least a 7-byte string with fixed values.
o The 7-byte fixed string can be anywhere in your pattern.
o The 7 values must be fixed, this means no ‘.’ (dot), no ‘*’ (star), no ‘+’ (plus), or other wildcard characters within the 7 bytes.

[TSilverline]

One last question ... could the http:// count as the seven fixed characters?

I tried this but still receive pattern is invalid.

[bradk14]

it depends on which field you are looking at. the URI request which is what I probably would have used in this case is the GET (or POST) line. it wouldn't have http in it. I'm not even sure if the traffic itself would ever actually even have http in it. http:// specifies the protocol to be used, but the actual transmission (e.g. the headers) don't mention http.

in any case, I would start really simple as I mentioned earlier. PA seems to be ultrasensitive about its regex patterns.

I'm still not very hopeful for you in this case, to be honest. even if it does work, I think blocking all IPs is a bad idea and alert is would be fine, but obviously not as effective. the EDL's are pretty much mandatory IMO. PAN-OS 8.0 even comes with a couple of malicious EDL's pre-defined.

[TSilverline]

I see you mention "alert is would be fine."

Is there some other method you know of to alert on the behavior?  I agree that blocking is not ideal, but still searching for a way to alert.  

PAN support is still pending respose to me on this matter as well.

[bradk14]

I only meant alert would be fine in the sense that you aren't blocking anything. I think the potential for false positives is too great.

But no, other than what I've suggested by using threat intel feeds and/or custom DBL/EDLs to block known bads, I don't have any ideas for you that might work.

You should also probably take advantage of the built-in Botnet report

https://www.paloaltonetworks.com/documentation/71/pan-os/web-interface-help/monitor/monitor-botnet

as that will flag traffic of interest to you (users browsing to IP addresses vs fqdn), but that's after the fact, of course.

[BPry]

@TSilverline, 

You might want to see how well creating a rule with the URL Category 'unknown' set to alert would work. All of the direct IPs are going to be flagged as category unknown and most websites resolve to a URL category if they have an actual URL. This would provile you with an alert for browsing directly to an IP address, but it might get you unwanted alerts for URLs that are simply not categorized as well. 

[TSilverline]

Thanks for the suggestions guys.

@bradk14: This was actually what I remembered from my training that I mentioned in my OP.  Thank you for pointing this out as I now have less of a feeling like I am not providing the customer the best response.  At least with the botnet report, there is a method of alerting on IP address browsing within the reports.

@BPry:  This makes sense but yah I can see the potential for false positives being very large.  Will have to do some reporting analysis on their environment to see how often they are detecting such behavior today.