Linux Securirty Notes 15: IPTables 5 :IPTables Targets (-j)

IPTables Targets(-j)
Commonly used targets are
1. ACCEPT
     Sends packtes to other rule or process

2. DROP
     Drops the packet silently. Remote machine will not be aware about what happend to the packet.

3. REJECT
     When the rule met an error msg is send to client.
Eg of Reject:-

# iptables -A INPUT -p icmp --icmp-type echo-request -j REJECT

This will reject all the echo request part with a msg icmp-port-unreachable. If we ping to the host we will get a destination host unreachable.

4. REDIRECT
     This is used to redirect a current traffic to a desired target. It is applied to PREROUTING chain of NAT table.
Eg:-

# iptables -t nat -A PREROUTING -p tcp --dport 3128 -j REDIRECT --to-port 80

     This will redirect all the trafic coming to the destination port 3128 to 80.

# iptables -L -n -t nat -v

     Test with the verbose mode to get the packet count which hits the rule.

5. LOG
     This allow us to log the traffic which meets the rules from the level of debug to emergency using syslog.

IPTable Logs:
     It relies upon the kernel(kern) facility in syslog. So have to setup the syslog for logging the iptables activities.

Setup Logging
     Primarily we enable the logging in IPTables
Enabling the Log for a chain

# iptables -I INPUT 1 -p tcp --dport 22 -j LOG

This will start logging for the traffic which meets the above rule.(Logs all the incoming ssh request.) The default level of logging is warning. The Log level corresponds to the syslog.

# iptables -L -n -v

Check any packets hits the log

# tail -f /var/log/messages

This is the default place where undefined facilities logs to.So we the kern facility has been logging to /var/log/messages.
Configure syslog to log iptables activity separately:
We will change the facility to log to a seperate file

# vi /etc/syslog.conf
kern.none /var/log/messeges
kern.* /var/log/firewall.log

This will stop the kern facility to log to /var/log/messeges and redirects all levels of logs to /var/log/firewall.log

# service syslog reload

This will restart the syslog daemon and creates the file /var/log/firewall.log.
Test the Logging information by creating the traffic to port 22 on host.

# tail -f /var/log/firewall.log

brief about the log format:-
time- syslog facility - interface that revived the tracfic- MAC address of the remote system- MAC address of the local system - SRC IP- DSTIP - ID=packet sequence number - SPT=source port - DPT=destination port etc

Note:-
Generally logging should be enabled for separate chains & a specific rule. A catch all log for all the traffic will grow the log file numerously.

Loging All trafic

# iptables -A INPUT -j LOG
# tail -f /var/log/firewall.log

This will Log all traffic destined to the local server(INPUT). This will log all the protocols

Log All except a perticular protocol from host 192.168.1.53

# iptables -I INPUT 1 -p tcp ! --dport 22 -src 192.168.1.53 -j LOG
# tail -f /var/log/firewall.log

This will log everything except traffic to destination port 22

Log Excluding Multiple port in single rule

# iptables -I INPUT 1 -m multiport -p tcp --dport !80,8080 -j LOG
# tail -f /var/log/firewall.log

This will log all traffic except packet destined to port 80 and 8080.

Log using separate chains
Now we will check how to create a separate chain in IPTables for logging activities.
Create a New chain

# iptables -N LOGGER

Create a reference in INPUT chain to new chain LOG

# iptables -I INPUT 1 -j LOGGER

Create the logging rule in chain LOG

# iptables -A LOGGER -m multiport -p tcp --dport 21,22,80,143,8080 -j LOG
# tail -f /var/log/firewall.log

This will start logging ports 21,22,80,143 & 8080.

Loging the ssh access to the console.
In iptables:
Create a New CHAIN

# iptables -N SSHLOG

Create a reference in INPUT chain to new chain SSHLOG

# iptables -I INPUT 1 -j SSHLOG

Create the loging rule in chain LOG

# iptables -A LOGGER -p tcp --dport 22 -j LOG

In syslog:

# vim /etc/syslog.conf
kern.* /dev/console
# service syslogd restart

This will start logging any ssh access to the console.

Prefixing Interesting Traffic with a Log Prefix(--log-prefix "log prefix")

# iptables -A LOGGER -p tcp --dport 22 -j LOG --log-prefix "SSH Access Logs"

This will prefix the given string to the log. So it is easy to grep/awk the content from the log file.
Note:-
The Maximum prefix length is 29 characters.

Note:-
--log-level (debug to emer)
This will decide the level of log from debug to emergency level.

