Great story (with a bit of "oh to be young again" nostalgic flavor at least to me). Thanks.
For a person who has been computing for many years, but who is epically uninterested in security, it would have been great with a short and clear description of the attack. I think I understand everything mentioned yet fail to see the danger.
I'm not super well versed in this sort of thing, but I did read Wikipedia, and I think I understand.
The short version is that it lets an attacker on machine A determine whether machine B has a port open, without needing to actually receive a response from B. This is done by creating a SYN packet destined for machine B, but with a false source of some innocent victim machine C. If the port is open, machine B will "respond" to machine C with a SYN/ACK.
Machine C thinks machine B is trying to talk to someone else, and so responds with a RST packet. This increments machine C's packet counter, which can be queried as described in the article.
This allows the attacker on machine A to enumerate the services offered by machine B ("port scan"), without leaving any record on B that is traceable to machine A. There are some targets (e.g. law enforcement) that can take umbrage at being port scanned, and try to do something about it.
It doesn't super work today, because modern operating systems use unpredictable packet IDs. This makes the query from A to C ineffective.
To be clear, it doesn't work today because OS's reacted to neutralize the possibility.
At this point there is so much "Internet Background Radiation" of constant port scanning and everyone has just accepted that you are being constantly scanned by, say, Shodan and it's ilk that this threat doesn't seem super-alarming. Back in the 1990's- when SSL wasn't everywhere, and telnet was still a thing- someone who could silently find your attempt at security-through-obscurity 'I moved telnet to port 2525" nonsense that was still done pretty regularly in 1998- was a big deal.
The problem with idle scan isn't much scanning itself, but understanding trust relationships between hosts. This allowed to target the attacks much better. But I get what you mean in general.
I haven't looked for a few years but last time I checked there were still a bunch of crappy ip stacks out there (eg particular cable modem brands) with sequential ip ids.
Great description. And most importantly, it was possible to choose C IP address to test if other machines on the network had special privileges and ports open. This allowed to penetrate C to gain access to B.
All that means is that you need to find an idle machine C with predictable packet IDs to make it work. This is growing harder over time, but by no means is impossible.
"An attacker would first scan for a host with a sequential and predictable sequence number (IPID). The latest versions of Linux, Solaris, OpenBSD, and Windows Vista are not suitable as zombie, since the IPID has been implemented with patches[7] that randomized the IPID.[1]"
Is this Wikipedia entry up-to-date. On NetBSD, there is a sysctl to randomise IPID.
https://seclists.org/bugtraq/1998/Dec/79
Antirez should be humble to his younger self, even with Redis under his belt now.