Implement UDP

[joker234]

According to CONFIGURATION.md, there is currently no possibility to check UDP Ports. Sure, this Problem is a little bit harder to manage than TCP, because you have no defined followable stream. My use case is to check if Kerberos is running resp. available on UDP Port 88.

I would be happy if someone could implement this.

[brian-brazil]

I think we could do a simple single query/response.

[tim-oak]

would be really great to be able to test the availability of udp ports! Next to kerberos I would need it for dhcpd and ntpd, dns and samba... Unfortunately I'm not into "go" or I would have a look on howto implement this. regards

[candlerb]

I think a proper Kerberos check involves making a proper Kerberos call. Therefore you will probably be better off with a separate script which requests and validates a Kerberos ticket. You can integrate this using one of the following:

• nrpe_exporter
• exporter_exporter
• Run the script from cron, and write the results into a file for node_exporter's textfile-collector to pick up

This script is a quick hack to check Active Directory - both Kerberos and LDAP (the LDAP query is authenticated using the Kerberos ticket). I currently use it with Nagios, but nrpe_exporter should be fine with it. It could probably be better written to avoid temporary files.

As regards the other things you describe: again, to check dhcpd you should send a correctly-formatted dhcp request and validate the response. DNS queries are already supported by blackbox_exporter.

[jirib]

A openvpn prober would be great, see https://github.com/liquidat/nagios-icinga-openvpn/blob/master/bin/check_openvpn

[avanichy25]

@brian-brazil i am trying to configure the UDP probe any update on the ticket when this feature will be available by blackboxexporter?

[candlerb]

@avanichy25, what is your use case?

Almost no UDP protocols are text-based. Therefore, generating a text UDP packet and doing a regex check on the response (like you can with say SMTP) wouldn't be useful. Sending a canned binary UDP packet isn't very useful either, e.g. for any protocol which encodes the current time.

So I can't see a useful way to provide a "generic UDP check". You need a specific check for the protocol you're interested in - e.g. RADIUS, DHCP, OpenVPN etc - just like the built-in DNS check.

[hslabbert]

Is there any appetite for a generic UDP echo check? I've got a case of a distributed set of boxes that all implement a very basic UDP echo service, so literally just text echo to a UDP port that the server end will echo back to the prober/client.

I'm setting up blackbox_prober for a chunk of basic ICMP, TCP, and HTTP/s monitoring, and it would be preferable to be able to leverage it for these UDP echo checks as well. Is the main argument here as in #242 that it's not a common use case, with binary protocols more prevalent in UDP and so it being less likely of being able to generic ping/pong type checks with regex?

I mean, ultimately it would probably be feasible for me to shift this check into another pod that supports UDP echo/response; I would just need to plumb the logging from it to be able to export metrics to Prometheus properly. It's either taking a generic udp echo implementation and plumbing the Prometheus bits on it, or trying to drop a generic UDP echo implementation into blackbox_exporter, for my use case.

Basically: if someone did cleanup of what was put together in #242 and ensures test coverage in there, what would it take to get it merged to cover this use case, or is it a non-starter that folks would prefer to not include into blackbox_exporter?

[candlerb]

I think it's a bad idea. If this feature is added, people will expect blackbox_exporter to be able to test their (RADIUS / DHCP / Kerberos / STUN / TFTP / NTP / NFS / SNMP / OpenVPN / Wireguard / etc) server, when it can't[^1]. The only useful text-over-UDP protocol I can think of that it might be able to test is SIP.

In general, I think it's better for UDP testing to be in separate exporters, with code specific to each use case. This proposed "plain ASCII UDP tester" should also be a separate exporter, so as not to mislead people that it can be used to test any normal UDP application.

I admit that view is inconsistent with the DNS checker being in blackbox_exporter. However I think it should stay; DNS is a very common testing requirement, and it does use both TCP and UDP.

As I mentioned before, exporter_exporter has the ability to exec external programs on demand, and for some use cases this may be simpler than writing an actual exporter.

---

[^1]: remember that the OP said: "My use case is to check if Kerberos is running resp. available on UDP Port 88", followed by someone else saying "Next to kerberos I would need it for dhcpd and ntpd, dns and samba". None of these could be tested by a text UDP probe.

[candlerb]

To address this point specifically:

Is there any appetite for a generic UDP echo check?

I think running a UDP echo server in a production network is an atypical use case. Also, unless it's being used on an entirely isolated network, it's liable to be discovered and used for DoS attacks.

(Attacker sends traffic with spoofed source address X.X.X.X; in turn your server floods victim X.X.X.X with traffic)

[hslabbert]

I think it's a bad idea. If this feature is added, people will expect blackbox_exporter to be able to test their (RADIUS / DHCP / Kerberos / STUN / TFTP / NTP / NFS / SNMP / OpenVPN / Wireguard / etc) server, when it can't

Fair point. I can see how it would lead to confusion or problematic assumptions.

I admit that view is inconsistent with the DNS checker being in blackbox_exporter. However I think it should stay; DNS is a very common testing requirement, and it does use both TCP and UDP.

Yip, fair enough for DNS as a special case.

As I mentioned before, exporter_exporter has the ability to exec external programs on demand, and for some use cases this may be simpler than writing an actual exporter.

I'll give that a bash, yea. Should be workable to sort out.

Also, unless it's being used on an entirely isolated network, it's liable to be discovered and used for DoS attacks.

Yip, reflection would definitely be an issue if public.

[crockk]

I think it's a bad idea. If this feature is added, people will expect blackbox_exporter to be able to test their (RADIUS / DHCP / Kerberos / STUN / TFTP / NTP / NFS / SNMP / OpenVPN / Wireguard / etc) server, when it can't[^1]. The only useful text-over-UDP protocol I can think of that it might be able to test is SIP.

Unfortunately some of us are needing to do UDP checks using the SIP port. :(

[roidelapluie]

In general we'd like to have support for specific UDP probes. SIP seems a good candidate to try out.

[crockk]

I don't have the go programming experience unfortunately to write a SIP specific UDP probe, but I would certainly like to use it if there was any motivation for someone to create it.

[Stef-33560]

May Wireshark wireguard also be a good candidate ? without udp probing, how can we check it's alive ?

[candlerb]

Wireshark doesn't respond to any packets, so there's no way to check it's alive by probing it externally.

[Stef-33560]

Wireshark doesn't respond to any packets, so there's no way to check it's alive by probing it externally.

I only thought to be able to port scan wireshark wireguard's open port like a nmap -sU -p 51820 would do.

[candlerb]

Are you talking about wireguard, not wireshark? In any case, what response would you expect wireguard to send?

I would expect no response in the case of wireguard up and listening. You may get "ICMP port unreachable" if it is not listening. But if you don't get it, it doesn't guarantee that wireguard is working.

[Stef-33560]

:astonished: Wireguard of course .. damned I didn't see it twice :sleeping: sorry.

Yes, indeed, we cant' guarantee it's working since it's using UDP. Only that there's no modification on the firewall or (maybe) that the port is closed ?

[candlerb]

IMO, the best way to test a wireguard server would be to create a wireguard tunnel from the prometheus/blackbox server to the wireguard server, and to send test probes down it (e.g. standard blackbox_exporter icmp probes). It's a proper functional test, which you can already do.

I think that the nmap scan states aren't all that useful for UDP. Essentially you get either:

• open|filtered: no response received
• closed: target server responded with ICMP port-unreachable
• filtered: target server or intervening network responded with ICMP admin-prohibited

open|filtered (no response received) does not provide positive confirmation that the service is actually active or working; it only means that the service may or may not be there.