Re: de-peering for security sake

[Owen DeLong <owen () delong com>]

> 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> wrote:
>
> > My gauge is volume of obnoxious traffic.  When I get lots of SSH probes from a /32, I block the /32.
>
> ... without any knowledge of how many end systems are going to be affected.
>
> A significant campus or provider user base behind a NAT is likely to
> have more infections in absolute terms, which means more observed bad
> behaviour. It also means more end-systems (again, in absolute terms)
> that represent collateral damage.

Living with IPv4 sucks. It’s only going to get worse. This not news.
There are no good IPv4 answers.

> > When I get lots of SSH probes across a range of a /24, I block the /24.
>
> [...]
>
> > When I see that the bad traffic has caused me to block multiple /24s, I will block the entire allocation.
>
> Your network, your rules. But that's not the way I would manage things
> if I thought my job was to optimise and maximise connectivity between
> my users and the Internet.

So what is your approach?

> 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.

Owen