PK D@}Z% % tollgate-3.0.1/credits.html
Website (for email contact): http://micolous.id.au/
Started the project, wrote almost everything.
tollgate is a captive portal system for Linux.
You can find out more at the website or the GitHub project.
Contents:
Add the tollgate repository, or grab the rpms manually.
You can install the tollgate repository by running:
yum localinstall --nogpgcheck 'http://repo.tollgate.org.au/pub/fedora/tollgate-repo.noarch.rpm'
Install tollgate by running:
yum install tollgate
Make sure your networking is set to start on boot.:
systemctl enable network.service
systemctl start network.service
We need to allow certain traffic into our system. This should be configured by iptables. An example set of rules can be found in example/fedora/iptables and should be placed into /etc/sysconfig/iptables. Once you have configured these rules, reload iptables with:
systemctl restart iptables.service
We can setup the network either with DNSMASQ or ISC-DHCP and BIND9. This will document how to install ISC-DHCP and BIND9.
Install the packages:
yum install dhcp bind bind-utils
Setup your LAN facing network device with a static IP address. There is an example of this in example/fedora/ifcfg-lan, and the file you want to edit will be /etc/sysconfig/network-scripts/ifcfg-DEVICENAME.
Additionally, ensure that your internet facing device is set to ONBOOT="yes"
Once configured run.:
ifup DEVICENAME
Next, we setup ISC-DHCP. This will provide DHCP addresses to your LAN network. Make sure you get this right, else you will have a DHCP conflict on your Internet side. There is an example config in example/fedora/dhcpd.conf.
Before you can start DHCP, you must create the rndc key that will be shared with named. Run the command:
rndc-confgen -a -r keyboard -b 256
chown named:named /etc/rndc.key
Now ISC-DHCP can be started:
systemctl enable dhcpd.service
systemctl start dhcpd.service
Check systemctl status dhcpd.service and /var/log/messages if you encounter issues.
Next named.conf needs to be configured. There is an example of this in example/fedora/named.conf. This is a modification of the default named.conf.
Additionally, you must configure the forwards and reverse zones to match for ISC-DHCP. There are example zones in example/fedora/named/. These should go into /var/named/dynamic/.
Please note, we have provided a zone for conntest.nintendowifi.net. This is also aided by a component in HTTPD (Documented later). This is to allow the Nintendo DS, Nintendo DSi and Nintendo Wii wireless connection test to complete, so that the Access point can be associated with. If this is not avaliable, Nintendo devices will be unable to join the wireless access point.
Now BIND9 is picky about permissions, but afterwards, can be started:
chown named:named /etc/named.conf
chown named:named /var/named/dynamic/*
systemctl enable named.service
systemctl start named.service
You can check that bind it working from the server, by running a query against localhost. In this case, we also try zone transfers (axfr):
dig @127.0.0.1 example.lan A
dig @127.0.0.1 example.lan axfr
dig @127.0.0.1 dhcp.example.lan axfr
dig @127.0.0.1 1.0.4.10.in-addr.arpa PTR
dig @127.0.0.1 0.4.10.in-addr.arpa axfr
dig @127.0.0.1 conntest.nintendowifi.net A
From a client connected to the LAN side, you should NOT be able to carry out a zone transfer, but you should see the A and PTR records returned:
dig @10.4.0.1 1.0.4.10.in-addr.arpa PTR
dig @10.4.0.1 tollgate.example.lan. A
dig @10.4.0.1 conntest.nintendowifi.net A
dig @10.4.0.1 example.lan axfr
When a client connects you should see messages in /var/log/messages like:
tollgate dhcpd: DHCPREQUEST for 10.4.0.10 from 00:00:00:00:00:00 (Franky) via p1p1
tollgate dhcpd: DHCPACK on 10.4.0.10 to 00:00:00:00:00:00 (Franky) via p1p1
tollgate dhcpd: Added new forward map from Franky.dhcp.example.lan. to 10.4.0.10
tollgate dhcpd: Added reverse map from 10.0.4.10.in-addr.arpa. to Franky.dhcp.example.lan.
If you see messages like:
tollgate dhcpd: Unable to add forward map from Franky.dhcp.example.lan. to 10.4.0.10: not found
Then you have made a mistake somewhere. Check that the rndc-key permissions are set to named:named, that dhcpd and named have been reloaded, that you have the correct control statements in named.conf and that in dhcpd.conf you have the primary option either as an ip or a resolvable hostname - We recommend this be the same as the IP in the named.conf control statement.
Django supports a number of SQL servers for it’s operation. We have extensively tested MariaDB (Formerly MySQL) with Tollgate. However, PostgreSQL and SQLite are also valid options.
We have extensively tested Tollgate with MySQL and MariaDB. Additionally, they support replication features which allows for retrospective conversion to a clustered setup.
First install the mysql packages.:
yum install MySQL-python mysql-server mysql
Now you need to setup the database. We advise you to remove the anonymous users and test tables, as well as setting a strong root password.:
systemctl start mysqld.service
mysql_secure_installation
Now we need to login to mysql, to create the database and tollgate user.:
mysql -u root -p
mysql> create database tollgate;
mysql> create user 'tollgate'@'localhost' identified by 'password';
mysql> grant all privileges on tollgate.* to 'tollgate'@'localhost';
mysql> flush privileges;
Keep these details for when you configure the settings.py - You will need to remember the USER, NAME and PASSWORD. The HOST setting will be localhost.
Apache HTTPD is what provides the majority of Tollgate functionality. We highly recommend that you install mod_ssl, mod_nss or mod_gnutls, since tollgate requires user authentication’s to be sent via the HTTP channels. Our examples below will cover the usage of mod_ssl.
We create certificates for use with Tollgate.:
cd /etc/pki/tls/private/
openssl genrsa -out tollgate.key 2048
openssl req -new -key tollgate.key -out tollgate.csr
It is CRUCIAL at this step, that when asked, you put in your servers hostname in the Common Name field.:
Common Name (eg, your name or your server's hostname) []: tollgate.example.lan
Either you can send this CSR to be signed by another CA, or you can self sign. Either way, your resultant certificate should be tollgate.crt. Below is how you self sign your certificate:
openssl x509 -req -in tollgate.csr -days 365 -signkey tollgate.key -out tollgate.crt
Now you should reconfigure the ServerName and ServerAlias parameters in /etc/httpd/conf.d/tollgate.conf. Please note the VirtualHost for conntest.nintendo.net. Do not modify this VirtualHost.
Next you must edit /var/www/tollgate/tollgate_site/settings.py. Fill in the DATABASE section with your SQL server information. Finally, at the bottom of the settings.py fill in your LAN details as needed. Check to make sure all values seem sane for your environment.
Additionally, you should configure the SOURCE_URL parameter to ensure that you uphoad your AGPL obligations. If you DO NOT modify the tollgate source code (With the sole exception of the configuration files) this obligation can be met by sharing the source RPMs to the package. The source url parameter you can use is SOURCE_URL='https://tollgate.example.lan/source/' To retrieve these, run the following commands. The HTTPD configuration doesn’t need alteration to support this configuration.:
yum install yum-utils
yumdownloader --source tollgate --destdir /var/www/tollgate/source
NOTE: If you are using mysql, you must add to your settings.py USE_TZ = False
Finally, we need to sync the database, and collect the static components ready for deployment.:
cd /var/www/tollgate/tollgate_site
python manage.py syncdb --noinput
python manage.py migrate --noinput
python manage.py collectstatic --noinput
python manage.py createsuperuser
If you are running on MySQL or MariaDB, you will also need to patch the tables that Django has generated to allow big quota usage values, otherwise it will stop counting at 4GB:
python manage.py mysql_bigint_patch
Now you should start httpd.:
systemctl enable httpd.service
systemctl start httpd.service
You should configure /etc/tollgate/backend.ini with your site details. Additionally, you should configure /etc/sysconfig/tollgate with the correct DNS name of your tollgate.
You can now start the tollgate backends.:
systemctl enable tollgate-backend.service
systemctl enable tollgate-captivity.service
systemctl start tollgate-backend.service
systemctl start tollgate-captivity.service
All releases in the 3.x series are named after types of toothpaste.
This is the first point release, intended for some bug fixing.
This represents the first public stable release of tollgate (formerly portal2). Changes from 2.8.3 (September 2010):
These are changes which happened before the public source release of tollgate, when the project was still named “portal2”.
First versions 2.0 - 2.2 were from October - December 2008. These were often pulled shortly after the start of the LAN due to bugs. It was later found that many of these problems were related to faulty networking equipment. The equipment has since been replaced.
The system was implemented due to issues with the previous WiFiDog-based setup (GLaDOS).
Tasks that I’ve got in mind at the moment:
I’ve started implementing IPv6 support in the backend of tollgate in a seperate branch. At the moment it’s got some basic backend support but I haven’t implemented the frontend code just yet (or the scanning module for ipv6). There’s some stuff to consider though:
This is a fairly general task, anyone can pick this up. Particularly a step-by-step installation guide would be helpful, or some sort of bootstrap script so you can put that on a system, it pulls deps and then the git repo.
This has been now started in the form of the tollgatebuilder project: https://github.com/micolous/tollgatebuilder
There’s no test cases, we probably should have some.
Started an Esperanto translation of the project a while ago, haven’t really touched it since. Many strings aren’t in the translation files, and the setup of where the strings actually are could be improved a lot, because it’s a mess.
I’d like to see this software ported to non-Linux systems. I’ve done some preliminary research that’s come up empty as yet as to operating systems with firewalls that meet all of the following requirements for tollgate’s backend to work properly.
The majority of the work you’d need to do in porting the software is in the backend. There’s a little bit of Linux-specific frontend code to print out the contents of the ARP table. All the backend is setup in a way that it calls from the frontend are abstracted away from iptables.
Before you start work porting it to a new operating system, please consider the following list of requirements. If you can’t get it to do everything in this list, then tollgate won’t work.
TODO: Finish writing this.
This is how a packet is handled inside tollgate when running on Linux.
Port forwarding doesn’t work correctly when the internal and external ports are different.
There’s no way to deregister a console from an account that hasn’t signed in to the current event. (ie: Previous event the console is marked as being owned by user X, next event user Y can’t sign it in because user X hasn’t attended)
Please activate JavaScript to enable the search functionality.
From here you can search these documents. Enter your search words into the box below and click "search". Note that the search function will automatically search for all of the words. Pages containing fewer words won't appear in the result list.
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.
A full copy of the license is available in the file /LICENSE.
Please be specifically aware of Section 13 “Remote Network Interaction; Use with the GNU General Public License.” This requires you to make modifications to this software available to network users. The easiest way you can do this is by making a publicly available Git repository for your users. (GitHub has a nice ‘fork’ option, which makes it easy for me to track this stuff...)
A notice will appear on all pages unless you set the SOURCE_URL setting to a location where the source code is stored. This is enforced as some members of the LAN community in my experience are “lax” about following licensing obligations. Removing the code that enforces this does not exempt you from the agreement - it is only there as a reminder and to assist you in license compliance.
Pushing your changes upstream is a great thing to do – it not only assists other users of the software, but also assists you as internally-developed features don’t have to be patched in every time there is a new release.
This software uses flot, a jQuery library for generating charts, copyright 2007-2009 IOLA and Ole Laursen. It’s terms are as follows:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
flot itself also includes:
Welcome to tollgate. This is a captive portal system for Linux, designed for operating LAN parties. A lot of the concepts in the software are specific to how a LAN party operates, however you could use it for a sharehouse if you wanted, or something else.
It consists of two parts, connected via dbus:
It’s important to note that tollgate only manages routing on your network. A typical network will also need a DHCP server and DNS. tollgate simply sets up NAT for you, and manages client access to the internet.
tollgate is a little bit different to most captive portal solutions because it doesn’t use RADIUS at all. It is entirely managed within your database, which can run on anything Django can such MySQL or SQLite.
tollgate will only run on Linux. You do not need to have your DHCP or DNS servers on the same machine (though is it recommended).
tollgate has some limited support for running the frontend, for development purposes, on Mac OS X and Windows. However, the backend will not work on these systems.
At the time of writing, your author is not aware of any other operating system that supports the needed functionality to make the system work. See Porting to non-Linux systems.
The following packages must be installed:
Python 2.5 or later
Django 1.2 or later, as well as a supported database (such as MySQL or SQLite3).
WSGI-compliant web server, such as apache2. It is strongly recommended that you run the site using HTTPS only, so you will also need mod_ssl.
Linux 2.6.28 or later with netfilter (most distributions ship with this).
iptables 1.4.3 or later.
xtables-addons 1.22 or later.
dbus
django-south
djangorestframework
nmap
python-dbus
python-iplib or python-ipy
python-lxml
python-simplejson (if using Python 2.5)
python-tz
Optional dependencies:
tollgate should allow any client with an IPv4 stack and a web browser to work with it. The software has been tested with (but support is not limited to):
Because the software is designed for running LAN Parties, it also has support for gaming consoles, including those without web browsers, such as:
tollgate allows you to claim ownership of another device remotely, so if the device does not have a web browser, you can use this to login the device from something else.
Footnotes
[1] | (1, 2, 3, 4) This platform is untested, however should work. |
[2] | (1, 2) Platform lacks a web browser, so requires you to login from another device which does. |
[3] | (1, 2, 3) Platform has a web browser application which isn’t installed by default or requires purchase. The web browser is not required, but will require you login with another device which has a web browser if you don’t. |
[4] | (1, 2, 3) Platform does not come with an in-built ethernet or wireless adapter as standard. |
The “proper” way to deploy tollgate is to install the software (using setup.py), and then create a Django project with tollgate setup inside of it.
This is achieveable fairly simply, however be aware that tollgate only manages routing, it does not manage things like DNS and DHCP which you’ll need to make your network actually accept clients.
This has the advantage of allowing you to easily customise configuration and templates. Be aware though that all modifications to tollgate must be made available, as well as the software itself, to all of your users, as a condition of the license.
I’m assuming here that you have:
Installation and configuration of those is outside of the scope of this document. If you’re looking up HOWTO documents on the internet, do not do anything with iptables, as setting up a NAT and routing itself is part of tollgate.
Install tollgate, either using an official stable build, git repository, or distribution package. You can install the latest master version of tollgate using pip with this command:
$ sudo pip install git+https://github.com/micolous/tollgate.git
This may not work though, as the state of git master may be in flux.
This will install the entire tollgate package into your Python path, and install the captivity and backend daemons.
We need to add some configuration files for tollgate to DBUS’ configuration in order to allow the web server process to use tollgate’s backend.
In docs/example/dbus/system.d/tollgate.conf are some example configuration you can use with tollgate. Copy this to /etc/dbus-1/system.d/, and modify with the appropriate username that the webserver uses (if it is not www-data).
Then reload the DBUS configuration with /etc/init.d/dbus reload.
Now, you should create a Django project for tollgate to use. This won’t have any of tollgate’s code in this folder – it will reference a the system-installed copy.
$ django-admin startproject mylanportal
This will create some boilerplate code for a Django site. Currently, tollgate doesn’t support not being at the root of the site, but this may change in the future.
From here on in, I’m going to assume your project name is mylanportal.
Jump into the mylanportal/mylanportal/urls.py. Change it so it includes tollgate.urls. tollgate.urls will also give you the Django admin site, and the internationalisation configuration app. It should look something like this:
from django.conf.urls.defaults import patterns, include, url
urlpatterns = patterns('',
(r'^', include('tollgate.urls')),
)
The next step is to setup settings.py.
Near the top, add these lines:
from os.path import *
PROJECT_PATH = realpath(dirname(__file__))
This is a handy trick because you can use it to setup other paths later.
Setup the location of the database. It is recommended you use MariaDB (MySQL).
You should also setup a STATIC_ROOT for where all the static files should be served from, and a STATIC_URL. Be aware that if you are deploying on a HTTPS site (which you should!) you need to make your resources also be on a HTTPS site. The purpose of this is that outside of DEBUG mode, you’re expected to serve static files external to Django – as it is much faster.
To your INSTALLED_APPS, append:
'django.contrib.humanize',
'django.contrib.admin',
'djangorestframework',
'south',
'tollgate.api',
'tollgate.frontend',
'tollgate.scripts'
You should also add the following extra settings for tollgate and configure appropriately:
AUTH_PROFILE_MODULE = 'frontend.userprofile'
LAN_SUBNET='10.4.0.0/23'
LAN_IFACE='eth1'
DEFAULT_QUOTA_AMOUNT=150
RESET_EXCUSE_REQUIRED=True
RESET_PURCHASE=False
ONLY_CONSOLE=False
RESTRICTED_CALLS_KEY=''
LOGIN_URL='/login/'
LOGOUT_URL='/logout/'
The final setting to add is a URL where you are hosting the tollgate sources with your modifications, SOURCE_URL. You should never link back to the official tollgate repository using this method (there is already a link to the official repo on the source page).
Not hosting the source code yourself may expose you to legal liability.
Install the init scripts and backend configuration:
$ sudo cp platform/debian/init.d/* /etc/init.d/
$ sudo cp platform/debian/default/* /etc/default/
$ sudo mkdir /etc/tollgate/
$ sudo cp docs/example/tollgate/backend.ini /etc/tollgate/
Modify the scripts (tollgate-backend and tollgate-captivity) as appropriate to match the path to the tollgate_backend and tollgate_captivity scripts.
Edit /etc/default/tollgate-captivity to point to the URL where tollgate is hosted.
To make the daemons start, run:
$ sudo update-rc.d tollgate-backend defaults
$ sudo update-rc.d tollgate-captivity defaults
Modify the backend configuration as appropriate for your network (/etc/tollgate/backend.ini).
We won’t start the daemons just yet, though.
tollgate requires a periodic cronjob to refresh the list of hosts in it’s database.
An example configuration is given in docs/example/tollgate.cron. You will need to adapt it to point to the path of your Django project.
You’ll need to now configure your web server.
If you are using Django 1.3 or earlier, you may wish to copy tollgate/tollgate.wsgi and use it in your own project folder. However, be sure to change the DJANGO_SETTINGS_MODULE to the name of your project (eg: mylanportal.settings), as tollgate itself includes a tollgate.settings for use in development deployment.
In Django 1.4 or later, it will create a file named like mylanportal/wsgi.py with settings that you should use instead.
There is an example apache2 configuration, including all vhosts, in docs/example/apache2/tollgate-vhost.
You will need to modify the path of static items (like the WPAD and WFC vhosts, and aliases for static files) to the appropriate locations, and URLs.
Included in the examples is how to configure a gitweb instance. You could also push code changes to an external repository, however it must be accessible to users at all times (ie: you should mark it as “unmetered”).
The first time you run you’ll need to manually start the daemons. They will start automatically on next boot.
In development, you can run and deploy tollgate from within a git clone of the repository. This is the “old” way of deploying tollgate in production, and has since been superceeded.
You can run tollgate in development either out of a WSGI-compatible webserver, or using Django’s single-threaded development server.
tollgate can run in a clustered configuration with CARP (Common Address Redundancy Protocol). You’ll need to also set up redundant DHCP, DNS and database (eg: multi-master MySQL, or a single external database server) for this to work.
tollgate’s quota saving procedures are written in such a way that it will work with multiple copies of tollgate simultaneously. No special configuration of tollgate is required in order for it to work (apart from possibly changing database settings).
However, there is a window (between refresh_hosts calls, normally every 10 minutes) where you can use all of your quota via one tollgate and still have it available on the other, because the counters aren’t synchronised live (and doing so is quite expensive).
In typical deployments however I haven’t had this as a real problem, as it hasn’t been possible to use more than 50% of the allocated quota in 10 minutes. Doing so would require quite fast internet access, and you’re generally competing for that resource with other clients on the network.
Be sure when configuring your network infrastructure for redundancy that:
At the moment, tollgate doesn’t support running multiple instances of itself managing different subnets. That’s a plan for down the track.
You may encounter performance issues and hosts dropping out “randomly” when running the software on subnets larger than a /24. This is because of the size of the ARP table in Linux is effectively limited to 128 hosts, and the software will automatically send large amounts of ARP requests to see who currently holds each IP address on the network.
It is at this point you should seriously consider the size of your subnet. If you have less than 200 hosts on your network, then you really only need a /24. If you have a proper network plan in place, with DNS and static DHCP entries setup, you can still segment your network a lot more tightly. You can use hostnames to provide memorable names to services, rather than wanting 10.0.13.37 when all your other hosts are in 10.0.1.0/24.
When you’re planning for a LAN party, I generally do the math based on:
hosts = (maximum_attendance * 2) + static_hosts
You should only be using a /16 if you’re expecting in excess of 30,000 people attending your LAN. And even then you should consider slicing it up into subnets, because most operating systems have an ARP cache limit of about 1024 hosts, and you’ll have problems with broadcast packets. Even something as simple as a Master Browser Election could knock out your network (though you should be Using WINS at this point).
With dynamic DNS assignments by DHCP and routing in place, you can even keep it so that hostnames across subnets can still talk to each other by name. Without this, you’ll end up with a lot of “noise” on your network from all sorts of multicast protocols.
At this point of time though, you’ll need to setup multiple copies of tollgate: one to service each network. However, each instance should be able to share a single database provided the IP addresses are unique.
There are, of course, some applications and games which simply won’t work because they require multicast or link-local packets. But it is also those games which become increasingly unreliable on large networks.
You can tweak the behaviour of the ARP cache on Linux to let you have a bigger ARP table. But this comes at a price – it uses more memory, and the cron job for tollgate’s refresh process will take much longer.
Linux provides three settings in /proc/sys/net/ipv4/neigh/default/:
You should keep those ratios if you adjust it, but gc_thresh needs to be able to handle the base amount of hosts on your network.
tollgate-backend will automatically set this for you if you set the arp_table_size option in backend.ini.
This will automatically set all three garbage collector thresholds appropriately according to the ratios above.
You absolutely require this value to be set to the number of hosts in your subnet, with a little bit of leeway for your WAN ethernet interface. Which means if you have a /23 (512 IPs) on your LAN side, and about 10 machines on your WAN side, you should set the value to about 530 (enough for both sides with some leeway):
arp_table_size = 530
If you set it to exactly 512, then the non-result ARP table entries will push out legitimate ones, and also entries from your WAN side will push out entries from your LAN size.
There is an issue where Django will not create a big enough field type for PositiveIntegerFields, resulting in data collection failing when there has been more than 4GB used, or if more than 4GB is allocated to a user.
You can patch the tables with this command on your deployed project:
python manage.py mysql_bigint_patch
While this isn’t a core issue inside of tollgate, there’s a pretty strong chance when running LAN Party events that you will have a large amount of Microsoft Windows hosts.
There are many things that Windows doesn’t handle properly, which will require some manual tweaking to sort out. Most of these problems you will be blamed “for breaking it”, despite there being problems in the Windows OS.
Note
These issues are not caused by tollgate. They are simply included in this guide because they are problems not often documented in a single place.
Here are some problems your author has encountered in the past:
In DHCP options, you can offer multiple DNS search domains. On Windows, only the first search domain will be used.
You should separate your static (official) hosts and dynamic (user) hosts into two subnets still:
css01.example.lan
openttd1.example.lan
irc.example.lan
jimmy-pc.dhcp.example.lan
janes-macbook-pro.dhcp.example.lan
You should then specify the resolution order as follows:
example.lan (Windows will only use this one)
dhcp.example.lan
You can work around this bug, however it is an “opt-in” and requires some manual configuration in Windows:
Then this brings us to the next bug in Windows’ DNS resolver:
On a non-Windows machine, say you have a search domain set to example.lan. If you lookup jimmy-pc.dhcp, it will look up jimmy-pc.dhcp.example.lan. then jimmy-pc.dhcp..
On a Windows machine, it assumes any name being resolved with a dot in it is actually being resolved as a root object (ie: jimmy-pc.dhcp internally becomes jimmy-pc.dhcp.), so it will never try to look up jimmy-pc.dhcp.example.lan.
We can work around this with a DNAME zone for dhcp similar to this:
dhcp. IN SOA ns1.example.com. root.example.com (
2010012301 ; serial
60 ; refresh (1 minute)
60 ; retry (1 minute)
3600 ; expire (1 hour)
60 ; minimum (1 minute)
)
NS tollgate.example.lan.
dhcp. IN DNAME dhcp.example.lan.
Internet Explorer on Windows will try to discover a proxy server by doing NetBIOS lookups for the server called WPAD by default. As a result, a local network user may intercept all traffic from a vulnerable computer by specifying proxy settings that redirect traffic.
Included in tollgate’s source repository is a site at /www/wpad/. This should be hosted at the server named wpad.example.lan. and wpad. (where example.lan. is your search domain).
Likewise, you should send DHCP option 252 to indicate an absolute path to the WPAD configuration. In ISC DHCPd, you can do this with:
option auto-proxy-config code 252 = string;
subnet 10.4.0.0 netmask 255.255.255.0 {
# ... some other configuration here
option auto-proxy-config "http://10.4.0.1/wpad.dat";
}
See also:
In an effort to help reduce the master browser election traffic, and assist in NetBIOS name resolution, you should setup a WINS server.
In ISC DHCPd, this is done with the following configuration option:
option netbios-name-servers 10.4.0.1;
You’ll also need to run an actual WINS server too. Samba 3 provides a WINS server, but it is not enabled by default. In the [global] section of /etc/samba/smb.conf, you can enable this functionality with:
wins support = yes
dns proxy = yes
After this, reload your Samba and DHCP daemon.
It’s pretty much a given you will have problems with infected Windows hosts. One major thing you will want to consider is blocking external SMTP traffic to at least prevent your network from becoming a spam hub, and angering your ISP (as well as other internet users). You can do this with an entry in backend.ini, under the section blacklist:
externaldns = 0.0.0.0/25
Normally you only have to block port 25 traffic. SMTP over SSL is generally never used by such worms, and mail servers running on SSL generally also require authentication (which the spam bots won’t have).
It will also allow legitimate senders of mail on your network to be able to continue sending mail.
Unfortunately, there isn’t a simple way at this time to exempt blocking of SMTP over TLS (which uses port 25 and STARTTLS command). Additionally, many ISPs do not offer encrypted SMTP servers – until they are lobbied by users. ;)
Warning
Nintendo DS and DS Lite, as well as any DS games on the DSi and 3DS will only connect to wireless networks that are either unencrypted or encrypted with WEP. Additionally, they will only connect to 2.4GHz 802.11b networks.
Because of the additional radio bandwidth that 802.11b clients require, it is recommended that you run a seperate 802.11b-only network for those devices.
Note
On the Nintendo DSi and 3DS, connection profiles 1 - 3 do not support WPA or WPA2 encryption (for compatibility with DS games), only the profiles 4 - 6 support it.
All of Nintendo’s gaming consoles, with the exception of the Gamecube, will probe a site called conntest.nintendowifi.net during connection setup.
If this site is inaccessible or does not return a “200 OK” response, the console will assume it cannot connect to the internet, and refuse to save the connection profile.
Included in tollgate’s source repository in /www/wpad/ is a website you can host at conntest.nintendowifi.net, with a DNS record pointing to your server. This must be accessible inside of your LAN.
Warning
Playstation Portable will only connect to 2.4GHz 802.11b networks, and does not support WPA2 encryption.
Because of the additional radio bandwidth that 802.11b clients require, it is recommended that you run a seperate 802.11b-only network for those devices.
Warning
Playstation Portable E-1000 does not have WiFi.
PSP System software v2.00 includes a web browser. Earlier versions of the system software do not include a web browser.
If you wish to sign earlier versions of the PSP into tollgate, you will need to do it from another device with a web browser.
The general process for logging a system into tollgate when the device does not have a web browser is:
After this, the device will be registered with that user’s account. Whenever they are signed into the event they will automatically grant access to the internet for all of their devices.
There have been several instances at events your author has administed where Windows worms propegating on the network will send out rogue DHCP server responses, attempting to either route traffic through the infected machine, or replace DNS with a third-party server that will redirect traffic to popular websites through an attacker’s server.
There are two major mitigation steps you should take:
This can be done in backend.ini, by adding a blacklist line like:
externaldns = 0.0.0.0/53
This will only allow your DNS server, and any whitelisted / unmetered servers to have DNS traffic passed through to them.
Layer 3 managed switches offer various filtering options. You can limit the spread of a rogue DHCP server by:
If you are low on budget, there’s a good chance that you will not be able to afford all Layer 3 managed switches. In this case, save the money for at least one on your backbone, so any rogue DHCP server issues will be limited to one leaf switch, and you’ll be able to quickly determine which host is compromised.
Tollgate has a “quota reset” function whereby a user may gain their allocated quota again for their use. No usage information is discarded. So for example, if a user has 300 MiB of quota, they will gain an additional 300 MiB of quota for a total of 600 MiB.
At present, tollgate has a hard-coded “one free quota reset” function, which is user accessible. This becomes available to a user once they have used 70% of their quota allocation.
An administrator may reset a user’s quota any number of times. However administrators are prevented from resetting their own quota more than once.
There are two settings relating to this function:
As a result, you should generally allocate a user about half of the total amount of quota you want them to use. Your author has observed the following that makes these restrictions useful, and has some other notes:
When offered a free reset immediately (or if no reset is used at all), the user will often take it straight away, either through not understanding it’s function or wanting all the quota they can get.
However, if they do reset their quota early, they’ll often use it all up without realising, and not properly manage the use of their quota. They’ll then demand more quota to compensate.
As a result tollgate only offers it after the user has used 70% of their quota allocation.
Administrators will often also reset themselves numerous times without regard, and fall into the same trap. There is an “unmetered” function if it is really required to have unlimited access, however this is prone to abuse.
As a result, tollgate prevents administrators from resetting their own quota more than once (no more than any other user).
If you are tracking regular attendees, it is generally a good idea to lower the quota of non-regular attendees. Non-regulars more frequently try to exhaust as much quota as possible, often citing a right to use as much of the venue’s bandwidth as possible. They will also often not be familiar with what kind of traffic their computers use.
Regular attendees are generally more respectful of the event and it’s resources.
Most Windows-based traffic monitoring programs (like DU Meter, NetLimiter) do not accurately record internet usage. Generally, these programs will show lower amounts of traffic as to what is actually produced.
NetLimiter in particular is notoriously bad at recording usage accurately, and will report several orders of magnitude low. [1] [2] [3] [4]
The WinSock hooks that these software use in Windows are unreliable, and require that each packet be sent to a userspace program. If the program does not record the usage in a timely manner, it is possible for them to miss information about other packets.
It is also for this reason that at present tollgate will never be able to act as a router on Windows.
Windows network byte counters are optionally provided by the network card driver. Irregularities may occur as a result between different network card chipsets.
TL;DR: It is impossible to get accurate traffic information out of Windows operating systems, ever.
Some programs that create “raw” packets may not be accounted for properly by the OS in either traffic counters or firewall quota records, nor might they be filtered by outbound rules. Tollgate will also count traffic that the firewall may have rejected or dropped – it has no way to tell if the client is ignoring or using the traffic or not.
Additionally, these programs fail to take into account things like blacklisted and unmetered site access, as well as access from other sources (such as home internet use, or mobile broadband), which can cause them to read higher amounts of usage.
It is important when reporting irregularities to come up with solid evidence that proves it. I’m welcome to reproducable reports of these issues. Please include all details in your report, including tollgate versions, kernel versions, network hardware, packet captures, etc., enough so that I can try to reproduce the problem and verify that there is not an issue with your reporting device.
Any reports incorporating data from only Windows machines will be ignored for the above reasons. Incomplete, vague or non-reproducable reports will also be ignored.
Footnotes
[1] | http://whrl.pl/RbdgEC |
[2] | http://whrl.pl/RbxbbZ |
[3] | http://whrl.pl/RDrTP |
[4] | http://whrl.pl/RbN17d |