Using Linux as a Small Business Internet Gateway, Part 2
Pages: 1, 2, 3

Monitoring Systems

To tell the truth, running a web server on the gateway is not necessary. Everything will be fine without it. Nevertheless, many modern monitoring systems use a web server to visualize their reports. This is why we'll install one. However, we shouldn't forget to deny web access from the external network.

Almost every Linux distribution includes the Apache web server, a very powerful, multi-function server. For our purpose (monitoring) we do not need all of its power, but, because of its popularity and modest resource needs, we'll install it.

Installing the minimal number of packages produces:

# rpm -ihv httpd-2.0.40-21.i386.rpm httpd-manual-2.0.40-21.i386.rpm
Preparing...             ########################################### [100%]
1:httpd                  ########################################### [ 50%]
2:httpd-manual           ########################################### [100%]

Please note that the latest version of Apache 2 at the time of writing is 2.0.48, with some critical bug fixes. Don't forget to upgrade!

Apache's main configuration file is /etc/httpd/conf/httpd.conf. This file includes many different arguments. We'll need to modify a few before running our server. Later, while describing the monitoring system, we'll need to modify a few more.

You need to change only few arguments:

• ServerAdmin is the email address of the administrator. For example, it could be root@ourcompany.com.
• ServerName is the DNS name of your server. Set it to gateway.ourcompany.com or 192.168.0.1, depending on your DNS configuration.

You may not believe it, but that's all for now. As usual, we need to slightly restrict the iptables rules.

# Simple firewall for internet gateway
*filter
:INPUT ACCEPT [0:0]

# Deny forward for security reasons
:FORWARD DROP [0:0]
:OUTPUT  ACCEPT [0:0]
:RH-FW-INPUT - [0:0]

# Redirect all input-forwarded packets to our special rule
-A INPUT -j RH-FW-INPUT

# Accept all packets for local interface (lo)
-A RH-FW-INPUT -i lo -j ACCEPT

# Define custom rules
# Access to mail services
-A RH-FW-INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 110 -i eth0 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 143 -i eth0 -j ACCEPT

# Access to DNS service
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 53 -i eth0 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p udp -m udp --dport 53 -i eth0 -j ACCEPT

# Access to HTTP service
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 80 -i eth0 -j ACCEPT

# This part equal to some part from generated by Lokkit utility
-A RH-FW-INPUT -p tcp -m tcp --dport 143             -j ACCEPT
-A RH-FW-INPUT -p tcp -m tcp --dport 0:1023    --syn -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 2049      --syn -j REJECT
-A RH-FW-INPUT -p udp -m udp --dport 0:1023          -j REJECT
-A RH-FW-INPUT -p udp -m udp --dport 2049            -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 6000:6009 --syn -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 7100      --syn -j REJECT

# Allow access to external mail/news/DNS
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 25  -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 110 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 143 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 119 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 53  -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p udp -m udp --dport 53  -j ACCEPT
COMMIT

# Enable masquarading
*nat
:PREROUTING  ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT      ACCEPT [0:0]
-A POSTROUTING -p tcp -s 192.168.0.0/24 -o ppp0 -j SNAT
    --to-source 123.123.123.123
-A POSTROUTING -p udp -s 192.168.0.0/24 -o ppp0 -j SNAT
    --to-source 123.123.123.123
COMMIT

Do not forget to reload iptables!

# service iptables restart

At last, we can start the httpd service:

# service httpd start
Starting httpd:                         [  OK  ]

Let's check it now. In any web browser, try to open the page http://gateway.ourcompany.com/. If everything is all right, you will see Apache's introduction page. To change it to something else, you will need to put other pages into /var/www/html. The default CGI directory is /var/www/cgi-bin. Again, this will change, based on distribution and configuration options.

Monitoring Proxy Activity

There are two ways to monitor and control our proxy. The first is by analyzing our log files. This allows us to produce reports about the number of hits of any Internet resource over time. This data can be useful for system administrators and managers. This also allows administrators to control which sites users can visit during work hours.

