14 - Linux Security: TCP wrappers

- Layout for this exercise:





1 - Introduction

- TCP Wrapper is a host-based networking ACL system used to filter network access to Internet Protocol servers on Unix-like operating systems such as Linux or BSD. 

- For access control and filtering purposes it allows host IP or subnetwork IP addresses, and also hostnames to be used as tokens.

- The tarball includes a library named libwrap that implements the actual functionality, and most common network service daemons can be compiled against libwrap directly. 

- A wrapped service is compiled with libwrap support.

- Some benefits of using TCP wrappers:

a) connections are monitored and reported through the syslog facility.
b) simple form of access control based on pattern matching. 
c) verifies the client host name is returned by the address.
d) spoofing protection.
e) works on the application layer so encrypted requests can be filtered.


2 - Configuration of TCP wrappers

- The command ldd can be used to see if the library libwrap.so is supported by services, meaning that those services are compiled with TCP wrappers. For instance:





- There are two main files for the configuration of TCP Wrappers: /etc/hosts.allow and /etc/hosts/deny, listing hosts allowed and not allowed to use the services.

- Locating hosts.allow and hosts.deny:










- /etc/hosts.allow is checked first. If a match is found access is granted. If not, then /etc/hosts.deny is checked next, and if a match is found access is denied. 

- Access rules, one per line, are written inside those two files. The pattern of the rules is SERVICES : CLIENTS : ACTIONS

- ALL can be used as a wildcard for all services and for clients. 

- Let's see some examples of how to apply TCP wrappers.


3 - Example 1: allowing and denying access

- Editing hosts.allow for allowing SSH access from the Windows system:





- Editing hosts.deny for denying SSH access from the Kali device:





- The result is that Windows can remotely access Debian with SSH, but Kali cannot:







- The reason for that result is that hosts.allow matches the Windows devices's IP when trying to use SSHD, running the connection. However, because hosts.allow does not match Kali's IP it moves to hosts.deny file where Kali's IP is actually present, therefore denying the access.

4 - Example 2: using the wildcard ALL

- Let's try another configuration. In this case hosts.allow holds both Windows and Kali's IPs:



- However, hosts.deny holds the wildcard ALL, meaning that any other host different from 192.168.17 or 192.168.1.19 is not allowed to access via SSH:






- Not even the localhost, whose SSH access is also denied because it is comprised under the wildcard ALL:

13 - Linux Security: Iptables firewall

IPTABLES FIREWALL

- Layout for this exercise:

1 - Introduction to Iptables

- Iptables is a powerful firewall that provides a table based system for defining rules that can filter or transform packets.

- Iptables is integrated in the Linux kernel as part of the netfilter project, having the ip6tables version for IPv6. 

- Iptables has 5 tables or zones where a string of rules can be applied:

a) raw: filters packets before any other table. It is mainly used to configure connection tracking exemptions in combination with the target NOTRACK. 
b) filter: default table if not passed the -t option.
c) nat: used for network address translation. Due to limitations in iptables, filtering should not be done here.
d) mangle: used for altering specialized network packets (see Mangles packet). 
e) security: used for Mandatory Access Control network connection rules.

- Tables contain chains which are lists of rules that handle the network packets.

- By default the filter table contains 3 built-in chains: INPUT, OUTPUT, FORWARD. 

a) INPUT: all incoming traffic directed to the machine is passed through this chain.
b) OUTPUT: all outbound traffic generated locally passes through this chain.
c) FORWARD: all routed traffic which has not been supplied locally passes through this chain.


- Also, other often used built-in chains are PREROUTING and POSTROUTING:

a) PREROUTING: alters packets before routing.
b) POSTROUTING: alters packets after routing.





- Users can define rules of the chains to make them more efficient. Compiled chains have a predefined target which is used if no rules are defined. Neither compiled nor user-defined chaina can be a predefined target.

- The filtering of network packets is based on rules which are specified by various matches or conditions that the packet must satisfy for the rule to apply, and a target or action to take when the package fully matches the condition. While individual conditions are often very simple, the specification of the entire rule can be very complex.

- Targets are specified by the -j or --jump option. Targets can be either user-defined chains, one of the special integrated targets, or a target extension. 

- The integrated targets are ACCEPT, DROP, QUEUE, RETURN; the target extensions are for example REJECT and LOG.

- If the target is an integrated target the destination of the packet is decided immediately and the processing of the network packet in the current table is stopped. 

- If the target is a chain defined by the user and the packet successfully overcomes the chain it will move to the next rule.


2 - Setting the lab

- To start with a blank slate the command iptables -F (flush) removes any possible iptables configuration:

- Listing (-L option) the iptables table is empty:

- Starting Apache and SSH services:

- Scanning ports, both Apache and SSH services are open, as expected:

- Connection to the web server is available:




- Also SSH connection is available:




3 - Creating rules

- The first rule is added (-A option) and accepts any incoming packet directed to the web server or port 80:




- Listing the rule with numbers (-nL):




- Adding another rule that accepts incoming packets from the local network (192.168.1.0/24) and directed to port 22, where SSH service is enabled:




- Listing:




- The third and last rule forces to drop any other type of packet that does not match the 2 previous rules:




- Listing the 3 rules:




- Now, let's check that the web connection is successful from the Kali system:




- The SSH connection from Kali is also successful:




- However a ping is not successful because it works with ICMP protocol, not included in the previously defined rules:







4 - Deleting rules

- The option -D can be used to delete individual rules. Using --line-numbers option we can see an ordered list of the rules:




- For instance, let's delete the first rule leaving untouched the other two rules. 




- Checking that the first rule has been deleted:




- As a consequence, only packets from local network trying to access via SSH will be allowed, and any other protocol like HTTP or ICMP will be filtered:








- As expected, only SSH service is avilable:





5 - Logging 

- Flushing the tables:




- Let's add these rules that enable logging of all packets not matching the first rule (packets to port 22 or SSH service):




- Tailing the syslog file to see what happens when an HTTP packet tries to arrive and it is blocked by the firewall:









6 - REJECT versus DROP

- It is interesting to compare two types of firewall blocking: REJECT versus DROP.

- While REJECT sends back a message notifying the rejection, DROP just drops the incoming packets.

- Let's apply REJECT to packets coming from Kali Linux device and DROP to packets coming from a Windows device:




- Scanning the system all ports appear as filtered. While filtered means that a service is enabled but blocked by a firewall, close means that the service is disabled:















- Pings from Kali are rejected and notified as unreachable:




- However, pings from Windows are simply dropped without no notification:




- Also, SSH connection from Kali is notified as refused:




7 - Saving iptables configuration

- One way of saving and restoring iptables configuration is to use the commands iptables-save and iptables-restore and the file iptables.conf: