Squid Setup on RedHat 7

Document Sample
Squid Setup on RedHat 7 Powered By Docstoc
					  Modification of Existing Network

    constituents to accommodate

incorporation of a Squid proxy server

     for use as an Access control

  mechanism for Internet services
                                                                 TABLE OF CONTENTS
INTRODUCTION..................................................................................................................................................3
ACTIVE DIRECTORY SECURITY ...................................................................................................................3
BUILDING, INSTALLING AND CONFIGURING SAMBA ............................................................................3
   BUILDING AND INSTALLING SAMBA ......................................................................................................................4
   CONFIGURING SAMBA ...........................................................................................................................................4
BUILDING, INSTALLING AND CONFIGURING SQUID ..............................................................................5
   BUILDING AND INSTALLING SQUID ........................................................................................................................5
   CONFIGURING SQUID ............................................................................................................................................6
IPTABLES FIREWALL CONFIGURATION ....................................................................................................7
   SETTING DEFAULT POLICIES .................................................................................................................................7
   SETTING INPUT RULES.........................................................................................................................................7
   ITPSETTING NAT RULES ........................................................................................................................................7

STARTUP SCRIPTS ..............................................................................................................................................8
   SAMBA ..................................................................................................................................................................8
   WINBIND ...............................................................................................................................................................8
   SQUID ...................................................................................................................................................................8
   SETTING MODE ......................................................................................................................................................8
ROUTING ON THE LINUX BOX .......................................................................................................................9
   ADDING ROUTES ...................................................................................................................................................9
   ENABLING IP FORWARDING ..................................................................................................................................9
WATCHGUARD FIREBOX II PLUS: CONFIGURING ROUTES, NAT, AND VPN ...................................9
   ROUTING ...............................................................................................................................................................9
   “1 TO 1 NAT” (A.K.A. DESTINATION NAT) ........................................................................................................10
   PPTP VPN ..........................................................................................................................................................10
DOMAIN NAME SERVICE (DNS) CONFIGURATION ............................................................................... 11
ENABLING DOMAIN CLIENTS TO USE SQUID......................................................................................... 11
FORCING INTERNET EXPLORER CLIENTS TO USE WEB-BASED FTP ............................................ 11
PERFORMANCE TUNING THE SQUID PROXY SERVER ........................................................................12
   HTTP_PORT ..........................................................................................................................................................12
   ICP_PORT .............................................................................................................................................................12
   CACHE_DIR .........................................................................................................................................................12
   POSITIVE DNS CACHE TTL ................................................................................................................................12
   CACHE_MGR........................................................................................................................................................12
   CACHEMGR_PASSWD ...........................................................................................................................................12




                                                                                     2
Introduction
This guide expects the reader is relatively proficient with basic RedHat linux management, and thus not all
detail regarding setup and configuration of software will be covered. Documentation covering basic RedHat
administration is plentiful on the internet and in various books (RedHat Linux 7 Unleashed), and a good starting
place are the online manuals for RedHat, which can be found at http://www.redhat.com. As good practice,
when compiling and installing software from source, it is imperative to read the included README file and if
present, the INSTALL file for each software package. Only limited information contained in these documents
will be reiterated in this guide.

Squid is a caching proxy server that can also be used to control access to some internet resources. In
combination with a Windows domain, Squid can offer reliable and inexpensive proxy functionality that can be
integrated directly with Window‟s security with the help of Samba. Furthermore, by using two physical
network interface cards (NIC) in the linux box, all clients on a local area network (LAN) can be forced to use
the proxy for access to the internet. However, by using two NICs, routing must be address and potentially
large-scale changes may need to be completed.

In this guide, the example network consists of a Watchguard Firebox II Plus with multiple Cisco routers behind
the firebox. Routing functions on the firebox will be kept to a minimum, as it is intended as a firewall and not a
router. The firebox will also be configured as a virtual private network (VPN) server handling incoming point
to point tunneling protocol (PPTP) VPN connections. The linux box (named ARES) will be running RedHat
Linux 7.3 (installed with Server configuration and added X-Windows System, Gnome, KDE, and Apache) and
be placed physically inline between the firebox and the LAN. A complete discussion will be presented that
covers setting up the linux box to finalizing routing setup on the example network.

Active Directory Security
Security on all objects in Active Directory (AD) needs to be set correctly to allow access from the linux box.
Security should include Pre-Windows2000 Compatibility group. At the domain level, set advanced security for
this group as follows:

