Information for enterprises

From BCP38
Jump to: navigation, search

Contents

What is BCP38?

BCP38 is a Best Current Practice published by the IETF which outlines methods useful in filtering out packets which are injected with a spoofed source address into a network. BCP was ratified in May 2000.

What Does It Mean To Me?

Due to the ever-growing frequency and size of DDoS attacks directed towards enterprise customers, BCP38 is becoming a critical tool in helping mitigate DDoS.

What it means to the enterprise is two fold:

Having an Internet Service Provider who is BCP38 compliant can help drop traffic if you come under DDoS attack.
Being BCP38 compliant can stop your devices participating in a DDoS

Overall, implementing BCP38 will make the Internet a better place for all users, not just your network.

How Do I Tell If I Have It Already?

How Does Having It Affect Me?

How Does Not Having It Affect Me?

How Do I Set It Up?

The exact steps to set up source address verification depends on the equipment that you use, its capabilities, and your topology. A deployment does not have to occur all at once and, like other aspects of network security, need not be perfect at every point in order to gain benefit. For example, if one of your routers cannot check source addresses without impacting performance, you may be able to perform the checking upstream or downstream of the device and still achieve the desired result. Below are some places where it can generally be enabled with no impact to valid traffic. In all cases, know your network and research all commands, including any possible undesired side effects, before making any changes. Use at your own risk.

User LANs

These LANs only contain desktops/laptops and possibly IP phones. These LANs are often the easiest to set up, but can also be the most work as these are often the most numerous type of network in an enterprise. Suggested deployment plan:

  • Confirm that all nodes on the LAN are actually endpoints. You may discover routers, firewalls, or other layer 3-aware devices on user LANs as part of your audit. You may also find users running VMs on their PCs that run software routers or firewalls. If you do, exceptions will generally need to be made or these devices moved to other networks.
  • Identify all routers for the network. This is often just two routers—or layer 3 switches—running HSRP or VRRP between them.
  • Confirm the source address filtering capabilities of the routers for the network, and determine the appropriate commands. This could be a one-line command to enable verification, or require a LAN-specific access list.
  • Establish a baseline of CPU utilization for the routers on the network, as well as TCAM utilization.
  • Deploy source address verification using the commands determined above—either using the single verification command, or as an access list applied inbound on the interface facing the user desktops/laptops/phones.
  • Check CPU and TCAM utilization, as well as the device logs for any packets that were denied. The exact commands will differ per hardware platform.

Connections to your ISPs - major connections - outbound access list method

These connections are the circuits to your Internet Service Providers. It's assumed that you have multiple connections—with some shared among multiple locations—and having an identical access list at all of your connections to the Internet is preferred for ease of deployment. An identical access list can also minimize changes should your underlying topology change or be consolidated. This plan may be used when it is not feasible to check packets received on interfaces that face your internal infrastructure. Suggested deployment plan:

  • Establish a list of all Internet-routable networks you are advertising via BGP and all networks statically routed to your network from your ISP. This is generally address space you obtained from a Internet registry like ARIN, RIPE, APNIC, AfriNIC, or LACNIC, or address space delegated to you from your ISP(s).
  • Create an access list that permits packets containing these addresses as sources. The access list should end with a "deny" statement that logs exceptions, but the logging may be omitted if hardware limitations is a concern.
  • Establish a baseline of CPU utilization for your router that is connected to your ISP(s), as well as TCAM utilization.
  • Deploy the access list and apply it as an outbound access list on the interface(s) facing your ISP(s).
  • Check CPU and TCAM utilization, as well as the device logs for any packets that were denied. The exact commands will differ per hardware platform.

Connections to your ISPs - major connections - inbound access list or RPF command

This is an alternate way to check the source addresses of packets sent to your ISP(s) but could require more steps to deploy in large organizations or those with more connections to internal infrastructure. In this plan source address checking occurs when packets enter the router that has connections to your ISP(s) such that outbound checking is not needed. Each of the interfaces facing your internal infrastructure, if you have more than one, must have this enabled or there is still the potential to emit packets with spoofed source addresses. Checking the source addresses via another method downstream—like on a firewall off the interface—can plug such a gap. Suggested deployment plan:

  • Establish a list of all Internet-routable networks that could appear as source addresses in packets from each interface. Consider disaster recovery, planned maintenance, and unplanned outage scenarios, and any address space that is used for internal-to-internal connectivity via the router out another non-ISP-facing interface. (If such address space is not Internet-routable and delegated to you this is very likely a gap in your source address checking, and, if not checked elsewhere, could result in packets with invalid addresses reaching your ISP(s).)
  • If the list of addresses contains any addresses that your router will not permit using a single verification command, then you need to use an inbound access list for that interface. If using an access list, the last line should deny any packets that are not permitted, preferably logging them.
  • Establish a baseline of CPU utilization for your router that is connected to your ISP(s), as well as TCAM utilization.
  • If using an access list for the interface, deploy the access list and apply it as an inbound access list on the interface facing your internal infrastructure.
  • If using a single verification command, deploy it on the interface facing your internal infrastructure.
  • Check CPU and TCAM utilization, as well as the device logs for any packets that were denied. The exact commands will differ per hardware platform.

Connections to extranet partners

While BCP38 is primarily concerned with spoofed source addresses on the Internet, source address verification is also suggested for private links to your suppliers, partners, or customers. Deployment plans for these connections are very similar to the steps for ISP connections, but can use RFC1918 or other mutually-agreed private address space. See the two sections on ISPs above and adjust as needed for your topology.

Firewalls

A deployment plan for firewalls is heavily dependent on the firewall vendor as well as the number of interfaces in use on the firewall, and, of course, your internal network topology. Also, because firewalls often front networks containing a valid usage of RFC1918 addressing or perform NAT that changes the addresses of a packet, the concept of a "valid" address is not always clear. Further verification closer to your ISP connection(s) (or any private connection(s)) may be required. General steps if verification is not enabled by default, orientated for Cisco firewalls using static routing:

  • Establish a list of all addresses that could validly appear as source addresses in packets from each internal interface of the firewall. Consider disaster recovery, planned maintenance, unplanned outage scenarios, addresses in use behind load balancers, and any address space that is used for internal-to-internal connectivity via the firewall out another internal interface. It's possible and even likely that you will find address space that is not Internet-routable or not delegated to you.
  • Create a list of static routes that are needed to match the list of addresses, with next hops out the appropriate interface. You may find that none are needed, or that you need to adjust some, or that more-specific routes are needed.
  • For further safety, check the logs to confirm all connections through the firewall have source addresses that you considered, and that they are actually coming in the interface you expect. Cisco firewalls will use the xlate table before the routing table, so a correct static route is no guarantee that connections with not work via an unexpected interface. "show xlate detail" will provide a point-in-time snapshot of addresses seen on interfaces.
  • If the list of addresses contains any addresses that the firewall will not permit using a single verification command, then you need to use an inbound access list for that interface. If using an access list, the last line should deny any packets that are not permitted, preferably logging them.
  • Establish a baseline of CPU utilization, connection counts, denied connection counts, and any other gauge of system performance that is applicable for your firewall. Confirm that you have access to the firewall logs—preferably not via the firewall you will soon enable source verification on.
  • If using an access list for the interface, deploy the access list and apply as an inbound access list on the interface facing your internal infrastructure.
  • If using a single verification command, deploy it on the interface facing your internal infrastructure.
  • Check the CPU utilization, connection counts, denied connection counts, other system performance gauges gathered earlier, and especially the firewall log. Cisco firewalls will immediately log any packet drops due to failed verification.

What Does It Cost Me?

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox