Users login

Create an account »

JOIN XATRIX

Users login

Home » Hacking News » Firewalling: Reject vs. Deny, Default-open vs. Default-closed

Firewalling: Reject vs. Deny, Default-open vs. Default-closed

by phiber on May 23rd, 2001 Firewalling: everybody does it. Some because of concern for their networks, others because of peer pressure. Most of us have carefully chosen our firewalling technology, ensuring that it cannot be tricked by wily hackers using packet fragmentation or other dirty tricks to slip data past it. Then, carefully crafting our networks, we have created chokepoints and placed firewalls in-between various networks.





We have made up our rule list, and checked it twice (or more in some cases) and carefully implemented these rules on our firewalls. At this point many people sit back with a sigh of relief and move on to other tasks. Unfortunately, there are a number of issues considered all too rarely by firewall administrators.


Reject vs. Deny

Most IP level firewalls have a number of options for handling a packet. The packet can typically be accepted, dropped, or sent through another set of rules for inspection (allowing you to break up your ruleset into more manageable pieces). When blocking a packet, you are faced with an important choice; whether to drop it silently, or generate an ICMP error message. Each choice has several advantages, and also creates a variety of potential problems.



If you generate an error message (i.e. ICMP unreachable), then the remote end will usually immediately stop trying to connect. This makes detecting some types of port scans more difficult since the remote end will likely send off only one packet, and give up after it receives the first error message. This also makes "shotgun" port scanning (i.e. where the attacker simply tries several thousand ports in rapid order) much easier, since the software will receive a definitive answer as to whether the port is blocked or not. Sending an error message does have several advantages, though, the primary one being to make life more difficult for someone who wants to spoof your IP addresses. Since your firewall is likely to generate ICMP error messages, the victim being attacked (by what looks like packets from your systems) will know something is up. To prevent you from sending error messages the attacker must take you offline, or otherwise act overtly to prevent data getting from the victim's network to yours and back.



This by its very nature creates another problem, because an attacker can spoof a victim's address, and send data to your systems, which will generate ICMP error messages, but, if the attacker's bandwidth and your bandwidth are larger then the victims bandwidth, you may inadvertently be used to flood someone offline. A somewhat more sophisticated version of this attack is for the attacker to send ICMP packets to your network broadcast address (so that every system on your network sees and responds to them), which is referred to as smurfing.



If you choose to silently discard packets, this will typically make it more difficult for an attacker to scan your ports, since the attacker's software will need to wait for packets to time out, and (if you are lucky) maybe even leave your network alone if they think it doesn't exist or is offline. Slow portscans or other activity used to hide portscans may be easier to detect as well, since legitimate software will often try to connect several times before timing out, whereas many portscan tools only send out one packet per connection attempt. Not returning any error messages also reduces the load placed on your firewall and outgoing bandwidth. Of course, this usually makes life easier for an attacker to ip spoof you. Since the victim's responses will be silently dropped by your firewall, the attacker will not need to take your network offline or otherwise interrupt communications between you and the victim.



Which of these two methods you use depends heavily on your threat models. If you are more worried about generic "shotgun" style portscans from largely unskilled script kiddies, or want to keep as low a profile as possible online, then silently dropping firewalled packets may be the way to go. If you are more worried about people spoofing your site then you may wish to go with returning error messages. A mixed approach may also be called for, returning error messages for networks you exchange large amount of "legitimate" traffic with and silently discarding from networks that are likely to be "hostile" (i.e. 24.*, which is broken up among cable providers).



Configuration of Rulesets and Server Layout

This is by far the most difficult subject for most firewall administrators. Even with "simple" rulesets things can become difficult in a hurry. Many administrators must make trade-offs between complexity, manageability, speed, performance and several other factors when creating rulesets.



At the highest level, we have the debate of closed by default vs. open by default. Generally speaking, the less services you need to offer and access, the easier it is to use a closed by default set of firewall rules. If, like most people, you have a very large network that is not fully under your control (i.e. a large academic network or corporate LAN/WAN), then chances are you will be forced to go with an open by default policy -- blocking things where you can. Then you are faced with tasks such as creating separate rulesets for different departments (which may not have contiguous network blocks), adding complex rules for special "exemptions" and so forth. Of course, the larger these rulesets get, the more likely it is for packets to be in the wrong order, an especially worrisome condition since flaws that allow packets through accidentally will not likely be noticed for some time.



At this point, administrators will typically need more then one firewall, often these are in "parallel", attached at entry points to the network and so on. In some cases, they may be setup in series as a form of additional security (i.e. using separate products and operating systems) or to spread the load (with half the rules on each). The best way to deal with this complexity is to actively test your firewalls. Your rules should express a set of wishes, such as "allow ftp and www, but block everything else". You can then come up with example packets you wish to be blocked (i.e. anything to port 111 from anywhere, or anything from 10.* to port 80). Using a variety of free tools, such as Nmap, you can then easily hit your firewall with the packets that should be blocked, and ensure they are being blocked. Of course, this testing is not 100% foolproof as there may be unintended exceptions. For example, port 20/21 (FTP) and 53 (DNS) often cause difficulty with firewalls, and the rules regarding these packets may be more promiscuous then intended.



Summary

Running firewalls is not a trivial task. Chances are, things will only get more complicated as time goes on, especially with use of protocols such as H.232, peer-to-peer file sharing, and other technologies that do strange things on your network. No matter which technology you use, it will likely fail at some point unless you have solid procedures and management guidelines in place (and even then, there is a chance that something can go wrong). Do you know the layout of your network, and all the access points to it? Do you know where every single firewall is, what software it is running and what rulesets it has installed? Do you have "test cases" for packets you wish to block or allow that enable you to test your firewalls? Do you know who is in charge of the various firewalls and how to contact them in an emergency? Chances are you have some homework (workwork?) to do.





By By Kurt Seifried ([email protected]) for SecurityPortal.


Newsletter signup

Signup to our monthly newsletter and stay in touch with IT news!

Free E-books

We've got ebooks! But they're not online. :( Please give us a few days to bring downloads back.

Contact

Have something to say or just wanna drop us a line? Please keep this in mind: to spam, we reply with spam.

Contact us »