The security of a networked computer is very much affected by network traffic. Remote computer can launch attacks from anywhere to an Internet connected host. Security, much like a chain, is only as strong as the as the weakest link. Let’s first consider the individual links in this chain.
First, there is the NIC (network interface card) itself. By itself, a NIC should never become a vulnerability. This is because when a NIC receives a packet, it is up to the device driver of the operating system to process it. A badly designed NIC can affect reliability, but not security.
A NIC device driver, on the other hand, can be a problem. This is because code of a device driver often run at a high privilege mode. As a result, any exploit that successfully attacks a device driver can quickly gain privileged access to the operating system itself. This is not a unique problem in Linux. For year, the blue-screen-of-death of NT-based kernels is largely due to poorly written third party device drivers.
After the device driver, the kernel gets the network traffic. At this point, the network traffic is raw, which means it is at the data-link layer. The operating system is, then, responsible to strip all the data-link layer wrapping, and interpret the payload so the network traffic raises to network layer. One popular network-layer protocol is TCP/IP, which actually consists of two protocols: TCP (Transport Control Protocol) and IP (Internet Protocol). IP is technically in the network layer, and TCP is in the transport layer. UDP (user datagram protocol) is at the same level as TCP, but it is connectionless.
The kernel contains the logic to interpret a packet so it is recognized as a part of a TCP packet/fragment, a UDP packet, and ICMP packet. This logic (code) is often known as the TCP/IP stack. The TCP/IP stack is quite critical because if it contains any vulnerability, then the attacking code gains kernel level privilege instantaneously. Note that the TCP/IP stack consists of some fairly complicated logic, which increases the chances of bugs (defects) that can be used in an attack. Fortunately, the TCP/IP stack of most operating systems are well tested, and attack at this level is usually considered futile.
After the TCP/IP stack, network traffic is directed to the proper programs to handle session, presentation and application layer logic. There three layers are often combined, and they are usually handled outside of the operating system. For example, ftpd and telnetd are daemons that handle the protocols FTP and telnet protocols, respectively, and they are started by inetd or xinetd.
At this layer (application layer), much code is entirely based on community contribution. Some are well tested, while others are not. For example, for years, a certain FTP daemon is well known for having vulnerabilities. However, in order for these daemons to do their job, they are often run as root, which means exploits can gain privileged access to the operating system. This is why a good administrator minimizes the number of active services (daemons) to lower the vulnerabilities.
The way iptables fit into this picture is that it permits the operating system to control what traffic reaches the session, presentation and application layer. This means you can have a system with ftpd installed, but also have iptables configured to stop all traffic to the FTP port. As a result, even if the ftpd daemon has vulnerabilities, network traffic cannot reach it.
iptables can also specify who can use what. In other words, if computers on a local area network can be trusted to use FTP, then iptables can be configured to selectively only permit FTP connections to/from computers on the local area network. This beats uninstalling ftpd altogether. The same applies to other protocols for which hosts of a local area network can be more trusted.