3 ms·

Weird! The decrementing TTLs almost sounds like the sender is trying to perform some strange variation on a traceroute. With the long interval, maybe they are s

Weird! The decrementing TTLs almost sounds like the sender is trying to perform some strange variation on a traceroute. With the long interval, maybe they are sending such packets to many destinations, and trying to build an evolving picture of Internet routing infrastructure?

saurik 3y ago
nmap's --traceroute uses this technique (but I don't know if it has a way to cause this long gap; this is just a demonstration that this is an oft-used technique).
- LinuxBender 3y ago
  I just tried that with nmap using --traceroute -p 53 and it used new sequence numbers for each connection, different source ports. It did decrement but never went to 1 and I received responses along the way. NMAP did not set SackOK but it used my home MSS. Maybe someone wrote their own implementation trying to copy NMAP but missed something. Perhaps those servers are good for people trying to learn to write scanners.
LinuxBender 3y ago
It's a weird one for sure. It's a new TCP SYN packet in between each interval. I would say it's a whole new connection but every sequence number and source port is the same which is common with poorly / lazily coded scanning scripts yet they set an MSS of 1400 but then lacks SackOK. EDIT: Turns out NMAP also lacks SackOK eth0 In IP (tos 0x0, ttl 3, id 0, offset 0, flags [none], proto TCP (6), length 44) 209.141.62.239.37300 > [redacted].53: Flags [S], cksum 0x003c (incorrect -> 0xe3dd), seq 3632312462, win 65535, options [mss 1400], length 0 eth0 In IP (tos 0x0, ttl 2, id 0, offset 0, flags [none], proto TCP (6), length 44) 209.141.62.239.37300 > [redacted].53: Flags [S], cksum 0x003c (incorrect -> 0xe3dd), seq 3632312462, win 65535, options [mss 1400], length 0 eth0 In IP (tos 0x0, ttl 1, id 0, offset 0, flags [none], proto TCP (6), length 44) 209.141.62.239.37300 > [redacted].53: Flags [S], cksum 0x003c (incorrect -> 0xe3dd), seq 3632312462, win 65535, options [mss 1400], length 0 I've enabled logging of invalid packets. Hopefully they will try again.

saurik 3y ago

nmap's --traceroute uses this technique (but I don't know if it has a way to cause this long gap; this is just a demonstration that this is an oft-used technique).

LinuxBender 3y ago
I just tried that with nmap using --traceroute -p 53 and it used new sequence numbers for each connection, different source ports. It did decrement but never went to 1 and I received responses along the way. NMAP did not set SackOK but it used my home MSS. Maybe someone wrote their own implementation trying to copy NMAP but missed something. Perhaps those servers are good for people trying to learn to write scanners.

LinuxBender 3y ago

It's a weird one for sure. It's a new TCP SYN packet in between each interval. I would say it's a whole new connection but every sequence number and source port is the same which is common with poorly / lazily coded scanning scripts yet they set an MSS of 1400 but then lacks SackOK. EDIT: Turns out NMAP also lacks SackOK eth0 In IP (tos 0x0, ttl 3, id 0, offset 0, flags [none], proto TCP (6), length 44) 209.141.62.239.37300 > [redacted].53: Flags [S], cksum 0x003c (incorrect -> 0xe3dd), seq 3632312462, win 65535, options [mss 1400], length 0 eth0 In IP (tos 0x0, ttl 2, id 0, offset 0, flags [none], proto TCP (6), length 44) 209.141.62.239.37300 > [redacted].53: Flags [S], cksum 0x003c (incorrect -> 0xe3dd), seq 3632312462, win 65535, options [mss 1400], length 0 eth0 In IP (tos 0x0, ttl 1, id 0, offset 0, flags [none], proto TCP (6), length 44) 209.141.62.239.37300 > [redacted].53: Flags [S], cksum 0x003c (incorrect -> 0xe3dd), seq 3632312462, win 65535, options [mss 1400], length 0 I've enabled logging of invalid packets. Hopefully they will try again.