mn :: comp :: net

LRP Firewall FAQ
Jack Coates, jack@monkeynoodle.org

The proper policy is default deny, then open up required ports if needed. While this sounds overly simplistic, it's the best policy possible. The weakness comes about in the ports that are required. If you really want to know more, Building Internet Firewalls by Chapman & Zwicky is a good start. In the meantime, here's a quick overview.

When a client wants to talk to a server, generally it will choose a random port between 1025 and 65535 as the source port. Destination is the server's well known service port, such as 80, 25, 443, &c. There are exceptions and this isn't a published standard, but most of the time that's the way it works in real life.

If you want to make your network more secure, you might use Access Control Lists (ACL's) to build a policy that denies traffic. Depending on the platform you're working with, this might mean ipfwadm statements, ipchains statements, or Cisco IOS commands. Unfortunately, if you want to make a server available you can't predict where the clients will be or what source port they'll use, so you have to write a rule that allows any client to come from any port 1025:65535 into your port 80.

If you don't like the idea of doing that, you might implement a stateful inspection engine, such as Check Point's FireWall-1 or Cisco's CBAC. Those work by maintaining a table of known sessions:

outside	firewall	inside
SYN request, 1025 -> 80
	does policy allow connection to port 80? If yes, then open 1025 <-> 80, forward this packet.
		SYN-ACK, 1025 <- 80
	session is real, so enter it into the state table. Future traffic on TCP 1025 <- 80 can be accepted without inspection until timeout.

Only traffic that is from the originally initiated session will be allowed in. Theoretically this means that the session will be harder (though not impossible) to hijack, though in real life it means very little. Hijacking a session is too hard and has too little payoff compared to the real threats: distributed denials of service (DDoS), breaking into servers, and snarfing useful information out of the traffic stream. More on these later. The stateful inspection engine vendors will also tell you that stateful inspection allows the firewall to "make sure that [telnet] is really [telnet]" or even "make sure that the commands in the traffic stream are proper [telnet] commands." The first statement is marketingspeak for "deny client ports that are known service ports." In other words, here's a possible attack:

outside	firewall	inside
SYN request, 21 -> 23
	policy allows connection to port 23,so open 21 <-> 23, forward this packet.
		SYN-ACK, 21 <- 23
	session is real, so enter it into the state table. Future traffic on TCP 21 <- 23 can be accepted without inspection until timeout.
Kill telnetd with a buffer overflow and initiate FTP connection from inside server.

So Check Point will deny SYNs from source ports that are well known service ports. Of course, since well-known service ports are merely a convention and TCP connections can be made from any port to any port, I fail to see how this behavior, in and of itself, provides very much protection against a tool like ftp_ozone.

Now if the firewall was actually able to analyze the payload of packets for valid commands in the service which is supposedly being allowed, that would be pretty keen and would make the second Check Point marketing statement accurate. However, it's not true and won't be true any time soon because doing so would soak performance, even if it were possible to implement. If you want to analyze the application level payload you have to use a proxy, not a stateful inspection engine.

One cool thing that is very simple which Check Point does is deny incoming packets which aren't SYN packets, unless they match an entry in the state table. These generate a log message, "received packet from unknown established TCP session." (This functionality is broken by service pack 2 to the 4.1 release, unfortunately.) Categorically denying this sort of traffic is a good idea, so let's all look forward to trying out the stateful inspection engine in kernel 2.4. Another nice thing Check Point trains its admins to do is implement a "stealth rule." This rule silently drops any packet which is destined for one of the firewall's interfaces. This can and should be done with LRP as well.

If you really want tight control, you use a proxy server. This is a server that provides the same service(s) that you wanted to make public, but it relays the traffic between the client and the real server. By making the proxy server tight and featureless, the security admin can reduce the foothold presented to a hacker. In a DoS attack, the solution fails safe by crashing the proxy, not real systems. However, proxies are relatively slow, difficult to configure, and usually don't support the latest and greatest bells and whistles. Both CPFW and Cisco provide some limited proxy service for common things like SMTP and HTTP. It is architecturally flawed to do so, and the only reason they do it is to provide a lower price. The "single box for a single purpose" model has been evolved through experience, not vendor whim. I cannot stress enough that you should be very careful when choosing proxy software. If the proxy itself is vulnerable to buffer overflow, you've just given the bad guys a root shell on your firewall with access to the networks that the firewall is supposed to protect. If you're going to use a proxy, INSIST on a well audited open source platform. If the network you're protecting is valuable, I recommend using an OpenBSD server with Postfix for the SMTP and another OpenBSD server with Squid for the HTTP. Using commercial software because it is enough to show due diligence may make your lawyers happy, but it won't keep out the bad guys. Commercial security software may or may not be safe and if you get the right people to talk to you off-the-record, the companies involved will admit it. Quality of the software and market capitalization have no correlation.

If you're not yet fully convinced that putting a proxy onto your firewall box or border router is a bad idea, think about this. Even if the proxy software you want to use is certifiably 100% bug free and otherwise invulnerable to the common buffer overflow (snicker), it is still a single process operating on a server/router/whatever which has other things to do (e.g. analyzing and passing or denying traffic). This means that events which cause high CPU utilization or RAM utilization will take away from the effectiveness of your firewall. It also means that your firewall needs to receive traffic on the ports which the proxy application listens to, so bye-bye stealth mode.

Now, here's how these solutions stack up against the real world attacks:

• DDoS: There are two general families out there, SYN flooders and bandwidth hogs. Flooders are elegant tools which exploit a poorly considered implementation choice or protocol flaw to consume the resources of a piece of equipment. Hogs are brute-force tools that simply use hardware to overpower hardware. For the detail-oriented, I'm grouping frag-bombers like rape.c under SYN flooders, even though the plumbing is different, because the intent is the same.
• ACLs are no defense against SYN flooders, because they don't monitor TCP connection status. Bandwidth effects can be theoretically minimized by use of QoS tools (WFQ and WRED in Cisco, kernel 2.2 and iproute2 in Linux), but it's an escalation game. Sooner or later they'll get enough TFN nodes to take your site down.
• Stateful inspection engines can help a little against SYN flooders. Both CPFW-1 and CBAC have some simple DoS prevention tools, but they only work against a single attacker at a time. Search for Tribe Flood Network and Trinoo for more info.
• Proxy servers will fall on their faces in a SYN flood. That's what they're supposed to do, it's called failing safe. Personally, I'd rather see it happening on a dedicated server in a DMZ than in the firewall's process space.
A common mistake is to assume that DoS isn't that big of a deal since the pipe to the Internet is low bandwidth and therefore won't be enough traffic to crash a server or anything. Setting aside the fact that for many companies the Internet connection is as important as the phones, this attitude fails to take into account that the ISP may take corrective action (up to cutting you off permanently or billing you for the hours required to isolate and stop the attack). The other mistake in the dismissal of DoS attacks is the assumption that attacks are originating from outside. Disgruntled employees are just as capable of running evil tools as bored teenagers, and have much better motivation and bandwidth. Don't underestimate DoS tools -- they're simple, but so is a club.
• Breaking into servers: An alarmingly large amount of software will crash if you feed it too much information or unexpected information. Frequently when the software crashes it leaves its network ports open and a command prompt with its permissions waiting to be accessed. Servers may also allow remote execution of arbitrary code through a number of exploits. Search www.securityfocus.com and www.rootshell.com for some examples, but if you don't see your software there, it may not mean anything. Generally a problem or exploit shows up in public for one of four reasons: the discoverer is a security professional who wants to help the vendor or get recognition, or the discoverer is a hacker/cracker who wants to embarrass the vendor or get recognition. Ask yourself this: if you were cracking into systems for fun and profit, would you sacrifice your best tools into a public arena where administrators, vendors, and other crackers could get at them? So, let's return to how our defensive tools stack up against software exploits:
  • ACLs are no defense.
  • Stateful inspection engines are no defense.
  • Proxy servers could theoretically be able to defend against some attacks by doing bounds-checking, but I'm not aware of any actual implementations that actually do so.
  Server software can be thought of as the plate glass window at a store. There's no way to prevent someone throwing a rock and breaking it, but you can put an alarm on the window and/or bars behind it. By securing the rest of the server system, using good passwords, avoiding clear text protocols, using Tripwire and the NT equivalent, using an IDS and other management tools one can prevent a lot of damage from taking place.
• Snarfing useful information: If the hacker can get access to a machine long enough to download some software, he can scan the network segment and discover what machines are connected, what protocols they're using, what operating systems they run, and in some cases what versions of certain programs are in use. Given more time the local or domain password file can be cracked (and no, Windows domain passwords are not safe). If clear text protocols are in use, such as POP3 and Telnet, he can snarf passwords out of them. He can also grab files from the wire if they're passed with NFS or SMB. Switched architecure is the best way to slow this process down, though some switches are vulnerable to attacks which will break down the boundaries between VLANs.

To summarize, you wouldn't see much benefit from switching away from Linux Router Project onto a commercial firewall package for security policy implementation. While it is theoretically tighter to use a stateful inspection engine, the true value to a package like Check Point is in the management GUI, support channel, and added services such as VPN and virus scanning.

Jack Coates
jack@monkeynoodle.org

Last modified: Oct 24, 2008 2:28 pm. Contact me.