1 |
I will freely admit (as has already been made apparent on this mailing list) |
2 |
that I am essentially ignorant when it comes to the RFCs. It seems plain |
3 |
that any normal reading of RFC 793 disallows dropping packets without |
4 |
sending a RESET. |
5 |
|
6 |
I think your watch analogy is sound, and I find the social/politeness |
7 |
premise quite agreeable. Based on personal observation, though, I would say |
8 |
that the vast majority of packets that my firewall drops are almost certain |
9 |
to be malicious. (Connections to the Windows networking ports originating |
10 |
from outside the subnet, connections to common trojan ports, etc.) So it is |
11 |
more the case (from my perspective) that I am not dignifying someone who's |
12 |
clearly looking to go around and break other people's watches with a |
13 |
response. |
14 |
|
15 |
As far as the potential for a DoS attack goes, the scenario as I envision it |
16 |
is this: |
17 |
|
18 |
1) Attacker and Host have similar bandwidth resources at their disposal. |
19 |
Attacker wants to perform a DoS attack on Target's connection, which is |
20 |
capable of being saturated by Attacker's resources alone. |
21 |
|
22 |
2) Attacker spoofs TCP connection requests so they appear to be originating |
23 |
from Target's address, and sends them to Host. Host, being RFC compliant, |
24 |
responds by sending a REJECT packet to Target. |
25 |
|
26 |
3) Attacker uses all his available bandwidth to send these requests. Host |
27 |
dutifully replies to each one, using his own bandwidth and filling up |
28 |
Target's. Even if Target is dropping them as fast as it can, there are |
29 |
still more coming than his connection can handle. |
30 |
|
31 |
Note that the attacker's bandwidth can be substantially augmented using |
32 |
typical DDoS methods. |
33 |
|
34 |
>From the Target's perspective, it appears exactly as if Host is the only one |
35 |
behind the attack, and from a certain point of view this is accurate (i.e. |
36 |
Host really is sending out a lot of packets to Target that Target definitely |
37 |
doesn't want.) |
38 |
|
39 |
I am sure there are a variety of preventative measures that make this less |
40 |
plausible (rate limiting REJECT responses etc), and it could be that I am |
41 |
totally overlooking something which makes it entirely ineffective. |
42 |
|
43 |
However, REJECT packets do seem to allow an attacker to cause my server to |
44 |
arbitrarily send packets to any given IP address, which is something that I |
45 |
don't feel particularly comfortable with. |
46 |
|
47 |
Also, my particular hardware firewall model does not seem to have an option |
48 |
to explicitly reject packets (versus dropping them quietly). This also |
49 |
doesn't justify not conforming to the RFC, but from my perspective it is a |
50 |
fairly compelling reason not to. |
51 |
|
52 |
Ben |
53 |
|
54 |
----- Original Message ----- |
55 |
From: "Frank Gruellich" <frank@××××××××××××.org> |
56 |
To: "Ben Cressey" <ben@×××××.org> |
57 |
Sent: Thursday, January 08, 2004 4:35 PM |
58 |
Subject: Re: [gentoo-security] firewall suggestions? |
59 |
|
60 |
|
61 |
> * Ben Cressey <ben@×××××.org> 8. Jan 04 |
62 |
> > > To hide a host is always very stupid, why should you do this? There is |
63 |
no |
64 |
> > > advantage. If you "hide" your computer an attacker knows there is an |
65 |
> > > stupid guy who doesn't know anything about network security. |
66 |
> > You're rather free with calling people "stupid" with little to no |
67 |
> > justification. |
68 |
> |
69 |
> Well, let's see. |
70 |
> |
71 |
> > If I am just running a web server, nobody has any business connecting to |
72 |
any |
73 |
> > port besides 80/tcp and 443/tcp. ICMP traffic is fine, but what |
74 |
legitimate |
75 |
> > purpose is there in attempting a connection to another tcp port? |
76 |
> |
77 |
> It's kinda social thing. If you tip my shoulder asking for time I would |
78 |
> answer, that I have no clock. If I give no answer at all you would call |
79 |
> me shy, taciturn, unsocial or, simply, stupid. |
80 |
> |
81 |
> > It's not about hiding the server or some fictitious security gain -- |
82 |
> > although as someone pointed out replying to potentially spoofed source |
83 |
> > addresses could be leveraged into some form of DoS attack. |
84 |
> |
85 |
> Would you please be so kind to explain that. I am still interested in |
86 |
> this and still can't see how to use this in a DoS attack. In fact, |
87 |
> there are many more efficient ways to DoS a host. |
88 |
> |
89 |
> Gruss vom Frank. |
90 |
> -- |
91 |
> Sigmentation fault |
92 |
> |
93 |
|
94 |
|
95 |
-- |
96 |
gentoo-security@g.o mailing list |