Firewall filtering overview
To introduce firewalls, we need to start this post by discussing networks, the backbone component of them all.
A network is a conjunction of devices interconnected and identified with a range of specific addresses and network masks, while routers handle the interconnection and are occasionally aisled by firewalls. The routers will handle the network’s traffic correct delivery process while the firewall handles the filtering and the rule assessment validation on the network.
Firewalls have different flavors, there are Hardware firewalls (just like physical routers) that are connected to the traffic, and Software firewalls are available as an application for the PC (host) internal firewall settings.
It’s important to mention that the firewall packet inspection applies in certain OSI model layers, specifically in the transport and network layers. Firewalls go for inspection of origin, ports, and packet protocols, they can only inspect headers, not the data (content) properly speaking.
In the TCP/IP architecture represented by the Physical, Network, Transport, and Application layers in the OSI model, however, it changes things a little bit at a TCP/UDP level (Transport layer), here, an IP packet is denoted a datagram, and a Session can consist of the transmission of multiple packets encapsulated inside a datagram.
Internally the Firewall will only inspect TCP/UDP packets and the IP headers of the network, it won’t inspect the packet content of the datagrams or the sessions involved, just independent well-formed packets, and that’s it.
Let’s move on to filtering
The Firewall filtering goes all the way based on address, so even the data containing malware can be passed on to the network. Firewalls won’t affect communication encryptions or authentications.
A standard Firewall will filter packets based on certain security policies, but advanced firewalls can identify sessions, affecting TCP all the way.
Sessionless protocols like UDP and ICMP can be considered at high risk to firewalls because of their autonomy and independence, these are hard to contextualize but not impossible to work with. For ICMP messages you can protect your infrastructure based on the type of messages generated, you can easily block ECHOs or ping requests to avoid detecting active machines in your system. UDP packets can be filtered by the ports that typically are used.
Let’s classify firewalls
Some specifications and common features are in place.
Class 1
This is the typical Firewall resident in the computer, it generally has packet filtering, and dynamic inspection, can support NAT routing, and has filtering for FTP, HTTPS, DNS, and SSH protocols.
Class 2
These are firewalls based on router devices, ideal for SOHO environments. It supports NAT and the same protocols as the Class 1 firewall but extends filtering in addresses and ports.
Class 3
Low-level hardware Firewalls with more features than Class 2 devices. Includes Remote handling, static filtering, switching capabilities, VPNs, UTM integrations, and anti-malware solutions
Class 4
Next-gen firewalls for mid-level/big companies, ideal for big network traffic.
Class 5
Same as Class 4, ideal for big infrastructures with some sort of perimetral protection and specific hardware configuration
The packet treatment
In terms of firewalls, this is the action of handling (blocking or allowing) network packets based on the internal IP and port rules based on protocols.
This is all achieved with the Stateful Packet Inspection, this mechanism will inspect each packet (session packets) and will make a decision based on filtering rules evaluating not only headers, but the content, and also the related stream.
However, it takes some time and practice to get to know the normal expected traffic, at the end you can expect some traffic and sharp about it, but this can lead to a bunch of false positives.
A great example of this behavior is the port scan. It’s used to determine which port is open and what service is running in it. This information implies getting certain access, that can be trackable and recorded by a firewall, trigger an alert, and perform actions to it.
In terms of malware, all the communications with a C2 server can be seen as suspicious connections, however, this other behavior can lead to malware infection too, or excessive DNS requests and other protocols (anomaly network traffic), unknown IP addresses, unusual activity time or a high-traffic network in short time frames.
And the good thing is that all of this can be logged. Mostly it has a timestamp for the ordered activity stack trace records, and more, sometimes we need to know if we are the target of a network attack.
Here are some attack scenarios
Here are 3 types of attacks that can complement the importance of detecting Firewall instructions.
Let’s start with the Teardrop attack, this one consists of sending massive TCP packets, and in between the fragmentation is corrupted by the attacker. So, the target device will have a bunch of packets inside the buffer expecting to be reconstructed, since there are a lot of them the system will be blocked by some sort of saturation.
This is pretty much similar to DoS attacks.
Another one is the Land attack. that sends a TCP/SYN packet to a target, with the intentional purpose of responding to itself. Again, if is targeted massive, the internal network traffic will crash due to collapse. These whole false packet massive emissions are processed by the firewall, and will respond to itself.
The last one is the Smurg attack is the most classical DDoS form. And it’s pretty similar to both previous attacks. It will overload the network traffic of the victim through the massive sending of ICMP packets.
A simple variant of the Smurg is the Fraggle attack, and it’s the same but with UDP packets.
Some short considerations
Installing Wireshark and performing regular analysis of the network can be beneficial for avoiding these types of errors.
The same thing can happen to routers, the network is very prone to DDoS attacks and many other errors.
Hope this helps.
Happy filtering :)
