A firewall restricts the network traffic through them. It does this pretty much like a security guard screens people entering an exclusive Hollywood party. Only guests with their names on the list are allowed into the party. In a similar fashion, a firewall will only allow traffic through if it is allowed by it's set of definable rules (access control list). A firewall inspects data packets going through them, looking at the source and destination IP addresses or port numbers to make sure they are allowed. It may block certain ICMP traffic and/or allow or disallow access to devices depending on their MAC address (hardware address).
Some firewalls inspect inbound traffic only while others check both inbound and outbound traffic. I guess it’s good to make sure no bad stuff gets in but also checking that no sensitive personal data goes out would be good too.
A firewall may protect a whole network with many hosts connected to it (e.g. corporate network) or it may be installed on a single host to protect that host only (e.g. on home PC).
Some firewalls act as flood guards, detecting malicious attacks which try to overwhelm the server or network. For example, countering SYN floods that exploit the TCP three-way handshake between server and client to generate a denial of service attack. Another example is ping floods that use ICMP traffic to overwhelm the network. There are certain types of firewalls that can also monitor the sequence numbers of data packets as they flow through in order to guard against session hijacking. The firewalls react to these attacks by throttling the sessions or denying access to those ‘bad’ source IP addresses.
The other day, I read about a web application firewall. It works on a different level in that it examines the contents of the packets (payload) to see whether it’s legitimate or not. It checks the packet, for example, to see if the data sent for the date field on a web form is really a date and not some malicious embedded SQL command. This adds an extra line of defence for web applications by mitigating buffer overflow and data injection attacks. How awesome is that? Obviously, it’s not the “be-all and end-all” but it certainly adds another layer of security to ensure our assets are well protected.
However, having a firewall installed but not turned on doesn’t do much for security. Even working firewalls can sometimes allow malicious traffic through. For instance, firewalls cannot inspect encrypted data packets (although IPv6 apparently alleviates this problem) and there can be vulnerabilities in the firewall firmware itself which could be exploited. At the end of the day, firewalls can’t catch everything but it is a first line of defence.
As testers, we should not forget about the potential impact of firewalls on our testing. Do we need to execute our functional tests from within the firewall or from outside? Does it matter?
If we are doing performance testing, having a firewall will definitely have an impact. Performance times will be slower if the data packets are travelling through a firewall so it is important to consider whether we are executing our test cases within the firewall (inside of firewall) or taking our measurements with data travelling through the firewall. If our end users will be going through the firewall then our testing should reflect this.
If we are doing security testing, we need to ascertain what is expected of us. Are we simply doing a vulnerability scan or are we executing penetration tests (exploiting the vulnerabilities found)? Are we responsible for testing the firewall configuration? If so, we need test that only “allowed” data packets are let through and those that are not are blocked. As for any type of testing, defining the boundaries of what will be tested in security testing is very important.
What are other considerations for firewalls during testing? What are your thoughts? At minimal, don’t forget that the firewalls are there and what potential impact they may have on your testing!
Posted by Donna Chin