next up previous contents index
Next: Security in the Network Up: Network Previous: Heterogenous Networks   Contents   Index

Subsections


Internet

A lot could be written about the Internet, but most applications just work ``out of the box'' after configuring Internet access with YaST. Therefore, this chapter only focuses on more interesting aspects: the configuration of the smpppd (SuSE Meta PPP-Daemon), the manual configuration of ADSL access in case problems arise with the YaST2 configuration, and the configuration of the Squid proxy.


The smpppd as Dial-up Assistant

Program Components for the Internet Dial-Up

Most home users do not have a dedicated line connecting them to the Internet. Rather, they use dial-up connections. Depending on the dial-up method (ISDN or DSL), the connection is controlled by the ipppd or the pppd. Basically, all that needs to be done to go online is to start these programs correctly.

If you have a flat-rate connection that does not generate any additional costs for the dial-up connection, simply start the respective daemon. Control the dial-up connection with a KDE applet or a command-line interface. If the Internet gateway is not the host you are using, you might want to control the dial-up connection by way of a network host.

This is where smpppd is involved. It provides a uniform interface for auxiliary programs and acts in two directions: first, it programs the required pppd or ipppd and controls its dial-up properties. Second, it makes various providers available to the user programs and transmits information about the current status of the connection. As smpppd can also be controlled by way of the network, it is suitable for controlling dial-up connections to the Internet from a workstation in a private subnetwork.

Configuring the smpppd

The connections provided by smpppd are automatically configured by YaST. The actual dial-up programs kinternet and cinternet are also preconfigured. Manual settings are only required to configure additional features of the smpppd, such as remote control.

The configuration file of smpppd is /etc/smpppd.conf. By default, it does not enable remote control. The most important options of this configuration file are as follows:

open-inet-socket = <yes|no>
To control smpppd via the network, this option must be set to yes. The port on which the smpppd will listen is 3185. If this parameter is set to yes, the parameters bind-address, host-range, and password should also be set accordingly.
bind-address = <ip>
If a host has several IP addresses, this parameter can be used to determine by which IP address smpppd should accept connections.
host-range = <min ip> <max ip>
The parameter host-range can be used to define a network range. Hosts whose IP addresses are within this range are granted access to smpppd. All hosts not within this range are denied access.
password = <password>
By assigning a password, limit the clients to authorized hosts. As this is a plain-text password, you should not overrate the security it provides. If no password is assigned, all clients are entitled to access smpppd.

More information about smpppd is available in [8]smpppd and [5]smpppd.conf.


Configuring kinternet and cinternet for Remote Use

The programs kinternet and cinternet can be used locally as well as for controlling a remote smpppd. cinternet is the the command-line counterpart of the graphical kinternet. To prepare these utilities for use with a remote smpppd, edit the configuration file /etc/smpppd-c.conf manually or using kinternet. This file only uses three options:

server = <server>
Here, specify the host on which the smpppd runs. If this host is the same as the default gateway of the host, it is sufficient to set the gateway-fallback to yes.
gateway-fallback = <yes|no>
If no server was specified and there is no local smpppd, this option, which is enabled by default, causes a search for an smpppd on the default gateway.
password = <password>
Insert the password selected for smpppd.

If the smpppd is active, you can now try to access it. This can be done with the command cinternet -verbose -interface-list. If you experience difficulties at this point, refer to [5]smpppd-c.conf and [8]cinternet.


Configuring an ADSL or T-DSL Connection

Default Configuration

Currently, SuSE Linux supports DSL connections that work with the point-to-point over ethernet protocol (PPPoE) used by most major providers. If you are not sure what protocol is used for your DSL connections, ask your provider. If you have a single-user workstation with a graphical interface, the DSL connection should be set up with the YaST modules ADSL or T-DSL.

  1. The ppp and smpppd packages must be installed. It is best to use YaST for this purpose.

  2. Configure your network card with YaST. Do not activate dhcp, but set a fixed IP address instead, such as 192.168.2.22.

  3. The parameters set with the DSL module of YaST will be saved in the file /etc/sysconfig/network/providers/provider0. In addition, there are configuration files for the smpppd (SuSE meta ppp daemon) and its front-ends kinternet and cinternet. For information, refer to man smpppd.

  4. If necessary, start the network with the command rcnetwork start and the smpppd with the command rcsmpppd start.

  5. On a system without a graphical user interface, use the commands cinternet -start and cinternet -stop to establish or terminate a connection. On a graphical user interface, this can be done with kinternet. This program is started automatically in KDE if you used YaST to set up DSL. Click the gear icon in the control panel. Select ` Communication/Internet' ->` Internet Tools' ->` kinternet'. A plug icon will appear in the control panel. You can now start the connection with a simple click on the icon, and terminate the connection later on with another click.


