Re: de-peering for security sake

[Joe Abley]

On Dec 26, 2015, at 10:09, Stephen Satchell  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.

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

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.


Joe

Re: de-peering for security sake

[Owen DeLong]

I think as granular as practicable. In some cases, that will be a /32 or /128. 
In some cases, that will be a /24 or /64.

In some cases, it may be an entire ASN.

Each network will need to decide for themselves based on the constraints of the 
time they have to address the issue, the level of automation for addressing 
these things, memory in their routing platform(s), etc.

There is no one-size-fits all answer.

Owen

> On Dec 26, 2015, at 06:19 , Mike Hammett  wrote:
> 
> How much is an acceptable standard to the community? Individual /32s ( or 
> /64s)? Some tipping point where 50% of a /24 (or whatever it's IPv6 
> equivalent would be) has made your naughty list that you block the whole 
> prefix? 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> 
> 
> Midwest Internet Exchange 
> http://www.midwest-ix.com 
> 
> 
> - Original Message -
> 
> From: "Owen DeLong"  
> To: "Dan Hollis"  
> Cc: "Mike Hammett" , "NANOG"  
> Sent: Saturday, December 26, 2015 1:00:35 AM 
> Subject: Re: de-peering for security sake 
> 
> 
>> On Dec 25, 2015, at 22:16 , Dan Hollis  wrote: 
>> 
>> On Fri, 25 Dec 2015, Owen DeLong wrote: 
>>> Merely because people are asleep at the switch does not give those of us in 
>>> a position to understand the consequences license to abuse our position. 
>> 
>> At what point do you cut the wire? How abusive is acceptable? 
> 
> IMHO, you never cut the wire. You may filter selectively, but cutting the 
> wire comes with far more collateral damage than actual useful effect. 
> 
> Owen 
> 

Re: IPv4 shutdown in mobile

[Mikael Abrahamsson]

On Sat, 26 Dec 2015, Mark Tinka wrote:

One network in southern Africa have upgraded 70% of their network to 4G 
as part of an enhancement exercise in the last 16x months, and provide 
98% 3G coverage across their country of operation. But not a peep re: 
IPv6.


Out of the 34 major mobile providers in Sweden, only one has a single peep 
regarding IPv6 for regular customers. All of these have ubiquitus 4G 
coverage and have had this for 4-5 years.



In general, in the progressive African countries, one would be
hard-pressed to get anything less than 3G coverage in major business
districts/cities.


Well, if most providers in Europe can't get this done, I am not surprised 
that the African ones won't get it done either. Remember that the european 
ones operate in an environment where RIPE went into last /8 policy almost 
4 years ago, and still most of them haven't deployed any IPv6 at all yet.


IPv6 only operation for mobile is going to become fairly easy in the next 
few years due to the entire ecosystem maturing in this aspect, so my guess 
is that we'll start to see a lot more IPv6 over the next few years in 
mobile.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: de-peering for security sake

[William Waites]

On Sat, 26 Dec 2015 11:14:25 -0500, Joe Abley  said:

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

Indeed this is only going to get worse with pressure on IPv4
addressing space. I often see this with small rural providers that
have not yet progressed to the level of getting their own address
space, and the available space is already insufficient in many cases.

