Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Network Security Best Practice (BCP38 & 140)

918 views

Published on

Network Security Best Practice (BCP38 & 140)

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Network Security Best Practice (BCP38 & 140)

  1. 1. BCP38  and  BCP140 Matsuzaki  ‘maz’  Yoshinobu   <maz@iij.ad.jp> 2014/5/24 maz@iij.ad.jp 1
  2. 2. 2014/5/24   maz@iij.ad.jp   2   IP  reflecIon  aJack   IP  spoofed  queries   replies   vicIm   AJacker  
  3. 3. 2014/5/24   maz@iij.ad.jp   3   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
  4. 4. 2014/5/24   maz@iij.ad.jp   4   NTP  amplificaIon  aJack   NTP   NTP   vicIm   Command&Control   botnet   IP  spoofed   NTP  queries  
  5. 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. 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. 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   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.    
  8. 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. 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. 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. 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. 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. 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:ff::/48   point-­‐to-­‐point   10.0.0.0/30   2001:db8::/64   ISP  Edge  Router   2014/5/24 maz@iij.ad.jp
  14. 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:ff::/48   point-­‐to-­‐point   10.0.0.0/30   2001:db8::/64   ISP  Edge  Router   2014/5/24 maz@iij.ad.jp
  15. 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. 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. 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. 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. 19. aJack  against  a  web  site •  110Kpps  of  TCP  SYN  flood  was  observed   2014/5/24 maz@iij.ad.jp 19
  20. 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. 21. spoofing 2014/5/24 maz@iij.ad.jp 21 0.0.0.0 255.255.255.255 IPv4  range Ime
  22. 22. 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   2014/5/24 maz@iij.ad.jp 22
  23. 23. 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   maz@iij.ad.jp 23 2014/5/24
  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. 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. 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. 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. 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. 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. 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. 31. 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”   maz@iij.ad.jp 31 2014/5/24
  32. 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. 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. 34. 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   maz@iij.ad.jp 34 2014/5/24
  35. 35. 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   2014/5/24 maz@iij.ad.jp 35
  36. 36. conclusion •  implement  BCP38   – enforce  source  IP  address  in  your  network   •  implement  access  control  for  your  services   – source  IP  address  based  filtering   2014/5/24 maz@iij.ad.jp 36

×