Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-security
Navigation:
Lists: gentoo-security: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-security@g.o
From: William Yang <wyang@...>
Subject: Re: SSH probes
Date: Sun, 06 Nov 2005 14:45:06 -0500
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@...
-- 
gentoo-security@g.o mailing list


References:
SSH probes
-- Brian Micek
Re: SSH probes
-- William Yang
Re: SSH probes
-- Brian Micek
Navigation:
Lists: gentoo-security: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: SSH probes
Next by thread:
Weird Network and Portage Digest Issues
Previous by date:
Re: Snort alert with Squid ?
Next by date:
Re: Snort alert with Squid ?


Updated Jun 17, 2009

Summary: Archive of the gentoo-security mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.