Squid Proxy Implementation Lab: Configuration, ACLs and Access Rules

The IP configuration of both virtual machines was checked to verify that the network interfaces were properly configured. The lab uses two virtual machines: one Linux machine, which will be used as the proxy server, and one Windows 10 machine, which will be used as the client.

On the Linux VM, the IP configuration was checked using:

ip addr

On the Windows 10 VM, the IP configuration was checked using:

ipconfig

The output of these commands shows the network interfaces and their assigned IP addresses. This confirms that both virtual machines are connected to the configured internal network and are ready for the proxy implementation.

Squid was installed on the Linux virtual machine, which was configured as the proxy server. After installing the Squid package, the Squid service was checked using the service squid status command. The service status confirmed that Squid was running successfully on the proxy server and was ready to provide proxy services to the client machine. The lab specifically requires the service status to be demonstrated with this command.

The http_port directive specifies the port on which the Squid proxy server listens for HTTP client requests. In the default Squid configuration, the value of http_port is 3128. Therefore, the proxy server is configured to listen for HTTP requests on port 3128.

The http_port setting can be found in the Squid configuration file, usually located at:

/etc/squid/squid.conf

The relevant configuration line is:

http_port 3128

This confirms that Squid is using port 3128 as its default HTTP proxy port.

In the Squid configuration file, the localnet object is defined as an ACL (Access Control List). This ACL represents the local network addresses that can be controlled by Squid rules. The localnet ACL definitions are located under the Access List section of the configuration file.

For this question, commented lines beginning with # should be ignored. The active lines defining localnet should be shown.

Configuration:

acl localnet src 10.0.0.0/8

acl localnet src 172.16.0.0/12

acl localnet src 192.168.0.0/16

These entries define the private network ranges that Squid recognizes as localnet.

The http_access section of the Squid configuration file contains the rules that control access for the defined ACLs. After searching for http_access and scrolling to the relevant section, the configuration shows rules for both localhost and localnet.

