CERT VU#539363
From: Mike Hoskins (mike@adept.org)
Date: 10/16/02
- Next message: Chuck Swiger: "Re: CERT VU#539363"
- Previous message: Jess Kitchen: "Re: FW: monitor ALL connections to ALL ports"
- Next in thread: Chuck Swiger: "Re: CERT VU#539363"
- Reply: Chuck Swiger: "Re: CERT VU#539363"
- Reply: Darren Reed: "Re: CERT VU#539363"
- Reply: David Schultz: "Re: CERT VU#539363"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 16 Oct 2002 13:02:53 -0700 (PDT) From: Mike Hoskins <mike@adept.org> To: freebsd-security@freebsd.org
I'm sure everyone saw this on Bugtraq, firewalls, firewall-wizards, etc...
But I noticed Apple was quick to resond with a 'we're not vulnerable'
regarding OS X and wondered if we could draw similar conclusions.
From their "Solution" section:
"Use firewall features that detect and block flood traffic"
I assume they mean things like the PIX can do... Monitor for excessive
SYNs from foreign hosts and throttle connections (or deny them entirely
after a threshold). However, if the attacker used randomly forged source
addresses to an open port on the firewall, I don't see how these features
would really help.
"Use dynamically resizeable state tables"
Couldn't this hurt more at some point? Assuming the attacker has time and
is able to forge IPs... A state table has to either become full
(reach net.inet.ip.fw.dyn_max) or use all available resources at some
point, right? Hard to say which is better.
"Use separate timeout values for initial sessions"
net.inet.ip.fw.dyn_syn_lifetime ?
"Use dynamically adjustable session timers (Aggressive Aging)"
Do they mean the net.inet.ip.fw.dyn_* timers? If so, what sort of
algorithm would do this "dynamic" adjustment, and based upon what
criterea?
A couple possible cases...
A large number of rules are created for a given host... So the timeout
values for rules associated with that host are cut short until the total
rules from that host return below some threshold.
Or maybe a lot of rules are created for a set of hosts causing the state
table to grow to within some threshold of net.inet.ip.fw.dyn_max, causing
the lifetime of all rules to be shortened and hopefully create more room
for additional rules.
"Allow connection tracking to be disabled"
I.e. Turn off statefulness? I suppose that could give one time to find a
real solution, but it may require a lot of work. :)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
- Next message: Chuck Swiger: "Re: CERT VU#539363"
- Previous message: Jess Kitchen: "Re: FW: monitor ALL connections to ALL ports"
- Next in thread: Chuck Swiger: "Re: CERT VU#539363"
- Reply: Chuck Swiger: "Re: CERT VU#539363"
- Reply: Darren Reed: "Re: CERT VU#539363"
- Reply: David Schultz: "Re: CERT VU#539363"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|