Read Permission                                                             This object only
List Contents                                                               This folder, subfolder and files
Special (list contents, read all properties, read permissions)              Group Objects
Special (list contents, read all properties, read permissions)              User Objects

These security settings should be inherited down the AD tree. Be aware that there might be some containers
and objects that do not inherit permissions from their parent and therefore, might not have the Pre-
Windows2000 security settings correct. These folders and objects will be unavailable to winbind. Winbind will
display an exception error code (e.g. 0xc00000022) when trying to access these types of objects

This procedure focuses on the domain, student.example.com, since ultimately students will be restricted from
accessing the internet. Therefore, a Global1 group was created in the student domain and this group was named
NoINETAccess.

Building, Installing and Configuring Samba
If Samba was installed during the installation of RedHat 7.3, uninstall it. The rpm version that shipped with
RedHat 7.3 was not configured with support for all winbind features required for this procedure. Winbind is the
Samba component that allows a linux box to act as a Window‟s machine in various ways. You can download

1
        Must be Global or Universal group. Domain Local groups are not visible to winbind.
                                                              3
the latest Samba source from www.samba.org, but be aware that using and combining different versions of
Samba and Squid may result in neither package working as expected. For this procedure, it is recommend to
use exact version used here. The version of Samba used in this procedure is 2.2.6-1.

Building and Installing Samba
Samba needs to be compiled to include support for winbind. To do so, compile it with the --with-winbind --
with-winbind-auth-challenge options i.e.

[root@squidy source]#./configure --with-winbind --with-winbind-auth-challenge

Next make the binaries for Samba using the make command…then make install.

Configuring Samba
Copy the libnss_winbind.so file from source/nsswitch directory to /lib. Create a symlink for this file as
follows: ln –s /lib/libnss_winbind.so /lib/libnss_winbind.so.2.

The pam_winbind.so file can be made if PAM will be implemented for any services. However, for this
configuration of authentication from Squid, this module is not needed. From the source directory run the
following: source#make nsswitch/pam_winbind.so. Then copy this file to /lib/security.

To link these newly created libraries, run the following command: root#/sbin/ldconfig –v | grep winbind.

Next, the /etc/nsswitch.conf file needs to be altered to include winbind support. Find the passwd, shadow, and
group lines, and insert winbind as shown below:

passwd:          files winbind nisplus
shadow:          files winbind nisplus
group:           files winbind nisplus

Now, the smb.conf needs to be configured by adding a few lines to the Global Settings section. Copy the
default RedHat smb.conf from the samba-2.2.6/packaging/RedHat directory to the /usr/local/samba/lib
directory. Contrary to the Samba/Winbind documentation, for this procedure no winbind separator needs to be
specified2. The following lines can be added to the top of the Global Settings section.

winbind cache time = 15
template shell = /bin/false #or /bin/bash (only needed if telnet (or similar) access allowed for users)
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes

The following options are already present in the smb.conf file, but need to be configured correctly. Find these
options and edit them accordingly.

workgroup = STUDENT
security = domain
password server = odin.student.example.com

2
          It was found that setting the winbind separator to “+” causes problems with Squid‟s wb_group and its ability to read the
current user‟s credentials obtained by %LOGIN. Therefore, let winbind use the default separator “\” by not specifying a separator in
the smb.conf file. This enables wb_group to function properly.
                                                                  4
encrypt passwords = yes

To ensure that the password server listed in the smb.conf file is accessible, add the following line to the
/etc/hosts file.

192.168.1.26 odin.student.example.com         odin

In addition, it is important that the linux box is configured to use the DNS server odin.student.example.com
(192.168.1.26) or another DC for this domain. Since odin is in the same Window‟s “site” as the linux box, odin
should be used.

The machine now needs to be joined to the Windows 2000 domain. Use the following command to join to the
domain: root#/usr/local/samba/bin/smbpasswd –j STUDENT –r ODIN –U administrator (where administrator
is a username of someone with access to join machines to the domain). If the join process was successful, a
message will appear stating so.

Start winbind and test it using the wbinfo tool found in /usr/local/samba i.e. /usr/local/samba/bin/wbinfo –u. If
you see all domain users, winbind is operating correctly. Note that with the default winbind separator, the
syntax of the test for wbinfo –a is student\\username%password…you have to add an extra backslash.

