Dynamic Firewall Daemon (DFD)

[email protected]

1 Copyright and Distribution Control

The latest version is always here:

http://www.subspacefield.org/security/dfd/

This is a copyrighted work, with some rights reserved. This work is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License (http://creativecommons.org/licenses/by-nc-nd/3.0/us/). This means you may redistribute it for non-commercial purposes, and that you must attribute me properly (without suggesting I endorse your work).

2 Description

The dynamic firewall daemon (DFD) sets up and (optionally) maintains your packet filter (firewall) rules. It is a framework, not a specific implementation. My goal is for it to be capable of doing almost anything that you’d want to do to firewall rules. Some people call them reactive firewalls, and they are akin to IPS systems. The philosophy behind DFD is to be the only program which modifies your firewall rules, and by doing so, it can enforce policies and allow multiple clients to request changes from it concurrently without problem.

2.1 CIDF Analysis

The Commom Intrusion Detection Framework (CIDF, see http://www.isi.edu/gost/cidf/drafts/architecture.txt) defines four components of intrusion detection systems. They are E-boxes (Event Generators), A-boxes (Event Analyzers), D-boxes (Event Databases), and R-boxes (Response Units). The dynamic firewall daemon (DFD) programs fall strictly within the R-box category.

2.2 Design Principle

The basic idea behind DFD is to "do one thing, and do it well". The DFD programs are designed to be able to exploit virtually any capability of the underlying firewall, and adds several abilities. It is designed to decouple the programs which invoke R-box functions (clients such as sniffers, snort, etc.) from the details of the R-box implementation (specifically, firewall rules).

DFD allows you to define a set of firewall rules (any of which may be active at a given time) and a set of commands which transform them in specific ways.

Put simply, the other components of your IDS shouldn’t need to know what kind of firewall you are using, much less what rule chain you want them to insert the block rules on, or the syntax of the rules, etc.

2.3 A Shell For Your Firewall

A way of explaining DFD (from the point of view of clients) might be to say that DFD aspires to be to the firewall what the Bourne shell (/bin/sh) is to Unix; it provides a convenient, simple, human-friendly text-based API for performing automated, parameterized tasks. Of course, all analogies are inaccurate at some level of detail, so certain things like pipelines have no direct analogue in DFD.

2.4 A Framework For Your Scripts

Another way of explaining DFD (from the implementor’s point of view) is that it is a framework (or API, or library) that the script you write can use to define the set of allowable firewall rulesets.

2.5 An Intelligent Network

In my opinion, a static firewall is like a locked door that sits there passively while you try to bypass it. An IDS is like an alarm system. An IPS is an alarm system that can block adversaries based on their claimed source IP.

DFD is something different; it allows your network to become an active, mildly intelligent target, dynamically reconfiguring itself in response to what an adversary does.

And if you’re going to do that for the occasional attacker, why not also have it reconfigure itself to make a legitimate user’s life easier on a day to day basis?

2.6 DFD Is Not...

a firewall
a way to write a single firewall ruleset
a language for generating firewall-specific rulesets
a NIDS
a NIPS
a tool that has any specific, single, narrow purpose

3 Motivation

3.1 Why Reactive?

The goal is to allow any passive firewall to become reactive, for it to go from a static device to a dynamic one.

One of my friends installed intrusion detection systems for customers. He said that often the CEO (or decision maker who wanted it installed) said he would want a call whenever an intrusion was attempted, but that after being woken up every night, this rarely lasted more than a few days. What’s the point of detecting something, like an intrusion, if you won’t, or can’t, do anything about it? If you were sitting in your house, and someone came by and started trying to open your doors and windows one by one, would you sit there and do nothing? If they broke in, would you sit there in fear and hope they didn’t kill you, or would you grab a weapon, hide yourself, and call for assistance?

Okay, I’ll assume we’re all agreed that you want to react to abuse somehow. But how? What if you’re sleeping, or drunk; do you really want to be editing firewall rules by hand? Suppose the attack is automated and happening too fast for a human to respond to, like a worm; what then? Well, obviously it needs to be automated. Furthermore, it is valuable to make the common changes to your firewall as easy and pain-free as possible. This increases availability and reliability, because you don’t accidentally lock yourself out of the firewall, or lose Internet connectivity for your whole LAN while you fumble around. You shouldn’t have to edit a config file to make a simple change to your firewall.

3.2 Reasons You Might Use DFD

Have you ever wanted to troubleshoot some networking problems, only to realize that your own firewall prevents your test packets from getting through (for example, packet scrubbing preventing traceroute from working)? In that case, the security measure (min-ttl fixing) is simply getting in the way, and it would be nice to be able to easily turn it off for a few seconds without disturbing anything else.
Have you ever wanted to block attackers from communicating with you at all, without requiring a NIPS?
Have you ever wanted to implement port-knocking (http://www.port-knocking.org/) or SPA (http://www.cipherdyne.org/fwknop/docs/SPA.html)?
Have you ever wanted to run peer-to-peer programs from behind NAT? What if you decide to switch internal computers? Wouldn’t you want a tool that could detect use on the other computer and redo your port forwarding automagically, and close (de-forward) the port when it was no longer being used?
Have you ever just wanted to make a temporary firewall change that expires after a certain amount of time, or at a certain time?
Have you wanted to make a simple change to the firewall rules and easily revert it, without logging in an editing a file?
Have you ever wanted to have a queue of the last N blocked hosts, so that you don’t end up with a ton of outdated perjorative rules?
Have you ever wanted to do all this with open-source software alone?
Do you want to avoid being bound to any particular firewall implementation?
Do you realize that a firewall configuration is a shared data structure, and that to have multiple clients attempting to modify it concurrently may require some effort to ensure consistency?
Have you ever wished that you could define the policy and allow changes within it, but not allow changes that violate it?
Once you’ve defined that, why not automate the repetitive rule changes?

3.3 Example Scenarios

A reactive firewall works anywhere you need to change the packet filter rules on a regular basis.

Here are some scenarios where manual firewall administrator intervention is often required and that DFD (with some supporting software) could eliminate from your list of tasks.

3.3.1 Protocols Incompatible with NAT

These require port forwarding, or DNAT. Search the Internet for “port forward” to find out how much time is wasted on this eminently trivial and uninteresting task.

IDENTD connections, like for connecting to IRC servers
peer-to-peer, including bittorrent
VoIP
streaming media
active-mode FTP (for clients), passive-mode FTP (for servers)
online games

See here for some details: http://www.subspacefield.org/~travis/firewalls_and_protocols.html

3.3.2 Active Security Response

Shunning
Transparent redirection to honeypot/honeynet

3.3.3 Unusual Network Communications

Port Knocking http://en.wikipedia.org/wiki/Port_knocking
Single Packet Authorization http://www.cipherdyne.org/fwknop/docs/SPA.html

Note that these communication mechanisms are just another way of communicating, so their primary benefit comes from them being somewhat unusual. In theory, they accept untrusted network input, and thus are just as vulnerable to exploitation, but in practice it seems unlikely to happen.

3.3.4 Temporary Changes to Firewall Rules

Turning off packet scrubbing to debug or troubleshoot
Allowing ICMP through during troubleshooting

3.3.5 Dynamic DNS Names

Usually DNS names only get resolved once (when the ruleset is loaded). By reloading or (equivalently) updating the rules periodically, you can incorporate dynamic DNS changes.

4 Related Work

4.1 Other Tools

fwknop (port knocking on firewalls using single-packet authentication) http://www.cipherdyne.org/fwknop/
PSAD (port scan auto-detector) http://www.cipherdyne.org/psad/
py-pf (python interface to pf) http://www.kernel-panic.it/software/py-pf/
snortsam (can respond to snort alerts using a “distributed blocking fabric”) http://www.snortsam.net/
IDR (can be used to block IPs close to source using BGP) https://datatracker.ietf.org/wg/idr/charter/
authpf (user shell for authenticating gateways) http://www.openbsd.org/faq/pf/authpf.html
UPnP (Microsoft-sponsored thing) http://www.upnp.org/
miniupnpd (F/LOSS port) http://miniupnp.free.fr/

4.2 On Combining Other Tools

Now some systems have idioms that make automated rule changes easy; in pf, you can use anchors, and in iptables you can use tables. Often you operate on an entire anchor or table at a time; you can load or unload them. With iptables, you can append to a table quite easily. But suppose you appended rule A to a table, and appended rule B to the table. Now you want to delete rule A, but not B. You can’t delete the first rule, because A may not have been the first. You can delete A if you remember the exact rule, but either way you’ve got to keep data elsewhere that refers to the rules in your tables to know which is which.

Now what happens if your system reboots? The packet filter is cleared, and that external data is no longer in sync with it. What you need is for the firewall rule state and the external data to persist in exactly the same way.

Now suppose you have such a system for managing the firewall rules and it responds to intrusions by shunning the attacker at the router for, say, 24 hours. Now suppose you also want to do portknocking, which also modifies firewall rules. But you can’t have two things attempting to control the firewall rules without them stomping on each other.

5 Issues with Automatic Rule Changes

5.1 Ruleset Size

If you keep adding rules, the ruleset can get unwieldy. That is, if you have to check every packet against a list of 10,000 machines you don’t want to accept packets from, you spend most of your time searching the list. There are a few things you can do about this problem.

5.1.1 Timeouts

For example, “this rule expires one day from now”. This is something that DFD supports - rules that die at certain times.

5.1.2 Fixed Maximum Size with Eviction Policy

Least Recently Used Eviction Policy

The last ten malicious hosts stay blocked (first in, first out - FIFO). This is supported by DFD.

Least Frequently Used Eviction Policy

The ten most malicious hosts (most frequent attackers) stay blocked.

5.1.3 Rule Aggregation

If you can collapse multiple rules into one, you do so.

5.2 Whitelists

Don’t want to block our default route, or root name servers, or close business partner, or CEO.

5.3 Discrimination

I mean this in the sense of “not all IPs are the same”. Might not want to block a IP used for dial-up as long as we block a permanent IP, in the interest of fairness, or pragmatism.

6 Proactive Rule Changes

So someone keeps hopping around in a class B; you can start to generalize. You can say, if fifty percent of a subnet is malicious, I’ll block the whole subnet. Or you can say, if someone attacks one of my systems, I’ll block them on all of my systems. Or you can say, if someone attacks my friend Bob, I’ll block that person too.

7 Tricks

Can emulate stateful filtering on stateless filters, if we’re fast enough; just watch outbound packets and adjust rules to allow return traffic back in. DFD can level the playing field in the sense that a firewall without special dynamic features can effectively simulate them, so variations in firewall capabilities are not as important.

8 FAQs

8.1 Hey, you use netcat in your examples; isn’t that totally lacking in security?

You’ll note in all the example transcripts, DFD is bound to localhost, and that’s on a firewall machine where only I have access.

8.2 But what if you want another system to be able to access this daemon?

I assume that, if you’re looking at this program, you already understand what a firewall does. Hint: network access control.

8.3 Oh, I get it. But for something this important, should you really trust IP addresses and ports?

You’re right, for high security, you can’t rely on network addresses (“somewhere you can be reached”) for authentication. Ultimately, they’ll either be secured with cryptography, or not thought of as anything but a “low hanging fruit” security mechanism. But that doesn’t mean packet filters aren’t useful; they can serve to make attacks more difficult or more costly than they are worth.

In the mean time (that is, until we secure all the infrastructure and rewrite all our software), there’s another solution that’s pretty obvious; use SSH, SSL, IPSec, or another VPN to cryptographically restrict access to a service.

8.4 But wouldn’t it be better for everything implement its own security at the application layer?

Perhaps. I’m considering adding SSL into the server, but right now it’s not a high priority. It would add complexity to the code, and make writing clients a bit harder, and introduce key management into the mix, which makes it more complex. But it might be right for access control and authorization (see later), where a key maps to certain access rights.

8.5 Can’t commercial product X already do (something)?

Yes, commercial products can probably do something, otherwise who would buy them? ;-)

Seriously though; “don’t know, don’t care”.

8.6 Can’t F/LOSS product X do (something)?

So far, all I’ve seen are point solutions that don’t interoperate well, and often don’t persist their state across reboots.

But if you know of a related tool I haven’t listed here, please email me a link.

8.7 Wouldn’t it be useful to have some authentication, access control or authorization for different clients/commands?

Yes, it most definitely would. I’m thinking about how best to do this.

8.8 How long has DFD been in development/use?

I started dfd_keeper in 2005, and it has been in continuous use ever since. dfd_tbk actually predates that. The underlying firewalls have become significantly more sophisticated since then, incorporating some things that DFD did, and this, in my mind, merely validates the concept.

8.9 How many people use DFD?

Either I don’t seem to be able to communicate the idea very well, or I’m the only person in the universe who cares.

8.10 Why do you write about rules when you should really be concerned with sets of IP addresses?

That’s an excellent point. I wrote this (tool and description) when lists, tables, and so on were relatively new, so it seemed natural to talk of adding and deleting rules. Perhaps makes sense to think of the ruleset as static, and only the sets of IP addresses as changing. I will reflect on this deeply.

8.11 Why isn’t it sufficient to immediately block a detected adversary, like an IPS?

It lacks subtlety.

8.12 I don’t understand.

You’re not alone. However, you didn’t phrase this in the form of a question.

8.13 Where do I get more information?

The Bridge Keeper page is very detailed, and the next best thing to browsing the code, which is actually very small (about 1500 SLOC) and well-commented.

8.14 Where is a sample transcript?

See the end of The Bridge Keeper’s page (http://www.subspacefield.org/security/dfd_keeper/) for the best example.

9 Software

9.1 DFD Implementations

The Bridge Keeper (http://www.subspacefield.org/security/dfd_keeper/) - python/pf implementation
The Black Knight (http://www.subspacefield.org/security/dfd_tbk/) - python/iptables implementation

The Black Knight needs a new owner since I don’t use it any more. Email me if you’re interested in taking it over and sharing ideas.

9.2 Related Software

Related OpenBSD packages http://www.subspacefield.org/~travis/OpenBSD/

10 Mailing List

http://lists.bitrot.info/mailman/listinfo/dfd