In message [EMAIL PROTECTED]
, Paul D. Robertson writes:
On Mon, 15 Apr 2002, Saso Virag wrote:
Yes, but you can't rip everything out if you expect to run a commercial
firewall's GUI.
Sure you can. It's a Good_Thing(sm).
Commercial GUIs want X...
*Sigh* You seem to be right. As usual.
Symantec Firewall (Raptor) has had a true CIFS proxy for about 5 years. It only
supports TCP file sharing (port 139) but that allows file sharing between an internal
segment and a server segment with relative safety (as much as any files sharing
protocol can have). That is, an intruder could
Symantec Firewall (Raptor) has had a true CIFS proxy for about 5 years. It only
supports TCP file sharing (port 139) but that allows file sharing between an internal
segment and a server segment with relative safety (as much as any files sharing
protocol can have). That is, an intruder could
Paul D. Robertson wrote:
Right, but I was wondering if the [w2k] frag reassembly code is
now threaded where it wasn't before.
Nah. I just think someone clued them in on having more than 100
reassembly slots being a good idea. That, and zapping old
reassemblies when the slots are full.
In message [EMAIL PROTECTED]
, Paul D. Robertson writes:
[And I can already see myself falling for Paul's bait.]
On Thu, 11 Apr 2002, Simon J. Gerraty wrote:
proxies to all interfaces anymore. Also, since most are hybrids, they
normally also packet filter everything on OSen where you can't
On Sat, 13 Apr 2002, Mikael Olsson wrote:
CPU load logarithmically. The effects of a low-bandwidth jolt2 were
really interesting to watch.)
You should see what happens when someone fixes the code. We've got
someone who looked at Jolt2 and said Oh, I can see what they MEANT to do
here...
In message [EMAIL PROTECTED],
David Lang writes:
On Mon, 15 Apr 2002, Saso Virag wrote:
[snip]
That's true, but people really _should_ know better than running Xserver
and *gasp* CDE X manager on the firewall box. Operative word being
*should*. :-)
unfortunantly the alturnative seems to be
Paul D. Robertson wrote:
[on reassembly DoS]
I wonder if it's really better under 2k+patches, or if the
threading is just better?
It isn't a total system DoS. It just DoSes fragment reassembly.
The CPU load of the target system won't even increase a single
percent.
(This isn't jolt2 I'm
On Fri, 12 Apr 2002, Mikael Olsson wrote:
[on reassembly DoS]
I wonder if it's really better under 2k+patches, or if the
threading is just better?
It isn't a total system DoS. It just DoSes fragment reassembly.
The CPU load of the target system won't even increase a single
percent.
proxies to all interfaces anymore. Also, since most are hybrids, they
normally also packet filter everything on OSen where you can't just rip
out all the non-proxy stuff (Solaris anyone?.)
Actually you can remove big hunks of solaris's kernel. Just rm -f the
modules. You keep doing this
Paul D. Robertson wrote:
On Wed, 10 Apr 2002, Mikael Olsson wrote:
(unless specifically asked to do so, of course)
You're not getting off that easy!
I'll take that as specifically asking me to be specific.
Isn't it fairly common for (commercial) proxy firewalls to apply
On Thu, 11 Apr 2002, Mikael Olsson wrote:
I'll take that as specifically asking me to be specific.
N, you should take that as specifically not specifically asking you to
specificly be specific.
Hey! If you get to assume set up correctly (especially for turnkey
boxes), I get to assume
Paul D. Robertson wrote:
[on pseudo-reassembly]
Ah, but with never allow overlaps, do you take the first thing, or
reject the packet? If you've already let the first frag go, IMO you're
skating a fine line. I've always preferred to see reassembly before
passing with a complete drop if
On Thu, 11 Apr 2002, Mikael Olsson wrote:
Then AGAIN, linux machines deliver all fragments backwards,
Yep, the stack is um...quirky in behaviour. Fixing it isn't easy either
:(
Not everyone was asked- a lot of OSen weren't used for Web
servers back then, and some of those that were
Paul Robertson wrote:
On Thu, 11 Apr 2002, Mikael Olsson wrote:
Then AGAIN, linux machines deliver all fragments backwards,
Yep, the stack is um...quirky in behaviour. Fixing it isn't
easy either.
Fixing it would be a Good Thing(tm).
When I first realized what the Linux IP stack
On Wed, 10 Apr 2002, Mikael Olsson wrote:
(unless specifically asked to do so, of course)
You're not getting off that easy!
If you're refering to simply filling up the available reassembly
slots, that will DoS fragment reassembly on a proxy equally well.
It depends on how much checking
Paul D. Robertson wrote:
At some point, you add enough state tracking information to have a thing
as complex as a stack. At that point, the benifits start to go south
(worrying about size of state tables, lifetime of entries, etc.)
This happens pretty much immediately when you start
On Tue, 9 Apr 2002, Mikael Olsson wrote:
(And hopefully, a firewall developer is a bit more careful than the
average general o/s developer, although I know that there are exceptions
to that. But that reflects on proxy developers aswell, so I refuse to
call this a valid point in the
On Tue, 9 Apr 2002, Mikael Olsson wrote:
Is it just ISNs that get randomized, or do (either product) they also
track and rewrite all sequence numbers? Is it for both sides of the
connection (in either case)?
If you modify the sequence numbers in one direction, you'd darn better
keep
Paul D. Robertson wrote:
What I meant by both sides is do you also randomize the server's
sequence number going back to the client (first ACK), not just the
client's ISN going to the server.
Okay, we're probably just confusing eachother with fuzzy
terminology here. I'll try it in
On Wed, 10 Apr 2002, Mikael Olsson wrote:
Is there an off switch for performance if the firewall just
sits in front of a Web farm for instance?
Nope. But that has never been a problem. Removing the randomization
would buy you very little in performance and has the potential to cost
you a
Paul Robertson wrote:
ICMP unreachables to the external interface is much less
dangerous than to every client.
Hm. I must be missing something here. I don't think of inbound
ICMP errors as being very harmful. (Given that they've
been structurally verified and so on.)
Inbound unreachables
Paul Robertson wrote:
[on not disabling sequence number randomization]
Hmmm, I suppose that you've not had to do dual in-line boxes with
asymetric routing at Web farms then?
I don't really understand what you mean here, but if it involves
packets only passing through the firewall in ONE
On Wed, 10 Apr 2002, Mikael Olsson wrote:
Hm. I must be missing something here. I don't think of inbound
ICMP errors as being very harmful. (Given that they've
been structurally verified and so on.)
Anything inbound is a potential tunnel, and everything inbound needs to be
rate-limited.
On Wed, 10 Apr 2002, Mikael Olsson wrote:
Okay then damnit :)
marketroid warning
Ubj qbrf shyy-qhcyrk tvtnovg guebhtuchg teno ln?
/marketroid warning
I can't easily imagine an architecture where placing a single point of
failure/filtering upon such a pipe would be my first choice :-P Is
From: Mikael Olsson [EMAIL PROTECTED]
Okay then damnit :)
marketroid warning
Ubj qbrf shyy-qhcyrk tvtnovg guebhtuchg teno ln?
/marketroid warning
I've always thought 802.11b should have used ROT-13 instead... :)
--
Gene Lee
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Paul D. Robertson wrote:
On Wed, 10 Apr 2002, Mikael Olsson wrote:
Okay then damnit :)
marketroid warning
Ubj qbrf shyy-qhcyrk tvtnovg guebhtuchg teno ln?
/marketroid warning
I can't easily imagine an architecture where placing a single point of
failure/filtering upon such a
Ngh. I'm not really in the right mood for this right now; I think
I got too worked up over UPnP. Ah, heck, I'll give it my best shot. :)
quote quote dissect attempt to avoid stupid 10KB message limit
Paul Robertson wrote:
On Mon, 8 Apr 2002, Mikael Olsson wrote:
(Or strip URG data,
(I'm redirecting this back to this list -- there might be others
that are interested)
Someone wrote (off-list):
What is the inherent danger in URG data? I know that interactive apps rely
on this for things like quit and control c etc.?
The inherent danger is in applications that do not
## On 2002-04-08 21:03 +0200 Mikael Olsson typed:
MO
MO
MO 2. Ditto ICMP without breaking unreachables, etc.
MO
MO I'm not quite following you here.
MO Unless of course you're talking about a transparent proxy
MO doing some ICMP error magic that I'm not familiar with,
MO in which case you
Rafi Sadowsky wrote:
## On 2002-04-08 21:03 +0200 Mikael Olsson typed:
MO Paul Robertson wrote:
MO 2. Ditto ICMP without breaking unreachables, etc.
MO
MO I'm not quite following you here.
MO Unless of course you're talking about a transparent proxy
MO doing some ICMP error magic that
*plug*
openbsd's PF can do this also (see modulate state).
*plug*
AFAIK the Cisco PIX will randomize TCP ISN numbers
What makes yours unique ?
Thanks,
Rafi
--
Rafi Sadowsky
[EMAIL PROTECTED]
Network Operations Center | VoiceMail:
On Mon, 8 Apr 2002, Mikael Olsson wrote:
This is definately true. (If, of course, this is what Paul was
referring to, which is not unlikely; I'm just being my usual
dim bulb self.)
These days I tend to worry more about unreachables (most of the
'connected' 'Net seems to handle larger MTUs
33 matches
Mail list logo
