06 Aug

AS Number hijacking due to misconfiguration

 

This Sunday I was looking at global routing table dump and found AS1 announcing some very weird prefixes.

 

AS1 i.e Autonomous System Number 1 belongs to Level3 but as far as I know they are not actively using it. They use AS3356 globally (along with Global Crossing’s AS3549). I noticed quite a few prefixes of a Brazil based telecom provider – Netvip Telecomunicaes being announced by AS1. 

 

Some of entries in global routing table belonging to AS1 (as picked from BGP table dump of route-views archive):

Anurags-MacBook-Pro:Downloads anurag$ grep -w ‘1 i’ oix-full-snapshot-latest.dat|cut -f 3 -d ‘ ‘ |sort -u

177.185.100.0/23
177.185.100.0/24
177.185.101.0/24
177.185.102.0/23
177.185.102.0/24
177.185.103.0/24
177.185.104.0/23
177.185.104.0/24
177.185.105.0/24
177.185.106.0/23
177.185.106.0/24
177.185.107.0/24
177.185.108.0/23
177.185.108.0/24
177.185.109.0/24
177.185.110.0/23
177.185.110.0/24
177.185.111.0/24
177.185.96.0/23
177.185.96.0/24
177.185.97.0/24
177.185.98.0/23
177.185.98.0/24
177.185.99.0/24
186.251.240.0/21
186.65.112.0/20
190.185.108.0/22
4.31.236.64/29
4.34.12.0/24
4.34.13.0/24
94.31.44.0/24
Anurags-MacBook-Pro:Downloads anurag$

 

So there are quite a few prefixes belonging to different network providers being originated by AS1. Only 4.34.12.0/24 and 4.34.13.0/24 seem to be with Level3. Red ones here 188.185.xx.0/24 all belong to Netvip. This appeared very strange to me as why Level3 would let anyone to use AS1 and announce their own prefix? Could it be a hijacked ASN i.e someone using AS1 without having any specific relation to Level3? My past experience tells that if there’s a chance of hijacked ASN then easiest way out is to observe AS path and find who is providing upstream to that ASN.

 

Asking bgp table dump on what it knows about that prefix:

 

Anurags-MacBook-Pro:Downloads anurag$ grep -w 177.185.100.0/24 oix-full-snapshot-latest.dat
* 177.185.100.0/24 85.114.0.217 0 0 0 8492 9002 16735 52931 1 i
* 177.185.100.0/24 213.144.128.203 1 0 0 13030 16735 52931 1 i
* 177.185.100.0/24 66.185.128.1 556 0 0 1668 6762 26615 28309 52931 i
* 177.185.100.0/24 208.51.134.246 14233 0 0 3549 16735 52931 1 i
* 177.185.100.0/24 206.24.210.102 0 0 0 3561 6762 26615 28309 52931 i
* 177.185.100.0/24 67.17.82.114 14023 0 0 3549 16735 52931 1 i
* 177.185.100.0/24 134.222.87.1 0 0 0 286 6762 26615 28309 52931 i
* 177.185.100.0/24 157.130.10.233 0 0 0 701 3549 16735 52931 1 i
* 177.185.100.0/24 203.62.252.186 0 0 0 1221 4637 3549 16735 52931 1 i
* 177.185.100.0/24 198.129.33.85 0 0 0 293 16735 52931 1 i
* 177.185.100.0/24 216.18.31.102 0 0 0 6539 577 3549 16735 52931 1 i
* 177.185.100.0/24 154.11.11.113 0 0 0 852 2914 3549 16735 52931 1 i
* 177.185.100.0/24 137.164.16.84 0 0 0 2152 3356 3549 16735 52931 1 i
* 177.185.100.0/24 89.149.178.10 10 0 0 3257 3549 16735 52931 1 i
* 177.185.100.0/24 154.11.98.225 0 0 0 852 2914 3549 16735 52931 1 i
* 177.185.100.0/24 194.153.0.253 1015 0 0 5413 1299 3549 16735 52931 1 i
* 177.185.100.0/24 129.250.0.11 6 0 0 2914 3549 16735 52931 1 i
* 177.185.100.0/24 96.4.0.55 0 0 0 11686 11164 3549 16735 52931 1 i
* 177.185.100.0/24 195.22.216.188 100 0 0 6762 26615 28309 52931 i
* 177.185.100.0/24 216.218.252.164 0 0 0 6939 16735 52931 1 i
* 177.185.100.0/24 168.209.255.23 0 0 0 3741 2914 3549 16735 52931 1 i
* 177.185.100.0/24 144.228.241.130 0 0 0 1239 6762 26615 28309 52931 i
* 177.185.100.0/24 4.69.184.193 0 0 0 3356 3549 16735 52931 1 i
* 177.185.100.0/24 91.209.102.1 0 0 0 39756 3257 3549 16735 52931 1 i
* 177.185.100.0/24 80.91.255.62 0 0 0 1299 3549 16735 52931 1 i
* 177.185.100.0/24 12.0.1.63 0 0 0 7018 6762 26615 28309 52931 i
* 177.185.100.0/24 203.181.248.168 0 0 0 7660 2516 6762 26615 28309 52931 i
* 177.185.100.0/24 202.232.0.3 0 0 0 2497 3356 3549 16735 52931 1 i
* 177.185.100.0/24 147.28.7.1 0 0 0 3130 2914 3549 16735 52931 1 i
* 177.185.100.0/24 147.28.7.2 0 0 0 3130 1239 6762 26615 28309 52931 i

 