Linux Securirty Notes 15: IPTables 4 :IPTables Statefullness

IPTables Statefullness(-m state --state):
    IPTables provide state fullness. The state full firewall is considered more secure than stateless firewall because of their connection tracking capability and their ability to determine whether or not the session is new,related, invalid or established. Based on this criteria we can create more powerfull rules.
State Module:

# rpm -ql iptables | grep -i conntrack

/lib/iptables/libipt_conntrack.so

    This is the module that makes IPTables to behave as statefull. It is applicable for all the protocols (TCP/UDP/ICMP)
The states are:
NEW (The First SYN traffic)
ESTABLISHED
RELATED(SESSION/STATE)
INVALID
    When a user creates a TCP/UDP based session IPTables can follow the connection. Here IPTable will keep a track with SYN, ACK-SYN, ACK and labelled with NEW(for SYN), ESTABLISHED or RELATED (For all other subsequent connections).

Example:
Permit Host to Initialte the connection and deny other hosts from initiating traffic to our host.

# Default Policy to Drop All connection
# iptables -P INPUT DROP
# iptables -P OUTPUT DROP
# State Rule
# iptables -A OUTPUT -m state --state NEW,ESTABLISHED -j ACCEPT
    This will allow creating a NEW session (SYN) with outside and continue the ESTABLISHED  connections(regardless of protocol(UDP/TCP))
# iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
    After initiating a traffic to any other machine, the traffic will be permitted when it comes back.(regardles of protocol(UDP/TCP))

End Result:
The host will be able to make all connections to out side(NEW & ESTABLISHED is allowed in OUTPUT chain).
All new connection coming to our system will be dropped(No NEW is defined in INPUT chain only  ESTABLISED as well the default rule of DROP) only allows the ESTABLISHED connections(Initiated by our host)

The details of the connection tracking will be stored in

# cat /proc/net/ip_conntrack

    This file contains the status of all the established connections in the system for all protocols. The number of packets that transmitted, The
source and destination address, source and destination port etc.

Linux Securirty Notes 15: IPTables 3: Matching Traffic

IPTables Building Rules with Source, Destination of IP, MAC, Protocols & Port
   
    Here we will deal with the possibilities to match the traffic to define the rule, i.e, matching destination & source IP/MAC/PORT/PROTOCOL, Interfaces,Usage of Wildcards etc.

Matching the traffic based on Source and destination:
--src/-s/--source
--dst/-d/--destination
    These are the switches used to match the source and destination of the traffic. Widely used while rules created based on source and destination address
Eg:-
Blocking all the traffic from a source (192.168.1.200) (--src)

# iptables -A INPUT --src 192.168.1.200 -j DROP

    This Drops all the incoming traffic to out server from the Source 192.168.1.200. Here the match of source is used by "--src".
Blocking all the traffic To a destination from our server (--dst)

# iptables -A OUTPUT --dst 192.168.1.200 -j DROP

    This Drops all the outgoing traffic in our server to 192.168.1.200. Here the match of destination is used by "--dst".

Matching Based on Interface:
    It is useful while creating the rules based on a particular interface.
(-i eth0/eth1.. etc)
    switch "-i" is used to match the traffic with the interface to define the rule.
Eg:-
(-i eth1)

# iptables -A INPUT -i eth1 --src 192.168.1.200 -j DROP

    Any incoming traffic from the ip address on the interface eth1 will be dropped.

Negation rule:

# iptables -A INPUT -i eth1 --src !192.168.1.200 -j DROP

    This will Drop all the incoming traffic to the interface eth1 other than the IP 192.168.1.200. Only the incoming traffic from ip 192.168.1.200 will be accepted.

# iptables -A INPUT -i eth1 -j DROP

    This Drops all the incoming traffic on the interface eth1.

Wildcard for Matching all interfaces(eth+):
For eg:-
    IF we have more interfaces like eth0, eth1, eth2, eth3, eth4 etc and need to define a rule that matched all the interface, we can use the wild-card eth+ . eth+ will match all the interfaces starting with "eth".
For Eg:-

# iptables -A INPUT -i eth+ -p tcp --dport 23 -j DROP

    This will drop all the incoming telnet traffic to all interfaces, which starts with eth.

TCP Based Matching (--protocol/-p): (Connection Oriented)
     Majority of the rules are based on TCP . TCP is on Transport Layer (layer 4).
-p tcp/ --protocol tcp
    This switch will make IPTables to initiate the tcp modules and allow/deny the tcp based traffic. This switch makes sense to IPTables about the three way handshake of TCP. The protocol type (tcp/udp) has to be specified while using the "-p" match.