If problems are encountered at this point, the most commonly found issues have been related to security in
Active Directory preventing the linux box from accessing group and account information, or name resolution
related to DNS problems.

Building, Installing and Configuring Squid
Like Samba, if Squid was installed during the installation of RedHat 7.3, it should be uninstalled because it
wasn‟t compiled with all necessary functionality for this procedure. The latest Squid source can be
downloaded from www.squid-cache.org, but it is important to use the same version of Squid as outlined in this
manual, squid-2.5-STABLE1-20021119. If the web-based cache management tool included with Squid will be
used, make sure Apache is installed on the linux box.

The Winbind interface changed in Samba-2.2.6 and therefore, the winbind components of Squid-2.5stable1
don‟t work correctly. To enable the Squid winbind components to work correctly, before compiling squid,
replace the Squid versions of winbindd_nss.h located in the squid/helpers/ directories (there are three: one in the
basic_auth/winbind, one in the ntlm_auth/winbind, and one in the external_acl/winbind_group directories) with
the Samba version of winbindd_nss.h found in samba/source/nsswitch.

Building and Installing Squid
Several command-line options need to be specified during the configure process to ensure Squid is built with
support for winbind integration. They are

--enable-auth=”ntlm,basic”
--enable-basic-auth-helpers=”winbind”
--enable-ntlm-auth-helpers=”winbind”
--enable-external-acl-helpers=”winbind_group”

and if using the ldap external acl helper, use the following options to replace their corresponding options above.

--enable-basic-auth-helpers=”LDAP”
--enable-external-acl-helpers=”ldap_group”

                                                         5
The following command was used to compile Squid:

./configure --enable-auth=”ntlm,basic” --enable-basic-auth-helpers=”winbind” --enable-ntlm-auth-
helpers=”winbind” --enable-external-acl-helpers=”winbind_group”

This should all be on one line with no carriage returns.

After configure is done, run make. Then run make install.

Configuring Squid
Now the squid.conf file needs to be configured. It may be helpful to eventually have a minimal squid.conf file,
but to begin with, the default configuration file will be modified to suit the needs of this procedure. During the
Squid installation, a backup copy (squid.conf.default) of the squid.conf file was created and can be found in
/usr/local/squid/etc. Edit the squid.conf file and uncomment, edit or add the following lines:

visible_hostname ares

auth_param ntlm program /usr/local/squid/libexec/wb_ntlmauth
auth_param ntlm children 5
auth_param ntlm max_challenge_resuses 0
auth_param ntlm max_challenge_lifetime 2 minutes

auth_param basic program /usr/local/squid/libexec/wb_auth
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
(really don‟t need any of these basic auth_params for this procedure)

external_acl_type W2Kgroup %LOGIN /usr/local/squid/libexec/wb_group

acl Student_NOINET external W2Kgroup NoINETAccess
acl Allowed proxy_auth REQUIRED

http_access deny Student_NOINET
http_access allow Allowed

Without starting Squid, run wb_group to test whether or not this tool can determine if a given user is a member
of a particular Window‟s group e.g. run /usr/local/squid/libexec/wb_group –d. At the (lack of) prompt, enter
student\\username NoINETAccess. If successful, a list should be displayed of SIDs and groups that this user is
a member of followed by “OK” if the user is a member of the specified group. Otherwise, the “ERR” message
is displayed. When the “ERR” is displayed in the absence of any SIDs, there was an error by wb_group
communicating with the domain. This error is vague and can be difficult to troubleshoot. No specific
recommendations can be given when this error is encountered.

It was found that /usr/local/squid/var permissions are not set correctly initially for squid to function properly.
Since squid runs as nobody (user and group) when started by root, the var dir user and group need to be changed
to “nobody” instead of “root”. Apply these changes recursively by running the following commands:

root#chown –R nobody /usr/local/squid/var
root#chgrp –R nobody /usr/local/squid/var
                                                           6
Start squid with the –z option (/usr/local/squid/sbin/squid –z); this creates swap and cache directories. Then
start squid normally and test it using a client machine. Set the client machine to use ares as a proxy server for
Internet Explorer.

When a change is made in AD for the group membership of NoINETAccess, both Winbind and Squid need to
be restarted to see this change immediately. Restart Winbind first, then Squid.

