Re: Broken SSL cert caused by router?

[Lewis,Mitchell T.]

Meraki Access Points are interesting devices. 

I have found they cause issues with Linux firewalls if the merakis are not 
configured "correctly". 

Meraki Access Points do content inspections which I have found can cause 
produce symptoms similar to yours, although I have not experienced what you are 
describing. Since the MX64W is both an Access Point & security gateway, it has 
some additional content inspection/intelligence for it's security appliance 
role on top of the functions it performs as an access point, the same functions 
which are found in Meraki standalone access points as well. 

I am not sure what the specifics are as I do not use Meraki security appliances 
but it is worth checking. I have found with Meraki that items in the control 
panel/dashboard are not always labeled the best so I have found it is usually 
worth putting in a ticket with them and/or a call to them to see what they 
think (1-888-490-0918). 











Mitchell T. Lewis 
mle...@techcompute.net 
: www.linkedin.com/in/mlewiscc 
Mobile: (203)816-0371 
PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E Public PGP Key 




A computer will do what you tell it to do, but that may be much different from 
what you had in mind. ~Joseph Weizenbaum 

- Original Message -

From: "Mike"  
To: nanog@nanog.org 
Sent: Thursday, March 26, 2015 6:38:55 PM 
Subject: Broken SSL cert caused by router? 

Hi, 

I have a very odd problem. 

We've recently gotten a 'real' ssl certificate from godaddy to 
cover our domain (*.domain.com) and have installed it in several places 
where needed for email (imap/starttls and etc) and web. This works 
great, seems ok according to various online TLS certificate checkers, 
and I get the green lock when testing using my own browsers and such. 

I have a customer however that uses our web mail system now secured 
with ssl. I myself and many others use it and get the green lock. But, 
whenever any station at the customer tries using it, they get a broken 
lock and 'your connection is not private'. The actual error displayed 
below is 'cert_authority_invalid' and it's "Go Daddy Secure Certificate 
Authority - G2". And it gets worse - whenever I go to the location and 
use my own laptop, the very one that 'works' when at my office, I ALSO 
get the error. AND EVEN WORSE - when I connect to my cell phone provided 
hotspot, the error goes away! 

As weird as this all sounds, I got it nailed down to one device - 
they have a Cisco/Meraki MX64W as their internet gateway - and when I 
remove that device from the chain and go 'straight' out to the internet, 
suddenly, the certificate problem goes away entirely. 

How is this possible? Can anyone comment on these devices and tell 
me what might be going on here? 

Mike- 

Re: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761]

[ML]

Wouldn't it be a BCP to set no-export from the Noction device too?


On 3/26/2015 6:20 PM, Nick Rose wrote:

Several people asked me off list for more details, here is what I have 
regarding it.

This morning a tier2 isp that connects to our network made an error in their 
router configuration causing the route leakage. The issue has been addressed 
and we will be performing a full post mortem to ensure this does not happen 
again.
While investigating the issue we did find that the noction appliance stopped 
advertising the no export community string with its advertisements which is why 
certain prefixes were also seen.

Regards,
Nick Rose
CTO @ Enzu Inc.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Nick Rose
Sent: Thursday, March 26, 2015 3:49 PM
To: a...@djlab.com; Peter Rocca
Cc: nanog@nanog.org
Subject: RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 
/ AS4761]

This should be resolved from AS18978. If you experience anything else please 
let me know and I will get it addressed immediately.

Regards,
Nick Rose
CTO @ Enzu Inc.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy
Sent: Thursday, March 26, 2015 12:14 PM
To: Peter Rocca
Cc: nanog@nanog.org
Subject: RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 
/ AS4761]

On 03/26/2015 9:00 am, Peter Rocca wrote:

+1

The summary below aligns with our analysis as well.

We've reached out to AS18978 to determine the status of the leak but
at this time we're not seeing any operational impact.

+2, after the morning coffee sunk in and helpful off list replies I can
finally see it's probably not INDOSAT involved at all.

FYI, the more specifics are still active:

2015-03-26 13:56:11 Update  AS4795  ID  198.98.180.0/23 4795 4795 4761
9304 40633 18978 6939 29889 Active
2015-03-26 13:56:11 Update  AS4795  ID  198.98.182.0/23 4795 4795 4761
9304 40633 18978 6939 29889 Active

--
~Randy

Re: Broken SSL cert caused by router?

[Eygene Ryabinkin]

