There isnt anything in MWG that would bypass as much as you mentioned above (by default).
The only thing that MWG uses reverse DNS for is categorization when we receive an unrated IP. We then lookup the category and reputation based on the reverse DNS results. This is used only as a down selector and can be disabled easily.
Customers can use the property DNS.Lookup.Reverse(URL.Destination.IP). This would return a list of hostnames returned from the reverse lookup. You could then compare that list against another list for whitelisting purposes. However this is infrequently used in my experience.
Let me know if that helps.
Thanks for this very useful info, Jon.
If one were to turn off that reverse lookup... you avoid the attack outline (spammer fakes an RDNS entry on an IP they control), and have you given up as an administrator... anything? Is there a down side? Sure, categorization of legit IP's reverse hostnames, but is the worst of that just possibly blocking more traffic based on that?
In this context, can you define what is meant by an "Unrated IP-based url"
Are we talking about categorization, IP reputation, risk... all these terms kinda smear together still for me and it's an opportunity to really know what's going on.
Could you go through an example of how policy thinks on this realm?
Let's take this numeric URL, from an Indian news site:
URL Status Categorization Reputation http://18.104.22.168/ DNS reverses to an informational hosted-by.reliablesite.net (which does not forward DNS). Categorized URL - Technical Information
Would the handling of these modulate if I unchecked that box?
Note that even though the reverse of 22.214.171.124 it's hosted-by.reliablesite.net.
If you forward resolve hosted-by.reliablesite.net you get nothing.
It seems, however to have a categorization in Trusted Souce:
URL Status Categorization Reputation http://https://www.trustedsource.org/sources/redirect?r=http%3A%2F%2Fhosted-by.reliable site.net&c=5D0B7CB3AEA7AAF50ACF431E18813D34hosted-by.reliablesite.net Categorized URL - Technical Information Minimal Risk
So, suppose I'm a bad guy. I control an IP. I poof my DNS PTR record to point that IP back to hosted-by.reliablesite.net.
Q: in what circumstances will MWG consider http://my.badguy.ip.addy/ as "Technical Information" ?
Q: Will simply unchecking that "Do a backwards DNS lookup" box in policy and searching policy for references to DNS.Lookup.Reverse(URL.Destination.IP) put me in the clear from such attacks?
To clarify if this is not already understood, everything related to reverse DNS only applies when we receive a request by IP, not by domain name. MWG will not rely on the reverse lookup information if a domain name is given, we would only rely on the result of a forward lookup (another setting in the screenshot above).
The setting mentioned above relates to categorization and reputation of the given URL. In general they should go hand in hand.
MWG will evaluate the given URL against the local or cloud database, and if that yields no result, we'll check the other variations of the URL for a result. Using your example, lets say the URL is: http://126.96.36.199/blahblahblah
If that URL is uncategorized, since it's an IP, we will get the DNS name returned, which is "hosted-by.reliablesite.net". The MWG would then evaluate a reverse lookup variation of the URL (based on the setting mentioned above): http://hosted-by.reliablesite.net/blahblahblah
The URL checker written by Erik Elsasser highlights this functionality pretty well, see screenshot below:
Speaking to your questions:
1) MWG would not rely on reverse DNS for a URL like http://my.badguy.ip.addy/ since that is a domain name... unless you really meant to type an IP http://x.x.x.x in which case, if x.x.x.x was uncategorized and the reverse lookup yielded something like hosted-by.reliablesite.net (which is categorized as Technical Information) in the results.
2) Yes it would. Though this would also be contingent on you using these results to make critical policy decisions. In some cases customers use the DNS.ReverseLookup just to populate a log field.
Let me know if that helps.