In the default configuration, the rule for localnet is present but commented out, while the rule for localhost is active. Therefore, the localnet rule does not apply until its comment symbol (#) is removed.

Configuration to show:

http_access allow localnet

http_access allow localhost

The localnet allow rule is commented out in the default Squid configuration, so it is not active. The only active rule that is broader than localnet is:

http_access deny all

This rule denies all requests that have not been allowed by a previous active rule. Therefore, under the default configuration, clients in localnet cannot access the Internet through Squid.

With the default Squid configuration, neither the Windows client nor the Linux proxy server can browse the Internet through Squid using the localnet rule. The localnet access rule is commented out, while the active deny all rule blocks requests that are not allowed by an earlier rule.

Therefore, the Windows client cannot access the Internet through the proxy until the localnet rule is enabled.

On the Windows 10 client, the browser proxy settings were configured to use the Linux machine as the Squid proxy server. The proxy server’s internal IP address was entered as the proxy address, and port 3128 was entered as the proxy port. This configuration makes the Windows client send its Internet requests through the Squid proxy instead of connecting directly to the Internet.

I tried to access www.herzing.ca from the Windows client. The website could not be opened and an error page was displayed.

This error is coming from the Squid proxy server, because the browser request is being sent through Squid and Squid is blocking the request according to its current configuration.

In a real network, this type of restriction can be recommended when an organization wants to control Internet access and prevent users from visiting unwanted or restricted websites. However, the rules should be configured carefully so that useful and required websites are not blocked accidentally.

10. In the proxy server, change http_port for IP_INTERNAL_INTERFACE:3128 and remove the comment on the line http_access for localnet. Restart the service. What is the purpose of each of these changes?

In the Squid configuration file, I changed the http_port setting to use the internal IP address of the Linux proxy server with port 3128.

I also removed the comment (#) from the http_access allow localnet line. This allows computers in the local network to use the Squid proxy for Internet access.

After making these changes, I restarted the Squid service so that the new configuration could take effect.

Purpose of the changes:

· http_port IP_INTERNAL_INTERFACE:3128 tells Squid to listen for proxy requests on the internal network interface and port 3128.

· Enabling http_access allow localnet allows clients on the local network to access the Internet through Squid.

· Restarting Squid applies the new configuration.

These changes are necessary because, with the default configuration, the localnet access rule is disabled and the deny all rule blocks the client.

After enabling the localnet rule and restarting Squid, I tried to access www.herzing.ca again from the Windows client. This time, the website should open through the Squid proxy.

I then checked the network connections using the netstat command in Windows CMD.

The Windows client is not connected directly to the public IP address of the website because the client sends the HTTP request to the Squid proxy server first. Squid then connects to the Internet and forwards the requested web page back to the Windows client. Therefore, the client’s connection is established with the proxy server rather than directly with the public web server.

This shows that the Squid proxy is working correctly and is handling the Internet requests from the Windows client.

I created a new ACL named banned_sites under the Access List section of the Squid configuration file. The purpose of this ACL is to identify the IP addresses of Facebook and Instagram so that access to these sites can be blocked later.

The first ACL required by the lab is:

ACL for blocking Facebook and Instagram

acl banned_sites dst 31.13.71.36

The second ACL should contain the IP address identified for the other required site.

The lab document explicitly provides 31.13.71.36 for the first ACL, but it does not provide the second IP address in the supplied instructions, so I would not invent one.

I added the deny rule for the banned_sites ACL before the rule that allows access for the localnet network. This is important because Squid checks the access rules in order.

The configuration is:

Block access to banned sites

http_access deny banned_sites

Allow local network clients to use the proxy

http_access allow localnet

The banned_sites rule must come first so that the blocked sites are denied before the general localnet rule allows Internet access.

I checked both Facebook and Instagram from the Windows client browser. Both websites were blocked by the Squid proxy because their destination IP addresses were included in the banned_sites ACL. The browser did not allow access to either site, which confirms that the Squid blocking rule is working correctly.

I created an ACL named myself using the IP address of my Windows client. This ACL identifies my workstation.

Then, I modified the rule from Question 13 so that the banned_sites rule applies to all workstations except my own.

The configuration is:

Identify my workstation

acl myself src CLIENT_IP_ADDRESS

Block banned sites for all workstations except mine

http_access deny banned_sites !myself

The !myself part means that the rule does not apply to my workstation.

I created an ACL named business_hours to define the regular business working hours from Monday to Friday. I then used this ACL in the access rule so that workstations in the localnet network can have Internet access during these hours.

The configuration is:

# Define regular business hours: Monday to Friday, 09:00 to 17:00

acl business_hours time MTWHF 09:00-17:00

# Allow local network clients broad Internet access during business hours

http_access allow localnet business_hours

The business_hours ACL defines the allowed weekdays and time period, while the http_access allow rule allows clients in localnet to access the Internet during those hours.

If I needed to override the rule for my workstation, I would use the myself ACL in a separate rule before the general rule. This would allow my workstation to bypass the restriction that applies to the other workstations.

For example:

# Allow my workstation to bypass the restriction

http_access allow myself

# Apply the restriction to all other workstations

http_access deny banned_sites !myself

The important point is to place the exception rule before the general deny rule because Squid processes the access rules in order.

I created a single ACL named malware_virus using the dstdom_regex type. This ACL checks the domain name requested by the client and matches any domain that contains the word “malware” or “virus”.

I used one ACL instead of creating two separate ACLs, as required in the question.

The configuration is:

# ACL for domains containing the words malware or virus

acl malware_virus dstdom_regex -i malware|virus

The | symbol means OR, so the ACL will match a domain containing either malware or virus.

After creating the malware_virus ACL, I added an http_access deny rule to block websites whose domain contains either malware or virus.

I placed the deny rule before the general localnet allow rule because Squid checks the access rules from top to bottom. If the general allow rule comes first, the request could be allowed before reaching the blocking rule.

The rule in its context is:

# Block domains containing the words malware or virus

http_access deny malware_virus

# Allow my workstation

http_access allow myself

# Allow local network clients during business hours

http_access allow localnet business_hours

# Allow local network clients to use the proxy

http_access allow localnet

The http_access deny malware_virus rule tells Squid to reject any request that matches the malware_virus ACL. This prevents users from accessing domains containing either malware or virus.

tested both malwarebytes.com and virustotal.org from the Windows client. Both websites were blocked by Squid because their domain names contain the word “malware” or “virus”, which matches the malware_virus ACL created in the previous question.

To confirm that the rule was actually working, I checked the Squid access log file on the proxy server. The log showed denied requests for both websites with a TCP_DENIED/403 response.

This confirms that the requests reached the Squid proxy and were blocked by the configured access rule, rather than simply failing because of a network connection problem.

The relevant log file is:

/var/log/squid/access.log

Therefore, the malware_virus ACL and its corresponding http_access deny malware_virus rule are working correctly.