Hi Chris, et all who have suggested that lo0 is the correct place to put these filters,
I’ve been through the Day One book previously, and I suspect Chip’s Safari link is much the same. Except here’s my problem after having gone through that framework - I have my ‘global’ scope (which I believe can also be referred to as inet.0), which holds my MPLS underpinnings - LDP, ISIS and MP-BGP; I have my ‘management’ scope, which is inside a VRF-type routing instance, and is also where my management systems reside; I have other VRF-type routing instances, where untrusted networks reside; I want to allow SSH from my management VRF primarily (which is currently attached to lo0.somthing), and from any interfaces inside inet.0 (i.e.: internal point-to-point core/backbone links) as a backup incase my MPLS core explodes. I want to disallow access from anywhere else. Near as I can tell, on EX physical interfaces, I cannot assign any address at all on an interface unit that is not 0 if it is intended to be ‘untagged’. This means I have no way to separate interfaces from that are in my global scope from interfaces that are inside a routing instance, be it my trusted management instance or more importantly, inside any of the untrusted routing instances. This perceived limitation makes it very difficult to use apply-path (which is a super cool hook!) to select interfaces that I would like to accept something like SSH on. Maybe this is to Chip’s point with regards to his thought that the EX filter space is rather limited, by comparison to other platforms? Maybe this perceived limitation is just my own ignorance? This is why I was curious about the filter mechanism in forwarding options, but perhaps there is a way around my current problem preventing me from attaching to lo0 using apply-path? > On Jul 25, 2016, at 5:15 PM, Chris Jones <ipv6fre...@gmail.com> wrote: > > lo0 is the correct place to put an RE filter. Get the free PDF of the Day One > book "Securing the Routing Engine" here: > http://www.juniper.net/us/en/training/jnbooks/day-one/fundamentals-series/securing-routing-engine/ > > On Mon, Jul 25, 2016 at 1:55 PM, Jason Lixfeld <jason-j...@lixfeld.ca> wrote: > Hi, > > I’m trying to write filters to prevent management access to my system (ssh, > SNMP, etc), and I’m unsure about where to apply them. > > Let’s assume I have IPs configured on a bunch of interfaces, both physical > and logical, and I don’t want the majority of them to be able to accept > management attempts to my system. > > One way to prevent this is is to apply a filter to each interface where there > is an IP configured, but I can’t imagine that scales very well. > > Another way I was reading about is to apply a filter via forwarding-options: > > set forwarding-options family inet filter <filter_name> > > Is this an appropriate way to accomplish this, or should I be looking at a > different method? > > If this is acceptable, my next question is bound to be how a system-wide > filter like that would affects protocols that actually need to talk to the > RE, like BFD, ISIS, BGP, etc., but maybe I can leave that for another thread > :) > > Previously, I tried to apply filters to various lo0 units, thinking those > were the only interface to the RE, but that didn’t seem to help for cases > where the IPs were applied to interfaces other than lo0 units. And I haven’t > been able to find a way to apply a filter or client list specifically to the > ssh service itself like you can with snmp, for example. > > Thanks in advance. > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > -- > Chris Jones > JNCIE-ENT #272 > CCIE# 25655 (R&S) _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
