NetWare 5.1 comes with a very cool program called Management Portal, used to view and manage the server. (I absolutely LOVE this program!) It is now called Novell Remote Manager (NRM, or NoRM).
For the rest of this document, I will simply refer to the Management Portal as 'Portal', but don't confuse it with the Portal Services offering from Novell, a completely different product. This Portal is the web-based management feature of NetWare 5.1 servers. See the Novell Cool Solutions web site article on Portal called "Accessing
NetWare 5.1 files from a Browser".
There are some real security concerns when you run Portal (installed by default) on a NetWare 5.1 BorderManager firewall. In short, the default filter exceptions will ALLOW Portal access from the Internet.
Portal requires you to log into NDS in order to change settings, but if someone guesses (or knows) your Admin password, or the password to an account which has management rights to the server object, that person can do some nasty things to you, the least of which might be to simply reboot your server.
The problem is:
1. Portal defaults to listening on ports 80, 8008 and 8009
2. The BorderManager default filter exceptions [Note: BorderManager 3.6 and earlier] allow traffic to the
server's public IP address, from anywhere, on all those ports.
This tip will discuss three ways to block access to Portal from the Internet. The reader should immediately see from that discussion how to ALLOW access from the Internet, should Internet access be desired.
Portal will listen on the ports mentioned by default, but will not necessarily listen on the public IP address. Portal (like other services such as SLP) will listen, by default, on the first IP address bound. In most NetWare 5.1 servers, this will be whichever IP address is the first binding in the SYS:ETC\NETINFO.CFG file. The first address bound there might be the private address, the public address, or even the VPN tunnel address. In 99.9% of the cases, you will want the first address bound in that file to be the (or one of the) primary PRIVATE IP addresses.
You may need to manually edit the NETINFO.CFG file to change the address binding sequence, and then reboot the server to have the new sequence take effect.
If you want to manually edit the NETINFO.CFG file, first make a backup copy of it! Next, delete the NETINFO.CHK file, which is a 'check' file designed to warn you (in INETCFG) if someone has manually edited the file. The procedure for changing the bind sequence should be fairly obvious to the read by looking at the file contents.
You will need to move several lines, such as in the following example. The entries shown in bold text are all part of a group that should stay together. In the example below, the private IP address is 192.168.10.252, and it is bound first. It does not matter if IPX is bound in a different sequence. It does not matter if the board drivers are loaded in a different sequence.
#!BEGINBIND STATUS=ENABLED
BIND IP PRIVATE_EII ARP=Yes Mask=FF.FF.FF.0 Address=192.168.10.252
#192.168.10.252
#!END
#!BEGINBIND STATUS=ENABLED
BIND IP PUBLIC_EII ARP=Yes Mask=ff.ff.ff.0 Address=4.3.2.254
#4.3.2.254
#!END
#!BEGINBIND STATUS=ENABLED
BIND IP VPTUNNEL Address=192.168.99.254 Mask=FF.FF.FF.0 WAN=NBMA
#
#!END
Should you WANT to make Portal accessible from the Internet, and also not want the public IP address bound first, you can make that happen by configuring Portal to listen on additional IP addresses by using the HTTPBIND command. This procedure is described in a Novell Cool Solutions web site article on Portal called "Accessing NetWare 5.1 files from a Browser" and also in TID 10061072.
Portal will listen by default on ports 80, 8008 and 8009. You can change those port numbers so that the default exceptions block Portal from the Internet. You will want to Portal to listen on a port number below 1024 in order to have the default filter exceptions block access from the Internet. This step is not necessary if you have Portal configured not to listen on the public interface to start with.
On the other hand, it is conceivable that you WANT Portal to be accessed from the Internet, but only on some non-standard port number, and perhaps even using a custom filter exception to allow access to that new port number
only from a restricted IP address.
To change the default port numbers used by Portal, first log into Portal, then click on the red Network Management Portal text in the upper right of the browser. That links to a menu where you can change the primary, alternate and SSL listening ports for Portal.
Probably the best way to handle the security issue, not just with Portal, but with any of the services now supplied with NetWare 5.x, on a BorderManager 3.0-3.6 server, is to change the default filter exceptions. This is not something a beginner should do without a thorough understanding of how the filters and filter exceptions work! (See my book on configuring filter exceptions.)
The problem exception is the Dynamic/TCP default exception which allows TCP ports 1024-65535 to the public IP address of the server. The basics of this method are to a) delete that exception, and b) replace it with multiple exceptions that skip over port numbers of concern. Such port numbers include 2000 (used by CSATPXY), 2034 (default RCONJ port), and 8008 & 8009 (Portal).
So you may want to configure an exception that allows TCP destination ports 1024-1999 to the public IP address, then another that allows 2001-2033, another that allows 2035-8007, and another that allows 8010-65535.
Another method that is even more secure involves deleting all the default exceptions, and using a series of stateful exceptions tailored exactly to the services in use at your location, which is the approach BorderManager 3.7 and 3.8 default filter exceptions use. The problem with this approach is that it is not very flexible (you have to have stateful exceptions for every oddball web server your users need to get to), and having all stateful filter exceptions has simply never worked very reliably.
The method I prefer, and the one I show in the Advanced chapter of my book on configuring filter exceptions is to modify the default exceptions in BorderManager 3.6 and earlier (and replace most of them in 3.7 and later). The gist of the technique is to replace the default Dynamic/TCP filter exception with a custom one that is just the same, but has ACK bit filtering enabled. I explain the details on this one in my filtering book - you want to understand how it works and the ramifications to inbound traffic before you try this.