Port 853?

[Shabu Khan-2]

We recently had a PCI compliance audit and they asked us to run netstat -an on one of our boxes and asked us to explain what each port was for anything under 1024, one of the ports that I couldn't find concrete information about was 'Port 853'.

We are running 11.23 on IA 64 with the latest bundle.

lsof -i:853 doesn't show any information, couldn't get enough information from lsof | grep -i udp either, but netstat -an | grep 853 shows that it is listening, but it is not listening all the time, it goes away sometimes and listens back up again.

From a few google searches it looked like ypbind but I don't have NIS or anything like that running on the box, this is a production system and I am sure it is a startup script that starts something up and listening on port 853?
I also looked at the IANA link for ports:
http://www.iana.org/assignments/port-numbers,
853 falls in the range of unassigned category (849-859) ...

Any thoughts?

Thanks,
Shabu

[Rick Garland]

Look into the /etc/services file. Is that port listed in there?

Maybe some application?

[Shabu Khan-2]

I forgot to mention that it is not listed in /etc/services either, that would have been too easy :)

Thanks,
Shabu

[A. Clay Stephenson]

By any chance are you using Amanda for backup?

[Rick Garland]

Yea, I thought it was too easy as well :)

[A. Clay Stephenson]

Plan B: Have a cron job that runs every 5 minutes or so and does an "lsof -i :853 > /var/tmp/myfile".

[Shabu Khan-2]

sorry guys I had to run to a meeting ...

No, we are using net Backup for backups.

I actually have a while true loop going to spit out netstat -an and lsof output ... didn't find anything so far (I've been running for the last hour or so) ...

Thanks,
Shabu

[A. Clay Stephenson]

OK, since this is a low port number, the effective UID must be 0 meaning that this process must be started by a super-user. You said that you examined the /sbin/init.d for any processes. Have you check crontab, at jobs, and/or anything in /etc/inittab?

How many people have the root passwd? This could be some explicit command rather than a triggered process. It might also be a setuid program so a quick scan for setuid files might reveal something --- of course, you should be doing that anyway and comparing it to a list of "ok" setuid files. It could also be a sudo'ed command.

The fact that an unassigned port is used, indicates some discipline on the part of the developer.

[Shabu Khan-2]

Thanks Clay for your inputs, I looked around and still couldn't find any information.

Another port that I couldn't find information on is Port 834, it shows-up in the output of netstat -a | grep 834 as:

udp 0 0 *.834 *.*

But, lsof -i:834 returns nothing. Do you know why it doesn't, but lsof | grep -i udp shows a bunch of udp ports and some of the output doesn't say a port number but:

UDP *:* (Unbound)

and ofcourse there is a process that is tied to it like alarmgen, agdbserver and rep_server

For now, any informatin on what port 834 could be would be helpful.

THanks,
Shabu

[Rasheed Tamton]

Try any luck with below:

lsof -i tcp:853
lsof -i udp:834

lsof â iTCP

lsof -i TCP|grep ":853 "
lsof -i UDP|grep ":834 "



Regards,
Rasheed Tamton

[Shabu Khan-2]

Nope.

