An IRC server on port zero led a hacker to 2,905 unexpected service responses
Acidvegas followed a chat-network stunt into an IPv4 survey, where load-balancer error messages nearly drowned out the useful results.
The IRC daemon never knew it was doing anything weird. A firewall took connections addressed to port zero, changed their destination to 6667, and changed the replies back on their way out. The chat server stayed comfortably inside its usual port, while clients outside had to handle traffic addressed to zero.
Acidvegas’s November 6 write-up starts with that trick on irc.supernets.org. The author also redirected port 1 to the server’s encrypted IRC port. “The ircd never knows,” the author writes. Neither move required persuading the IRC software to accept a port its normal socket calls would interpret differently. Sometimes the workaround is just forwarding the mail to somebody who will open it.
An application asking the operating system to bind port zero normally gets an automatically selected port. The author traces that behavior through Linux, then separates it from what a TCP packet can contain. The packet has a numeric destination field, and zero fits. The software’s special meaning and the bytes on the network have wandered off in different directions (naturally).
Client software supplied the next headache. In the author’s tests, OpenBSD netcat and GNU inetutils telnet refused zero, while socat and Python asyncio connected. Chromium blocked it. A connection could therefore exist while the program at the other end of your keyboard insisted it should not.
The write-up even traces a Python SSL failure to a Linux peer-name check that treats destination port zero as evidence of an unconnected socket. An actual connection tripped the check anyway, leaving Python to report a failure while the underlying TCP connection was already working.
The bigger surprise came when the author pointed masscan at IPv4. It constructs its own packets, so the usual client objections did not stop the experiment. More than a million addresses answered the initial handshake, a number practically begging for an enormous headline. Instead of declaring a million discoveries, Acidvegas grouped the replies by network block and checked what those connections actually returned.
Most completed connections sent no application data. Of the 56,951 that sent something, 53,741 carried F5 BIG-IP reset explanations. Another 305 repeated a fixed token. Subtract those two groups and the remaining count is 2,905. That is the difference between finding a million hidden servers and finding a lot of networking equipment saying no in an unusually informative accent.
The remaining responses included 748 SSH addresses, 215 MySQL or MariaDB addresses, and 211 telnet addresses, according to the author’s classification. The report also describes building-control interfaces and phone-system call records. Those identifications are the researcher’s findings; the survey is one author’s account, with no independent reproduction presented here.
The author suspects some equipment inherited port-forwarding rules with an external port left at zero. That remains a guess, and the cause matters: an intentional hidden chat service and an accidentally exposed controller call for different fixes. The scan cannot supply the missing configuration history.
Security tooling could make this less awkward by distinguishing an unsupported port from a tested, closed service. Otherwise an operator gets a tidy report that says nothing about a working interface the scanner never attempted to inspect.
The chat server is still on 6667.