Guide: Hardening an SRX for an internet-facing DMZ.

Absolutely right on building your own AD set. The predefined one is a minefield of ports you'd never want open from a DMZ.

A practical tip I use is to create that custom application-set, but then apply it as a *service negate* in a rule above my permit. So the rule denies anything matching the over-broad "ms-ad" set, then a more specific rule below allows my narrow custom set. It's a good safety net if the predefined set gets updated or referenced elsewhere in the config.

Also, double-check the protocol definitions. For example, UDP 389 is often needed for simple LDAP binds, but if you're only using LDAPS, you might not need it. The narrow list is great, but getting the protocol right for each port is just as important.

Your approach with the hardened forwarder and its egress filter is smart, it's the right way to contain it. That whack-a-mole feeling is real, and I've seen teams burn hours on it.

One thing that's helped me is using a dedicated DNS resolver in the DMZ, but feeding it a zone file that's generated from our CMDB or IPAM. That way, the static entries for critical services are automated, and you can still allow recursive queries for external domains like APIs or CDNs, but *only* from that resolver. It shifts the management burden to maintaining a single source of truth, which is usually easier.

It's not perfect, but it's better than manual config. Do you have any kind of IP management system in place that could be tapped for that?

That lab method is solid, but it's also a big cost. The real trick is convincing whoever holds the purse strings to pay for a replica environment just for testing firewall rules.

If you can't get that budget, do the next best thing: negotiate a hard downtime window for the prod DMZ. Use the same traceoptions method but directly on the live firewall during that window, then roll back if it fails. Frame it to the app owners as "paying for certainty with time instead of hardware." It usually gets them to reconsider if they really need that AD hole.

That's a tough sell for a lot of shops. Even getting a maintenance window can be a battle. How do you handle the rollback plan? A commit confirmed timer, or are you manually backing out the changes if the test fails?

I love the spirit of this, but it's often a non-starter in the real world. The architectural purity breaks down the second someone asks, "Where do we get the threat intel feeds?" or "How does the WAF talk to the SIEM?" Suddenly you're back to punching holes, just for management traffic instead of the app.

That's where a zero-trust overlay inside the DMZ itself becomes critical. You're still building a wall, but you're also adding checkpoints and gates inside the DMZ perimeter so a single compromise doesn't hopscotch to the database segment.