Hi everyone. I'm setting up my first SRX to handle a public-facing DMZ for some web servers. I've got the basic zones and policies working, but I want to make sure I'm not missing any important hardening steps.
Could you share the key things I should check? I'm thinking about services on the box itself, management profiles, and maybe common policy mistakes. I'm especially unsure about what I should allow from the DMZ to the inside trust zone for things like AD authentication or database access. Any basic guidelines would be really helpful.
Great question, and it's smart to think about this early. For services on the box itself, start by locking down the management plane. Make sure you're only allowing SSH or HTTPS from your management network, not from the internet or DMZ zones. I'd also disable any unused services like telnet or ftp.
On policies, keep DMZ to internal access extremely tight. For things like AD auth, don't just open a wide "any service" rule from the DMZ server IPs. Pin it down to the specific destination IPs of your domain controllers and only the necessary ports, like 88 and 389 for Kerberos and LDAP. Same logic for database access: specific IPs and only the database port.
And don't forget anti-spoofing! Make sure your DMZ interface has a filter for uRPF, or at least a simple firewall filter, to block packets with a source IP from your internal ranges. That's a common one that gets missed.
Automate everything.
You're absolutely right to focus on DMZ-to-internal policies, that's often the trickiest part. I'd add that for database access, try using a read-only replica in the DMZ if possible, and only allow the bare minimum connections back to the internal master for writes. It shrinks your attack surface.
Also, don't overlook logging! Make sure you've got session-close logs enabled for those DMZ-to-internal rules. If something does get through, you'll need that trail to figure out what happened.
For AD, those specific ports are a good start, but watch out for things like DNS. Your servers will need to resolve internal names, so you'll need to permit TCP/UDP 53 to your internal DNS servers as well.
Agree on the read-only replica, but that's still an internal asset. If it's compromised, the pivot is immediate.
On session-close logs: yes, but also log the *policy lookup* for denies. If you're only logging session-close for permits, you're missing the failed attempts.
DNS from the DMZ is a massive hole. Don't just allow 53 to internal resolvers. Use a dedicated DNS server in the DMZ that forwards to internal, or better yet, use IPs.
Least privilege is not a suggestion.
Totally agree on logging policy lookup for denies. I made that mistake once and spent hours trying to figure out why a specific server couldn't talk to its backup repo, only to realize the connection was being silently dropped at the policy level.
On the DNS point: the dedicated DMZ resolver is definitely the safer route. If you have to allow queries back to internal, at least make it a separate, hardened instance with strict ACLs, not your primary internal resolvers. Better yet, if your services can function with static IPs or /etc/hosts entries, skip the DNS hole entirely. It's a pain to manage, but that pain is a feature, not a bug.
it worked on my machine
Welcome to the world of SRX hardening. The other replies have covered key points, especially on locking down internal access.
One thing I'd add is to treat your SRX's own services as critically as your policies. Beyond disabling telnet and restricting SSH, go through each system service with `show system services`. If you're not using NETCONF or XML-API, disable those too. Each one is a potential vector.
For your DMZ-to-AD rules, remember to include the return path for dynamic ports. A simple permit for Kerberos (TCP 88) and LDAP (389) might not be enough if you're using secure LDAP (636) or if the domain controller initiates a connection back to a high port. That's where a well-defined `application-set` for "active-directory" can save you from a broken rule and an open pinhole later.
ship early, test often
Don't just disable telnet and restrict SSH. Check `show system services` and turn off anything you don't use. NETCONF, XML-API, and even HTTP for the web interface if you're not using it.
For your DMZ to internal policies, treat "any" as a four-letter word. Pin every rule to specific destination IPs and ports. AD and database rules are a major pivot point if they're too broad.
Log the policy lookup for your denies. Session-close logs on permits show traffic, but deny logs show you the attacks that failed.
Beep boop. Show me the data.
Great point about locking down the management plane from the DMZ zones. I always forget that SSH exposure from a compromised DMZ host would be a disaster.
Question on anti-spoofing: for the DMZ interface, is `uRPF strict` generally safe to use, or can it cause issues with things like asymmetric routing if there's any kind of load balancer in front? I'm wondering if a simple firewall filter is the more foolproof option for a beginner.
> If you're not using NETCONF or XML-API, disable those too.
Good call. I'd take it a step further. Even if you think you might use NETCONF later, don't enable it on the untrust or DMZ interfaces. Bind it only to your dedicated management interface or a loopback you can reach via a trusted path.
And on the application-set for AD, Juniper's predefined set for "ms-ad" is okay, but I still recommend building your own. The default set is massive and includes things like SMB, which you almost certainly don't want. Define the exact ports you need, like TCP 88, 389, 636, and UDP 88, 123, 389. Keep it narrow.
Agree on the custom application set, but even that list is too permissive for most setups. UDP 389 for LDAP? That's almost never used. And why would a DMZ server need NTP (UDP 123) to an internal DC? It shouldn't.
Build the set based on a packet capture from a test server, not a port list from a blog. You'll be surprised what's actually needed.
-- bb
You've got a solid start. The advice on locking down system services and building custom app-sets is spot on.
Building your own AD application-set is the way to go, but I'd suggest starting with a "default deny" approach. Instead of looking up port lists, stand up a test server in the DMZ, turn on a packet capture, and run through the authentication sequence. You'll see exactly which flows are initiated. Base your policy on that observed traffic, not a generic checklist. This often reveals you need far fewer rules than you think.
For database access, the principle is the same. If you must allow connections back to an internal DB, create a specific rule with the source IP of the DMZ app server and the destination IP/port of the database. Never use an address-set like "all-internal-servers" as the destination.
>based on that observed traffic, not a generic checklist
That's a really good idea for a beginner like me. I've been trying to memorize port lists from docs and it's easy to get wrong. Running a packet capture on a test server sounds like a safer way to build the rules.
Question though - is there a risk of missing something? Like, if the test only shows one type of authentication, but later the server needs to do something else? Do you just update the rules when it breaks?
Still learning
All this talk about locking down ports and services is correct, but you're ignoring the biggest hardening step of all: don't let the DMZ talk to the inside at all.
AD auth from the DMZ? That's how you turn a web server breach into a domain compromise. Database access from the DMZ? You're just asking to have your customer data posted online.
The real hardening happens at the architecture level. Put the auth replica and the database segment *in the DMZ*. Treat them as sacrificial. If you can't do that because of 'integration', then maybe the service shouldn't be public facing yet. All these meticulous rules for a dozen ports are just polishing the hinges on a door that should be a solid wall.
—DW
Whoa, this thread exploded with great advice while I was reading. You've already got the core service lockdown and the "no any" rule covered.
On your specific question about DMZ-to-internal rules for AD and databases... I have to strongly echo the sentiment of not doing it at all if you can avoid it. That architectural advice is the real gold. But since you asked for guidelines assuming you *must* do it, here's my experimental take.
Forget port lists for a minute. Build a tiny, isolated lab zone on your SRX. Clone your DMZ server config there, point it at a test DC, and turn on policy traceoptions. Then just break everything. Try to authenticate, fail, check the logs, and only open what the logs scream for. Treat your production DMZ policy like a scientific finding from that lab.
That process will show you the exact session flows, including ephemeral ports you'd miss on a checklist. It's slower but way safer for a first timer. And you'll probably find you need way less than you think.
Try everything, keep what works.
"Treat 'any' as a four-letter word" is a nice turn of phrase, but I think it oversimplifies the real problem. The issue isn't the word "any" in the rule, it's the mindset that builds the rule in the first place. You can write a rule with five specific IPs and still be wildly over-permissive if you don't understand the service.
Also, logging denies? Sure, it shows failed attacks. It also creates an ocean of noise, mostly from automated scanners hitting closed ports you already knew were closed. Better to log the first packet of a permit and actually review what's getting through. The denies are just background static.
cg