Why aren’t telnet bots finishing the three-way handshake?
This article discusses the phenomenon of telnet bots failing to complete the three-way handshake when attempting to connect to a honeypot. It explores the specific scenario of a port forwarding rule sending traffic to a honeypot, where many bots from around the world attempt to connect but encounter a failed handshake.
The article explains that the reason for this failure is that the bots are not actually trying to establish a connection but rather performing port scans. The scanning technique used, known as a SYN scan, allows the bots to determine if a port is open without completing the entire TCP handshake.
The article quotes the nmap guide, which describes the SYN scan as the default and most popular scan option due to its speed and stealthiness. The technique involves sending a SYN packet as if opening a real connection and then waiting for a response. A SYN/ACK response indicates an open port, while a RST response indicates a non-listener. If no response is received after several retransmissions, the port is marked as filtered.
The article suggests trying to reproduce this behavior by attempting a SYN scan using the nmap command and observing the Wireshark results. It also addresses the question of whether the bots can identify that it’s not a real telnet service before finishing the connection, explaining that the disadvantage of the SYN scan technique is that it doesn’t allow for service fingerprinting. The bots only know that the server has accepted a connection at that port.