Best way is:
in hosts.deny
ALL:ALL
in hosts.allow
in.telnetd XXX.XXX.XXX.: ALLOW
in.ftpd XXX.XXX.XXX: ALLOW
(Where XXX.XXX.XXX is you class "whatever" IP address).
Keeps the hackers out for me.
:-)
Jeff
"Michael T. Babcock" wrote:
>
> (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/
-
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