DSL Connection by Dial-on-Demand

Dial-on-demand means that the connection will automatically be set up when the user goes online, for example, when visiting a web site in a browser or when sending an e-mail. After a certain amount of idle time when no data is sent or received, the connection will automatically be dropped. Because the dial-up connection via PPPoE, the protocol for ADSL, is very fast, it seems as if it were a dedicated line to the Internet.

Using dial-on-demand, however, really only makes sense if you have a flat-rate connection. If you use it but are charged for time online, make sure tthere are no interval processes, such as a cronjob, periodically establishing a connection. This could get quite expensive.

Although a permanent online connection would also be possible using a DSL flat-rate connection, there are certain advantages to having a connection that only exists for a short amount of time when needed:

  • Most providers drop the connection after a certain period of time.

  • A permanent connection can be considered as a drain on resources (e.g. , IP addresses).

  • Being online permanently is a security risk, because hackers may be able to comb the system systematically for vulnerable areas. A system that is only accessible over the Internet when necessary and is always changing IP addresses is significantly more difficult to attack.

Dial-on-demand can be enabled using YaST (also refer to the User Guide). Alternatively, set it up manually:

Set the parameter DEMAND=yes in the /etc/sysconfig/network/providers/provider0 file then define an idle time via the variable IDLETIME=60 . This way, an unused connection will be dropped after sixty seconds.


Proxy Server: Squid

The following chapter describes how caching web sites assisted by a proxy server works and what the advantages of using proxy servers are. A widely popular proxy cache for Linux and UNIX platforms is Squid. The chapter discusses its configuration, the specifications required to get it running, how to configure the system to do transparent proxying, how to gather statistics about the cache's use with the help of programs like Calamaris and cachemgr, and how to filter web contents with squidGuard.


About Proxy Caches

Squid acts as a proxy cache. It behaves like an agent that receives requests from clients, in this case web browsers, and passes them to the specified server. When the requested objects arrive at the agent, it stores a copy in a disk cache.

Benefits arise when different clients request the same objects: these will be served directly from the disk cache, much faster than obtaining them from the Internet and, at the same time, saving overall bandwidth for the system.


Tip

Squid covers a wide range of features, including intercommunicating hierarchies of proxy servers to divide the load, defining strict access control lists to all clients accessing the proxy, and, with the help of other applications, allowing or denying access to specific web pages. It also can obtain statistics about the most visited web sites, user usage of the Internet, and others.

Squid is not a generic proxy. It proxies normally only between HTTP connections. It does also support the protocols FTP, Gopher, SSL, and WAIS, but it does not support other Internet protocols, such as Real Audio, news, or videoconferencing. Because Squid only supports the UDP protocol to provide communication between different caches, many other multimedia programs will not be supported.


Some Facts About Cache Proxying


Squid and Security

It is also possible to use Squid together with a firewall to secure internal networks from the outside using a proxy cache. The firewall denies all clients access to external services except Squid. All web connections must be established by way of the proxy.

If the firewall configuration includes a DMZ, set the proxy there. In this case, it is important that all computers in the DMZ send their log files to hosts inside the secure network. The possibility of implementing a ``transparent'' proxy is covered in 17.


Multiple Caches

Several proxies can be configured in such a way that objects can be exchanged between them, thus reducing the total system load and increasing the chances of finding an object already existing in the local network. It enables the configuration of cache hierarchies so a cache is able to forward object requests to sibling caches or to a parent cache. It can get objects from another cache in the local network or directly from the source.

