MAC based filtering in squid

MAC based filtering is useful for networks using DHCP to assign ip addresses to systems. As we know MAC is hard coded on NIC and can’t be changed but IP addresses assigned by DHCP may change on next ip assignment. This tutorial will help you to how to Configure Squid Proxy Server Mac Address Based Filtering.

If you do not have Squid installed, Go to below link for installing squid on CentOS/RHEL/Fedorasystems.

Install and Configure SQUID Proxy Server on CentOS/RHEL Linux

ACL rules are need to add in squid configuration file /etc/squid/squid.conf. Remember that squid Squid always applied first matching rules from top to down order and ignore other after matching any rule

1. Block All Sites For Single MAC Address

Following configuration will block all the sites to system having MAC address 01:23:45:AB:CD:EF.

Squid ACL Rule:

acl pcmac1 arp 01:23:45:AB:CD:EF
http_access deny pcmac1

2. Block Single Site for Single MAC Address

Following configuration will block www.example.com site to system having MAC address 01:23:45:AB:CD:EF.

Squid ACL Rule:

acl blocksite1 dstdomain www.example.com
acl pcmac1 arp 01:23:45:AB:CD:EF
http_access deny blocksite1 pcmac1 

3. Block All Sites for Multiple MAC Addresses

Following configuration will block all the sites to systems having MAC addresses 01:23:45:AB:CD:EF and AB:CD:EF:01:23:45.

MAC Addresses List

# cat /etc/squid/mac-addrs.lst
01:23:45:AB:CD:EF
AB:CD:EF:01:23:45

Squid ACL Rule:

acl pcmacs arp "/etc/squid/mac-addrs.lst"
http_access deny pcmacs

4. Block Single Site for Multiple MAC Addresses

Following configuration will block www.example.com to systems having MAC addresses 01:23:45:AB:CD:EF and AB:CD:EF:01:23:45.

MAC Addresses List

# cat /etc/squid/mac-addrs.lst
01:23:45:AB:CD:EF
AB:CD:EF:01:23:45

Squid ACL Rule:

acl blocksite1 dstdomain www.example.com
acl pcmacs arp "/etc/squid/mac-addrs.lst"
http_access deny blocksite1 pcmacs

5. Allow Specific Site for Single MAC Address

Following configuration will allow www.example.com to system having MAC address 01:23:45:AB:CD:EF and deny other sites.
Squid ACL Rule:

acl pcmac1 arp 01:23:45:AB:CD:EF
acl allowsite1 dstdomain www.example.in
http_access allow allowsite1 pcmac1
http_access deny pcmac1

6. Allow Multiple Sites for Single MAC Address

Following configuration will allow all sites added in /etc/squid/allowsites.lst to system having MAC address 01:23:45:AB:CD:EF and deny other sites.

Allowed Sites List

# cat /etc/squid/allowsites.lst
www.google.co.in
yahoo.com
in.yahoo.com

Squid ACL Rule:

acl pcmac1 arp 01:23:45:AB:CD:EF
acl allowsite1 dstdomain "/etc/squid/allowsites.lst"
http_access allow allowsite1 pcmac1
http_access deny pcmac1

7. Allow Specific Site for Multiple MAC Addresses

Following configuration will allow www.example.com to systems having MAC address 01:23:45:AB:CD:EF and and AB:CD:EF:01:23:45 and deny other sites.

MAC Addresses List

# cat /etc/squid/mac-addrs.lst
01:23:45:AB:CD:EF
AB:CD:EF:01:23:45

Squid ACL Rule:

acl blocksite1 dstdomain www.example.com
acl pcmacs arp "/etc/squid/mac-addrs.lst"
http_access allow blocksite1 pcmacs
http_access deny pcmacs

8. Allow Multiple Sites for Multiple MAC Addresses

Following configuration will allow all the sites listed in /etc/squid/allowsites.lst to all systems having MAC address listed in /etc/squid/mac-addrs.lst and deny other sites.

MAC Addresses List

