Messages in this thread | | | Date | Thu, 05 Aug 1999 09:43:07 -0400 | From | "Cliff Woolley" <> | Subject | Re: tracing ports open by kernel modules |
| |
>>> "Lennert Buytenhek" <buytenh@dsv.nl> 08/05/99 06:38AM >>> >>haven't yet gotten a good answer to. I'm writing a perl script to audit >>the IP ports that are open on a machine, giving the name of the service >Don't you mean TCP/UDP ports? IP has no such thing as ports. >Furthermore /etc/inetd.conf is a very unreliable indication for what >ports are open.
Yes, that is exactly what I meant. I just said IP because I was generalizing... ie, the mechanism should work regardless of what higher-level proto is used, TCP, UDP, RAW, whatever. So ignore that part.
As for inetd.conf, assuming inetd is running, it's a good starting place, as ports will be open that don't necessarily map to any process except inetd when no connections are open. That's why I use that... just to ferret out which program it will END UP being when the connection gets opened.
>> The only part I haven't figured out is for ports open by the kernel. >> Where can I get the type of information that fuser will return for user >>processes for these modules? Take kernel-based NFS as an example... it >>seems to show up with its own PID, and I can make a fairly educated >>guess that 800/udp maps to it, but that's not exactly definitive. >"netstat -at" or "netstat -au"? Just my educated guess.
I'm already using netstat. It's the basis of the whole thing. Based on that, I know which ports are open and therefore which ones to analyze. It's just that I need to match up the port with a PID, which netstat doesn't seem to want to do with these kernel processes (trying 'netstat -anp' you just get a - where the process name should be), and fuser won't for kernel processes because... (see below).
>> Checking the /proc/<pid> information for that process yields >>virtually nil. Is there are reason for this? >Yes, there is a reason. /proc/<pid> for _that process_? What >process are you referring to? knfsd, is this a process? (could >be, I don't run it). Well, that's probably because kernel threads >don't need fds. Generally, kernel threads don't have fds (they >surrender their 'file' state with an exit_files (I believe) when they >go kernel-thread.) Kernel threads just request raw sockets from >the networking layer (struct socket I believe) and they use them >to read/write etc. They do not need referring fds. (When a write >or read from userspace comes in, first the corresponding 'struct >file' is sought for that fd, and when it is a socket the >corresponding 'struct socket' is looked up, and this one is >passed down the kernel.).
That would be a good reason. :( Hmmm.... I don't guess there's any way to keep track of which module answers which port, then. Yuck.
>You could go dig in /proc for open networking sockets (maybe >/proc/net/tcp or /proc/net/udp gives you what you want? Try >/proc/net/raw for raw IP sockets. There are also IPv6 versions >if you have 2.2/2.3) but you will not find them under /proc/<pid>/fd/ >etc. because these sockets you are looking for have no fd's.
That's the same problem again... Digging in /proc/net/[tcp|udp], I *do* find the ports in question, and an inode that they belong to... but I can't seem go glean anything useful from the inode number. Thoughts? What exactly does it represent?
Thanks again, Cliff
Cliff Woolley Central Systems Software Administrator Washington and Lee University http://www.wlu.edu/~jwoolley/
Work: (540) 463-8089 Pager: (540) 462-3472
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |