The DataPlane.org telnetlogin feed is now publicly available. It looks much like other feeds with the usual set of entry attributes: an IPv4 or IPv6 address, associated route origin information (ASN and AS name), the most recent time stamp of the event in the past 7 days, and the feed name.
This feed is derived from TELNET sensors that mimic, but do not implement an actual TELNET server service. The telnetlogin feed reports on clients sending login and password credentials after a TCP port 23 connection to a sensor in the wild. This activity is often associated with malware attempting to spread via a weakly protected public TELNET interface on embedded systems in consumer electronic devices.
Due to the nature of the TELNET protocol it can be very difficult to distinguish between potentially malicious clients and benign ones. Network scanner tools or surveying projects may interact with DataPlane.org’s decoy TELNET login process and show up in the feed. Like all DataPlane.org data feeds, this feed should not be used as a block list. This feed like others is intended to be used for insight and evidence of some activity. A feed in isolation can rarely be relied upon to characterize intent.
If DataPlane.org’s public feeds are imperfect arbiters of activity, network mapping tools and surveying projects are also imprecise in their cataloging efforts. Like the harmless surveyors that may end up on the telnetlogin feed, so too might a DataPlane.org sensor be listed as a TELNET server, when it really is not. Some refer to this as a “blue on blue” problem, indicating a team is attacking it’s own side. Further complicating matters, surveyors and monitors tend not to want to disclose their sources and methods to anyone, including each other. This can cause unwanted work when false positives end up in reports or lists, but ideally this should be a rare, minor annoyance.
Almost immediately after initial deployment of the DataPlane.org TELNET sensor we started showing up in a TELNET server listing by one of the well known network surveyors. At least one incident response organization uses that listing to report when you are running “an outdated network protocol.” In this case a national CERT proactively uses the list to contact the sysadmins for TELNET servers operating within it’s geographic boundary. This seems like it a reasonable practice, especially since DataPlane.org is a non-citizen guest operating in their country. Upon receiving these reports a brief email exchange between DataPlane.org and this CERT was all it took to acknowledge each other and work out an easy solution to avoid interference.
One advantage of successfully working in the network and incident response security community for many years is that you build up some street cred and make a few friends. This helps tremendously when interacting with others who are essentially on the same team, but are coming at a problem from a different direction and operating independently.
Hopefully this post gives you some insight into what it takes to operate the feed and what may end up in it. Feel free to reach out with any reactions to what you’ve read here.