Another important scenario where this happens is Tor exit nodes. I
have not observed any de-peering or network-layer filtering around
exit nodes, but the milder, but still very obnoxious, tactic of
application-layer capchas happens a lot. This is a serious problem for
privacy or security conscious users (i.e. most of Tor's userbase) that
tend not to enable JavaScript unless there is good reason. And a lot
of these capcha systems require JavaScript.

I see this every day since I live in a country where it would be
foolish not to use Tor as a matter of course. Large CDNs like
Cloudflare are guilty of this and this exascerbates the problem
because it prevents access to a very large set of resources and not
just a single web site. It's not nice. It has the effect of turning
the privacy-conscious into second-class netizens.

Rachel Greenstadt is presenting some research tomorrow at the CCC on
the effect this has on excluding contributions to common goods such as
Wikipedia:

https://events.ccc.de/congress/2015/Fahrplan/events/7324.html


--
William Waites   |  School of Informatics
   https://tardis.ed.ac.uk/~wwaites/  | University of Edinburgh
 https://hubs.net.uk/ |  HUBS AS60241

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: IPv4 shutdown in mobile

[Mark Tinka]

On 26/Dec/15 09:38, Mikael Abrahamsson wrote:

>  
>
> I guess there are major differences across the continent as to what
> network gear is used, but I know some operators who shipped their 10
> year old 2G basestations to African providers, and if these are still
> in use, potentially even without a support contract, then these will
> never support IPv6 properly. Networks built like this will be laggards
> just the same way people running old routers won't have the right
> features to support IPv6 properly.

In eastern and southern Africa, there is a reasonable average 3G and
4G/LTE coverage.

One network in southern Africa have upgraded 70% of their network to 4G
as part of an enhancement exercise in the last 16x months, and provide
98% 3G coverage across their country of operation. But not a peep re: IPv6.

In general, in the progressive African countries, one would be
hard-pressed to get anything less than 3G coverage in major business
districts/cities.

Mark.

Re: de-peering for security sake

[Owen DeLong]

> On Dec 26, 2015, at 08:14 , Joe Abley  wrote:
> 
> On Dec 26, 2015, at 10:09, Stephen Satchell  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

Re: de-peering for security sake

[Matthew Petach]

On Sat, Dec 26, 2015 at 12:34 PM, Owen DeLong  wrote:
>> On Dec 26, 2015, at 08:14 , Joe Abley  wrote:
>> On Dec 26, 2015, at 10:09, Stephen Satchell  wrote
>>> My 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.

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.

Massively different solution space volumes
to deal with.  Equating the two only has meaning
in cosmological contexts.

> Owen
>

Matt

Re: de-peering for security sake

[Baldur Norddahl]

On 26 December 2015 at 16:09, Stephen Satchell  wrote:

> On 12/26/2015 06:19 AM, Mike Hammett wrote:
>
>> How much is an acceptable standard to the community? Individual /32s
>> ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's
>> IPv6 equivalent would be) has made your naughty list that you block
>> the whole prefix?
>>
>
> My gauge is volume of obnoxious traffic.  When I get lots of SSH probes
> from a /32, I block the /32.  When I get lots of SSH probes across a range
> of a /24, I block the /24.
>


Do you people have nothing better to do than scan firewall log files and
insert rules to block stuff that was already blocked by default?

Hint: if ssh probes spams your log then move your ssh service to a non
standard port.

Regards,

Baldur

Re: announcement of freerouter

[Alan Buxey]

>RouterOS is an existing product by MikroTik

Yes but this was an announcement about freerouter. If RouterOS has an 
announcement to make they can send their own email ;)

alan

Re: de-peering for security sake

[Mike Hammett]

1) Automation is your friend. 
2) If a host is compromised and doing an SSH scan, it's likely going to also be 
attempting SMTP, WordPress, home router, etc. attacks. Use a canary to block 
that host altogether to better your network. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Baldur Norddahl"  
To: nanog@nanog.org 
Sent: Saturday, December 26, 2015 9:19:15 AM 
Subject: Re: de-peering for security sake 

On 26 December 2015 at 16:09, Stephen Satchell  wrote: 

> On 12/26/2015 06:19 AM, Mike Hammett wrote: 
> 
>> How much is an acceptable standard to the community? Individual /32s 
>> ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's 
>> IPv6 equivalent would be) has made your naughty list that you block 
>> the whole prefix? 
>> 
> 
> My gauge is volume of obnoxious traffic. When I get lots of SSH probes 
> from a /32, I block the /32. When I get lots of SSH probes across a range 
> of a /24, I block the /24. 
> 


Do you people have nothing better to do than scan firewall log files and 
insert rules to block stuff that was already blocked by default? 

Hint: if ssh probes spams your log then move your ssh service to a non 
standard port. 

Regards, 

Baldur 

Re: IPv4 shutdown in mobile

[Mikael Abrahamsson]

On Sat, 26 Dec 2015, Mark Tinka wrote:

None of the major mobile carriers in eastern, western, central and 
southern Africa have done anything IPv6-related on their network that I 
am aware about. The availability of IPv4 space in the AFRINIC region, 
coupled with the ease of spending millions on CG-NAT's vs. rolling out 
IPv6 means unless they start, someone's pants will be at their knees in 
a non-picturesque way very soon.


Well, in Europe and Asia, the amount of providers that have rolled out 
IPv6 is not zero, but I'd say it's in the 5-10% range or something like 
that.


It's easier to roll out IPv6 in a mobile network if you can do it single 
stack, so Apple supporting IPv6 only is a major step forward (this is due 
to the IPv6 bearer type was introduced around 12-14 years ago, whereas the 
IPv4v6 bearer type is less than 5 years old and was initially a 4G only 
thing).



