FQDN URLs that change IP addresses quickly

[ksauer507]

PA-3220 Active/Standby Pair

10.0.8-h8

We have a URL we tried adding to a negate policy for inside to outside decryption.  This resolves the ability to pull credit reports into our core financial system.  However the problem is still intermittent.

Its added as an FQDN object.  Here's the thing, If I do an nslookup or go to digwebinterface.com and look it up across multiple DNS servers, it always gives a different IP address.  Without knowing all of their IP's or knowing if they would ever change... we put it in as an FQDN object.  Do you think its only periodically pulling one IP but then the traffic is coming from one of their other IPs?  Its on an akami CDN and we don't want to whitelist all of akami.

[LAYER_8]

Sounds like you could benefit from Minemeld. Dynamically generate an EDL. It went EoL 8/1/21, but it is community supported here on LiveCommunity. 

[ksauer507]

I did have a VM of that installed but it lit up our vulnerability console like a Christmas tree.  When I updated Ubuntu to a newer release, that fixed the vulnerabilities but broke minemeld.  If its EoL I wonder if PA has any future plans for it, or better yet just build this right into PANOS, why require an external server to do all this legwork.  Maybe that's on the roadmap.

[Adrian_Jensen]

---

@ksauer507 wrote:

...Its added as an FQDN object.  Here's the thing, If I do an nslookup or go to digwebinterface.com and look it up across multiple DNS servers, it always gives a different IP address.  Without knowing all of their IP's or knowing if they would ever change... we put it in as an FQDN object.  Do you think its only periodically pulling one IP but then the traffic is coming from one of their other IPs?  Its on an akami CDN and we don't want to whitelist all of akami.

---

What you are describing is Fast Flux DNS... and yes it is a pain to deal with. Basically, you can never insure the DNS result the firewall gets and the result the end client gets, will be the same. The PA will do a DNS lookup for the FQDN object and cache the results. With FFDNS this may be a half dozen results with a very short TTL, say 30 seconds (the PA will cache a maximum of 10 results I believe). But when the client does a nslookup a second or two later it gets 6 different results with a short TTL. 15 seconds after the PA first queried the FQDN in DNS, it refreshes again and gets yet another set of results, invalidating the first set. So the end result is that you can never be certain that the PA and end client are going to have the same DNS results at the same time.

You can get around this doing URL inspection for normal rules, but for doing decryption bypass this is a major pain... My only solution was to setup a script to probe DNS for all the results over time and add them all to an IP address object group included in the do-not-decrypt rule. But then a month or two later the Akami cluster would change and I would have to reprobe/update all the IPs. For us, a bunch of these cases were ultimately caused by Java apps with their own internal cert stores (doesn't use the system store) that we eventually forced our corporate CA cert into to be able to do decryption on the traffic.

[ksauer507]

Ok all connections to this site are from one machine, so we did a negate rule on the source from this machine.  So far it seems our random connection issues have been resolved.

Its an ok risk for this one machine to not be in a decryption policy.  In fact its a lot of financial data, we know what it is and its probably better its not tampered with.

[LAYER_8]

It isn't on the roadmap but the functionality has been ingested by Cortex XSOAR Threat Intel Management (TIM). Cortex XSOAR