[dns-operations] Reducing AS112 traffic

[Sidney Faber]

This is a follow-up to the AS112 presentation from the LAX OARC meeting
(http://public.oarci.net/files/workshop-2007/Faber-AS112v2.pdf).  Thanks
for the feedback, I'm working on making a stronger case for data
exfiltration via AS112 (if one exists), and I'll forward results as they
emerge.

In the mean time, I know some folks would like to block AS112 traffic,
and I'd like to give them some advice.  The audience is varied, but
consider the typical medium-to-large enterprise admin.  They may have
access to any subset of workstations, DNS servers, firewalls or the
routing infrastructure.  I've tried to come up with some reasonable
solutions to implement at different layers and outline pros & cons of
each.  Do these sound reasonable?  Have I missed anything?  Thanks!


1.  Make your DNS server authoritative for:
    10.in-addr.arpa
    168.192.in-addr.arpa
    [16-31].172.in-addr.arpa
    254.169.in-addr.arpa
    Any other internal-only address blocks
  Pros:
    Works the way the system was intended
  Cons:
    Doesn't cover roving clients
    Clients have to use your DNS servers

2.  Do not allow clients to perform DNS updates
  Pros:
    Keeps mobile clients safe when they’re roaming
    Updates are now centrally controlled at the DHCP server
  Cons:
    Requires enforcement on *all* IP-enabled devices
    Misconfigured mobile guest on your network may still expose
      some topology
    Only affects UPDATE records, PTR records must be controlled
      separately (see #1)

3.  Create A records in your zone for prisoner.iana.org,
    blackhole-1.iana.org and blackhole-2.iana.org to sink
    traffic locally
  Pros:
    Simple, easy to manage
  Cons:
    Requires access to DNS servers
    Clients must use your DNS servers

4.  Block all 192.175.48.0/24 inbound and outbound traffic
  Pros:
    Easy to implement at network chokepoints
    Zero risk of blocking legitimate traffic
  Cons:
    If clients are not given a cachable negative reply, they often
       become more aggressive:  this is likely to amplify unwanted
       traffic

5.  Reroute AS112 to an internal server
  Pros:
    This essentially creates a local AS112 anycast node
    Successful, proven solution
  Cons:
    Exercise caution not to become a sink for other networks
      (what if later on someone drops a T1 into your network?)
    Technically more difficult

6.  Configure IDS to alert on (or IPS to block) AS112 traffic
  Pros:
    Uses existing infrastructure
    Might identify unauthorized access points
  Cons:
    Potential for excessive alerts
    IPS blocking could cause clients to become aggressive (see #4)




-- 
Sid Faber, Member of the Technical Staff
CERT
Software Engineering Institute
Carnegie Mellon University
sfaber at cert.org