Choosing the appropriate topology for the cache hierarchy is very important, because we do not want to increase the overall traffic on the network. For example, in a very large network, it is possible to configure a proxy server for every subnetwork and connect it to a parent proxy, connected in its turn to the proxy cache from the ISP. All this communication is handled by ICP (Internet Cache Protocol) running on top of the UDP protocol. Data transfers between caches are handled using HTTP (Hyper Text Transmission Protocol) based on TCP.

To find the most appropriate server from which to get the objects, one cache sends an ICP request to all sibling proxies. These will answer the requests via ICP responses with a HIT code if the object was detected or a MISS if it was not. If multiple HIT responses were found, the proxy server will decide which server to download depending on factors such as which cache sent the fastest answer or which one is closer. If no satisfactory responses have been sent, the request will be sent to the parent cache.


Tip

To avoid duplication of objects in different caches in our network, other ICP protocols are used, such as CARP (Cache Array Routing Protocol) or HTCP (HyperText Cache Protocol). The more objects maintained in the network, the greater the possibility of finding the desired one.


Caching Internet Objects

Not all objects available in the network are static. There are a lot of dynamically generated CGI pages, visitor counters, and encrypted SSL content documents. Objects like this are not cached because they will have changed each time they are accessed.

The question remains as to how long all the other objects stored in the cache should stay there. To determine this, all objects in the cache are assigned one of various possible states.

Web and proxy servers find out the status of an object by adding headers to these objects, such as ``Last modified'' or ``Expires'' and the corresponding date. Other headers specifying that objects must not be cached are used as well.

Objects in the cache are normally replaced, due to a lack of free hard disk space, using algorithms such as LRU (Last Recently Used). It consists of first replacing the less requested objects.


System Requirements

The most important thing is to determine the maximum load the system will have to bear. It is, therefore, important to pay more attention to the load picks, because these might be more than four times the day's average. When in doubt, it would be better to overestimate the system's requirements, because having Squid working close to the limit of its capabilities could lead to a severe loss in the quality of the service. The following sections point to the system factors in order of significance.

Hard Disks

Speed plays an important role in the caching process, so this factor deserves special attention. In hard disks, this parameter is described as ``random seek time'', measured in milliseconds. As a rule of thumb, the lower this value, the better.

One possibility to speed up the system is to concurrently use a number of disks or to employ striping RAID arrays.


Size of the Disk Cache

It depends on a few factors. In a small cache, the probability of a HIT (finding the requested object already located there) will be small, because the cache is easily filled so the less requested objects will be replaced by newer ones. On the other hand, if for example 1 GB is available for the cache and the users only surf 10 MB a day, it will take more than one hundred days to fill the cache.

The probably easiest way to determine the needed cache size is to consider the maximum transfer rate of our connection. With a 1 Mbit/s connection, the maximum transfer rate will be 125 KB/s. If all this traffic ends up in the cache, in one hour it will add up to 450 MB and, assuming that all this traffic is generated in only 8 working hours, it will reach 3.6 GB in one day. Since the connection is normally not used to its upper volume limit, it can be assumed that the total data volume handled by the cache is approximately 2 GB. This is why in the example 2 GB of disk space is required for Squid to keep one day's worth of browsed data cached.

Since Squid prominently reads or writes smaller blocks of data from the hard disk, the access time of a hard disk is more important than its data throughput speed. It is especially in these cases that hard disks with high rotation speeds are of great advantage by allowing a faster positioning of the heads.


RAM

The amount of memory required by Squid directly correlates to the number of objects in the cache. Squid also stores cache object references and frequently requested objects in the main memory to speed up retrieval of this data. Random access memory is much faster than a hard disk.

It is very important to have more than enough memory for the Squid process, because system performance will be dramatically reduced if it must be swapped to disk. The cachemgr.cgi tool can be used for the cache memory management. This tool is introduced in 17.


CPU

Squid is not a program that requires intensive CPU usage. The load of the processor is only increased while the contents of the cache are being loaded or checked. Using a multiprocessor machine does not increase the performance of the system. To increase efficiency, it is better to buy faster disks or add more memory.

Some examples of configured systems running Squid are available at http://wwwcache.ja.net/servers/squids.html.


Starting Squid

Squid is already preconfigured in SuSE Linux, so you can start it easily right after installation. A prerequisite for a smooth start is an already configured network, at least one name server and, of course, Internet access. Problems can arise if a dial-up connection is used with dynamic DNS configuration. In cases such as this, at least the name server should be clearly entered, because Squid will not start if it does not detect a DNS server in the /etc/resolv.conf.

