Jeff Garzik wrote: > Caitlin Bestler wrote: >> David S. Miller wrote: >> >>> I personally think allowing sockets to trump firewall rules is an >>> acceptable relaxation of the rules in order to simplify the >>> implementation. >> >> I agree. I have never seen a set of netfilter rules that would block >> arbitrary packets *within* an established connection. >> >> Technically you can create such rules, but every single set of rules >> actually deployed that I have ever seen started with a rule to pass >> all packets for established connections, and then proceeded to >> control which connections could be initiated or accepted. > > Oh, there are plenty of examples of filtering within an established > connection: input rules. I've seen "drop all packets from <these> > IPs" type rules frequently. Victims of DoS use those kinds of > rules to stop packets as early as possible. > > Jeff
If you are dropping all packets from IP X, then how was the connection established? Obviously we are only dealing with connections that were established before the rule to drop all packets from IP X was created. That calls for an ability to revoke the assignment of any flow to a vj_netchannel when a new rule is created that would filter any packet that would be classified by the flow. Basically the rule is that a delegation to a vj_netchannel is only allowed for flows where *all* packets assigned to that flow (input or output) would receive a 'pass' from netchannels. That makes sense. What I don't see a need for is examing *each* delegated packet against the entire set of existing rules. Basically, a flow should either be rule-compliant or not. If it is not, then the delegation of the flow should be abandoned. If that requires re-importing TCP state, then perhaps the TCP connection needs to be aborted. In any event, if netfilter is selectively rejecting packets in the middle of a connection then the connection is going to fail anyway. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
