| 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 |
Archives