SuSE has a utility for creating iptables policies, called SuSEfirewall2. If you install this package, then all you need to do is edit the file /etc/rc.config.d/firewall2.rc.config, run SuSEconfig, and
reboot. If you know anything at all about TCP/IP, however, it’s probably not that much more trouble to write your own iptables script.
Similarly, Red Hat and Mandrake users can avail themselves of Bastille Linux’s "Firewall" module. Bastille’s Q & A is actually a simple, quick way to generate a good iptables configuration.
There are also a number of GUI-based tools that can write iptables rules. As with SuSEfirewall2 and Bastille, it’s up to you to decide whether a given tool is convenient and therefore worth adding complexity to your bastion host in the form of extra software.
We’ve covered only a subset of netfilter’s features, but it’s an extremely useful subset. While local packet filters aren’t a cure-all for system security, they’re one of the thicker layers of our security onion, and well worth the time and effort it takes to learn iptables and fine-tune your filtering policies.
3.1.9 Checking Your Work with Scanners
You may have heard scare stories about how easy it is for evil system crackers to probe potential victims’ systems for vulnerabilities using software tools readily available on the Internet. The bad news is that these stories are generally true. The good news is that many of these tools are extremely useful (and even designed) for the legitimate purpose of scanning your own systems for weaknesses.
In my opinion, scanning is a useful step in the system-hardening process, one that should be carried out after most other hardening tasks are completed and that should repeated periodically as a sanity check. Let’s discuss, then, some uses of nmap and nessus, arguably the best port scanner and security scanner (respectively) available for Linux.
3.1.9.1 Types of scans and their uses
There are basically two types of system scans. Port scans look for open TCP and UDP ports — i.e., for "listening services." Security scans go a step further and probe identified services for known weaknesses. In terms of sophistication, doing a port scan is like counting how many doors and windows a house has; running a security scan is more like rattling all the doorknobs and checking the windows for alarm sensors. 3.1.9.2 Why we (good guys) scan
Why scan? If you're a system cracker, you scan to determine what services a system is running and which well-known vulnerabilities apply to them. If you're a system administrator, you scan for essentially the same reasons, but in the interest of fixing (or at least understanding) your systems, not breaking into them. It may sound odd for good guys to use the same kinds of tools as the bad guys they're trying to thwart. After all, we don't test dead-bolt locks by trying to kick down our own doors. But system security is exponentially more complicated than physical security. It's nowhere near as easy to gauge the relative security of a networked computer system as is the door to your house.
Therefore, we security-conscious geeks are obliged to take seriously any tool that can provide some sort of sanity check, even an incomplete and imperfect one (as is anything that tries to measure a moving target like system security). This is despite or even because of that tool's usefulness to the bad guys. Security and port scanners give us the closest thing to a "security benchmark" as we can reasonably hope for.
3.1.9.3 nmap, world champion port scanner
The basic premise of port scanning is simple: if you try to connect to a given port, you can determine whether that port is closed/inactive or whether an application (i.e., web server, FTP dæmon, etc.) is accepting connections there. As it happens, it is easy to write a simple port scanner that uses the local connect( ) system call to attempt TCP connections on various ports; with the right modules, you can even do this with Perl. However, this method is also the most obtrusive and obvious way to scan, and it tends to result in numerous log entries on one's target systems.
Enter nmap, by Fyodor. nmap can do simple connect( ) scans if you like, but its real forte is stealth scanning . Stealth scanning uses packets that have unusual flags or don't comply with a normal TCP state to trigger a response from each target system without actually completing a TCP connection.
nmap supports not one, but four different kinds of stealth scans, plus TCP Connect scanning, UDP scanning, RPC scanning, ping sweeps, and even operating-system fingerprinting. It also boasts a number of features more useful to black-hat than white-hat hackers, such as FTP-bounce scanning, ACK scanning, and Window firewall scanning (many of which can pass through firewalls undetected but are of little interest to this book's highly ethical readers). In short, nmap is by far the most feature-rich and versatile port-scanner available today.
Here, then, is a summary of the most important types of scans nmap can do: TCP Connect scan
This uses the OS’s native connect( ) system call to attempt a full three-way TCP handshake (SYN, ACK-SYN, ACK) on each probed port. A failed connection (i.e., if the server replies to your SYN packet with an ACK-RST packet) indicates a closed port. It doesn’t require root privileges and is one of the faster scanning methods. Not surprisingly, however, many server applications will log connections that are closed immediately after they’re opened, so this is a fairly "noisy" scan. TCP SYN scan
This is two-thirds of a TCP Connect scan; if the target returns an ACK-SYN packet, nmap immediately sends an RST packet rather than completing the handshake with an ACK packet. "Half-open" connections such as these are far less likely to be logged, so SYN scanning is harder to detect than TCP Connect scanning. The trade-off is that since nmap, rather than the kernel, builds these packets, you must be root to run nmap in this mode. This is the fastest and most reliable TCP