The second approach is to monitor and to control all current open connections. This can be helpful to figure out why things are slow at times.

The sarg package fits the first approach. It generates readable and suitable reports and is easy to configure. However, it's not included in our distribution, so we will have to download it ourselves. I recommend sarg-1.1.1 (RPM linking by Sergei Dushenkov), because in 1.2.1 and 1.2.2 I found a bug — on some systems, only the daily report works properly.

Let's begin with installation:

# rpm -ihv sarg-1.1.1-2.i386.rpm 
Preparing...             ########################################### [100%]
1:sarg                   ########################################### [100%]

Configuration files live in /etc/sarg. You will also find there examples of commands to add to /etc/crontab to run recurring reports. Executable files are in /usr/sbin. Reports will be written into subdirectories under /var/www/html/squid daily, weekly, and monthly.

Related Reading Linux Network Administrator's Guide By Olaf Kirch, Terry Dawson

Let's now configure sarg. We need to edit the file /etc/sarg/sarg.conf. All necessary commands are described below.

• language sets the language of generated reports. The generated reports will respect the system locale settings. You can, for example, receive messages in win1251 and the date in koi8-r. You can fix that by choosing a language that is equal to system locale.

• access_log defines the location and name of the file where squid logs all access requests.

• title defines the title of the generated reports.

• The group of arguments from font_face to background_image defines how the report will look.

• password defines a list of squid users who require authentication to use the proxy. In our case, we set the value to none.

• temporary_dir defines the directory for temporary files. I suggest leaving this at the default value.

• output_dir defines the directory where all reports will be saved. If you want to view your reports from other computers, this directory must be available to the web server.

• output_email sets an email address to which to send reports. This is necessary if reports are not accessible via web server.

• resolve_ip governs whether hostnames should be looked up before writing to log files. If enabled, this will increase the readability of the files, though it requires an available DNS server and takes additional time.

• topuser_sort_field sets the sort order of the top 100 users.

• user_sort_field is the same as above, but works for the full user list.

• exlude_hosts can exclude some hosts or networks from the report.

• date_format defines the reported date format (European or American).

• lastlog defines how many reports should be stored. By default it is 0, or no restrictions.

• topsites_num specifies how many sites to see in the top list. By default it's TOP100 (100).

• topsites_sort_order controls how sites will be sorted in the TOP list, either by number of hits or size of downloaded data.

• report_type is a list of report types to be created.

• charset is the code page of the report language.

You also need to delete the file /etc/logrotate.d/squid or comment out all of its lines. Log file rotation will happen monthly with the help of the sarg.monthly script. It can't happen more often, or the monthly reports will not work.

To crown it all, let's configure the report generator to run automatically. This takes the following command:

# crontab -u squid /etc/sarg/sarg.cron

If you look at sarg.cron, you can see that sarg.monthly will run weekly. That's not a mistake; everything is okay.

Now we must configure proxy monitoring. Squid includes the cachemgr.cgi utility to provide a lot of information about the proxy's state. Copy this file into /var/www/cgi-bin directory. Now, browsing to http://192.168.0.1/cgi-bin/cachemgr.cgi will prompt for authorization to view the proxy manager interface. By default, there's no password. We just need to check the hostname and port number of the proxy. To set a password or otherwise restrict access, see the cachemgr_password option in squid's configuration file.

After authorization, you'll see the proxy manager interface. It provides a lot of data, but for beginners, the only interesting data is in the Client-side Active Requests section. Choose it. You will see a list of current client connections, including client IP addresses, requested URLs, times of connection, and the sizes of transferred information.

It's a pity, but the current form of this information is unsuitable for analysis. (Of course, you can try, but it's a question of habits and time). That's why other programs exist to convert this data into more useful views. SquidMon is one example. This program is for Microsoft Windows; nevertheless, it works fine under Wine. The author's site describes how to configure this application.

Pages: 1, 2, 3

Next Page