Topic: Filter for securing SRX admin access

[viggo]

Hi,
I want to secure admin access to a SRX. The SRX is managed via a NSM system. Does anyone have a suitable filter script for that? I tried the following, but when applied the system drops off the NSM.

I'm new to Junos, any help is very welcome.

Thanks!

------------
term access-term1 {
    from {
        source-prefix-list {
            management-access;
        }
        protocol tcp;
        destination-port [ ssh https 7800 7803 7804 http ];
    }
    then accept;
}
term allow-ping1 {
    from {
        source-address {
            0.0.0.0/0;
        }
        protocol icmp;
        icmp-type echo-request;
    }
    then accept;
}
term block-rest1 {
    then {
        reject;
    }               
}
---------------------------------

[frogmanclay]

Assuming you are applying this to the lo0 interface, do you have any dynamic routing running?  Because that filter would be blocking that as well.  Generally when I lock down a device I leave a term in there for NSM but just state the source IP and I don't specify a port.  (Now I realize that this leaves room for someone to spoof a source address and cause a small amount of havoc, but the chances of that are pretty small because they would have to know the right IP.)

Hope that helps,
Clay

[viggo]

Hi Clay,
thanks for the reply.
Yes, this filter is applied to the lo0 interface. If I remove the port restrictions, then the communication with the NSM works fine, thanks.  I don't understand what causes the issue when the filter is restricted I didn't see any other port used.

Thanks,

[adamc]

The reason your filter won't work is the default deny at the End. This is a non-stateful filter. Which means that the source request from the junos router/firewall e tc will originate potentially on a dynamic-port. The reply will have to assume the source-port is permitted. Otherwise the Junos device won't allow the reply from the far end back.

Basically I do my LO0 filters as such..
term 1 permit what you want to permit and from where. (Specifically ports, source address or prefix-list etc)
term 2 the same as term 1 accept deny, and don't include any source address information
term 3 permit all. (this permits replies back for traffic originating from the router. IE NTP, BGP, OSPF, DNS, syslog, ETC)

So really the only difference, remove the ping permit policy, change term 2 to be the same as term 1 accept deny and make the last term a default permit.

[screenie.]

I wrote this on the subject:

Introduction.

A lot of engineers who switch from ScreenOS to JUNOS are missing the manager-ip functionality found in ScreenOS. This technote gives a similar functionality for a srx or J-series.

Solution.

The solution found here is described is many documents, but I tried to make a small summary. Look for “protecting the Routing Engine” when looking for background information.
 

The srx does not have the manager-ip build-in. Coming from the packetbased JUNOS version something came be build to achieve the same functionality. The core of this are stateless firewall filters. This filters can be applies to interface. But instead of applying it to all interface it’s applied between the PFE (packet forwarding engine) and the RE (Routing Engine). Consider that as at the point traffic enters the SRX itself instead of being forwarded. The to do this is to apply a filter to the loopback interface. The loopback stack is used in sending traffic from PFE to RE.
On packetbased JUNOS you have to write rather complex filters, but for the SRX most for the work is already done in zone or interface host-inbound-traffic settings.
The add-on to this filtering on prefixes.

The first step in the config is to create a list of networks (or hosts) allowed to manage. For this you can use a prefix-list:




policy-options {
    prefix-list manager-ip {
        10.0.0.0/8;
        192.168.4.254/32;
    }
}

This list is referenced in the actual filter, so this is where you can change your manager-ip’s!

The next step is to write a filter. On trick thing here is you have to include all your management services in the first rule! (Don’t forget NSM when you use it)

firewall {
    filter manager-ip {
        term block_non_manager {
            from {
                prefix-list {
                    manager-ip except;
                }
                protocol tcp;
                destination-port [ ssh https telnet http ];
            }
            then {
                reject;
            }
        }
        term accept_everything_else {
            then accept;
        }
    }
}

As you can see management traffic (when using a port listed in destination port) is rejected except when coming from an address listed in the prefixlist “manager-ip”.

Finaly we have to apply this filter to the loopback interface:

interfaces {
        lo0 {
        unit 0 {
            family inet {
                filter {
                    input manager-ip;
                }
            }
        }
    }
}

And don’t forget to commit confirmed when trying this on a remote system…….

You'll have to add the nam ports.