To start Squid, enter rcsquid start at the command line as SuSE @nohyphen root. For the initial start-up, the directory structure must first be defined in /var/squid/cache. This is done by the start script /etc/init.d/squid automatically and can take a few seconds or even minutes. If done appears to the right in green, Squid has been successfully loaded. Test Squid's functionality on the local system by entering localhost and Port 3128 as proxy in the browser. To allow all users to access Squid and thus the Internet, change the entry in the configuration file /etc/squid/squid.conf from http_access deny all to http_access allow all. However, in doing so, consider that Squid is made completely accessible to anyone by this action. Therefore, define ACLs that control access to the proxy. More on this is available in 17.

If you have made changes in the configuration file /etc/squid/squid.conf, instruct Squid to load the changed file. Do this by entering rcsquid reload or restart Squid with rcsquid restart. With rcsquid status, determine whether the proxy is running. Use rcsquid stop to halt Squid. The latter can take a while, because Squid waits up to half a minute (shutdown_lifetime option in /etc/squid/squid.conf) before dropping the connections to the clients then will still need to write its data to the disk. Terminating Squid with kill or killall can lead to the destruction of the cache, which will then have to be fully removed to restart Squid.

If Squid dies after a short period of time, although it has seemingly been started successfully, it can be the result of a faulty name server entry or a missing /etc/resolv.conf file. The cause of the start failure would then be logged by Squid in the /var/squid/logs/cache.log file.

If Squid should be loaded automatically when the system boots, reset the entry START_SQUID=no to START_SQUID=yes in the /etc/sysconfig/squid file.

An uninstall of Squid will remove neither the cache or the log files. Manually delete the /var/cache/squid directory.


Local DNS Server

Setting up a local DNS server, such as BIND9, makes absolute sense even if the server does not manage its own domain. It will then simply act as a ``caching-only DNS'' and will also be able to resolve DNS requests via the root name server without requiring any special configuration. If you enter this in the /etc/resolv.conf with the IP address 127.0.0.1 for localhost, Squid will detect a valid name server when it starts up. Configuring a name server is discussed in 13. It is sufficient, however, to install the package and to boot it. The name server of the provider should be entered in the configuration file /etc/named.conf under forwarders along with its IP address. If you have a firewall running make sure the DNS requests will be sent.


The Configuration File /etc/squid/squid.conf

All Squid proxy server settings are made in the /etc/squid/squid.conf file. To start Squid for the first time, no changes will be necessary in this file, but external clients will initially be denied access. The proxy needs to be made available for the localhost, usually with 3128 as port. The options are extensive and therefore provided with ample documentation and examples in the preinstalled /etc/squid/squid.conf file. Nearly all entries begin with a # sign (the lines are commented out) and the relevant specifications can be found at the end of the line. The given values almost always correlate with the default values, so removing the comment signs without changing any of the parameters actually has little effect in most cases. It is better to leave the sample as it is and reinsert the options along with the modified parameters in the line below. In this way, easily interpret the default values and the changes.


Note


[Update from Version 2.4 to Version 2.5] Following an update of Squid from version 2.4 to version 2.5, the cache of Squid must be deleted, as the directory structure was changed.

If you have updated from an earlier Squid version, it is recommended to edit the new /etc/squid/squid.conf and only apply the changes made in the previous file. If you try to implement the old squid.conf again, run a risk that the configuration will no longer function, because options are sometimes modified and new changes added.

General Configuration Options (Selection)

http_port 3128
This is the port where Squid listens for client requests. The default port is 3128, but 8080 is also common. If desired, specify several port numbers separated by blank spaces.

cache_peer <hostname> <type> <proxy-port> <icp-port>
Here, enter a parent proxy as ``parent'', for example, or use that of the provider. As <hostname>, the name and IP address of the proxy to use are entered and, as <type>, parent. For <proxy-port>, enter the port number that is also specified by the operator of the parent for use in the browser, usually 8080. Set the <icp-port> to 7 or 0 if the ICP port of the parent is not known and its use is irrelevant to the provider. In addition, default and no-query should be specified after the port numbers to strictly prohibit the use of the ICP protocol. Squid will then behave like a normal browser as far as the provider's proxy is concerned.