--sport/--source-port
    Generally the --sport of TCP client will be greater than 1024, and it is generaly picked arbitrarily from greater than 1024. So usally we wont filter based on the source port for TCP based traffic until and unless we know exactly how a application behaves.
--dport/--destination-port
    This is the common match that used along with the "-p" switch. Each and every TCP connection will have a well defined destination port. so based on this destination port we created/matched the rule.
--tcp-flags SYN, ACK SYN, ACK, FIN
    This is used to match the three way handshake of the tcp protocols.
    SYN - Step 1 of Three way Handshake (Initial synchronization) (From Server)
    ACK SYN - Step 2 of three way Handshake (To Acknowledge that the SYN has recieved) (From Client)
    ACK - Step 3 of Three way HandShake(From Server)
    FIN (Finishing a TCP Session)
Eg:-

# iptables -A INPUT -p tcp --dport 23 -j DROP

    Here Match is made with the protocol TCP having the destination port of 23. So all the incoming traffic to telnet will be dropped.

# iptables -A OUTPUT -p tcp --dport 21 -j DROP

    This will Drop all the FTP outbound traffic(all request to ftp access from our server)

UDP Based Match: (Connection Less)
    Some of the UDP based applications are TFTP:69, Syslog:514, NTP:123, DHCP:67/68, DNS:53
-p udp/--protocol udp
--dport/--destination-port
--sport/--source-port
    In majority of the cases, the UDP based traffic having same source port as the destination port.Eg:- The NTP client packets has same destination-port and source-port as 123 in header.
Eg:-
If we are running the syslogd daemon we have to block all other traffic to the service other than the syslog server.

# iptables -A INPUT -p udp --dport 514 -s !192.168.1.3 -j DROP

    So here only the traffic from the host 192.168.1.3 with UDP:514 will be accepted and all other source will be denied. Here the match is made with the protocol UDP and --dport 514 along with the Source(-s) using Negation(!).

ICMP based traffic Match.
    This is designed to communicate the status information.
various types of ICMP:
    echo-request - PING (sends the request via output chains using echo-request to destination)
    echo-reply -   PONG (Remote system Recieves the echo-request and responds with an echo-reply (PONG))
-p icmp/--protocol icmp
    Here defines the protocol type
--icmp-type name/number of icmp type
    Here we specifies the ICMP-Types. It can be name or number.eg:- echo-reply, icmp-request etc.
To get the list of icmp types that supported by the IPTables

# iptables -p icmp --help

        Using this we can build the rules. The above command can be used for both the tcp and udp protocols

    # iptables -p tcp --help
    # iptables -p udp --help

Eg:-

# iptables -A INPUT -p icmp --icmp-type echo-reply -j DROP

    All the echo-reply from outside will be droped.
Rule to drop all the echo-request to our filrewall from all outbound destination.

# iptables -A INPUT -i eth1 -p icmp --icmp-type echo-request -j DROP

    This will disable all the echo-request from the outside interface. But from this server we will be able to ping to any other system because we have not doped any incoming echo-reply.

Multiport Matching in single rule (-m):
    This feature uses to match multiple ports in a single rule.
-m multiport
 Checking the Multiport module installation

# rpm -ql iptables |grep multiport
/lib/iptables/libipt_multiport.so

    This is the modlue responsible for multiport
Eg:-

# iptables -A INPUT -p tcp -m multiport --dport 21,23 -j DROP

    Here we defined the multiple ports in single rule.

Matching Layer 2 Traffic (MAC-address):
    The MAC address is least changable.
Checking the capability of iptables to match the Layer 2 traffic

# rpm -ql iptables |grep mac
/lib/iptables/libipt_mac.so

    This is the modlue responsible for mac address based rule.
-m mac
    This will tell iptables to consult the libipt_mac.so module for processing the rule
--mac-source
    Source MAC address. Same as the --src option in Layer 3 (IP Adress)
--mac-destination
    Destination MAC address. Same as the --dst option in Layer 3 (IP Address)
Eg:-

# iptables -A INPUT -p tcp -m mac --mac-source 00:09:8F:3E:10:3A -j DROP

    IF the source mac address is matched then the traffic will be DROPed.
Filtering based on Layer 2 (MAC Address) is more secure because the IP Address can easily be changed.

Linux Securirty Notes 15: IPTables 2: Chain Management

IPTables Chain Management

Listing all the chains in Table Filter