Thu, Mar 26, 2015 at 03:38:55PM -0700, Mike wrote:
> I have a customer however that uses our web mail system now secured 
> with ssl. I myself and many others use it and get the green lock. But, 
> whenever any station at the customer tries using it, they get a broken 
> lock and 'your connection is not private'. The actual error displayed 
> below is 'cert_authority_invalid' and it's "Go Daddy Secure Certificate 
> Authority - G2". And it gets worse - whenever I go to the location and 
> use my own laptop, the very one that 'works' when at my office, I ALSO 
> get the error. AND EVEN WORSE - when I connect to my cell phone provided 
> hotspot, the error goes away!
> 
> As weird as this all sounds, I got it nailed down to one device - 
> they have a Cisco/Meraki MX64W as their internet gateway - and when I 
> remove that device from the chain and go 'straight' out to the internet, 
> suddenly, the certificate problem goes away entirely.
> 
> How is this possible? Can anyone comment on these devices and tell 
> me what might be going on here?

Sounds like deep packet inspection (DPI) with SSL MITM.  Reading
  https://meraki.cisco.com/lib/pdf/meraki_datasheet_mx.pdf
makes me believe that this device can do that.  Look for it's
configuration, DPI for HTTPS must be active.
-- 
Eygene Ryabinkin, National Research Centre "Kurchatov Institute"

Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live.

Re: Broken SSL cert caused by router?

[Joe]

You might want to look at some of the documentation on that device.
Looks like it might be doing some proxy stuff.


Regards,
-Joe

On Thu, Mar 26, 2015 at 5:38 PM, Mike  wrote:
> Hi,
>
> I have a very odd problem.
>
> We've recently gotten a 'real' ssl certificate from godaddy to cover our
> domain (*.domain.com) and have installed it in several places where needed
> for email (imap/starttls and etc) and web. This works great,  seems ok
> according to various online TLS certificate checkers, and I get the green
> lock when testing using my own browsers and such.
>
> I have a customer however that uses our web mail system now secured with
> ssl. I myself and many others use it and get the green lock. But, whenever
> any station at the customer tries using it, they get a broken lock and 'your
> connection is not private'. The actual error displayed below is
> 'cert_authority_invalid' and it's "Go Daddy Secure Certificate Authority -
> G2". And it gets worse - whenever I go to the location and use my own
> laptop, the very one that 'works' when at my office, I ALSO get the error.
> AND EVEN WORSE - when I connect to my cell phone provided hotspot, the error
> goes away!
>
> As weird as this all sounds, I got it nailed down to one device - they
> have a Cisco/Meraki MX64W as their internet gateway - and when I remove that
> device from the chain and go 'straight' out to the internet, suddenly, the
> certificate problem goes away entirely.
>
> How is this possible? Can anyone comment on these devices and tell me
> what might be going on here?
>
> Mike-

Re: Broken SSL cert caused by router?

[Roland Dobbins]

On 27 Mar 2015, at 5:38, Mike wrote:

How is this possible? Can anyone comment on these devices and tell me 
what might be going on here?


It's been compromised and its being used for MITM?  Or has some sort of 
TLS inspection capability built in which is essentially MITM, and which 
is enabled?  Or some kind of content filtering capability which amounts 
to the same thing?


---
Roland Dobbins 

Broken SSL cert caused by router?

[Mike]

Hi,

I have a very odd problem.

We've recently gotten a 'real' ssl certificate from godaddy to 
cover our domain (*.domain.com) and have installed it in several places 
where needed for email (imap/starttls and etc) and web. This works 
great,  seems ok according to various online TLS certificate checkers, 
and I get the green lock when testing using my own browsers and such.


I have a customer however that uses our web mail system now secured 
with ssl. I myself and many others use it and get the green lock. But, 
whenever any station at the customer tries using it, they get a broken 
lock and 'your connection is not private'. The actual error displayed 
below is 'cert_authority_invalid' and it's "Go Daddy Secure Certificate 
Authority - G2". And it gets worse - whenever I go to the location and 
use my own laptop, the very one that 'works' when at my office, I ALSO 
get the error. AND EVEN WORSE - when I connect to my cell phone provided 
hotspot, the error goes away!


As weird as this all sounds, I got it nailed down to one device - 
they have a Cisco/Meraki MX64W as their internet gateway - and when I 
remove that device from the chain and go 'straight' out to the internet, 
suddenly, the certificate problem goes away entirely.


How is this possible? Can anyone comment on these devices and tell 
me what might be going on here?


Mike-

RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761]

[Nick Rose]

Several people asked me off list for more details, here is what I have 
regarding it.

