Need a secure 'portmap' daemon - NIS security questions...

2007-12-25 9:29:00

Thanks to everyone who responded! I include here my original question, the

partial summary I posted a few days ago, and the resolution to the

additional question posted in the partial summary, along with any other

relevant information.

ORIGINAL QUESTION:

>OS: SUNOS-4.1.3_U1

>Platforms: Sparc 1,1+,2,IPC,Classic

>Issues: Security, NIS

>

>After looking through the various FAQs, manuals, and patch summaries, I put

>it to the list: does anyone know of a secure implementation of 'portmap'

>that would disallow a system from outside your network from tapping your

>domain and garnering such items as NIS maps? I need to be able to allow

>access to designated remote machines outside my subnet structure while

>denying all others.

PARTIAL SUMMARY:

>A followup to my earlier posting concerning a secure portmap daemon: Sun

>had a patch to address this (100482) for OSes up through 4.1.3. They

>applied this patch to 4.1.3_U1 (along with many others) and it solved my

>problem. You basically have to create a file called /var/yp/securenets with

>one or more lines of the format

>

>netmask netaddr

>

>e.g.

>

>255.255.0.0 128.30.0.0

>255.255.255.0 128.311.10.0

>

>The second example allows ypserv to respond only to those addresses within

>the subnet 128.311.10 range. You can have as many as you need ( as far as

>I know ).

>

>One additional question is raised by this: is it possible to address only

>one machine out of a subnet with this procedure? It would help me quite a

>bit if it were possible. Any suggestions are welcome!

And the answer to the question above:

Using a netmask of 255.255.255.255 allows you to reference any one computer.

E.g.,

255.255.255.255 132.19.205.4

would reference just that host. (The address above was changed to protect

the innocent. :-) )

Finally, sections of relevant comments on these questions:

Joel,

        I ran across a CERT advisory a few minutes ago that might pertain to

your systems. It's kinda old, but does address some SunOS NIS problems.

 I don't know if it'll help you any or not, but here it is:

--Duane

--Cut here----

CA-92:13 CERT Advisory

                               June 4, 1992

                          SunOS NIS Vulnerability

-------------------------------------------------------------------------=


--

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning several vulnerabilities with NIS under
Sun Microsystems, Inc. SunOS. These vulnerabilities exist in NIS under
SunOS 4.1, 4.1.1, and 4.1.2, and may or may not exist in earlier =
versions
of NIS.

Sun has provided fixes for SunOS 4.1, 4.1.1, and 4.1.2 for these
vulnerabilities. The patch file containing these fixes is available
through your local Sun Answer Center and through anonymous ftp from
ftp.uu.net (137.39.1.9) in the /systems/sun/sun-dist directory. Note
that these fixes will probably not be compatible with SunOS 4.0.3 and
earlier versions of the operating system.

Fix PatchID Filename =
Checksum
/usr/etc/{ypserv,ypxfrd,portmap} 100482-2 100482-02.tar.Z 53416 =
284

Please note that Sun will occasionally update patch files. If you
find that the checksum is different, please contact Sun or the CERT/CC
for verification.

-------------------------------------------------------------------------=
--

I. Description

A security vulnerability exists under NIS allowing unauthorized =
access
to NIS information.

II. Impact

A user on a remote host can obtain copies of the NIS maps from a
system running NIS. The remote user can attempt to guess passwords
for the system using the obtained NIS password map information.

III. Solution

A. Obtain and install the patch from Sun or from ftp.uu.net =
following
the instructions provided in the "README" file. =20

1. As root, rename the existing versions of
/usr/etc/{ypserv,ypxfrd,portmap} and modify the
permissions to prevent misuse.

# mv /usr/etc/ypserv /usr/etc/ypserv.orig
# mv /usr/etc/ypxfrd /usr/etc/ypxfrd.orig
# mv /usr/etc/portmap /usr/etc/portmap.orig
# chmod 0400 /usr/etc/ypserv.orig=20
# chmod 0400 /usr/etc/ypxfrd.orig
# chmod 0400 /usr/etc/portmap.orig

2. Copy the new binaries into the /usr/etc directory.

# cp `arch`/{4.1, 4.1.1, 4.1.2}/ypserv /usr/etc/ypserv
# cp `arch`/{4.1, 4.1.1, 4.1.2}/ypxfrd /usr/etc/ypxfrd
# cp `arch`/{4.1, 4.1.1, 4.1.2}/portmap /usr/etc/portmap
# chown root /usr/etc/ypserv /usr/etc/ypxfrd =
/usr/etc/portmap
# chmod 755 /usr/etc/ypserv /usr/etc/ypxfrd =
/usr/etc/portmap

3. Copy the securenets file to the /var/yp directory. Any
site that has an existing /var/yp/securenets file should=20
rename it prior copying the new version of the file.

# cp `arch`/{4.1, 4.1.1, 4.1.2}/securenets /var/yp
# chown root /var/yp/securenets
# chmod 644 /var/yp/securenets

4. Edit the /var/yp/securenets file to reflect the correct
configuration for your site. See the "README" file for
details of the file syntax and special instructions for
hosts with multiple Ethernet interfaces. The file should
not contain any blank lines.
=20
5. Reboot the system to invoke the new binaries.