cache_mem 8 MB
This entry defines the amount of memory Squid can use for the caches. The default is 8 MB.

cache_dir ufs /var/cache/squid/ 100 16 256
The entry cache_dir defines the directory where all the objects are stored on disk. The numbers at the end indicate the maximum disk space in MB to use and the number of directories in the first and second level. The ufs parameter should be left alone. The default is 100 MB occupied disk space in the /var/cache/squid directory and creation of 16 subdirectories inside it, each containing 256 more subdirectories. When specifying the disk space to use, leave sufficient reserve disk space. Values from a minimum of fifty to a maximum of eighty percent of the available disk space make the most sense here. The last two numbers for the directories should only be increased with caution, because too many directories can also lead to performance problems. If you have several disks that share the cache, enter several cache_dir lines.

cache_access_log /var/log/squid/access.log
path for log messages
cache_log /var/log/squid/cache.log
path for log messages
cache_store_log /var/log/squid/store.log
path for log messages

These three entries specify the paths where Squid logs all its actions. Normally, nothing is changed here. If Squid is experiencing a heavy usage burden, it might make sense to distribute the cache and the log files over several disks.

emulate_httpd_log off
If the entry is set to on, obtain readable log files. Some evaluation programs cannot interpret this, however.

client_netmask 255.255.255.255
With this entry, mask the logged IP addresses in the log files to hide the clients' identity. The last digit of the IP address will be set to zero if you enter 255.255.255.0 here.

ftp_user Squid@
With this, set the password Squid should use for the anonymous FTP login. It can make sense, however, to specify a valid e-mail address here, because some FTP servers can check these for validity.

cache_mgr webmaster
An e-mail address to which Squid sends a message if it unexpectedly crashes. The default is webmaster.

logfile_rotate 0
If you run squid -k rotate, Squid can rotate secured log files. The files will be enumerated in this process and after reaching the specified value, the oldest file at that point will be overwritten. This value here normally stands for 0 because archiving and deleting log files in SuSE Linux is carried out by a cronjob found in the configuration file /etc/logrotate/squid.

append_domain <domain>
With append_domain, specify which domain to append automatically when none is given. Usually, your own domain is entered here, so entering www in the browser accesses your own web server.

forwarded_for on
If you set the entry to off, Squid will remove the IP address and the system name of the client from the HTTP requests.

negative_ttl 5 minutes; negative_dns_ttl 5 minutes
Normally, you do not need to change these values. If you have a dial-up connection, however, the Internet may, at times, not be accessible. Squid will make a note of the failed requests then refuse to issue new ones, although the Internet connection has been reestablished. In a case such as this, change the minutes to seconds then, after clicking Reload in the browser, the dial-up process should be reengaged after a few seconds.

never_direct allow <acl_name>
To prevent Squid from taking requests directly from the Internet, use the above command to force connection to another proxy. This must have previously been entered in cache_peer. If all is specified as the <acl_name>, force all requests to be forwarded directly to the parent. This might be necessary, for example, if you are using a provider that strictly stipulates the use of its proxies or denies its firewall direct Internet access.


Options for Access Controls

Squid provides an intelligent system that controls access to the proxy. By implementing ACLs, it can be configured easily and comprehensively. This involves lists with rules that are processed sequentially. ACLs must be defined before they can be used. Some default ACLs, such as all and localhost, already exist. After defining an ACL, implement it, for example, in conjunction with http_access.

acl <acl_name> <type> <data>
An ACL requires at least three specifications to define it. The name <acl_name> can be chosen arbitrarily. For <type>, select from a variety of different options which can be found in the ACCESS CONTROLS section in the /etc/squid/squid.conf file. The specification for <data> depends on the individual ACL type and can also be read from a file, for example, via host names, IP addresses, or URLs. The following are some simple examples:

acl mysurfers srcdomain .my-domain.com
acl teachers src 192.168.1.0/255.255.255.0
acl students src 192.168.7.0-192.168.9.0/255.255.255.0
acl lunch time MTWHF 12:00-15:00

