Re: Validating possible BGP MITM attack

[Andy Litzinger <andy.litzinger.lists () gmail com>]

Hi Steve and Job,
  Same here- I didn't actually see my prefixes leaked anywhere I could
check, but I couldn't  check near China where BGPmon's probe was
complaining.  So I was glad it didn't seem to be spreading, but still
concerned that there may have been a large area (China) where my traffic
was getting hijacked.

The alert did clear after around 18 minutes.

Presuming it was a route optimizer and the issue was ongoing, what would be
the suggested course of action?  reach out to those 2 AS owners and see if
they could stop it?  Or is it something I just have to live with as a
traffic engineering solution they are using and mark the alerts as false
positives?

thanks!
 -andy

On Thu, Aug 31, 2017 at 10:23 AM, Steve Feldman <feldman () twincreeks net>
wrote:

> Interesting.  We also got similar BGPMon alerts about disaggregated
> portions of couple of our prefixes. I didn't see any of the bad prefixes
> in route-views, though.
>
> The AS paths in the alerts started with "131477 38478 ..." and looked
> valid after that.  Job's suggestion would explain that.
>
>      Steve
>
> On Aug 31, 2017, at 10:01 AM, Job Snijders <job () instituut net> wrote:
>
> Hi Andy,
>
> It smells like someone in 38478 or 131477 is using Noction or some other
> BGP "optimizer" that injects hijacks for the purpose of traffic
> engineering. :-(
>
> Kind regards,
>
> Job
>
> On Thu, 31 Aug 2017 at 19:38, Andy Litzinger <andy.litzinger.lists@gmail.
> com>
> wrote:
>
> Hello,
> we use BGPMon.net to monitor our BGP announcements.  This morning we
> received two possible BGP MITM alerts for two of our prefixes detected by a
> single BGPMon probe located in China.  I've reached out to BGPMon to see
> how much credence I should give to an alert from a single probe location,
> but I'm interested in community feedback as well.
>
> The alert detailed that one of our /23 prefixes has been broken into /24
> specifics and the AS Path shows a peering relationship with us that does
> not exist:
> 131477(Shanghai Huajan) 38478(Sunny Vision LTD) 3491(PCCW Global) 14042
> (me)
>
> We do not peer directly with PCCW Global.  I'm going to reach out to them
> directly to see if they may have done anything by accident, but presuming
> they haven't and the path is spoofed, can I prove that?  How can I detect
> if traffic is indeed swinging through that hijacked path? How worried
> should I be and what are my options for resolving the situation?
>
> thanks!
> -andy