NetReg Proxy HOWTO

As part of the NetReg network registration process, you may wish to scan computers for vulnerabilities and have patches applied accordingly. Distributing CDs with patches is not a particularly good solution, nor is enabling the vulnerable systems to have full network/Internet access to download patches. A better solution is for not-yet-registered systems to have access only to the relevant patches.

To accomplish this goal, I've used BIND (DNS) and squid (web proxy). This HOWTO is provided to help others implement similar setups. These notes are for Debian GNU/LINUX 3.0 with a 2.4 kernel using bind9 (9.2.1-2.woody) and squid (2.46.6-2woody2). Other Linux/Unix flavors should be similar. The NetReg version shouldn't matter; I'm using CMU NetReg.

In all examples, the NetReg web server, proxy server, and bogus DNS server is ( The real DNS servers are and Unregistered computers have IPs in the network.

Allowed Zones/Sites

In addition to having access to the NetReg web server, I have found it useful for unregistered machines to have access to the following zones:

The list of zones is subject to change. For a list of zones needed for Windows Update, see (mirror) and


BIND must be configured so that hostnames in these domains resolve to their correct IPs while all other hostnames resolve to the IP of the NetReg web server.

Each allowed zone should have a stanza in named.conf of the form:

  zone "zonename" {
    type forward;
    forwarders {;; };
    forward only;

The final stanza of named.conf should be something like:

  zone "." {
    type master;
    file "db.wildcard";

Also make sure that (at least) the following options are set in named.conf:

  allow-query {; };   
  allow-recursion {; }; 

The zone file for . (db.wildcard) needs to have NS records for each allowed domain and a wildcard A record. For example:

  @			IN NS
  allowed.domain1	IN NS
  allowed.domain2	IN NS
  *.			IN A

Check the syntax with named-checkconf and named-checkzone and restart bind (/etc/init.d bind9 restart in Debian).

See also:


Note: Recent versions of WindowsUpdate require https (port 443). By design, squid will not proxy https. In other words, if your goal is to get WindowsUpdate working, you will be very disappointed.

A number of changes need to be made to /etc/squid.conf. These include disabling caching, defining and applying access controls (ACLs), and httpd accelerator options for transparent proxying.


  acl all src 0/0
  acl unregistered src 
  acl alloweddomains dstdomain .some.domain .another.domain
  http_access allow unregistered alloweddomains
  http_access deny unregistered
  deny_info ERR_NR_REDIRECT unregistered
  http_access deny all

Disable caching (optional):

  no_cache deny all

httpd accelerator:

  httpd_accel_host virtual
  httpd_accel_uses_host_header on

Then edit a custom error page (ERR_NR_REDIRECT) which will redirect to the registration page. (In Debian the error files are in /usr/lib/squid/errors/English/.)

  <META HTTP-EQUIV="refresh" CONTENT="1;URL=">

Start squid (/etc/init.d/squid restart in Debian).

See also:


For Linux 2.4 kernels, the following kernel options must be enabled:

  Networking Options -> 
    Network packet filtering
    IP: Netfilter Configuration ->
      Connection tracking   
      IP tables support
      Full NAT
      REDIRECT targe support

And the iptables rule to enable transparent proxying:

  iptables -t nat -A PREROUTING -i eth0 -d !
      -p tcp -m tcp --dport 80 -j REDIRECT --to-port 3128

Make sure this rule is applied on boot. (In Debian, run iptables-save > /etc/iptables and then add the line up iptables -F; iptables-restore < /etc/iptables || true to the 'iface eth0' stanza in /etc/network/interfaces.)

See also:

Questions or comments? Email me at

(Last updated June 2005)