Skip site navigation (1)Skip section navigation (2)
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-questions" 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>