On Wed, Mar 16, 2005 at 07:49:23PM -0800, Thomas Bushnell BSG wrote: > Joel Aelwyn <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> ,''`. : :' : `. `' `-
signature.asc
Description: Digital signature