The lack of interest, head-in-the-sand approach is quite alarming,
particularly as mobile networks are increasingly carrying the majority
of consumer data traffic in Africa, year-in, year-out.


A lot of providers who have rolled out IPv6 have predominantly done so 
because they happen to have employed good engineers and empowered them to 
do things over longer time, keeping IPv6 costs down because they were done 
during normal hardware/software cycles, instead of a short intensive 
project that cost a lot of money.


I imagine that doing IPv6 single stack rollout in mobile starting now, you 
could be done in 1-2 years without major costs incurred, because now the 
handset landscape has matured enough that there are a good set of devices 
that support (or will support) IPv6 single stack properly. 2-3 years back, 
this just wasn't the case for generic bought-in-the-electronics-store 3GPP 
featurephone or smartphone. It's still the case that if a large part of 
your customer base has simple phones or feature phones, IPv6 support isn't 
needed. So while I do not agree that it's a great business strategy to 
wait even longer, I can understand those who have waited because they saw 
it as too hard to do, potentially because they didn't have the skilled 
engineers to do it. If they start now or during 2016, it's going to be a 
lot easier for them compared to the ones who started in 2010.


I guess there are major differences across the continent as to what 
network gear is used, but I know some operators who shipped their 10 
year old 2G basestations to African providers, and if these are still in 
use, potentially even without a support contract, then these will never 
support IPv6 properly. Networks built like this will be laggards just the 
same way people running old routers won't have the right features to 
support IPv6 properly.


However, if you have 3G basestations with support contracts (or that at 
least have software updated in the last 5-10 years), then getting IPv6 
only working should be perfectly doable if they upgrade the core of their 
mobile network.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: announcement of freerouter

[mate csaba]

>RouterOS is an existing product by MikroTik

Yes but this was an announcement about freerouter. If RouterOS has an 
announcement to make they can send their own email ;)

since then i got it and corrected my page...
cs

Re: de-peering for security sake

[Mike Hammett]

How much is an acceptable standard to the community? Individual /32s ( or 
/64s)? Some tipping point where 50% of a /24 (or whatever it's IPv6 equivalent 
would be) has made your naughty list that you block the whole prefix? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Owen DeLong"  
To: "Dan Hollis"  
Cc: "Mike Hammett" , "NANOG"  
Sent: Saturday, December 26, 2015 1:00:35 AM 
Subject: Re: de-peering for security sake 


> On Dec 25, 2015, at 22:16 , Dan Hollis  wrote: 
> 
> On Fri, 25 Dec 2015, Owen DeLong wrote: 
>> Merely because people are asleep at the switch does not give those of us in 
>> a position to understand the consequences license to abuse our position. 
> 
> At what point do you cut the wire? How abusive is acceptable? 

IMHO, you never cut the wire. You may filter selectively, but cutting the wire 
comes with far more collateral damage than actual useful effect. 

Owen 

Re: de-peering for security sake

[Stephen Satchell]

On 12/26/2015 06:19 AM, Mike Hammett wrote:

How much is an acceptable standard to the community? Individual /32s
( or /64s)? Some tipping point where 50% of a /24 (or whatever it's
IPv6 equivalent would be) has made your naughty list that you block
the whole prefix?


My gauge is volume of obnoxious traffic.  When I get lots of SSH probes 
from a /32, I block the /32.  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.


By "lots" I mean hundreds or more.  When the criminals try to bust my 
door down, I take stops to stop them.


Ditto with attempts to relay mail through my mail servers.

My goal isn't to reduce traffic.  My goal is to stop irresponsible 
people from finding a rat-hole to do things I don't authorize them to 
do.  Defense in depth.


This is in addition to selecting the TCP and UDP ports carefully that I 
expose to the outside world.  Indeed, I have separate ACLs for inbound, 
outbound, and DMZ ports.  So, I've limited service from the inside to 
the outside to this:



#   ---originated by LAN host to Internet
FORWARD_TCP="ftp ssh snmp telnet smtp smtps submission domain http https ntp nicname 
rwhois pop3 pop3s imap imaps radius"
FORWARD_TCP="$FORWARD_TCP 465 8008 webcache 8443  snpp rsync"
#   xmpp-client
FORWARD_TCP="$FORWARD_TCP 5222 5223 8002"
#   Microsoft Notification Protocol (msnp) [Messenger]
FORWARD_TCP="$FORWARD_TCP 1863"
#   Microsoft PPTP
FORWARD_TCP="$FORWARD_TCP 1723"
#   Timbuktu client, Service Ports 1-4
FORWARD_TCP="$FORWARD_TCP 407 1417:1420"
#   memoq
FORWARD_TCP="$FORWARD_TCP 2705"
#
FORWARD_UDP="domain ntp snmp 407 443 500 1419 1701 1812 4500 snmp 3389 1 5 
"