This morning a tier2 isp that connects to our network made an error in their 
router configuration causing the route leakage. The issue has been addressed 
and we will be performing a full post mortem to ensure this does not happen 
again.
While investigating the issue we did find that the noction appliance stopped 
advertising the no export community string with its advertisements which is why 
certain prefixes were also seen.

Regards,
Nick Rose
CTO @ Enzu Inc.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Nick Rose
Sent: Thursday, March 26, 2015 3:49 PM
To: a...@djlab.com; Peter Rocca
Cc: nanog@nanog.org
Subject: RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 
/ AS4761]

This should be resolved from AS18978. If you experience anything else please 
let me know and I will get it addressed immediately.

Regards,
Nick Rose
CTO @ Enzu Inc.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy
Sent: Thursday, March 26, 2015 12:14 PM
To: Peter Rocca
Cc: nanog@nanog.org
Subject: RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 
/ AS4761]

On 03/26/2015 9:00 am, Peter Rocca wrote:
> +1
> 
> The summary below aligns with our analysis as well.
> 
> We've reached out to AS18978 to determine the status of the leak but 
> at this time we're not seeing any operational impact.

+2, after the morning coffee sunk in and helpful off list replies I can
finally see it's probably not INDOSAT involved at all.

FYI, the more specifics are still active:

2015-03-26 13:56:11 Update  AS4795  ID  198.98.180.0/23 4795 4795 4761 
9304 40633 18978 6939 29889 Active
2015-03-26 13:56:11 Update  AS4795  ID  198.98.182.0/23 4795 4795 4761 
9304 40633 18978 6939 29889 Active

--
~Randy

Re: godaddy contact

[Anne P. Mitchell, Esq.]

> Anyone from godaddy on here or have contact details for them? We are
> having a routing issue to them.
> 

Tim, please contact me offlist.

Anne

Anne P. Mitchell, Esq.
CEO/President
ISIPP SuretyMail Email Reputation, Accreditation & Certification
Your mail system + SuretyMail accreditation = delivered to their inbox!
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

Author: Section 6 of the Federal CAN-SPAM Act of 2003
Member, California Bar Cyberspace Law Committee
Ret. Professor of Law, Lincoln Law School of San Jose
303-731-2121 | amitch...@isipp.com | @AnnePMitchell | Facebook/AnnePMitchell 

Re: Frontier: Blocking port 22 because of illegal files?

[Aaron C. de Bruyn]

Someone with Frontier contacted me off-list and assured me they don't
block port 22, and that it could have been related to port scans,
infected PCs, etc...  They are looking in to it.

Apologies for the noise and for being a prat.  ;)

-A

On Wed, Mar 25, 2015 at 7:31 PM, Aaron C. de Bruyn  wrote:
> I've had a handful of clients contact me over the last week with
> trouble using SCP (usually WinSCP) to manage their website content on
> my servers.  Either they get timeout messages from WinSCP or a message
> saying they should switch to SFTP.
>
> After getting a few helpful users on the phone to run some quick
> tests, we found port 22 was blocked.
>
> When my customers contacted Frontier, they were told that port 22 was
> blocked because it is used to transfer illegal files.
>
> I called them, and got the same ridiculous excuse.
>
> Just a friendly heads-up to anyone from Frontier who might be
> listening, I have a few additional ports you may wish to block:
>
> 80 - Allows users to use Google to search for illegal files
> 443 - Allows users to use Google to search for illegal files in a secure 
> manner
> 69 - Allows users to trivially transfer illegal files
> 3389 - Allows users to connect to unlicensed Windows machines
> 179 - Allows users to exchange routes to illegal file shares
> 53 - Allows people to look up illegal names
>
> -A

RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761]

[Nick Rose]

This should be resolved from AS18978. If you experience anything else please 
let me know and I will get it addressed immediately.

Regards,
Nick Rose
CTO @ Enzu Inc.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy
Sent: Thursday, March 26, 2015 12:14 PM
To: Peter Rocca
Cc: nanog@nanog.org
Subject: RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 
/ AS4761]

On 03/26/2015 9:00 am, Peter Rocca wrote:
> +1
> 
> The summary below aligns with our analysis as well.
> 
> We've reached out to AS18978 to determine the status of the leak but 
> at this time we're not seeing any operational impact.

+2, after the morning coffee sunk in and helpful off list replies I can
finally see it's probably not INDOSAT involved at all.

FYI, the more specifics are still active:

2015-03-26 13:56:11 Update  AS4795  ID  198.98.180.0/23 4795 4795 4761 
9304 40633 18978 6939 29889 Active
2015-03-26 13:56:11 Update  AS4795  ID  198.98.182.0/23 4795 4795 4761 
9304 40633 18978 6939 29889 Active

