Filtering requires that the firewall filtering rules for allowing and denying packets
Note Show The A packet filtering firewall filters incoming and outgoing network packets based on the packet header information. You can create packet filter rules that determine whether packets are accepted or rejected. For example, if you create a rule to block a port, any request is made to that port that is blocked by the firewall, and the request is ignored. Any service that is listening on a blocked port is effectively disabled. The Oracle Linux kernel uses the Netfilter feature to provide packet filtering functionality for IPv4 and IPv6 packets respectively. Netfilter consists of two components:
To implement a simple, general-purpose firewall, you can use the Firewall Configuration GUI (system-config-firewall) to create basic Netfilter rules. Figure 24.1 shows the Firewall Configuration GUI. Figure 24.1 Firewall Configuration To create a more complex firewall configuration, use the iptables and ip6tables utilities to configure the packet filtering rules. Netfilter records the packet filtering rules in the The
The default table, which is mainly used to drop or accept packets based on their content. Mangle This table is used to alter certain fields in a packet. NAT The Network Address Translation table is used to route packets that create new connections. The kernel uses the rules stored in these tables to make decisions about network packet filtering. Each rule consists of one or more criteria and a single action. If a criterion in a rule matches the information in a network packet header, the kernel applies the action to the packet. Examples of actions include:
Continue processing the packet. DROP End the packet’s life without notice. REJECT As Rules are stored in chains, where each chain is composed of a default policy plus zero or more rules. The kernel applies each rule in a chain to a packet until a match is found. If there is no matching rule, the kernel applies the chain’s default action (policy) to the packet. Each
Packets that are not addressed to the local system pass through this chain. INPUT Inbound packets to the local system pass through this chain. OUTPUT Locally created packets pass through this chain. The chains are permanent and you cannot delete them. However, you can create additional chains in the filter table. For more information, see the 6.10 Putting It All TogetherThis section works through a few more examples to show how many of the concepts we've talked about in this chapter come together in the real world. For detailed discussions of the packet filtering characteristics of particular protocols, see Chapter 8. This section is designed to demonstrate the process of developing a filter set; filters are elaborated as we go on, rather than being produced in final form. We aren't attempting to show a complete filter set for any site. Every site is different, and you can get burned by packet filtering if you don't understand all the details and implications of its use in your particular environment. We want people to carefully consider and understand what they're doing - not blindly copy something out of a book (even ours!) without a careful consideration of how relevant and appropriate it is for their own situation. In any case, a full solution for a site requires considering packet filtering, proxying, and configuration issues. That process is illustrated in Chapter 9, Two Sample Firewalls. Let's start with a simple example: allowing inbound and outbound SMTP (so that you can send and receive electronic mail) and nothing else. You might start with the following rule set.
Now, let's consider some sample packets to see what happens. Let's say that your host has IP address 172.16.1.1, and that someone is trying to send you mail from the remote host with IP address 192.168.3.4. Further, let's say the sender's SMTP client uses port 1234 to talk to your SMTP server, which is on port 25. (SMTP servers are always assumed to be on port 25; see the discussion of SMTP in Chapter 8):
Figure 6.10 shows this case. Figure 6.10: Packet filtering: inbound SMTP (sample packets 1 and 2)In this case, the packet filtering rules permit your incoming email:
What about outgoing email from you to them? Let's say that your SMTP client uses port 1357 to talk to their SMTP server:
Figure 6.11 shows this case. Figure 6.11: Packet filtering: outbound SMTP (sample packets 3 and 4)Again, in this case, the packet filtering rules permit your outgoing email:
Now, let's stir things up. What happens if someone in the outside world (for example, someone on on host 10.1.2.3) attempts to open a connection from port 5150 on his end to the X11 server on port 6000 on one of your internal systems (for example, 172.16.3.4) in order to carry out an attack? (See Chapter 8 for a discussion of X11 and some of its vulnerabilities.)
Figure 6.12 shows this case. Figure 6.12: Packet filtering: inbound SMTP (sample packets 5 and 6)The rule set shown above allows this connection to take place! In fact, the rule set shown above allows any connection to take place as long as both ends of the connection are using ports above 1023. Why?
There are probably lots of vulnerable servers listening on ports above 1023 at your site. Examples are X11 (port 6000), OpenWindows (port 2000), databases (Sybase, Oracle, Informix, and other databases commonly use site-chosen ports above 1023), and so on. This is why you need to consider a rule set as a whole, instead of assuming that if each rule or group of rules is OK, the whole set is also OK. What can you do about this? Well, what if you also looked at the source port in making your filtering decisions? Here are those same five basic rules with the source port added as a criterion:
And here are those same six sample packets, filtered by the new rules:
As you can see, when the source port is also considered as a criterion, the problem packets (numbers 5 and 6, representing an attack on one of your X11 servers) no longer meet any of the rules for packets to be permitted (rules A through D). The problem packets end up being denied by the default rule. OK, now what if you're dealing with a slightly smarter attacker? What if the attacker uses port 25 as the client port on his end (he might do this by killing off the SMTP server on a machine he controls and using its port, or by carrying out the attack from a machine that never had an SMTP server in the first place, like a PC), and then attempts to open a connection to your X11 server? Here are the packets you'd see:
Figure 6.13 shows this case. Figure 6.13: Packet filtering: inbound SMTP (sample packets 7 and 8)As you can see, the packets would be permitted, and the attack would likely succeed (X11 security being as weak as it is). So what can you do? The solution is to also consider the ACK bit as a filtering criterion. Again, here are those same five rules with the ACK bit also added as a criterion:
Now, packet 7 (the attacker attempting to open a connection to your X11 client) will fail:
The only difference in this rule set are in rules B and D. Of these, rule D is the most important, because it controls incoming connections to your site. Rule B applies to connections outgoing from your site, and sites are generally more interested in controlling incoming connections than outgoing connections. Rule D now says to accept incoming packets from things that are supposedly SMTP servers (because the packets are coming from port 25) only if the packets have the ACK bit set; that is, only if the packets are part of a connection started from the inside (from your client to his server). If someone attempts to open a TCP connection from the outside, the very first packet that he sends will not have the ACK bit set; that's what's involved in "opening a TCP connection." (See the discussion of the ACK bit in the "TCP" section of "Protocols above IP" earlier in this chapter.) If you block that very first packet (packet 7 in the example above), you block the whole TCP connection. Without certain information in the headers of the first packet - in particular, the TCP sequence numbers - the connection can't be established. Why can't an attacker get around this by simply setting the ACK bit on the first packet? If he does, the packet will get past the filters, but the destination will believe the packet belongs to an existing connection (instead of the one with which the packet is trying to establish a new connection). When the destination tries to match the packet up with the supposed existing connection, it will fail because there isn't one, and the packet will be ignored.
What is filtering in firewall?A packet filtering firewall is a network security feature that controls the flow of incoming and outgoing network data. The firewall examines each packet, which comprises user data and control information, and tests them according to a set of pre-established rules.
What do the rules on a packet filtering firewall include?The information the packet filtering router looks for includes (1) the packet source IP address and source TCP/UDP port, and (2) the destination IP address and destination TCP/UDP port of the packet.
What is the role of filtering rules?Firewall administrators create packet filtering firewall rules to prevent packet transmission and only allow packets that match specific IP addresses or ports. They can create rules that allow just packets intended for their IT services to pass through while rejecting all others.
How do firewalls make packet filtering decisions?While a packet filtering firewall only examines an individual packet out of context, a stateful firewall is able to watch the traffic over a given connection, generally defined by the source and destination IP addresses, the ports being used, and the already existing network traffic.
|