Your client base and my client base differ.  I make NNAP difficult to 
use against the world from my people.  But I don't hamstring them; if 
they want access to an outside service, they have but to ask.


I also terminate spammers.

Re: de-peering for security sake

[Jared Mauch]

> On Dec 25, 2015, at 3:10 PM, Colin Johnston  wrote:
> 
> why do the chinese network folks never reply and action abuse reports, normal 
> slow speed network abuse is tolerated, but not high speed deliberate abuse 
> albeit compromised machines

Biggest reason I’ve seen is the same reason I delete spam in 
Chinese/Japanese/charset that is foreign to me.

When I know I’m supposed to be reading something I toss it into google 
translate, when I don’t expect it, it may not even reach my $inbox.  I’d expect 
writing to people in their non-native language is more likely to result in 
things being ignored or misclassified[1].

I work for a part of a multinational that doesn’t use the roman alphabet and 
mails are sometimes missed for this reason between our groups.

This is far more of a two way street than people realize.  When you find that 
person who speaks both languages it can remove hurdles.

- Jared

1 - Think of the setting ok_languages in spamassassin.

Re: de-peering for security sake

[Jared Mauch]

> On Dec 26, 2015, at 11:14 AM, Joe Abley  wrote:
> 
> 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.

Or if you can’t get users to use keys (aside from remove the users) consider 
things like:

example /etc/ssh/sshd_config
Match User root
PasswordAuthentication no

for users that should not be permitted to fall-back to password authentication.

- Jared

Re: de-peering for security sake

[Mike Hammett]

Different network types will have different abilities to enforce this. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Jared Mauch"  
To: "Joe Abley"  
Cc: nanog@nanog.org 
Sent: Saturday, December 26, 2015 3:21:03 PM 
Subject: Re: de-peering for security sake 


> On Dec 26, 2015, at 11:14 AM, Joe Abley  wrote: 
> 
> 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. 

Or if you can’t get users to use keys (aside from remove the users) consider 
things like: 

example /etc/ssh/sshd_config 
Match User root 
PasswordAuthentication no 

for users that should not be permitted to fall-back to password authentication. 

- Jared 

Re: de-peering for security sake

[Owen DeLong]

> On Dec 26, 2015, at 12:50 , Matthew Petach  wrote:
> 
> On Sat, Dec 26, 2015 at 12:34 PM, Owen DeLong  > wrote:
>>> On Dec 26, 2015, at 08:14 , Joe Abley  wrote:
>>> On Dec 26, 2015, at 10:09, Stephen Satchell  wrote
 My 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

Re: de-peering for security sake

[Valdis . Kletnieks]

On Sat, 26 Dec 2015 15:11:13 -0800, Owen DeLong said:
> Or contexts where the user is sloppy about securing their private key, e.g. 
> the real world.

I seem to remember that enough people stashed their entire home directory
to github, including their keys, that github had to put in special hacks
to stop that.


pgpUuzuP4j6c7.pgp
Description: PGP signature

Re: de-peering for security sake

[Owen DeLong]

> On Dec 26, 2015, at 15:54 , Baldur Norddahl  wrote:
> 
> On 27 December 2015 at 00:11, Owen DeLong  wrote:
> 
>> 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.
>> 
> 
> The key approach is still better. Even if the password is 123456 the
> attacker is not going to get in, unless he somehow stole the key file.

Incorrect… It is possible the attacker could brute-force the key file.

A 1024 bit key is only as good as a ~256 character passphrase in terms of 
entropy.

If you are brute force or otherwise synthesizing the private key, you do not 
need
the passphrase for the on-disk key. As was pointed out elsewhere, the passphrase
for the key file only matters if you already stole the key file.

In terms of guessing the private key vs. guessing a suitably long pass phrase, 
the
difficulty is roughly equivalent.

> Technically it is two-factor even if the user made one of the factors
> really easy. And that might save the day if you have users that chooses bad
> passwords.

Technically it’s not two-factor and pretending it is is dangerous.

