Junos OS

Hi there...

Just trying to get up to speed on JunOS and applied the following filter to protect against SSH access mainly (and allow some things).  It doesn't appear to be working and I'm puzzled why.  Please note that vlan.4094 is the only layer3 interface on this device and is purely for management (EX4200 switch).

    vlan {
        unit 4094 {
            family inet {
                filter {
                    input PROTECT;
                }
                address xx.xxx.33.42/29;
            }
        }
    }

firewall {
    family inet {
        filter PROTECT {
            term SSH {
                from {
                    source-address {
                        xxx.xxx.115.176/28;
                        xx.xxx.20.115/32;
                    }
                    destination-port ssh;
                }
                then accept;
            }
            term OSPF {
                from {
                    source-address {
                        xx.xxx.33.40/29;
                    }
                    protocol ospf;
                }
                then accept;
            }
            term DROP {
                from {
                    protocol ospf;
                    destination-port [ ssh telnet ];
                }
                then {
                    discard;
                }
            }
            term DEFAULT {
                then accept;
            }
        }
    }
}

Thanks very much,

Paul

Hi,

your filter does not seem right.

            term SSH {
                from {
                    source-address {
                        xxx.xxx.115.176/28;
                        xx.xxx.20.115/32;
                    }

                    protocol tcp; <---- IMPORTANT!!!!

                    destination-port ssh;
                }
                then accept;
            }

            term DROP {
                from {
                    protocol ospf; <---- MUST BE TCP!!!!
                    destination-port [ ssh telnet ];
                }
                then {
                    discard;
                }
            }

Kind Regards

Michael Pergament

If this worked for you please flag my post as an "Accepted Solution" so others can benefit. A kudo would be cool if you think I earned it.

Thank you for the reply - I have removed the OSPF portion for now as it's not important (to this discussion).

My current filter looks like this:

firewall {
    family inet {
        filter PROTECT {
            term SSH {
                from {
                    source-address {
                        xxx.xxx.115.176/28;
                        xx.xxx.20.115/32;
                    }
                    protocol tcp;
                    destination-port ssh;
                }
                then accept;
            }
            term DROP {
                from {
                    destination-port ssh;
                }
                then {
                    discard;
                }
            }
            term DEFAULT {
                then accept;
            }
        }
    }
}

Here's my problem now though - it works on one EX4200 switch just fine .... doesn't work on another one.  So I thought this has to be where/how it's applied .. but both switches are identical from a layer3 perspective:

    vlan {
        unit 4094 {
            family inet {
                filter {
                    input PROTECT;
                }
                address xx.xxx.33.41/29;
            }
        }
    }

Very puzzling... the *only* difference is that one of the EX4200's is stand alone and the other EX4200 is actually a pair in a VC configuration.  Same software load as well.....

To top it off, on an EX3200 we have in production it filters SSH no problem without the "protocol tcp" included....

Thoughts? 😉

Paul

Paul,

The loopback interface can be looked at as the virtual path from the packet forwarding engine to the routing engine.  So to properly secure your switch, you should apply the firewall filter on that interface (and only that interface).  Applied there is most effective for two big reasons.  One, it only effects traffic headed to the routing engine, meaning it does not effect transit traffic.  Two, in all cases it only has to be applied in that one place.  If you had multiple L3 interfaces, and you weren't applying the filter to the lo0 interface, then you would have to apply it to every L3 interface for it to be effective.

Generally speaking, it is a good idea to do a "commit confirmed" when applying a loopback filter, this is because ALOT of people accidentally lock themselves out their device because of a mistake in the filter.  IE. blocking the dynamic routing protocol by accident.

Hope this helps,

Clay

---

@frogmanclay wrote:

Paul,

 

The loopback interface can be looked at as the virtual path from the packet forwarding engine to the routing engine.  So to properly secure your switch, you should apply the firewall filter on that interface (and only that interface).  Applied there is most effective for two big reasons.  One, it only effects traffic headed to the routing engine, meaning it does not effect transit traffic.  Two, in all cases it only has to be applied in that one place.  If you had multiple L3 interfaces, and you weren't applying the filter to the lo0 interface, then you would have to apply it to every L3 interface for it to be effective.

 

Generally speaking, it is a good idea to do a "commit confirmed" when applying a loopback filter, this is because ALOT of people accidentally lock themselves out their device because of a mistake in the filter.  IE. blocking the dynamic routing protocol by accident.

 

Hope this helps,

Clay

---

Thanks very much Clay - do appreciate it.

Yes, we have learned that the loopback makes the most sense - in this particular scenario we do not have an IP address on the loopback address itself.  In the Juniper world, will it work to apply it to the loopback to protect the device anyways?  Sorry if that sounds confusing - coming from Cisco to Juniper currently 😉

You do not have to have an IP address assigned to the loopback interface for the filter to work.  It will work fine just the way it is.

As for omitting "protocol tcp" in the firewall filter, that is your choice, just understand that without it, you are matching on ANY packet with port 22 as the destination port.  So the possibility is there that you would be matching traffic that you are not meaning to.  Of course with the filter only applied to the loopback interface and all management type traffic using well known ports, the chances are small that it will match anything else.

Another common mistake people make is instead of specifying "destination-port" they just say "port".  In that case it will match the specified port number whether it is the source or destination port.  (Which is not a bad thing if you are trying to block both incoming and outgoing ssh sessions from a box.)

Either way, I hope this helps,

Clay

Hi,

>To top it off, on an EX3200 we have in production it filters SSH no problem without the "protocol tcp" included....

If you omit protocol tcp statement then it would pass SSH BUT it would also pass a lot of other packets which have "right" hex value on specific offset! So just trust me and do NOT omit "protocol tcp" :).

Kind Regards

Michael Pergament