Security Incidents mailing list archives
Re: port 768
From: eric () ERICPRESTON COM (Eric Preston)
Date: Mon, 31 Jan 2000 01:59:45 -0500
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
Current thread:
- Re: port 768 Guido A.J. Stevens (Jan 28)
- Re: port 768 Richard Johnson (Jan 28)
- Re: port 768 Dave Dittrich (Jan 28)
- Re: port 768 Robert Graham (Jan 28)
- First china, now russia? Joseph Geyer (Jan 30)
- Re: port 768 Eric Preston (Jan 30)
- <Possible follow-ups>
- Re: port 768 Guido A.J. Stevens (Jan 28)