nanog mailing list archives
Re: de-peering for security sake
From: Owen DeLong <owen () delong com>
Date: Sat, 26 Dec 2015 15:11:13 -0800
On Dec 26, 2015, at 12:50 , Matthew Petach <mpetach () netflight com> wrote: On Sat, Dec 26, 2015 at 12:34 PM, Owen DeLong <owen () delong com <mailto:owen () delong com>> wrote:On Dec 26, 2015, at 08:14 , Joe Abley <jabley () hopcount ca> wrote: On Dec 26, 2015, at 10:09, Stephen Satchell <list () satchell net> wroteMy gauge is volume of obnoxious traffic. When I get lots of SSH probes from a /32, I block the /32.[...]With respect to ssh scans in particular -- disable all forms of password authentication and insist upon public key authentication instead. If the password scan log lines still upset you, stop logging them.This isn’t a bad idea, per se, but it’s not always possible for the guy running the server to dictate usage to the people using the accounts. Also, note that the only difference between a good long passphrase and a private key is, uh, wait, um, come to think of it, really not much. The primary difference is that nobody expects to have to remember a private key so we don’t get fussed when they contain lots of entropy. Users aren’t good at choosing good long secure passphrases and the automated mechanisms that attempt to enforce strong passwords just serve to increase user confusion and actually reduce the entropy in passwords overall.No, the difference is that a passphrase works in conjunction with the private key, which is the "something you have" vs the "something you know" in two-factor authentication.
No… You are missing the point. Guessing a private key is roughly equivalent to guessing a really long pass phrase. There is no way that the server side can enforce password protection of the private key on the client side, so if you are assuming that public-key authentication is two-factor, then you are failing miserably.
With password authentication, there's only a single solution space for the attacker to sift through; with private key authentication, unless you're sloppy about securing your private key, there's two massive solution spaces for the attacker to sift through to find the unique point of intersection.
The point here is that securing the private key is a user task and not under the control of the administrator. As such, you have to assume sloppy.
Massively different solution space volumes to deal with. Equating the two only has meaning in cosmological contexts.
Or contexts where the user is sloppy about securing their private key, e.g. the real world. Owen
Current thread:
- Re: de-peering for security sake, (continued)
- Re: de-peering for security sake Owen DeLong (Dec 25)
- Message not available
- Re: de-peering for security sake Owen DeLong (Dec 25)
- Re: de-peering for security sake Mike Hammett (Dec 26)
- Re: de-peering for security sake Stephen Satchell (Dec 26)
- Re: de-peering for security sake Baldur Norddahl (Dec 26)
- Re: de-peering for security sake Mike Hammett (Dec 26)
- Re: de-peering for security sake Joe Abley (Dec 26)
- Re: de-peering for security sake William Waites (Dec 26)
- Re: de-peering for security sake Owen DeLong (Dec 26)
- Re: de-peering for security sake Matthew Petach (Dec 26)
- Re: de-peering for security sake Owen DeLong (Dec 26)
- Re: de-peering for security sake Valdis . Kletnieks (Dec 26)
- Re: de-peering for security sake Baldur Norddahl (Dec 26)
- Re: de-peering for security sake Owen DeLong (Dec 26)
- Re: de-peering for security sake Baldur Norddahl (Dec 26)
- Re: de-peering for security sake Owen DeLong (Dec 27)
- Re: de-peering for security sake Valdis . Kletnieks (Dec 27)
- Re: de-peering for security sake Christopher Morrow (Dec 27)
- Re: de-peering for security sake Mike Hale (Dec 27)
- Re: de-peering for security sake Christopher Morrow (Dec 27)
- Re: de-peering for security sake Mike Hale (Dec 27)