Novell Home

AppNote: Alternate Approach to Maintaining NBM Packet Filters

Novell Cool Solutions: AppNote
By Bhavani S T, Chitra Atul Gurjar

Digg This - Slashdot This

Posted: 24 Aug 2004
 

An Alternate Approach To Easily Maintain Novell BorderManager Packet Filters

Bhavani S T
stbhavani@novell.com
Software Consultant

Chitra Atul Gurjar
gchitra@novell.com
Software Consultant

This AppNote shows how the customer can leverage the Novell LDAP utilities (available with eDirectory) for adding/modifying and deleting filters collectively, without having to go through FILTCFG or iManager. The article also helps you add filters individually.

Support files for this AppNote are available here.

Objective

Large distributed networks need packet filtering configurations. The servers in such organizations are spread over geographical areas and it becomes difficult for system administrators to individually configure the packet filters at each and every location.

The objective of this solution is to provide customers an alternate way to create and add packet filters on the Novell BorderManager (NBM) server without having to use filtcfg or iManager. This will cut down the effort involved in adding large numbers of such filters manually, and will help with adding filters to multiple servers (on to which packet filters need to be added). This paper shows you how an administrator can be located at one place, use one configuration file, and add the same packet filter on multiple servers.

Intended Audience:

  • System administrators
  • Test engineers
  • Users who use filters actively either to setup or to test filters their exceptions

Users of this tool must be familiar with:

  • LDIF files
  • Novell LDAP tools
  • eDirectory
  • filtcfg utility and its functionality
  • Novell BorderManager 3.8

Introduction

The packet filtering feature of Novell BorderManager (NBM) is used extensively for filtering incoming and outgoing packets at the network layer. Since NBM 3.7, packet filters configurations are stored in eDirectory. In most customer scenarios, the server on which NBM is installed is part of a multi-server tree and is distributed across multiple locations. Packet filters are stored and can be used only on the server on which NBM has been installed. This requires that the customer configures packet filtering on every machine. In such environments the customer can leverage the Novell LDAP utilities (available with eDirectory) for adding/modifying and deleting packet filters collectively, without having to go through filtcfg or iManager, and individually add the filters.

How Packet Filtering Works

Packet filtering works at the IP layer in the TCP/IP model and at the Network layer in the OSI model. It works by examining each packet (basically packet header information) and comparing the packet with a set of criteria (rules) before forwarding that packet. Depending on the packet and the criteria, the firewall can forward the packet, drop it, or send a notification to the originator. This offers a degree of security lower in the network. That is, packets cannot travel beyond this layer without being subject to examination by the filters.

The advantages of packet filters are:

  • No customization or major configuration is required on the client side, because most filtering occurs at the network level rather than the application level.
  • Network performances are known to be better. There is a direct connection between clients and remote hosts.

BorderManager and Packet Filtering

Packet filtering can be configured using the 'filtcfg' utility, run from the NetWare Console or through iManager (browser-based). Each filter has a packet type that contains details about protocols and ports; whether the filter is stateful; and the source and destination information). The benefits are:

  • NBM packet filtering systems guard against security attacks such as address spoofing, in which an unauthorized host sends false addresses to gain network access.
  • Packet filtering prevents unauthorized network access without interfering with authorized access.
  • Strategically placed packet filters can protect your entire network from a wide variety of denial-of-service attacks.

The following link contains detailed information regarding the overview, planning and configuration of packet filtering for NBM:

http://www.novell.com/documentation/nbm38/overview/data/ae70pg6.html#ae70pg6

Difference Between Hardware and Software-based Packet Filtering

It is important to note the differences between hardware- and software-based firewalls. A large number of firewall installations are hardware- based, especially when using packet filters. These are configured mainly on routers, as they reside on the edges of networks (intranet or internet). The firewall capability is included as part of the operating system on the routers.

The firewall information helps the customer understand how packet filtering in NBM is different from those available on hardware devices. The concept of packet filtering remains the same on both hardware- and software- based firewalls, and the function is the same -- blocking unwanted packets and allowing ones defined by a set of rules.

