I think I'm not being clear here, so let me try this with some pictures:
clean 1---+--- clean 2
If clean 1, clean 2, or clean 3 trust any or all of the other two "clean"
networks, you need to install an INPUT filter on "evil 1." An example of
this is someone who has a router for connecting various parts of their
company together, but also has a link to the internet. You want to protect
the entire company from the evil network, but the clean networks are all
under common security administration.
clean 1---+--- clean 2
If, however, there is NO trust between the clean networks (e.g. they belong to
different customers or different organizations or whatever), then there is no
need to use input filters, in fact, input filters are the WRONG thing to use,
since it doesn't protect "clean 1" from an attack from "clean 2" or "clean 3".
Examples of this model would be a service provider doing security for 3
evil 2 ---+--- evil 3
In this example, you're trying to shield one "clean" network from three evil
networks. In this case, installing an output filter on the "clean" interface
is the way to go. An example of this configuration would be to protect a set
of sensitive machines from the rest of a company (or the rest of the
Now, on to specifics...
> I knew about the performance penalty, but "more complex to configure" ?
> How so, exactly ?
It depends entirely on what your configuration is... but as an example,
people tend to do things like "permit RIP to the local router" on their
input filters. Relying on the router to permit packets to itself is
easier to deal with (of course, you are trusting your router to be more
secure than a unix host, but I do :-) ).
> > [I assume that means "how vulnerable to router-based attacks" - see
> > next question]
> > Well, not very secure, even if you try really hard, since no routing
> > protocol I know of (eg, RIP, OSPF, BGP) was designed with security in
> > mind. Even the clear-text "authentication" scheme in OSPF can easily be
> > defeated with address spoofing and a bit of sniffing. SNMP can be a
> > gaping hole, too. On top of that, they have complex real-time software,
> > which IMHO means lots of potential race conditions and other security
> > holes, which you can't detect since you don't have the source (unless
> > you know something I don't ;-)
> > I would tend to disagree with you there.
> That's your right, of course ;-), but could you be more specific ?
Well, if you're going to conjure up that because a router has complex
real-time software, there are going to be a lot of security holes, I think
you're pretty far off base. A router doesn't end up with things like
rdist, a router is not a general purpose computing machine. A router
doesn't let you install your own version of /bin/su, etc etc etc.
Don't get me wrong, I will most definitely not say that routers don't have
security bugs! :-( What I'm saying is that you're making this into a
mysteriously complex device, when in fact, it's far simpler and in the usual
case, far more secure than a typical box that you find on the net, if for no
other reason than it's not a general purpose box.
> > Yes. If nothing else, they're vulnerable to dictionary attacks, address
> > spoofing and hijacking.
> > Again, depending upon how you configure them.
> Right. I should have written "as vulnerable as hosts".
> > [snip]
> > With tacacs you can use a one-time-key server (ala S/key or Enigma Logic)
> > which makes them quite secure (contact the support folks for pointers).
> How does tacacs work, and how secure does it feel ? (meaning, any known
> (potential) holes/weaknesses ?)
Read the protocol RFC and weep. If you're vulnerable to sniffer attacks, the
current TACACS protocol is a problem. This is something we inherited from the
TIPs and TACs of ARPA days.
On the good side, the use of current TACACS protocol in combination with
authentication that one time passwords (e.g. an s/key based tacacsd or Enigma
Logic DES gold cards) means that you're not vulnerable to replay attacks.
I've said about all I can say on that subject.