-- 
~Randy

RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761]

[Randy]

On 03/26/2015 9:00 am, Peter Rocca wrote:

+1

The summary below aligns with our analysis as well.

We've reached out to AS18978 to determine the status of the leak but
at this time we're not seeing any operational impact.


+2, after the morning coffee sunk in and helpful off list replies I can 
finally see it's probably not INDOSAT involved at all.


FYI, the more specifics are still active:

2015-03-26 13:56:11	Update	AS4795	ID 	198.98.180.0/23	4795 4795 4761 
9304 40633 18978 6939 29889 	Active
2015-03-26 13:56:11	Update	AS4795	ID 	198.98.182.0/23	4795 4795 4761 
9304 40633 18978 6939 29889 	Active


--
~Randy

Charter Engineer

[Shawn L]

Could a Charter engineer with familiarity with Michigan contact me
off-list?  We have a mutual client who's having issues communicating
between sites.

Thanks

RE: Prefix hijack by INDOSAT AS4795 / AS4761

[Peter Rocca]

+1

The summary below aligns with our analysis as well. 

We've reached out to AS18978 to determine the status of the leak but at this 
time we're not seeing any operational impact.

-Original Message-
From: Andree Toonk [mailto:andree+na...@toonk.nl] 
Sent: March-26-15 11:54 AM
To: Peter Rocca
Cc: nanog@nanog.org
Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761

Hi List,

this morning our BGPmon system picked up many new more specific announcements 
by a variety of Origin ASns, the interesting part is that the majority of them 
were classified as BGP Man In The middle attacks (MITM).

A typical alert would look like:


Possible BGP MITM attack (Code: 21)

Your prefix:  23.20.0.0/15:
Prefix Description:   acxiom-online.com --- Amazon EC2 IAD prefix
Update time:  2015-03-26 11:27 (UTC)
Detected by #peers:   24
Detected prefix:  23.21.112.0/20
Announced by: AS14618 (AMAZON-AES - Amazon.com, Inc.,US)
Upstream AS:  AS3257 (TINET-BACKBONE Tinet SpA,DE)
ASpath:   4608 24130 7545 6939 40633 18978 3257 14618

All alerts have the following part of the AS Path is common:
40633 1897

We're still looking into the details of this particular cases, but based on 
past experience it's likely that it is not in fact 14618 AWS, that originated 
this more specific (in this example), but most likely
18978 (or 40633), which leaked it to AS40633 Los Angeles Internet exchange, 
where others picked it up and propagated it to their customers.

In the past we've seen similar issues caused by BGP traffic optimizers.
These devices introduce new more specifics (try to keep the ASpath in
tact) for Traffic engineering purposes, and then folks leak those. A good write 
up of a previous example can be found here:
http://www.bgpmon.net/accidentally-stealing-the-internet/

A quick scan show that this affected over 5000 prefixes and about 145 
Autonomous systems. All of these appear to be more specific prefixes (which is 
the scary part).

Cheers,
 Andree

PS. It appears this is not related to INDOSAT, they just happen to be one of 
the peers that picked this up.


.-- My secret spy satellite informs me that at 2015-03-26 7:43 AM  Peter Rocca 
wrote:
> We just received a similar alert from bgpmon - part of 108.168.0.0/17 is 
> being advertised as /20's - although we're still listed as the origin. We are 
> 40788.
> 
> 108.168.64.0/20  4795 4795 4761 9304 40633 18978 6939 40788
> 108.168.80.0/20  4795 4795 4761 9304 40633 18978 6939 40788
> 108.168.96.0/20  4795 4795 4761 9304 40633 18978 6939 40788
> 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788
> 
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy
> Sent: March-26-15 10:08 AM
> To: nanog@nanog.org
> Subject: Prefix hijack by INDOSAT AS4795 / AS4761
> 
> On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing 
> more specifics on one of our prefixes.   Anyone else seeing similar or 
> is it just us?
> 
> 198.98.180.0/23   4795 4795 4761 9304 40633 18978 4436 29889
> 198.98.182.0/23   4795 4795 4761 9304 40633 18978 4436 29889
> 

Re: Prefix hijack by INDOSAT AS4795 / AS4761

[Andree Toonk]

Hi List,

this morning our BGPmon system picked up many new more specific
announcements by a variety of Origin ASns, the interesting part is that
the majority of them were classified as BGP Man In The middle attacks
(MITM).

A typical alert would look like:


Possible BGP MITM attack (Code: 21)

