Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Show which processes are listening to which ports System
I had the recent unforunate occurence of having my machine hacked into. And no, it wasn't a security hole, but simply a really weak password that was compromised through a brute-force ssh attack. During my audit/clean-up, I was trying to figure out what all the attacker may have installed, since I initially found a shellbot perl script running under the compromised account.

When a machine is compromised, you want to see what servers it may have installed, listening on your system. To do this, you need to "identify" all of the processes running servers. Normally you do this with fuser or netstat -nlp. Unfortunately, neither work on OS X.

I finally figured out how to do this, and just wanted to post it online so others searching could find it. In Terminal, just run this command:
lsof -i | grep LISTEN
This will list all processes that are listening on your machine. That's it!
    •    
  • Currently 3.71 / 5
  You rated: 5 / 5 (7 votes cast)
 
[103,376 views]  

Show which processes are listening to which ports | 31 comments | Create New Account
Click here to return to the 'Show which processes are listening to which ports' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Show which processes are listening to which ports
Authored by: Ezra Balaraj on Apr 26, '07 07:53:17AM

Hi,

I followed your instructions and got this :-

GoogleDes 271 ezra 14u IPv4 0x023a0200 0t0 TCP localhost:9011 (LISTEN)

Can you interpret what it means? Thank you.

---
EB



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: markuswarren on Apr 26, '07 07:54:53AM

GoogleDes sounds as though it might be GoogleDesktop, do you happen to have that installed?



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: jeremyp on Apr 26, '07 09:43:02AM

It's a process called GoogleDes with a pid of 271. The process is owned by user ezra. 14u means it is file descriptor number 14 and is open for update. The file type is an IP v4 socket and the next bit is the address in the kernel of the file structure. The 0t0 is the offset within the file which is a socket (being listened to) so probably meaningless. Finally it is a TCP socket on the localhost interface port 9011 and it's being listened to by the GoogleDes process.

Basically it means GoogleDes is listening for TCP connections on port 9011.



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: nvdingo on Apr 26, '07 07:54:14AM

While i haven't installed it on an OS X box yet, i have installed sshdfilter on my linux servers.
it should be possible to make it work under OS X with a little work.
Essentially, it watches the secure log for sshd login attempts. if the user name supplied doesn't exist, instant block of that ip address.
it just goes dead. the script automatically cleans those IP addresses out later at a user defined interval.
it gives you 3 attempts to get a user/password combination to login, before it blocks your IP address. That number is also configurable.
You can find sshdfilter, if you are interested in hacking it apart, on freshmeat.net
No, i am not the author, and am in no way affiliated.
i found it after one of my linux boxes was bruteforced through ssh.

the sshdfilter logs that i have emailed to myself in the morning are always amusing.
it's fun reading a couple dozen lines of 'Instant block of xx.xx.xx.xx, unknown user'
where i used to have hundreds of lines of attempts at user guessing.
oh, and anyone trying to use the root user is blocked instantly as well.



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: argh128 on Apr 26, '07 08:11:41AM

I had high hopes for this as a general tool to see what daemons are running... but it looks incomplete.

For example on my system it lists the following:
ARDAgent
AppleVNC
SubethaEdit

but not SSHD, or any other services (SMB, WEB, etc)... Am I missing a reason why these services are not showing up?



---

A completely SANE Canadian.



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: doctype on Apr 26, '07 08:16:17AM
To see all processes, prepend sudo:

sudo lsof -i | grep LISTEN