# iptables -L -n

    It lists INPUT, FORWARD and OUTPUT chains and rules associated with. Each of the chains will have a default policy. i.e the default policy is accept the traffic in IPTables.

# iptables -L OUTPUT

    It will list all the rules in the chain OUTPUT for the default table.

Listing all the chains in Table NAT.

# iptables -L -n -t nat

     It contains the chains PREROUTING(will use NAT before routing occurred -destination nat-),  POSTROUTING(uses NAT to after the packets get routed  -source nat-) & OUTPUT (Reserved for packets that sourced locally that need the NAT)

Listing all the chains in Table Mangle.

# iptables -L -n -t mangle

    It contains chains INPUT,OUTPUT,FORWARD, PREROUTE & POSTROUTE. Mangle Table is the ANDing of Filter & NAT table.

To List the amount of traffic that processed by the a chain

# iptables -L -n -v -t filter

    This will show the total amount of traffic in each chains. Even if there is no rule defined it shows the traffic in chains. This is because there is default rule of accept all in IPTables.

Determine the Line number of the rule in a chain

# iptables -L -n -v --line-numbers
# iptables -L -n -v --line-numbers -t nat

    This will show the line numbers column for all the chains.

Appending(-A) and Inserting(-I) rules to Chains

    We will  try to understand each chains with a real time scenario
Source (192.168.1.1)pings to -> destination (192.168.254)
    In this case the source sends a ICMP (echo-request) packet to 192.168.254 which pass across the OUTPUT chain in filter table. Once the request reaches the destination it responds with a echo-reply to the source 192.168.1.1 which pass across the INPUT chain in filter table.

Now we will create rule in source all traffic for SSH will be permitted and Telnet traffic will be denied
Appending a rule(-A):

# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# iptables -A INPUT -p tcp --dport 23 -j DROP

    This will make the server to accept only the ssh based connection and telnet sessions wll be droped.
The append (-A) will add the rule to the last rule in the chain(to the end of the rule list in chain).

# iptables -L -n -v --line-number

    This will list the newly added rule

