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
reflecIon
aJack
IP
spoofed
queries
replies
vicIm
AJacker

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. 2014/5/24
maz@iij.ad.jp
4
NTP
amplificaIon
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
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. 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: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
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. 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
flood
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. spoofing
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
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. 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. 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
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. 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
• 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. 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. 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