Network Security Best Practice (BCP38 & 140)

1. BCP38 and BCP140 Matsuzaki ‘maz’ Yoshinobu <maz@iij.ad.jp> 2014/5/24 maz@iij.ad.jp 1

2. 2014/5/24 maz@iij.ad.jp 2 IP reﬂecIon aJack IP spoofed queries replies vicIm AJacker

3. 2014/5/24 maz@iij.ad.jp 3 DNS ampliﬁcaIon aJack DNS DNS DNS vicIm Command&Control DNS DNS stub-‐resolvers full-‐resolvers root-‐servers tld-‐servers example-‐servers botnet IP spoofed DNS queries ISP Cache DNS CPE/Routers

4. 2014/5/24 maz@iij.ad.jp 4 NTP ampliﬁcaIon aJack NTP NTP vicIm Command&Control botnet IP spoofed NTP queries

5. weakness •  AJackers love weakness, as it’s useful – ‘weaker’ means ‘easier’ for them •  AJackers will waste your resources if you don’t improve your security – internaIonal bandwidth – cpu power – etc. 2014/5/24 maz@iij.ad.jp 5

6. 2014/5/24 maz@iij.ad.jp 6 aJacker soluIons against IP reflecIon aJacks IP spoofed packets vicIm open amplifier prevenIng IP spoofing client authorizaIon BCP38 BCP140

7. 2014/5/24 maz@iij.ad.jp 7 Source Address ValidaIon/BCP38 •  ValidaIng source IP address of incoming packets –  BCP38/RFC2827 •  All providers of Internet connecIvity are urged to implement ﬁltering described in this document to prohibit aJackers from using forged source addresses... –  BCP84/RFC3704 •  It is important for ISPs to implement ingress ﬁltering to prevent spoofed addresses being used, both to curtail DoS aJacks and to make them more traceable, and to protect their own infrastructure.

8. BCP38 should be deployed as close to the edge as possible •  It’s reasonable to deploy BCP38 at provider edge routers precise rule can be applied for the packet. J not enough informaIon to apply strict rule, just able to check if its source IP is routable or not 2014/5/24 maz@iij.ad.jp 8 packet

9. 2014/5/24 maz@iij.ad.jp 9 enforcing the verificaIon by: •  ACL – packet filter – permit valid-‐source, then drop any •  uRPF check – using ‘rouIng table’ – look-‐up the return path for the source IP address – use strict mode for your customers •  you can’t stop IP reflecIon aJacks by loose mode

10. 10 cisco ACL example customer network 192.168.0.0/24 2001:db8:ff::/48 ip access-‐list extended fromCUSTMER4 permit ip 192.168.0.0 0.0.255.255 any permit ip 10.0.0.0 0.0.0.3 any deny ip any any ! IPv6 access-‐list fromCUSTMER6 permit ipv6 2001:db8::/64 any permit ipv6 any 2001:db8::/64 any permit ipv6 2001:db8:ff::/48 any permit ipv6 fe80::/10 fe80::/10 permit ipv6 fe80::/10 ff02::/16 deny ipv6 any any ! interface Gigabitethernet0/0 ip access-‐group fromCUSTOMER4 in ipv6 traffic-‐filter fromCUSTOMER6 in point-‐to-‐point 10.0.0.0/30 2001:db8::/64 ISP Edge Router 2014/5/24 maz@iij.ad.jp

11. 11 juniper IPv4 ACL example firewall family inet { filter fromCUSTOMER4 { term CUSTOMER4 { from source-‐address { 192.168.0.0/16; 10.0.0.0/30; } then accept; } term Default { then discard; }}} [edit interface ge-‐0/0/0 unit 0 family inet] filter { input fromCUSTOMER; } customer network 192.168.0.0/24 2001:db8:ff::/48 point-‐to-‐point 10.0.0.0/30 2001:db8::/64 ISP Edge Router 2014/5/24 maz@iij.ad.jp