IPTables Firewall Configuration
The linux box needs to be protected from attack from both internal and external sources. Therefore a firewall
needs to be configured, and iptables was chosen since it is more robust and flexible than ipchains. The concept
behind what needs to be accomplished by iptables is relatively simple. Only secure shell traffic can directly
connect to the linux box from the external interface, but all traffic from the internal interface is accepted (threats
from internal sources will be handled via redirection3 to port 3128). ICMP traffic is rate limited to prevent flood
attacks. All traffic destined for another machine is allowed to be forwarded. All packets originating from the
linux box are allowed out. In addition, on the internal interface, four addresses are NATted (requests from
external sources are NATted by the firebox).

Setting Default Policies
From the command prompt, run the following to set default policies. These can be changed to suit differing
needs.

prompt# iptables -P INPUT DROP
prompt# iptables -P OUTPUT ACCEPT
prompt# iptables -P FORWARD ACCEPT

Setting INPUT rules
iptables –A INPUT –i lo –j ACCEPT
iptables –A INPUT –p tcp --dport 22 –j ACCEPT
iptables –A INPUT –i eth2-i –j ACCEPT
iptables –A INPUT –m state --state ESTABLISHED –j ACCEPT
iptables –A INPUT –p icmp –m icmp --icmp-type 8 –m limit --limit 1/sec –j ACCEPT
iptables –A INPUT –p icmp –m icmp --icmp-type 8 –j DROP
iptables –A INPUT –p icmp –m icmp ! --icmp-type 8 –j ACCEPT

itpSetting NAT rules
iptables -t nat -A PREROUTING -i eth2 -d 205.168.220.35 –j DNAT --to 192.168.1.20
iptables -t nat -A PREROUTING -i eth2 -d 205.168.220.36 –j DNAT --to 192.168.1.13
iptables -t nat -A PREROUTING -i eth2 -d 205.168.220.37 –j DNAT --to 192.168.1.37
iptables -t nat -A PREROUTING -i eth2 -d 205.168.220.100 –j DNAT --to 192.168.1.4
iptables -t nat -A PREROUTING -i eth2-i –s ! 192.168.1.14 –d ! 128.121.26.136 -p tcp -m multiport --dport
80,443 -j DNAT --to 192.168.1.25:3128 (the –s ! address is to allow linux mail server antivirus software to pull
virus defs automatically since this software can use an auth proxy; the –d ! address it to allow the Weatherbug
software to pull weather updates)
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.20 -o eth2 -j SNAT --to 192.168.1.25
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.13 -o eth2 -j SNAT --to 192.168.1.25

3
          It was found that for ftp connections to be proxied from Internet Explorer, the Advanced Internet Option “Enable Folder
view for FTP sites” should be disabled. This can be accomplished using a vbscript that sets the value of the proper registry value. The
registry value that needs to be set is HKCU\Software\Microsoft\Ftp\Use Web Based Ftp … this value should be set to “yes”. Refer to
the section Forcing Internet Explorer clients to use web-based FTP.
                                                                  7
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.37 -o eth2 -j SNAT --to 192.168.1.25
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.4 -o eth2 -j SNAT --to 192.168.1.25

Each of the SNAT lines about can also used the MASQUERADE option instead of the SNAT segment.
MASQUERADE is just another form of SNAT. Therefore, each of the SNAT lines above can actually be
replaced by the following:

iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.20 -o eth2 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.13 -o eth2 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.37 -o eth2 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.4 -o eth2 -j MASQUERADE

There is a limitation with this NAT however, in that these NAT rules only apply and work when a client is not
using the proxy. When the client is using the proxy, requests for these addresses originate from squid (i.e. the
localhost), and DNAT is not fully implemented in iptables for OUTPUT packets (packets originating on the
linux box). This should not be a problem for standard users, as long as requests for domain names are translated
to internal IPs. On machines (headache) where the external IP is requested directly, the use of a proxy server
should be disabled to allow access to these external IPs.

There may be a time when all unnecessary traffic on ports 1024 to 65535 should be redirected to the proxy
server. This can be accomplished with the following:
iptables –t nat –A PREROUTING –i eth2-i –p tcp –dport 1024:65535 –j DNAT –to 192.168.1.25:3128

Once these rules are active in iptables, this configuration can be saved to a file, /etc/sysconfig/iptables, by
running the following:

prompt#service iptables save

Everytime iptables is restarted, it will now load this configuration.