This is interesting. We can see two ASNs are originating this prefix – AS1 (as we know already) and AS52931. The fun fact is that wherever there’s AS1, the next ASN in AS path is AS52931 i.e AS1 for such prefixes is sitting below AS52931 which on other side is originating same prefix. Further AS52931 has upstream from AS28309 & AS16735. It seems like AS1 is coming only for routes which have AS16735 as upstream while for other case it’s direct announcement by AS52931. This gave me an interesting clue which was later verified by replies to my post on NANOG mailing list. 

 

Basically AS52931 – Netvip did not hijack AS1 intentionally but rather it was a case of mis-configured prepending. Netvip has two upstreams and was trying to prepend one of them (AS16735). In prepending networks simply repeat their own AS few times to increase AS-PATH which makes a route less preferred. 

 

Ideally what the needed is a AS path like this:

XXX XXX XXX 28309 52931 i – Preferred via AS28309 transit

XXX XXX XXX 16735 52931 52931 i – Not-preferred via AS16735 transit. 

 

Instead of putting their own ASN once in route map, they put “number 1” in the prepend which brought AS1 in global table for this prefix. I tried looking around and saw some funny prefixes from AS2, AS3, AS4 etc. 

 

Anurags-MacBook-Pro:Downloads anurag$ grep -w ‘2 i’ oix-full-snapshot-latest.dat|cut -f 3 -d ‘ ‘ |sort -u
128.4.0.0/16
177.129.161.0/24
31.192.64.0/19

 

Last prefix 31.192.64.0/19 does not belongs to AS2 (which is with UDEL-DCN – University of Delaware). 

 

route-views>sh ip bgp 31.192.64.0/19 long
BGP table version is 4043628875, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path
* 31.192.64.0/19 208.74.64.40 0 19214 25973 6830 3.1190 i
* 194.85.102.33 0 3277 3267 9002 6830 3.1190 i
* 4.69.184.193 0 0 3356 6830 3.1190 i
* 154.11.98.225 0 0 852 174 12570 3.1190 2 i
* 207.172.6.20 0 0 6079 6830 3.1190 i
* 193.0.0.56 0 3333 6830 3.1190 i
* 154.11.11.113 0 0 852 174 12570 3.1190 2 i
* 69.31.111.244 0 0 4436 6830 3.1190 i
* 194.85.40.15 0 3267 9002 6830 3.1190 i
* 66.59.190.221 0 6539 577 6830 3.1190 i
* 209.124.176.223 0 101 101 3356 6830 3.1190 i
* 128.223.253.10 0 3582 3701 3356 6830 3.1190 i
* 207.172.6.1 0 0 6079 6830 3.1190 i
* 157.130.10.233 0 701 1299 6830 3.1190 i
* 134.222.87.1 0 286 6830 3.1190 i
* 66.185.128.48 547 0 1668 6830 3.1190 i
* 202.249.2.86 0 7500 2497 6830 3.1190 i
* 216.218.252.164 0 6939 6830 3.1190 i
* 207.46.32.34 0 8075 6830 3.1190 i
* 144.228.241.130 0 1239 3257 8928 12570 3.1190 2 i
* 114.31.199.1 0 0 4826 6939 6830 3.1190 i
* 208.51.134.254 1 0 3549 3356 6830 3.1190 i
* 129.250.0.11 384 0 2914 8928 12570 3.1190 2 i
* 217.75.96.60 0 0 16150 6830 3.1190 i
* 195.66.232.239 0 5459 6830 3.1190 i
*> 164.128.32.11 0 3303 6830 3.1190 i
* 202.232.0.2 0 2497 6830 3.1190 i
* 203.62.252.186 0 1221 4637 6830 3.1190 i
* 203.181.248.168 0 7660 2516 3257 8928 12570 3.1190 2 i
* 66.110.0.86 0 6453 3356 6830 3.1190 i
* 89.149.178.10 10 0 3257 8928 12570 3.1190 2 i
* 12.0.1.63 0 7018 1299 6830 3.1190 i
* 206.24.210.102 0 3561 3356 6830 3.1190 i
route-views>

 

 