http_access allow <acl_name>
http_access defines who is allowed to use the proxy and who can access what on the Internet. For this, ACLs must be given. localhost and all have already been defined above, which can deny or allow access via deny or allow. A list containing any number of http_access entries can be created, processed from top to bottom, and, depending on which occurs first, access will be allowed or denied to the respective URL. The last entry should always be http_access deny all. In the following example, the localhost has free access to everything while all other hosts are denied access completely.

http_access allow localhost
http_access deny all

Another example, where the previously-defined ACLs are used. The group SuSE @nohyphen teachers always has access to the Internet. The group SuSE @nohyphen students only gets access Monday to Friday during lunch time.

http_access deny localhost
http_access allow teachers
http_access allow students lunch time
http_access deny all

The list with the http_access entries should only be entered, for the sake of readability, at the designated position in the /etc/squid/squid.conf file. That is, between the text

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR
# CLIENTS

and the last

http_access deny all

redirect_program /usr/bin/squidGuard

With this option, a redirector, such as squidGuard, which is able to block unwanted URLs, can be specified. Internet access can be individually controlled for various user groups with the help of proxy authentication and the appropriate ACLs. squidGuard is a package in and of itself that can be separately installed and configured.

authenticate_program /usr/sbin/pam_auth
If users must be authenticated on the proxy, a corresponding program, such as pam_auth, can be specified here. When accessing pam_auth for the first time, the user will see a login window where the user name and password must be entered. In addition, an ACL is still required so only clients with a valid login can use the Internet:

acl password proxy_auth REQUIRED

http_access allow password
http_access deny all

The REQUIRED after proxy_auth can be replaced with a list of permitted user names or with the path to such a list.

ident_lookup_access allow <acl_name>
With this, have an ident request run for all ACL-defined clients to find each user's identity. If you apply all to the <acl_name>, this will be valid for all clients. Also, an ident daemon must be running on all clients. For Linux, install the pidentd package for this purpose. For Windows, there is free software available to download from the Internet. To ensure that only clients with a successful ident lookup are permitted, a corresponding ACL also needs to be defined here:

acl identhosts ident REQUIRED

http_access allow identhosts
http_access deny all

Here, too, replace the REQUIRED with a list of permitted user names. Using ident can slow down the access time quite a bit, because ident lookups will be repeated for each request.


Transparent Proxy Configuration

The usual way of working with proxy servers is the following: the web browser sends requests to a certain port in the proxy server and the proxy provides these required objects, whether they are in its cache or not. When working in a real network, several situations may arise:

  • For security reasons, it is recommended that all clients use a proxy to surf the Internet.
  • All clients must use a proxy whether they are aware of it or not.
  • The proxy in a network is moved, but the existing clients should retain their old configuration.

In all these cases, a transparent proxy may be used. The principle is very easy: the proxy intercepts and answers the requests of the web browser, so the web browser receives the requested pages without knowing from where they are coming. This entire process is done transparently, hence the name.


Kernel Configuration

First, make sure the proxy server's kernel has support for transparent proxying. Kernel modules change sometimes from version to version. Check the current state in the Transparent Proxy mini-howto installed in your SuSE Linux system at /usr/share/doc/howto/en/html/mini/TransparentProxy-3.html or online at the Linux Documentation Project web page (http://www.tldp.org/HOWTO/mini/TransparentProxy-3.html).


Configuration Options in /etc/squid/squid.conf

The options to activate in the /etc/squid/squid.conf file to get the transparent proxy up and running are:

  • httpd_accel_host virtual
  • httpd_accel_port 80 # the port number where the actual HTTP server is located
  • httpd_accel_with_proxy on
  • httpd_accel_uses_host_header on


Firewall Configuration with SuSEfirewall2

Now redirect all incoming requests via the firewall with help of a port forwarding rule to the Squid port.

To do this, use the SuSE-provided tool SuSEfirewall2. Its configuration file can be found in /etc/sysconfig/SuSEfirewall2. Again, the configuration file consists of well-documented entries. Even to set only a transparent proxy, you must configure some firewall options. In our example:

  • Device pointing to the Internet: FW_DEV_EXT=eth1
  • Device pointing to the network: FW_DEV_INT=eth0

Set ports and services (see /etc/exports) on the firewall being accessed from untrusted networks such as the Internet. In this example, only web services are offered to the outside:

FW_SERVICES_EXT_TCP=``www''

Define ports or services (see /etc/exports) on the firewall to be accessed from the secure network, both TCP and UDP services:

FW_SERVICES_INT_TCP=``domain www 3128''

FW_SERVICES_INT_UDP=``domain''

This allows accessing web services and Squid (whose default port is 3128).

The service ``domain'' specified before stands for DNS. This service is commonly used. Otherwise, simply take it out of the above entries and set the following option to no:

FW_SERVICE_DNS=``yes''

The most important option is number 15:

File: Firewall Configuration: Option 15



#
# 15.)
# Which accesses to services should be redirected to a localport
# on the firewall machine?
#
# This can be used to force all internal users to surf via your
# squid proxy, or transparently redirect incoming webtraffic to
# a secure webserver.
#
# Choice: leave empty or use the following explained syntax of
# redirecting rules, separated by a space.
# A redirecting rule consists of 1) source IP/net,
# 2) destination IP/net, 3) original destination port and
# 4) local port to redirect the traffic to, separated by a colon,
# e.g. "10.0.0.0/8,0/0,80,3128 0/0,172.20.1.1,80,8080"
#

The comments above show the syntax to follow. First, the IP address and the netmask of the ``internal networks'' accessing the proxy firewall. Second, the IP address and the netmask to which these clients ``send'' their requests. In the case of web browsers, specify the networks 0/0, a wild card that means ``to everywhere''. After that, enter the ``original'' port to which these requests are sent and, finally, the port to which all these requests are ``redirected''. As Squid supports more protocols than HTTP, redirect requests from other ports to our proxy, such as FTP (port 21), HTTPS, or SSL (port 443). The example uses the default port 3128. If there are more networks or services to add, they only need to be separated by a single blank character in the corresponding entry.

FW_REDIRECT_TCP="192.168.0.0/16,0/0,80,3128 192.168.0.0/16,0/0,21,3128"

FW_REDIRECT_UDP="192.168.0.0/16,0/0,80,3128 192.168.0.0/16,0/0,21,3128"

To start the firewall and the new configuration with it, change an entry in the /etc/sysconfig/SuSEfirewall2 file. The entry START_FW must be set to "yes".

Start Squid as shown in 17. To check if everything is working properly, check the Squid logs in /var/log/squid/access.log.

To verify that all ports are correctly configured, perform a port scan on the machine from any computer outside your network. Only the web services port (80) should be open. To scan the ports with nmap, the command syntax is nmap -O IP_address.

Squid and Other Programs

In the following, see how other applications interact with Squid. cachemgr.cgi enables the system administrator to check the amount of memory needed for caching objects. squidGuard filters web pages. Calamaris is a report generator for Squid.


cachemgr.cgi

The cache manager (cachemgr.cgi) is a CGI utility for displaying statistics about the memory usage of a running Squid process. It is also a more convenient way to manage the cache and view statistics without logging the server.

Setup

First, a running web server on your system is required. To check if Apache is already running, type, as SuSE @nohyphen root, rcapache status.

If a message like this appears:

Checking for service httpd: OK 
Server uptime: 1 day 18 hours 29 minutes 39 seconds

Apache is running on your machine. Otherwise, type rcapache start to start Apache with the SuSE Linux default settings.

The last step to set it up is to copy the file cachemgr.cgi to the Apache directory cgi-bin:


cp /usr/share/doc/packages/squid/scripts/cachemgr.cgi
   /srv/www/cgi-bin/

Cache Manager ACLs in /etc/squid/squid.conf

There are some default settings in the original file required for the cache manager:

acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255

With the following rules:

http_access allow manager localhost
http_access deny manager

the first ACL is the most important, as the cache manager tries to communicate with Squid over the cache_object protocol.

The following rules assume that the web server and Squid are running on the same machine. If the communication between the cache manager and Squid originates at the web server on another computer, include an extra ACL as in File 52.


acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl webserver src 192.168.1.7/255.255.255.255 # webserver IP

Then add the rules as in File 53.

File: Access Rules


http_access allow manager localhost
http_access allow manager webserver
http_access deny manager

