Responded to an odd incident tonight.

An admin noticed UDP ports 517 and 518 were reported as open on a linux system, but they knew of no services that were supposed to be attached to them:

# nmap xx.xx.xx.xx -sU -p 500-520
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-11-28 23:20 PST
Interesting ports on xx.xx.xx.xx:
(The 19 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
517/udp open|filtered talk
518/udp open|filtered ntalk

No services seemed willing to confess that they were using the ports flagged by the network scan:

# netstat -tunap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 5387/mysqld
tcp 0 0 :::80 :::* LISTEN 5633/httpd2-prefork
tcp 0 0 :::22 :::* LISTEN 5356/sshd
tcp 0 0 :::443 :::* LISTEN 5633/httpd2-prefork


Monitored all traffic to the port via tcpdump, and saw no unusual UDP packets. Tried to establish communication with the listener, but it instantly closed the connections. Did a quick rootkit check and looked for signs of hidden processes, trojaned binaries, etc. on the system but it came back clean. Considered doing a signature match on the binaries themselves, but then had a hunch that a network device might be at fault.

Swapped out an Actiontec GT701-WG with a Cisco 678 and sure enough, the ports closed:

# nmap xx.xx.xx.xx -sU -p 500-520
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-11-28 23:36 PST
All 21 scanned ports on xx.xx.xx.xx are: closed

Might be enough to finger-print the Actiontec’s of the world (scan Quest blocks for UDP 517/518). Also might be worth isolating the device to get a better idea of how broken/exposed it is, if it turns out enough people are still using these things.