Unidentified opened ports on HP-UX 11.23 systems

[Virgil Chereches_2]

Hi gurus!
I have the following annoying issue:
after a security audit I have discovered that some ports are opened on my systems and that I cannot find which program uses it.
Moreover, I've found a tcp-ip communication on the loopback interface and neither of the ports can be found in lsof output.
And now some details:
#netstat -an|grep 817|grep udp
udp 0 0 *.817 *.*
#lsof -i udp:817
#
# netstat -an|grep 1023|grep udp
udp 0 0 *.1023 *.*
# lsof -i udp:1023
#
# netstat -an|grep 53043
udp 0 0 *.53043 *.*
# lsof -i udp:53043
#
# netstat -an|grep 49179
tcp 0 0 127.0.0.1.49179 *.* LISTEN
tcp 0 0 127.0.0.1.49179 127.0.0.1.777 ESTABLISHED
tcp 0 0 127.0.0.1.777 127.0.0.1.49179 ESTABLISHED
# lsof -i tcp:777
#
# lsof -i tcp:49179
#
In all cases the lsof output was null.
The ports aren't listed either in rpcinfo -p output and all, except the tcp one, allow connecting from outside.
The behaviour is more or less common to few fresh installed systems; however I couldn't find any common links between the ones which exhibit the behaviour and the ones that don't.
Please advice on some investigation methods.
The version of lsof used is 4.77.

Thank you in advance,
Virgil

[Steven E. Protter]

Shalom Virgil,

The software porting center has nmap for HP-UX which permits self scan of all ports.

You can also use a Linux box, which will be more realistic and likely to work.

Always check with network administration prior to running a port scanner.

I get a little picky when people do it to my boxes without notice.

SEP

[Rick Garland]

nmap is a good choice to assist you in determining what is running on a port.

Comes wiht Linux distros such as RedHat and Fedora.

As mentioned, the porting center has it too.
http://gatekeep.cs.utah.edu

A good tool but do be wary of running it against unsuspecting systems - sysadmins get a little annoyed when when are being port scanned.

[Virgil Chereches_2]

I have already tried nmap. Unfortunately for all ports I've mentioned in my first post the output shows only: open/filtered unknown:
PORT STATE SERVICE VERSION
53043/udp open|filtered unknown
Device type: general purpose
Running: HP HP-UX 11.X
OS details: HP-UX B.11.11
Network Distance: 1 hop
My nmap version is 4.20
However, there should be some way of finding out what binds on these ports. I have also tried to gather some network packets with nettl but in a relative short period of time (3 minutes) I couldn't sniffer any relevant packet.

[Florian Heigl (new acc)]

I think You were on the better track using lsof.

I know port 1023/udp as something 'normal' for HP-UX and I was able to locate its process using lsof.

I can't locate a box with port 777 open, but /etc/services says it's related to openview.

Checking with IANA shows HP messed up and didn't register the port there, I would assume this is why it popped up during the audit.[*]

conclusion a)
1023 and 777 seem ok, but actually it's weird how 777 connected back to 49179
guess b)
certain policies won't let me use lsof right now but I'd hope You just got some parameter wrong. I'll have a look at this at home.

817,53043 and 49179 appear strange and are not registered or known for backdoors.
if it need be, kill processes till the ports close :)


Florian

[rant]
Same applies for port 1023, which is IANA reserved, I really wonder what makes vendors think they can use ports the IANA reserved.

[Virgil Chereches_2]

Florian, you replied that: "I know port 1023/udp as something 'normal' for HP-UX and I was able to locate its process using lsof."
Can you please tell me which process name has you tracked with lsof?
In my case I can find the port 1023 opened on some hosts while on other is closed. I couldn't figure out until now the relation between the ones with the port opened.
Concerning the ideea with killing all processes until finding which one was opening the port I could tell you that I should find first a test system which exhibit the same behaviour; still killing all user processes doesn't guarantee that the port is closed: it is quite well possible that the port be opened by a kernel daemon.
I have tried to stop all nfs processes and the ports remain opened.

[Biswajit Tripathy]

Another option would be to run IPFilter firewall and block the port and see what stops working ;-)

LISTEN on higher ports like 49179 could be because of FTP data connections.

- Biswajit