[osiris] Re: osiris 4.2.1 -- regression from 4.2.0?

[David Vasil]

Michael Menge wrote:
> Hi
> 
> i think the name of the process listening would be more usefull then the 
> inode.
> Is there a way to insert this information in the mod_ports?

It would be more useful, and it is possible, however, it requires a bit 
more effort to attain the process name instead of just the inode.  Here 
is part of an email I sent back on 08/17/2005 to the list:

--------------------
It takes a bit more work to get the actual program name/pid in the
output. Ideally you would need to build a hash table of the processes
which have sockets open, and then do a lookup to that table using the
inode associated with the port in question.

Having the uid number may be useful for filtering purposes though.  And
if the inode changes, that may arouse suspicion as to the process
opening the port.  Input on this is welcomed.
--------------------

Programs like lsof and netstat get the process name by building a list 
of entries in /proc that have sockets open for file descriptors in 
/proc/<process id/fd/*.  They then map the /proc/net/tcp|udp inode entry 
to the socket number and get the command name from /proc/<process id>/exe.

At the time, adding in the uid and inode to mod_ports was a trivial task 
since the information was already in /proc/net/tcp, it just wasnt being 
reported in the mod_ports output.  My original thinking on this was: 
having the UID information is useful since if a port is opened with a 
UID of a privileged user, an immediate investigation should be conducted 
if it was an unexpected event.

If the inode of a port changed, this meant the process holding that 
particular port had likely been restarted (either restarted as part of a 
normal operation [weekly log rotations for syslog], or restarted as part 
of a malicious purpose [an intruder broke in, replace sshd, and 
restarted the process]).

Regardless, I will look into how much work it would require to integrate 
an 'lsof -i' type functionality to get the process name into mod_ports. 
  It would most likely require non-trivial changes to mod_ports which 
would require some time to implement.

-dave