We have just received alert from bgpmon that AS58587 Fiber @ Home Limited has hijacked most of our (AS43996) prefixes and Hurricane Electric gladly accepted them.
Anybody see their prefixes hijacked as well?
Yes, we have seen one of our prefixes hikacked. We contacted to Fiberathome and they told us the issue has been solved.
Greetings.
Ferran.
We have just received alert from bgpmon that AS58587 Fiber @ Home Limited has hijacked most of our (AS43996) prefixes and Hurricane Electric gladly accepted them.
Anybody see their prefixes hijacked as well?
Welcome to the party 
Not only you.
-Hank
be nice if some technical details were included
I have sent this to a contact at another Bangladeshi ISP that should be able to reach the right person for this ASAP.
Your prefix: xx.104.150.0/24:
Prefix Description: xxxx
Update time: 2015-06-30 07:39 (UTC)
Detected by #peers: 8
Detected prefix: xx.104.150.0/24
Announced by: AS58587 (FIBERATHOME-BD Fiber @ Home Limited,BD)
Upstream AS: AS6939 (HURRICANE - Hurricane Electric, Inc.,US)
ASpath: 25152 6939 58587
and another:
On Tuesday June 30th 2015 at 7:37 UTC we detected a Origin AS Change event for your prefix (23.44.244.0/22 Akamai)
The detected prefix: 23.44.244.0/22, was announced by AS58587 (FIBERATHOME-BD Fiber @ Home Limited,BD) Alert description: Origin AS Change
Detected Prefix: 23.44.244.0/22
Detected Origin AS: 58587
Expected Origin AS: 1680
Same Aspath of 6939 58587
-Hank
NTT's customer Sofia Connect leaked our routes to NTT. NTT accepted
these routes instead of properly filtering their customer
announcements. As a network of non-trivial size, announcing over
75,000 customer routes which is nearly 15% of the IPv4 routing table,
we'd expect the common courtesy of having our ASN included in their
customer facing AS-PATH filters, as we extend this same courtesy to
other networks of this size (such as AS2914).
sometimes the goddesses have a sense of humor
A friend in AS58587 confirmed that this was caused by a configuration
error - it seems like related to redistribution, and they already
fixed that.
A friend in AS58587 confirmed that this was caused by a configuration
error - it seems like related to redistribution, and they already
fixed that.
7007 all over again. do not redistribute bgp into igp. do not
redistribute igp into bgp.
randy
I also suggested them to implement BGP community based route filtering
in their outbound policy. Any other suggestions or thoughts to
prevent such incidents in general?
- Get your downstreams to create route objects before you turn them up.
- Get your provisioning teams to validate the prefixes being
provided by your downstreams.
- Use both prefix- and AS_PATH-based filters for your downstreams.
- Use BGP communities (as you've stated).
- No exceptions.
Mark.
In addition to the BGP community scheme, outbound as-path filters could
help. Most network's list of transit providers is fairly static, it
would be easiy with as-path filters to prevent announcing upstream
routes to other upstreams or peering partners.
Kind regards,
Job
I agree, but possibly not in the case of a redistribution loop.
(We don't know that's what happened, exactly, but I thought it was worth mentioning.)
Joe
Joe, you are right.
In this specific situation, for a small to medium sized network, it
might be prudent to apply an outbound prefix-filter on all transit &
peering sessions and thus only allowing prefixes which actually belong
to downstream customers and the network itself.
One could generate that prefix-list based on the network's AS-SET. I
wouldn't deploy /only/ outbound prefix-filters. This method should be
viewed as complementary to other methods such as the already mentioned a
BGP community scheme.
Kind regards,
Job
I say that regardless of size, deploy the ultimate solution as the
network is only bound to grow.
It's harder for folk to undo old habits as they become more entrenched.
Mark.
At a minimum, AS-PATH filtering of outgoing routes to just your ASN(s) and your downstream customer ASNs. Whether this is done manually, built using AS-SETs from your route registry of choice, or through some other
automated means is another story.
jms
Except that this was not a route leak per se. The announced routes AS_PATH shows them as originated by the offending AS, not *propagated* by the offending AS. So the outbound AS_PATH did not retain the upstream portion of the path.
--Sandy
Nothing is ever regardless of anything 
I would forsee issues if i'd try to add an eleven megabyte prefix-list
on all devices in the network.
Kind regards,
Job
That sort of AS_PATH filtering would not have helped in this case. The AS originated the routes, it did not propagate an upstream route.
So an AS_PATH filter to just its own AS would have passed these routes.
You would need origin validation on your outbound routes. Job suggested prefix filters on outbound routes. (If you are doing prefix filters on your inbound customer links, it might be excessive caution to also prefix filter customers prefixes on outbound links? Or is it: you can never be too careful, belt-and-suspenders, measure twice, etc?)
--Sandy
plus:
- fully automate ingress prefix management
- use maxprefixes with manual reenable on all ebgp sessions
I've been caught with fully automated IRR based per-session prefix
filtering where the customer put the IXP AS macro into their AS macro.
When the customer did a 7007 on this, we accepted everything that they
announced back to us, oy vey.
So you need both.
Nick