On 9/4/06, Ted Johnson <[EMAIL PROTECTED]> wrote:
I also did a search of the document you suggested and it doesn't even have the word "close" in it, therefore, it would appear to not address the issue. From your reply, I'm missing something obvious here. But would you point it out anyway?
Fair enough. It's because dropping packets before they reach the port makes it irrelevant whether they are closed (that is, have no listening daemon) or not. If a port scanner says the port is closed, it generally means that it got an ICMP unreachable (UDP) or a TCP reset (TCP) back. This is helpful to attackers as they know quickly that the port is useless to them, and that the target is online. On the other hand, if you drop the incoming packets, the attacker cannot infer whether you are online, and most port scanners wait for some period and then decide that the target is not going to respond, so it slows down single-threaded scans. In general, it is better to drop than to reject to untrusted networks, since the scanners are generally hostile. Internal communication on your LAN can usually be rejected, because internal users are generally not hostile. This means that if they try to access a service that isn't running, they get a response right away that they made a mistake, instead of waiting for a response which will never come. Furthermore, a closed and an open port permit pretty good OS fingerprinting. I think that if you drop instead of reject, then an attacker cannot narrow down the OS as well. In summary: The way to close a port is to not run a program which listens on that port. This can be simulated by rejecting packets at the firewall. The way to block a port is with packet filters, and there's no way to do that without one (unless you disable reject messages at the kernel level). -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"