While going through newly published RFCs last week, I noticed one which may turn out to be quite useful for security practitioners, even though it is just an “informational” document. It is the RFC 9511 – Attribution of Internet Probes[1].

There are many organizations and individuals around the globe, who perform port scans of internet-connected systems belonging to third parties. Some of these are malicious actors, however, there is a significant number or well-meaning people and companies who do so as well (e.g., for the purposes of research or troubleshooting), and unsolicited packets may therefore be considered a “background noise” of the internet.

Nevertheless, there are times when one might wish to attribute a specific “scan” (i.e., unsolicited packet or set of packets) to its originator, or at least discover whether the traffic originated from a potential threat actor or a researcher/research organization - for example, if one saw that a new public IP address started to periodically scan all ports of one’s infrastructure in the last week.

So far, security analysts and administrators have had to rely mostly on WHOIS[2], RDAP[3], reverse DNS lookups and third-party data (e.g., data from ISC/DShield[4]) in order to gain some idea of who might be behind a specific scan and whether it was malicious or not. However, authors of the aforementioned RFC came up with several ideas of how originators of “internet probes” might simplify their own identification.

In the document, they define a "Probe Description File", which an originator of a scan may place in the path “/.well-known/probing.txt” on a web server, which is accessible on the same IP address, which originated the scan (and/or on a domain, to which a reverse DNS lookup of the IP address points). Format of the file is based on the security.txt file, as defined by RFC 9116[5], and should contain fields Canonical, Contact, Expires, Preferred-Languages and Description, as the following example taken from the RFC shows.

# Canonical URI (if any)
Canonical: https://example.net/measurement.txt

# Contact address
Contact: mailto:lab@example.net

# Validity
Expires: 2023-12-31T18:37:07z

# Languages
Preferred-Languages: en, es, fr

# Probes description
Description: This is a one-line string description of the probes.

It should be noted that IANA has already added the “/.well-known/probing.txt” URI suffix to its “Well-Known URIs” registry[6].

The RFC also mentions the option of providing identifying information “in-band”, i.e., by including a “Probe Description URI” (URI pointing to a Probe Description File, an email address or a phone number) in a probe itself, in the data field or payload of a packet. In such cases, the URI must start at the first octet of the payload and must be null terminated (and if the URI can’t be placed at the beginning of the payload, then it must be preceded by an octet of 0x00). This means that if one wanted to include a Probe Description URI in packets sent by Nmap, for example, one could do so quite easily using the --data option[7].

To sum up, implementing the recommendations of this RFC might not be a bad idea for those who actively probe third-party systems as part of their research activities, and for security analysts and administrators, it is certainly good to know that this RFC exists, as it might potentially help them distinguish between a “benign” scan and a malicious one.

And while it should be stressed that threat actors might set up Probe Description Files on their servers as easily as anyone else, and blindly trusting information contained in such files is therefore unadvisable, RFC 9511 is still a useful document. As its authors themselves put it, the solution which they came up with “is not perfect, but it provides a way for probe attribution, which is better than no solution at all”[1].

[1] https://www.rfc-editor.org/rfc/rfc9511.html
[2] https://datatracker.ietf.org/doc/html/rfc3912
[3] https://about.rdap.org/
[4] https://isc.sans.edu/data/
[5] https://www.rfc-editor.org/rfc/rfc9116
[6] https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
[7] https://nmap.org/book/man-briefoptions.html

-----------
Jan Kopriva
@jk0pr
Nettles Consulting