12. 12 juniper IPv6 ACL example firewall family inet6 { filter fromCUSTOMER6 { term CUSTOMER6 { from source-‐address { 2001:db8::/64; 2001:db8:ff::/48; } then accept; } term LINKLOCAL { from source-‐address { fe80::/10; } desInaIon-‐address { fe80::/10; ff02::/16; } then accept; } term Default { then discard; }}} [edit interface ge-‐0/0/0 unit 0 family inet6] filter { input fromCUSTOMER6; } customer network 192.168.0.0/24 2001:db8:ff::/48 point-‐to-‐point 10.0.0.0/30 2001:db8::/64 ISP Edge Router 2014/5/24 maz@iij.ad.jp

13. 13 cisco uRPF example interface Gigabitethernet0/0 ip verify unicast source reachable-‐via rx ipv6 verify unicast source reachable-‐via rx uRPF customer network 192.168.0.0/24 2001:db8:ﬀ::/48 point-‐to-‐point 10.0.0.0/30 2001:db8::/64 ISP Edge Router 2014/5/24 maz@iij.ad.jp

14. 14 juniper uRPF example [edit interface ge-‐0/0/0 unit 0] family inet { rpf-‐check; } family inet6 { rpf-‐check; } uRPF customer network 192.168.0.0/24 2001:db8:ﬀ::/48 point-‐to-‐point 10.0.0.0/30 2001:db8::/64 ISP Edge Router 2014/5/24 maz@iij.ad.jp

15. 2014/5/24 maz@iij.ad.jp 15 BCP38 deployment at IIJ/AS2497 peering ASes Upstream ASes IIJ/AS2497 uRPF strict mode uRPF loose mode mulI homed AS/ISP customers consumer Enterprise Customers consumer

16. uRPF •  lookup a reverse path by source IP address •  strict mode – the incoming interface should match with the rouIng table •  loose mode – there should be a valid rouIng entry for the source IP address 2014/5/24 maz@iij.ad.jp 16

17. packet forwarding – dst-‐ip based •  rouIng_table(dst-‐ip) => outgoing interface – lookup by 10.0.0.1 => if.i – then router forwards the packet IP packet dst-‐ip src-‐ip data src ip: 192.0.2.1 dst-‐ip ip: 10.0.0.1 dst 2014/5/24 17 maz@iij.ad.jp if.o if.i 192.0.2.0/28 10.0.0.0/8 if.o if.i rouIng table

18. uRPF – lookup by the src-‐ip •  rouIng_table(src-‐ip) => interface – lookup by 192.0.2.1 => if.o – The result MUST match the incoming interface IP packet dst-‐ip src-‐ip data src ip: 192.0.2.1 dst-‐ip ip: 10.0.0.1 dst 2014/5/24 18 maz@iij.ad.jp if.o if.i 192.0.2.0/28 10.0.0.0/8 if.o if.i rouIng table

19. aJack against a web site •  110Kpps of TCP SYN ﬂood was observed 2014/5/24 maz@iij.ad.jp 19

20. uRPF loose did reduce the aJack •  The aJack was prevented if the admin at the aJack source has deployed BCP38 about 30% of the aJack packets were reduced by uRPF loose mode 2014/5/24 maz@iij.ad.jp 20

21. spooﬁng 2014/5/24 maz@iij.ad.jp 21 0.0.0.0 255.255.255.255 IPv4 range Ime

22. BCP38 is useful to protect yourself •  many access controls are depending on validity of source IP address – source IP address based ﬁltering – ACL on vty, snmp and etc •  If your users can spoof source IP address, sIll it’s reliable 2014/5/24 maz@iij.ad.jp 22

23. BCP140 (RFC5358) •  PrevenIng Use of Recursive Nameservers in Reﬂector AJacks – Best Current PracIce – hJps://tools.iex.org/html/bcp140 •  RecommendaIons: 1.  Disabling recursive service where it’s not necessary 2.  ImplemenIng client authorizaIon maz@iij.ad.jp 23 2014/5/24

24. implemenIng BCP140 •  Several ISPs in Japan have operated ‘open’ recursive nameservers for many years. As these servers tend to be used in dns amp aJacks, ISPs decided to put ACL to accept queries from its customers only -‐ BCP140. maz@iij.ad.jp 24 2014/5/24

