(I've tacked the Linux Kernel too ... )
As an intro to them: this has been a good discussion so far and should be looked up in
the nmap-hackers or netfilter mailing list archives if one is interested.
The behaviour you describe would fit best into the kernel code directly, would it not
(thus the addition of linux-kernel to the CC: list)?
I'd have to agree with your summarised point though; firewalled closed ports should
behave, unless otherwise directed, as normal closed ports. It would be interesting to
see if it would be most intelligent to have an option in the firewall code to ignore
incoming connection requests on closed ports (and let the kernel deal with them
normally instead of firewalling them).
ipchains -A input -p tcp --destination-port closed-ports --jump ACCEPT
(ACCEPT'ing it would pass it through to the kernel code dealing with closed ports,
n'est-ce pas?)
Greg Hinton wrote:
> Yes Michael, it's axiomatic that the set containing some form of DROP and
> REJECT will exhaust all possible cases, and therefore is "perfectly
> sufficient". But that argument is irrelevant IMHO. The relevant argument
> is whether the *current* implementation of REJECT (i.e. only being able to
> send ICMP messages, and a subset of them at that) is "perfectly
> sufficient". I've argued that it's not for the following 2 reasons:
>
> 1. There are many implementers who would like their *closed* TCP ports
> (never mind for the moment their open, filtered ones) to behave as normal
> closed TCP ports. Normal closed TCP ports send RST's under certain
> conditions, such as when receiving the infamous ACK probe. I realize you
> were responding to Lennert's post about OS fingerprinting, but I think
> that issue is irrelevant in this discussion. The enhancement we're
> seeking has nothing whatsoever to do with being "embarassed of the OS you
> use" or even of trying to hide which OS you use. It's simply a matter of
> *allowing* implementers to make their TCP ports behave normally. And the
> beauty of it is that it would also allow implementers to keep the current
> "abnormal" TCP port behavior.
>
> 2. If we're only allowed the current 2 choices -- either DROP or REJECT
> with optional ICMP message -- then we can't easily and reliably implement
> IETF-compliant systems. Deliberately violating IETF standards should only
> be done if there's no alternative. Now if such violations were in fact an
> unavoidable situation then it would be unfortunate, but we'd all just have
> to learn to live with it. But the fact of the matter is that adding
> something functionally equivalent to "--reject-with RST" should be
> relatively easy to implement. In fact, Rusty said it was once implemented
> but he allowed it fall into disrepair and be removed because there was no
> interest at the time in using it. Well obviously there now *is* some
> interest in using such a feature. Therefore, *forcing* us to implement
> non-compliant systems when the alternative is readily available cannot be
> justified. We definitely need the option of generating RST packets.
>
> Those are the critical issues IMHO. And my $0.02. Quite a bargain...
> $0.01 per critical issue. ;-)
The humour is always welcome ;-)
--
_____/~-=##=-~\_____
-=+0+=-< Michael T. Babcock >-=+0+=-
~~~~~\_-=##=-_/~~~~~
http://www.linuxsupportline.com/~pgp/ ICQ: 4835018
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:12 EST