Folks-
This is an update to my previous posting wherein I
asked if anyone could decipher the meaning of entries
in the portmapper log. Thanks to Thomas Leitner Mike
Iglesias, Serguei Patchkovskii, Richard Bemrose, Martin
Mokrejs, and Jim Belonis for replies.
One thing that I didn't make clear in the previous
posting is that all of the portmapper errors arise from
other machines in our class B network. Some of the
replies (shown below) indicate that such portmapper
entries may reresent mis-configured computers of the PC
kind. This is an answer I can accept; however, for me
to feel confident that I'm not being hacked, I need to
be able to determine when a portmapper hit represents a
genuine attempt at hacking (even hacking from other
machines on our own network) and when it represents a
mis-configured machine on our network.
My initial thought about resolving this problem
was to get the owners of the mis-configured computers
to clean up their act. I contacted our local network
folks to ask what is going on and could they contact
the owners of the mis-configured machines, but basically
I've been ignored. Given this lack of interest, I'm pretty
much back to near where I started. There is about zero
chance that we could install a router to isolate us from
some forms of hacking or to search for rpc port sweeps.
So I'm still looking for hints or tools that might
tell me what is going on. How do I decipher portmapper
entries such as:
callit(300055)
callit(390109)
callit(rusersd)
callit(mountd)
We don't run any services that use these service/port
numbers. Are they commonly used in the PC world as
some responders suggested? Given that I receive
thousands of these rejected portmapper connection attempts
daily, I'd like to find a computer tool that could
sort out these connection attempts or alert me when there
are port sweeps going on.
Thanks again,
Mike
====================
Original Question:
I've installed Wietse Venema's portmapper on all my Dec
Personal Workstations and discovered/blocked hundreds of
portmapper calls per day. A few of the portmapper log
entries are shown below (without the proper IP numbers).
I'm no RPC expert, so I'm not sure how to interpret
these log entries. I'm guessing that the callit(ypserv)
log messages refer to someone broadcasting for ypservice.
But what is the callit(mountd) log entry? Is someone
trying to NFS mount my disks? Where to I go to find out
what the callit(300055) and callit(390109) log entries
mean? I've looked at the O'Reilly RPC book, but nothing
leapt out of page at me.
Feb 23 17:26:04 portmap[11287]: connect from W.X.Y.Z to callit(300055): request
from unauthorized host
Feb 24 18:47:15 portmap[15035]: connect from A.B.C.D to callit(390109): request
from unauthorized host
Feb 23 16:55:56 portmap[11210]: connect from E.F.G.H to callit(mountd): request
from unauthorized host
Feb 24 21:01:38 portmap[14108]: connect from I.J.K.L to callit(ypserv): request
from unauthorized host
===================
Answers:
----------
I have the same problem here and spotted the following reasons for it:
a.) Somewhere in our network is a Novell server with some NIS (or NFS)
software installed. It permanently tries to contact all available
machines on the net. I had the Novell admin to turn this off here.
b.) Last week someone installed Onnet 32 from FTP software on his Windows
NT PC. He was sitting in another subnet which I've excluded from
the portmap service in the hosts.deny file. The Onnet 32 NFS client
can "browse" NFS servers similar to a Windows Network by trying
to contact all NFS servers it finds in a certain network. This
also causes many portmap warnings here.
----------
The mountd entry is someone trying to call mountd on your system. If it's
from a host that you don't know (like off-site), it could be someone probing
your system to see if you're running mountd. Some versions of mountd have
a security hole that lets hackers gain root access to your system.
Normally the RPC program codes are in /etc/rpc. If you can't find them
in there, you can use /usr/sbin/rpcinfo to see what tcp or udp port that
RPC code gets translated into (if there's something on your system using it),
and then you can track it down from there using something like lsof.
------------
> Feb 24 18:47:15 portmap[15035]: connect from A.B.C.D to callit(390109): request from unauthorized host
Use rpcinfo -p to find out which port (if any) is registered for this program,
and then use lsof to get at the pid which opened it.
--------------
Just to let you know, you are not alone. I am no RPC expert but find
Venema's portmapper very useful. I would be very concerned if you received
YP requests from outside of your domain. This would indicate somebody is
probably using ypx (or equivalent) to access your YP information (like the
password file). You may want to read ypserv(8) man page about the
securenets "/etc/yp/securenets".
As for as resolving RPC numbers, I can only suggest using the rpcinfo
command which reports what programs are registered.
-------------
I'm also not an expert, but I see similar messages here.
It seems to me that when some of our SGI Indy's boots up, I get:
Feb 25 16:11:09 4C:pteryx portmap[5820]: connect from 195.113.56.249 to callit(mountd): request from unauthorized host
Feb 25 16:11:10 4C:pteryx portmap[5825]: connect from 195.113.56.249 to callit(mountd): request from unauthorized host
Feb 25 16:11:12 4C:pteryx portmap[5830]: connect from 195.113.56.249 to callit(mountd): request from unauthorized host
Feb 25 16:11:12 4C:pteryx portmap[5835]: connect from 195.113.56.249 to callit(mountd): request from unauthorized host
Because of lack of the informations I'm just ignoring the messages.
-----------
You should be receiving something between one every couple days to
a couple a day of probes of your mountd port (and other ports like imapd)
from hackers at VERY random locations around the world.
Especially if you see similar times (within a second or two)
on multiple machines, you can be pretty sure
it is a hacker.
Contact the owner of the attacking machine and they will typically be grateful
to find out a hacker has probably taken over that machine.
To find useful addresses to send to, check out their web site or the web site
of their domain. Or send to postmaster at the machine and also at the domain.
Received on Wed Mar 10 1999 - 21:53:21 NZDT