[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: doctype on Apr 26, '07 08:18:34AM

... and btw, ssh is managed by launchd, so you will only see sshd in the list if there is a current session (somebody is currently logged in)



[ Reply to This | # ]
Not true
Authored by: kholburn on Apr 27, '07 10:30:57AM
If you have ssh enabled you will see something like this:

launchd       1 root    9u  IPv6 0x386dc50      0t0  TCP *:ssh (LISTEN)
launchd       1 root   10u  IPv4 0x3d85e08      0t0  TCP *:ssh (LISTEN)
The ssh port has to have something listening on it if you are able to log in.

hmmm.... I have IPv6 configured to be off so why is launchd also listening on an IPv6 port? That's not good.

[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: argh128 on Apr 26, '07 10:15:19AM

Good point.

And really, when not run as root this would be almost useless to find "trojans" (Assuming that it was able to in the first place)

---

A completely SANE Canadian.



[ Reply to This | # ]
additional hint: see all processes
Authored by: doctype on Apr 26, '07 08:14:48AM
This command lists only the processes of the current user. If you want to see all (e.g. maybe the attacker got root access?), you would have to prepend sudo to run the command as root (administrator/"super user"):

sudo lsof -i | grep LISTEN

You will then be asked for your (administrator) password: The password you may use to login into your account (if it is a privileged account).

[ Reply to This | # ]
Don't trust this on hacked machines...
Authored by: dbs on Apr 26, '07 08:55:54AM

This is a great tool in general, but be very careful of trusting this on a hacked machine.

A common technique of hackers is to replace programs like lsof, ps, top, etc., with hacked versions which explicitly don't show any of their trojan processes. So if your machine has been hacked by all means use this to look around and see what happened, but don't trust it to indicate your machine has been cleaned.

The only decently reliably way to clean up from a hack is to re-install the OS from scratch and then copy data over from a backup. (If you restore the OS from a backup you don't have any way of knowing whether the backup was made before or after the hack for the same reasons mentioned above.)



[ Reply to This | # ]
Don't trust this on hacked machines...
Authored by: lar3ry on Apr 26, '07 10:52:19AM
That's all well and good, but that's incomplete advice.

If the user wants to find out what processes are listening on TCP/IP ports, the lsof program will work, albeit with your caveat that the program may be hacked.

Other things that could be done to simply check for listeners which are not as drastic as a complete system reinstall would be:

  • attempt to locate a program like lsof on the OS X install disk, if possible, by exploring the base install packages
  • transfer the image from another OS X system that you know for sure isn't compromised
  • Find the sources to the utility and compile it yourself
Once you have a "known good" copy, you can run it to check out if anything is awry.

Oh... and backup, backup, backup! If you have a smart backup script with incrementals running daily, you might be able to see how and where your system may have been internally compromised (recent edits to files in /usr/bin are a good clue!)

[ Reply to This | # ]

Don't trust this on hacked machines...
Authored by: kholburn on Apr 27, '07 10:36:15AM

That wouldn't work if the hacker has compromised libraries. You would need a statically linked binary.

What hackers might not do is replace "Activity Monitor" because unix hackers don't expect apple gui tools.

None-the-less if you have been hacked you need to reinstall the OS. There is no real way around this.

Also turn on your firewall and you might consider "Little Snitch".



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: Anonymous on Apr 26, '07 09:23:50AM

What is this ?

SEC\x20He 222 savage 14u IPv4 0x03916b38 0t0 TCP *:49168 (LISTEN)
SEC\x20He 222 savage 16u IPv4 0x039167e4 0t0 TCP *:23000 (LISTEN)

No idea what these 2 are ?



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: jeremyp on Apr 26, '07 09:47:09AM

It's a process whose name begins "SEC He" and has pid 222. Use Activity monitor to find it.



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: ddauerbach on Apr 26, '07 11:12:23AM

So my ignorant 'what are these' question is:
What are these?
netinfod 80 root 7u IPv4 0x02ed7e8c 0t0 TCP localhost:netinfo-local (LISTEN)
AppleFile 179 root 30u IPv6 0x02a2bc50 0t0 TCP *:afpovertcp (LISTEN)
AppleFile 179 root 31u IPv4 0x02ed569c 0t0 TCP *:afpovertcp (LISTEN)
cupsd 191 root 0u IPv4 0x02ed713c 0t0 TCP localhost:ipp (LISTEN)
python 679 david 4u IPv4 0x03089740 0t0 TCP localhost:50000 (LISTEN)
firefox-b 1466 david 32u IPv4 0x040e669c 0t0 TCP localhost:50001 (LISTEN)
slpd 3531 root 2u IPv4 0x03f44200 0t0 TCP *:svrloc (LISTEN)

(yeah, I know firefox...)



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: bloodycelt on Apr 26, '07 12:52:13PM

netinfod - Netinfo (It's from next Step, stores info normally found in the /etc folder, like passwords. Will be replaced by ldap in the future).
AppleFile AFP Daemon, it allows you to connect to afp shares.
cupsd CUPS is an open source print daemon/driver.
python - Are you running any scripts? Look this one up in activity monitor.
slpd - service location protocol, wiki says osx uses this to find network shares.



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: ddauerbach on Apr 27, '07 07:17:37AM

679 python david 0.00 1 1.16 MB 41.49 MB PowerPC



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: uurf on Apr 26, '07 02:15:28PM

Are you running Salling Clicker? if so it's SEC Helper.



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: ctierney on Apr 26, '07 02:02:51PM

Thanks for the tip.

On a side note, a great way to shut down these attacks is to setup key authentication, then disable password authentication in /etc/sshd_conf:
PasswordAuthentication no
Don't forget to HUP sshd for the setting to take effect.

--
Cole



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: johnqsmith on Apr 26, '07 03:53:25PM

that's pretty useless if the state isn't LISTENING (for instance, like , oh, I don't know...ESTABLISHED?) You don't care about what connections are ALL READY going on? OK then, use the suggested command.

lsof -nP | grep TCP
or
lsof -nP | grep UDP

are better by far



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: bdm on Apr 27, '07 04:08:06AM

So why is Microsoft Word listening on port 3806 (TCP)?



[ Reply to This | # ]
Microsoft Office opens random ports
Authored by: luomat on Apr 27, '07 10:48:56PM
Microsoft Office for Mac opens random TCP and an UDP port to "protect" you from using more than one copy of same license on the network. See Disable Office v.X network serial number check and CIACTech02-003: Protecting Office for Mac X Antipiracy Server Ports

[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: morespace54 on Apr 27, '07 11:08:21AM

Hi...

sorry but what about:

mysqld 205 nobody 4u IPv4 0x01f62f50 0t0 TCP 127.0.0.1:50701 (LISTEN)

I know it must be MySQL, but being run by 'nobody'?
Could that be a problem?



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: fbitterlich on May 03, '07 12:21:13PM

On the contrary, this is a good thing. Some processes (like mysqld) drop their privileges after launchinf and acquiring a socket to listen on, running under an unprivileged "nobody" user ID. So if the security of that process is compromised somehow, at least the attacker cannot easily exploit the elevated privileges of that process to do more damage.



[ Reply to This | # ]
Little Snitch
Authored by: bronskrat on Apr 27, '07 11:50:28AM

I use "Little Snitch" which handles all this for me.

http://www.obdev.at/products/littlesnitch/



[ Reply to This | # ]
There is a better command for this I guess
Authored by: tice on Apr 28, '07 05:28:04AM
Try to use the command lsof -i TCP and you get a more complete list and more details (in FreeBSD).

[ Reply to This | # ]
Combined suggestions and got even more info
Authored by: vickishome on Apr 28, '07 10:31:45AM
I don't know what I'm doing at all, but I decided to combine two of the suggestions already posted by johnqsmith, tice, and doctype to come up with:

sudo lsof -nP | grep TCP
and
sudo lsof -nP | grep UDP

The first one gave me the most information that I could somewhat understand. But in either case, they both gave me more information than any of the other suggestions by themselves.

Using sudo lsof -nP | grep TCP, I got:

mDNSRespo 33 root 11u IPv4 0x0333eca0 0t0 TCP *:* (CLOSED)
netinfod 34 root 7u IPv4 0x02358e8c 0t0 TCP localhost:netinfo-local (LISTEN)
netinfod 34 root 8u IPv4 0x0333f69c 0t0 TCP localhost:netinfo-local->localhost:956 (ESTABLISHED)
netinfod 34 root 10u IPv4 0x023573ec 0t0 TCP localhost:netinfo-local->localhost:1021 (ESTABLISHED)
Directory 45 root 6u IPv4 0x02357740 0t0 TCP localhost:1021->localhost:netinfo-local (ESTABLISHED)
Directory 45 root 11u IPv4 0x02f473ec 0t0 TCP *:* (CLOSED)
Directory 45 root 33u IPv4 0x03340a94 0t0 TCP *:* (CLOSED)
cupsd 367 root 0u IPv4 0x02d587e4 0t0 TCP localhost:ipp (LISTEN)
Safari 2519 admin 25u IPv4 0x02e56d44 0t0 TCP 192.168.2.20:52459->scds77.ord.llnw.net:http (CLOSED)
lookupd 3770 root 6u IPv4 0x02e56348 0t0 TCP localhost:956->localhost:netinfo-local (ESTABLISHED)

And using sudo lsof -i UDP, I got:

mDNSRespo 33 root 7u IPv4 0x01fb1ad0 0t0 UDP *:mdns
mDNSRespo 33 root 8u IPv6 0x01fb1a00 0t0 UDP *:mdns
mDNSRespo 33 root 9u IPv4 0x01fb0340 0t0 UDP 10.0.1.2:52066
mDNSRespo 33 root 12u IPv4 0x01fb0000 0t0 UDP *:mdns
netinfod 34 root 6u IPv4 0x01fb1e10 0t0 UDP localhost:netinfo-local
syslogd 35 root 17u IPv4 0x01fb1d40 0t0 UDP *:*
Directory 45 root 10u IPv4 0x01fb0750 0t0 UDP *:*
Directory 45 root 31u IPv4 0x01fb1860 0t0 UDP *:*
ntpd 193 root 5u IPv4 0x01fb1ba0 0t0 UDP *:ntp
ntpd 193 root 6u IPv4 0x01fb1790 0t0 UDP localhost:ntp
ntpd 193 root 7u IPv4 0x01fb1c70 0t0 UDP 192.168.2.20:ntp
automount 228 root 8u IPv4 0x01fb0b60 0t0 UDP localhost:1023
automount 234 root 8u IPv4 0x01fb12b0 0t0 UDP localhost:1022
cupsd 367 root 6u IPv4 0x01fb1110 0t0 UDP *:ipp

While I don't know what all that means, what I can do is run these commands randomly and keep a log of the results. So I'd then have something to compare with if I'm concerned that something is not going right.

I think what might work is to log into my "clean admin" account, run both commands, and log what came up. Then I'd have a baseline to work with that isn't so highly affected by my personal user activities.

Does anyone see any problems with this?

---
Vicki

[ Reply to This | # ]

looks like you've been pwn'ed!
Authored by: craigw on Apr 28, '07 04:06:11PM
Just kidding. I put the two in a shell script like this:

#!/bin/sh
/usr/sbin/lsof -nP | grep TCP
/usr/sbin/lsof -nP | grep UDP
And I made it executable by owner, with owner root. That will remind me to run it with sudo, for more complete results.
For a few records to compare, you could put something like that into a daily or hourly cron job & direct the output into a log file.

[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: 97mop on May 07, '07 08:10:29AM

Never use setuid on a shell script! Simply by making a softlink from your script to a file named "-i", anyone can root you. Google it for details, but basically adding #!/bin/sh to the beginning of the file will cause the shell to take the name of the script ($0) and create a new command with /bin/sh and then the name of the script. If the filename of the script is -i, then the command becomes "/bin/sh -i", and your attacker just got an interactive root shell.



[ Reply to This | # ]
Show which processes are listening to which ports
Authored by: lpds on May 26, '07 07:23:00AM
hi, netstat -an | grep LISTEN should work on osx i tried it on my macbook .. works fine and btw. lsof -i | grep LISTEN returned with nothing netstat sais i have something on .1033 on localhost maybe that lsof bypasses loopback ifaces ?

[ Reply to This | # ]