1 |
> To hide a host is always very stupid, why should you do this? There is no |
2 |
> advantage. If you "hide" your computer an attacker knows there is an |
3 |
> stupid guy who doesn't know anything about network security. |
4 |
|
5 |
You're rather free with calling people "stupid" with little to no |
6 |
justification. One could as easily turn it around and ask "why should my |
7 |
server reply at all to connection attempts to ports I am not running any |
8 |
services on?" |
9 |
|
10 |
If I am just running a web server, nobody has any business connecting to any |
11 |
port besides 80/tcp and 443/tcp. ICMP traffic is fine, but what legitimate |
12 |
purpose is there in attempting a connection to another tcp port? If I was |
13 |
running another service at that IP address, it would be advertised through |
14 |
the appropriate channels. Users would (obviously) not need to run a port |
15 |
scan to discover it. |
16 |
|
17 |
Since the person is trying to connect to a port they have no business |
18 |
connecting to, I don't see why my server should send out a packet in reply. |
19 |
It's not about hiding the server or some fictitious security gain -- |
20 |
although as someone pointed out replying to potentially spoofed source |
21 |
addresses could be leveraged into some form of DoS attack. While the |
22 |
chances of this are probably not high, they are precisely *zero* if you |
23 |
don't bother to reply in the first place. |
24 |
|
25 |
The issues of "ident lookups" and "difficult to troubleshoot" are in my |
26 |
opinion not relevant. If you are relying on the behavior of REJECT vs DROP |
27 |
to ensure that supported applications behave correctly, you might be better |
28 |
advised to just figure out what network access is necessary in the first |
29 |
place and enable that. |
30 |
|
31 |
As far as RFCs go, the only relevant excerpt I could find was quoted on |
32 |
http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject and seems |
33 |
to only cover the side initiating the connection. That is, IF they get a |
34 |
"REJECT" packet then they should immediately abort the connection and notify |
35 |
the application. If their connection is just dropped and we never tell |
36 |
them, so what? |
37 |
|
38 |
Ben |
39 |
|
40 |
|
41 |
-- |
42 |
gentoo-security@g.o mailing list |