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.) -- Joel <rees@xxxxxxxxxxx>