All firewalls run firewall software, and they all run it on some sort of hardware. A "hardware firewall" is an integrated appliance that comes with the software pre-installed, usually on a proprietary operating system. A "software firewall" can be installed on general-purpose network operating systems.

Hardware firewalls can be further divided into those that are basically dedicated PCs with hard disks and those that are solid state devices built on ASIC (Application Specific Integrated Circuit) architecture. ASIC firewalls are generally faster performers and don't have the hard disk (a mechanical device) as a potential point of failure.

Hardware firewalls are often marketed as "turnkey" because you don't have to install the software or worry about hardware configuration or conflicts. Those that run proprietary operating systems claim greater security because the OS is already "hardened" (however, many of the proprietary systems have been exploited nonetheless). A disadvantage of hardware firewalls is that the user is locked into the vendor's specs. For instance, a firewall appliance will have a certain number of network interfaces, and the user is stuck with that number.

With a software firewall, the user can add NICs to the machine on which it's running, to increase the number of available interfaces. Also, the user can easily upgrade the standard PC with the software firewall, easily adding standard RAM or even multiple processors for better performance.

Novell LDAP Utilities

The LDAP utilities can be used to delete entries, modify entries, add entries, extend the schema, modify relative distinguished names, move entries to new containers, create search indexes, or perform searches.

eDirectory stores these tools in /usr/ldaptools/bin to help manage the LDAP directory server. If the user wants to use the commands directly, then above path needs to be exported and should be available in the variable $PATH. Otherwise the user need to mention full path each time the utilities are used. You can leverage eDirectory. Since the filters are stored there, they can be added to the eDirectory directly along with the exceptions through ldif files.

For detailed syntax and other information on LDAP utilities please refer to this link: http://www.novell.com/documentation/edir873/index.html?page=/documentation/edir873/edir873/data/a6qjdjx.html#a6qjdjx

Another Solution: PERL Scripts

The alternative solution to packet filtering has been provided through PERL scripts. These enable the user to do a set of actions prior to adding the filters to the NBM server and then add the filters using LDAP commands. With these scripts, users can do the following things:

  • Define filters as needed.
  • Create those filters in LDIF format.
  • Add filters to any NBM server, using the LDIF files.
  • Add, delete and modify filters, using Novell LDAP utilities.
  • Define packet filters as well as use whatever is available in filtcfg or iManager.

The two executable scripts are:

  1. genpf (generate packet filters) -- generates the LDIF file for filter exceptions and user-defined filters.
  2. addfilter -- populates two configurable files (usrfil and datafil), depending on whether the user wants to add all filters or just some user-defined filters

The four configurable files are:

  1. maindata -- contains details regarding server name, context, NBM context, input files etc.
  2. datafil -- one of the two files that acts as an input to the maindata file. All filters available via filtcfg can be created here.
  3. usrfil -- contains information for generating user-defined filters. It may be an input file to maindata file.
  4. datausr -- an input to addfilter, to add user-defined filters.

The scripts run in the following manner:

  1. The tool uses two configuration files for initial data collection. They are for general configurations and filter configurations. General configuration will contain all the information for default tool settings and default filter settings. The Filter configuration file will contain more information regarding the user defined filters and additional details for the filters.
  2. Once the configuration is complete, a script is executed to generate the LDIF file.
  3. The LDAPMODIFY command is executed in the script. This command is used to add/modify objects in the eDirectory.

Things to do Before Using the Scripts

  • Ensure that the "LDAP clear text passwords" option is enabled on the NBM server, for the LDAP server. The LDAP commands used here provide the admin (or admin equivalent) password in the clear, while adding objects into eDirectory.
  • Enable filters through inetcfg, or else they cannot be used on the NBM server.
  • Back up existing filters using the filtsrv_backup command. This backs up all filters that were configured using filtcfg.

System Requirements

  • Any system on which Perl 5.0 runs. These scripts were tested on a SUSE Linux 9.0 machine.
  • Servers, either standalone or multiple servers in an eDirectory tree, with NBM 3.8 installed on required servers.
  • The version of eDirectory from where the utilities are taken must be 8.7 or above.

