1 |
* Benjamin Jury <benjamin.jury@××××.com> 8. Jan 04 |
2 |
> > * Thomas T. Veldhouse <veldy@×××××.net> 8. Jan 04 |
3 |
> > > Oliver Schad wrote: |
4 |
> > > > [DROP or REJECT] |
5 |
> > > One reason ... it slows down various scans. |
6 |
> > No, it doesn't. |
7 |
> If you reject the packet does it not allow you to be used for DOSing a host |
8 |
> via a spoofed IP? |
9 |
|
10 |
WTF? Could you please be more specific, how this could work? I would |
11 |
really be interested. |
12 |
|
13 |
Something like this: $badguy sends a spoofed paket to any host, the host |
14 |
answers usually with ICMP3/3 to the wrong IP# (the reject). This host |
15 |
suddenly receives the message and discards it, as it doesn't belong to |
16 |
any of it's requests. |
17 |
|
18 |
I can't see, how to DoS somebody this way. It binds on attackers side |
19 |
as much resources as on victims one. A DDoS with many more hosts, |
20 |
flooding rejecting filters with pakets of _one_ spoofed IP# (the one of |
21 |
the victim) could do some damage, but discarding pakets is much less |
22 |
expensive than sending answers. For DoSing you have to achieve, that |
23 |
the victim queuses requests somehow. |
24 |
|
25 |
I know only one missuse of REJECT: Look for an idle host with a OS |
26 |
using predictable (ascending) sequence numbers. Now you can use this |
27 |
host to scan another without appearing in its logfiles: constantly |
28 |
stream the idle host with pakets and record the answers. Send a SYN |
29 |
with the IP# of the idle host to the host to be scanned and it will |
30 |
either answer with SYN/ACK, a ICMP to the idle host or not at all. The |
31 |
ICMP will be simply discarded (and isn't of interest anyway), but if the |
32 |
idle host receives a SYN/ACK without a previous SYN it sends a RST with |
33 |
current sequence number. And exactly this sequence number you will miss |
34 |
in your records. A little timing and much free time you will find out |
35 |
open ports. Happy hacking. |
36 |
|
37 |
But the disadvanteges of DROP are IMHO still outweighing, |
38 |
regards, Frank. |
39 |
-- |
40 |
Sigmentation fault |
41 |
|
42 |
-- |
43 |
gentoo-security@g.o mailing list |