DansGuardian Documentation Wiki

You are here: Main Index » preventing_skipping_around


Wiki Information

Prevent Circumventing the Filter

Both configuration families of DansGuardian (“transparent-intercepting” and “explicit-proxy”) can easily be set up so it's impossible for users to skip around them. But eliminating skipping may not be automatic in either case, and some instructions are a little misleading about configuring a DansGuardian system so it can't be skipped.

Users may either skip around your whole DansGuardian system entirely, or they may skip around the first half and access your back-end proxy directly. We call both by the same name -“skipping”- and discuss how to stop both of them at the same time.

(Some distributions may do additional under-the-covers configuration when you activate DansGuardian so it appears preventing skipping around is tied to “transparent-intercepting” configurations. Also, the fact that “transparent-intercepting” configurations sometimes prevent skipping around as a side effect leads to the misconclusion “transparent-intercepting” is required to prevent skipping around, something that is not true.)

(Of course, preventing skipping is only the first step in shutting down flouting of web restrictions. Even after skipping is prevented, an end user may still be able to connect right through DansGuardian to an external proxy site and hop onward to a restricted site, or to avoid web ports completely with some anonymizer tools. But until you first prevent skipping, none of your other restrictions will have hardly any effect because users will be able to so simply and easily avoid them.)

Closely Related Goals

The same techniques used to prevent circumventing the filter are often also used for one or more of these closely related goals:

  • stop circumvention attempts by trapping the traffic (in more detail, this may mean either of the following)
    • simply block the circumvention attempts so the only way to send traffic is through the filter
    • trap circumvention attempts and toss the network traffic back into the filtered web stream
  • provide seamless fully automatic web access even for new users or new computers, with no configuration changes at all
  • trap direct web access attempts (both circumvention attempts and new computers), and instead of the requested webpage display a detailed message (typically one or more of the following)
    • welcome to new users
    • explanation of what is filtered and why
    • Acceptable Use Policy (AUP)
    • self-help directions for configuring each browser to access the web from this network

The “transparent-intercepting” family of configurations especially can lead to confusion, because they not only have the side effect of preventing circumventing the filter but often also fulfill the first two closely related goals above. The mistaken common wisdom that the “explicit-proxy” family of configurations can't do these things well can in fact be mitigated by a simple Network Billboard.

Warning: Not Until It Works

Do not implement non-skipping measures until your DansGuardian is installed and working. These measures do more than just prevent illicit use; they also interfere with several useful troubleshooting techniques.

Implement these measures after filtered web access is working for everyone.

Howto Summary

To eliminate any possibility of skipping, you need to do two things:

  1. Keep users from sending any web traffic through the “standard” web ports (ports 80 and 443).
  2. Ensure the connection between DansGuardian and its back-end proxy is not available to users.

Howto Details

This description of how to prevent skipping of DansGuardian is generic to any Linux-based system with IPtables. But for convenience and brevity, these examples refer to a specific configuration. Here we assume DansGuardian is using 'squid' for its back-end proxy. Here we assume use of the ShoreWall front end to IPtables rather than direct manipulation with the IPtables commands (and further that the firewall areas are called “loc” [interface to your LAN] “fw” [the computer itself] and “net” [interface to you Internet drop]). FIXME Please expand these instructions with details for a) those that build on the IPtables configuration built into their distribution and b) those that craft individual IPtables commands. Here we assume the DansGuardian input port is 8080 and the Squid input port is 3128 (beware: once in a great while the ports are reversed). And here we assume DansGuardian and Squid are running on the main firewall computer rather than elsewhere.

With the transparent-intercepting configuration family, you need to “intercept” all the web traffic from the normal web port and shunt it into DansGuardian. As a side effect of doing this, you'll also keep users from directly accessing a website over the standard port (in other words you'll satisfy number one). You'll need an IPtables instruction to grab all traffic that comes in to port 80 from your workstations and redirect it to the DansGuardian input port (in ShoreWall syntax: “REDIRECT  loc  8080  tcp  80”. With the explicit-proxy configuration family, you need to “block” all the web traffic coming into the normal web ports (“REJECT  loc  net  tcp  80” and “REJECT  loc  net  tcp  443), since all legitimate traffic appears directly on port 8080. (A ”Network Billboard” (or a web server running for some other reason) will replace these rules. One of its side effects will be to prevent skipping around, so there still won't be any problem.) For both configuration families you'll need IPtables (or something similar), although only for one or a few settings. (You may notice that the IPtables rules for the two configuration families are pretty similar.)

Depending on the specifics of your system and of your firewall policy, you might also need to explicitly allow traffic from DansGuardian into the Squid input port (“ACCEPT fw fw tcp 3128”), and maybe even explicitly allow traffic into the DansGuardian input port (“ACCEPT loc fw tcp 8080”). Usually these things already happen by default or policy, and no explicit setting is needed. (In any case you should not explicitly allow traffic from an arbitrary workstation into the Squid input port [don't “ACCEPT loc fw tcp 3128”] in a production environment.)

To do the second thing, simply make the back-end proxy available only to other software running on the same machine. The best way to do this is probably not with IPtables but rather with the configuration of the back-end proxy itself. All you need to do is configure the communication between DansGuardian and your back-end proxy to use only the local computer rather than any global IP address (specifically, in squid.conf: http_port, and in dansguardian.conf: proxyip = [and proxyport = 3128]).

Once you've done both things, your users won't be able to skip around your DansGuardian system.

(You could prevent skipping around an “explicit-proxy” configuration without using IPtables at all simply by turning off ip-forwarding in your kernel and making the back-end proxy available only to other software running on the same machine per the directions above. But doing so would affect all traffic to the Internet, not just web traffic, which is inappropriate in most situations.)