Your prefix:  23.20.0.0/15:
Prefix Description:   acxiom-online.com --- Amazon EC2 IAD prefix
Update time:  2015-03-26 11:27 (UTC)
Detected by #peers:   24
Detected prefix:  23.21.112.0/20
Announced by: AS14618 (AMAZON-AES - Amazon.com, Inc.,US)
Upstream AS:  AS3257 (TINET-BACKBONE Tinet SpA,DE)
ASpath:   4608 24130 7545 6939 40633 18978 3257 14618

All alerts have the following part of the AS Path is common:
40633 1897

We're still looking into the details of this particular cases, but
based on past experience it's likely that it is not in fact 14618 AWS,
that originated this more specific (in this example), but most likely
18978 (or 40633), which leaked it to AS40633 Los Angeles Internet
exchange, where others picked it up and propagated it to their customers.

In the past we've seen similar issues caused by BGP traffic optimizers.
These devices introduce new more specifics (try to keep the ASpath in
tact) for Traffic engineering purposes, and then folks leak those. A
good write up of a previous example can be found here:
http://www.bgpmon.net/accidentally-stealing-the-internet/

A quick scan show that this affected over 5000 prefixes and about 145
Autonomous systems. All of these appear to be more specific prefixes
(which is the scary part).

Cheers,
 Andree

PS. It appears this is not related to INDOSAT, they just happen to be
one of the peers that picked this up.


.-- My secret spy satellite informs me that at 2015-03-26 7:43 AM  Peter
Rocca wrote:
> We just received a similar alert from bgpmon - part of 108.168.0.0/17 is 
> being advertised as /20's - although we're still listed as the origin. We are 
> 40788.
> 
> 108.168.64.0/20  4795 4795 4761 9304 40633 18978 6939 40788
> 108.168.80.0/20  4795 4795 4761 9304 40633 18978 6939 40788
> 108.168.96.0/20  4795 4795 4761 9304 40633 18978 6939 40788
> 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788
> 
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy
> Sent: March-26-15 10:08 AM
> To: nanog@nanog.org
> Subject: Prefix hijack by INDOSAT AS4795 / AS4761
> 
> On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing 
> more specifics on one of our prefixes.   Anyone else seeing similar or 
> is it just us?
> 
> 198.98.180.0/23   4795 4795 4761 9304 40633 18978 4436 29889
> 198.98.182.0/23   4795 4795 4761 9304 40633 18978 4436 29889
> 

Re: Prefix hijack by INDOSAT AS4795 / AS4761

[Christian Teuschel]

Hi Randy,

Assuming that your prefix is 198.98.180.0/22 (AS29889 - FSNET-1 - Fast
Serv Networks, LLC) none of the mentioned more specifics are currently
seen from the RIPE NCC's RIS network, see the Looking Glass widget:

https://stat.ripe.net/198.98.180.0/23#tabId=routing
https://stat.ripe.net/198.98.182.0/23#tabId=at-a-glance

though there has been some BGP activity going on since 11:49:42, see the
BGPlay and BGP Update Activity widget. In both cases the originating ASN
was AS29889.

Cheers,
Christian

On 26/03/15 15:46, Randy wrote:
> All,
> 
> Info gathered off-list indicates this may be a couple of issues in our
> case - possible routing leak by 18978 (check your tables!) and more
> specifics on our prefixes from 4795 that we couldn't see before the leak
> hence the apparent hijack.
> 
<>

Re: Prefix hijack by INDOSAT AS4795 / AS4761

[Chuck Anderson]

We are AS 10326 130.215.0.0/16 and I just received a BGPmon alert as
well:

130.215.160.0/20 4795 4795 4761 9304 40633 18978 4436 10326
130.215.176.0/20 4795 4795 4761 9304 40633 18978 4436 10326

On Thu, Mar 26, 2015 at 10:45:09AM -0400, Christopher Morrow wrote:
> On Thu, Mar 26, 2015 at 10:43 AM, Peter Rocca  wrote:
> > We just received a similar alert from bgpmon - part of 108.168.0.0/17 is 
> > being advertised as /20's - although we're still listed as the origin. We 
> > are 40788.
> >
> > 108.168.64.0/20  4795 4795 4761 9304 40633 18978 6939 40788
> > 108.168.80.0/20  4795 4795 4761 9304 40633 18978 6939 40788
> > 108.168.96.0/20  4795 4795 4761 9304 40633 18978 6939 40788
> > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788
> >
> 
> common point looks like LAIX ? their routeserver go crazy perhaps? or
> did they change in/out prefix management information?
> 
> > -Original Message-
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy
> > Sent: March-26-15 10:08 AM
> > To: nanog@nanog.org
> > Subject: Prefix hijack by INDOSAT AS4795 / AS4761
> >
> > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing
> > more specifics on one of our prefixes.   Anyone else seeing similar or
> > is it just us?
> >
> > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889
> > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889
> >
> > --
> > Randy

