Date: Tue, 03 Oct 2000 19:07:58 +0100 From: David Pick <D.M.Pick@qmw.ac.uk> To: security@FreeBSD.ORG Subject: Re: cvs commit: src/etc inetd.conf Message-ID: <E13gWTu-0006gD-00@xi.css.qmw.ac.uk> In-Reply-To: Your message of "Tue, 03 Oct 2000 13:22:27 EDT." <200010031722.NAA41823@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Lyndon Nerenberg commented: > David> Sorry, I don't get this. If sendmail attempts to call the > David> "auth" port on the sending machine and gets a response it > David> should be happy. If it gets no response (after a time-out) > David> it would be entitled to retry a few times in case of packet > David> loss. > > No it wouldn't. TCP takes care of the retries for you. True. > If the auth > service is blocked by a firewall the firewall will usually eat the SYN > packets, and you will never get a RST. Unless you've told the firewall package to generate one. Both IPFW and IPFILTER can be told to do this these days. Garrett Wollman commented: > <<On Tue, 03 Oct 2000 18:16:12 +0100, David Pick <D.M.Pick@qmw.ac.uk> said: > > > gets no response (after a time-out) it would be entitled to retry a > > few times in case of packet loss. *But* if it gets a RST, which is a > > If net.inet.tcp.blackhole is set, an RST will not be emitted. True. Unless the RST is coming from IPFW or IPFILTER rules. They tend to the way I run my machines. But I had forgotten that variable. So, getting back to the original discussion, What we want to make sure is that sendmail is not unnecessarily delayed. (And "exim" which does the same thing.) So we need to make sure that either: - an "auth" daemon is running (or built in to "inetd" or whatever) - an "auth" daemon is not running and a RST packet is returned regardless of the setting og "net.inet.blackhole" The first option may give away too much information. The second slightly defeats the objective of the "blackhole" option. But, if we *really* care it would be possible to arrange one or the other of the "firewall" packages to generate a RST response to "auth" queries *if the query was received from a machine we "know" about, but not from other machines*. The precise definition of "know" is more problematical. The "best" would be: a machine to which we have a connection open and IPFilter might be enhancable to do this provided we used the "keep state" options on outward connections. If we sent all outgoing mail to a "smart host" then that would be a candidate for being told there is no "auth" data available rather than being told nothing at all. And there's always the option of giving real data to only the questioners we "know" about. But is'a all a lot of work, and I wonder if it's worth it. As far as I can see it's only a problem if the RSTs don't happen for one reason or another. And my original comment still applies. I don't see why a RST *that gets sent* should cause any more delay than an "accept and here's the data". -- David Pick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E13gWTu-0006gD-00>