Startup Scripts
Startup scripts need to be created to manage each program: winbindd, smbd, nmbd, and squid.
Original startup scripts (installed from rpms) for samba, winbind, and squid can be found on dist70_test. Copy
these scripts to the /etc/init.d directory. Finally, create symlinks to facilitate each script‟s functionality and set
the mode for each to allow root to run these scripts.


Samba
Created the following symlinks:
       ln –s /usr/local/samba/var/locks /var/cache/samba
       ln –s /usr/local/samba/bin/smbd /usr/sbin/smbd
       ln –s /usr/local/samba/bin/nmbd /usr/sbin/nmbd
       ln –s /usr/local/samba/lib /etc/samba

Winbind
The samba symlinks take care of most requirements of winbind. Need to add one more symlink.
      ln –s /usr/local/samba/bin/winbindd /usr/sbin/winbindd

Squid
Created the following symlinks.
       ln –s /usr/local/squid/var/logs /var/cache/squid
                                                           8
        ln –s /usr/local/squid/sbin/squid /usr/sbin/squid
        ln –s /usr/local/squid/etc /etc/squid

Setting mode
Change directory to /etc/init.d and run the following commands to set the mode on each startup script.

prompt#chmod u+x samba
prompt#chmod u+x squid
prompt#chmod u+x winbind

Routing on the Linux box
Routing on the linux box is relatively straight forward. However, there is one small quirk with RedHat in that
by default, ip forwarding is disabled. This means that traffic coming in one NIC won‟t be forwarded to the
other NIC. Therefore, ip forwarding should be enabled.

Adding Routes
Necessary routes are as follows:
192.168.1.0 go out internal NIC (eth2)          192.168.7.0 go out eth2         192.168.13.0 go out eth2
192.168.2.0 go out eth2                         192.168.8.0 go out eth2         192.168.14.0 go out eth2
192.168.3.0 go out eth2                         192.168.9.0 go out eth2         192.168.15.0 go out eth2
192.168.4.0 go out eth2                         192.168.10.0 go out eth2        192.168.16.0 go out eth2
192.168.5.0 go out eth2                         192.168.11.0 go out eth2        192.168.17.0 go out eth2
192.168.6.0 go out eth2                         192.168.12.0 go out eth2        192.168.18.0 go out eth2
192.168.19.0 go out eth2                        192.168.25.0 go out eth2
192.168.20.0 go out eth2                        192.168.30.0 go out eth2
192.168.21.0 go out eth2                        192.168.35.0 go out eth2
192.168.22.0 go out eth2

These routes can be setup to be loaded automatically everytime the network restarts. To do this, add these
routes to the /etc/sysconfig/static-routes file. The syntax of the static-routes file is different than that of the
route command. For instance, adding a route with the route command would be done like this

prompt#route add –net 192.168.1.0 dev eth2

In the static-routes file, the line to add this route would be as follows:

eth2 net 192.168.1.0

Add each route to the static-routes file in the above format.

Enabling IP Forwarding
Before any routing will work on the linux box, the kernel must be instructed to forward ip packets. By default
under RedHat 7.3, ip forwarding is disabled. It can be enabled quite easily by editing the /etc/sysctl.conf file
and changing the “0” to “1” for the line pertaining to ip forwarding.

WatchGuard Firebox II Plus: Configuring Routes, NAT, and VPN
To pass traffic to and from the linux box, several factors need to be considered when configuring the firebox.
The firebox should be setup in “Drop-In” mode (refer to Watchguard documentation for further explanation),
and a secondary network should be created on the Trusted interface. This secondary network should be of the
same network as the external NIC on the linux box. For instance, the firebox has a secondary network of
                                                            9
192.168.255.1/24 on the Trusted interface. The external NIC on the linux box therefore has an IP of
192.168.255.2/24. These two hardware devices are plugged into the “External” VLAN on the HP Procurve.
Also plugged into this external VLAN is Athena (IP address of 192.168.255.3) to serve as the logging host for
the firebox. (Currently, Watchguard software version is 6.1 with hotfix released on 11-02-2002.)

Routing
According to the Watchguard documentation, the firebox does not support routing protocols, so all routes on the
firebox must be setup as static. To setup these routes, open the Watchguard Control Center, open the Policy
Manager, click the Network menu and select the Routes option. Create network routes using gateway of
192.168.255.2 for all internal networks as follows:

