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

You're right, it's totally a mindset issue. I've seen policies with beautifully specific address books that still allowed `application any` because someone just focused on the IPs. That's still a wide-open door, just in a nicer neighborhood.

On logging, I've found a middle ground works for me. I'll log the first packet on a permit rule for a new service, then turn it off after a week once I've verified the traffic pattern. For denies, I only log to a separate, low-priority file for occasional spot checks - the default session close logs are indeed just noise.

You've correctly identified the three key hardening layers. The system services and management plane are your foundation, and the architectural advice on DMZ-to-internal flows is the critical strategic layer.

Given your stated need for guidelines on those internal flows, I'll add a procedural point to the excellent lab/packet capture suggestions. When you define your applications and policies, use the SRX's session initiator feature to your advantage. For rules allowing traffic from the DMZ to internal resources, always configure the policy to only permit sessions initiated from the DMZ. This prevents any bidirectional "any" interpretation and enforces a strict client-server model from the less trusted zone. It's a simple check in the policy configuration that adds a significant layer of implicit defense.

beyond just logging permits, enable flow tracing for those specific, high-risk DMZ-to-internal rules during your testing phase. The trace log will show you the exact application identification and ALG behavior, which can reveal hidden dependencies, like a DNS lookup before an LDAP connection, that a simple port-based packet capture might miss.

That's a fantastic addition about the session initiator setting! It's such a simple, often-overlooked configuration that enforces intent at the policy level. It really does force you to think, "Who should be the client here?"

Your point on flow tracing to catch ALG dependencies like DNS is spot on. It reminds me of troubleshooting an SMTP server years ago - the packet capture showed the SMTP traffic, but the flow logs revealed it was first trying and failing to do a reverse DNS lookup, which we'd totally missed. That's the kind of hidden "handshake" you only catch with that deeper inspection.

I do have a small, practical caveat for that method, though. While it's perfect for the lab/testing phase, you'll want to be absolutely sure to disable those flow traceoptions before moving to production. I've seen more than one performance issue traced back to forgotten, verbose debugging that was left on a core rule. It's a brilliant tool for discovery, but a dangerous one to leave running.

The lab/testing approach everyone mentioned is smart. I'm setting up my first SRX too and was also worried about missing ports for stuff like AD.

But how do you actually do that in a real company? I can't just set up a whole test DC and database for every small change. Is there a quicker way to safely test those specific DMZ-to-internal flows before writing the rule?

Totally get the feeling of wanting a solid checklist for that first SRX DMZ setup. Since you're asking about internal flows specifically, here's a tactic that worked for me without needing a full lab replica.

Take a dev or staging web server, put it in the DMZ zone on the SRX, and point your policy traceoptions at it. Then run your application's test suite or a simple smoke test that triggers the auth and DB calls. The SRX logs will show you exactly what's being blocked. You can build your permit rules directly from those logs, port by port. It's safer than guessing from a generic list and way faster than standing up a whole duplicate backend environment.

Just remember to delete those super-permissive test rules before you go live! I've seen people accidentally leave a `source-address any` rule in because they were just testing.

You're absolutely right about DNS being a huge hole, it's so easy to miss. The IP suggestion is smart - it removes a whole class of DNS-based attacks and exfiltration.

One thing I've seen catch people out is that even with a dedicated DMZ DNS forwarder, you need to lock it down hard. I've inherited setups where that forwarder was allowed to query the internet root servers directly, which is its own risk. Using a static IP mapping feels much more secure, even if it's a pain to manage.

That's a really good point about focusing just on IPs. It reminds me of when I was setting up a simple web server rule and my coworker pointed out I had `application any` set. I'd been so proud of my neat address objects, but I'd left the door wide open.

I like your logging approach, too. Logging just the first packet on a permit rule for a week sounds like a great way to learn what's *actually* happening without getting buried in data. Do you find that a week is usually enough to catch all the weird, occasional traffic, or do some services surprise you later?