Here is the output of lsof -i UDP

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
inetd 1099 root 4u IPv4 0xe00000021fc4ce40 0t0 UDP *:49176 (Idle)
inetd 1099 root 11u IPv4 0xe00000021fc4cac0 0t0 UDP *:hacl-cfg (Idle)
snmpdm 1387 root 6u IPv4 0xe00000021effd3c0 0t0 UDP *:snmp (Idle)
snmpdm 1387 root 7u IPv4 0xe00000021effd580 0t0 UDP *:* (Unbound)
mib2agt 1423 root 3u IPv4 0xe00000021f1ac040 0t0 UDP *:* (Unbound)
dced 1490 root 3u IPv6 0xe00000021dfc1040 0t0 UDP *:* (Unbound)
dced 1490 root 8u IPv4 0xe00000021dfc1900 0t0 UDP *:135 (Idle)
xntpd 1597 root 4u IPv4 0xe00000021e062580 0t0 UDP *:ntp (Idle)
xntpd 1597 root 5u IPv4 0xe00000021e062200 0t0 UDP hostnamehb.unix.gsm1900.org:ntp (Idle)
xntpd 1597 root 6u IPv4 0xe00000021e062040 0t0 UDP hostnamea.unix.gsm1900.org:ntp (Idle)
xntpd 1597 root 7u IPv4 0xe00000021e062740 0t0 UDP hostname.unix.gsm1900.org:ntp (Idle)
xntpd 1597 root 8u IPv4 0xe00000021e062900 0t0 UDP localhost:ntp (Idle)
perflbd 1764 root 6u IPv6 0xe00000021f1b43c0 0t0 UDP *:* (Unbound)
vxsvc 2026 root 6u IPv4 0xe00000021fca2040 0t0 UDP *:2148 (Idle)
cmcld 2101 root 8u IPv4 0xe0000002249e7200 0t0 UDP localhost:49361 (Idle)
cmcld 2101 root 9u IPv4 0xe0000002249e7040 0t0 UDP *:49363 (Idle)
cmcld 2101 root 14u IPv4 0xe00000021e062e40 0t0 UDP *:49364 (Idle)
cmcld 2101 root 21u IPv4 0xe00000021cca0200 0t0 UDP hostnamehb.FQDN.org:5300 (Idle)
cmcld 2101 root 23u IPv4 0xe00000021cca0580 0t0 UDP hostnamehb.FQDN.org:5301 (Idle)
cmlogd 2113 root 1u IPv4 0xe0000002249e7740 0t0 UDP localhost:49362 (Idle)
opcmsga 2401 root 28u IPv4 0xe0000002242ed580 0t0 UDP *:49676 (Idle)
dtlogin 2450 root 7u IPv4 0xe00000021f49eac0 0t0 UDP *:xdmcp (Idle)
rep_serve 3901 root 6u IPv6 0xe00000021f1b43c0 0t0 UDP *:* (Unbound)
rep_serve 3901 root 11u IPv6 0xe00000021f498740 0t0 UDP *:* (Unbound)
rep_serve 3901 root 13u IPv4 0xe00000021f498c80 0t0 UDP *:50403 (Idle)
agdbserve 3922 root 6u IPv6 0xe00000021f1b43c0 0t0 UDP *:* (Unbound)
agdbserve 3922 root 12u IPv6 0xe00000021ce24ac0 0t0 UDP *:* (Unbound)
agdbserve 3922 root 14u IPv4 0xe00000021ce24580 0t0 UDP *:50406 (Idle)
alarmgen 3925 root 6u IPv6 0xe00000021f1b43c0 0t0 UDP *:* (Unbound)
alarmgen 3925 root 8u IPv6 0xe00000021dd0b900 0t0 UDP *:* (Unbound)
alarmgen 3925 root 12u IPv6 0xe00000021ce24ac0 0t0 UDP *:* (Unbound)
cmclconfd 11241 root 3u IPv4 0xe00000021fc4cac0 0t0 UDP *:hacl-cfg (Idle)
syslogd 13309 root 6u IPv6 0xe000000245dbe900 0t0 UDP *:syslog (Idle)
swagentd 13915 root 8u IPv6 0xe00000028687b3c0 0t0 UDP *:* (Unbound)
swagentd 13915 root 12u IPv4 0xe00000028687e3c0 0t0 UDP *:2121 (Idle)
emagent 23924 oracle 10u IPv4 0xe0000002503ebac0 0t0 UDP localhost:51624 (Idle)
emagent 23924 oracle 14u IPv4 0xe000000226339580 0t0 UDP localhost:51620 (Idle)
oracle 27233 oracle 17u IPv4 0xe000000250501e40 0t935 UDP localhost:54952 (Idle)
oracle 27250 oracle 40u IPv4 0xe000000245ecd740 0t0 UDP *:59080 (Idle)
oracle 27258 oracle 28u IPv4 0xe0000002504e7200 0t0 UDP *:52880 (Idle)


Here is the output of 'netstat -an | grep 834'

udp 0 0 *.834 *.*

Thanks,
Shabu

[Rick Garland]

Got a linux box handy on the network? Run 'nmap' against that server.

nmap -A -T4


It is available at http://gate.cs.utah.edu/ hppd/hpux/Networking/Admin/nmap-3.93/ if you need HPUX depot binary

[Maxim Yakimenko]

run lsof with extra option -P

lsof -P | grep 834

This option prevents lsof resolving port numbers to port names

[Maxim Yakimenko]

I mean

lsof -P | grep 853 :)

[Shabu Khan-2]

lsof -P didn't help ...
Anyways I think it is coming together now, read the faqs on lsof and it makes sense on why it would show-up on netstat and not lsof and also throws some light around my question regarding port 834.
Here it is:
Why can't lsof find accesses to some TCP and UDP ports?
Kernel implementations sometimes set aside TCP and UDP ports for communicating with support activities running in application layer servers -- the automountd and amd daemons, and the NFS biod and nfsd daemons are examples. Netstat may report the ports are in use, but lsof doesn't. These kernel ports are not associated with file system objects, may be set aside by the kernel on demand, and sometimes are never released. Because they aren't associated with open file system objects, they are transparent to lsof. After all, lsof does stand for LiSt Open Files, and there are no open files associated with these kernel ports. I don't know a way to determine when ports reported by netstat but not by lsof are reserved by the kernel.


Thanks,
Shabu

[Maxim Yakimenko]

Well,
Very interesting, so if it is used for internal needs of kernel then this is not your problem - is it?