> On Mon, 1 Nov 2004 02:10:36 -0800 (PST) > "Steve Ellis" <ellis@xxxxxxxxxxxx> helped out: > > Joel said: > > > On Sun, 31 Oct 2004 23:19:39 +0000 > > > James Wilkinson <james@xxxxxxxxxxxxxxxxxxx> wrote > > >> In particular, you can't really spoof IP addresses on > SSH sessions. > > >> The server needs to be able to get packets back to the (possibly > > >> attacking) client, which means the client's IP address must be > > >> routable. > > > > > > Okay, educate me. Why is a spoofed IP address known to be not > > > routable? > > > > Because generally it isn't of value to use as a spoofed address an > > address on your own subnet (a trace will get back to the correct > > network admin anyway, who can start capturing packets and > figure out > > the true MAC address). Consequently, most spoofing attacks > will probably use: > > 1) An address on the victim's subnet > > Okay, that would not be routable, unless, or instance, the > attacker 0wns the router. > > > 2) A 10./8 or 192.168./16 address > > And that should not be routable in from outside unless our > gateway to the external net is built, well, cheaply, should we say? > > > 3) A broadcast or multicast address > > Which we assume SSH will reject even if some weird router let > it through? > > > 4) A 127./8 address > > Well, if he already 0wns the box, he 0wns it. > > > 5) some other victims address (for a DDoS-type attack). > > "... (for instance, for a DDoS-type attack)." > > > If the attacker is already on the same subnet as the > victim, then #3 > > might help, but someone could still trace the attack by MAC, so why > > bother. > > > > In my experience, most ssh attacks seem to be launched from systems > > that are already 0wn3d (if I'm using the correct terminology), so > > there is no point in trying to cover up where the attack is coming > > from. > > Which is kind of an important point. Especially if the 0wn3d > box happens to be on the local net. > > What am I missing? (I'm thinking of one more, but there are probably > others.) > The point is that the original discussion talked about black-holing traffic based on ssh authentication failures. You can't get to ssh authentication (successful or otherwise) unless you finish TCP connection set up--regardless of whether an address is routable or not, in order for TCP setup to complete the initiator MUST RECEIVE packets sent from the attacked system. Auto-black-holing traffic after receiving most DoS-type attacks is unsafe (and ineffective) because often the source IP addresses are forged and do not correspond to where the attacker is really coming from the hackers could force you to dropping traffic from nearly everyone, while auto-black-holing traffic based on communication AFTER TCP connection set up only effects the hackers (and anyone whose machine has been taken over--call it collateral damage). Re-reading the discussion, I guess that the distinction that spoofed IP addresses on SSH sessions required two-way communication wasn't clear--my apologies. -se
