Date: Mon, 19 Apr 1993 14:03:52 -0400 (EDT)
From: safdas@moose.wan.gs.com (Shabbir J Safdar)
Subject: Re: DNS over TCP
To: firewalls@GreatCircle.COM, brent@GreatCircle.COM
Message-Id: <9304191803.AA00769@moose.wan.gs.com>

> From Firewalls-Owner@GreatCircle.COM Mon Apr 19 13:50:14 1993
> Date: 19 Apr 1993 10:09:36 -0700

> Unfortunately, that's about the only option you have to keep folks
> from exploiting security holes in RPC-based services such as NFS and
> Yellow Pages (aka NIS).  By the nature of RPC, you don't know for
> certain what UDP port an RPC-based server is going to end up using
> (though NFS usually uses 2049; NFS is a special case, though, that's
> more predictable than the others).  You end up having to block almost
> all UDP in order to keep people from getting at your RPC-based
> services.  Fortunately, most of the troublesome services aren't
> offered under TCP, or you'd have the same problem there.

There are two other options.  To block access to NIS/YP, you should install
Sun patch 100482.  It lets you specify, by subnet, who gets access to your
NIS/YP services.  It really works too.  I had a co-worker setup a workstation
over the weekend.  He was unable to use my NIS server because I had not
given him permission in my /var/yp/securenets file.

Your second option (and one I would highly recommend) is to use the "securelib"
product from William Lefebvre.  With it, you produce a new shared library
for use by RPC daemons.  It intercepts the accept(), recvmsg(), and recvfrom()
socket calls.  I've attached the README for it.  This product also gives
you IP-level control over who connects to your RPC daemons.  I have tested
it on 4.1.2 and 4.1.3 Sun systems.

-Shabbir

I've included the first part of the README.  The product can be ftp'ed from
ftp.eecs.nwu.edu.

SunOS 4.1 secure C library package

Written by William LeFebvre, EECS Department, Northwestern University.
Internet address: phil@eecs.nwu.edu

Code for reading the configuration file, along with a few important
patches, was provided by Sam Horrocks of UCI (sam@ics.uci.edu).

OVERVIEW:

This package contains replacement routines for these three kernel
calls: accept, recvfrom, recvmsg.  These replacements are compatible
with the originals, with the additional functionality that they check
the Internet address of the machine initiating the connection to make
sure that it is "allowed" to connect.

Once compiled, these can be used when building a new shared libc.  The
resulting libc.so can then be put in a special place.  Any program
that should be protected can then be started with an alternate
LD_LIBRARY_PATH.

What you need:
        SunOS version 4.1, 4.1.1, or 4.1.2 (or 4.1.3 if there ever is one),
        installation of the "shared library" option,
        root access.

SunOS 5 (Solaris 2.0) users are on your own.  I have no idea if this
will work with version 5 or its successors.

You can see if your machine has the shared library option installed by
looking for the directory "/usr/lib/shlib.etc".  If it is not
installed, then you will need to extract it from the distribution
tapes (Sun-factory installed machines will NOT have it installed).

Do you need to use this?  If you can answer all of these questions
with "yes", then this package will benefit you:

        Are you connected to the Internet (even via a local or
        regional network)?

        Do all of the routers/gateways between your machine and the
        "rest of the world" route all packets regardless of protocol
        or port number?

        Are you concerned about the fact that any user on any system
        anywhere on the Internet can connect to any network daemon
        that runs on your machine, including ypserv and pwdauthd?

AVAILABILITY:

The latest version of securelib is available via anonymous FTP from
the host "eecs.nwu.edu".  It is stored in the file "pub/securelib.tar".
Remember to use the "binary" transfer mode!

DETAILS:

Each modified system call has the same basic algorithm:

{
        int retval;

        if ((retval = syscall(...)) >= 0)
        {
                if (_ok_address(socket, addr, *addrlen))
                {
                        return (retval);
                }
                close(retval); /* this line: "accept" only */
                errno = ECONNREFUSED;
                return (-1);
        }
        return (retval);
}

Connections that are established from a host that is not "okay" will
be closed (if established via "accept"), then errno will be set to
ECONNREFUSED and the calling application will get an error indication
back from its system call.  It is assumed that the application will
deal with such an error in an intelligent fashion.  All Sun daemons
that we have tried seem to handle this correctly: they merely do the
system call again.

The application will only see success for machines that "_ok_address"
says are acceptable.  All other connections look like failures.

The function "_ok_address" reads a configuration file (normally
"/etc/securelib.conf" or "/etc/security/securelib.conf") which
describes what Internet address are acceptable.