SSH hank attempts bad?
chris.carey at gmail.com
Wed Apr 12 10:46:11 MDT 2006
On 4/12/06, Chris Carey <chris.carey at gmail.com> wrote:
> On 4/12/06, Michael Halcrow <mike at halcrow.us> wrote:
> > On Wed, Apr 12, 2006 at 08:22:16AM -0600, Chris Carey wrote:
> > > Though, you could spend your whole life fighting this losing battle.
> > > My opinion is to set your security in place, and forget about it.
> > Some of the tactics suggested in this thread *are* setting security in
> > place. And you should *never* just forget about it, because more
> > likely than not, your adversaries are cleverer than you are. Good
> > attacks are rarely conventional; if history has taught us anything,
> > attackers will always ``cheat.'' Security is a hard problem -- in
> > fact, it reduces to the same problem as the correctness problem, which
> > any CS student knows is intractable.
> > When it comes to system security, what we have to rely on is basic
> > economics. If someone wants to ``get to'' your system, and if they
> > have the willpower and enough resources to do it, you're screwed.
> > So what you need to do is make it *more costly* for an attacker to get
> > to your resources than whatever benefits the attacker would obtain by
> > compromising your resources. For most run-of-the-mill systems on the
> > Internet, the ``low-hanging'' fruit principle applies, just as it
> > applies to the security tactics of home burglar alarm signs, walking
> > down the sidewalk with confidence, and so forth. Criminals also
> > understand the concept of opportunity cost.
> > The moral of the story is to employ as many (layered) security
> > mechanisms as you can while minimizing the inconvenience to the
> > legitimate users. There are no one-shot silver bullets (although SE
> > Linux comes close), and so you should be using a wide variety of
> > tactics -- the more unique the approach, the less likely they will be
> > compromised via a ``class break.''
> > Mike
> > .___________________________________________________________________.
> > Michael A. Halcrow
> > Security Software Engineer, IBM Linux Technology Center
> > GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C 20F5 DB40 8531 6DCA 8769
> > Natural selection is a theory, just like gravity. If you don't
> > believe it, go jump off a bridge!
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (GNU/Linux)
> > iQEVAwUBRD0jD9tAhTFtyodpAQOTkAgAhSmY4WOo8LFcNEinuXnsCV2x9CU9159f
> > JzK2LcO/ilzOJMeBveeihpc2WuWwj8xUSMGjt11fpnegC9RsaBacH2qwU1gx/6Oh
> > bvVZnPJiPkZSfmkGak6GC9nfIQQRVYvuagEIcrWwNiKneKDNmjaMQuaknL4ILMkP
> > M2mc0Is9CX5x074nPUpNtjJZxItPBxv0IU8AODgjzogYrV5cpMtEyS1zS8Nw+vOY
> > 0dH0SnJJyWc6GzSuZn+5c7FQFa0lMM+L2bkC1hVESU8flk6QqM9yF70lGfQDwxBY
> > ztbsYpPpSWB7n6zUVxo5IaXfhAgHr0tIty5vjFM2XsZenZqIIzdYuA==
> > =iDY4
> > -----END PGP SIGNATURE-----
> > /*
> > PLUG: http://plug.org, #utah on irc.freenode.net
> > Unsubscribe: http://plug.org/mailman/options/plug
> > Don't fear the penguin.
> > */
> I agree wholeheartedly. What I meant is that its futile to block
> individual IPs. For every one you block, two more will appear. For an
> Internet connected device, one should put a policy for security in
> place that covers all IPs.
> Chris Carey
I want to make sure my comment is not taken out of of context. The way
you snipped it makes it appear as if I was making a blanket "forget
about it" approach to security in general. It was in response to
setting up blacklists for IPs attempting to connect to the SSH port.
More information about the PLUG