Ben Nagy wrote
>
> Are you sure that the "forward with replies" in the GUI is stateful? I was
> under the impression that it just filtered statically on the ACK bit.
That's right, Gauntlet's packet filter is not "stateful".
The "f* with r*" simply means that when the rule is created, a second one
is created by eversing the src and dest and specifying the ACK bit.
so there is no caching of IP packets.
one idea that may (or may not) show that is to configure such rules,
and then run "ipfs -p" to check what rules are really configured.
This may or may not work, as ipfs may be aware of the trick and show what
you entered, not what's in the kernel.
Anyway, you can check the real thing using a program like netcat.
> Additionally, I'm pretty sure that there is nothing that you can
> do via the GUI that you can't do by editing the config files directly.
the config files, yes, but not the netperm-table. the ip filter config
programs
read both netper-table and gauntlet.conf, so there may be stuff in
gauntlet.conf
that is not in netperm-table.
if admitting that the filter is not stateful, then you can generate the
rules
manually, this means that for each outgoing paccket allowed to be forwarded,
add a second rule for its response, by simply reversing source and
destination
informations, and if it is TCP, by also specifying that the packet must have
the ACK bit set.
> It's a minor point anyway. The real question is this - why are you using
> Gauntlet if you're permitting traffic via the packet filtering engine?
> Gauntlet is an ALG (Application Level Gateway).
yes, the plug should be ok in most cases.
There are however situations where people would like to use the forwarding
at the IP level:
- If the security provided by the ALG and if the routing of packets
does not introduce any problems (either you have NAT or you're
routing between hosts that know how to find their peer), then
using the plug introduces a useless performance overhead.
- if using a "multi-channel" protocol, the plug may be unusable.
as an example, you can't use the plug to relay ftp traffic. so, you'll
need the ftp proxy. but what if you're relaying multi-channel traffic
for which no proxy is available.
I personally dislike such protocols and feel angry after all those webbyguys
who develop stupid protocols without serious analysis of security
consideration.
(now that I said it, I feel happier!)
>
> Are you positive that what you want can't be done with a plug proxy? AFAIK
> the only reason that they have the ugly packet filter is to block certain
> types of traffic at the shim driver level to offer a level of
> protection for the host stack.
shim? this is for NT, isn't it?
anyway, I am pretty sure they developped the packet filter to provide
transparency for the proxies (via the absorb). Then having a filter goes
with having other functionalities.
regards,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
