Test Firewall Rules to Prevent Network Hacks
As part of your ethical hacking, you can test your firewall rules to make sure they’re working as they’re supposed to. Breaches in firewalls can easily compromise your best efforts at security. A few tests can verify that your firewall actually does what it says it’s doing. You can connect through the firewall on the ports that are open, but what about the ports that can be open but shouldn’t be?
Netcat can test certain firewall rules without having to test a production system directly. For example, you can check whether the firewall allows port 23 (telnet) through. Follow these steps to see whether a connection can be made through port 23:
Load Netcat on a client machine inside the network.
This sets up the outbound connection.
Load Netcat on a testing computer outside the firewall.
This allows you to test from the outside in.
Enter the Netcat listener command on the client (internal) machine with the port number you’re testing.
For example, if you’re testing port 23, enter this command:
nc –l –p 23 cmd.exe
Enter the Netcat command to initiate an inbound session on the testing (external) machine. You must include the following information:
The IP address of the internal machine you’re testing
The port number you’re testing
For example, if the IP address of the internal (client) machine is 10.11.12.2 and the port is 23, enter this command:
nc –v 10.11.12.2 23
If Netcat presents you with a new command prompt (that’s what the cmd.exe is for in Step 3) on the external machine, you’ve connected and can execute commands on the internal machine! This can serve several purposes, including testing firewall rules, network address translation (NAT), port forwarding and — well, uhhhmmm — executing commands on a remote system!
AlgoSec Firewall Analyzer
A commercial tool with great results is AlgoSec’s Firewall Analyzer.
AlgoSec Firewall Analyzer, and similar ones such as Athena Firewall Grader, allows you to perform an in-depth analysis of firewall rulebases from all the major vendors and find security flaws and inefficiencies you’d never uncover otherwise.
Firewall rulebase analysis is a lot like software source code analysis — it finds flaws at the source that humans would likely never see even when performing in-depth ethical hacking tests from the Internet and the internal network. If you’ve never performed a firewall rulebase analysis, it’s a must!
Countermeasures against firewall rulebase vulnerabilities
The following countermeasures can prevent a hacker from testing your firewall:
Perform a firewall rulebase audit. You cannot secure what you don’t acknowledge. There’s no better example of this than your firewall rulebases. No matter how seemingly simplistic your rulebase is, it never hurts to verify your work using an automated tool.
Limit traffic to what’s needed.
Set rules on your firewall (and router, if needed) that passes only traffic that absolutely must pass. For example, have rules in place that allow HTTP inbound traffic to an internal web server, SMTP inbound traffic to an e-mail server, and HTTP outbound traffic for external web access.
This is the best defense against someone poking at your firewall.
Block ICMP to help prevent an external attacker from poking and prodding your network to see which hosts are alive.
Enable stateful packet inspection on the firewall to block unsolicited requests.