> The system is weak in that it is too easy to steal the key file. It is not
> unlikely that a user with sloppy passwords is also sloppy with his key file.

Right… No matter what you do it is virtually impossible to protect against 
sloppy
users.

This has been true for decades even before the internet with teenagers given 
house
keys.

> Too bad ssh does not generally support a challenge-response protocol to a
> write only hardware key device combined with server side passwords that can
> be checked against a blacklist.

There’s no reason that it can’t if you use PAM.

Owen

Re: de-peering for security sake

[Valdis . Kletnieks]

On Sat, 26 Dec 2015 12:50:27 -0800, Matthew Petach said:

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

Actually, to be pedantic (and this is crypto, where failure to be pedantic
can be fatal), the online attacker still has only one large space to search
through.  The private key you have on disk isn't the private key you
present to the remote server - the passphrase is used to convert from
one to the other.

(Hint: Consider the case of an ssh key generated without a passphrase.
Yes, there's valid reasons for doing this, such as allowing an ssh from
within a cronjob or other place where providing a passphrase is difficult.
And yes, if you do this, you should be securing it at the server end to
only allow that key to invoke the one command it was intended to, by using
the 'command="/your/one/command/here" option in authorized_keys)

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

Actually, you have that backwards.  The attacker only has 2 solution
spaces if you *have* been sloppy and  your private key is captured.

The passphrase only helps if your private key on disk is captured - the
length of it determines how many possible on-the-wire private keys could
correspond to that on-disk copy.  Just remember that if they captured that,
they almost certainly also captured your known_hosts file - you *did* hash
that, right? :)

And of course, nothing hardens it like an iptables rule that only accepts
inbound port 22 (or whatever you chose) to only address space you *expect*
to see inbound ssh from. :)


pgpj6pFjmkpx0.pgp
Description: PGP signature

Re: de-peering for security sake

[Baldur Norddahl]

On 27 December 2015 at 00:11, Owen DeLong  wrote:

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

The key approach is still better. Even if the password is 123456 the
attacker is not going to get in, unless he somehow stole the key file.

Technically it is two-factor even if the user made one of the factors
really easy. And that might save the day if you have users that chooses bad
passwords.

The system is weak in that it is too easy to steal the key file. It is not
unlikely that a user with sloppy passwords is also sloppy with his key file.

Too bad ssh does not generally support a challenge-response protocol to a
write only hardware key device combined with server side passwords that can
be checked against a blacklist.

Regards,

Baldur

Re: de-peering for security sake

[Baldur Norddahl]

Owen you misunderstood what two factor is about. It is not practical to
brute force the key file. Nor is it practical to brute force a good
passphrase or password. Both have sufficient strength to withstand attack.

But two factor is about having two things that needs to be broken. The key
can be stolen, but the thief needs the password. The password can be
stolen, but the thief needs the key. He needs both.

SSH password + key file is accepted as two factor by PCI DSS auditors, so
yes it is in fact two factor.

But it is weak two factor because the key file is too easily stolen. NOT
because the key file can be brute forced. Nor because hypothetically
someone could memorize the content of the key file.

It is also weak because the key file can be duplicated. Note it does not
stop being two factor because of this, but stronger hardware based two
factor systems usually come with the property that it is very hard to
duplicate the key. Other examples of a two factor system were the key is
easy to duplicate is credit card with magnetic strip + pin. Example where
it is hard to duplicate is credit card with chip + pin. Both are examples
of where the password (the pin) is actually very weak, but it is still two
factor.

Btw, you should not be using RSA anymore and a 1024 bit RSA key does not in
fact have a strength equal to 1024 bits entropy. It was considered equal to
about 128 bit of entropy, but is believed to be weaker now. I am using ECC
ecdsa-sha2-nistp521 which is equal to about 256 bits. Although some people
with tin foil hats believe we should stay away from NIST altogether. Unless
someone breaks the crypto, you are NOT going to brute force that key.

Yes I get your argument, you are saying break the key and you won't need
the password, but a) you can't actually break the key before the universe
ends, b) it is still two factor, just a extremely tiny in the academic
sense little bit weaker two factor. All crypto based two factor systems
suffers from the possibility that one could break the crypto and possibly
escape the need to know one or even both factors. But Owen - come one -
this silly argument pales and is so infinite insignificant to the real
problem with the ssh key two factor system, which is that the key is easily
stolen and duplicated and there is no way to check the quality of the
password (users might even change the key password to NO password).

Regards,

Baldur


