Date: Fri, 31 Mar 2000 13:11:06 -0500 (PET) From: Rici Lake <rlake@oxfam.org.pe> To: David Malone <dwmalone@maths.tcd.ie> Cc: Jeff Hamilton <hjeffrey@hotmail.com>, freebsd-questions@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: portmap in hosts.allow configuration notes. Was Re: /etc/hosts.allow Message-ID: <Pine.LNX.4.05.10003311059380.8417-100000@rlake.oxfam.org.pe> In-Reply-To: <20000328231657.A9744@walton.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
I received this error, too. In the course of investigating it, I found out a whole lot about FreeBSD. Some of my notes are reproduced here in the hopes that they might be useful to someone. I don't know if this is an appropriate forum, but if it's not no doubt someone will flame me :-) Sorry about the length of the message. There are three parts: first, a quick answer to Jeff's original question; second, a diagnosis of what's happening, and third, some recommendations for whoever feels they're responsible. The short answer to Jeff is that you did do something wrong: you can't use twist with portmap. So you can't let portmap "fall through" to the default rejection line in hosts.allow. You must use either ACCEPT or DENY, and as the comments in hosts.allow say (but not the example), you cannot use hostnames. I think this should be made clearer in the hosts.allow template, FWIW. The other piece of the puzzle is that this was almost certainly a port scan, although it could have been an attempted break-in -- in any case, it would have been unsuccessful. Finally, I think we can conclude that Jeff is not using portmap and should not be running the service. :-) (see below) Here's the diagnosis, in case anyone cares. Wietse Venema's wonderful tcp wrapper program and library are incredibly useful, and I don't mean this to be a criticism in any way. The tcp wrapper library (libwrap) provides an interface to the /etc/hosts.* configuration files, and this support is used in various programs, including portmap and sendmail (and probably others.) However, the tcp wrapper package was originally written to be used in a "single-fire" mode with inetd, and many of the extended options (enabled with the -DPROCESS_OPTIONS compile-time flag to the tcp wrappers package, which seems to be the default setting in FreeBSD, amongst others) are not going to work other than in this mode. The twist option cannot work other than in inetd mode. It causes the calling process to be replaced (through the execl(3) system call) with an configured shell process. If the calling process intended to hang around for a while to answer more requests, it's in for a surprise. To attempt to prevent this, the tcp wrappers library maintains a count of the number of times it has been called, and if it's been called more than once, it won't do the twist. (Call it square :-) ) This check will not be effective if the twist happens on the first call to the wrappers library after the process starts. This is unlikely but possible, unless the service is not being legitimately used. So if you run portmap but don't use it AND you take the portmap lines out of hosts.allow, leaving only the default ALL : ALL : twist line at the end, then when someone attempts to connect to portmap, it will call the wrapper library, the wrapper library will try the twist, and it will fail with the error message you saw (more on that later.) Having failed to twist, and having failed to execl(3), the library will call exit(3) and portmap will be no more. The reason the twist fails is that it attempts to dup2(3) the fd for the socket connection prior to the execl(3). However, programs like portmap which use the simplified wrapper library interface hosts_tcl(see hosts_access(3)) cannot inform the wrapper library of the fd of the socket connection (nor, probably, should they), and therefore the wrapper library will attempt to dup2(3) file descriptor -1. dup2(3) returns EBADF, and the error you received is generated. Oddly, the wrapper library will already have syslog(3)ged the twist attempt, which might have told you the IP number the connection came from, but you probably won't have seen that. That's because the default logging facility/level set by the default hosts.allow file is auth.info, and the default syslog.conf(5) file discards everything in auth under auth.notice. So, here are some suggestions. Accept, ignore, critique, whatever: 1. The default /etc/hosts.allow should make it clearer that you can't twist certain services, including portmap and sendmail. 2. Either the default /etc/syslog.conf should log auth.info somewhere, or the default /etc/hosts.allow should not downgrade the importance of twists, or some comment somewhere should point out that twists aren't logged. No doubt there were good reasons for these choices (although they strike me as curious) so I'd settle for the comment. 3. With respect to Wietse Venema, I think the protection against stupidity or ignorance in options.c could be improved a little bit. I would suggest pre-checking the value of fd before trying to use it, for example. This fairly small patch would at least produce meaningful error messages in this particular case (and would have saved portmap from having been terminated, although I don't suppose that that matters much.) 4. While I was cruising around trying to find the answer to all this stuff, I noticed that in portmap, hosts_ctl is called with empty strings for the client host name and user name arguments. In hosts_access(3), it states that these arguments should be set to the macro STRING_UNKNOWN if they are invalid. As far as I can see, the manpage is correct: if the argument is specified as "", the wrapper library will attempt to work it out if necessary. Since it's clear that you can't do a DNS lookup, much less an ident, in portmap, it would be better to specify STRING_UNKNOWN to flag the wrapper library to not bother trying to do the lookups. However, for the life of me, I can't see how tcpd.h is #included in pmap_check.c; I suppose it doesn't matter given c's laxity about function prototyping. STRING_UNKNOWN is, in fact "unknown". On Tue, 28 Mar 2000, David Malone wrote: > On Tue, Mar 28, 2000 at 01:24:18PM -0800, Jeff Hamilton wrote: > > > >My guess is that the portmapper is getting a tcp connection, which the > > >remote end closes almost immediately. Then when the wrapping code goes > > >to to dup the discriptor which is supposed to be connected it finds it > > >is unconnected. > > > > Could this possibly be an indicator of a port scan or other exploit attempt? > > Is there anyway to trace the IP address that originated the connection? > > If my guess was right, there is a good chance it could be a portscan. > Tracing the IP address is probably a bit harder. I'll experiment at > home and see if I can reproduce this. > > David. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.05.10003311059380.8417-100000>