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
[EMAIL PROTECTED]
--
[email protected] mailing list
