From owner-freebsd-security Tue Oct 3 11: 8: 9 2000 Delivered-To: freebsd-security@freebsd.org Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by hub.freebsd.org (Postfix) with ESMTP id D04C537B66D for ; Tue, 3 Oct 2000 11:08:03 -0700 (PDT) Received: from xi.css.qmw.ac.uk ([138.37.8.11]) by zeta.qmw.ac.uk with esmtp (Exim 3.02 #1) id 13gWTt-0002rU-00 for security@freebsd.org; Tue, 03 Oct 2000 19:07:57 +0100 Received: from cgaa180 by xi.css.qmw.ac.uk with local (Exim 1.92 #1) for security@FreeBSD.ORG id 13gWTu-0006gD-00; Tue, 3 Oct 2000 19:07:58 +0100 X-Mailer: exmh version 2.0.2 2/24/98 To: security@FreeBSD.ORG Subject: Re: cvs commit: src/etc inetd.conf In-reply-to: Your message of "Tue, 03 Oct 2000 13:22:27 EDT." <200010031722.NAA41823@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Oct 2000 19:07:58 +0100 From: David Pick Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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: > < 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