Easy way to deal with Google SMTP (1e100.net)?

[PeterT]

Anybody found an easy way to deal with allowing SMTP traffic to Google but nowhere else.  The problem here is 1e100.net IP space is all over the place (since it's Google's world wide distrubted cloud) and FQDN address object type, when it even works [bugs all over the place with that code], doesn't allow wildcares.

Really need a day to say something like "allow SMTP to *.1e100.net" because not tying to continually check and update my manual rules for google every time they expand / contract their IP space which they seem to do regularly and I'm also not trying to allow STMP to the world even from the source address in question.

Edit: Just to be clear here for clarification I'm looking to white list these, not black hence the problem

[Brandon_Wertz]

I'm assuming it's not something as simple as gmail, but you're talking about SMTP traffic that's being hosted in Google CDN space?

[OtakarKlier]

Hello,

I think blocking the application would be one approach to this. If you block the application gmail, this should block all traffic to google mail servers.

Hope this helps.

[PeterT]

Correct; google 1e100.net as *.*.*.26 and *.*.*.27 addresses from thousands of blocks and they expand/contrast daily.  Not really an issue for pre-defined google apps signatures but for raw SMTP this is an issue.

[Brandon_Wertz]

You're trying to 'blacklist' "Google" and application "SMTP," this will probably be almost impossible to maintain.  

In general I would think you would want to whitelist what from your company can SMTP out, and it probably would be going to a specific destination or resource.  it it possible to do a whitelist, which would inherently block SMTP anywhere else?

[BPry]

@PeterT,

Or you could utilize minemeld to pull IPs assigned to Google's SPF records, and simply block SMTP traffic to those ranges. Much easier, and MineMeld allows the entire process to be automated. 

Just a thought. 

[PeterT]

@Brandon_Wertz Actually it's the opposite, I'm trying to white list Google hence the problem.

@BPry I've thought about that but never seen any good documentation on MindMeld especially for WhiteListing, not black plus last time I attempted to install it; some years ago, I think we ran into a problem where either it didnt' work with RHEL -OR- it didn't work with RHEL in FIPS mode but that was some years ago so maybe it doesn't hold true anymore.  Still I'm not adverse to labbing this, you got a link to a URI with a similiar setup / walkthru? 

[BPry]

@PeterT,

MineMeld is really the best way of dealing with things like this. Whitelisting or Blacklisting is pretty much the same, you simply build the policy with an allow action instead of deny and utilize the EDL as the destination address on the firewall policy. 

[Remo]

@PeterT

If you need to whitlelist the google servers for sending emails to whatever domain, then the automated approach with minemeld would probably be the best. But only this one here is not that difficult automate by yourself with a little script ... the advantage of minemeld is a lot bigger and almost an overkill if you only use it for this one example.

If you need to whitelist a particular domain (or a few) (I have no idea which hostnames you need to connect to) URL filtering is also a way to go - at least when smtps is used as then the firewall extracts the hostname from the cert / SNI.

[santonic]

What about API and (dynamic) address groups?

On some server make a script that daily (hourly) gets a list of IP addresses, parses it and then adds them to the correct group via API on firewall.

Minemeld would work too, but I'd say for this situation a simple script and few API calls are quicker solution.

[PeterT]

Been a couple years and I'd like to think we have come a long way on a better way to handle this. I'm dreading the future when we all go IPv6 if PANOS isn't updated to handle DNS wildcards in security policy / fw rules; I think we all understand the days of filtering by IP are limited with IPv6 and the every expanding CDN networks / cloud.