Linux iptables with Gufw Firewall

While firewalls remain an important network defensive tool, commercial firewall vendors have gone in seemingly different directions when it coems to managing firewalls.  It's important that people entering the security field have a good grasp of generic firewall capabilities.  A good way of learning about firewalls is using iptables available on almost every Linux distro.  A tool that can help getting started is Gufw Firewall.

The Linux firewall is iptables.  Using iptables the root user (or equivalenty) uses access control lists (ACLs) to define filtering policies.  ACLs can be multiple lines long with each line of the ACL being an access control element or ACE.  ACLs and  ACEs should be ordered from the leact specific match policies to the most specific policies.  That means that specific hosts and protocols to be blocked should be defined first (at the top of the table) and whole networks that should be later. 

If you are just getting started with firewalls and want to deploy a restrictive policy consider this command: 'iptables -P INPUT DROP'.  This command configures the firewall so that every connection that originates from the outside interface is dropped until explicitly allowed by an ACL. This configuration; where traffic is denied by default is a standard feature of most firewalls and referred to as an implicit deny.  

The iptables firewall in Linux is configured and maintained using a command line interface (CLI).  It'd important that firewall administrators learn how that CLI, but getting started it can be difficult.  I recommend the use of the Gufw Firewall utility, an open source graphical user interface (GUI) utility that is supported on many distros.  Using the Gufw utility the admin can configure basic policies and compare the GUI amd command line output. 

 

  

Implicit deny and discard versus drop

Many or most open source and commercial firewall have some basic rules that are configured when the product is first installed.  These rules are defined in an access control list (ACL).  One such rule is based on concept of the Implicit Deny.  Implicit Deny means that the default answer to whether a communication is allowed to transit the firewall is always No or Deny.  An implicit deny is often the last rule or ACL in the firewall configuration.

When first getting started the majority of ACLs tend to allow traffic to pass.  This is important in order to let traffic from authorized users and sites into the network where each connection will be authorized.  Examples of this would be allowing virtual provate network (VPN) inbound to a VPN concentrator; where individual users are authorized.  

Firewalls process communication inbound or outbound, based on the highest priority or most specific  ACL that applies to the lowest or most generic ACL.  Once a  access control element (ACE) is found with conditions that match, that ACL is executed by the firewall.  Allow, Deny & Discard are actions that the firewall can be configiured to take for any communication that match a particular ACL.  

When traffic is found to match the conditions of an ACL with the Deny action, the communication will not be permitted to proceed.  The communication is dropped by the firewall.  A RST (reset) packet sent back to the originating device and the communication will be ended.  The RST packet is a communication that goes back to the originator of the traffic stating that the connection has been closed.  

An ACL using the Drop action is often referred to as a stealth mode rule.  This option is much like Deny in that it will stop and drop the communication.  However using Drop action, the firewall will not send a RST packet as described in the Deny action above.  When the RST packet does not go back, the originator has no confirmation that there is a device to respond at the IP address that is trying to reach.  Even if the originator suspects that it is a security function that is stopping it, they will still not know anything for sure. 

The implicit deny feature is used when traffic comes into the firewall and no ACL meets the condition to allow it through, the firewall will drop the communication.

State versus Stateless Firewalls

Firewalls are a tool used to provide critical protection for systems and information. Operating according to a set of configured security rules, firewalls monitor and manage the traffic flowing into and out of your network. It is important to understand the differences between stateful versus stateless firewall technology to ensure that those systems and information is protected.

There are different ways of implementing firewalls.  Firewalls can be either network firewalls running on network hardware (a dedicated appliance or integrated into a switch or router); or host-based firewalls that inspect traffic of one or more interfaces of a host computer. When researching firewall types you likely encountered stateful and stateless firewalls. There is also a third firewall type; next-generation firewalls which have become the most common type of commercially available products. 

Stateful firewalls are capable of monitoring and detecting states of all traffic on a network to track and defend based on traffic patterns and flows. Stateless firewalls only focus on individual packets, using preset rules to filter traffic.

Firewall State Tables

A firewall state table builds and stores information about active connections that have been permitted by firewall rules.  Entries in the table define each connection based on:

