The Distributed Firewall

Isn't it a better idea to block unwanted traffic at the source? Here's how that might work.

I'd promised myself that I wouldn't post this until I'd had the time to fully form the idea, but as I find myself constantly overworked and overtired, I might as well post what I have to date and perhaps amend and append further on down the road.

The problem

Background noise on the Internet is a growing problem. Bad code with hard-coded IP addresses, forgotten cronjobs, vacated IP ranges, vanished enterprises and so forth have decreased the signal to noise ratio of the IP traffic on the Internet (think what you might about the ratio of the content). Further, DDoS attacks, SPAM, worms and viruses are with us every step of the way. The packet containing this sentence might be in the buffer right behind a packet containing Welchia. Who could know? Adding to this problem are the hastily implemented filters placed on routers and firewalls all over the Internet, blocking traffic from an assortment of IP ranges for infractions committed by the user of that IP space at a certain point in time. If enough of these forgotten filters exist for an IP range, this renders entire range simply unusable.

A Solution

The best example I have come up with for what I'm thinking is BGP. While BGP may be undergoing a renaissance of sorts at the moment, it forms the basic structure of the distributed firewall.

Currently, you must be a somewhat-trusted entity with significant connectivity to be assigned an ASN. DBP (Distributed Blackhole Protocol) would function similarly, with neighbors authenticated via private keys or similar. Due to the nature of the protocol, participation in DBP would be subject to intense peer review and perhaps even be initially limited to Tier 1 providers.

The main thrust of DBP is the concept that a trusted source can determine the source, or closest DBP peering point, of an unattractive datastream. This datastream might be a zombie engaged in a smurf attack, and open relay, or a worm-infested host. The trusted source could then issue a DBP-drop request to the closest DBP peer to the origination point of the unattractive stream, which would then populate a dynamic ACL to blackhole specific traffic from that origin destined for the requesting source.

The DBP filtering agent need not be a router; the agents could be transparent, fail-open in-line devices on ethernet segments connecting peering points or edge routers. They could be driven by a central server that receives and acts upon inbound requests from DBP sources. This would permit the centralization of administration, and allow for cheaper agents to be deployed throughout a network. The communications between the DBP server and agents should be source-address filtered and SSL encrypted at the least, with private key authentication. With this method, agent configuration should be minimal and deployment relatively simple. This will be an important factor for adoption.

Here's a very simple illustration:


Fledgling rules:

  • Drop requests are made by downstream ISPs or customers of the provider via manual request form. This might get onerous.
  • Requests are spooled on the local ISPs DBP server, and either automatically processed or held in a queue for administrator review.
  • Requests are then forwarded to the DBP service nearest the source. Closest DBP server to traffic source is based on route tracing and DBP peer information.
  • Drop requests may not be fulfilled immediately, depending on load.
  • Drop requests have an implicit 60 minute TTL, max 120 minutes, minimum 10 minutes. TTL is determined by the requesting server.
  • A single DBP pair may not have more than 1,024 active drop requests at any moment in time.
  • Extended drop requests (i.e. repetitive requests at each drop expiration) beyond 24 hours must be manually approved.
  • All drop requests are to be formed as src/dst layer 3:4 pairs, and ICMP packet types, e.g.
  • Filters cannot block packets destined for any other IP address or range other than the one requested.
  • TCP/UDP ranges are valid for source address only.
  • A configurable request threshold for automated filter invocation can be made on a global and subnet basis.

    (e.g. more than n identical requests within x minutes from unique DBP sources triggers automatic filtering)
  • Notification of administrators is required for every subnet that passes the request threshold and is subsequently filtered.
  • The receiving DBP service should respond to the requesting server with an ACK or NACK with error code describing the action taken.
  • The server can be configured to ignore requests from certain servers, and to prioritize requests from others.
  • All filtering actions are logged and tracked for trend analysis. 

    I've looked around the net for a similar concept, but haven't seen anything quite like this. I can easily envision a reference implementation using iptables and perl on Linux. I hope to have the time to stitch this together at some point, but if there's anyone willing to have a go at it, or has any comments at all, let me know.