Re: Prefix hijack by INDOSAT AS4795 / AS4761

[Paul S.]

Same here. These Indosat guys can't seem to catch a break =/

On 3/26/2015 午後 11:43, Peter Rocca wrote:

We just received a similar alert from bgpmon - part of 108.168.0.0/17 is being 
advertised as /20's - although we're still listed as the origin. We are 40788.

108.168.64.0/20  4795 4795 4761 9304 40633 18978 6939 40788
108.168.80.0/20  4795 4795 4761 9304 40633 18978 6939 40788
108.168.96.0/20  4795 4795 4761 9304 40633 18978 6939 40788
108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy
Sent: March-26-15 10:08 AM
To: nanog@nanog.org
Subject: Prefix hijack by INDOSAT AS4795 / AS4761

On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing
more specifics on one of our prefixes.   Anyone else seeing similar or
is it just us?

198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889
198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889

Re: Prefix hijack by INDOSAT AS4795 / AS4761

[Pierre Emeriaud]

Hi,


2015-03-26 15:08 GMT+01:00 Randy :
> On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing more
> specifics on one of our prefixes.   Anyone else seeing similar or is it just
> us?
>
> 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889
> 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889

We (as3215) are seeing almost the same path with 40633 18978 3257
3215, for some quite a lot of prefixes.

Some alerts from bgpmon:
193.251.32.0/20 271 6939 40633 18978 3257 3215
193.251.32.0/20 271 6939 40633 18978 3257 3215

We are not directly connected to 3257. Looks like 18978 deaggregated
to /20 and reannounced to 40633 (LAIX).


Rgds,
pierre

Re: Prefix hijack by INDOSAT AS4795 / AS4761

[Randy]

All,

Info gathered off-list indicates this may be a couple of issues in our 
case - possible routing leak by 18978 (check your tables!) and more 
specifics on our prefixes from 4795 that we couldn't see before the leak 
hence the apparent hijack.


--
~Randy

Re: Prefix hijack by INDOSAT AS4795 / AS4761

[Christopher Morrow]

On Thu, Mar 26, 2015 at 10:43 AM, Peter Rocca  wrote:
> We just received a similar alert from bgpmon - part of 108.168.0.0/17 is 
> being advertised as /20's - although we're still listed as the origin. We are 
> 40788.
>
> 108.168.64.0/20  4795 4795 4761 9304 40633 18978 6939 40788
> 108.168.80.0/20  4795 4795 4761 9304 40633 18978 6939 40788
> 108.168.96.0/20  4795 4795 4761 9304 40633 18978 6939 40788
> 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788
>

common point looks like LAIX ? their routeserver go crazy perhaps? or
did they change in/out prefix management information?

> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy
> Sent: March-26-15 10:08 AM
> To: nanog@nanog.org
> Subject: Prefix hijack by INDOSAT AS4795 / AS4761
>
> On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing
> more specifics on one of our prefixes.   Anyone else seeing similar or
> is it just us?
>
> 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889
> 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889
>
> --
> Randy

Re: Prefix hijack by INDOSAT AS4795 / AS4761

[Christopher Morrow]

On Thu, Mar 26, 2015 at 10:38 AM, Randy  wrote:
> On 03/26/2015 7:27 am, Christopher Morrow wrote:
>>
>> is your AS in the path below? (what is your AS so folk can check for
>> your prefixes/customer-prefixes and attempt to help?)
>
>
> Sorry, we're 29889.
>

ok, and it looks like the path you clipped is:
198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889

possibly LAIX is passing along your /24 you didn't mean them to pass on?

RE: Prefix hijack by INDOSAT AS4795 / AS4761

[Peter Rocca]

We just received a similar alert from bgpmon - part of 108.168.0.0/17 is being 
advertised as /20's - although we're still listed as the origin. We are 40788.

108.168.64.0/20  4795 4795 4761 9304 40633 18978 6939 40788
108.168.80.0/20  4795 4795 4761 9304 40633 18978 6939 40788
108.168.96.0/20  4795 4795 4761 9304 40633 18978 6939 40788
108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy
Sent: March-26-15 10:08 AM
To: nanog@nanog.org
Subject: Prefix hijack by INDOSAT AS4795 / AS4761

On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing 
more specifics on one of our prefixes.   Anyone else seeing similar or 
is it just us?

198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889
198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889

-- 
Randy

Re: Prefix hijack by INDOSAT AS4795 / AS4761

[Randy]

On 03/26/2015 7:27 am, Christopher Morrow wrote:

is your AS in the path below? (what is your AS so folk can check for
your prefixes/customer-prefixes and attempt to help?)


Sorry, we're 29889.

Re: Frontier: Blocking port 22 because of illegal files?

[Daniel Corbe]

Nothing helps promote a free and open Internet more than micromanaging
your users' download activity.  

Not really sure how someone comes to the conclusion that nobody really
*needs* ssh for anything.

"Livingood, Jason"  writes:

> ISPs are generally expected to disclose any port blocking. A quick Google 
> search shows this is Frontier’s list:
> http://www.frontierhelp.com/faq.cfm?qstid=277
>
> On 3/25/15, 10:31 PM, "Aaron C. de Bruyn" 
> mailto:aa...@heyaaron.com>> wrote:
>
> I've had a handful of clients contact me over the last week with
> trouble using SCP (usually WinSCP) to manage their website content on
> my servers.  Either they get timeout messages from WinSCP or a message
> saying they should switch to SFTP.
>
> After getting a few helpful users on the phone to run some quick
> tests, we found port 22 was blocked.
>
> When my customers contacted Frontier, they were told that port 22 was
> blocked because it is used to transfer illegal files.
>
> I called them, and got the same ridiculous excuse.
>
> Just a friendly heads-up to anyone from Frontier who might be
> listening, I have a few additional ports you may wish to block:
>
> 80 - Allows users to use Google to search for illegal files
> 443 - Allows users to use Google to search for illegal files in a secure 
> manner
> 69 - Allows users to trivially transfer illegal files
> 3389 - Allows users to connect to unlicensed Windows machines
> 179 - Allows users to exchange routes to illegal file shares
> 53 - Allows people to look up illegal names
>
> -A

Re: Frontier: Blocking port 22 because of illegal files?

[Jeff Richmond]

All, I have reached out to Aaron privately for details, but we do not block 
port 22 traffic unless it is in direct response to an attack or related item. 
Please let me know directly if you have any specific questions.

Thanks,
-Jeff

> On Mar 26, 2015, at 7:09 AM, Livingood, Jason 
>  wrote:
> 
> ISPs are generally expected to disclose any port blocking. A quick Google 
> search shows this is Frontier’s list:
> http://www.frontierhelp.com/faq.cfm?qstid=277
> 
> On 3/25/15, 10:31 PM, "Aaron C. de Bruyn" 
> mailto:aa...@heyaaron.com>> wrote:
> 
> I've had a handful of clients contact me over the last week with
> trouble using SCP (usually WinSCP) to manage their website content on
> my servers.  Either they get timeout messages from WinSCP or a message
> saying they should switch to SFTP.
> 
> After getting a few helpful users on the phone to run some quick
> tests, we found port 22 was blocked.
> 
> When my customers contacted Frontier, they were told that port 22 was
> blocked because it is used to transfer illegal files.
> 
> I called them, and got the same ridiculous excuse.
> 
> Just a friendly heads-up to anyone from Frontier who might be
> listening, I have a few additional ports you may wish to block:
> 
> 80 - Allows users to use Google to search for illegal files
> 443 - Allows users to use Google to search for illegal files in a secure 
> manner
> 69 - Allows users to trivially transfer illegal files
> 3389 - Allows users to connect to unlicensed Windows machines
> 179 - Allows users to exchange routes to illegal file shares
> 53 - Allows people to look up illegal names
> 
> -A
> 

Re: Prefix hijack by INDOSAT AS4795 / AS4761

[Christopher Morrow]

On Thu, Mar 26, 2015 at 10:08 AM, Randy  wrote:
> On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing more
> specifics on one of our prefixes.   Anyone else seeing similar or is it just
> us?

is your AS in the path below? (what is your AS so folk can check for
your prefixes/customer-prefixes and attempt to help?)

>
> 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889
> 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889
>
> --
> Randy

Re: Frontier: Blocking port 22 because of illegal files?

[Livingood, Jason]

ISPs are generally expected to disclose any port blocking. A quick Google 
search shows this is Frontier’s list:
http://www.frontierhelp.com/faq.cfm?qstid=277

On 3/25/15, 10:31 PM, "Aaron C. de Bruyn" 
mailto:aa...@heyaaron.com>> wrote:

I've had a handful of clients contact me over the last week with
trouble using SCP (usually WinSCP) to manage their website content on
my servers.  Either they get timeout messages from WinSCP or a message
saying they should switch to SFTP.