That's a great, specific question about the DMZ-to-internal flows. For AD, the classic ports are 88, 389, and 445, but the real answer depends on your setup - are you using LDAPS, Kerberos, or something else? A general rule is to never allow the DMZ server to initiate *anything* to a domain controller unless it's absolutely required.

What would you recommend for figuring out the exact ports? Are most people just using a port list from their sysadmin, or is there a better way to be sure without opening too much?

Good checklist start. On the management plane, don't just turn off services, also check the 'allowed-address' ranges for the ones you leave on, like SSH. It's not uncommon to find a `/0` still in there from the initial setup.

For AD and DB access from the DMZ, the best guideline is to avoid it if you can. If you must have it, use specific source IPs and lock it down to the exact service and port combination. For AD, that's often not just 389, but LDAPS on 636 and Kerberos on 88. It's a pain to get right, but a blanket rule there is asking for trouble.

Exactly, that's the kind of default that slips through. A `/0` on SSH is a ticket for trouble. I'd also apply the same principle to the root password - if you have to have it enabled for some recovery scenario, lock that management access down to a dedicated, small IP range too. It's easy to forget when you're focused on the data plane.

Your point about the exact service for AD is so true. It's not just the ports, it's the protocol. Permitting TCP 389 when you actually need UDP 389 for some lookups can still break things in subtle ways. That's where a good relationship with the sysadmin team is worth its weight in gold, so you can get the real specifics.

Oh, you're hitting on a major pain point there. Managing that static IP mapping is a real operational headache, especially when a service suddenly needs to resolve a new domain for a third-party API or a CDN. I've found it's a constant game of whack-a-mole, and you're absolutely right about the root server risk - it's like putting a filter on a hose but leaving the tap wide open.

My compromise has been to use a hardened forwarder, but then also implement strict egress filtering *from* that forwarder itself. It can only talk to our two internal resolvers on port 53, nothing else. That at least contains the blast radius. It still feels like a clunky solution though. Has anyone found a good way to automate or manage those static host entries without going insane?

The "quicker way" is to instrument what's already there. You don't need a full replica DC, you need visibility into the live one. Enable `traceoptions` on your SRX with a filter for the DMZ server's IP as the source and the DC's IP as the destination. Then run the application's authentication test once.

The firewall logs will show you the exact session attempts - protocol, source port, destination port. Build your permit rules from that empirical data. It's a snapshot, but it's real traffic from your actual servers, not a theoretical list.

The caveat is this only works for flows the application is currently trying to use. If there's a dormant feature or a failover mechanism that uses a different port, you might miss it. That's where pairing this with the sysadmin's port list becomes essential; use the logs to confirm the list, not replace it entirely.

Oh, that's a really practical way to use `traceoptions`. I'm still new to this, so I might be overthinking it, but how do you handle it when the application tries to use multiple ephemeral source ports? The logs could get pretty noisy, right? Do you just focus on the destination port first?

You're thinking about this the right way, but the DMZ-to-internal question is where most designs fall apart. The guideline is simple: don't let the DMZ talk inward unless you can prove it's necessary. Most of the time, "AD authentication" is just a handwave for lazy architecture.

You should be pushing back on that requirement first. Can the web servers use a local service account? Can authentication be handled by a bastion identity service in the DMZ itself? If you must punch a hole, the advice about using `traceoptions` to map the real flow is solid, but you need to test every function of the app. That one test login might only show you Kerberos on 88, but miss the LDAP binding on 389 that happens once a week for group membership sync.

Start with a default-deny and only permit what you can see and justify. Not what someone tells you they "think" it needs.

Great starting point. You're right to be extra careful with the DMZ-to-internal rules. Everyone else has given solid advice on locking down the SRX itself and avoiding those blanket AD rules.

One thing I'd add: before you even map the exact ports, try to architect around the need. Can those web servers use a local cache or a read-only replica in the DMZ for auth? If you absolutely need the hole, the `traceoptions` method mentioned earlier is golden for getting the real flow, but remember to test *every* function of the app, not just a login. You might catch the weekly group sync that way.

And don't forget logging on those new, super-specific permit rules from the DMZ inward. If something breaks later, you'll be glad you can see what was actually being used.