Dataplane.org 2023 Q3 Newsletter
Updates, new Signal and SMTP Insights
NETINT 2023-Q3 Update
Welcome to the latest edition of the Dataplane.org quarterly newsletter. Inside, we provide updates in the ever-evolving network intelligence (NETINT) world. As the Internet landscape transforms rapidly, we work to highlight trends and offer insights to keep you up to speed.
You will find more information on our newest Signal, insights into SMTP traffic, and learn more about happenings at Dataplane.org. Thank you for joining us for an exploration that we hope you find useful in NETINT.
Introducing dnstypename
We’ve added a new Signal derived from unsolicited DNS queries our sensors see in-the-wild. We call this signal dnstypename and it is updated daily. It presents a global view of unique, but common Internet (IN) class queries, grouped by query type seen by multiple, globally diverse sensors.
Our DNS sensor network sees thousands of unique queries from scans and surveyors on the Internet every month. When we filter out low visibility queries (type/name pairs seen by only one or a small handful of sensors), the number of common queries seen by most sensors is quite small.
Some recent entries in the dnstypename Signal:
dnstypename | A | ip.parrotdns.com dnstypename | ANY | sl dnstypename | TXT | version.bind
To understand this phenomenon, an example may help. Internet DNS surveyors often issue one-time unique queries. They often embed the target IP address, a random code, a timestamp, a counter, or other information as part of the query name. In the simplest case, imagine a query of the form “192-0-2-1.surveyor.example.net” sent to the host at IP address 192.0.2.1. In this example, the surveyor embeds the target IP address in the hostname portion of the full query name, ensuring that each IP address gets a unique query. We’d consider the specific, fully qualified type/name pair to have low visibility, because the query is only seen by the target IP address.
The list of common name/type pairs seen in-the-wild at multiple, diverse sensors makes it easier to spot certain kinds of activity, such as the queries often used for DNS amplification / reflection. This report may also help expose other types of interesting activity, such as mass cache snooping activity.
We hope this report helps provide useful hints about current Internet DNS activity and fosters new ideas with our DNS sensor network that might be used to derive additional insights. If you’d like to explore more ways this sort of data might be useful to your organization or for your research, please reach out through our contact details at the bottom of this newsletter.
SMTP Insights
This quarter, we will look at data from our various signals that cover SMTP (Simple Mail Transfer Protocol) and some of the findings across our network of sensors. SMTP itself was defined in RFC 821, with extensions added in RFC 1869. While looking into this in aggregate, we can slice it per hosting provider, across various network blocks, or even per host. We have not advertised nor configured any of our sensors in the DNS as a mail server via a Mail Exchange (MX) resource record. All SMTP traffic we see is unsolicited.
SMTP Signals
We have two different SMTP Signals published from our sensors that are updated hourly:
SMTP data - IP addresses sending unsolicited DATA commands.
SMTP greeting - IP addresses sending unsolicited HELO/EHLO commands.
Both identify IP addresses seen across multiple sensors that send unsolicited SMTP commands. While the arguments are not published, we are working on making data sets available to researchers.
HELO/EHLO (extended helo) Arguments
The HELO command identifies the originating SMTP server/client sending to the receiving SMTP server (RFC 821). The EHLO command indicates the server/client intends to use the Extended SMTP protocol, or ESMTP (RFC 1869). The top identifier string, as seen below, is by far “User”. This is likely due to an attempted exploit on Exim, which powers over 50% of mail exchange servers. While this exploit has had a patch available for years, there is a persistent amount of exploit attempts looking for vulnerable systems.
The ylmf-pc entry is a well-known brute force attack published in August of 2016 (Analysis of Brute Force Attacks with Ylmf-pc Signature by Anton Arzhakov and Dmitry Silnov). The majority of the next several are hosts that utilized their IP address when issuing the HELO/EHLO command. Other notable mentions that are within the top 100: www.censys.io (a company that provides a variety of commercial services on data they collect through scanning) and masscan (a GPLv3 TCP port scanner).
Top 10 mail FROM:
<>
<admin@51lingyun.com>
<infoeubank8@gmail.com>
<test@ipxon.net>
<szaid70000@gmail.com>
<jenniferahsan840@gmail.com>
<infolee@usa.org>
<projectconsults1956@gmail.com>
<gil@gibori.net>
<JohnsonA.Kingprojectconsults1956@gmail.com>
The empty brackets at the top of the list are for delivery status notifications, which RFC 1123, section 5.2.9 mandates its support by SMTP servers. The majority of the rest of the entries are probable Spam and, in some cases, 419 scam attempts. While these represent unsolicited attempts, we should not assume all are malicious. Some could be misconfigured systems. If you would like to see more data, please reach out through our contact details at the bottom of this newsletter.
Organizational Updates
The past quarter has been busy as we have been adjusting our footprint, deprecating problematic hosts, migrating our backend services, increasing the scaling of our sensors with over 100 more globally, and adding capabilities to the network. Some new functionalities, which will bring new Signals, and increase our NETINT capabilities, are being deployed:
Leveraging nginx we are developing Signals based off of HTTP(s) headers.
Evaluating the pmacct project by Paolo Lucente, to capture netflow data across our network. Current considerations are to use a couple of modules:
pmacctdto collect and export IPFIX through thenfprobetool. As well as nfacctd along with Kafka
Last year, we decided to cease operations in Russia, along with many organizations, based on the invasion of Ukraine. The board approved winding down any systems we had deployed inside Russian ISPs and hosting providers who would have control of the VMs we manage. We are now replenishing our Russian footprint. The ability to measure and monitor Internet infrastructure from, to, and within Russia is an important part of providing global NETINT.
Other upcoming projects include:
RPKI monitoring infrastructure enhancements to bring our CA/PP back to life.
Deploying our unused address space as an anycast sinkhole for traffic analysis.
Deploying distributed BGP route collectors.
Publishing historic sensor activity data for researchers.
For contributions to our mission of providing NETINT to the public and our Signals continuous availability, please consider contributing a donation.
Be sure to follow “The Internet Last Week” by Dataplane.org on Mastodon for interesting happenings in our weekly post.
We welcome feedback on any items covered in our update or suggestions for improvement.
Feel free to reach out via email, Mastodon, or Slack (request an invite if you need one).