After getting a few helpful users on the phone to run some quick
tests, we found port 22 was blocked.

When my customers contacted Frontier, they were told that port 22 was
blocked because it is used to transfer illegal files.

I called them, and got the same ridiculous excuse.

Just a friendly heads-up to anyone from Frontier who might be
listening, I have a few additional ports you may wish to block:

80 - Allows users to use Google to search for illegal files
443 - Allows users to use Google to search for illegal files in a secure manner
69 - Allows users to trivially transfer illegal files
3389 - Allows users to connect to unlicensed Windows machines
179 - Allows users to exchange routes to illegal file shares
53 - Allows people to look up illegal names

-A

Prefix hijack by INDOSAT AS4795 / AS4761

[Randy]

On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing 
more specifics on one of our prefixes.   Anyone else seeing similar or 
is it just us?


198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889
198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889

--
Randy

Re: Frontier: Blocking port 22 because of illegal files?

[Jens Link]

Stephen Satchell  writes:

> It's been a while since I did this, but you can select an additional
> port to accept SSH connections.  

That's easy: 

jens@screen:~$ grep Port /etc/ssh/sshd_config  
Port 22
Port 443
 
> Picking the right port to use is an exercise, though, that will depend
> on what other services you are running on your server.

I always have at least one sshd listening on port 443. For all the
hotel, coffee house, customer networks blocking ssh.  

You can even multiplex and run ssh and ssl on the same port:

http://www.rutschle.net/tech/sslh.shtml

Jens
-- 

| Foelderichstr. 40   | 13595 Berlin, Germany   | +49-151-18721264 |
| http://blog.quux.de | jabber: jensl...@jabber.quux.de | ---  | 

booster to gain distance above 60km

[Rodrigo Augusto]

Hi folksŠ we have a point and have a 63km between point A to point BŠ. We
have a sigle fiber ( only one fiber) and use a fiberstore sfp+ 10GB dibi
1270/1330 module to connect these sites. All attenuation are okŠI don¹t have
any trouble on fiber Š.
I have received this signal on my sfp+:

Receiver signal average optical power :  0.0026 mW / -25.85 dBm


Does anyone know if have some possible to amplifier this scenario to get
more 7db ? Is it possible to put any booster or any way to solve this?
I think to use a optical PreAmlifierŠbut I don¹t know if is possible because
my scenario have just one fiberŠor, use a ROPA- remote optical pumping
amplifier) because I have 63kmŠ
Does anyone have some idea?

Rodrigo Augusto
Gestor de T.I. Grupo Connectoway
http://www.connectoway.com.br 
http://www.1telecom.com.br 
* rodr...@connectoway.com.br 
( (81) 3497-6060
( (81) 8184-3646
( INOC-DBA 52965*100

Re: Frontier: Blocking port 22 because of illegal files?

[Seth Mos]

Stephen Satchell schreef op 26-3-2015 om 12:24:
> On 03/25/2015 07:31 PM, Aaron C. de Bruyn wrote:
>> After getting a few helpful users on the phone to run some quick
>> tests, we found port 22 was blocked.
> 
> It's been a while since I did this, but you can select an additional
> port to accept SSH connections.  A Google search indicates you can
> specify multiple ports in OpenSSH.  Picking the right port to use is an
> exercise, though, that will depend on what other services you are
> running on your server.
> 
> People with sane ISPs can use the standard port.  People on Frontier can
> use the alternate port, which shouldn't be firewalled by the provider.
> If Frontier is running a mostly-closed firewall configuration, then you
> have to be damn careful about the port you select.

Ahem, just to clarify, he is not talking about inbound on the Frontier
connection, but outbound *from* the Frontier network.

Akin to the "Let's block outbound port 25 (smtp)".

This is just a really really bad idea m'kay.

Cheers

Re: Frontier: Blocking port 22 because of illegal files?

[Stephen Satchell]

On 03/25/2015 07:31 PM, Aaron C. de Bruyn wrote:
> After getting a few helpful users on the phone to run some quick
> tests, we found port 22 was blocked.

It's been a while since I did this, but you can select an additional
port to accept SSH connections.  A Google search indicates you can
specify multiple ports in OpenSSH.  Picking the right port to use is an
exercise, though, that will depend on what other services you are
running on your server.

People with sane ISPs can use the standard port.  People on Frontier can
use the alternate port, which shouldn't be firewalled by the provider.
If Frontier is running a mostly-closed firewall configuration, then you
have to be damn careful about the port you select.