> I believe what is being requested is a kind of state engine that is > smart enough to modify packets on the fly and recognize "related" > packets. This is common in many commercial firewalls and also in > SunScreen and Netfilter/IPTables.
Okay. To avoid confusion from here on in, take this as a definition: Def'n: (Kernel Proxy) A kind of state engine, implemented in the kernel that is smart enough to modify packets on the fly and recognize "related" packets. The naming comes from the ipf kernel-proxy for FTP. > I would argue that this is not quite the same as a proxy. However, > now-a-days, the difference between a stateful/NAT firewall and a Proxy is a > fine line and somewhat subjective. No. It's not a proxy. It's a "kernel proxy." We are ALL talking about the same thing here. > > Yes. Since the kernel sees traffic a packet at a time, it essentially > > has to "fake" the statefulness of TCP in order to track these things. > > It's a layer violation. It's also next to impossible, without re- > > implementing TCP. > What I don't get, is if what you are saying is true, how do commercial > firewall products work? They don't have access to the O/S source code and > manage. What am I missing? They implement a kernel proxy. They also implement kernel proxy bugs. (c.f. explots for both ipf and checkpoints' FTP proxies, allowing the malicious user to create arbitrary firewall states) > How is it a layer violation? Can't you link in with a callback or > something? Why do you have to re-implement TCP? Because you have to inspect traffic at the TCP level in order to determine what "related" traffic to allow through the firewall. (i.e. monitor the FTP control connection). Unfortunately, you are looking at packets as they arrive (i.e. the IP layer). If packets all arrived uniquely, un-fragmented, and in-order, this would be straigtforward. They do not. See Ptacek and Newsham's paper for a thousand reasons why this is a bad assumption. > In the end, I think Daniel is right. It sounds like a cool feature, but > someone would have to step up or help fund it. Perhaps some day, I'll learn > enough to be able to contribute... And if they are going to step up, they should think about scrub, bpf, and userland. Not kernel and payload inspection. Now, I've said my peace. Back to slackin' -kj