Note: To test scripts, we installed the LDAP utilities on the SUSE Linux 9.0 machines. Since the scripts have been written in PERL, there should be no compatibility issues in running them from any other platform, provided LDAP utilities are available on that system.

Usage Scenarios

There are ways to get started:

  1. Add filters and/or filter exceptions to the NBM server.
  2. Create user-defined filters first and then add exceptions.

Both these approaches will generate an LDIF file with the list of filters to be added in the required LDIF format. The user can examine the LDIF files before adding the filters to the server.

Script Scenarios

Here are several scenarios for using scripts.

Scenario 1:

The user defines a set of filters and needs to create an LDIF. For this purpose, a datafil file has been created. This file contains a list of all filters available from filtcfg; it can be considered to be a master file.

The user can choose a list of filters to be added to the NBM server from datafil and provide this as the input file into maindata.

In addition to providing filters that the user can select, datafil also contains the fields for source and destination network addresses. For more information on datafil fields, see the appendix at the end of this document.

On executing the command:

perl genpf.pl maindata

an LDIF file is created that contains all the filters in the required format. These filters are added to the specified NBM server. The ldapmodify command is used recursively (with the --c option) to continue adding all filters despite errors.

Scenario 2

The user defines filters and corresponding exception lists or filter lists.

  1. Clear the files usrfil and datafil, except for the first line in each.
  2. Prepare data files for creating user defined filters.
  3. Provide the data in datausr file.
  4. Execute the "perl addfilter.pl datausr" command. This will populate data in usrfil and datafil.
  5. In datafil and usrfil, provide specific information for interfaces (source and destination) and IP addresses (source and destination).
  6. Check the data you provided for accuracy.
  7. Provide input in maindata (data_file = usrfil and usr_defined = 1).
  8. Execute "perl genpf.pl maindata". Modifications made to both files will be included. This will generate a LDIF file called addldif.ldif (or user-supplied name).
  9. Using ldapmodify option add the contents to eDirectory.

Scenario 3

The user wants to delete the filters created using this tool. The script that creates addldif.ldif also creates a delldif.ldif file. Use the ldapmodify command to delete the filters created using this file. Note: Sample LDIF and data files are provided.

Advantages of Using the Scripts

  • A sample file can be created and kept for use for a set of filters, without having to create them each time they need to be added to different servers.
  • Filters can be added onto any number of servers in an eDirectory tree from a single place.
  • A large number of filters can be readily added at any given time using the master file (datafil).
  • The tool can be used to create a setup with a large number of filters, before actually deploying packet filters in a real-time environment. Scalability and performance of the system can be measured easily.
  • The scripts can be easily modified to suit any user requirements.

Limitations/Known Issues of the Scripts

  • Filters that are added via the scripts can be deleted only with the LDAP utilities.
  • Certain values have been hard-coded, such as name of the input file (datafil).
  • When the user creates an LDIF file, and adds it for the first time to create filters, the file is not backed up. The next time the scripts are run, this file is overwritten. The user needs to back up the LDIF files meant for adding and deleting the filter objects.

Additional References

For more FAQs on packet filtering, see the following TID: http://support.novell.com/cgi-bin/search/searchtid.cgi?/10070403.htm

For general configuration and information on packet filtering, see: http://www.novell.com/documentation/nbm38/index.html?page=/documentation/nbm38/inst_admin/data/anecyf1.html#anecyf1

For useful information for LDAP utilities, see: http://www.novell.com/documentation/ndsedir86/index.html?page=/documentation/ndsedir86/taoenu/data/a6i0f1p.html

Troubleshooting Information

Problem: The LDAP modify command gives the following error message: " "

Possible cause: The data provided for creating the LDIF file contains one or more errors, or there is an error in LDAP syntax.

Solution: If the data provided for generating ldif is wrong then please recheck the data files (datafil and usrfil) and regenerate the script. Or, you can directly edit the LDIF files for minor syntax errors that cause ldapmodify failures.

If there is still a problem in the LDAP syntax, go through the links provided in this document, correct the LDIF file or change the script in genpf.pl, and regenerate the LDIF.

