I'm on osx. netstat -an -f inet gives me a bunch (around 10) of entries like these:

udp4       0      0  *.*                    *.*
udp46      0      0  *.*                    *.*

In my understanding, this means there are applications accepting udp packets on any port from anywhere on any interface. Isn't this a security risk? How do I identify the processes that opened these sockets?


I identified some processes owning these sockets using lsof -i. They include WiFiAgent, sharingd, SystemUIServer and UserEventAgent. All of these seem to be part of OSX. However, there are much more entries in the netstat output than in the lsof output.

In addition, I still fail to interpret the netstat output. I thought it is only possible to open a BSD socket on a specific port, or to let the kernel assign a port if none is specified. So what does the *.* mean in the "Local Address" column?

  • The netstat command should give you the process name or PID, it's just a matter of setting the correct command line switches. Use netstat --help for info. – André Borie Aug 23 '15 at 20:07
  • Thanks for the answer. However, on osx i am stuck with the BSD version of netstat, which does not support printing pids. – madmax1 Aug 23 '15 at 20:10
  • 1
    @AndréB. The PID or the program is only visible to the root user. Try the -p option. – ott-- Aug 23 '15 at 20:14
  • This has nothing to do with security issues – user45139 Aug 24 '15 at 1:03

I don't think you need to be too concerned. There are many legitimate reasons to have the UDP processes you have identified.

As you have noted, lsof can be used to find out which program is associated with the socket. Note that you will need to use sudo to run the command if you want to see information for processes which are not owned by the current user.

The . is the interface and port. If the interface is *, it means that the socket is bound to or can bind to all interfaces i.e. the IP of your ethernet or wireless interface and possibly the 224/multicast interface.

If the port is listed as *, it normally means there is no active connection to the port and there is no defined or well known port used by that service or it is a service that allocates ports dynamically and there is no current connection. When there is a connection, there will also be something listed in the status column, such as LISTEN, ESTABLISHED etc.

UDP ports are broken up into 3 basic groups 0 - 1023 used for common, well known services. Ports 1024 - 49151 for IANA-registered port use and 49152 - 65535 which are available for use by services and can be assigned dynamically as needed (assuming nothing else is using the port of course).

With respect to general security, there are a few basic principals you should follow

  1. Turn on the OSX firewall. This will limit what can connect and to what ports. In general, the standard config allows your services to connect to external addresses but only allows external address to connect to you for either ports you allow or when it is part of some already established session - for example, if you have initiated a service which as part of that service, the remote system needs to communicate back to you on a UDP port.

  2. Disable any services you don't use. For example, if you don't use OSX data sharing services, turn them off. Likewise, if you are connected over a wired connection and don't need wireless, turn it off. If you don't use/need location services, turn them off etc.

  3. Some services can be configured to only listen on specific interfaces or only allow connections from specific hosts. This is more common with TCP, but can be done with some UDP based services. However, you need to be careful as you can break or adversely impact on a service if you restrict it incorrectly.

The key point is that you don't rely just on a single layer of protection. You have multiple layers so that if one layer should fail (due to a bug, misconfiguration, zero-day vulnerability etc) other layers of protection may provide protection. For example, I have a firewall on my OSX system, a firewall on my router and various security settings on my internal networking switch.

One of the benefits of something like OSX over Linux (for example) is that it has pretty reasonable defaults. Provided you follow the advice/best practice recommended by Apple, your in a pretty good position. However, one of the disadvantages of this approach is that it is often much harder to tweak the configuration to meet your specific needs. With a Linux system, you have full control and can tweak it to be as locked down as you like. However, you also have the power to completely screw it up. With OSX, Apple has taken some of that power away or made it very difficult to get to, so you have less chances of screwing it up. However, when Apple screw it up, then everyone is at risk. The other problem is that because it is so standardised,it provides a bigger target. Linux, with less standardisation means that if someone wants to find an exploit, they also have to find a Linux box with just the right mixture of software and configuration in order to have assurance the exploit will work. This is why I use my Linux system for high risk situations/environments and my OSX system for low risk situations. I spend less time tweaking and configuring my OSX system and it is convenient. I spend more time with the Linux system and while it is less convenient, it is more secure.

It should be noted that as UDP is a connectionless protocol which does not have the 3-way handshake of TCP, the security threats are a bit different. UDP is sometimes referred to as an unreliable connection because it does not have all the checks and balances of TCP sockets. It is used where loss of datagrams or datagrams arriving out of sequence is not a problem. It therefore tends to be used when you want to send/receive simple and low importance data. It isn't suitable for bi-directional communication where the order of packets is important and there is likely to be a 'session' involving a bi-directional conversation/communication. This doesn't mean you can't do such things, but that it is typically harder and less reliable than a TCP connection.

One of the most common threats based around UDP is denial of service. Because there is no handshake in the protocol, it is very easy to spoof the originating source IP. Many of the reflection and amplification denial of service attacks use this technique. For example, I could use the NTP protocl config flaw which allow you to query an NTP server over UDP to request a list of all the servers which have used it to synchronise their time, but instead of having my IP address associated with the query, I spoof a victims address. The NTP server receives the request and sends the response back to the spoofed IP I used. This is the reflection part. As the response is much large (more bytes) than the request, the data returned is larger than the data sent - this is the amplification part. If I do this to a large number of NTP servers, suddenly my victim starts receiving all these UDP datagrams it did not request. You can't do this easily with TCP because when I spoof the address, the destination I send the data to immediately tries to do a handshake with the spoofed IP I used. The real host with that IP will receive this handshake attempt and essentially go "eh What?" and the handshake will fail because it did initiate and doesn't know anything about the connection.

| improve this answer | |

Try using the following command:

lsof -nP | grep UDP
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.