is it possible to add a UDP port monitor? I’ve looked through the documentation and google, but the best I could come up with is a ~7y old github issue saying that “we” should have generic protocol support. Specifically:
we don’t have a plugin for this, but it is a nice request.
Ideally, we should have a plugin to accept jobs like this:
name:
url: 'http://ip:port/path' or 'https://ip:port/path' or 'tcp://ip:port' or 'udp://ip:port',
Hey @ilyam8 thanks for the reply, and my apologies for the delay in answering your questions (I took some time off for labor day and then last week just got away from me so I’m just now getting back to this ¯_(ツ)_/¯)
To elaborate more on what I’m looking for perhaps a little background as to my deployment strategy would help. I’m adding netdata to my instances and having the individual nodes monitor their own services via local checks, and generally they are bound to localhost/127.0.0.1.
Recently, I’ve been investigating overlay vpn networks, and following my deployment pattern I wanted to add a portcheck to monitor these services. I realize UDP is difficult to scan for remotely; however I’ve found it’s pretty reliable when doing so locally. For example, on a host with netbird the following nmap seems to be reliable:
┌─[parrot@parrot]─[~]
└──╼ $sudo nmap -sU -Pn -n -p3120-3130 127.0.0.1
[sudo] password for parrot:
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-16 17:01 PDT
Nmap scan report for 127.0.0.1
Host is up (0.000019s latency).
PORT STATE SERVICE
3120/udp closed d2000webserver
3121/udp closed unknown
3122/udp closed vtr-emulator
3123/udp closed edix
3124/udp closed beacon-port
3125/udp closed a13-an
3126/udp closed unknown
3127/udp closed ctx-bridge
3128/udp open|filtered ndl-aas
3129/udp closed netport-id
3130/udp closed squid-ipc
Nmap done: 1 IP address (1 host up) scanned in 1.38 seconds
where netbird is in fact listening on port 3128 and nothing on the other ports:
nmap sends 0-byte UDP packets to each port on the target system. Receipt of an
ICMPv4 Destination Unreachable/Port Unreachable (Type 3, Code 3) message signifies the port is closed; otherwise it is assumed open.
We can add exactly this logic. It will require CAP_NET_RAW (we need to listen for incoming ICMP packets that require this capability). As far as I remember, we add this capability during installation, so no additional manual configuration is required.
Receipt of an
ICMPv4 Destination Unreachable/Port Unreachable (Type 3, Code 3) message signifies the port is closed; otherwise it is assumed open.
This is the “open/filtered” state. I see that nmap has some logic to send specific UDP packets to known applications that applications can respond to. For instance, it sends NTPv4 Client messages when scanning port 123
13:11:35.057785 IP localhost.54926 > localhost.ntp: NTPv4, Client, length 48
13:11:35.057809 IP localhost.54926 > localhost.ntp: NTPv3, symmetric active, length 48
13:11:35.057912 IP localhost.ntp > localhost.54926: NTPv4, Server, length 48
State would be “open” on response. This is something we can’t implement right away. So compared to nmap we can show only “closed” or “open/filtered”.