-------------------------------------------------------------------------=
--
The CERT/CC would like to thank Casper Dik of the University of =
Amsterdam,
The Netherlands, and Peter Lamb of the Division of Information =
Technology,
Commonwealth Scientific and Industrial Research Organization, Australia,
for their assistance. We also wish to thank Sun Microsystems, Inc. for
their response to this vulnerability.
-------------------------------------------------------------------------=
--

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security =
Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
CERT/CC personnel answer 7:30 a.m.-6:00 p.m. =
EST(GMT-5)/EDT(GMT-4),
on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.org (192.88.209.5).

==============================

The mask 255.255.255.255 means to match the entire address. 0-bits in the
mask are "don't care", and this has no 0-bits.

--
Barry Margolin
BBN PlaNET Corporation, Cambridge, MA
barmar@bbnplanet.com
Phone (617) 873-3126 - Fax (617) 873-6351

==============================

secure portmap is at ftp.win.tue.nl in one of the security dirs.

weitze is the administrator of that location, he is the person that
wrote tcp wrappers fyi

--chris

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Christopher Eastman %% Cable & Wireless, Inc %%
%% MDS Network Engineer %% 1919 Gallows Road %%
%% chris@cwi.net %% Vienna, VA 22182 %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

==============================

ftp to ftp.win.tue.nl in pub/security, for wieste venemas secure rpcbind.
It ''authenticates'' like tcpwrappers...

Jim

---
Jim McBride jmcbride@neog.com
Neoglyphics Media Corp. http://www.neog.com

=================================

Yes, use Wietse Venema's rpcbind, which can be found at:
ftp://ftp.win.tue.nl/pub/security/rpcbind_1.1.tar.Z

Regards,

John
--
John DiMarco <jdd@cdf.toronto.edu> Office: EA201B
Computing Disciplines Facility Systems Manager Phone: 416-978-1928
University of Toronto Fax: 416-978-1931
http://www.cdf.toronto.edu/personal/jdd/jdd.html

===================================

We use

ftp.cert.org:/pub/tools/nfs_tools/portmap_3.shar.gz

on machines with Solaris and

ftp.cert.org:/pub/tools/nfs_tools/rpcbind_1.1.tar.gz

on SunOS 4.1.3...

Both tools are replacements for daemons shipped with operating system.
They work in conjunction with tcp_wrapper library:

ftp.cert.org:/pub/tools/tcp_wrappers

Best regards,

Benjamin Zwittnig

--

----------------------------------------------------------------------------
Benjamin Zwittnig phone: +386 61 125 15 15
ARNES fax: +386 61 125 54 54
(Academic and Research Network of Slovenia)
Jamova 39
61111 Ljubljana e-mail: Benjamin.Zwittnig@arnes.si
Slovenia C=si;ADMD=mail;PRMD=ac;S=Zwittnig;G=Benjamin
----------------------------------------------------------------------------

============================

yes portmap_3 from Wietse Venema will do just what you are looking for! here is
the BLURB:

This is the third replacement portmapper release.

There is an increasing interest in access control for the NIS, mount
and other RPC-based services that are normally registered with the
portmap process. Possible attacks on RPC daemons involve:

- theft of NIS (YP) password files

- ypset to force hosts to bind to a rogue NIS (YP) server

- theft of NFS file handles

My contribution is a replacement portmap program, derived from source
code in the RPCSRC 4.0 and the TIRPC source distributions. Access
control is in the style of my tcp wrapper (log_tcp) package. It should

work with all SunOS 4.x and Ultrix >= 3.0 releases. However, the source
is reasonably portable and the code should work on most UNIX systems
that provide SUNRPC on top of BSD-style TCP/IP. System V.4 support is
problematic, though.

The present portmap version attempts to close all portmap security
problems that are known to me. It should be as secure as the portmap
daemon that comes with the SunOS 4.x portmap+NIS patch (patch id
100482-02). The README file gives a complete list of security
features.

Without the availability of portmap source, possible alternatives are
1) packet filtering with a smart router; 2) linking the portmap
executable against the securelib shared library. Linking RPC daemons
against the securelib library is a good idea, anyway.

The source is available for anonymous FTP from ftp.win.tue.nl directory
/pub/security/portmap_*.shar.Z.

Wietse Venema (wietse@wzv.win.tue.nl)
Mathematics and Computing Science
Eindhoven University of Technology
The Netherlands

--
Ciao!
Shakeel

******************************************************** __ ***************
Hewlett-Packard(Canada) Ltd. ************* / / ************
Panacom Division(PAD) *********** / / *********
20 Lexington Road ********* / /___ ______ *******
Waterloo, Ontario ******** / __ // __ / ******
Canada N2J 3Z3 ******** / / / // /_/ / ******
Email: rao@waterloo.hp.com ********* /_/ /_// ____/ *******
Phone : (519)883-3089 ********** / / *********
Fax : (519)886-8620 ************ / / ***********
***************************************************** /_/ ****************

==========================

Thanks to all the above and those with 'me too' replies. Moral support is
also important when problems are occurring!

Regards,

Joel L. Seber | Dry humor is wasted around here.
Sun Workstation Laboratory Manager | -Joel L. Seber
Center for Manufacturing Research |
and Technology Utilization | recursive, adj.
Tennessee Technological University | See 'recursive'
Box 5077 Brown Hall |
Cookeville, TN 38505 | What if there were no hypothetical
jls2013@tntech.edu | situations? -Steven Wright
more info: |
finger jls2013@gemini.tntech.edu | Who, me? -Alfred E. Newman
|
| "It is bad luck to be superstitious."
| -- Andrew W. Mathis

Comments

Got something to say?

You must be logged in to post a comment.