# cat /etc/squid/mac-addrs.lst
01:23:45:AB:CD:EF
AB:CD:EF:01:23:45

Allowed Sites List

# cat /etc/squid/allowsites.lst
www.google.co.in
yahoo.com
in.yahoo.com

Squid ACL Rule:

acl pcmacs arp "/etc/squid/mac-addrs.lst"
acl allowsites dstdomain "/etc/squid/allowsites.lst"
http_access allow allowsites pcmacs
http_access deny pcmacs

Flushing iptables rules in centos

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

How Squid ACLs work

For less experienced Squid administrators the concept of ACLs can be confusing at first. But they offer a great way of controlling who is allowed to access which web pages when.

ACLs

First you need to define certain criteria like accesses from the marketing department or accesses to google.com or need to authenticate. There are certain types of ACLs for that purpose. The complete list of ACLs can be found at http://www.visolve.com/squid/squid24s1/access_controls.php
The syntax of an acl is:

acl name type definition1 definition2 definition3 ...

Examples:

acl accesses_to_google dstdomain .google.com
acl accesses_to_search_engines dstdomain .yahoo.com .google.com .vivisimo.com
acl accesses_from_marketing_department src 10.52.0.0/16
acl need_to_authenticate proxy_auth

You can also use lists of definitions that are stored in files on your hard disk. Let's assume you have a list of search engines URLs that you want to allow:

/etc/squid/search-engines-urls.txt:
.google.com
.yahoo.com
.altavista.com
.vivisimo.com

Then the ACL for that file would look like:

acl accessess_to_search_engines dstdomain "/etc/squid/search-engines-urls.txt"

The quotes are important here to tell Squid it needs to look up definitions in that file.

Using the ACLs: http_access

Defining the ACLs alone does not actually block anything - it's just a definition. ACLs can be used in various places of your squid.conf. The most useful feature is the http_access statement. It works similar to the way a firewall would handle rules. For each request that Squid receives it will look through all the http_access statements in order until it finds a line that matches. It then either accepts or denys depending on your setting. The remaining rules are ignored.
The general syntax of an http_access line is:

http_access (allow|deny) acl1 acl2 acl3 ...

Example:

http_access allow accesses_from_admins
http_access deny accesses_to_porn_urls
http_access allow accesses_during_lunchtime
http_access deny all

This would allow accessing from the admins (whatever that ACL looks like - probably a src ACL pointing to the subnet where the admin workstations are in). For everyone else it will deny accesses to porn URLs. Then it would allow accesses from everyone to every web site during lunch time. And finally all other accesses would be denied.

Combining ACLs (AND/OR)

Often you need to combine ACLs. Let's say you want to allow access to google.com only for the back office. This combines two ACLS with an AND. This would look like this:

http_access allow accesses_to_google.com accesses_from_back_office

If you wanted to use an OR and say either accesses from the back office or accesses to google.com are allowed then the line would look like this:

http_access allow accesses_to_google.com
http_access allow accesses_from_back_office

To summarize: AND means putting the conditions in one line. OR means using seperate lines.

Custom error pages (deny_info)

By default when you deny access the user gets the error page that is stored in the ERR_ACCESS_DENIED file. But luckily you can define your own custom error pages and display them when you deny certain accesses. A simple example:

acl google dstdomain google.com
deny_info error-google google
http_access deny google

Put an error page into the directory where the HTML files are stored (look for error_directory in your squid.conf) and name it error-google. If the user tries to access www.google.com the access is denied and your error page is shown.

Careful when you combine ACLs on a http_access line. Example:

acl google dstdomain google.com
acl admin src 10.0.5.16
deny_info google error-google
http_access deny admin google

This will deny access only for the user from the IP address 10.0.5.16 when www.google.com is accessed. As you can see I have combined the ACLs admin and google. In such a combination the last ACL in the line is taken into account for lookups of deny_info. So it's important that you define a deny_info for the google ACL.

Re-Authentication control

Usually when a user is authenticated at the proxy you cannot "log out" and re-authenticate. The user has to close and re-open the browser windows to be able to re-login at the proxy. A simple configuration will probably look like this:

