blog.over-update.download

• Mac Find App Listening To Port Settings

The following command displays information about all network ports in a two-node cluster: cluster1:: network port show Speed (Mbps) Node Port IPspace Broadcast Domain Link MTU Admin/Oper - - - - - - - node1 e0a Cluster Cluster up 9000 auto/1000 e0b Cluster Cluster up 9000 auto/1000 e0c Default Default up 1500 auto/1000 e0d Default Default up 1500 auto/1000 e1a. Try lsof sudo lsof -n -P -i +c 13 Output will be like. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME avahi-daemon 1222 avahi 13u IPv4 10835 0t0 UDP.:5353 avahi-daemon 1222 avahi 14u IPv6 10836 0t0 UDP.:5353 avahi-daemon 1222 avahi 15u IPv4 10837 0t0 UDP.:32913 avahi-daemon 1222 avahi 16u IPv6 10838 0t0 UDP.:41774 cupsd 1242 root 8u IPv6 1847 0t0 TCP ::1:631 (LISTEN) cupsd. The name of the protocol the port is using (TCP or UDP). The local IP address and name of the computer and the port number being used. The IP address and port number to which we’re connecting. The state of a TCP connection. For details on what these states are, read the Event Processing section of RFC 793. Using Netstat To See Listening Ports.

Click here to return to the 'Show which processes are listening to which ports' hint

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

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

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. Best sound noise reduction software mac. 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.

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.

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.

.. 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)

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.

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.)

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!)

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'.

What is this ?
SECx20He 222 savage 14u IPv4 0x03916b38 0t0 TCP *:49168 (LISTEN)
SECx20He 222 savage 16u IPv4 0x039167e4 0t0 TCP *:23000 (LISTEN)
No idea what these 2 are ?

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

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..)

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.

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

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

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

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

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?

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.

I use 'Little Snitch' which handles all this for me.
http://www.obdev.at/products/littlesnitch/

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

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.

Mac Find App Listening To Port Settings