On 27 December 2015 at 03:37, Owen DeLong  wrote:

>
> > On Dec 26, 2015, at 15:54 , Baldur Norddahl 
> wrote:
> >
> > On 27 December 2015 at 00:11, Owen DeLong  wrote:
> >
> >> 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.
> >>
> >
> > The key approach is still better. Even if the password is 123456 the
> > attacker is not going to get in, unless he somehow stole the key file.
>
> Incorrect… It is possible the attacker could brute-force the key file.
>
> A 1024 bit key is only as good as a ~256 character passphrase in terms of
> entropy.
>
> If you are brute force or otherwise synthesizing the private key, you do
> not need
> the passphrase for the on-disk key. As was pointed out elsewhere, the
> passphrase
> for the key file only matters if you already stole the key file.
>
> In terms of guessing the private key vs. guessing a suitably long pass
> phrase, the
> difficulty is roughly equivalent.
>
> > Technically it is two-factor even if the user made one of the factors
> > really easy. And that might save the day if you have users that chooses
> bad
> > passwords.
>
> Technically it’s not two-factor and pretending it is is dangerous.
>
> > The system is weak in that it is too easy to steal the key file. It is
> not
> > unlikely that a user with sloppy passwords is also sloppy with his key
> file.
>
> Right… No matter what you do it is virtually impossible to protect against
> sloppy
> users.
>
> This has been true for decades even before the internet with teenagers
> given house
> keys.
>
> > Too bad ssh does not generally support a challenge-response protocol to a
> > write only hardware key device combined with server side passwords that
> can
> > be checked against a blacklist.
>
> There’s no reason that it can’t if you use PAM.
>
> Owen
>
>

Re: de-peering for security sake

[Damian Menscher via NANOG]

On Sat, Dec 26, 2015 at 10:06 PM, Matthew Petach 
wrote:

> Thanks for the reminder to look at it from multiple perspectives.
>

The key attribute missing from the discussion so far is that the factors be
*different*, from the set of:
  - something you know (password / PIN)
  - something you have (keyfob / OTP generator / chip)
  - something you are (fingerprint / retina scan)

Claiming a passphrase and key are two "factors" is missing the point --
they both come from the same set (a secret which could be cloned).  If you
believe those are two factors then a password alone is 10 factors (one for
each character)! ;)

Damian

Re: de-peering for security sake

[Colin Johnston]

interesting:)
but useful to make a attempt at cleaning up traffic from china and russia

colin

Sent from my iPhone

> On 27 Dec 2015, at 06:32, Hugo Slabbert  wrote:
> 
>> On Fri 2015-Dec-25 08:55:24 +0530, Suresh Ramasubramanian 
>>  wrote:
>> 
>> Hmm, has anyone at all kept count of the number of times such a discussion 
>> has started up in just the last year...
> 
> Not on an ongoing basis, but I was curious as well, so a quick mailbox search 
> for 2015:
> 
> http://mailman.nanog.org/pipermail/nanog/2015-January/072841.html
> subject: Facebook outage?
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-February/073556.html
> subject: AOL Postmaster
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-March/074251.html
> http://mailman.nanog.org/pipermail/nanog/2015-March/074241.html
> subject: Getting hit hard by CHINANET
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-April/074432.html
> subject: BGP offloading (fixing legacy router BGP scalability issues)
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-July/077790.html
> subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 
> hours
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-December/083104.html
> subject: de-peering for security sake
> author: Colin Johnston 
> 
> I tried to be pretty wide in the search and filter through a decent chunk of 
> false positives manually, though of course I could have missed some.  It does 
> skip a few of the "all of their traffic is crap and abuse reports are 
> ignored" messages that don't *explicitly* call for wholesale country-level 
> blocks or de-peering.
> 
>> ...and how many more times in the past 16 or so years?
> 
> I was curious, but not masochistic ;)
> 
> -- 
> Hugo
> 
> h...@slabnet.com: email, xmpp/jabber
> PGP fingerprint (B178313E):
> CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E
> 
> (also on textsecure & redphone)
> 
> 
>> 
>> Mind you, back in say 2004, this discussion would have run to 50 or 60 
>> emails at a bare minimum, in no time at all.
>> 
>> --srs
>> 
>> On 25-Dec-2015, at 6:55 AM, Stephen Satchell  wrote:
>> 
 On 12/24/2015 04:50 PM, Daniel Corbe wrote:
 Let’s just cut off the entirety of the third world instead of having
 a tangible mitigation plan in place.
