Mark Atwood, Project Manager <mark.atw...@ntpsec.org>:
> There are a couple of different but very similar angles of approach to
> explain why a network security experts will not trust a userspace daemon to
> control it's own defensive packet filtering.
>
> The UNIX concept: each tool should do one thing, and do it well. The ntpd
> should no more do packet filtering than the packet filers should implement
> the NTP protocol.
>
> Separation of knowledge. The packet filers know how the network stack is
> implemented, and how the local site has plumbed them. Repeating this
> knowledge in the ntpd violates DRY, and are hard to keep in sync.
>
> Separation of configuration. Network configuration tools know to speak to
> the packet filter API and know to speak to the switch APIs. Asking those
> tools to speak to every random daemon's implementation of each own control
> interface is asking too much.
>
> Assumption of mistrust. Admins and devops people now assume (after 40+
> years of bitter experience) that all daemons are broken and insecure. That
> lack of trust extends to any given daemon's own (probably half assed and
> poorly reviewed) implementation of packet filters.
>
> Assumption of corruption. Once a bad guy has presented a malicious packet
> stream to a daemon, you cannot trust that daemon's own logging, or trust
> any part of that daemon's execution paths. Including the execution of it's
> own packet filters!
>
> Linus's Law, and it's weaknesses. The packet filters are the point where
> Linus's Law has engaged about packet filtering. The slightest quiver of
> uncertainly in the packet filter implementations will trigger CERT
> conference calls, corporate sev2 incidents, and personal line-by-line
> hand-execution code audits by technical leads. The discovery of yet
> another parsing bug in a userspace daemon is called a "Tuesday".
>
> The "half of common lisp" narrative. Just like every large programmable
> system eventually has a poorly specified implementation of parts of Lisp,
> every local single process userspace implementation of packet filtering is
> just a poorly specified poorly performent implementation of the the packet
> filter.
That's a good explanation. I'm keeping a copy.
(Gradually, gradually, I remedy my ignorance of infosec.)
I could summarize it something like this:
"We have removed packet filtering by interface name because we judge it's
a security-defect attractor. The place to do this is in kernel-level packet
filters and firewalls, which get much more scrutiny; good admin practice
in this century is to not trust usespace packet filtering at all."
This opens a can of worms, though. Should we drop the entire interface command?
[[interface]]
+interface+ [+listen+ | +ignore+ | +drop+] [+all+ | +ipv4+ | +ipv6+ |
+wildcard+ | 'name' | 'address'[/'prefixlen']]::
This command controls which network addresses +ntpd+ opens, and
whether input is dropped without processing. The first parameter
determines the action for addresses which match the second parameter.
That parameter specifies a class of addresses, or a specific interface
name, or an address. In the address case, _prefixlen_ determines how
many bits must match for this rule to apply. +ignore+ prevents opening
matching addresses, +drop+ causes +ntpd+ to open the address and drop
all received packets without examination. Multiple +interface+
commands can be used. The last rule which matches a particular address
determines the action for it. +interface+ commands are disabled if any
of the +-I+, +--interface+,+-L+, or +--novirtualips+ command-line options
are used. If none of those options are used and no +interface+ actions
are specified in the configuration file, all available network
addresses are opened. The +nic+ command is an alias for +interface+.
I'm inclined to think dropping this would be a good thing. There's a
lot of code complexity behind that, and that bit abour interface
commands being inoperative if you choose the wrong command-line option
raises my shoot-self-in-foot alarm.
I'd like to hear from our security officer about this. I'd also lilke
to hear from people with lots of ops experience like Hal and Matt.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
