19.08.07 @ 21:51 Eduardo Meyer wrote:
Yes, dynamic rules in ipfw are not intended for supporting state created
in the middle of the session, wuth the default sysctl settings it will
be
kept for 1 second (which, however, is enough for shaping of fast
transfers). I think, precise controlling of dynamic rules from both
userland and kernel should be added to ipfw, to modify existing rules on
the fly (or even more features, like pfsync). As a hackish dirty
workaround, may be it should be only one keyword, something like
"keep-state-middle", to create normal dynamic rule without initial SYNs.
But you've said about even more complex behaviour, like init on TCP,
continue with UDP. That's difficult to implement in kernel, and may be
even not suitable for ipfw. Currently (I think), you can try to emulate
this behaviour by divert'ing tagged by ng_tag packet to userland
program,
like snort_inline (from ports collection) with needed scripting, which
will trigger adding proper rules to firewall (you should also care about
expiring that connection on FINs and RSTs, though).
That's exactly the point. However, from a simplistic and probably
ignorant point of view on this matter, like mine, I believed it to be
in fact a much more simple "state", which would only compare IP
addresses (src<->dst) for the match, so I could just
ipfw add X allow { tcp or udp } from any to any keep-iponly-state tagged
Y
It would be helpfull with many protocols which in fact use a transport
proto (like TCP) to do actual session initialization while using
another transport proto (UDP, DDP, whatever) for the real traffic;
many things do this nowadays;
Would such a feature be possible?
Yes, in theory. But I'm not sure that such a patch will be merged into
official tree. Also, one can think about link negotiation with another IP
(src<->dst) pair, not this hosts: imagine direct FTP transfer between two
servers or P2P application where clients negotiate connection parameters
via server, and then only actual data in undetectable connection flows
between them. So in general case you again need specialized protocol
analyzer. For example, in your case with only IPs - can you say when
dynamic rule will expire?
--
WBR, Vadim Goncharov
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
