On Mon, 1 Nov 2004 11:16:27 -0800 "Steve Ellis" <ellis@xxxxxxxxxxxx> wrote > > 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. Actually, the original discussion, if we go back that far, was about reactive techniques for firewalling in general. > 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. True, and it doesn't do much good for a cracker to get a buffer overflow on http if he can't get the shell prompt back to the attacking box. > 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). That's a point. Sometimes patience is a good thing. Thus the honeypot that someone mentioned, and using the honeypot to harvest evil IPs that actually pick up a two-way conversation, as was also mentioned. > 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. I think the point was made, perhaps before someone tagged the "OT" on the front of the topic. But it's a point worth making again. Speaking in an entirely theoretical vein, if I were to consider blackholing for, say, Amazon, I would want a whole security system with several servers doing honeynet and several other servers doing nothing but tracking troublesome IP addresses, timing them out, and lengthening the time out for repeat offender IP addresses. Initial timeouts would probably start at two minutes or so. And I might do the design and decide that I couldn't guarantee it would be fast enough to protect against a DoS. Or maybe the engineer babysitting the system would push the cost beyond the benefits. In a not-so-theoretical vein, I want to set up some reactive techniques for my personal server. Attacks outweigh real accesses by two orders of magnitude right now, and it wouldn't really hurt anything if the thing were DoSsed while I was at work. Permanent black holes are not a good idea, of course, and that was discussed. I don't think I'd use the two day timeouts that someone mentioned for his setup, I'd think more in terms of thirty minutes. Possibly lengthen that a little if I got repeats. But your point, that we need to be _very_ careful about reactive techniques, is well worth repeating. -- Joel <rees@xxxxxxxxxxx>