network        gateway               network        gateway                network        gateway
192.168.1.0    192.168.255.2         192.168.12.0   192.168.255.2          192.168.25.0   192.168.255.2
192.168.2.0    192.168.255.2         192.168.13.0   192.168.255.2          192.168.30.0   192.168.255.2
192.168.3.0    192.168.255.2         192.168.14.0   192.168.255.2          192.168.35.0   192.168.255.2
192.168.4.0    192.168.255.2         192.168.15.0   192.168.255.2
192.168.5.0    192.168.255.2         192.168.16.0   192.168.255.2
192.168.6.0    192.168.255.2         192.168.17.0   192.168.255.2
192.168.7.0    192.168.255.2         192.168.18.0   192.168.255.2
192.168.8.0    192.168.255.2         192.168.19.0   192.168.255.2
192.168.9.0    192.168.255.2         192.168.20.0   192.168.255.2
192.168.10.0   192.168.255.2         192.168.21.0   192.168.255.2
192.168.11.0   192.168.255.2         192.168.22.0   192.168.255.2

“1 to 1 NAT” (A.K.A. Destination NAT)
Watchguard refers to what is commonly known as destination network address translation (DNAT) as 1 to 1
NAT. This type of NAT converts a request for one IP address (regardless of what port is requested) to another
IP address. It is necessary to setup 1 to 1 NAT for any public IP addresses to map these IPs to the appropriate
server on the LAN that has a private address. Currently, there are four external IPs to be mapped to internal
addresses. To setup these 1 to 1 NATs, open the Policy manager, select the Setup menu and select the NAT
option. From the NAT dialog box, click the Advanced button, and then click the 1 to 1 NAT Setup tab. Enable
the checkbox Enable 1 to 1 NAT, and click Add. Select the external interface, Number of hosts is 1, NAT base
is 205.168.220.35 and Real base is 192.168.1.20, click OK. Repeat this for the remaining external IPs to be
NATted (205.168.220.36 -> 192.168.1.13, 205.168.220.37 -> 192.168.1.37, 205.168.220.100 -> 192.168.1.4).

From the Dynamic NAT Exception tab on the NAT dialog box, select Add. In the To box, select external
interface. Click the “…” button next to the From field and enter the Real (internal) IP address to be excluded.
For each 1 to 1 NAT rule, exclude the Real Base IP here on the Exception tab. Repeat this for each internal IP
used in each 1 to 1 NAT rule. NOTE: For 1 to 1 NAT to work, the external IPs NATted must NOT appear in
Aliases under Network Configuration, and internal servers must NOT be multihomed with external IPs.

PPTP VPN
The firebox can be setup to accept VPN connections using the PPTP protocol. Open the Policy manager, and
from the Network menu, select Remote User. From the Remote Users dialog box, click the PPTP tab, select the
option “Activate Remote User,” and add private IPs to be assigned to connections. For this procedure, class B
IPs were used since the preexisting class C IPs were being routed to the LAN. IPs entered here for VPN clients
must NOT be routed to the LAN or VPN connections will fail. Since the current setup for VPN connections
only has a max of ten pptp users, only ten IPs were entered (172.16.0.1 through 172.16.0.10).



                                                        1
                                                        0
The firebox must now be setup to use “firebox” authentication as opposed to RADIUS or NT Server
authentication. Open Policy manager, and from the Setup menu, select Firewall Authentication. Select Firebox
and click OK.

Users must be setup to access the firebox from external sources. To setup users, open Policy manger, and from
the Setup menu, select Authentication Servers. On the Authentication Servers dialog box, click the Firebox
Users tab, and at the bottom, click Add to add a group for PPTP VPN access. In this procedure, the added group
was named pptp-users. Now click Add at the top and enter username and password combinations for each user
that will access the firebox via VPN and make each user a member of the pptp-users group. Click OK when
finished adding users.

Lastly, if VPN users are to access the internet while connected, a new service should be created. Open the
Policy manger, and add a new service. From the Services dialog box, under Packet Filters select PPTP and
click OK twice. On the PPTP service dialog box, click the Incoming tab and change the drop-down menu for
“Incoming PPTP connections are” to Enabled and Allowed. Replace “Any” in the From section with pptp-
users, and replace the “Any” in the To section with external. On the Outgoing tab, replace the “Any” on the
From section with external and replace the “Any” on the To section with pptp-users. Click OK and save this
configuration to the firebox.

