Filter Configuration

The Redwood filter engine can be configured in various ways via the available Settings and Parameters. These settings apply system-wide, and not customizable per individual Devices, ACLs, or Groups.

Filter Settings may only be defined one time, while Parameters be defined multiple times, and are cumulatively collected when Redwood parses the configuration at run time.


The minimum total score from a blocked category needed to block a page

threshold 275

Log Files

Redwood has several categories of messages that can be logged.

The access log has a line for each request processed. It is in CSV format and goes to standard output by default. The access log has the following fields:

log-title True
log-user-agent True

The content length is meaningful only if a phrase scan was performed. The page title is available only if a phrase scan was performed and log-title was enabled in the configuration.

The TLS log has a line for each HTTPS connection that was intercepted. The TLS log has the following fields:


Redwood can be configured (using the ssl-bump ACL action) to perform Man-in-the-Middle filtering of HTTPS traffic. This feature is called SSLBump after the corresponding feature in Squid.

For SSLBump to work, Redwood must be configured with a root certificate that is trusted by the users’ browsers. Paths to the certificate and its private key are specified with the tls-cert and tls-key options. The certificate and key should be in PEM format.

tls-cert /path/to/cert.pem
tls-key /path/to/key.key

Redwood uses the system root certificates to verify the identity of the sites it bumps. Other trusted root certificates can be specified with the trusted-root option.

trusted-root /path/to/trusted/cert.pem

The SSLBump feature only works with SSL version 3 and newer (including all TLS versions). By default, earlier versions are passed through unfiltered. It can be configured to block them instead with the block-obsolete-ssl option.

block-obsolete-ssl True

Transparent Proxy

With the proper firewall setup, Redwood can transparently intercept connections to web servers and filter them without needing to configure proxy settings on the client computers. Intercepted HTTP connections can use the same proxy port as is used for manually-configured proxy connections. For HTTPS connections, Redwood must be configured to listen for intercepted connections on a separate port, with the transparent-https directive.

The following configuration lines will set Redwood to listen on ports 6502 and 6510:

http-proxy :6502
transparent-https :6510

If Redwood is running on a Linux gateway/router system, the following iptables rules will enable transparent filtering for the computers on the LAN (assuming that the LAN interface is eth1):

iptables -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-ports 6502
iptables -A PREROUTING -i eth1 -p tcp --dport 443 -j REDIRECT --to-ports 6510

To do the same thing with pf on a FreeBSD gateway (assuming that the LAN interface is re0):

table  { re0:network }
rdr pass inet proto tcp from  to any port 80 -> re0 port 6502
rdr pass inet proto tcp from  to any port 443 -> re0 port 6510

Classification Service

In addition to running as a proxy, Redwood can also be used as a URL classification service. It receives an HTTP request specifying a URL, and returns a JSON object that tells what categories it was classifed in, and the score for each category.

Categories can be excluded from the classification reports:

classifier-ignore sslbump
classifier-ignore masterwhitelist

The classification request must have the URL as an HTTP form parameter named "url." The JSON object in the response has the following keys:

For example, if Redwood is running on port 6502 on, might return {"url":"","categories":{"computer":266}}.

It can also classify text directly. might return {"text":"programming language","categories":{"computer":27}}.