Inserting a rule (-I):
We can insert the rule into a particular line number using this option. (Keep in mind the iptable checks the rule from above to bottom and once it matches the criteria it executes the rule).(We can even insert a same rule to the chain, creating a duplicate rule. IPTables doesn't have a feature to detect the duplicate rules that have appended or inserted.

# iptables -I INPUT 1 -p tcp --dport 23 -j DROP
# iptables -L -n -v --line-number

    Here we can see that the rule for dropping the telnet session has been added to first line in the chain. So IPTables will process the rule number 1 before it hitting the rule number 2.
Other examples:

# iptables -I INPUT 2 -p tcp --dport 21 -j DROP

    It inserts a rule to line number 2 in INPUT Chain for the table Filter,for Dropping all FTP traffic.

Deleting(-D) and Replacing(-R) Rules
Deleting a Rule:
Syntax for deleting the rule from the chain:
# iptables -D
# iptables -D
Type 1

# iptables -L -n -v --line-number
# iptables -D INPUT 2

    This will delete the 2nd rule in the chain INPUT.
Type 2

# iptables -D INPUT -p tcp --dport 21 -j DROP

    This will delete the rule as mentioned . This need the exact match and in case of any duplicate rules the first match will be deleted.

Replacing Rules:
Syntax:
# iptables -R

# iptables -L -n -v --line-number
# iptables -R INPUT 1 -p tcp --dport 23 -j ACCEPT

    This will replace the existing rule from DROP to ACCEPT (we had previously denied the telnet access)

Flush(-F) rules and Zero counters (-Z)

Flush rules:
syntax:
# iptables -F

# iptables -F INPUT

    This will flush all the rules in the chain INPUT.

# iptables -F

    This will flush all the rules from all the chains in default Table. But the flusing will not zero the packet counters (iptables -L -v).

Zero Counters:
Syntax:
# iptables -Z

# iptables -Z INPUT
# iptables -L -n -v

    This will reset the packet count for the chain INPUT

# iptables -Z

    This will reset all the chain packet counts in default table.

# iptables -Z POSTROUTING -t nat

    This will reset the packet counter for the chain POSTROUTING for table nat.

User Defined Tables/Chains (Creating (-N) and Renaming (-E old new)):
    IPTables ships with 3 default tables which cannot be deleted.

Creating a New chain called INTRANET

# iptables -N INTRANET
# iptables -L -n

    This will create a new chain called INTRANET in the filter table. This will create a chain with the default refereces as "0". reference is the link towards the default chains(INPUT, OUTPUT & FORWARD).
Now we define the new chain INTRANET how to behave. i.e, which traffic should be this chain responsilbe for.

# iptables -R INPUT 1 -s 192.168.1.0/24 -j INTRANET

    This will tell IPTables that - In rule number 1, any trafic having the source network ID 192.168.1.0 should be contacted the chain INTRANET

# iptables -L -n

    Here we can see that a new entry for the Chain is added into the Line number 1 stating that for all the packages having source address in the network 192.168.1.0/24 should jump to target chain INTRANET.

Now create the rules

# iptables -A INTRANET    -p tcp --dport 23 -j DROP

    So when a packet comes with a source address in 192.168.1.0/24 with the destination port 23. The iptables will refer from the INPUT chain to the INTRANET chain and Then IPTables will start matching the rule. If the packet has the destitantion port 23 then it will DROP.

Note:-
    User defined chains must have unique names. Because it function has the target (-j).

Rename a Chain(-E):
    If we need to rename a user defined chain
Syntax:
# iptables -E

# iptables -E INTRANET    SUBINTRANET

    This will rename the chain to SUBINTRANET. The iptables "will update the references as well"(The reference to the default chain).
Chain Policy (-P):
    It is usually "accept" in RedHat environment for all the chains in filter table. should be very careful while setting the chain default policy to DROP(Update the iptables to permit the appropriate access, else if we are using a remote session this may freez the access).
Syntax:
# iptables -P

# iptables -P INPUT DROP
    This will make the default policy of INPUT chain to DROP.
# iptables -L -n

    Check the "chain INPUT (policy DROP)" to verify.
Note:-
    Default DROP Policy may prevent typical TCP/UDP/ICMP communication.So a state matching rule should be added in case of such scenarios.

Linux Securirty Notes 15: IPTables 1: Introduction

IPTABLES
    The integrated firewall feature in Linux Kernel is IPTables. Using IPTables can turn the Linux machine to a fully fledged firewall. Since the IPTable netfilter frame work is capacble to filter pretty much most of the level of OSI models & with in all the various field in TCP, UDP and ICMP packets it has a significant value in corporate enviornment to build the security.

OSI Models
    The Open System Interconnection Reference Model (OSI Reference Model or OSI Model) is an abstract description for layered communications and computer network protocol design. It was developed as part of the Open Systems Interconnection (OSI) initiative. In its most basic form, it divides network architecture into seven layers which, from top to bottom, are

•     Layer 1: Physical Layer
•     Layer 2: Data Link Layer
•     Layer 3: Network Layer
•     Layer 4: Transport Layer
•     Layer 5: Session Layer
•     Layer 6: Presentation Layer
•     Layer 7: Application Layer

some of the Protocols in each Layer are given below.
7. Application Layer
NNTP  · SIP  · SSI  · DNS  · FTP  · Gopher  · HTTP  · NFS  · NTP  · SMPP  · SMTP  · SNMP  · Telnet (more)
6. Presentation Layer
MIME  · XDR  · SSL  · TLS
5. Session Layer
Named Pipes  · NetBIOS  · SAP
4. Transport Layer
TCP  · UDP  · PPTP  · L2TP  · SCTP
3. Network Layer
IP  · ICMP  · IPsec  · IGMP
2. Data Link Layer
ARP  · CSLIP  · SLIP  · Frame relay  · ITU-T G.hn DLL
1. Physical Layer
RS-232  · V.35  · V.34  · I.430  · I.431  · T1  · E1  · Ethernet  · POTS  · SONET  · DSL  · 802.11a/b/g/n PHY  · ITU-T G.hn PHY
   
    IPTables is a front end user space tool to manage Netfilter in Linux kernel. IPTables functions primarily in the Transport (Layer4) and Network (Layer 3), even it can work in the DataLink layer too. IPTables can manage the ICMP .

Layer 4 -Transport- Focuses on Protocols & Ports (TCP/UDP & Ports(0-65535)). The ports are based on 16bit value
Layer 3 -Network- Focuses on Source & Destination (IP Address). The IP address is based on 32 bit value

Installing IPTables
         The package IPTables will be installed by default in most of the Linux distro.

# rpm -qa |grep -i IPTables

    Or download the Latest package of IPTables from http://www.netfiler.org

# rpm -ql iptables
    IPTables ships with many modules that provides the functionality of Masquerading, Rejecting, Mapping etc. The modules that installed can be found in /lib/iptables/*.so.

Checking the kernel for the support of the IPTables.

Find the area for "NETFILTER" in Kernel config file.

# uname -a

# vim /boot/config-

CONFIG_NETFILTER=y

    (y)This means the netfilter basic support has been integrated and compiled to the kernel.If (m) option is defined then this means the module can be loaded on the fly so here we need to check the iptables modules has been loaded by command "lsmod".

Default Tables & Chains in IPTables
    There are 3 default tables which cannot be deleted. Each table contains chains and the rules are written to the chains
1. Mangle
    This allows to alter packets eg:- Type Of Service, Time To Live etc.
2. NAT
    Network Address Translation, This allows to change IP Address & Ports. Eg:- Source NAT / DST NAT etc
3. Filter
    Here we perform the Filtering the traffic (INPUT, OUTPUT & FORWARD). It works between Layer 3 & Layer 4.

Rule Syntax IPTables.

# /sbin/iptables   
commands are used in the following syntax:
    name of chain - action done to chain (Append/Incert or Replace)
    name of table - default it will append to filter table
    Layer 3 object - src or dst of ip address
    Layer 4 object - protocols & ports
    Jump/Target - if the above criteria meets the do this action

Example of iptables
Drop All the packages from a Host

# iptables -A INPUT -t filter -s 192.168.1.233    -j DROP

    This will Drop all the packages coming from the source 192.168.1.233.
Now Test by pinging to the destination host 192.168.1.233
     Here we have the OUTPUT chain opened and the rule is defined in INPUT chain. This means our system is able to send the packages to the destination and while the destination machines replies back we drop the packets.

Saving and Restoring the rules in IPTables

# iptables-save

    This will dump the rules to STDOUT(to the terminal). The output will be in the iptables default format.

# iptables-save > firewall-rules

    This will write the rule the file firewall-rules

# iptables-restore

    Default reads the rule from STDIN and loads in to the kernel.

# iptables-restore < firewall-rules

    This will restore the rule that saved in the file firewall-rules.

Linux Securirty Notes 14: Squid notes 8: Cache Hierarchies & Transparent Proxy

Squid cache Hierarchies:

Parent-Child Hierarchies:

    Here we will define the parent child cache peering relationship. The cache will be located in two servers i.e, there will be a main cache server called as parent server, and a local cache server named as client. All the local users will query the client server for the cache and the client will pull the cache from the parent. Here the only one squid server will be connected to externel network and for auditing purpose all the traffic from other squid servers should be routed through the single proxy server.

Configuring the cache peering
Scenario:
192.168.1.0/24 Local network will query the cache client client.cache.domain.com:3128  -> which will query the parent.cache.domain.com for the cache which is not found locally.The parent cache server is the only one that connected to internet.The client uses port 3130 a UDP protocol to find out the requested cache is present in cache-parent.
Note:-
    Squid supports multiple protocols for caching, CARP(cache array routing protocol). ICP, HTCP (Hyper text caching protocol), Cache-Digests etc. Make sure that the port 4827, 3130 & 3128 are opened in the firewall if the client cache is behind a firewall.

Configuring the cache-peer

In client.cache.domian.com
# vim squid.conf
--------------
cache_peer    parent.cache.domian.com      parent    8080    3130    default
--------------
# relaod squid
    This will make the client.cache.domain.com to query parent.cache.domain.com using the cache peer port 3130 and proxy port 8080 with default settings.
Test by setting the proxy variable to the client.cache.domain.com for subnets. The client will try to pull page from the client.cache.domain.com, if the page found in client.cache.domain.com then the squid running on client.cache.domain.com will contact the parent.cache.domain.com for the cache. Check the access.log file for the request path.

Sibling Hierarchies:

Sibling-cache Relationship
    This is sharing the cache among the multiple squid servers. i.e, if a server gets query for a particular cache and if it is not found in its history the server will query the sibling proxy servers for the same cache. So implementing this feature will save the bandwidth usage and time taken for downloading the page. In this case the cache will be shared among the sibling servers.

Configuration:
In cleint.cache.domain.com
# vim squid.conf
---------
cache_peer    parent.cache.domian.com      sibling    8080    3130    default
---------
# reload squid

In parent.cache.domain.com
# vim squid.conf
-----------
cache_peer    clinet.cache.domian.com      sibling    8080    3130    default
-----------
# reload squid
    This will make both the servers to act as siblings. And will share the cache if that present in any one of the server before it queries the internet.
    Test by setting up the proxy variables in the client and check the access.log file in both the server. We will be able to trace the query from the sibling servers here.

Limiting the squid service access:
    For limiting the cache access usage.
# vim squid.conf
---------
acl all src 0.0.0.0/0.0.0.0
acl connection_limit    maxconn    10
http_access deny connection_limit    all
---------
# reload squid
    If a user attempts to create more than 10 connection to the server the squid server will deny the new access. Test using wget.


Transparent Proxy
    Local network (No proxy settings in browser)-> proxy/firewall (http accelerator and Iptables) -> Internet
Configuring the Transparent Proxy in proxy/Firewall box
Step 1:
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A PREROUTING -i eth1 tcp --dport 80 -j REDIRECT --to-port 3128
    (what ever the packates coming to the box with the dstination port 80 should redirect to port 3128)
Step2:
    Now we have to configure the squid as transparent proxy by adding the http acceleration feature (only in 2.x series). In new version this is not needed.

# vim squid.conf
-----------
httpd_accel_host     virtual
httpd_accel_port     80
httpd_accel_with_proxy    on
httpd_accel_uses_host_header    on
-----------
# relaod squid
    Now this features makes the proxy to run in transparent mode.
Note:-
# squid -v
    Command will show the compiled options of squid server when installed. Here we will find a key directive that is used to interact with IPtables to while enabling the transparent proxy, named "--enable-linux-netfilter". This feature makes the squid to integrate with iptables while running in transparent mode.

Linux Securirty Notes 14: Squid notes 7: Bandwidth Management using Delay Pools

Squid - Delay Pools Bandwidth Management
    This feature is used to restrict the bandwidth usage for the user community. It  has been introduced in ver 2.x

Implementing bandwidth management using delay pool

Delay Pools have 3 different class for restriction

1. class 1 pool allows to restrict the rate of bandwidth for large downloads.
    This makes the restriction of rate of download of a large file.
Implementing Class1 delay pool
Steps:

1.  Define the ACL for the delay pool
2.  Defines the number of delay pools (delay_pools 1)
3.  Define the class of delay pool    (delay_calss 1 1)
4.  Set the parameters for the pool number (delay_parameres 1 restore_rate/max_size). Once the request exceds the max_size then the squid will make the bandwidth to the given restore_rate for a user/source(The mesurement is taken in "bytes")  eg:- delay_parameters 1 20000/15000
5.  Enable the delay_access to include the feature (delay_access)

Configure the class 1 delay pool
# vim squid.conf
--------
acl    bw_users    src    192.168.1.0/24      # The acl defined for the Network    
delay_pools    1                                         # This will tell the delay pool number
delay_calss    1 1                                       # This defines the delay pool number 1 is a class1 type delay pool
delay_parameters    1    20000/15000        #This is delay parameter for pool number 1 which has the restore rate of 20000 when the usage hits 15000 bytes
delay_access    1    allow    bw_users      # This is the access tag which tie to the acl bw_users
--------
# relaod the squid
    This will make the bandwidth usage for any one of the src when execeds the download limit of 15K, restores the rate of download to 20K/s.
Test the configuration by downloading files using wget
Limitations of class pool1:
    If we have a bandwidth of 1500000 Bytes and if we configure a rate of 20000 bytes per sec then the max simultaneous connections will be 1500000/20000 = 75. This will max out the connection if we have a large number of connections from the src
 
2. Class 2 pool allows to set the bandwidth usage to a sustained rate
    Using the class 2 pool we can overcome the Limitation of max out in class1. So here we can implement the Bandwidth in aggregate rate.


Configure the class 2 pool

If we have a Link with bandwidth of -(1.5Mb/s) 1544000 bytes/s of bandwidth
If we need to limit or set ceiling of 62500 bytes/s (500k/s) as bandwidth for the netusage
and 10% of the ceiling for each users

# vim squid.conf
----------
acl    bw_users    src    192.168.1.0/24 # The acl defined for the Network
delay_pools    1                                    # Number of Pool
delay_class    1 2                                  # Defines the class of pool for the Pool Number 1
delay_parametes    1 62500/62500 6250/6250 # This tells to create a cieling of 500K (62500) for our bandwidth having (1.5M) with a indivigual cieling of  #10% of the cieling (Any given time the users will be restricted to the 10% of the cieling bandwidth 500k)
delay_access  1  allow  bw_users        # This is the access tag which tie to the acl bw_users
----------
# reload squid
    Test the rate of bandwidth using wget. Here we can see that all the rate will be restricted to 10% of the cieling from the begning for all the src. This makes the rest of the bandwidth free for usage of other purpose i.e, Out of 1.5M we have taken a cieling of .5M for internel network and  we have told to squid that each request from src should get a 10% of .5M of bandwidth.
Note:-
 In the class1 pool the restriction of the bandwidth was started only after meeting the max size of download. But in class 2 instead of the max download size here we defined a ceiling and user is restricted to it from the beginning.
   
3. Class3 pool allows to restrict the bandwidth usage for subnets
    This will implement the bandwidth management with aggregate rate per subnets. i.e, the class2 pool with subnet-based ceiling

Configuring the class 3 pool
# vim squid.conf
----------
acl    bw_users    src    192.168.1.0/24 # The acl defined for the Network
delay_pools    1                                    # Number of Pool
delay_class    1 3                                 # Defines the class of pool for the Pool Number 1
delay_parametes    1 62500/62500 31250/31250 6250/6250 # This tells to create a cieling of 500K (62500) for our bandwidth having (1.5M) with a subnets cieling of 50% of the cieling (Any given time the request from the each subnets will be restricted to the 50% of the cieling bandwidth 500k and each users in subnet will have 20% of the bandwidth rate of subnet cieling)
delay_access  1  allow  bw_users       # This is the access tag which tie to the acl bw_users
----------
# reload squid
    This makes the squid to make the bandwidth usage 50% per subnet(Incase if we have 2 subnets in our network) and each user will get 20% of the subnet cieling. (i.e, out of 1.5M we have taken a cieling of .5M. the subnet cieling will share 50% of this .5M clieing(.25M). In each subnet the users will get 20%(.05M) of bandwidth of the subnet cieling (.25M)).
 
Delay Pool class2 with Time based ACL:
    This will implement the bandwidth management only during the business hours.

Configure the Class2 pool with time restriction
# vim squid.conf
----------
acl    bw_users src 192.168.1.0/24         # The acl defined for the Network
acl work_time time MTWHF 09:00-18:00
delay_pools    1                                      # Number of Pool
delay_class    1 2                                    # Defines the class of pool for the Pool Number 1
delay_parametes    1 62500/62500 25000/25000 # each user has given an average of 25000 bytes of bandwidth
delay_access  1  allow work_time         # This is the access tag which tie to the acl all and work_time.
----------
# reload squid
    This will make the class 2 pool to be activated only while the office hours. Test by changing the time in the squid servers after configuring the class 2 pool with time period.

Linux Securirty Notes 14: Squid notes 6: DNS Round Robin

Squid - Force proxy usage
    Here will explain how configure all the outbound traffic (to internet) to only route through proxy.
Step 1:
    We will disable all the outbound access to the internet from local network except the squid server in the firewall.
    And explicitly allow the squid server outbound traffic to port 80/443.
Step 2:
    Now configure the Proxy server. Setup the proxy variable in the client (Browser settings as well the http_proxy variable settings). And check the access.log file. This is the recommended setup so that all the outbound traffic from our network will be monitored and controlled using squid.

Squid Load balancing - Using DNS Round Robin:
    This configuration will make squid to run in a load-balance fashion. The DNS ROUND ROBIN will take care of routing request from source to all the squid servers configured with DNS Round Robin. Here the cache can be shared among the squid servers. This make the same cache access for all the requests on load balancing.

To obtain this we will configure two squid servers for our network
Network:          192.168.1.0/24
Squidserver1:    192.168.1.1
Squidserver2:    192.168.1.254
Step 1:
    Install squid on both the servers and configure both the servers with the same business rule. Start squid servers. Make sure that the squid is running on both the servers.
Step 2:
Configure the DNS for ROUND ROBIN:
    Here we will make entry of both the squid servers in DNS. Here we have to make a same "A" record pointing to different IP address of the two squid servers
Eg:    cache.domain.com    A    192.168.1.1
         cache.domain.com    A    192.168.1.254
        So when we make a query to the DNS server the DNS server will reply both the IPs, subsequent reply will alter the position of the A record. This means If the result for the first query for the FQDN returns "cache.domain.com    A 192.168.1.1". Then the subsequent query will yield the result of "cache.domain.com A 192.168.1.254". Thus the Load will be balanced equally to both of the servers.
Check the working of DNS ROUND ROBIN using
# dig cache.domain.com
&
# nslookup cache.domain.com

Step 3:
    Configure the browsers and the variables in the client for the squid server "cache.domain.com". and try to brows.

Note:-

        Keep in mind about the DNS cache used by client.