network security best practice (bcp38 & 140)
TRANSCRIPT
2014/5/24 [email protected] 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
2014/5/24 [email protected] 4
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.
2014/5/24 [email protected] 5
2014/5/24 [email protected] 6
aJacker
soluIons against IP reflecIon aJacks
IP spoofed packets
vicIm
open amplifier
prevenIng IP spoofing
client authorizaIon
BCP38 BCP140
2014/5/24 [email protected] 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.
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 [email protected] 8
packet
2014/5/24 [email protected] 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
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; }
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 [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
2014/5/24 [email protected] 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
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 [email protected] 16
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
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 [email protected] 20
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 [email protected] 22
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.
[email protected] 24 2014/5/24
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
[email protected] 25 2014/5/24
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; }; };
[email protected] 26 2014/5/24
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
[email protected] 27 2014/5/24
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’
[email protected] 28 2014/5/24
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
[email protected] 29 2014/5/24
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.”
[email protected] 30 2014/5/24
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”
[email protected] 31 2014/5/24
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
[email protected] 32 2014/5/24
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
[email protected] 33 2014/5/24
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
[email protected] 34 2014/5/24
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 [email protected] 35
conclusion
• implement BCP38 – enforce source IP address in your network
• implement access control for your services – source IP address based filtering
2014/5/24 [email protected] 36