• IP addresses for connection. 
• Protocol - TCP, UDP, and ICMP protocols.
• Port numbers - Services using numbered ports.  Port numbers range from 0–65535.
• Process ID (PID) -Unique identifiers for the host process associated with each connection’s traffic.
• Timestamp - The time of the last incoming or outgoing packet associated with the connection.
• Timeout - The time limit (in seconds) after which the entry is removed from the table if no packet matching the connection is received. The timeout for TCP connections is enforced only when the connection isn't established.
• Direction  - The direction (incoming or outgoing) of the traffic that triggered the entry. After a connection is established, bidirectional traffic is allowed even with unidirectional rules, provided the entry matches the connection’s parameters in the state table.

How are firewalls are the same as all other network devices.

Each host connected to each network attached to the firewall is assumed to have been assigned a unique IP address. 

Firewall state tables support both IPv4 and IPv6.  IPv4 addresses are 32 bits long while IPv6 permits addresses 128 bits long. 

When the process ends, all entries in the state table associated with a process are deleted.

How do state tables differ based on the open source project or manufacturer? 

If firewall rules change, all active connections are checked against the new rule set. If no matching rule is found, the connection entry is discarded from the state table.

If an network adapter obtains a new IP address, the firewall recognizes the new configuration and drops all state table entries with invalid local IP addresses.

 A TCP connection progresses through a series of states during its lifetime. The states are: 

• LISTEN (An open port on a host waiting for a connection.), 
• SYN-SENT (A host is actively attempting to establish a connection.), 
• SYNRECEIVED  (The server received a TCP SYN, responded with a SYN/ACK, and is now waiting for the remote host to send an ACK to finally establish the connection), 
• ESTABLISHED (There is a connection between a host and the remote IP and port that is able to exchange traffic.), 
• FIN-WAIT-1 (The first step of a four-way handshake was performed.), 
• FIN-WAIT-2  (Occurs when the server has an active connection with a client and wants to shut down the TCP connection.), 
• CLOSE-WAIT (The server has received the first FIN signal from the client and the connection is in the process of being closed.), 
• CLOSING  (Host is waiting for an acknowledgement for a connection termination request before going to the TIME-WAIT state.), 
• LAST-ACK (The local end-point has performed a passive close and has initiated an active close by sending a connection termination request to the remote end-point), 
• TIME-WAIT (The local end-point waits for twice the maximum segment lifetime (MSL) to pass before going to CLOSED to be sure that the remote end-point received the acknowledgement.), and 
• the fictional state CLOSED. 

CLOSED is considered a fictional state because based on the standard (RFC 9040) where it is defined it represents the state when there is no transmission control block (TCB), and a TCB is required to define a connection. 

References:

TCP states - explained  

TCP/IP State Transition Diagram (RFC793)  

Why deploy a stateless Firewall?

In many security courses that cover firewalls; the concept of a stateless is often barely discussed.  Most open source and commercially available firewalls are stateful and many add additional features in addition to the firewall leading them to be called 'next generation' firewalls. Stateless firewalls cannot determine the complete pattern of incoming data packets but does inspect each packet. 

Stateless firewalls perform better than stateful firewalls during heavy network traffic.  Since each packet is being individually inspected there are no tables to maintain. They are very easy to configure as the configuration simply includes which types of packets to allow.  That implicit deny all . They are also faster, less complex, and less expensive than stateful firewalls.

Another use case for packet inspection is rerouting of packets.  A firewall that can identify and reroute packets is especially useful as a defense against denial of service attacks.

Many of the use cases for stateless firewalls involve deep packet inspection (DPI). Stateful packet inspection typcially evaluates packet header information, such as source IP address, destination IP address, and port number, deep packet inspection looks at a more comprehensive range of data and metadata associated with individual packets.

Deep packet inspection, which is also known as DPI, information extraction, IX, or complete packet inspection, is a type of network packet filtering. Deep packet inspection evaluates the data part and the header of a packet that is transmitted through an inspection point, weeding out any non-compliance to protocol, spam, viruses, intrusions, and any other defined criteria to block the packet from passing through the inspection point.

What is TLS Fingerprinting?

