Re: port 768

[eric () ERICPRESTON COM (Eric Preston)]

> That explains, thank you. After I noticed lots of probes on port 111,
> I put an email alert on rpc.mountd rejects in hosts.deny. I got
> alerted all right, and it coincided with this port 768 scan. I was
> already wondering why the rpc probe (which I assumed to be targeted at
> 111) wasn't reject-logged by the firewall, whereas the 768 probe
> was. As it turns out to be, they're the same: an rpc probe on port
> 768.
>
> Obviously /etc/services is not the comprehensive port/service mapping
> I thought it to be. Is there another way to quickly create a
> comprehensive listing of which services are listening on which ports?

Uh, this should be pretty obvious. I'll just fire off some things that
most people already take forgranted, sorry if you already know this stuff,
but it sounds like you need some advice.

1) RPC services are brutally insecure, avoid them if you can.

2) A client connects to port 111 (portmap) and requests a particular
service. "rpcinfo -p" will list currently offered RPC services, the
protocol and port offered on. for example, process connects to portmap
(111) and asks for rpc.mountd and gets redirected to 768 in your example.

Now, the port a particular service is offered on depends on a whole bunch
of factors and hence this is why the portmapper exists, and also why it's
a pain in the ass for locking down. The ports, that for example,
rpc.mountds are offered on will change over time (reboots, number of
daemons, etc)

Personally, from the sounds of it, the fact that you've got a machine
running portmap offered to the outside world is insane, and relying on
hosts.deny ACLs is only a moderate measure.

3) to list what processes are listening on any given port at any given
time you use the "netstat -a" for all connections not just active (ports
open for LISTEN) will also be shown. now, what I usually use to take a
quick look is the "netstat -atup" command (under linux) which lists all
ports open and listening for udp and tcp (avoids all the unix domain
sockets) and the -p option also lists the owning process (shows which
process is actually bound to which port forget guessing at your
incomplete /etc/services)

4) /etc/services isn't an accurate mapping, it's more of a "helpful
list"... ofcourse most /etc/services I've seen lately are quite outdated
and missing particularities of given distros.

5) about why the portmap probe wasn't stopped at your firewall, I can only
assume that for some reason port 111 is open... (external NFS!?!?!) unless
other clever tricks are at work. Sounds like your firewalling rules need
fixin.

regards
-e