Problem: The added filters are not visible in filtcfg or through iManager, immediately after running the scripts.

Possible cause: Filters are not reinitialized.

Solution: Wait till the server displays the message "Reinitializing filters ............" or manually reinitialize the system using inetcfg.

Appendix

maindata

Field Name Description
serv_name server name on which the filters need to be added. At least a read/write BM replica must be on this server.
serv_context server context
nbm_cont nbm rule containers name. The assumption is server and its context are same.
pf_prefix_name prefix for the packet filter name
data_file The data file which needs to be considered as the input. This file will always be given as datafil (limitation of the scipts)
add_objects Can take 0 or 1 as input. If 1, the objects are added to server. If 0, the ldif file is created and user can add the objects later using LDAP utilities.
clean_scr (0/1) this is enabled means the tool creates the deletion of objects script for the added objects
add_lfile ldif file name for adding the object to eDirectory This file name can be anything. eg. "abc.ldif"
del_lfile ldif file for deleting objects from eDirectory. This file is created along with add_lfile.
all_filter this parameter is used for adding large number of filters and takes values 0,1, or 2 0- uses the master configuration file (datafil), 1 -- adds all the stateless filters from master configuration file, 2 - adds all the stateful filters from the master configuration file.
usr_defined To create user defined filters
admin_usr admin user name with context
adm_pass password for admin user

datafil

This file provides for inputs related to filters and packet types in a separate file. This file acts as the inputs to the main data file. By default, a datafil data file will be available with the tool which has all the default filters set. The parameters need to be provided with the delimiter as "," for this data file and also when providing IP addresses and subnet masks (example 164,99,160,109,255,255,254,0).

The list of input parameters for this file is:

Field Name Description
Enable To add the filter or not. Takes values 0 and 1: 0 - Will not add entries in ldif. 1 -Will create LDIF entries which can be added to eDirectory.
Allow/Deny To add the filter in the filter list or exception list: Allow -1 -- equivalent to "permit packets in filter list" in filtcfg. Deny -- 0- equivalent to "deny packets in filter list" in filtcfg
Name name of the filter
Protocol For the protocol which the filters or exception need to be provided.
source_port source port
dest_port destination port
comment comment for the filter
s_Interfacetype source interface type. Takes values of 0 and 1: 0 -- interface; 1- interface group
s_Interface/grpname source interface name or group name (if it is for all interface specify <Any> in datafil and by default it has been considered to be <Any>)
d_Interfacetype destination interface type (0 -- interface 1- interface group)
d_Interface/grpname destination interface name or group name( if it is for all interface specify <Any> in datafil and by default it has been considered to be <Any>)
scraddtype source address type ( Any -- 0, host -- 1, network -2)
IP_address if address type if 1 or 2 then specify the IP address information here
Subnet if address type if 1 or 2 then specify the subnet information here
Destaddtype destination address type (Any -- 0, host -- 1, network -2, multicast -- 3)
IP_Address if address type if 1 or 2 then specify the IP address information here; Subnet - if address type if 1 or 2 then specify the subnet information here
Subnet if address type if 1 or 2 then specify the subnet information here

usrfil

This file is automatically populated after running the command "perl addfilter.pl datausr".

Field Name Description
Enable To add the filter or not.
Name name of the filter
Protocol protocol
src_port source port
dest_port destination port
state To specify to add a stateless user defined filter or stateful user defined filter. ( 0 -- stateless and 1 -stateful)
comment comment for the filter

datausr

This is the file that is to be populated when user defined filters need to be added. This file is used as an input to the command "perl addfilter.pl datausr" that will populate usrfil and datafil.

Field Name Description
Count Number of entries to add. Adds entries from dest_port to dest_port + count number of lines in datafil & usrfil
state To specify to add a stateless user defined filter or stateful user defined filter. ( 0 -- stateless and 1 -stateful)
pf_prefix Prefix for the filter name
protocol Protocol type
dest_port Destination port number to start with
Allow/deny Whether to add filters or exception filter. ( allow -- 1- it adds an exception to allow that port, deny-0- it will add in the filters list)


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell