Putting Privacy Focused "Free Speech" VPS Providers to the Test
1–10 of 12 posts
Re: Putting Privacy Focused "Free Speech" VPS Providers to the Test
#2These providers are the sources of the strangest and most harmless but interesting traffic I have ever seen. Just the other day I was watching a node at BuyVM send my public DNS server a SYN packet every 10 seconds to port 53. The sequence number and source port stays the same, but the TTL decrements from 64 down to 1 in 64 seconds/packets. Checksums fail. No idea what they are enumerating or what script this is. Both my DNS daemon and the kernel know not to respond to any of it. They stopped before I restarted with debugging enabled. I also get a lot of scans looking for DKIM keys and other poor configurations coming from the providers on this list. I would never block any of it, too much fun to watch.
Re: Putting Privacy Focused "Free Speech" VPS Providers to the Test
#3These providers are the sources of the strangest and most harmless but interesting traffic I have ever seen. Just the other day I was watching a node at BuyVM send my public DNS server a SYN packet every 10 seconds to port 53. The sequence number and source port stays the same, but the TTL decrements from 64 down to 1 in 64 seconds/packets. Checksums fail. No idea what they are enumerating or what script this is. Bot…
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?
Re: Putting Privacy Focused "Free Speech" VPS Providers to the Test
#4These providers are the sources of the strangest and most harmless but interesting traffic I have ever seen. Just the other day I was watching a node at BuyVM send my public DNS server a SYN packet every 10 seconds to port 53. The sequence number and source port stays the same, but the TTL decrements from 64 down to 1 in 64 seconds/packets. Checksums fail. No idea what they are enumerating or what script this is. Bot…
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?
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).
Re: Putting Privacy Focused "Free Speech" VPS Providers to the Test
#5This honestly just sounds like an ad for "Kyun"?
You have a list of established providers and then some random new provider (who also happens to tick every box for your questionable content)
Re: Putting Privacy Focused "Free Speech" VPS Providers to the Test
#6These providers are the sources of the strangest and most harmless but interesting traffic I have ever seen. Just the other day I was watching a node at BuyVM send my public DNS server a SYN packet every 10 seconds to port 53. The sequence number and source port stays the same, but the TTL decrements from 64 down to 1 in 64 seconds/packets. Checksums fail. No idea what they are enumerating or what script this is. Bot…
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?
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
Re: Putting Privacy Focused "Free Speech" VPS Providers to the Test
#7This honestly just sounds like an ad for "Kyun"? You have a list of established providers and then some random new provider (who also happens to tick every box for your questionable content)
They didn't go with Kyun, they went with Pivex, and they gave 2 other providers the same A+ rating.
It seems pretty evenhanded and not like an ad to me.
Re: Putting Privacy Focused "Free Speech" VPS Providers to the Test
#8Earlier quoted context omitted.
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?
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).
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.
Re: Putting Privacy Focused "Free Speech" VPS Providers to the Test
#9These providers are the sources of the strangest and most harmless but interesting traffic I have ever seen. Just the other day I was watching a node at BuyVM send my public DNS server a SYN packet every 10 seconds to port 53. The sequence number and source port stays the same, but the TTL decrements from 64 down to 1 in 64 seconds/packets. Checksums fail. No idea what they are enumerating or what script this is. Bot…
Zone transfer shenanigans? Only thing I know that DNS uses TCP for.
Re: Putting Privacy Focused "Free Speech" VPS Providers to the Test
#10These providers are the sources of the strangest and most harmless but interesting traffic I have ever seen. Just the other day I was watching a node at BuyVM send my public DNS server a SYN packet every 10 seconds to port 53. The sequence number and source port stays the same, but the TTL decrements from 64 down to 1 in 64 seconds/packets. Checksums fail. No idea what they are enumerating or what script this is. Bot…
Zone transfer shenanigans? Only thing I know that DNS uses TCP for.
No, I get those all day long. Both zone transfer requests and attempts to do dynamic DNS updates which my DNS does not support dynamic DNS. My daemon will respond to those with rejected and NotImpl. Neither my DNS daemon nor the OS even responded to these probes and it was not even my doing. No SynAck from me so the kernel knew these were malformed or something I've enabled logging of invalid packets. Maybe they will try again.
For completeness sake TCP is used for a few other things on DNS these days such as falling back to TCP when the client does not support EDNS and the packet is bigger than 512 bytes which is common with DNSSEC. I do not have any large records. TCP is also used when encryption is implemented (DNS Over TLS) but that is usually on port 853 though it can be supported on 53 encryption can be opportunistic.