Re: [gentoo-security] firewall suggestions?

[Ben Cressey]

I will freely admit (as has already been made apparent on this mailing list)
that I am essentially ignorant when it comes to the RFCs.  It seems plain
that any normal reading of RFC 793 disallows dropping packets without
sending a RESET.

I think your watch analogy is sound, and I find the social/politeness
premise quite agreeable.  Based on personal observation, though, I would say
that the vast majority of packets that my firewall drops are almost certain
to be malicious.  (Connections to the Windows networking ports originating
from outside the subnet, connections to common trojan ports, etc.)  So it is
more the case (from my perspective) that I am not dignifying someone who's
clearly looking to go around and break other people's watches with a
response.

As far as the potential for a DoS attack goes, the scenario as I envision it
is this:

1)  Attacker and Host have similar bandwidth resources at their disposal.
Attacker wants to perform a DoS attack on Target's connection, which is
capable of being saturated by Attacker's resources alone.

2) Attacker spoofs TCP connection requests so they appear to be originating
from Target's address, and sends them to Host.  Host, being RFC compliant,
responds by sending a REJECT packet to Target.

3) Attacker uses all his available bandwidth to send these requests.  Host
dutifully replies to each one, using his own bandwidth and filling up
Target's.  Even if Target is dropping them as fast as it can, there are
still more coming than his connection can handle.

Note that the attacker's bandwidth can be substantially augmented using
typical DDoS methods.

>From the Target's perspective, it appears exactly as if Host is the only one
behind the attack, and from a certain point of view this is accurate (i.e.
Host really is sending out a lot of packets to Target that Target definitely
doesn't want.)

I am sure there are a variety of preventative measures that make this less
plausible (rate limiting REJECT responses etc), and it could be that I am
totally overlooking something which makes it entirely ineffective.

However, REJECT packets do seem to allow an attacker to cause my server to
arbitrarily send packets to any given IP address, which is something that I
don't feel particularly comfortable with.

Also, my particular hardware firewall model does not seem to have an option
to explicitly reject packets (versus dropping them quietly).  This also
doesn't justify not conforming to the RFC, but from my perspective it is a
fairly compelling reason not to.

Ben

----- Original Message ----- 
From: "Frank Gruellich" <frank@××××××××××××.org>
To: "Ben Cressey" <ben@×××××.org>
Sent: Thursday, January 08, 2004 4:35 PM
Subject: Re: [gentoo-security] firewall suggestions?


> * Ben Cressey <ben@×××××.org>  8. Jan 04
> > > To hide a host is always very stupid, why should you do this? There is
no
> > > advantage.  If you "hide" your computer an attacker knows there is an
> > > stupid guy who doesn't know anything about network security.
> > You're rather free with calling people "stupid" with little to no
> > justification.
>
> Well, let's see.
>
> > If I am just running a web server, nobody has any business connecting to
any
> > port besides 80/tcp and 443/tcp.  ICMP traffic is fine, but what
legitimate
> > purpose is there in attempting a connection to another tcp port?
>
> It's kinda social thing.  If you tip my shoulder asking for time I would
> answer, that I have no clock.  If I give no answer at all you would call
> me shy, taciturn, unsocial or, simply, stupid.
>
> > It's not about hiding the server or some fictitious security gain  --
> > although as someone pointed out replying to potentially spoofed source
> > addresses could be leveraged into some form of DoS attack.
>
> Would you please be so kind to explain that.  I am still interested in
> this and still can't see how to use this in a DoS attack.  In fact,
> there are many more efficient ways to DoS a host.
>
>  Gruss vom Frank.
> --
> Sigmentation fault
>


--
gentoo-security@g.o mailing list