this_is_making_fse_unreliable.png

Notices where this attachment appears

1. pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Wednesday, 27-Sep-2023 14:42:27 JST pistolero :thispersondoesnotexist:
   :hacker_f::hacker_s::hacker_e:
   
   In other news, if FSE is slow, that's because, for the first time in a while, we're being DDoS'd! Since I started typing this, we've gotten a few million DNS packets, about 14,000 per second. Almost all queries for mgi.gov. Given that mgi.gov is the .gov's "Materials Genome Initiative", FSE might not actually be the target, they might just be trying to do a reflection attack. FSE was running dnsmasq as an open recursor, which I figured I'd just do as long as it remained harmless. (If you were using FSE for a DNS server, sorry, I've shut it down.)
   
   One thing that's interesting is that the outgoing port on the sources is odd: the outgoing port is 80! (Usually, on most OSs, the program specifies "0" for the outgoing port when creating a socket, and the OS allocates an "ephemeral port", a port number between 32768 and 65535. Ports you listen() on are allocated below that range: have a look at /etc/services. This is why most port scans stick to the range 1-32767.) This could conceivably be to make it difficult to notice, but I don't think that's what's happening. Follow along for a minute (and skip the parentheticals if you know the stuff inside them already), I'll explain.
   
   These IP addresses are might be spoofed: with a TCP connection, there's the three-way handshake (SYN, ACKSYN, ACK), and then to make an HTTPS request, there's also the TLS negotiation: it's very difficult to spoof that many packets. (If the server gets an RST for its ACKSYN, then it treats it like a dropped connection. You used to be able to get around that, too, but then they started randomizing TCP sequence numbers, too, and you could get around that for a while because they were using bad RNGs, especially Windows. Look up the three-way handshake and TCP sequence numbers and TLS negotiation and then keep following links, I don't want to distract by going on about this much longer.) It is implausible that a full HTTPS request happens with a spoofed IP under normal circumstances, but DNS is UDP, it's fire and forget.
   
   That's why it might actually just be a reflection attack: if you've got a friendly enough route, you can send off a packet that says "I'm a DNS query from $some-other-host, port 80", and the DNS server will send a response to $some-other-host:80 (almost exactly like writing the wrong return address on a piece of mail to get it bounced to somewhere else). So if you wanted to hose someone's website and you had a list of open recursors and you knew how to fire off UDP packets with forged return addresses, then you could put the IP and port number of the service you wanted to hose in the source address of a DNS query, then send it along to the recursor, which will send its response back to whatever address is listed in the source.
   
   Anyway, no more open recursor on FSE (not that anyone besides botnets noticed, probably), and if it's a reflection attack rather than an attempt at DDoSing FSE, they'll probably give up. It's also possible they're trying to DDoS FSE and forging the packets' source address for splash damage, but that seems unlikely.
   
   cc @threat , @ins0mniak, you guys might get a kick out of this. Reflection attacks, forged UDP packets. Just like the old days!
   this_is_making_fse_unreliable.png
   dns_ddos--port80.png