Tue 30 Jan 2007
Firewalls Firewalls Firewalls are another useful tool for improving the security of our system. They come in different flavors, but all do essentially the same thing; network traffic passing through the firewall is analyzed and the decision about what to do with the traffic (let it through, throw it away and tell the sender, throw it away and don’t tell the sender, etc.) is made based on the rules configured by the firewall administrator. Some firewalls analyze network traffic at the packet level; these are called “packet filters”. They can work with any network traffic, but can implement only fairly simple rules based on the contents of the packet header (typically where the packet came from, where it’s going to and what flags are set). Other firewalls understand more about the higher level protocols used for e-mail and web browsing. They can perform more complex tasks such as scanning e-mail attachments for viruses, or requiring users to authenticate themselves before allowing access to certain Web sites. In a typical corporate environment, the protection provided by simple packet filtering firewalls is enhanced with more sophisticated firewalls and proxies that can analyze the contents of the packets as well as their headers. Since the Linux kernel has built in packet filtering capabilities, we’ll look at how we can configure these to enhance the security of our Red Hat Linux system. Network Connections Before we get into the mechanics of configuring the Red Hat Linux built in firewall, we need to understand how network connections work. For TCP/IP connections, there are two basic protocols; TCP (Transmission Control Protocol) and UDP (Universal Datagram Protocol). TCP is a connection-oriented protocol. This means that when two machines wish to communicate via TCP, their TCP stacks negotiate a connection and the application (such as a Web browser talking to Web server using HTTP), and TCP ensures that packets are delivered to the application in the right order, with no duplicates. The mechanism for setting up a connection involves the exchange of TCP packets between the systems that have different flags set in their headers. First, the client (that’s the machine that wants to establish a connection) sends the server (the machine the client wants to connect to) a TCP packet with the SYN flag set. The server replies with a packet whose header has both the SYN and ACK flags set, and when the client receives this packet, it sends one back with just the ACK bit set. From this point on, the connection is established, and the client and server can exchange packets. When the connection is no longer required, either party can request that it is closed by sending the other end a TCP packet with the FIN flag set. The recipient replies with a packet having the ACK flag set, then performs whatever termination steps are required by the application. When this is done, a packet with the FIN flag set is sent back to the end that initially requested the connection to be closed. When this is acknowledged with a packet where the ACK bit is set, the connection is finished. UDP is a much simpler, connection-less protocol. All that happens here is that the originator sends the UDP datagram to the recipient, and the network layer tries its best to deliver it. Unlike TCP, delivery is not guaranteed, and datagrams traveling over long distances may go by different routes and therefore arrive out of order at the other end. All the logic for synchronizing client and server, or re-trying failed packets, has to be handled by the application code. It is important that we understand the differences between TCP and UDP when configuring firewalls. With TCP, the direction of the connection (i.e. incoming, where the client is remote and the server is on our machine, or outgoing where the client is local and the server is remote) is determined by the exchange of 425
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services