Now that firewalls use is becoming commonplace, more and more IT pros find themselves asking questions about their practical applications. Recently, on TechRepublic’s Discussion Center, four members posted questions about the implementation of these security methods.

Starting the ball rolling was a question from member Ronypp, who asked, “After we install a firewall, what are the methods for checking whether the policies are intact and the configurations are working?” Member aaube took this one on, beginning by explaining that what exactly needs to be tested depends on what the firewall is expected to do. “But even the most basic firewall provides network- and transport-layer protection, and this can easily be audited by a port scanner,” he said. Noting that there are many commercial port scanners available, aaube said he prefers Nmap, which is free. “Combined with the freely available front-end program (nmapfe), it’s as easy to use as a commercial scanner, and it’s more powerful than some commercial scanners.”

Aaube’s recommendation was to start with a TCP connect or SYN scan and a TCP FIN scan of all TCP ports, then a UDP scan of all UDP ports. “This might take some time (especially the UDP scan), but it will tell you what ports are open on your firewall. Any port that doesn’t need to be open should be closed,” he said. Once you’ve closed all the ports you absolutely don’t need to have open, run the scans again to make sure they’re really closed. “Then you can look at more complex scans, such as fragments and TCP ACK scanning, to see if your firewall gives out any information it shouldn’t. Once you know you’ve closed your ports, run a vulnerability scanner to make sure your firewall (and any systems behind it) aren’t vulnerable to known threats,” he said.

To this discussion, member GGortt added the need to test your firewall before, during, and after deployment, recommending tools, scanners, and packet sniffers such as Nmap, Ethereal, or Analyzer to do this. GGortt warned that one should “keep services like HTTP, FTP, Mail, and VPN out of your internal network. These are primary targets for crackers and should reside in a DMZ where access is controlled and monitored. Know your firewall intimately,” he said. “Understand what the rules are doing whether it be IPTables, IPFilter, CheckPoint, or whatever. If you are using IPTables, you can find many useful tools on or”

Next up in the discussion was a question from webdrewjen regarding his firewall setup (it’s on the company network with all incoming ports closed (i.e., Deny * from LAN and allow LAN access to *). The setup allows users to do whatever they want on the Internet but denies anyone on the Internet access to the LAN. The question is, with the firewall completely closed, what other possible ways are there for hackers to get in? “Can hackers still attack unpatched workstations and servers when they’re not visible to the Internet? Workstations and servers are not assigned Internet ip addresses.”

Member DukeBytes fielded the question. He recommended patching up the boxes. “If one of your users runs an exe type file someplace outside your firewall, it can still affect that user’s system. You are mostly very secure. A firewall will drop a lot of attacks, but if it thinks that it’s OK traffic (http/ftp, for example), it will let it through if it has been established correctly. So make sure your systems are patched up.” He also recommended that the member use a hardware-based firewall which, he felt, is harder to hack into by its very nature.

Member dmertz kept the discussion going by asking for thoughts on how secure Microsoft’s firewall/proxy Internet Security and Acceleration server is. George_ou gave it a thumbs-up. “It’s secure, flexible, and it performs very well on good hardware. You can cluster an ISA server on two Dual 2.8 GHz XEON DP based systems. You can also integrate virus scanning on all traffic on the ISA server on the same box.”

Member Nick Waterson was concerned about vulnerable ports. “So you install the firewall, you scan/probe the ports and all is buttoned down and running in stealth mode. However, you now need to run an FTP server or a web server) so the port has to be open. Apart from applying any server service packs, what can you do to prevent these open ports [from] being vulnerable?”

John Verry, a consultant for the security firm CQUR IT, responded. “If you need to run FTP, scan your external IP with a vulnerability scanning tool. Nexxus is free and accurate, or you can go to good security sites like bugtraq/CERT/SANS and look for information relating to potential vulnerability of your FTP server application. Also validate that Port 21 is only allowed to connect to your FTP server. You can be more explicit at the firewall, authenticating users, restricting times, etc.”