The Transport layer Security or TLS 'fingerprint' is based on how your computer negotiates a TLS connection to a server. The JA3 algorithm is one of several that perform 'TLS snooping' in that they use data passed between a client computer and a server to identify the client. As long as your computer (operating system, web browser, and browser extensions) doesn't change; that fingerprint will be good.

If you use a different web browser from the same computer with different extensions installed in that web browser you should see a different signature. I say should because some TLS snooping implementations have the capability to 'fuzz' or ignore certain data like browser extensions.

TLS fingerprinting is valuable for an organization that wants to make sure that the secure communications between their server and their clients remains secure. If I know the TLS fingerprint for all authorized devices I can accept connections from those and ignore connection requests from hosts for which I don't have a matching fingerprint.

A deployment issue with TLS fingerprints is that if a user installs an extension in a web browser OR if the web browser or operating system is updated the fingerprint might need to be renewed or re-generated. Often users are always installing extensions unless they don't have the rights to install software. Same for operating system updates. The host computers and the server have to be rigorously controlled and managed.

Why do installed browser extensions matter when it comes to creating a TLS connection? Browser extensions are often either application or server specific and contain security settings for how that application works or how a server prefers to be contacted. If you had an extension loaded that needs to communicate with a specific server using SSLv3 that gets passed to the browser and the browser requirements get passed to the operating system. If the operating system supports SSLv3 then for that server the host will use SSLv3. That SSLv3 support becomes part of the TLS signature for that host. When negotiating any TLS connection the host will respond that it can 'speak' SSLv3 and TLS versions.

So your host security is only as good as your weakest extension.

What should happen when you 'harden' a host is that the operating system should report that it was asked by a browser or extension to support SSLv3. That doesn't always work by default. You can often figure that out using additional security tools that scan the system and browser logs looking for these conditions.

JA3 is an open source TLS Fingerprint project that was started by some engineers at Salesforce dot com. See https://github.com/salesforce/ja3

What's your take on biometric authentication?

What's the FAR and FRR of the biometric system you are considering? What's the CER?

FAR = False Acceptance Rate or when someone who is not an authorized user is granted access.

FRR = False Reject Rate or when a authorized user is rejected.

The CER = Crossover Error Rate which is the point at which the FAR and FRR meet.

You want your FAR and FRR to both be very low. If your FAR was 1 time in every 100 unique authorizations that would be 1%. Is that acceptable given the number of people using the system? You should try to account in your design for a FAR event (unauthorized user with access) and have some other protection in place; so that leads to a MFA (multi factor authorization) scheme.

FRR is what will truly frustrate your authorized users because they will be turned away and unable to access the system. That drives up the cost of operating the system since some additional person will have to be standing by to allow the rejected but authorized person access.

Another consideration for biometric systems is your user community and the design. Does the biometric system require touch? How's that work given the pandemic? If the biometric involve a camera; at what height is the camera set? Will it work for a person in a wheel chair?

Studying Cyber Security on a PC

A student asked me about how to get more familiar with Linux if they have a Windows PC?  I suggest looking at Oracle VirtualBox for virtualization. It's available for free.  It runs on almost any hardware.  It runs several distros of Linux (that I have used it for) very well. 

Linux distributions (distros) to look at.  Ubuntu.  I suggest looking at desktop first because the requirements are less and it has a GUI.  For studying cyber you want to look at Security Onion and Kali. Security Onion is great in that it has the essential Network security Monitoring (read that 'Blue Team') tools installed.  Kali has many, many tools installed for exploring both offense (Red team) and defensive (Blue Team) security.

If you want to run and use more than one operating system at the same time you'll probably want an external monitor (rather then trying to switch back and forth between virtual machine and Windows).  make sure that your computer supports a second display.

I'd suggest a minimum i5, with 8-16 Gb RAM, and 1 Tb HDD. 14-15 inch display capable of 1920x1080. 2 USB ports (USB v3 if possible). HDMI port is nice to have. Lots of Dell hardware comes with a DisplayPort; which via and adapter can drive a VGA or HDMI display.  Windows 10 Pro. Oracle VirtualBox. See Dell Refurb.