Gentoo Archives: gentoo-security

From: William Yang <wyang@××××.net>
To: gentoo-security@l.g.o
Subject: Re: [gentoo-security] SSH probes
Date: Sun, 06 Nov 2005 19:51:58
In Reply to: Re: [gentoo-security] SSH probes by Brian Micek
Brian Micek wrote:
> I don't think you understand what I'm proposing. I am currently > cat(1)ing /dev/urandom on TCP port 22 in hopes to discourage hackers who > attempt to break into my system. Its beyond me how this is treading on > dangerous ground, what systems I'll endanger or what is morally wrong > with doing this.
If it's beyond you, then perhaps you need to do further research into how things work before deploying your solution. Your stated goal was to cause a core dump through spewage. To restate that, you want *to crash software on a remote system.* Which is to say, you want to *cause damage to a remote system.* So, to explain this in a more tangible way, assume three hosts, A, B, and C. A is you. B is an attacker. C is an innocent bystander. It's possible, using several features of IP for B to connect the output of ports from A to ports on C. That is, B can create a connection from A to C using legitimate TCP behaviors, that neither C nor A would otherwise have initiated. Your "solution" of cat-ing /dev/urandom is, in effect, creating a binary character generator *which never stops generating characters* (though it will periodically delay in doing so, and it does exhaust your true entropy on your system, which is harmful if you have any reason for randomness (cryptography, password generation, complex simulations, game theory decision models, etc). For us oldtimers... those of us who've been around the block a few (hundred thousand) times... we remember the earliest DoS attacks, which created connections from the chargen to echo or discard ports on various machines, simply to consume bandwidth and processor. It sounds like a great avenue of attack against your "solution." Think a little broader. The reason I can level this criticism at all is because you're looking only at a tiny subset of the consequences of your technology. When one looks at a much broader range of possible outcomes and possible MIS-uses of the technology, when one looks at the boundaries of a problem statement and looks for how things will cross those boundaries, that's how you create actual security and assurance against adverse events. There's a reason why pretty much every major security organization comes down against "active response" (aka "strikeback" or "offensive response" or "retribution" or, my personal favorite, "vengence") strategies and approaches. These strategies almost invariably lead to unintended consequences which can damage uninvolved third parties, which are predictable, preventable, and undesirable. That's what makes these strategies a generally bad idea, and why security professionals argue against them. The line you don't want to cross has to do with sending responses to someone else. If you want to stop them from talking to you, fine. If you want to blacklist them from talking to your networks, fine. But when you reach your hand back toward them, you cross the line and become part of the problem, rather than part of the solution. -Bill -- William Yang wyang@××××.net -- gentoo-security@g.o mailing list