April 7 2025
Today, out of the blue, Little Snitch alerted me to an incoming connection attempt from IPv4 address 142.250.191.99 to UDP port 56878. (I denied the connection.) The IP address is in a range controlled by Google.
According to Little Snitch Network Monitor, there were no previous connection attempts of any kind to the syslogd process over the last month. Moreover, there were no previous incoming connection attempts from 142.250.191.99 to any port or process. However, there were a number of outgoing connection attempts to that IP address. Indeed, there was an outgoing connection to 142.250.191.99 at the same time as the incoming connection attempt to port 56878. The outgoing connection was from Safari to fonts.gstatic.com on UDP port 443, using the QUIC protocol. It's very common for web pages to load Google Fonts, and I was viewing a web page in Safari at the time of the Little Snitch alert.
It's crucial to note that there are two ports involved in any internet connection, the local port and the remote port. In this case, 56878 is the local port on my Mac. With the UDP QUIC protocol, 443 is the remote port on the web server, the same port that's used for https TCP connections.
The syslogd process is the Apple System Log server, located at /usr/sbin/syslogd on disk. According to the man page for syslogd:
The syslogd server receives and processes log messages. Several modules receive input messages through various channels, including UNIX domain sockets associated with the syslog(3), asl(3), and kernel printf APIs, and optionally on a UDP socket from network clients.
The man page also describes the options to syslogd, including -udp_in:
The “udp_in” module receives log messages on the UDP socket associated with the Internet syslog message protocol.
This module is normally enabled, but is inactive. The actual UDP sockets are managed by launchd, and configured in the syslogd configuration file /System/
Library/ LaunchDaemons/ com.apple.syslogd.plist. In the default configuration, launchd does not open any sockets for the “syslog” UDP service, so no sockets are provided to the “udp_in” module. If no sockets are provided, the module remains inactive. A socket may be specified by adding the following entry to the “Sockets” dictionary in the com.apple.syslogd.plist file.
Thus, the man page implies that syslogd should not be listening for UDP connections by default. Nonetheless, it is! When I ran the command sudo lsof -i in Terminal (lsof is short for list open files, and the -i option is short for Internet), the list included syslogd running as the root user, listening for UDP connections on port 56878.
The port number 56878 appears to be randomly selected. I booted into several macOS volumes, and the syslogd listening port number was different every time. By the way, I saw the syslogd UDP listener going all the way back to macOS 12 Monterey, but not on macOS 11 Big Sur.
Based on the given information, here's my theory, or speculation: the outgoing QUIC connection to fonts.gstatic.com randomly selected the same local UDP port that syslogd also randomly selected. It was pure coincidence, perhaps rare, yet with a non-zero chance of occurring. That's why Google was suddenly, almost magically—it turns out unintentionally—attempting to connect to syslogd. Google was innocently attempting to return the font data requested by Safari, but syslogd happened to be listening for data on that port already.
The remaining question is, why was syslogd listening for UDP connections from the internet in the first place? Unfortunately, I don't have an answer to that question. In any case, it doesn't seem like a good idea.
Addendum
I said, "By the way, I saw the syslogd UDP listener going all the way back to macOS 12 Monterey, but not on macOS 11 Big Sur." In retrospect, I think this was just because my Mac mini was already booted into Big Sur when I started testing. After booting into other macOS versions and later booting back into Big Sur, I see the syslogd UDP listener there too.
Apparently syslogd isn't listening on a UDP port 100% of the time. Currently, it's not listening on my MacBook Pro (according to sudo lsof -i), though it was when I first checked, and of course when the Little Snitch alert appeared. I have no idea when or why syslogd starts and stops listening.