>>> 
>>> While you thing you are making a snarky response, it would be handy for end 
>>> users to be able to turn on and off access to other countries retail.

Re: de-peering for security sake

[Matthew Petach]

On Sat, Dec 26, 2015 at 6:37 PM, Owen DeLong  wrote:
>> On Dec 26, 2015, at 15:54 , Baldur Norddahl  
>> wrote:
>>
[...]

>> The key approach is still better. Even if the password is 123456 the
>> attacker is not going to get in, unless he somehow stole the key file.
>
> Incorrect… It is possible the attacker could brute-force the key file.
>
> A 1024 bit key is only as good as a ~256 character passphrase in terms of 
> entropy.
>
> If you are brute force or otherwise synthesizing the private key, you do not 
> need
> the passphrase for the on-disk key. As was pointed out elsewhere, the 
> passphrase
> for the key file only matters if you already stole the key file.
>
> In terms of guessing the private key vs. guessing a suitably long pass 
> phrase, the
> difficulty is roughly equivalent.

Intriguing point.   I was thinking about it
from the end-user perspective; but you're
right, from the bits-on-the-wire perspective,
it's all just a stream of 1's and 0's, whether
it came from a private key + passphrase
run through an algorithm or not.

Thanks for the reminder to look at it from
multiple perspectives.  ^_^


Matt

Re: de-peering for security sake

[Hugo Slabbert]

On Fri 2015-Dec-25 08:55:24 +0530, Suresh Ramasubramanian  
wrote:


Hmm, has anyone at all kept count of the number of times such a discussion has 
started up in just the last year...


Not on an ongoing basis, but I was curious as well, so a quick mailbox 
search for 2015:


http://mailman.nanog.org/pipermail/nanog/2015-January/072841.html
subject: Facebook outage?
author: Colin Johnston 

http://mailman.nanog.org/pipermail/nanog/2015-February/073556.html
subject: AOL Postmaster
author: Colin Johnston 

http://mailman.nanog.org/pipermail/nanog/2015-March/074251.html
http://mailman.nanog.org/pipermail/nanog/2015-March/074241.html
subject: Getting hit hard by CHINANET
author: Colin Johnston 

http://mailman.nanog.org/pipermail/nanog/2015-April/074432.html
subject: BGP offloading (fixing legacy router BGP scalability issues)
author: Colin Johnston 

http://mailman.nanog.org/pipermail/nanog/2015-July/077790.html
subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 
24 hours

author: Colin Johnston 

http://mailman.nanog.org/pipermail/nanog/2015-December/083104.html
subject: de-peering for security sake
author: Colin Johnston 

I tried to be pretty wide in the search and filter through a decent chunk 
of false positives manually, though of course I could have missed some.  It 
does skip a few of the "all of their traffic is crap and abuse reports are 
ignored" messages that don't *explicitly* call for wholesale country-level 
blocks or de-peering.



...and how many more times in the past 16 or so years?


I was curious, but not masochistic ;)

--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on textsecure & redphone)




Mind you, back in say 2004, this discussion would have run to 50 or 60 emails 
at a bare minimum, in no time at all.

--srs

On 25-Dec-2015, at 6:55 AM, Stephen Satchell  wrote:


On 12/24/2015 04:50 PM, Daniel Corbe wrote:
Let’s just cut off the entirety of the third world instead of having
a tangible mitigation plan in place.


While you thing you are making a snarky response, it would be handy for end 
users to be able to turn on and off access to other countries retail.


signature.asc
Description: PGP signature

Re: Broadband Router Comparisons

[Mikael Abrahamsson]

On Sat, 26 Dec 2015, Mike wrote:

As a service provider with largely residential/small business customers, I 
certainly have some thoughts on broadband routers. Sorry if this is overly 
long.


Firstly, they are all junk.


Yes, that's correct. We get what we pay for. If the ISP buys the CPE, 
their procurement department will get bonus for shaving off every cent off 
of the price possible, meaning the device manufacturer also pressures all 
their people to come up a way to checkbox all the features requested.


For the low price CPEs bought in the electronics store, mostly by people 
with no technical expertise, we have a similar situation. Shiny box, list 
of some checkbox features, sell it for 8-12 months until there is a new 
SOC which is slightly more cost reduced, release a new hardware revision 
(completely incompatible with the old one but from a black box of view 
does the same), start selling that rev instead.