acl my_auth proxy_auth REQUIRED
http_access allow my_auth
http_access deny all

Now there is a tricky change that was introduced in Squid 2.5.10. It allows to control when the user is prompted to authenticate. Now it's possible to force the user to re-authenticate although the username and password are still correct. Example configuration:

acl my_auth proxy_auth REQUIRED
acl google dstdomain .google.com
http_access allow my_auth
http_access deny google my_auth
http_access deny all

In this case if the user requests www.google.com then the second http_access line matches and triggers re-authentication. Remember: it's always the last ACL on a http_access line that "matches". If the matching ACL has to do with authentication a re-authentication is triggered. If you didn't want that you would need to switch the order of ACLs so that you get http_access deny my_auth google.
You might also run into an authentication loop if you are not careful. Assume that you use LDAP group lookups and want to deny access based on an LDAP group (e.g. only members of a certain LDAP group are allowed to reach certain web sites). In this case you may trigger re-authentication although you don't intend to. This config is likely wrong for you:

acl ldap-auth proxy_auth REQUIRED
acl ldapgroup-allowed external LDAP_group PROXY_ALLOWED

http_access deny !ldap-auth
http_access deny !ldapgroup-allowed
http_access allow all

The second http_access line would force the user to re-authenticate time and again if he/she is not member of the PROXY_ALLOWED group. This is perhaps not what you want. You rather wanted to deny access to non-members. So you need to rewrite this http_access line so that an ACL matches that has nothing to do with authentication. This is the correct example:

acl ldap-auth proxy_auth REQUIRED
acl ldapgroup-allowed external LDAP_group PROXY_ALLOWED
acl dummy src 0.0.0.0/0.0.0.0

http_access deny !ldap-auth
http_access deny !ldapgroup-allowed dummy
http_access allow all

This way the second http_access line still matches. But it's the dummy ACL which is now last in the line. Since dummy is a static ACL (that always matches) and has nothing to do with authentication you will find that the access is just denied.
References:

• http://www.squid-cache.org/bugs/show_bug.cgi?id=1278
• http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE9-extaclauth
• http://www.squid-cache.org/mail-archive/squid-users/200511/0339.html

DHCP configuration file ( dhcpd.conf)

#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#   see 'man 5 dhcpd.conf'
#

ddns-update-style ad-hoc;
ddns-update-style interim;

#allow booting;
#allow bootp;
#ingnore client-updates;

default-lease-time 600;
max-lease-time 7200;

#log-fecility local7;

subnet 192.168.0.0 netmask 255.255.255.0 {
option broadcast-address 192.168.0.255;
range 192.168.0.10 192.168.0.100;
option domain-name-servers 218.248.255.145 , 14.139.5.5 , 8.8.8.8 , 8.8.4.4;
option routers 192.168.0.1;
default-lease-time 600;
max-lease-time 7200;
}
}

Internet Sharing with NAT using two NICs in CentOS

Configure two NICS

2. Active now screen

2.1. eth0 config

3. eth3 config

3.1 Change NIC, on which DHCP has to configure

gedit /etc/sysconfig/dhcpd

4. DHCP server config

5. subnet config

6. Edit client options

 

7. eth3 NIC config

8. Enable Ip forwarding in nano /etc/sysctl.conf

# Controls IP packet forwarding

net.ipv4.ip_forward = 1

9. Save Ip forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

10. FireWall settings NAT


iptables -A FORWARD -o eth0 -i eth3 -s 192.168.0.0/24 -m conntrack --ctstate NEW -j ACCEPT

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -t nat -F POSTROUTING

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

/sbin/service iptables save

OR

iptables -A FORWARD -o eth0 -i eth3 -s 192.168.0.0/24 -m conntrack --ctstate NEW -j ACCEPT

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -t nat -F POSTROUTING

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

iptables-save | sudo tee /etc/iptables.sav

/etc/sysconfig/iptables.save

/sbin/service iptables save