Network Security Best Practice (BCP38 & 140)

BCP38 and BCP140

Matsuzaki ‘maz’ Yoshinobu <[email protected]>

2014/5/24 [email protected] 1


IP reflecIon aJack

IP spoofed queries

replies

vicIm

AJacker


DNS amplificaIon 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


NTP amplificaIon aJack

NTP NTP

vicIm

Command&Control

botnet

IP spoofed NTP queries

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.



aJacker

soluIons against IP reflecIon aJacks

IP spoofed packets

vicIm

open amplifier

prevenIng IP spoofing

client authorizaIon

BCP38 BCP140


Source Address ValidaIon/BCP38

•  ValidaIng source IP address of incoming packets –  BCP38/RFC2827

•  All providers of Internet connecIvity are urged to implement filtering described in this document to prohibit aJackers from using forged source addresses...

–  BCP84/RFC3704 •  It is important for ISPs to implement ingress filtering to prevent spoofed addresses being used, both to curtail DoS aJacks and to make them more traceable, and to protect their own infrastructure.

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


packet


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

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 [email protected]

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; }


point-‐to-‐point 10.0.0.0/30 2001:db8::/64

ISP Edge Router


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; }


point-‐to-‐point 10.0.0.0/30 2001:db8::/64

ISP Edge Router


13

cisco uRPF example

interface Gigabitethernet0/0 ip verify unicast source reachable-‐via rx ipv6 verify unicast source reachable-‐via rx

uRPF


point-‐to-‐point 10.0.0.0/30 2001:db8::/64

ISP Edge Router


14

juniper uRPF example

[edit interface ge-‐0/0/0 unit 0] family inet { rpf-‐check; } family inet6 { rpf-‐check; }

uRPF


point-‐to-‐point 10.0.0.0/30 2001:db8::/64

ISP Edge Router



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

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


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 [email protected]

if.o

if.i

192.0.2.0/28 10.0.0.0/8

if.o if.i

rouIng table

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 [email protected]

if.o

if.i

192.0.2.0/28 10.0.0.0/8

if.o if.i

rouIng table

aJack against a web site

•  110Kpps of TCP SYN flood was observed


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


spoofing


0.0.0.0

255.255.255.255

IPv4 range

Ime

BCP38 is useful to protect yourself

•  many access controls are depending on validity of source IP address – source IP address based filtering – ACL on vty, snmp and etc

•  If your users can spoof source IP address, sIll it’s reliable


BCP140 (RFC5358)

•  PrevenIng Use of Recursive Nameservers in Reflector AJacks – Best Current PracIce – hJps://tools.iex.org/html/bcp140

•  RecommendaIons: 1.  Disabling recursive service where it’s not

necessary 2.  ImplemenIng client authorizaIon

[email protected] 23 2014/5/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.


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


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; }; };


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


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’


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


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.”


the warning page

•  Simple text only – no javascript – no image – no link

•  At first 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”


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


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


lesson learned

•  effecIve 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


many other ‘misuseable’ services

•  ntp •  snmp •  games •  useful talk at RIPE68 last week

–  hJps://ripe68.ripe.net/presentaIons/227-‐RIPE68_2014_CRossow_AmplificaIon_stripped.pdf


conclusion

•  implement BCP38 – enforce source IP address in your network

•  implement access control for your services – source IP address based filtering


Date post:	22-Feb-2017
Category:	Internet
Upload:	bangladesh-network-operators-group
View:	398 times
Download:	3 times