25. Client AuthorizaIon •  BCP140 describes several ways: 1.  source IP address based 2.  Incoming interface based 3.  TSIG/SIG(0) signed queries 4.  using a local caching nameserver •  The 1st one is the opIon for ISPs – no other choice at this moment •  source IP address based authorizaIon – in other words, ACL J maz@iij.ad.jp 25 2014/5/24

26. Technically it’s quite easy // BIND9 recursive service example acl my-‐net { 192.0.2.0/24; 2001:db8::/32; }; opIons { recursion yes; allow-‐query { my-‐net; }; }; maz@iij.ad.jp 26 2014/5/24

27. There should not be issues •  Usually users automaIcally get DNS seyng – PPPoE – DHCP •  System integrators who are responsible for enterprise network keep its seyng up-‐to-‐date maz@iij.ad.jp 27 2014/5/24

28. real situaIons L •  Some users staIcally setup DNS seyng on their devices, and don’t change it forever even a{er switching ISPs •  Lazy system integrators use nameservers which they just know and leave them forever •  Some users change DNS seyng based on a rumor like ‘you can get more internet speed by changing DNS seyng’ maz@iij.ad.jp 28 2014/5/24

29. IIJ case •  public announcement on Sept 2013 – “for those who used IIJ services before” – corporate web site •  hJp://www.iij.ad.jp/company/development/tech/ acIviIes/open_resolver/ – technical blog •  hJp://techlog.iij.ad.jp/archives/718 – news site •  about 3months before implemenIng maz@iij.ad.jp 29 2014/5/24

30. 2st Dec 2013 12:00JST •  IIJ’s cache nameservers started to serve its customers only •  For queries from outside, the nameservers are answering staIc A to lead users to a warning web page. – saying “your dns seyng is not valid anymore, so you need change your seyng to access the internet. please contact your ISP or network administrator for further assistance.” maz@iij.ad.jp 30 2014/5/24

31. the warning page •  Simple text only – no javascript – no image – no link •  At ﬁrst we put the name of IIJ at the boJom, then users called IIJ by searching telephone number somehow •  So IIJ deleted its name, and emphasized “contact your ISP or network administrator” maz@iij.ad.jp 31 2014/5/24

32. Users •  Some users sIll could post messages on social medias -‐ probably by using their smartphone •  Some of them were suggesIng to use other publically available nameservers – google’s – just usable ones L maz@iij.ad.jp 32 2014/5/24

33. collaboraIon with other ISPs •  ImplemenIng BCP140 might increase # of customer calls at other ISPs’ helpdesk •  ISPs shared their implemenIng schedule in advance each other so that ISPs can expect customer calls •  ISP community could develop a shared warning page that shows the beJer contact based on the source IP address of the client maz@iij.ad.jp 33 2014/5/24

34. lesson learned •  eﬀecIve announcement – public and also targeted based on query log •  collaboraIng with other ISPs – for beJer customer support •  phased implementaIon could be your choice •  start early before the issue is geyng bigger – more unexpected users will use your nameserver maz@iij.ad.jp 34 2014/5/24

35. many other ‘misuseable’ services •  ntp •  snmp •  games •  useful talk at RIPE68 last week –  hJps://ripe68.ripe.net/presentaIons/227-‐RIPE68_2014_CRossow_AmpliﬁcaIon_stripped.pdf 2014/5/24 maz@iij.ad.jp 35

36. conclusion •  implement BCP38 – enforce source IP address in your network •  implement access control for your services – source IP address based ﬁltering 2014/5/24 maz@iij.ad.jp 36

Network Security Best Practice (BCP38 & 140)

Network Security Best Practice (BCP38 & 140)

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

Similar to Network Security Best Practice (BCP38 & 140)

Similar to Network Security Best Practice (BCP38 & 140) (20)

More from Bangladesh Network Operators Group

More from Bangladesh Network Operators Group(20)

Recently uploaded

Recently uploaded(15)

Network Security Best Practice (BCP38 & 140)