On Wed, Mar 16, 2005 at 07:49:23PM -0800, Thomas Bushnell BSG wrote:
> Joel Aelwyn <fenton@debian.org> writes:
>
> > If you really want this fixed, I suggest finding someone who is well versed
> > in both network security issues and Internet protocol fundamentals (not
> > just TCP or even just IP, but all the other lovely beasties out there) and
> > convincing them it's worth their time (I hear money is often an excellent
> > motivator). The issues involved with writing a serious, production-capable
> > network stack are really quite non-trivial (and yes, I *do* speak from
> > personal experience in this).
>
> We have a network stack, thank you very much.
>
> The question is: which specific features do you want?
>
> "Deny by default" is all you mentioned, and that's already done.
> Next?
Fine, if you want to get pedantic, the following is a bare minimum of
capabilities I would expect from any network processing on a 'real'
(non-toy) network stack, where 'network stack' means everything between
hardware driver and delivery of data to a userland application. It's late,
so this may not be exhaustive.
* The ability to associate a network interface with an IP host address,
including network/netmask information for that IP subnet, and capable
of handling CIDR networks.
* The ability for an interface to receive, by default, only traffic that
is destined for that interface. (Non-promiscuous mode; promiscuous mode
availability is a big plus, but not required from the OS point of view)
* The ability to check all inbound and outbound traffic (as well as
throughbound if the system is capable of operating as a router between
multiple networks) on any interface against a series of filtering
rules.
* Filtering rules must be able to match against any supported IP protocol,
including protocol-specific information (ports for UDP and TCP, for
example), as well as ICMP (including message types). IP packets must
be able to be matched against source and destination network/host
values, as well as additional IP information (such as TOS bits).
* Filtering rules must be able to accept, reject, or drop (silent reject)
network packets. The ability to manipulate the network stack decisions
further (adding routing information) is a bonus, as is the ability to
trigger a sub-chain of rules for evaluation.
* The ability to log rejected or dropped traffic specifics.
* The ability to log per-rule traffic statistics (packet count is required;
packet size total is nice; other statistics may be useful).
* The ability to match certain exceptionally useful flags in very
common IP protocols (SYN, ACK, FIN, RST, etc, for TCP, as an example).
Unless marked as 'nice to have', everything above is a *must* for running
even basic firewall configurations on a host expected to face the Internet.
If you can do those, and configure them in some semi-sane fashion, then
you probably meet the expectations reasonable people would have for "basic
firewalling".
Or, in summary:
* The ability to talk to a modern (CIDR) IP network.
* The ability to look at the relevant header information on any protocol
required to run as a buildd (includes IP, TCP, and UDP at the very least,
quite possibly others I can't name offhand).
* The ability to accept, reject, or drop packets based on the above.
* The ability to monitor, both statistically and specifically, what the
filtering rules are doing.
I'm fairly sure there are things I'm forgetting, as well, but if your
network stack can do the above, extending it to do anything I've forgotton
is unlikely to be problematic for any code with a remotely sane internal
architecture (hell, Linux can do it, and I don't consider the network
internals to be all that sane...)
--
Joel Aelwyn <fenton@debian.org> ,''`.
: :' :
`. `'
`-
Attachment:
signature.asc
Description: Digital signature