Domain Name Service (DNS) Configuration
In this procedure, there are generally two types of DNS servers, external and internal. External DNS servers are
standalone standard primary servers and are represented by cygnus.example.com and ns2.example.com. For
this procedure, external DNS servers should only contain public IP addresses, as they should for any
configuration. Therefore, for hosts that are reached via a 1 to 1 NAT, each servers public IP should appear in
the external DNS servers database.

Internal DNS servers in this procedure consist of Windows 2000 domain controllers (DC) running Active
Directory DNS. Internal DNS servers should only contain private IPs. Since internal clients can access private
IPs routed on the local network, to which internal DNS servers belong, there is no need to NAT requests to these
servers from internal clients. In addition, internal DNS servers are not accessed by external clients, thus further
nullifying the need for external IPs in the internal DNS server‟s database. NOTE: The linux box still contains
NAT rules for requests for public IPs on the internal interface, and this is just to be thorough. Some internal
client may be configured to directly request public IPs in use on the LAN. Since there are no longer any public
IPs in use on the LAN, a NAT rule must be present to accommodate the request and return the corresponding
private IP.

Enabling Domain Clients to Use Squid
Client browsers can be configured to use the proxy server via Group Policy. In the domain‟s Global Group
Policy, edit the User Configuration>Windows Settings>Internet Explorer Maintenance>Connection>Proxy
Settings. Select “Enable Proxy Settings” and enter 192.168.1.25 port 3128 for the “HTTP” line. Select “Use
the same proxy server for all addresses” and select “Do not use proxy server for local (Intranet) addresses.”
Add the following to the “bypass proxy for these addresses”: http://www.example.com,
http://www2.example.com, etc.

Forcing Internet Explorer Clients to Use Web-Based FTP
A peculiarity of Windows 2000 and Internet Explorer was found that would allow ftp connections to bypass the
proxy server. This peculiarity is the option in Internet Explorer to “Enable Folder view for FTP sites”. This
method of ftp uses an apparently alternate protocol and/or alternate port for ftp connections. A user blocked
from internet access could use this feature to bypass the proxy server and gain access to the internet.

                                                        1
                                                        1
To remedy this problem, a workaround has been devised that utilizes Group Policy and a vbscript login script to
disable Folder view and enable Web-based ftp.

In each schools GPO (the school‟s general GPO applied at the organizational unit (OU) level), disable changing
any advanced options on the Advanced tab of the Internet Options control panel. To do this, open the GPO and
navigate to User Configuration>Administrative Templates>Windows Components>Internet Explorer (click on
Internet Explorer) and enable the option “Disable changing Advanced page settings.”

To disable Folder view for FTP sites (enable Web-based ftp), create a vbscript. To do so, copy an paste the
following text into a blank notepad document and save it as EnableWebBasedFTP.vbs. Copy this script to
\\student.example.com\sysvol\student.example.com\scripts. Additionally, the script can be encoded using the
Microsoft Script encoder to hinder a user from determining the mechanism the script uses to enable Web-based
FTP. Download the script encoder from the msdn website and run it with the following command:

c:\screnc EnableWebBasedFTP.vbs EnableWebBasedFTP.vbe

„--------------------------------------------------------------------
„Enable Web-Based FTP
„Language: VBScript

Dim WshShell
Set WshShell = WScript.CreateObject("WScript.Shell")

WshShell.RegWrite "HKCU\Software\ Microsoft\Ftp\Use Web Based FTP", "yes", "REG_SZ"

„End Of Script
„---------------------------------------------------------------------


To apply this script as a logon script designate it as a logon script in each site‟s GPO. Navigate to User
Configuration>Windows Settings>Scripts(Logon/Logoff)>Logon and add the script. The next time the user
logs onto the computer, Web-Based FTP will be enabled.

Performance Tuning the Squid Proxy Server
There are numerous options in the squid.conf file that can be configured, but most options will suffice with
default values. There are however, a few options that can be modified to better suit this procedure. The
following options can be changed from default:

http_port
X   http_port 192.168.1.25:3128

icp_port
# Disable this by setting it to 0
X   icp_port 0

cache_dir
X   cache_dir ufs /usr/local/squid/var/cache 20000 160 2560

Positive DNS Cache TTL
X   positive_dns_ttl 24 hours
                                                                  1
                                                                  2
cache_mgr
Currently, this option is set to webmaster. webmaster mail should be forwarded to your email address of choice.

cachemgr_passwd
Should be set for all
X   cachemgr_passwd _your_password_ all




                                                      1
                                                      3

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:32
posted:7/13/2011
language:English
pages:13