Date: Thu, 12 Sep 2002 17:30:26 -0400 From: Chuck Swiger <cswiger@mac.com> To: freebsd-security@FreeBSD.ORG Subject: Re: ipfw, natd, and keep-state - strange behavior? Message-ID: <DA6132B6-C696-11D6-90D4-000A27D85A7E@mac.com> In-Reply-To: <001401c25a80$346cbb50$0a00a8c0@groovy3xp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, September 12, 2002, at 01:16 PM, dfolkins wrote:
> From: "Chuck Swiger" <cswiger@mac.com>:
[ ... ]
>> Let me note that the whole intent of dynamic filtering is to permit
>> return
>> connections only in response to internal requests, and it presumes that
>> such connections are somehow "safer". I'm not so confident about that
>> assumption as some people seem to be.
>
> how's that? could you please elaborate?
Sure. What happens if a local user opens a connection to a popular site
which has been trojaned or redirected to malware via DNS hijacking? The
fact that you're using dynamic filtering doesn't help a bit when the
originating connection was local.
>> Frankly, I'd prefer to use static rules with aggressive ingress *and*
>> egress filtering,
>
> but wont that actually result in an overly permissive firewall? e.g., if
> you want to allow outgoing http connections, you have to allow packets
> from
> any external server port 80 to a whole bunch of tcp ports on internal ips.
Nope. While I prefer to use a proxy to centralize web access to the
outside via my interior firewall, you can also do something like:
add pass tcp from $INET $HIPORTS to any 80,443
add pass tcp from any 80,433 to $INET $HIPORTS established
Without performing the TCP 3-way startup (starting with a packet with SYN=
1 and ACK=0), the TCP sequence numbers won't match and the client being
scanned from some random external IP will simply drop the invalid
connection attempt.
>> which also avoids the DoS potential involved with
>> overflowing the number of dynamic connections permitted by a given
>> system,
>> thus causing the stateful firewall to lose track of older legitimate
>> connections. (*)
>
> true, there is that, but having a short enough syn_ udp_ and short_
> lifetime, and high enough number of allowed dyn rules would be pretty
> safe,
> no?
Not that I have seen, although I've never had a firewall which could do
syncookies hit by a DoS. Without that, denial-of-service attacks can
pretty easily overflow the connection database, thus causing all
pre-existing connections to drop, make creating new connections
problematic, and that was as true of a firewall on a multihomed x86 box
running FreeBSD 4.1 (now 4.5), as it was of Cisco hardware running IOS.
> also, i think you forgot to add the footnote that you implied would be
> forthcoming by the (*).
Sort of-- my PostScript ("PS:") was the footnote, but I wasn't consistent
in labelling it as such. :-)
[ ... ]
> but as you may remember in my original inquiry about firewall rules, i was
> trying to allow _outgoing_ ssh connections, not incoming ones.
Ok. Here are the equivalent static rules:
allow tcp from $INET to any 22 setup
allow tcp from any 22 to $INET established
-Chuck
Chuck Swiger | chuck@codefab.com | All your packets are belong to
us.
-------------+-------------------+-----------------------------------
"The human race's favorite method for being in control of the facts
is to ignore them." -Celia Green
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DA6132B6-C696-11D6-90D4-000A27D85A7E>