1 |
* Mark Hurst <mark@××××××.net> 9. Jan 04 |
2 |
> > Sorry, but this is completely nonsense. You should always use the |
3 |
> > REJECT target. To simply drop pakets is contrary the standards and |
4 |
> > hampers net traffic. If you don't want to talk to me, say so. Simply |
5 |
> > remain silent and let me wait is very unpolite. |
6 |
> So it's nonsense, stupid, unpolite (sic) and brain-dead to default drop |
7 |
> incoming traffic? OK, if you say so. I must make a note to inform the |
8 |
> authors of every firewall manual and book i've ever read that they're |
9 |
> wrong. |
10 |
|
11 |
Send me this note, too, 'cause I also use -P DROP. _But_ because usual |
12 |
default policies allow only to DROP packts. This is very okay, because |
13 |
in this scenario everything missing my rules is something unknown. To |
14 |
answer in a specific manner to something unknown is not advisable. But |
15 |
if my default policy catches I have done something wrong anyway, cause a |
16 |
packet traversed my rules I did not consider in my filter design. |
17 |
Default policies should be used as a kind of fallback (IMHO). |
18 |
|
19 |
> How exactly does it "hamper net traffic" to let you time out when |
20 |
> connecting to a closed port? |
21 |
|
22 |
I have to resend my requests multiple times. No answer means |
23 |
(following the RFCs), that the packet was lost due to a malfunction. |
24 |
|
25 |
> Yeah, top statement there. Your attacker knows no such thing, all he knows |
26 |
> is he timed out instead of getting rejected instantly. If you try a random |
27 |
> port on some random IP address and you don't get a host unreachable, do |
28 |
> you KNOW that it's up? |
29 |
|
30 |
This or any fault in the network between us. |
31 |
|
32 |
> Of course you don't, unless you control every router in the world. |
33 |
|
34 |
This may be the fault: some routers don't behave like routers. |
35 |
|
36 |
> You should tone down the insults. Trying to show how clever you are by |
37 |
> being rude is not productive. |
38 |
|
39 |
As mentioned in other posts I beg your pardon, too. |
40 |
|
41 |
> Better go now and try to unbind broken services from my external |
42 |
> interfaces like the braindead root that i am. And play with my filter. |
43 |
> Thanks for the laughs. |
44 |
|
45 |
The thread arose from the statement, that even on single hosts a paket |
46 |
filter used to drop ports increases security more than simply close |
47 |
ports by stoping services. |
48 |
|
49 |
Regards, Frank. |
50 |
-- |
51 |
Sigmentation fault |
52 |
|
53 |
-- |
54 |
gentoo-security@g.o mailing list |