[Updated June 2005] I'm sure things have improved in the half decade since I tested novell's
firewall. That's plenty of time for any company to get their act together,
and their decision to run on top of a *nix os does seem to bode well. Back when I played with it, though, I was less than impressed. This is what I had to say back then
Seven reasons not to use BorderManager
1. Novell complicates simple tasks
Compare adding a NAT rule in BSD's ipnat:
echo "rdr ne1 64.17.42.5/0 port 80 -> 192.168.1.5 port 80" >> /etc/ipnat.rules
ipnat -c -f /etc/ipnat.rules
with adding a NAT rule in Novell's INETCFG.NLM:
load inetcfg
Select protocals > Bindings
Select the NIC you want to bind an address to
Select "Expert TCP/IP Bind Options"
Select Network Address Translation
Select Network Address Translation Table
Press Insert
Type in the Public and Private addresses
Press Escape so the rule gets added to the NAT table
Press Escape
Press Escape
Select Yes (you are choosing to save your changes)
Press Escape
Press Escape
Select Yes (...so you can leave INETCFG.NLM)
down the server
restart the server
2. BorderManager's implimentation of NAT is broken
Most good firewalls are capable of redirecting the endpoints of two sockets (two ip
address/port combinations) to one ipaddress. For example, you would do this in ipnat as follows:
echo "rdr ne1 64.17.42.5/0 port 80 -> 192.168.1.5 port 80" >> /etc/ipnat.rules
echo "rdr ne1 64.17.42.5/0 port 22 -> 192.168.1.9 port 22" >> /etc/ipnat.rules
ipnat -c -f /etc/ipnat.rules
BorderManager cannot do this. If you have mapped 64.17.42.5 to 192.168.1.5 for port 80 on a
BorderManager box, any other ports on 64.17.42.5 must also map to 192.168.1.5
3. The Novell documentation for BorderManager is inconsistant
example 1
A. The Installation and Setup (100-004452-002-B) guide for BorderManager Enterprise Edition 3, which is included with
BorderManager 3.5 when the product ships, recommends configuring the firewall by setting the default action to
"Deny Packets in Filter List", setting up the list with a single filter of ALL ALL (all ports, all addresses), and
then setting up exceptions to allow specified traffic through the firewall.
B. Novell's Guide to BorderManager(0-7645-4540-X), which is also published by Novell Press, says to set the default
rule to "Permit Packets in Flilter List", then use rules in the filter list to allow specified traffic through the
firewall.
4. BorderManager can't filter on ICMP type
As near as I can tell, you either allow ICMP or you disallow it. If you let people ping your web server, you let them send it
ICMP redirects
5. The system-defined rules are broken
On close inspection of the rule named "pop3-stateful", you will see that the line for stateful filtering reads "Disabled". The rule named "realaudio" only allows connections to destinations at port 7070, which prevents use of realaudio sites using tcp on port 554. I'm sure there are other examples, but those are the ones that I've personally dealt with. How did I deal with them, you may ask? I created new rules that had the proper flags/ports set....there's no way to modify the system-defined rules in bordermanager.
6. The HTTP rules are dangerous
You either allow it, or you don't. There's no way to filter out PUT, DELETE, LINK, or UNLINK commands. (Yes, I know: The web server ought to be configured so that it doesn't allow those anyway. Personally, though, I'm a believer in the idea of using a belt and suspenders; i.e. multiple layers of protection.)
7. The password is in plain text
BorderManager doesn't require an NDS password to run FILTCFG.NLM. It only requires the rconsole password, which is, of course stored in the netinfo.cfg file. Yes, I know that normal users don't have the ability to read that password, but it still bothers me.
|