OT: Security....

[Steve Ellis]

> On Mon, 1 Nov 2004 02:10:36 -0800 (PST)
> "Steve Ellis" <ellis at brouhaha.com> helped out:
> > Joel said:
> > > On Sun, 31 Oct 2004 23:19:39 +0000
> > > James Wilkinson <james at westexe.demon.co.uk> 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