Configure a password for the manager for access to more options, like closing the cache remotely or viewing more information about the cache. For this, configure the entry cachemgr_passwd with a password for the manager and the list of options to view. This list appears as a part of the entry comments in /etc/squid/squid.conf.

Restart Squid every time the configuration file is changed. This can easily be done with rcsquid reload.

Viewing the Statistics

Go to the corresponding web site:
http://webserver.example.org/cgi-bin/cachemgr.cgi

Press ` continue' and browse through the different statistics. More details for each entry shown by the cache manager is in the Squid FAQ at http://www.squid-cache.org/Doc/FAQ/FAQ-9.html


squidGuard

This section is not intended to go through an extensive configuration of squidGuard, only to introduce it and give some advice for using it. For more in-depth configuration issues, refer to the squidGuard web site at http://www.squidguard.org.

squidGuard is a free (GPL), flexible, and fast filter, redirector, and access controller plug-in for Squid. It lets you define multiple access rules with different restrictions for different user groups on a Squid cache. squidGuard uses Squid's standard redirector interface.

squidGuard can be used for the following:

  • limit the web access for some users to a list of accepted or well-known web servers or URLs
  • block access to some listed or blacklisted web servers or URLs for some users
  • block access to URLs matching a list of regular expressions or words for some users
  • redirect blocked URLs to an ``intelligent'' CGI-based info page
  • redirect unregistered users to a registration form
  • redirect banners to an empty GIF
  • have different access rules based on time of day, day of the week, date, etc.
  • have different rules for different user groups
  • and much more

Neither squidGuard or Squid can be used to:

  • Edit, filter, or censor text inside documents
  • Edit, filter, or censor HTML-embedded script languages, such as JavaScript or VBscript


Using squidGuard

Install the package squidGuard. Edit a minimal configuration file /etc/squidguard.conf. There are plenty of configuration examples in http://www.squidguard.org/config/. Experiment later with more complicated configuration settings.

The following step is to create a dummy ``access denied'' page or a more or less intelligent CGI page to redirect Squid if the client requests a blacklisted web site. Using Apache is strongly recommended.

Now, tell Squid to use squidGuard. Use the following entry in the /etc/squid.conf file:

redirect_program /usr/bin/squidGuard

There is another option called redirect_children configuring how many different ``redirect'' (in this case squidGuard) processes are running on the machine. squidGuard is fast enough to cope with lots of requests (squidGuard is quite fast: 100,000 requests within 10 seconds on a 500MHz Pentium with 5900 domains, 7880 URLs, total 13780).

Therefore, it is not recommended to set more than 4 processes, because this may lead to an unnecessary increase of memory for the allocation of these processes.

redirect_children 4

Last, have Squid read its new configuration by running rcsquid reload. Now, test your settings with a browser.


Cache Report Generation with Calamaris

Calamaris is a Perl script used to generate reports of cache activity in ASCII or HTML format. It works with native Squid access log files. The Calamaris home page is located at http://Calamaris.Cord.de/

The use of the program is quite easy. Log in as SuSE @nohyphen root, then enter:


cat access.log.files | calamaris [options] > reportfile

It is important when piping more than one log file that the log files are chronologically ordered with older files first.

The various options are:

-a
normally used for the output of available reports
-w
an HTML report
-l
a message or logo in the header of the report

More information about the various options can be found with man calamaris.

A typical example is:


cat access.log.2 access.log.1 access.log | calamaris -a -w \

   >/usr/local/httpd/htdocs/Squid/squidreport.html

This puts the report in the directory of the web server. Apache is required to view the reports.

Another powerful cache report generator tool is SARG (Squid Analysis Report Generator). More information about this can be found in the relevant Internet pages at http://web.onda.com.br/orso/ .

More Information about Squid

Visit the home page of Squid at http://www.squid-cache.org/. Here, find the Squid User Guide and a very extensive collection of FAQs on Squid.

There is a Mini-Howto regarding transparent proxies in the package howtoen under /usr/share/doc/howto/en/mini/TransparentProxy.gz .

In addition, mailing lists are available for Squid at squid-users@squid-cache.org. The archive for this is located at: http://www.squid-cache.org/mail-archive/squid-users/


next up previous contents index
Next: Security in the Network Up: Network Previous: Heterogenous Networks   Contents   Index
root 2003-11-05