Protecting Juniper SRX Management by Client IP Address

This paper explains how to restrict management access to the Juniper SRX firewall. Instead of using firewall filters bound to an interface, I show how to use policy rules and address book objects.

Overview

In order to protect the SRX firewall beyond the default settings we need to control which IP addresses are permitted access to the management ports.

In particular, if you really need to manage the SRX via it’s external or Internet interface then you’ll need to configure the addresses allowed and block all others.

At my place of work, we have a number of client SRX firewalls that we normally manage in-band via a site-to-site IPSec VPN. The trouble here, is that if the VPN goes down or we need to change the way it works then we need to manage the client SRX in a way that is out of band from the normal VPN access. In order to do that, we enable management on the external interface of the remote SRX and carefully restrict the IP addresses that can connect to it.

Requirements

The requirements are fairly straightforward:

• Permit SRX management access only from the specified IP addresses
• Deny SRX management from any other addresses

How to Configure the SRX

The old way of doing this was to use firewall filters, these were ACLs that would be bound to an interface to filter incoming packets at a low level. If you’ve been using Google to search for a solution to this problem then a lot of the hits will be using this method.

A better way is to use the security policy rules. With this method, instead of using a usual destination zone of dmz or trust we use the junos-host zone to say that the destination is the SRX device itself.

First of all, configure the IP address from which you want to manage the device. This can be either a single CIDR address or a group. Here’s the definition for a simple group:

Here’s the policy code:

A few points are worth noting here.

Firstly, note that I allow https and ssh from the addresses in the address book, and then block all others to those ports. If I need to, I could add logging to the blocking rule.

Note that I also allow all others to go through at the last rule – this isn’t a typo. By doing this the SRX will fall back to the services allowed on the interface or the zone that the interface belongs to. If I did the usual firewall-like rule of blocking everything at the end then other things like pings and IKE for VPNs will stop working. Probably not what you want to do.

The same sort of policy could also be used to restrict other system services and protocols from reaching the SRX – services such as IKE, BGP, and so on.

Verification

Verify that the policy change has been configured properly:

The command show security policies from-zone untrust to-zone junos-host detail will show you more information about the policy.

Testing

Testing is fairly easy:

• Test ssh and https access from an allowed client IP, connections should be permitted
• Test ssh and https access from a client which is not allowed, connections should be denied

Also check that your logging options are logging the access.