Margins in this business are super tight and most of the vendors aren't 
making any money, just like the mobile phone business. Providing security 
updates is just a cost, there is no upside, because these boxes sit in a 
closet, unloved until they stop working, and they're thrown out and 
replaced by a new unloved box that goes into the closet until it stops 
working again.


So the ecosystem is completely broken, and I have no idea how to fix it.

If someone like Consumer Reports or similar agency started testing and 
rating devices on these things like long-time support, automatic updates, 
software quality etc, and not just testing wifi speed as a factor of 
distance, we might get somewhere.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Broadband Router Comparisons

[Mike]

On 12/23/2015 06:49 PM, Lorell Hathcock wrote:

All:

Not all consumer grade customer premises equipment is created equally.  But end 
customers sure think it is.  I have retirement aged customers buying the 
crappiest routers and then blaming my cable network for all their connection 
woes.  The real problem is that there were plenty of problems on the cable 
network to deal with, so it was impossible to tell between a problem that a 
customer was having with their CPE versus a real problem in my network.

Much of that has been cleared up on my side now, but customers were used to 
blaming us for everything so that they don't even consider that their equipment 
could be to blame.

I want to be able to point out a third party list of all (most) broadband 
routers that rates them by performance.  Or that rates them by crappiness that 
I can send them to so they can look up their own router and determine if other 
users have had problems with that router and what can be done to fix it.

So far my search has been in vain.

Any thoughts?




As a service provider with largely residential/small business customers, 
I certainly have some thoughts on broadband routers. Sorry if this is 
overly long.


Firstly, they are all junk. Every last one of them. Period. Broadband 
routers are designed to be cheap and to appeal to people who don't know 
any better, and who respond well (eg: make purchasing decisions) based 
on the shape of the plastic, the color scheme employed, and number of 
mysterious blinking lights that convey 'something important is 
happening'. Further, the price point is $45 - $70 thereabouts, putting 
some definite constraints on the actual quality of the engineering and 
components that go into them. I feel that we, the service provider, 
endure a significantly high and undue burden of cost associated with 
providing ongoing support to customers as a result of the defects 
contained therein.


The laundry list of general operational issues for broadband routers, 
the ones that seem to be universal to every last one of them, goes 
something like this:


* Device lock ups
* Lost Settings
* Abysmal device security
* Inconsistent forwarding performance

I will try to describe these:

Device lock up is by far the most damming problem there is. The lights 
are on, the cables are plugged in, but you aren't going anywhere 
therefore the Internet must be down. This condition typically can be 
resolved by powercycling the device, and whaever problem it was 
encountering is magically remedied and all is well again. The concept of 
the device developing 'a problem' that can only be resolved by power 
cycling it, is foreign and completely blows end users minds. And yet, it 
is very common, and leaves end users stranded since they don't have even 
the most basic of troubleshooting abilities. We have had people who wait 
days or even a week or two before calling in to ask for support, because 
they think the problem will fix itself or that we the provider are 
simply down (and, in their eyes, we're frequently down anyways and this 
is just routine...) and so it's out of their hands.


We've noted that there are waves of device lockups that occur nearly 
every time the weather turns, which I attribute to brownouts and other 
variations in the power grid which occur at these times and when coming 
into the office after a stormy weekend we know to expect our phones to 
be lit up all day with enormous numbers of people all screaming about 
being 'down the whole weekend!' and every last one of them being able 
restore themselves via powercycling. We try to counsel these customers 
and educate them that 'power cycling' is always a good "first responder" 
step to try, and secondly, that they always should employ a good quality 
standby UPS in order to avoid these types of issues in the future, but 
they never listen and blame us anyways. Broadband routers are not 
designed with quality robust power supplies, which certainly lowers the 
costs, but contributes substantially to this problem. This particular 
issue, I think, is one of the greatest deficiencies shared by all.


Other times, 'lockup' simply resolves to router software problems, such 
as  a kernel panic, a crashed or bugged system process such as 
pppoe/pppd or dhcp, an overfull nat state table, memory leaks, or other 
purely software related troubles. The recovery procedure is the same, 
eg: power cycle the device, but as before, it doesn't actually "fix" the 
underlaying problem (bugged software), it merely alleviates the current 
symptom...until next time later when it happens again. Many of these 
troubles are simply outstanding bugs in the versions of the opensource 
code that the SDK is built on, which never seems to get updated and 
instead just uses the same old buggy code. Some custom kits also have 
just crap buggy protocol implementations that also just never get fixed. 
And usually, (although this is improving), many of these