This seems even more interesting because of doted ASN. 🙂 

3.1190 means AS197798 as per dot conversion following RFC 5396. So we have AS197798 as well as AS2 sitting below AS197798 announcing that prefix – hence another misconfigured prepend case. (Nice tool by Sprint for dot.ASN conversion)

 

Regarding original case of AS1, I observed that yesterday  at 18:44:13 RIPE NCC route collectors noticed change in BGP announcements changes for this. 
One of route change noticed by Tinet AS3257 as route 3257 3549 16735 52931 1 was changed to 3257 3549 16735 52931. By 21:37:59 GMT, Netvip pulled off all routes from that mis-configured prepend. 

 

With hope that you won’t hijack an ASN while prepending, time for me to end this blog post and get back to work!

 

Note: 

I missed to thank Doug Madory from Renesys for his detailed explanation & Stephen Wilcox from IX Reach for giving clue about prepending in my original post. 

01 Feb

Network hijacking: Wrong BGP announcements screwing up traffic

Yesterday I came across a very interesting case of network hijacking of an ISP from wrong BGP announcements by another network. This issue was reported to NANOG mailing list. 

Issue was reported by Kevin, Senior Engineer at Altus Communications (AS11325). Problem was that SBJ Media LLC (AS33611) was making a /24 block announcement for specific slices of Altus –  208.110.48.0/2063.246.112.0/20, and 68.66.112.0/20 which are allocated to Altus Communications (as per ARIN whois).

Good news for now is problem seems on it’s way to fix, and route servers of At&t and Hurricane Electric are showing right path for /24 blocks.Just now Kevin updated NANOG saying: 

I hope none of you ever get hijacked by a spammer housed at Phoenix NAP. 🙂
We’re still not out of the woods, announcing /24s and working with upper
tier carriers to filter out our lists. However, I just got this response from Phoenix NAP and found it funny. The “thief” is a former customer,whom we terminated their agreement with. They then forged an LOA, submitted it to CWIE.net and Phoenix NAP and resumed using space above and beyond their terminated agreement.

 

This one is very interesting case and shows even today there’s no guarantee of correct routing on the Internet. So many autonomous systems out there but still at the end of day routing somehow works! 

 

What an ISP can do in such cases? (what I myself learned from looking at such cases so far):

  1. Small chunks like /24 are given more priority over /20, thus if someone hijacks /24 out of your /20 block then you can (should) also start announcing /24 to make sure hijacker does not get any additional benefit by announcing small specific route.
  2. Pick out upstream ISP’s of attacker’s autonomous system & eventually get announced prefixes filtered out at the source itself.
  3. Pick your upstream ISP’s and eventually request them for prefix filtering. 

 

This whole incidence reminds me of YouTube blackout in 2008 by Pakistan Telecom. Other then prefix filtering by big ISP’s one can’t really do much if such wrong announcement continues.

 

 

With hope that your ISP’s network is not “stealing” others IP’s time for me to go out for morning walk in village!

Special thanks to John Schneider from Iowa Network Services for his inputs & answering my questions! 🙂