Network Security Firewall User Manual DFL-210/ 800/1600/ 2500 DFL-260/ 860/1660/ 2560(G) Ver. 1.10 Security Security Network Security Solution http://www.dlink.
User Manual DFL-210/260/800/860/1600/1660/2500/2560/2560G NetDefendOS Version 2.26 D-Link Corporation No. 289, Sinhu 3rd Rd, Neihu District, Taipei City 114, Taiwan R.O.C. http://www.DLink.
User Manual DFL-210/260/800/860/1600/1660/2500/2560/2560G NetDefendOS Version 2.26 Published 2009-09-08 Copyright Notice This publication, including all photographs, illustrations and software, is protected under international copyright laws, with all rights reserved. Neither this manual, nor any of the material contained herein, may be reproduced without the written consent of D-Link. Disclaimer The information in this document is subject to change without notice.
Table of Contents Preface ...............................................................................................................12 1. NetDefendOS Overview ....................................................................................14 1.1. Features ................................................................................................14 1.2. NetDefendOS Architecture ......................................................................17 1.2.1. State-based Architecture .............
User Manual 3.3. Interfaces ..............................................................................................84 3.3.1. Overview ...................................................................................84 3.3.2. Ethernet Interfaces .......................................................................85 3.3.3. VLAN .......................................................................................90 3.3.4. PPPoE ....................................................................
User Manual 5.2. DHCP Servers ..................................................................................... 190 5.3. Static DHCP Assignment ....................................................................... 193 5.3.1. DHCP Advanced Settings ............................................................ 193 5.4. DHCP Relaying ................................................................................... 195 5.4.1. DHCP Relay Advanced Settings .................................................
User Manual 7.3.6. Multiple SAT Rule Matches ......................................................... 307 7.3.7. SAT and FwdFast Rules .............................................................. 308 8. User Authentication ........................................................................................ 311 8.1. Overview ............................................................................................ 311 8.2. Authentication Setup .......................................................
User Manual 10.1.11. A Summary of Traffic Shaping ................................................. 402 10.1.12. More Pipe Examples ............................................................... 402 10.2. IDP Traffic Shaping ............................................................................ 407 10.2.1. Overview ................................................................................ 407 10.2.2. Setup .....................................................................................
List of Figures 1.1. Packet Flow Schematic Part I ...........................................................................20 1.2. Packet Flow Schematic Part II ..........................................................................21 1.3. Packet Flow Schematic Part III .........................................................................22 1.4. Expanded Apply Rules Logic ............................................................................23 3.1. VLAN Connections ...........................
List of Examples 1. Example Notation .............................................................................................12 2.1. Enabling remote management via HTTPS ...........................................................30 2.2. Enabling SSH Remote Access ..........................................................................35 2.3. Listing Configuration Objects ...........................................................................46 2.4. Displaying a Configuration Object ..............
User Manual 4.13. if2 Configuration - Group Translation ............................................................. 170 4.14. Setting up Transparent Mode for Scenario 1 .................................................... 180 4.15. Setting up Transparent Mode for Scenario 2 .................................................... 182 5.1. Setting up a DHCP server .............................................................................. 191 5.2. Checking DHCP Server Status ...............................
Preface Intended Audience The target audience for this reference guide is Administrators who are responsible for configuring and managing NetDefend Firewalls which are running the NetDefendOS operating system. This guide assumes that the reader has some basic knowledge of networks and network security. Text Structure and Conventions The text is broken down into chapters and sub-sections. Numbered sub-sections are shown in the table of contents at the beginning.
Preface items in the tree-view list at the left of the interface or in the menu bar or in a context menu need to be opened followed by information about the data items that need to be entered: 1. Go to Item X > Item Y > Item Z 2. Now enter: • DataItem1: datavalue1 • DataItem2: datavalue2 Highlighted Content Special sections of text which the reader should pay special attention to are indicated by icons on the left hand side of the page followed by a short paragraph in italicized text.
Chapter 1. NetDefendOS Overview This chapter outlines the key features of NetDefendOS. • Features, page 14 • NetDefendOS Architecture, page 17 • NetDefendOS State Engine Packet Flow, page 20 1.1. Features D-Link NetDefendOS is the base software engine that drives and controls the range of NetDefend Firewall hardware products.
1.1. Features Chapter 1. NetDefendOS Overview VPN NetDefendOS supports a range of Virtual Private Network (VPN) solutions. NetDefendOS supports IPsec, L2TP and PPTP based VPNs concurrently, can act as either server or client for all of the VPN types, and can provide individual security policies for each VPN tunnel. The details for this can be found in Chapter 9, VPN which includes a summary of setup steps in Section 9.2, “VPN Quick Start”.
1.1. Features Chapter 1. NetDefendOS Overview enables a device running NetDefendOS to distribute network load to multiple hosts. These features are discussed in detail in Chapter 10, Traffic Management. Note Threshold Rules are only available on certain D-Link NetDefend product models. Operations and Maintenance Adminstrator management of NetDefendOS is possible through either a Web-based User Interface (the WebUI) or via a Command Line Interface (the CLI).
1.2. NetDefendOS Architecture Chapter 1. NetDefendOS Overview 1.2. NetDefendOS Architecture 1.2.1. State-based Architecture The NetDefendOS architecture is centered around the concept of state-based connections. Traditional IP routers or switches commonly inspect all packets and then perform forwarding decisions based on information found in the packet headers.
1.2.3. Basic Packet Flow Chapter 1. NetDefendOS Overview NetDefendOS Rule Sets Finally, rules which are defined by the administrator in the various rule sets are used for actually implementing NetDefendOS security policies. The most fundamental set of rules are the IP Rules, which are used to define the layer 3 IP filtering policy as well as carrying out address translation and server load balancing.
1.2.3. Basic Packet Flow Chapter 1. NetDefendOS Overview • TCP/UDP ports • ICMP types • Point in time in reference to a predefined schedule If a match cannot be found, the packet is dropped. If a rule is found that matches the new connection, the Action parameter of the rule decides what NetDefendOS should do with the connection. If the action is Drop, the packet is dropped and the event is logged according to the log settings for the rule.
1.3. NetDefendOS State Engine Packet Flow Chapter 1. NetDefendOS Overview 1.3. NetDefendOS State Engine Packet Flow The diagrams in this section provide a summary of the flow of packets through the NetDefendOS state-engine. There are three diagrams, each flowing into the next. Figure 1.1. Packet Flow Schematic Part I The packet flow is continued on the following page.
1.3. NetDefendOS State Engine Packet Flow Chapter 1. NetDefendOS Overview Figure 1.2. Packet Flow Schematic Part II The packet flow is continued on the following page.
1.3. NetDefendOS State Engine Packet Flow Chapter 1. NetDefendOS Overview Figure 1.3.
1.3. NetDefendOS State Engine Packet Flow Chapter 1. NetDefendOS Overview Apply Rules The figure below presents the detailed logic of the Apply Rules function in Figure 1.2, “Packet Flow Schematic Part II” above. Figure 1.4.
1.3. NetDefendOS State Engine Packet Flow Chapter 1.
Chapter 2. Management and Maintenance This chapter describes the management, operations and maintenance related aspects of NetDefendOS. • Managing NetDefendOS, page 25 • Events and Logging, page 51 • RADIUS Accounting, page 56 • Hardware Monitoring, page 61 • SNMP Monitoring, page 63 • The pcapdump Command, page 66 • Maintenance, page 69 2.1. Managing NetDefendOS 2.1.1. Overview NetDefendOS is designed to give both high performance and high reliability.
2.1.2. The Default Administrator Account Chapter 2. Management and Maintenance This feature is fully described in Section 2.1.6, “Secure Copy”. Console Boot Menu Before NetDefendOS starts running, a console connected directly to the NetDefend Firewall's RS232 port can be used to do basic configuration through the boot menu. This menu can be entered by pressing any console key between power-up and NetDefendOS starting. It is the D-Link firmware loader that is being accessed with the boot menu.
2.1.3. The Web Interface Chapter 2. Management and Maintenance NetDefendOS provides an intuitive Web Interface (WebUI) for management of the system via an Ethernet interface using a standard web browser. This allows the administrator to perform remote management from anywhere on a private network or the public Internet using a standard computer without having to install client software.
2.1.3. The Web Interface Chapter 2. Management and Maintenance password is admin and admin. If the user credentials are correct, you will be transferred to the main Web Interface page. First Time Web Interface Logon and the Setup Wizard When logging on for the first time, the default username is admin and the password is admin. After successful login, the WebUI user interface will be presented in the browser window.
2.1.3. The Web Interface Chapter 2. Management and Maintenance For information about the default user name and password, see Section 2.1.2, “The Default Administrator Account”. Note: Remote management access Access to the Web Interface is regulated by the configured remote management policy. By default, the system will only allow web access from the internal network.
2.1.4. The CLI Chapter 2. Management and Maintenance Controlling Access to the Web Interface By default, the Web Interface is accessible only from the internal network. If you need to enable access from other parts of the network, you can do so by modifying the remote management policy. Example 2.1. Enabling remote management via HTTPS CLI gw-world:/> add RemoteManagement RemoteMgmtHTTP https Network=all-nets Interface=any LocalUserDatabase=AdminUsers HTTPS=Yes Web Interface 1.
2.1.4. The CLI Chapter 2. Management and Maintenance is described below), or remotely via an Ethernet interface using the Secure Shell (SSH) protocol from an SSH client. The CLI provides a comprehensive set of commands that allow the display and modification of configuration data as well as allowing runtime data to be displayed and allowing system maintenance tasks to be performed. This section only provides a summary for using the CLI.
2.1.4. The CLI Chapter 2. Management and Maintenance command appears it can be re-executed in it's original form or changed first before execution. Tab Completion Remembering all the commands and their options can be difficult. NetDefendOS provides a feature called tab completion which means that pressing the tab key will cause automatically completion of the current part of the command.
2.1.4. The CLI Chapter 2. Management and Maintenance Not all object types belong in a category. The object type UserAuthRule is a type without a category and will appear in the category list after pressing tab at the beginning of a command. The category is sometimes also referred to as a context. Selecting Object Categories With some categories, it is necessary to first choose a member of that category with the cc (change category) command before individual objects can be manipulated.
2.1.4. The CLI Chapter 2. Management and Maintenance can be done either by referring to it by its index, that is to say its list position, or by alternatively using the name assigned to it. The CLI Reference Guide lists the parameter options available for each NetDefendOS object, including the Name= and Index= options. Using Unique Names For convenience and clarity, it is recommended that a name is assigned to all objects so that it can be used for reference if required.
2.1.4. The CLI 4. Chapter 2. Management and Maintenance Press the enter key on the terminal. The NetDefendOS login prompt should appear on the terminal screen. SSH (Secure Shell) CLI Access The SSH (Secure Shell) protocol can be used to access the CLI over the network from a remote host. SSH is a protocol primarily used for secure communication over insecure networks, providing strong authentication and data integrity. SSH clients are freely available for almost all hardware platforms.
2.1.4. The CLI Chapter 2. Management and Maintenance else as soon as possible after initial startup. User passwords can be any combination of characters and cannot be greater than 256 characters in length. It is recommended to use only printable characters. To change the password to, for example, my-password the following CLI commands are used.
2.1.4. The CLI Chapter 2. Management and Maintenance Explicity Checking Configuration Integrity After changing a configuration on the NetDefend Firewall, and before the activate/commit commands, it is possible to explicitly check for any problems in a configuration using the command: gw-world:/> show -errors This will cause NetDefendOS to scan the configuration about to be activated and list any problems.
2.1.5. CLI Scripts • Chapter 2. Management and Maintenance Web Interface sessions connected by HTTP or HTTPS. The command without any options gives a summary of currently open sessions: gw-world:/> sessionmanager Session Manager status ---------------------Active connections Maximum allowed connections Local idle session timeout NetCon idle session timeout : : : : 3 64 900 600 To see a list of all sessions use the -list option.
2.1.5. CLI Scripts Chapter 2. Management and Maintenance Script Variables A script file can contain any number of script variables which are called: $1, $2, $3, $4......$n The values substituted for these variable names are specified as a list at the end of the script -execute command line. The number n in the variable name indicates the variable value's position in this list. $1 comes first, $2 comes second and so on. Note: The symbol $0 is reserved Notice that the name of the first variable is $1.
2.1.5. CLI Scripts Chapter 2. Management and Maintenance To move the example my_script.sgs to non-volatile memory the command would be: gw-world:/> script -store -name=my_script.
2.1.6. Secure Copy Chapter 2. Management and Maintenance then uploaded and executed on the other NetDefend Firewalls. The end result is that all units will have the same IP4Address objects in their address book. The name of the file created using the -create option cannot be greater than 16 characters in length (including the extension) and the filetype should be .sgs.
2.1.6. Secure Copy Chapter 2. Management and Maintenance Download is done with the command: > scp The source or destination NetDefend Firewall is of the form: @:. For example: admin@10.62.11.10:config.bak. The must be a defined NetDefendOS user in the administrator user group.
2.1.7. The Console Boot Menu Chapter 2. Management and Maintenance Scripts”. • sshclientkey/ - The SSH client key object type. Examples of Uploading and Downloading In some cases, a file is located in the NetDefendOS root. The license file (license.lic) falls into this category, as well as backup files for configurations (config.bak) and the complete system (full.bak). When uploading, these files contain a unique header which identifies what they are.
2.1.7. The Console Boot Menu Chapter 2. Management and Maintenance If any console key is pressed during these 3 seconds then NetDefendOS startup pauses and the console boot menu is displayed. Initial Boot Menu Options without a Password Set When NetDefendOS is started for the first time with no console password set for console access then the full set of boot menu options are displayed as shown below: The options available in the boot menu are: 1.
2.1.8. Management Advanced Settings Chapter 2. Management and Maintenance The 1. Start firewall option re-continues the interrupted NetDefendOS startup process. If the 2. Login option is chosen, the console password must be entered and the full boot menu described above is entered. Removing the Console Password Once the console password is set it can be removed by selecting the Set console password option in the boot menu and entering nothing as the password and just pressing the Enter key to the prompt.
2.1.9. Working with Configurations Chapter 2. Management and Maintenance Default: 443 HTTPS Certificate Specifies which certificate to use for HTTPS traffic. Only RSA certificates are supported. Default: HTTPS 2.1.9. Working with Configurations Configuration Objects The system configuration is built up by Configuration Objects, where each object represents a configurable item of any kind.
2.1.9. Working with Configurations Chapter 2. Management and Maintenance can be added to the list. • Header - The header row displays the titles of the columns in the list. The tiny arrow images next to each title can be used for sorting the list according to that column. • Rows - Each row in the list corresponds to one configuration item. Most commonly, each row starts with the name of the object (if the item has a name), followed by values for the columns in the list.
2.1.9. Working with Configurations Chapter 2. Management and Maintenance Show the object again to verify the new property value: gw-world:/> show Service ServiceTCPUDP telnet Property ----------------Name: DestinationPorts: Type: SourcePorts: SYNRelay: PassICMPReturn: ALG: MaxSessions: Comments: Value ------telnet 23 TCP 0-65535 No No (none) 1000 Modified Comment Web Interface 1. Go to Objects > Services 2. Click on the telnet hyperlink in the list 3.
2.1.9. Working with Configurations Chapter 2. Management and Maintenance 6. Click OK 7. Verify that the new IP4 address object has been added to the list Example 2.7. Deleting a Configuration Object This example shows how to delete the newly added IP4Address object. CLI gw-world:/> delete Address IP4Address myhost Web Interface 1. Go to Objects > Address Book 2. Right-click on the row containing the myhost object 3.
2.1.9. Working with Configurations * ServiceTCPUDP Chapter 2. Management and Maintenance telnet A "+" character in front of the row indicates that the object has been added. A "*" character indicates that the object has been modified. A "-" character indicates that the object has been marked for deletion. Web Interface 1.
2.2. Events and Logging Chapter 2. Management and Maintenance 2.2. Events and Logging 2.2.1. Overview The ability to log and analyze system activities is an essential feature of NetDefendOS. Logging enables not only monitoring of system status and health, but also allows auditing of network usage and assists in trouble-shooting. Log Message Generation NetDefendOS defines a large number of different log event messages, which are generated as a result of corresponding system events.
2.2.3. Log Message Distribution Chapter 2. Management and Maintenance By default all messages of level Info and above are sent. The Debug category of designed for troubleshooting only and should only be turned on if required to try and solve a problem. Messages of all severity levels are found listed in the NetDefendOS Log Reference Guide. 2.2.3.
2.2.3. Log Message Distribution Chapter 2. Management and Maintenance In order to facilitate automated processing of all messages, NetDefendOS writes all log data to a single line of text. All data following the initial text is presented in the format name=value. This enables automatic filters to easily find the values they are looking for without assuming that a specific piece of data is in a specific location in the log entry.
2.2.4. Advanced Log Settings Chapter 2. Management and Maintenance by D-Link and defines the SNMP objects and data types that are used to describe an SNMP Trap received from NetDefendOS. Note There is a different MIB file for each model of NetDefend Firewall. Make sure that the correct file is used. For each NetDefend Firewall model there is one generic trap object called DLNNNosGenericTrap, that is used for all traps (where NNN indicates the model number).
2.2.4. Advanced Log Settings Chapter 2. Management and Maintenance Send Limit This setting limits how many log packets NetDefendOS may send out per second. This value should never be set too low, as this may result in important events not being logged, nor should it be set too high. A situation where setting too high a value may cause damage is when NetDefendOS sends a log message to a server whose log receiver is not active.
2.3. RADIUS Accounting Chapter 2. Management and Maintenance 2.3. RADIUS Accounting 2.3.1. Overview Within a network environment containing large numbers of users, it is advantageous to have one or a cluster of central servers that maintain user account information and are responsible for authentication and authorization tasks. The central database residing on the dedicated server(s) contains all user credentials as well as details of connections, significantly reducing administration complexity.
2.3.2. RADIUS Accounting Messages Chapter 2. Management and Maintenance authentication server. • How Authenticated - How the user was authenticated. This is set to either RADIUS if the user was authenticated via RADIUS, or LOCAL if the user was authenticated via a local user database. • Delay Time - The time delay (in seconds) since the AccountingRequest packet was sent and the authentication acknowledgement was received.
2.3.3. Interim Accounting Messages Chapter 2. Management and Maintenance Tip: The meaning of an asterisk in the list The asterisk "*" symbol in the above list indicates that the sending of the parameter is user configurable. 2.3.3. Interim Accounting Messages In addition to START and STOP messages NetDefendOS can optionally periodically send Interim Accounting Messages to update the accounting server with the current status of an authenticated user.
2.3.7. Handling Unresponsive Servers Chapter 2. Management and Maintenance Firewalls. This means that accounting information is automatically updated on both cluster members whenever a connection is closed. Two special accounting events are also used by the active unit to keep the passive unit synchronized: • An AccountingStart event is sent to the inactive member in an HA setup whenever a response has been received from the accounting server.
2.3.10. RADIUS Advanced Settings Chapter 2. Management and Maintenance continue to be logged in. Disabling the setting will mean that the user will be logged out if the RADIUS accounting server cannot be reached even though the user has been previously authenticated. Default: Enabled Logout at shutdown If there is an orderly shutdown of the NetDefend Firewall by the administrator, then NetDefendOS will delay the shutdown until it has sent RADIUS accounting STOP messages to any configured RADIUS server.
2.4. Hardware Monitoring Chapter 2. Management and Maintenance 2.4. Hardware Monitoring Availability Certain D-Link hardware models allow the administrator to use the CLI to query the current value of various hardware operational parameters such as the current temperature inside the firewall. This feature is referred to as Hardware Monitoring. The D-Link NetDefend models that currently support hardware monitoring are the DFL-1600, 1660, 2500, 2560 and 2560G.
2.4. Hardware Monitoring Chapter 2. Management and Maintenance The -verbose option displays the current values plus the configured ranges: gw-world:/> hwm -a -v 2 sensors available Poll interval time = 500ms Name [type][number] = low_limit] current_value [high_limit (unit) ----------------------------------------------------------------SYS Temp [TEMP ][ 0] = 44.000] 45.000 [ 0.000 (C) CPU Temp [TEMP ][ 1] = 42.000] 42.500 [ 0.000 (C) Time to probe sensors: 2.
2.5. SNMP Monitoring Chapter 2. Management and Maintenance 2.5. SNMP Monitoring Overview Simple Network Management Protocol (SNMP) is a standardized protocol for management of network devices. An SNMP compliant client can connect to a network device which supports the SNMP protocol to query and control it. NetDefendOS supports SNMP version 1 and version 2. Connection can be made by any SNMP compliant clients to devices running NetDefendOS. however only query operations are permitted for security reasons.
2.5.1. SNMP Advanced Settings Chapter 2. Management and Maintenance SNMP access. Port 161 is usually used for SNMP and NetDefendOS always expects SNMP traffic on that port. Remote Access Encryption It should be noted that SNMP Version 1 or 2c access means that the community string will be sent as plain text over a network. This is clearly insecure if a remote client is communicating over the public Internet.
2.5.1. SNMP Advanced Settings Chapter 2. Management and Maintenance Default: Enabled SNMP Request Limit Maximum number of SNMP requests that will be processed each second by NetDefendOS. Should SNMP requests exceed this rate then the excess requests will be ignored by NetDefendOS. Default: 100 System Contact The contact person for the managed node. Default: N/A System Name The name for the managed node. Default: N/A System Location The physical location of the node.
2.6. The pcapdump Command Chapter 2. Management and Maintenance 2.6. The pcapdump Command A valuable diagnostic tool is the ability to examine the packets that enter and leave the interfaces of a NetDefend Firewall. For this purpose, NetDefendOS provides the CLI command pcapdump which not only allows the examination of packet streams entering and leaving interfaces but also allows the filtering of these streams according to specified criteria.
2.6. The pcapdump Command Chapter 2. Management and Maintenance It is possible to have multiple pcapdump executions being performed at the same time. The following points describe this feature: 1. All capture from all executions goes to the same memory buffer. The command can be launched multiple times with different interfaces specified. In this case the packet flow for the different executions will be grouped together in different sections of the report.
2.6. The pcapdump Command • Chapter 2. Management and Maintenance The filename and extension can only contain the characters A-Z, 0-9, "-" and "_". Combining Filters It is possible to use several of these filter expressions together in order to further refine the packets that are of interest. For example we might want to examine the packets going to a particular destination port at a particular destination IP address.
2.7. Maintenance Chapter 2. Management and Maintenance 2.7. Maintenance 2.7.1. Auto-Update Mechanism A number of the NetDefendOS security features rely on external servers for automatic updates and content filtering. The Intrusion Prevention and Detection system and Anti-Virus modules require access to updated signature databases in order to provide protection against the latest threats.
2.7.3. Restore to Factory Defaults Chapter 2. Management and Maintenance be altered to include the date. For example, full.bak might become full-20081121.bak to show it is a snapshot of the state on November 21st, 2008. To restore a backup file, the administrator should upload the file to the NetDefend Firewall. The name of the file does not need to be changed in any way and can retain the date since NetDefendOS will read a header in the file to determine what it is.
2.7.3. Restore to Factory Defaults Chapter 2. Management and Maintenance Important: Any upgrades will be lost after a factory reset It should be understood that a reset to factory defaults is exactly that. Any NetDefendOS upgrades performed since the unit left the factory will be lost. Reset Procedure for the NetDefend DFL-210, 260, 800 and 860 To reset the NetDefend DFL-210/260/800/860 models, hold down the reset button located at the rear of the unit for 10-15 seconds while powering on the unit.
2.7.3. Restore to Factory Defaults Chapter 2.
Chapter 3. Fundamentals This chapter describes the fundamental logical objects which make up a NetDefendOS configuration. These objects include such items as IP addresses and IP rules. Some exist by default and some must be defined by the administrator. In addition, the chapter explains the different interface types and explains how security policies are constructed the administrator.
3.1.2. IP Addresses Chapter 3. Fundamentals corresponds to a 32 address net (netmask 255.255.255.224) and so on. The numbers 0-32 correspond to the number of binary ones in the netmask. For example: 192.168.0.0/24. IP Range A range of IP addresses is represented on the form a.b.c.d - e.f.g.h. Note that ranges are not limited to netmask boundaries. They may include any span of IP addresses. For example, 192.168.0.10-192.168.0.15 represents six hosts in consecutive order. Example 3.1.
3.1.3. Ethernet Addresses Chapter 3. Fundamentals Web Interface 1. Go to Objects > Address Book > Add > IP address 2. Specify a suitable name for the IP Range, for example wwwservers. 3. Enter 192.168.10.16-192.168.10.21 as the IP Address 4. Click OK Example 3.4. Deleting an Address Object To delete an object named wwwsrv1 in the Address Book, do the following: CLI gw-world:/> delete Address IP4Address wwwsrv1 Web Interface 1. Go to Objects > Address Book 2.
3.1.4. Address Groups Chapter 3. Fundamentals Web Interface 1. Go to Objects > Address Book > Add > Ethernet Address 2. Specify a suitable name for the Ethernet Address object, for example wwwsrv1_mac 3. Enter 08-a3-67-bc-2e-f2 as the MAC Address 4. Click OK 3.1.4. Address Groups Groups Simplify Configuration Address objects can be grouped in order to simplify configuration. Consider a number of public servers that should be accessible from the Internet.
3.1.6. Address Book Folders Chapter 3. Fundamentals Otherwise, the object will be left empty (in other words, the IP address will be 0.0.0.0/0). all-nets The all-nets IP address object is initialized to the IP address 0.0.0.0/0, which represents all possible IP addresses. The all-nets IP object is used extensively in the configuration of NetDefendOS and it is important to understand its significance. 3.1.6.
3.2. Services Chapter 3. Fundamentals 3.2. Services 3.2.1. Overview A Service object is a reference to a specific IP protocol with associated parameters. A Service definition is usually based on one of the major transport protocols such as TCP or UDP, with the associated port number(s). The HTTP service, for instance, is defined as using the TCP protocol with associated port 80. However, service objects are not restricted to just TCP or UDP.
3.2.2. TCP and UDP Based Services Chapter 3. Fundamentals To view a specific service in the system: CLI gw-world:/> show Service ServiceTCPUDP echo The output will look similar to the following listing: Property ----------------Name: DestinationPorts: Type: SourcePorts: PassICMPReturn: ALG: MaxSessions: Comments: Value ---------------echo 7 TCPUDP (TCP/UDP) 0-65535 No (none) 1000 Echo service Web Interface 1. Go to Objects > Services 2. Select the specific service object in the table 3.
3.2.2. TCP and UDP Based Services Chapter 3. Fundamentals Port Ranges Some services use a range of destination ports. As an example, the NetBIOS protocol used by Microsoft Windows uses destination ports 137 to 139. To define a range of ports in a TCP/UDP service object, the format mmm-nnn is used. A port range is inclusive, meaning that a range specified as 137-139 covers ports 137, 138 and 139. Multiple Ports and Port Ranges Multiple ranges or individual ports may also be entered, separated by commas.
3.2.3. ICMP Services Chapter 3. Fundamentals Gateway (ALG) to enable deeper inspection of certain protocols. For more information see Section 6.2, “ALGs”. Max Sessions An important parameter associated with a Service is Max Sessions. This parameter is allocated a default value when the Service is associated with an ALG. The default value varies according to the ALG it is associated with.
3.2.4. Custom IP Protocol Services • • Code 4: Cannot Fragment • Code 5: Source Route Failed Chapter 3. Fundamentals Redirect: the source is told that there is a better route for a particular packet.
3.2.5. Service Groups Chapter 3. Fundamentals 4. Optionally enter Virtual Router Redundancy Protocol in the Comments control 5. Click OK 3.2.5. Service Groups A Service Group is, exactly as the name suggests, a NetDefendOS object that consists of a collection of services. Although the group concept is simple, it can be very useful when constructing security policies. For example, there may be a need for a set of IP rules that are identical to each other except for the service parameter.
3.3. Interfaces Chapter 3. Fundamentals 3.3. Interfaces 3.3.1. Overview An Interface is one of the most important logical building blocks in NetDefendOS. All network traffic that passes through or gets terminated in the system is done so through one or several interfaces. An interface can be seen as a doorway for network traffic to or from the system.
3.3.2. Ethernet Interfaces Chapter 3. Fundamentals found in Section 9.5, “PPTP/L2TP”. • GRE interfaces are used to establish GRE tunnels. More information about this topic can be found in Section 3.3.5, “GRE Tunnels”. Even though the various types of interfaces are very different in the way they are implemented and how they work, NetDefendOS treats all interfaces as logical IP interfaces. This means that all types of interfaces can be used almost interchangeably in the various subsystems and policies.
3.3.2. Ethernet Interfaces Chapter 3. Fundamentals progressively smaller as the transmission rates get faster from normal Ethernet to Fast Ethernet and then Gigabit Ethernet. Each NetDefendOS Ethernet interface corresponds to a physical Ethernet port in the system. The number of ports, their link speed and the way the ports are realized, is dependent on the hardware model. Note: Additional switch ports Some systems use an integrated layer 2 switch for providing additional physical Ethernet ports.
3.3.2. Ethernet Interfaces • Chapter 3. Fundamentals Instead, the ip_lan object in the NetDefendOS Address Book should be assigned the new address since it is this object that is used by many other NetDefendOS objects such as IP rules. The CLI command to do this would be: gw-world:/> set Address IP4Address ip_lan Address=10.1.1.2 This same operation could also be done through the Web Interface. A summary of CLI commands that can be used with Ethernet interfaces can be found in Section 3.3.2.
3.3.2. Ethernet Interfaces Chapter 3. Fundamentals Web Interface 1. Go to Interfaces > Ethernet 2. Select the Ethernet interface of interest 3. Enable the Enable DHCP client option 4. Click OK 3.3.2.1. Useful CLI Commands for Ethernet Interfaces This section summarizes the CLI commands most commonly used for examining and manipulating NetDefendOS Ethernet interfaces. Ethernet interfaces can also be examined through the Web Interface but for some operations the CLI must be used.
3.3.2. Ethernet Interfaces Chapter 3.
3.3.3. VLAN Chapter 3. Fundamentals For a complete list of all CLI options see the CLI Reference Guide. 3.3.3. VLAN Overview Virtual LAN (VLAN) support in NetDefendOS allows the definition of one or more Virtual LAN interfaces which are associated with a particular physical interface. These are then considered to be logical interfaces by NetDefendOS and can be treated like any other interfaces in NetDefendOS rule sets and routing tables. VLANs are useful in several different scenarios.
3.3.3. VLAN Chapter 3. Fundamentals With NetDefendOS VLANs, the physical connections are as follows: • One of more VLANs are configured on a physical NetDefend Firewall interface and this is connected directly to a switch. This link acts as a VLAN trunk. The switch used must support port based VLANs. This means that each port on the switch can be configured with the ID of the VLAN or VLANs that the port is connected to.
3.3.4. PPPoE Chapter 3. Fundamentals The number of VLAN interfaces that can be defined for a NetDefendOS installation is limited by the parameters of the license used. Different hardware models have different licenses and different limits on VLANs. Summary of VLAN Setup It is important to understand that the administrator should treat a VLAN interface just like a physical interface in that they require at least IP rules and routes to be defined in order to function.
3.3.4. PPPoE Chapter 3. Fundamentals 3.3.4. PPPoE 3.3.4.1. Overview Point-to-Point Protocol over Ethernet (PPPoE) is a tunneling protocol used for connecting multiple users on an Ethernet network to the Internet through a common serial interface, such as a single DSL line, wireless device or cable modem. All the users on the Ethernet share a common connection, while access control can be done on a per-user basis.
3.3.4. PPPoE Chapter 3. Fundamentals receives this IP address information from the ISP, it stores it in a network object and uses it as the IP address of the interface. User authentication If user authentication is required by the ISP, the username and password can be setup in NetDefendOS for automatic sending to the PPPoE server. Dial-on-demand If dial-on-demand is enabled, the PPPoE connection will only be up when there is traffic on the PPPoE interface.
3.3.5. GRE Tunnels 3. Chapter 3.
3.3.5. GRE Tunnels Chapter 3. Fundamentals Like other tunnels in NetDefendOS such as an IPsec tunnel, a GRE Tunnel is treated as a logical interface by NetDefendOS, with the same filtering, traffic shaping and configuration capabilities as a standard interface. The GRE options are: • IP Address - This is the IP address of the sending interface. This is optional and can be left blank. If it is left blank then the sending IP address will default to the local host address of 127.0.0.1.
3.3.5. GRE Tunnels Chapter 3. Fundamentals The diagram above shows a typical GRE scenario, where two NetDefend Firewalls A and B must communicate with each other through the intervening internal network 172.16.0.0/16. Any traffic passing between A and B is tunneled through the intervening network using a GRE tunnel and since the network is internal and not public there is no need for encryption. Setup for NetDefend Firewall "A" Assuming that the network 192.168.10.
3.3.6. Interface Groups Chapter 3. Fundamentals • Remote Endpoint: remote_gw • Use Session Key: 1 • Additional Encapulation Checksum: Enabled 3. Define a route in the main routing table which routes all traffic to remote_net_A on the GRE_to_A GRE interface. This is not necessary if the option Add route for remote network is enabled in the Advanced tab, since this will add the route automatically. 4.
3.4. ARP Chapter 3. Fundamentals 3.4. ARP 3.4.1. Overview Address Resolution Protocol (ARP) is a protocol, which maps a network layer protocol address to a data link layer hardware address and it is used to resolve an IP address into its corresponding Ethernet address. ARP operates at the OSI Data Link Layer (Layer 2 - see Appendix D, The OSI Framework) and is encapsulated by Ethernet headers for transmission.
3.4.3. ARP Cache Chapter 3. Fundamentals The default expiration time for dynamic ARP entries is 900 seconds (15 minutes). This can be changed by modifying the advanced setting ARP Expire. The setting ARP Expire Unknown specifies how long NetDefendOS will remember addresses that cannot be reached. This is done to ensure that NetDefendOS does not continuously request such addresses. The default value for this setting is 3 seconds. Example 3.14.
3.4.4. Static and Published ARP Entries Chapter 3. Fundamentals hash size for VLAN interfaces only. The default value is 64. 3.4.4. Static and Published ARP Entries NetDefendOS supports defining static ARP entries (static binding of IP addresses to Ethernet addresses) as well as publishing IP addresses with a specific Ethernet address. Static ARP Entries Static ARP items may help in situations where a device is reporting incorrect Ethernet address in response to ARP requests.
3.4.5. Using ARP Advanced Settings Chapter 3. Fundamentals the corresponding NetDefendOS interface. Another use is publishing multiple addresses on an external interface, enabling NetDefendOS to statically address translate communications to these addresses and send it onwards to internal servers with private IP addresses. There are two publishing modes; Publish and XPublish.
3.4.6. ARP Advanced Settings Summary Chapter 3. Fundamentals Allowing this to take place may allow hijacking of local connections. However, not allowing this may cause problems if, for example, a network adapter is replaced, as NetDefendOS will not accept the new address until the previous ARP cache entry has timed out. The advanced setting ARP Changes can be changed to modify this behavior. The default behavior is that NetDefendOS will allow changes to take place, but all such changes will be logged.
3.4.6. ARP Advanced Settings Summary Chapter 3. Fundamentals Default: DropLog ARP Requests Determines if NetDefendOS will automatically add the data in ARP requests to its ARP table. The ARP specification states that this should be done, but as this procedure can facilitate hijacking of local connections, it is not normally allowed. Even if ARPRequests is set to "Drop", meaning that the packet is discarded without being stored, NetDefendOS will, provided that other rules approve the request, reply to it.
3.4.6. ARP Advanced Settings Summary Chapter 3. Fundamentals broadcast addresses. Such claims are usually never correct. Default: DropLog ARP cache size How many ARP entries there can be in the cache in total. Default: 4096 ARP Hash Size Hashing is used to rapidly look up entries in a table. For maximum efficiency, the hash size should be twice as large as the table it is indexing.
3.5. The IP Rule Set Chapter 3. Fundamentals 3.5. The IP Rule Set 3.5.1. Security Policies Common Policy Characteristics NetDefendOS Security Policies designed by the administrator, regulate the way in which traffic can flow through the NetDefend Firewall. Policies in NetDefendOS are defined by different NetDefendOS rule sets. These rule sets share a common means of specifying filtering criteria which determine the type of traffic to which they will apply.
3.5.1. Security Policies Chapter 3. Fundamentals and are described in Chapter 8, User Authentication. Specifying Any Interface or Network When specifying the filtering criteria in any of the rule sets specified above there are three useful predefined options that can be used: • For a Source or Destination Network, the all-nets option is equivalent to the IP address 0.0.0.0/0 which will mean that any IP address is acceptable.
3.5.2. IP Rule Evaluation Chapter 3. Fundamentals If the IP rule used is an Allow rule then this is bi-directional by default. The ordering of these steps is important. The route lookup occurs first to determine the exiting interface and then NetDefendOS looks for an IP rule that allows the traffic to leave on that interface. If a rule doesn't exist then the traffic is dropped. Figure 3.2.
3.5.3. IP Rule Actions Chapter 3. Fundamentals Stateful Inspection After initial rule evaluation of the opening connection, subsequent packets belonging to that connection will not need to be evaluated individually against the rule set. Instead, a highly efficient algorithm searches the state table for each packet to determine if it belongs to an established connection.
3.5.4. Editing IP rule set Entries Chapter 3. Fundamentals SAT This tells NetDefendOS to perform static address translation. A SAT rule always requires a matching Allow, NAT or FwdFast IP rule further down the rule set (see Section 7.3, “SAT” in Chapter 7, Address Translation for a detailed description). Drop This tells NetDefendOS to immediately discard the packet. This is an "impolite" version of Reject in that no reply is sent back to the sender.
3.5.5. IP Rule Set Folders Chapter 3. Fundamentals name and can then be used to contain all the IP rules that are related together as a group. Using folders is simply a way for the administrator to conveniently divide up IP rule set entries and no special properties are given to entries in different folders. NetDefendOS continues to see all entries as though they were in a single set of IP rules.
3.6. Schedules Chapter 3. Fundamentals 3.6. Schedules In some scenarios, it might be useful to control not only what functionality is enabled, but also when that functionality is being used. For instance, the IT policy of an enterprise might stipulate that web traffic from a certain department is only allowed access outside that department during normal office hours. Another example might be that authentication using a specific VPN connection is only permitted on weekdays before noon.
3.6. Schedules Chapter 3. Fundamentals Return to the top level: gw-world:/main> cc Configuration changes must be saved by then issuing an activate followed by a commit command. Web Interface 1. Go to Objects > Schedules > Add > Schedule 2. Enter the following: • Name: OfficeHours 3. Select 08-17, Monday to Friday in the grid 4. Click OK 1. Go to Rules > IP Rules > Add > IPRule 2. Enter the following: • 3. 4.
3.7. Certificates Chapter 3. Fundamentals 3.7. Certificates 3.7.1. Overview X.509 NetDefendOS supports digital certificates that comply with the ITU-T X.509 standard. This involves the use of an X.509 certificate hierarchy with public-key cryptography to accomplish key distribution and entity authentication. References in this manual to a certificate means a X.509 certificate. A certificate is a digital proof of identity.
3.7.2. Certificates in NetDefendOS Chapter 3. Fundamentals Validity Time A certificate is not valid forever. Each certificate contains the dates between which the certificate is valid. When this validity period expires, the certificate can no longer be used, and a new certificate has to be issued. Important Make sure the NetDefendOS date and time are set correctly when using certificates.
3.7.3. CA Certificate Requests Chapter 3. Fundamentals There are two types of certificates that can be uploaded: self-signed certificates and remote certificates belonging to a remote peer or CA server. Self-signed certificates can be generated by using one of a number of freely available utilities for doing this. Example 3.19. Uploading a Certificate The certificate may either be self-signed or belonging to a remote peer or CA server. Web Interface 1.
3.7.3. CA Certificate Requests • Chapter 3. Fundamentals Take out the relevant parts of the .pem file to form the required .cer and .key files. The detailed steps for the above stages are as follows: 1. Create the gateway certificate on the Windows CA server and export it to a .pfx file on the local NetDefendOS management workstation disk. 2. Now convert the local .pfx file to a .pem file. This can be done with the OpenSSL utility using the console command line: openssl pkcs12 -in gateway.
3.8. Date and Time Chapter 3. Fundamentals 3.8. Date and Time 3.8.1. Overview Correctly setting the date and time is important for NetDefendOS to operate properly. Time scheduled policies, auto-update of the IDP and Anti-Virus databases, and other product features require that the system clock is accurately set. In addition, log messages are tagged with time-stamps in order to indicate when a specific event occurred.
3.8.3. Time Servers Chapter 3. Fundamentals counted as being inside a given time zone will then have the same local time and this will be one of the integer offsets from GMT. The NetDefendOS time zone setting reflects the time zone where the NetDefend Firewall is physically located. Example 3.22. Setting the Time Zone To modify the NetDefendOS time zone to be GMT plus 1 hour, follow the steps outlined below: CLI gw-world:/> set DateTime Timezone=GMTplus1 Web Interface 1.
3.8.3. Time Servers Chapter 3. Fundamentals NetDefendOS is able to adjust the clock automatically based on information received from one or more Time Servers which provide a highly accurate time, usually using atomic clocks. Using Time Servers is highly recommended as it ensures NetDefendOS will have its date and time aligned with other network devices. Time Synchronization Protocols Time Synchronization Protocols are standardized methods for retrieving time information from external Time Servers.
3.8.3. Time Servers Chapter 3. Fundamentals The time server URLs must have the prefix dns: to specify that they should be resolved with a DNS server. NetDefendOS must therefore also have a DNS server defined so this resolution can be performed. Note If the TimeSyncInterval parameter is not specified when using the CLI to set the synchronization interval, the default of 86400 seconds (= 1 day) is used. Example 3.25.
3.8.4. Settings Summary for Date and Time Chapter 3. Fundamentals Example 3.27. Forcing Time Synchronization This example demonstrates how to force time synchronization, overiding the maximum adjustment setting. CLI gw-world:/> time -sync -force Synchronization Intervals The interval between each synchronization attempt can be adjusted if needed. By default, this value is 86,400 seconds (1 day), meaning that the time synchronization process is executed once in a 24 hour period.
3.8.4. Settings Summary for Date and Time Chapter 3. Fundamentals DST Offset Daylight saving time offset in minutes. Default: 0 DST Start Date What month and day DST starts, in the format MM-DD. Default: none DST End Date What month and day DST ends, in the format MM-DD. Default: none Time Sync Server Type Type of server for time synchronization, UDPTime or SNTP (Simple Network Time Protocol). Default: SNTP Primary Time Server DNS hostname or IP Address of Timeserver 1.
3.8.4. Settings Summary for Date and Time Chapter 3. Fundamentals Group interval Interval according to which server responses will be grouped.
3.9. DNS Chapter 3. Fundamentals 3.9. DNS Overview A DNS server can resolve a Fully Qualified Domain Name (FQDN) into the corresponding numeric IP address. FQDNs are unambiguous textual domain names which specify a node's unique position in the Internet's DNS tree hierarchy. FQDN resolution allows the actual physical IP address to change while the FQDN can stay the same. A Uniform Resource Locator (URL) differs from an FQDN in that the URL includes the access protocol along with the FQDN.
3.9. DNS Chapter 3. Fundamentals Dynamic DNS A DNS feature offered by NetDefendOS is the ability to explicitly inform DNS servers when the external IP address of the NetDefend Firewall has changed. This is sometimes referred to as Dynamic DNS and is useful where the NetDefend Firewall has an external IP address that can change. Dynamic DNS can also be useful in VPN scenarios where both ends of the tunnel have dynamic IP addresses.
3.9. DNS Chapter 3.
Chapter 4. Routing This chapter describes how to configure IP routing in NetDefendOS. • Overview, page 128 • Static Routing, page 129 • Policy-based Routing, page 143 • Route Load Balancing, page 148 • Dynamic Routing, page 154 • Multicast Routing, page 162 • Transparent Mode, page 174 4.1. Overview IP routing is one of the most fundamental functions of NetDefendOS.
4.2. Static Routing Chapter 4. Routing 4.2. Static Routing The most basic form of routing is known as Static Routing. The word "static" refers to the fact that entries in the routing table are manually added and are therefore permanent (or static) by nature. Due to this manual approach, static routing is most appropriate to use in smaller network deployments where addresses are fairly fixed and where the amount of connected networks are limited to a few.
4.2.1. The Principles of Routing Chapter 4. Routing This parameter usually doesn't need to be specified. If it is specified, NetDefendOS responds to ARP queries sent to this address. A special section below explains this parameter in more depth. Local IP Address and Gateway are mutually exclusive and either one or the other should be specified. • Metric This is a metric value assigned to the route and is used as a weight when performing comparisons between alternate routes.
4.2.1. The Principles of Routing Chapter 4. Routing The above routing table provides the following information: • Route #1 All packets going to hosts on the 192.168.0.0/24 network should be sent out on the lan interface. As no gateway is specified for the route entry, the host is assumed to be located on the network segment directly reachable from the lan interface. • Route #2 All packets going to hosts on the 10.4.0.0/16 network are to be sent out on the dmz interface.
4.2.1. The Principles of Routing • Chapter 4. Routing Local IP Address: An address within the second network's IP range. When the Default Gateway of the second network's clients is now set to the same value as the Local IP Address of the above route, the clients will be able to communicate successfully with the interface. The IP address chosen in the second network isn't significant, as long as it is the same value for the Default Gateway of the clients and the Local IP Address.
4.2.2. Static Routing Chapter 4. Routing network of a connection but also for the source network. The route that defines the source network simply says that the source network is found on a particular interface. When a new connection is opened, NetDefendOS performs a check known as a reverse route lookup which looks for this route. The source network route is not used to perform routing but instead as a check that the source network should be found on the interface where it arrived.
4.2.2. Static Routing Chapter 4. Routing 0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.10 20 10.0.0.0 255.0.0.0 10.4.2.143 10.4.2.143 1 10.4.2.143 255.255.255.255 127.0.0.1 127.0.0.1 50 10.255.255.255 255.255.255.255 10.4.2.143 10.4.2.143 50 85.11.194.33 255.255.255.255 192.168.0.1 192.168.0.10 20 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.0.0 255.255.255.0 192.168.0.10 192.168.0.10 20 192.168.0.10 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.0.255 255.255.255.255 192.168.0.10 192.168.0.10 20 224.0.0.
4.2.2. Static Routing Chapter 4. Routing gw-world:/main> show Route # 1 2 3 Interface --------wan lan wan Network -------all-nets lannet wannet Gateway ------------213.124.165.1 (none) (none) Local IP -------(none) (none) (none) To see the active routing table enter: gw-world:/> routes Flags Network ----- -----------------192.168.0.0/24 213.124.165.0/24 0.0.0.0/0 Iface Gateway Local IP -------------- --------------- --------------lan wan wan 213.124.165.
4.2.2. Static Routing Chapter 4. Routing However, the option also exists for any physical interface to indicate that it should be used for connection to the Internet. In the Web Interface this is an advanced setting in the Ethernet interface properties called: Automatically add a default route for this interface using the given default gateway. When this option is selected, the appropriate all-nets route is automatically added to the main routing table for the interface.
4.2.3. Route Failover Chapter 4. Routing Tip: Understanding output from the routes command For detailed information about the output of the CLI routes command. Please see the CLI Reference Guide. 4.2.3. Route Failover Overview NetDefend Firewalls are often deployed in mission-critical locations where availability and connectivity is crucial. A corporation relying heavily on access to the Internet, for instance, could have their operations severely disrupted if an Internet connection fails.
4.2.3. Route Failover Chapter 4. Routing instantly noticed, this method provides the fastest response to failure. Gateway Monitoring If a specific gateway has been specified as the next hop for a route, accessibility to that gateway can be monitored by sending periodic ARP requests. As long as the gateway responds to these requests, the route is considered to be functioning correctly. Setting the Route Metric When specifying routes, the administrator should manually set a route's Metric.
4.2.4. Host Monitoring for Route Failover Chapter 4. Routing Route Interface Grouping When using route monitoring, it is important to check if a failover to another route will cause the routing interface to be changed. If this could happen, it is necessary to take some precautionary steps to ensure that policies and existing connections will be maintained.
4.2.4. Host Monitoring for Route Failover Chapter 4. Routing The advantages of Host Monitoring are twofold: • In a complex network topology it is more reliable to check accessibility to external hosts. Just monitoring a link to a local switch may not indicate a problem in another part of the internal network. • Host monitoring can be used to help in setting the acceptable Quality of Service level of Internet response times.
4.2.5. Proxy ARP • Chapter 4. Routing Sample The number of polling attempts used as a sample size for calculating the Percentage Loss and the Average Latency. This value cannot be less than 1. • Maximum Failed Poll Attempts The maximum permissible number of polling attempts that fail. If this number is exceeded then the host is considered unreachable. • Max Average Latency The maximum number of milliseconds allowable between a poll request and the response.
4.2.5. Proxy ARP Chapter 4. Routing Overview As discussed previously in Section 3.4, “ARP”, the ARP protocol facilitates a mapping between an IP address and the MAC address of a node on an Ethernet network. However, situations may exist where a network running Ethernet is separated into two parts with a routing device such as an installed NetDefend Firewall, in between.
4.3. Policy-based Routing Chapter 4. Routing 4.3. Policy-based Routing 4.3.1. Overview Policy-based Routing (PBR) is an extension to the standard routing described previously. It offers administrators significant flexibility in implementing routing decision policies by being able to define rules so alternative routing tables are used. Normal routing forwards packets according to destination IP address information derived from static routes or from a dynamic routing protocol.
4.3.4. PBR Table Selection Chapter 4. Routing When looking up Policy-based Rules, it is the first matching rule found that is triggered. 4.3.4. PBR Table Selection When a packet corresponding to a new connection first arrives, the processing steps are as follows to determine which routing table is chosen: 1. The PBR Rules must first be looked up but to do this the packet's destination interface must be determined and this is always done by a lookup in the main routing table.
4.3.5. The Ordering parameter Chapter 4. Routing Important: Ensure all-nets appears in the main table A common mistake with policy-based routing is the absence of the default route with a destination interface of all-nets in the default main routing table. If there is no route that is an exact match then the absence of a default all-nets route will mean that the connection will be dropped. Example 4.3.
4.3.5. The Ordering parameter Chapter 4. Routing This example illustrates a multiple ISP scenario which is a common use of Policy-based Routing. The following is assumed: • Each ISP will give you an IP network from its network range. We will assume a 2-ISP scenario, with the network 10.10.10.0/24 belonging to ISP A and 20.20.20.0/24 belonging to ISP B. The ISP gateways are 10.10.10.1 and 20.20.20.1 respectively. • All addresses in this scenario are public addresses for the sake of simplicity.
4.3.5. The Ordering parameter Chapter 4. Routing Note Rules in the above example are added for both inbound and outbound connections.
4.4. Route Load Balancing Chapter 4. Routing 4.4. Route Load Balancing Overview NetDefendOS provides the option to perform Route Load Balancing (RLB). This is the ability to distribute traffic over multiple alternate routes based on a number of predefined distribution algorithms. The purpose of this feature is to provide the following: • Balancing of traffic between interfaces in a policy driven fashion.
4.4. Route Load Balancing 3. Chapter 4. Routing If more than one matching route is found then RLB is used to choose which one to use. This is done according to which algorithm is selected in the table's RLB Instance object: • Round Robin Successive routes are chosen from the matching routes in a "round robin" fashion provided that the metric of the routes is the same. This results in route lookups being spread evenly across matching routes with same metric.
4.4. Route Load Balancing Chapter 4. Routing Spillover Limits are set separately for ingoing and outgoing traffic with only one of these typically being specified. If both are specified then only one of them needs to be exceeded continuously for Hold Timer seconds for the next matching route to be chosen. The units of the limits, such as Mbps, can be selected to simplify specification of the values.
4.4. Route Load Balancing Chapter 4. Routing Several alternative routes can be set up, each with their own interface limits and each with a different metric. The route with the lowest metric is chosen first and when that route's interface limits are exceeded, the route with the next highest metric is then chosen. When that new route's interface limits are also exceeded then the route with the next highest metric is taken and so on.
4.4. Route Load Balancing Chapter 4. Routing to the firewall interfaces WAN1 and WAN2. RLB will be used to balance the connections between the two ISPs. Figure 4.5. A Route Load Balancing Scenario We first need to define two routes to these two ISPs in the main routing table as shown below: Route No.
4.4. Route Load Balancing Chapter 4. Routing achieve stickiness so the server always sees the same source IP address (WAN1 or WAN2) from a single client. CLI gw-world:/> add RouteBalancingInstance main Algorithm=Destination Web Interface 1. Go to Routing > Route Load Balancing > Instances > Add > Route Balancing Instance 2. The route balancing instance dialog will appear.
4.5. Dynamic Routing Chapter 4. Routing 4.5. Dynamic Routing 4.5.1. Dynamic Routing overview Dynamic routing is different to static routing in that the NetDefend Firewall will adapt to changes of network topology or traffic load automatically. NetDefendOS first learns of all the directly connected networks and gets further route information from other routers.
4.5.2. OSPF Chapter 4. Routing OSPF is not available on the DFL-210 and 260. Comparing Dynamic Routing Algorithms Due to the fact that the global link state information is maintained everywhere in a network, LS algorithms offer a high degree of configuration control and scalability. Changes result in broadcasts of just the updated information to other routers which means faster convergence and less possibility of routing loops.
4.5.2. OSPF Chapter 4. Routing Link-state Routing OSPF is a form of link-state routing protocol that defines the sending of link-state advertisements (LSAs) to all other routers within the same area. Each router maintains a database, known as a link-state database, describing the AS topology. From the information in this database, each router constructs a tree of shortest paths with itself as root. This shortest-path tree gives the best route to each destination in the AS.
4.5.2. OSPF Chapter 4. Routing Neighbors Routers that are in the same area become neighbors in that area. Neighbors are elected via the Hello protocol. Hello packets are sent periodically out of each interface using IP multicast. Routers become neighbors as soon as they see themselves listed in the neighbor's Hello packet. This way, a two way communication is guaranteed. The following Neighbor States are defined: Down This is the initial state of the neighbor relationship.
4.5.2. OSPF Chapter 4. Routing In the above example, the Virtual Link is configured between fw1 and fw2 on Area 1, as it is used as the transit area. In this configuration only the Router ID has to be configured. The diagram shows that fw2 needs to have a Virtual Link to fw1 with Router ID 192.168.1.1 and vice versa. These Virtual Links need to be configured in Area 1. A Partitioned Backbone OSPF allows for linking a partitioned backbone using a virtual link.
4.5.3. Dynamic Routing Policy Chapter 4. Routing The Virtual Link is configured between fw1 and fw2 on Area 1, as it is used as the transit area. In the configuration only the Router ID have to be configured, as in the example above show fw2 need to have a Virtual Link to fw1 with the Router ID 192.168.1.1 and vice versa. These VLinks need to be configured in Area 1.
4.5.3. Dynamic Routing Policy Chapter 4. Routing Example 4.7. Importing Routes from an OSPF AS into the Main Routing Table In this example, the routes received using OSPF will be added into the main routing table. First of all a Dynamic Routing Policy filter needs to be created. The filter needs to have a name, in this example ImportOSPFRoutes is used, as it explains what the filter does. The filter must also specify from what OSPF AS the routes should be imported.
4.5.3. Dynamic Routing Policy Chapter 4. Routing Web Interface 1. Go to Routing > Dynamic Routing Rules > Add > Dynamic routing policy rule 2. Specify a suitable name for the filter, for example ExportDefRoute 3. For From Routing Table select Main Routing Table 4. Choose wan for Destination Interface 5. Choose all-nets in the ...Exactly Matches list 6.
4.6. Multicast Routing Chapter 4. Routing 4.6. Multicast Routing 4.6.1. Overview Certain types of Internet interactions, such as conferencing and video broadcasts, require a single client or host to send the same packet to multiple receivers. This could be achieved through the sender duplicating the packet with different receiving IP addresses or by a broadcast of the packet across the Internet.
4.6.2. Multicast Forwarding with SAT Multiplex Rules Chapter 4. Routing The multiplex rule can operate in one of two modes: Using IGMP The traffic flow specified by the multiplex rule must have been requested by hosts using IGMP before any multicast packets are forwarded through the specified interfaces. This is the default behavior of NetDefendOS. Not using IGMP The traffic flow will be forwarded according to the specified interfaces directly without any inference from IGMP.
4.6.2. Multicast Forwarding with SAT Multiplex Rules Chapter 4. Routing The matching rule could also be a NAT rule for source address translation (see below) but cannot be a FwdFast or SAT rule. Example 4.9. Forwarding of Multicast Traffic using the SAT Multiplex Rule In this example, we will create a multiplex rule in order to forward the multicast groups 239.192.10.0/24:1234 to the interfaces if1, if2 and if3. All groups have the same sender 192.168.10.
4.6.2. Multicast Forwarding with SAT Multiplex Rules Chapter 4. Routing The CLI command to create the multiplex rule is then: add IPRule SourceNetwork= SourceInterface= DestinationInterface= DestinationNetwork= Action=MultiplexSAT Service= MultiplexArgument={outif1;ip1},{outif2;ip2},{outif3;ip3}... The two values {outif;ip} represent a combination of output interface and, if address translation of a group is needed, an IP address.
4.6.3. IGMP Configuration Chapter 4. Routing Example 4.10. Multicast Forwarding - Address Translation The following SAT Multiplex rule needs to be configured to match the scenario described above: Web Interface A. Create a custom service for multicast called multicast_service: 1. Go to Objects > Services > Add > TCP/UDP 2. Now enter: • Name: multicast_service • Type: UDP • Destination: 1234 B. Create an IP rule: 1. Go to Rules > IP Rules > Add > IP Rule 2. Under General enter. 3.
4.6.3. IGMP Configuration Chapter 4. Routing the multicast source is located on a network directly connected to the router. In this case, no query rule is needed. A second exception is if a neighboring router is statically configured to deliver a multicast stream to the NetDefend Firewall. In this case also, an IGMP query would not have to be specified. NetDefendOS supports two IGMP modes of operation - Snoop and Proxy. Figure 4.10. Multicast Snoop Figure 4.11.
4.6.3. IGMP Configuration Chapter 4. Routing 4.6.3.1. IGMP Rules Configuration - No Address Translation This example describes the IGMP rules needed for configuring IGMP according to the No Address Translation scenario described above. We want our router to act as a host towards the upstream router and therefore we configure IGMP to run in proxy mode. Example 4.11. IGMP - No Address Translation The following example requires a configured interface group IfGrpClients including interfaces if1, if2 and if3.
4.6.3. IGMP Configuration 4. • Multicast Source: 192.168.10.1 • Multicast Group: 239.192.10.0/24 Chapter 4. Routing Click OK 4.6.3.2. IGMP Rules Configuration - Address Translation The following examples illustrates the IGMP rules needed to configure IGMP according to the Address Translation scenario described above in Section 4.6.2.2, “Multicast Forwarding - Address Translation Scenario”. We need two IGMP report rules, one for each client interface.
4.6.3. IGMP Configuration • 3. 4. Chapter 4. Routing Output: if1 (this is the relay interface) Under Address Filter enter: • Source Interface: wan • Source Network: UpstreamRouterIp • Destination Interface: core • Destination Network: auto • Multicast Source: 192.168.10.1 • Multicast Group: 239.192.10.0/24 Click OK Example 4.13.
4.6.4. Advanced IGMP Settings 3. 4. Chapter 4. Routing Under Address Filter enter: • Source Interface: wan • Source Network: UpstreamRouterIp • Destination Interface: core • Destination Network: auto • Multicast Source: 192.168.10.1 • Multicast Group: 239.192.10.0/24 Click OK Advanced IGMP Settings There are a number of IGMP advanced settings which are global and apply to all interfaces which do not have IGMP settings explicitly specified for them. 4.6.4.
4.6.4. Advanced IGMP Settings Chapter 4. Routing Default: IGMPv3 IGMP Last Member Query Interval The maximum time in milliseconds until a host has to send an answer to a group or group-and-source specific query. Global setting on interfaces without an overriding IGMP Setting. Default: 5,000 IGMP Max Total Requests The maximum global number of IGMP messages to process each second. Default: 1000 IGMP Max Interface Requests The maximum number of requests per interface and second.
4.6.4. Advanced IGMP Settings Chapter 4. Routing interfaces without an overriding IGMP Setting. Default: 30,000 IGMP Unsolicated Report Interval The time in milliseconds between repetitions of an initial membership report. Global setting on interfaces without an overriding IGMP Setting.
4.7. Transparent Mode Chapter 4. Routing 4.7. Transparent Mode 4.7.1. Overview Transparent Mode Usage The NetDefendOS Transparent Mode feature allows a NetDefend Firewall to be placed at a point in a network without any reconfiguration of the network and without hosts being aware of its presence. All NetDefendOS features can then be used to monitor and manage traffic flowing through that point.
4.7.1. Overview Chapter 4. Routing . If the NetDefend Firewall is placed into a network for the first time, or if network topology changes, the routing configuration must therefore be checked and adjusted to ensure that the routing table is consistent with the new layout. Reconfiguration of IP settings may be required for pre-existing routers and protected servers. This works well when comprehensive control over routing is desired.
4.7.1. Overview Chapter 4. Routing Discovery is done by NetDefendOS sending out ARP as well as ICMP (ping) requests, acting as the initiating sender of the original IP packet for the destination on the interfaces specified in the Switch Route. If an ARP reply is received, NetDefendOS will update the CAM table and Layer 3 Cache and forward the packet to the destination. If the CAM table or the Layer 3 Cache is full, the tables are partially flushed automatically.
4.7.1. Overview Chapter 4. Routing associated with the switch routes, transparency will exist between them. For example, if the interfaces if1 to if6 appear in a switch routes in routing table A, the resulting interconnections will be as illustrated below. Connecting together switch routes in this way only applies, however, if all interfaces are associated with the same routing table. The situation where they are not, is described next.
4.7.2. Enabling Internet Access Chapter 4. Routing The recommended way to enable Transparent Mode is to add switch routes, as described above. An alternative method is to enable transparent mode directly on an interface (a check box for this is provided in the graphical user interfaces). When enabled in this way, default switch routes are automatically added to the routing table for the interface and any corresponding non-switch routes are automatically removed.
4.7.2. Enabling Internet Access Chapter 4. Routing Transparent Mode with a common address range (in this example 192.168.10.0/24). Figure 4.13. Transparent Mode Internet Access In this situation, any "normal" non-switch all-nets routes in the routing table should be removed and replaced with an all-nets switch route (not doing this is a common mistake during setup). This switch route will allow traffic from the local users on Ethernet network pn2 to find the ISP gateway.
4.7.3. Transparent Mode Scenarios Chapter 4. Routing The other consequence of not using NAT is that IP addresses of users accessing the Internet usually need to be public IP addresses. If NATing needs to be performed in the example above to hide individual addresses from the Internet, it would have to be done by a device (possibly another NetDefend Firewall) between the 192.168.10.0/24 network and the public Internet. In this case, internal IP addresses could be used by the users on Ethernet network pn2.
4.7.3. Transparent Mode Scenarios 5. 6. Chapter 4. Routing Now enter: • IP Address: 10.0.0.2 • Network: 10.0.0.0/24 • Transparent Mode: Enable Click OK Configure the rules: 1. Go to Rules > IP Rules > Add > IPRule 2. Now enter: 3. • Name: HTTPAllow • Action: Allow • Service: http • Source Interface: lan • Destination Interface: any • Source Network: 10.0.0.0/24 • Destination Network: all-nets (0.0.0.
4.7.3. Transparent Mode Scenarios Chapter 4. Routing Example 4.15. Setting up Transparent Mode for Scenario 2 Configure a Switch Route over the LAN and DMZ interfaces for address range 10.0.0.0/24 (assume the WAN interface is already configured). Web Interface Configure the interfaces: 1. Go to Interfaces > Ethernet > Edit (lan) 2. Now enter: • IP Address: 10.0.0.1 • Network: 10.0.0.0/24 • Transparent Mode: Disable • Add route for interface network: Disable 3. Click OK 4.
4.7.3. Transparent Mode Scenarios • 3. Chapter 4. Routing Interfaces: Select lan and dmz Click OK Configure the routing: 1. Go to Routing > Main Routing Table > Add > SwitchRoute 2. Now enter: 3. • Switched Interfaces: TransparentGroup • Network: 10.0.0.0/24 • Metric: 0 Click OK Configure the rules: 1. Go to Rules > IP Rules > Add > IPRule 2.
4.7.4. Spanning Tree BPDU Support 9. • Destination Interface: dmz • Source Network: all-nets • Destination Network: wan_ip Chapter 4. Routing Click OK 4.7.4. Spanning Tree BPDU Support NetDefendOS includes support for relaying the Bridge Protocol Data Units (BPDUs) across the NetDefend Firewall. BPDU frames carry Spanning Tree Protocol (STP) messages between layer 2 switches in a network.
4.7.5. Advanced Settings for Transparent Mode Chapter 4. Routing Default: Enabled Decrement TTL Enable this if the TTL should be decremented each time a packet traverses the firewall in Transparent Mode. Default: Disabled Dynamic CAM Size This setting can be used to manually configure the size of the CAM table. Normally Dynamic is the preferred value to use. Default: Dynamic CAM Size If the Dynamic CAM Size setting is not enabled then this is the maximum number of entries in each CAM table.
4.7.5. Advanced Settings for Transparent Mode Chapter 4. Routing Null Enet Sender Defines what to do when receiving a packet that has the sender hardware (MAC) address in ethernet header set to null (0000:0000:0000). Options: • Drop - Drop packets • DropLog - Drop and log packets Default: DropLog Broadcast Enet Sender Defines what to do when receiving a packet that has the sender hardware (MAC) address in ethernet header set to the broadcast ethernet address (FFFF:FFFF:FFFF).
4.7.5. Advanced Settings for Transparent Mode • Drop - Drop the packets • DropLog - Drop packets log the event Chapter 4. Routing Default: Drop Relay MPLS When set to Ignore all incoming MPLS packets are relayed in transparent mode.
4.7.5. Advanced Settings for Transparent Mode Chapter 4.
Chapter 5. DHCP Services This chapter describes DHCP services in NetDefendOS. • Overview, page 189 • DHCP Servers, page 190 • Static DHCP Assignment, page 193 • DHCP Relaying, page 195 • IP Pools, page 198 5.1. Overview Dynamic Host Configuration Protocol (DHCP) is a protocol that allows network administrators to automatically assign IP numbers to computers on a network. IP Address Assignment A DHCP Server implements the task of assigning IP addresses to DHCP clients.
5.2. DHCP Servers Chapter 5. DHCP Services 5.2. DHCP Servers DHCP servers assign and manage the IP addresses taken from a specified address pool. In NetDefendOS, DHCP servers are not limited to serving a single range of IP addresses but can use any IP address range that can be specified by a NetDefendOS IP address object. Multiple DHCP Servers The administrator has the ability to set up one or more logical DHCP servers in NetDefendOS.
5.2. DHCP Servers Chapter 5. DHCP Services • WINS Servers - WINS servers the client can use for WINS lookup. • Next Server - the IP address of the next server in the boot process, this is usually a TFTP server. In addition, Custom Options can be specified in order to have the DHCP servers hand out all options supported by the DHCP standard. Example 5.1.
5.2. DHCP Servers Chapter 5. DHCP Services 10.4.13.241 10.4.13.242 10.4.13.243 10.4.13.244 10.4.13.254 10.4.13.1 10.4.13.2 10.4.13.3 10.4.13.
5.3. Static DHCP Assignment Chapter 5. DHCP Services 5.3. Static DHCP Assignment Where the administrator requires a fixed relationship between a client and the assigned IP address, NetDefendOS allows the assignment of a given IP to a specific MAC address. Example 5.3. Setting up Static DHCP This example shows how to assign the IP address 192.168.1.1 to the MAC address 00-90-12-13-14-15. The examples assumes that the DHCP server DHCPServer1 has already been defined. CLI 1.
5.3.1. DHCP Advanced Settings Chapter 5. DHCP Services Auto Save Policy What policy should be used to save the lease database to the disk, possible settings are Disabled, ReconfShut or ReconfShutTimer. Default: ReconfShut Lease Store Interval How often, in seconds, the leases database should be saved to disk if DHCPServer_SaveLeasePolicy is set to ReconfShutTimer.
5.4. DHCP Relaying Chapter 5. DHCP Services 5.4. DHCP Relaying The DHCP Problem With DHCP, clients send requests to locate the DHCP server(s) using broadcast messages. However, broadcasts are normally only propagated across the local network. This means that the DHCP server and client always need to be on the same physical network. In a large Internet-like network topology, this means there would have to be a different DHCP server on every network. This problem is solved by the use of a DHCP relayer.
5.4.1. DHCP Relay Advanced Settings 3. Chapter 5. DHCP Services Click OK Adding a DHCP relayer called as vlan-to-dhcpserver: 1. Go to System > DHCP > Add > DHCP Relay 2. Now enter: • Name: vlan-to-dhcpserver • Action: Relay • Source Interface: ipgrp-dhcp • DHCP Server to relay to: ip-dhcp • Allowed IP offers from server: all-nets 3. Under the Add Route tab, check Add dynamic routes for this relayed DHCP lease 4. Click OK 5.4.1.
5.4.1. DHCP Relay Advanced Settings Chapter 5. DHCP Services Max Auto Routes How many relays that can be active at the same time. Default: 256 Auto Save Policy What policy should be used to save the relay list to the disk, possible settings are Disabled, ReconfShut, or ReconfShutTimer. Default: ReconfShut Auto Save Interval How often, in seconds, should the relay list be saved to disk if DHCPServer_SaveRelayPolicy is set to ReconfShutTimer.
5.5. IP Pools Chapter 5. DHCP Services 5.5. IP Pools Overview IP pools are used to offer other subsystems access to a cache of DHCP IP addresses. These addresses are gathered into a pool by internally maintaining a series of DHCP clients (one per IP). The DHCP servers used by a pool can either be external or be DHCP servers defined in NetDefendOS itself. External DHCP servers can be specified as the server on a specific interface or by a unique IP address.
5.5. IP Pools Chapter 5. DHCP Services Maximum free The maximum number of "free" IPs to be kept. Must be equal to or greater than the prefetch parameter. The pool will start releasing (giving back IPs to the DHCP server) when the number of free clients exceeds this value. Maximum clients Optional setting used to specify the maximum number of clients (IPs) allowed in the pool.
5.5. IP Pools Chapter 5.
Chapter 6. Security Mechanisms This chapter describes NetDefendOS security features. • Access Rules, page 201 • ALGs, page 204 • Web Content Filtering, page 251 • Anti-Virus Scanning, page 268 • Intrusion Detection and Prevention, page 274 • Denial-of-Service Attack Prevention, page 285 • Blacklisting Hosts and Networks, page 289 6.1. Access Rules 6.1.1. Introduction One of the principal functions of NetDefendOS is to allow only authorized connections access to protected data resources.
6.1.3. Access Rule Settings Chapter 6. Security Mechanisms VPNs provide one means of avoiding spoofing but where a VPN is not an appropriate solution then Access Rules can provide an anti-spoofing capability by providing an extra filter for source address verification. An Access Rule can verify that packets arriving at a given interface do not have a source address which is associated with a network of another interface.
6.1.3. Access Rule Settings Chapter 6. Security Mechanisms problems in case a rule is preventing some other function, such as VPN tunnel establishment, from working properly. Example 6.1. Setting up an Access Rule A rule is to be defined that ensures no traffic with a source address not within the lannet network is received on the lan interface. CLI gw-world:/> add Access Name=lan_Access Interface=lan Network=lannet Action=Expect Web Interface 1. Go to Rules > Access 2.
6.2. ALGs Chapter 6. Security Mechanisms 6.2. ALGs 6.2.1. Overview To complement low-level packet filtering, which only inspects packet headers in protocols such as IP, TCP, UDP, and ICMP, NetDefend Firewalls provide Application Layer Gateways (ALGs) which provide filtering at the higher application OSI level. An ALG object acts as a mediator in accessing commonly used Internet applications outside the protected network, for example web access, file transfer and multimedia transfer.
6.2.2. The HTTP ALG Chapter 6. Security Mechanisms Maximum Connection Sessions The Service associated with an ALG has a configurable parameter associated with it called Max Sessions and the default value varies according to the type of ALG. For instance, the default value for the HTTP ALG is 1000. This means that a 1000 connections are allowed in total for the HTTP Service across all interfaces. The full list of default maximum session values are: • HTTP ALG - 1000 sessions. • FTP ALG - 200 sessions.
6.2.2. The HTTP ALG Chapter 6. Security Mechanisms when specifying URLs, as described below. • URL Whitelisting The opposite to blacklisting, this makes sure certain URLs are always allowed. Wildcarding can also be used for these URLs, as described below. It is important to note that whitelisting a URL means that it cannot be blacklisted and it also cannot be dropped by web content filtering (if that is enabled, although it will be logged).
6.2.2. The HTTP ALG Chapter 6. Security Mechanisms download will be dropped. If nothing is marked in this mode then no files can be downloaded. Additional filetypes not included by default can be added to the Allow/Block list however these cannot be subject to content checking meaning that the file extension will be trusted as being correct for the contents of the file.
6.2.3. The FTP ALG Chapter 6. Security Mechanisms Using Wildcards in White and Blacklists Entries made in the white and blacklists can make use of wildcarding to have a single entry be equivalent to a large number of possible URLs. The wildcard character "*" can be used to represent any sequence of characters. For example, the entry *.some_domain.com will block all pages whose URLs end with some_domain.com.
6.2.3. The FTP ALG Chapter 6. Security Mechanisms Consider a scenario where an FTP client on the internal network connects through the firewall to an FTP server on the Internet. The IP rule is then configured to allow network traffic from the FTP client to port 21 on the FTP server. When active mode is used, NetDefendOS doesn't know that the FTP server will establish a new connection back to the FTP client. Therefore, the incoming connection for the data channel will be dropped.
6.2.3. The FTP ALG Chapter 6. Security Mechanisms Anti-Virus Scanning The NetDefendOS Anti-Virus subsystem can be enabled to scan all FTP downloads searching for malicious code. Suspect files can be de dropped or just logged. This feature is common to a number of ALGs and is described fully in Section 6.4, “Anti-Virus Scanning”. FTP ALG with ZoneDefense Used together with the FTP ALG, ZoneDefense can be configured to protect an internal network from virus spreading servers and hosts.
6.2.3. The FTP ALG Chapter 6. Security Mechanisms To make it possible to connect to this server from the Internet using the FTP ALG, the FTP ALG and rules should be configured as follows: Web Interface A. Define the ALG: 1. Go to Objects > ALG > Add > FTP ALG 2. Enter Name: ftp-inbound 3. Check Allow client to use active mode 4. Uncheck Allow server to use passive mode 5. Click OK B. Define the Service: 1. Go to Objects > Services > Add > TCP/UDP Service 2. Enter the following: 3.
6.2.3. The FTP ALG 3. • Name: SAT-ftp-inbound • Action: SAT • Service: ftp-inbound Chapter 6. Security Mechanisms For Address Filter enter: • Source Interface: any • Destination Interface: core • Source Network: all-nets • Destination Network: wan_ip (assuming the external interface has been defined as this) 4. For SAT check Translate the Destination IP Address 5.
6.2.3. The FTP ALG Chapter 6. Security Mechanisms Example 6.3. Protecting FTP Clients In this scenario shown below the NetDefend Firewall is protecting a workstation that will connect to FTP servers on the Internet. To make it possible to connect to these servers from the internal network using the FTP ALG, the FTP ALG and rules should be configured as follows: Web Interface A. Create the FTP ALG: 1. Go to Objects > ALG > Add > FTP ALG 2. Enter Name: ftp-outbound 3.
6.2.4. The TFTP ALG Chapter 6. Security Mechanisms Rules (Using Public IPs). The following rule needs to be added to the IP rules if using public IP's; make sure there are no rules disallowing or allowing the same kind of ports/traffic before these rules. The service in use is the ftp-outbound, which should be using the ALG definition ftp-outbound as described earlier. C. Allow connections to ftp-servers on the outside: 1. Go to Rules > IP Rules > Add > IPRule 2. Now enter: 3. 4.
6.2.5. The SMTP ALG Chapter 6. Security Mechanisms Allow/Disallow Read The TFTP GET function can be disabled so that files cannot be retrieved by a TFTP client. The default value is Allow. Allow/Disallow Write The TFTP PUT function can be disabled so that files cannot be written by a TFTP client. The default value is Allow. Remove Request Option Specifies if options should be removed from request. The default is False which means "do not remove".
6.2.5. The SMTP ALG Chapter 6. Security Mechanisms This is a very useful feature to have since it is possible to put in a block against either an infected client or an infected server sending large amounts of malware generated emails. Email size limiting A maximum allowable size of email messages can be specified. This feature counts the total amount of bytes sent for a single email which is the header size plus body size plus the size of any email attachments after they are encoded.
6.2.5. The SMTP ALG 4. Chapter 6. Security Mechanisms Anti-virus scanning (if enabled). As described above, if an address is found on the whitelist then it will not be blocked if it also found on the blacklist. SPAM filtering, if it is enabled, is still applied to whitelisted addresses but emails flagged as SPAM will not be tagged nor dropped, only logged. Anti-virus scanning, if it is enabled, is always applied, even though an email's address is whitelisted.
6.2.5. The SMTP ALG Chapter 6. Security Mechanisms The NetDefendOS SMTP ALG does not support all ESMTP extensions including Pipelining and Chunking. The ALG therefore removes any unsupported extensions from the supported extension list that is returned to the client by an SMTP server behind the NetDefend Firewall.
6.2.5. The SMTP ALG Chapter 6. Security Mechanisms security issue on the public Internet. Unsolicited email, sent out in massive quantities by groups known as spammers, can waste resources, transport malware as well as try to direct the reader to webpages which might exploit browser vulnerabilities. Integral to the NetDefendOS SMTP ALG is a SPAM module that provides the ability to apply spam filtering to incoming email based on its origin.
6.2.5. The SMTP ALG Chapter 6. Security Mechanisms weighted sum can then be calculated based on all responses. The administrator can configure one of the following actions based on the sum calculated: 1. Dropped If the sum is greater than or equal to a predefined Drop threshold then the email is considered to be definitely SPAM and is discarded or alternatively sent to a single, special mailbox.
6.2.5. The SMTP ALG Chapter 6. Security Mechanisms And this is what the email's recipient will see in the summary of their inbox contents. The individual user could then decide to set up their own filters in the local client to deal with such tagged emails, possibly sending it to a separate folder. Adding X-SPAM Information If an email is determined to be SPAM and a forwarding address is configured for dropped emails, then the administrator has the option to Add TXT Records to the email.
6.2.5. The SMTP ALG Chapter 6. Security Mechanisms allowed through if this happens. Setup Summary To set up DNSBL SPAM filtering in the SMTP ALG, the following list summarizes the steps: • Specify which DNSBL servers are to be used. There can be multiple and they can act both as backups to each other as well as confirmation of a sender's status. • Specify a weight for each server which will determine how important it is in deciding if email is SPAM or not in the calculation of a weighted sum.
6.2.6. The POP3 ALG Chapter 6. Security Mechanisms The dnsbl CLI command provides a means to control and monitor the operation of the SPAM filtering module. The dnsbl command on its own without options shows the overall status of all ALGs.
6.2.7. The SIP ALG Chapter 6. Security Mechanisms 6.2.6. The POP3 ALG POP3 is a mail transfer protocol that differs from SMTP in that the transfer of mail is directly from a server to a user's client software. POP3 ALG Options Key features of the POP3 ALG are: Block Clear Text Authentication Block connections between client and server that send the username/password combination as clear text which can be easily read (some servers may not support other methods than this).
6.2.7. The SIP ALG Chapter 6. Security Mechanisms Note: Traffic shaping will not work with the SIP ALG Any traffic connections that trigger an IP rule with a service object that uses the SIP ALG cannot be also subject to traffic shaping. SIP Components The following components are the logical building blocks for SIP communication: User Agents These are the end points or clients that are involved in the client-to-client communication.
6.2.7. The SIP ALG Chapter 6. Security Mechanisms Maximum Sessions per ID The number of simultaneous sessions that a single client can be involved with is restricted by this value. The default number is 5. Maximum Registration Time The maximum time for registration with a SIP Registrar. The default value is 3600 seconds. SIP Signal Timeout The maximum time allowed for SIP sessions. The default value is 43200 seconds.
6.2.7. The SIP ALG Chapter 6. Security Mechanisms (sometimes described as SIP pinholes) for allowing the media data traffic to flow through the NetDefend Firewall. Tip Make sure there are no preceding rules already in the IP rule set disallowing or allowing the same kind of traffic. SIP Usage Scenarios NetDefendOS supports a variety of SIP usage scenarios.
6.2.7. The SIP ALG Chapter 6. Security Mechanisms The SIP proxy in the above diagram could alternatively be located remotely across the Internet. The proxy should be configured with the Record-Route feature enabled to insure all SIP traffic to and from the office clients will be sent through the SIP Proxy. This is recommended since the attack surface is minimized by allowing only SIP signalling from the SIP Proxy to enter the local network.
6.2.7. The SIP ALG Chapter 6. Security Mechanisms sends its own IP address as contact information to the SIP proxy. NetDefendOS registers the client's local contact information and uses this to redirect incoming requests to the user. The ALG takes care of the address translations needed. 4. Ensure the clients are correctly configured. The SIP Proxy Server plays a key role in locating the current location of the other client for the session. The proxy's IP address is not specified directly in the ALG.
6.2.7. The SIP ALG Chapter 6. Security Mechanisms This scenario can be implemented in two ways: • Using NAT to hide the network topology. • Without NAT so the network topology is exposed. Solution A - Using NAT Here, the proxy and the local clients are hidden behind the IP address of the NetDefend Firewall. The setup steps are as follows: 1. Define a single SIP ALG object using the options described above. 2. Define a Service object which is associated with the SIP ALG object.
6.2.7. The SIP ALG Chapter 6. Security Mechanisms If Record-Route is enabled then the Source Network for outbound traffic from proxy users can be further restricted in the above rules by using "ip_proxy" as indicated. When an incoming call is received, the SIP ALG will follow the SAT rule and forward the SIP request to the proxy server. The proxy will in turn, forward the request to its final destination which is the client.
6.2.7. The SIP ALG Chapter 6. Security Mechanisms The exchanges illustrated are as follows: • 1,2 - An initial INVITE is sent to the outbound local proxy server on the DMZ. • 3,4 - The proxy server sends the SIP messages towards the destination on the Internet. • 5,6 - A remote client or proxy server replies to the local proxy server. • 7,8 - The local proxy forwards the reply to the local client.
6.2.7. The SIP ALG Chapter 6. Security Mechanisms DMZ interface as the contact address. • An Allow rule for outbound traffic from the proxy behind the DMZ interface to the remote clients on the Internet. • An Allow rule for inbound SIP traffic from the SIP proxy behind the DMZ interface to the IP address of the NetDefend Firewall. This rule will have core (in other words, NetDefendOS itself) as the destination interface. The reason for this is because of the NAT rule above.
6.2.8. The H.323 ALG 3. 4. Chapter 6. Security Mechanisms • Destination Port set to 5060 (the default SIP signalling port) • Type set to TCP/UDP Define four rules in the IP rule set: • An Allow rule for outbound traffic from the clients on the internal network to the proxy located on the DMZ interface. • An Allow rule for outbound traffic from the proxy behind the DMZ interface to the remote clients on the Internet.
6.2.8. The H.323 ALG Chapter 6. Security Mechanisms Gateways An H.323 gateway connects two dissimilar networks and translates traffic between them. It provides connectivity between H.323 networks and non-H.323 networks such as public switched telephone networks (PSTN), translating protocols and converting media streams. A gateway is not required for communication between two H.323 terminals. Gatekeepers The Gatekeeper is a component in the H.
6.2.8. The H.323 ALG Chapter 6. Security Mechanisms • The H.323 ALG supports version 5 of the H.323 specification. This specification is built upon H.225.0 v5 and H.245 v10. • In addition to support voice and video calls, the H.323 ALG supports application sharing over the T.120 protocol. T.120 uses TCP to transport data while voice and video is transported over UDP. • To support gatekeepers, the ALG monitors RAS traffic between H.
6.2.8. The H.323 ALG Chapter 6. Security Mechanisms Web Interface Outgoing Rule: 1. Go to Rules > IP Rules > Add > IPRule 2. Now enter: 3. • Name: H323AllowOut • Action: Allow • Service: H323 • Source Interface: lan • Destination Interface: any • Source Network: lannet • Destination Network: 0.0.0.0/0 (all-nets) • Comment: Allow outgoing calls Click OK Incoming Rule: 1. Go to Rules > IP Rules > Add > IPRule 2. Now enter: 3.
6.2.8. The H.323 ALG Chapter 6. Security Mechanisms Example 6.5. H.323 with private IP addresses In this scenario a H.323 phone is connected to the NetDefend Firewall on a network with private IP addresses. To make it possible to place a call from this phone to another H.323 phone on the Internet, and to allow H.323 phones on the Internet to call this phone, we need to configure rules.
6.2.8. The H.323 ALG 3. Chapter 6. Security Mechanisms • Destination Interface: core • Source Network: 0.0.0.0/0 (all-nets) • Destination Network: wan_ip (external IP of the firewall) • Comment: Allow incoming calls to H.323 phone at ip-phone Click OK To place a call to the phone behind the NetDefend Firewall, place a call to the external IP address on the firewall. If multiple H.323 phones are placed behind the firewall, one SAT rule has to be configured for each phone.
6.2.8. The H.323 ALG Chapter 6. Security Mechanisms Incoming Rule: 1. Go to Rules > IP Rules > Add > IPRule 2. Now enter: 3. • Name: H323AllowIn • Action: Allow • Service: H323 • Source Interface: any • Destination Interface: lan • Source Network: 0.0.0.0/0 (all-nets) • Destination Network: lannet • Comment: Allow incoming calls Click OK Example 6.7. Using Private IP Addresses This scenario consists of two H.
6.2.8. The H.323 ALG Chapter 6. Security Mechanisms • Source Interface: any • Destination Interface: core • Source Network: 0.0.0.0/0 (all-nets) • Destination Network: wan_ip (external IP of the firewall) • Comment: Allow incoming calls to H.323 phone at ip-phone 3. For SAT enter Translate Destination IP Address: To New IP Address: ip-phone (IP address of phone) 4. Click OK 1. Go to Rules > IP Rules > Add > IPRule 2. Now enter: 3.
6.2.8. The H.323 ALG Chapter 6. Security Mechanisms Web Interface Incoming Gatekeeper Rules: 1. Go to Rules > IP Rules > Add > IPRule 2. Now enter: • Name: H323In • Action: SAT • Service: H323-Gatekeeper • Source Interface: any • Destination Interface: core • Source Network: 0.0.0.0/0 (all-nets) • Destination Network: wan_ip (external IP of the firewall) • Comment: SAT rule for incoming communication with the Gatekeeper located at ip-gatekeeper 3.
6.2.8. The H.323 ALG 2. 3. Chapter 6. Security Mechanisms Now enter: • Name: H323In • Action: Allow • Service: H323-Gatekeeper • Source Interface: lan • Destination Interface: dmz • Source Network: lannet • Destination Network: ip-gatekeeper (IP address of the gatekeeper) • Comment: Allow incoming communication with the Gatekeeper Click OK Note: Outgoing calls do not need a specific rule There is no need to specify a specific rule for outgoing calls.
6.2.8. The H.323 ALG 3. Chapter 6. Security Mechanisms • Name: H323Out • Action: NAT • Service: H323-Gatekeeper • Source Interface: lan • Destination Interface: any • Source Network: lannet • Destination Network: 0.0.0.0/0 (all-nets) • Comment: Allow outgoing communication with a gatekeeper Click OK Note: Outgoing calls do not need a specific rule There is no need to specify a specific rule for outgoing calls.
6.2.8. The H.323 ALG Chapter 6. Security Mechanisms The head office has placed a H.323 Gatekeeper in the DMZ of the corporate NetDefend Firewall. This firewall should be configured as follows: Web Interface 1. Go to Rules > IP Rules > Add > IPRule 2. Now enter: • Name: LanToGK • Action: Allow • Service: H323-Gatekeeper • Source Interface: lan • Destination Interface: dmz • Source Network: lannet • Destination Network: ip-gatekeeper • Comment: Allow H.
6.2.8. The H.323 ALG Chapter 6. Security Mechanisms • Source Interface: lan • Destination Interface: dmz • Source Network: lannet • Destination Network: ip-gateway • Comment: Allow H.323 entities on lannet to call phones connected to the H.323 Gateway on the DMZ 3. Click OK 1. Go to Rules > IP Rules > Add > IPRule 2.
6.2.8. The H.323 ALG 3. Chapter 6. Security Mechanisms Click OK Example 6.11. Configuring remote offices for H.323 If the branch and remote office H.323 phones and applications are to be configured to use the H.323 Gatekeeper at the head office, the NetDefend Firewalls in the remote and branch offices should be configured as follows: (this rule should be in both the Branch and Remote Office firewalls). Web Interface 1. Go to Rules > IP Rules > Add > IPRule 2. Now enter: 3.
6.2.9. The TLS ALG Chapter 6. Security Mechanisms the communication between "external" phones and the Gatekeeper to make sure that it is possible for internal phones to call the external phones that are registered with the gatekeeper. 6.2.9. The TLS ALG Overview Transport Layer Security (TLS) is a protocol that provides secure communications over the public Internet between two end points through the use of cryptography as well as providing endpoint authentication.
6.2.9. The TLS ALG Chapter 6. Security Mechanisms Advantages of Using NetDefendOS for TLS Termination TLS can be implemented directly in the server to which clients connect, however, if the servers are protected behind a NetDefend Firewall, then NetDefendOS can take on the role of the TLS endpoint. NetDefendOS then performs TLS authentication, encryption and unencryption of data to/from clients and the transfer of unencrypted data to/from servers.
6.2.9. The TLS ALG 6. Chapter 6. Security Mechanisms Optionally, a SAT rule can be created to change the destination port for the unencrypted traffic. Alternatively an SLB_SAT rule can be used to do load balancing (the destination port can also be changed through a custom service object). URLs Delivered by Servers It should be noted that using NetDefendOS for TLS termination will not change URLs in webpages delivered by servers which lie behind the NetDefend Firewall.
6.3. Web Content Filtering Chapter 6. Security Mechanisms 6.3. Web Content Filtering 6.3.1. Overview Web traffic is one of the biggest sources for security issues and misuse of the Internet. Inappropriate surfing habits can expose a network to many security threats as well as legal and regulatory liabilities. Productivity and Internet bandwidth can also be impaired.
6.3.3. Static Content Filtering Chapter 6. Security Mechanisms Removing such legitimate code could, at best, cause the web site to look distorted, at worst, cause it to not work in a browser at all. Active Content Handling should therefore only be used when the consequences are well understood. Example 6.13. Stripping ActiveX and Java applets This example shows how to configure a HTTP Application Layer Gateway to strip ActiveX and Java applets.
6.3.3. Static Content Filtering Chapter 6. Security Mechanisms */*.gif Good. This will block all files with .gif as the file name extension. www.example.com Bad. This will only block the first request to the web site. Surfing to www.example.com/index.html, for example, will not be blocked. *example.com/* Bad. This will also cause www.myexample.com to be blocked since it blocks all sites ending with example.com.
6.3.4. Dynamic Web Content Filtering 7. Chapter 6. Security Mechanisms Click OK Finally, make an exception from the blacklist by creating a whitelist: 1. Go to Objects > ALG 2. In the table, click on the recently created HTTP ALG to view its properties 3. Click the HTTP URL tab 4. Now click Add and select HTTP ALG URL from the menu 5. Select Whitelist as the Action 6. In the URL textbox, enter www.D-Link.com/*.exe 7.
6.3.4. Dynamic Web Content Filtering Chapter 6. Security Mechanisms Figure 6.6. Dynamic Content Filtering Flow If the requested web page URL is not present in the databases, then the webpage content at the URL will automatically be downloaded to D-Link's central data warehouse and automatically analyzed using a combination of software techniques. Once categorized, the URL is distributed to the global databases and NetDefendOS receives the category for the URL.
6.3.4. Dynamic Web Content Filtering Chapter 6. Security Mechanisms Dynamic Content Filtering is a feature that is enabled by taking out a separate subscription to the service. This is an addition to the normal NetDefendOS license. Once a subscription is taken out, an HTTP Application Layer Gateway (ALG) Object should be defined with Dynamic Content Filtering enabled.
6.3.4. Dynamic Web Content Filtering Chapter 6. Security Mechanisms 5. In the Blocked Categories list, select Search Sites and click the >> button. 6. Click OK Then, create a Service object using the new HTTP ALG: 1. Go to Local Objects > Services > Add > TCP/UDP service 2. Specify a suitable name for the Service, for example http_content_filtering 3. Select the TCP in the Type dropdown list 4. Enter 80 in the Destination Port textbox 5.
6.3.4. Dynamic Web Content Filtering Chapter 6. Security Mechanisms This example is based on the same scenario as the previous example, but now with audit mode enabled. CLI First, create an HTTP Application Layer Gateway (ALG) Object: gw-world:/> add ALG ALG_HTTP content_filtering WebContentFilteringMode=Audit FilteringCategories=SEARCH_SITES Web Interface First, create an HTTP Application Layer Gateway (ALG) Object: 1. Go to Objects > ALG > Add > HTTP ALG 2.
6.3.4. Dynamic Web Content Filtering Chapter 6. Security Mechanisms will include a dropdown list containing all available categories. If the user believes the requested web site is wrongly classified, he can select a more appropriate category from the dropdown list and submit that as a proposal. The URL to the requested web site as well as the proposed category will then be sent to D-Link's central data warehouse for manual inspection.
6.3.4. Dynamic Web Content Filtering Chapter 6. Security Mechanisms this are web sites that contain information relating to sexuality and sexual health, which may be classified under the Health Sites Category (21). Examples might be: • www.naughtychix.com • www.fullonxxx.
6.3.4. Dynamic Web Content Filtering Chapter 6. Security Mechanisms A web site may be classified under the Shopping category if its content includes any form of advertisement of goods or services to be exchanged for money, and may also include the facilities to perform that transaction online. Included in this category are market promotions, catalogue selling and merchandising services. Examples might be: • www.megamall.com • www.buy-alcohol.
6.3.4. Dynamic Web Content Filtering Chapter 6. Security Mechanisms A web site may be classified under the Investment Sites category if its content includes information, services or facilities pertaining to personal investment. URLs in this category include contents such as brokerage services, online portfolio setup, money management forums or stock quotes. This category does not include electronic banking facilities; refer to the E-Banking category (12). Examples might be: • www.loadsofmoney.com.
6.3.4. Dynamic Web Content Filtering • www.sportstoday.com • www.soccerball.com Chapter 6. Security Mechanisms Category 17: www-Email Sites A web site may be classified under the www-Email Sites category if its content includes online, web-based email facilities. Examples might be: • www.coldmail.com • mail.yazoo.com Category 18: Violence / Undesirable A web site may be classified under the Violence / Undesirable category if its contents are extremely violent or horrific in nature.
6.3.4. Dynamic Web Content Filtering Chapter 6. Security Mechanisms Category 22: Clubs and Societies A web site may be classified under the Clubs and Societies category if its content includes information or services of relating to a club or society. This includes team or conference web sites. Examples might be: • www.sierra.org • www.walkingclub.
6.3.4. Dynamic Web Content Filtering • www.admessages.com • www.tripleclick.com Chapter 6. Security Mechanisms Category 28: Drugs/Alcohol A web site may be classified under the Drugs/Alcohol category if its content includes drug and alcohol related information or services. Some URLs categorized under this category may also be categorized under the Health category. Examples might be: • www.the-cocktail-guide.com • www.stiffdrinks.
6.3.4. Dynamic Web Content Filtering Chapter 6. Security Mechanisms particular installation's needs. The WebUI provides a simple way to download, edit and upload these files. The available files are: CompressionForbidden ContentForbidden URLForbidden RestrictedSiteNotice ReclassifyURL To perform customization it is necessary to first create a new, named ALG Banner Files object. This new object automatically contains a copy of all the files in the Default ALG Banner Files object.
6.3.4. Dynamic Web Content Filtering 2. Chapter 6. Security Mechanisms A new ALG Banner Files object must exist which the edited file(s) is uploaded to. If the object is called mytxt, the CLI command to create this object is: gw-world:/> add HTTPALGBanners mytxt This creates an object which contains a copy of all the Default content filtering banner files. 3. The modified file is then uploaded using SCP.
6.4. Anti-Virus Scanning Chapter 6. Security Mechanisms 6.4. Anti-Virus Scanning 6.4.1. Overview The NetDefendOS Anti-Virus module protects against malicious code carried in file downloads. Files may be downloaded as part of a web-page in an HTTP transfer, in an FTP download, or perhaps as an attachment to an email delivered through SMTP.
6.4.3. Activating Anti-Virus Scanning Chapter 6. Security Mechanisms Types of File Downloads Scanned As described above, Anti-Virus scanning is enabled on a per ALG basis and can scan file downloads associated with the HTTP, FTP, SMTP and POP3 ALGs. More specifically: • Any uncompressed file type transferred through these ALGs can be scanned. • If the download has been compressed, ZIP and GZIP file downloads can be scanned.
6.4.5. Subscribing to the D-Link Anti-Virus Service Chapter 6. Security Mechanisms 6.4.4. The Signature Database SafeStream NetDefendOS Anti-Virus scanning is implemented by D-Link using the "SafeStream" virus signature database. The SafeStream database is created and maintained by Kaspersky, a company which is a world leader in the field of virus detection. The database provides protection against virtually all known virus threats including trojans, worms, backdoor exploits and others.
6.4.6. Anti-Virus Options Chapter 6. Security Mechanisms 3. Compression Ratio Limit When scanning compressed files, NetDefendOS must apply decompression to examine the file's contents. Some types of data can result in very high compression ratios where the compressed file is a small fraction of the original uncompressed file size.
6.4.6. Anti-Virus Options Chapter 6. Security Mechanisms 4. When the update is completed, the newly active unit also downloads the files for the update and performs a reconfiguration. 5. This second reconfiguration causes another failover so the passive unit reverts back to being active again. These steps result in both NetDefend Firewalls in a cluster having updated databases and with the original active/passive roles. For more information about HA clusters refer to Chapter 11, High Availability.
6.4.6. Anti-Virus Options Chapter 6. Security Mechanisms 1. Go to Objects > ALG > Add > HTTP ALG 2. Specify a suitable name for the ALG, for instance anti_virus 3. Click the Antivirus tab 4. Select Protect in the Mode dropdown list 5. Click OK B. Then, create a Service object using the new HTTP ALG: 1. Go to Local Objects > Services > Add > TCP/UDP service 2. Specify a suitable name for the Service, for instance http_anti_virus 3. Select the TCP in the Type dropdown list 4.
6.5. Intrusion Detection and Prevention Chapter 6. Security Mechanisms 6.5. Intrusion Detection and Prevention 6.5.1. Overview Intrusion Definition Computer servers can sometimes have vulnerabilities which leave them exposed to attacks carried by network traffic. Worms, trojans and backdoor exploits are examples of such attacks which, if successful, can potentially compromise or take control of a server. A generic term that can be used to describe these server orientated threats are intrusions.
6.5.2. IDP Availability for D-Link Models • Chapter 6. Security Mechanisms Maintenance IDP Maintenance IDP is the base IDP system included as standard with the NetDefend DFL 210, 800, 1600 and 2500. Maintenance IDP is a simplified IDP that gives basic protection against IDP attacks. It is upgradeable to the higher level and more comprehensive Advanced IDP which is discussed next.
6.5.3. IDP Rules Chapter 6. Security Mechanisms configurable interval. This is done via an HTTP connection to the D-Link server network which delivers the latest signature database updates. If the server's signature database has a newer version than the current local database, the new database will be downloaded, replacing the older version.
6.5.4. Insertion/Evasion Attack Prevention Chapter 6. Security Mechanisms Each IDP rule has a section of settings for HTTP normalization. This allows the administrator to choose the actions that should be taken when IDP finds inconsistencies in the URIs embedded in incoming HTTP requests. Some server attacks are based on creating URIs with sequences that can exploit weaknesses in some HTTP server products.
6.5.5. IDP Pattern Matching Chapter 6. Security Mechanisms Insertion Attacks An Insertion attack consists of inserting data into a stream so that the resulting sequence of data packets is accepted by the IDP subsystem but will be rejected by the targeted application. This results is two different streams of data. As an example, consider a data stream broken up into 4 packets: p1, p2, p3 and p4. The attacker might first send packets p1 and p4 to the targeted application.
6.5.6. IDP Signature Groups Chapter 6. Security Mechanisms In order for IDP to correctly identify an attack, it uses a profile of indicators, or pattern, associated with different types of attack. These predefined patterns, also known as signatures, are stored in a local NetDefendOS database and are used by the IDP module to analyze traffic for attack patterns. Each IDP signature is designated by a unique number. Consider the following simple attack example involving an exchange with an FTP server.
6.5.6. IDP Signature Groups Chapter 6. Security Mechanisms IDP Signature Groups fall into a three level hierarchical structure. The top level of this hierarchy is the signature Type, the second level the Category and the third level the Sub-Category. The signature group called POLICY_DB_MSSQL illustrates this principle where Policy is the Type, DB is the Category and MSSQL is the Sub-Category. These 3 signature components are explained below: 1.
6.5.7. IDP Actions Chapter 6. Security Mechanisms scanning can make the load on the firewall hardware unnecessarily high, adversely affecting throughput. 6.5.7. IDP Actions Action Options After pattern matching recognizes an intrusion in traffic subject to an IDP Rule, the Action associated with that Rule is taken. The administrator can associate one of three Action options with an IDP Rule: • Ignore - Do nothing if an intrusion is detected and allow the connection to stay open.
6.5.8. SMTP Log Receiver for IDP Events Chapter 6. Security Mechanisms wait 600 seconds (equivalent to 10 minutes) before sending a new email. An SMTP server is assumed to have been configured in the address book with the name smtp-server. CLI Adding an SMTP log receiver: gw-world:/> add LogReceiver LogReceiverSMTP smt4IDP IPAddress=smtp-server Receiver1=youremail@yourcompany.
6.5.8. SMTP Log Receiver for IDP Events Chapter 6. Security Mechanisms An IDP rule called IDPMailSrvRule will be created, and the Service to use is the SMTP service. Source Interface and Source Network defines where traffic is coming from, in this example the external network. The Destination Interface and Destination Network define where traffic is directed to, in this case the mail server. Destination Network should therefore be set to the object defining the mail server.
6.5.8. SMTP Log Receiver for IDP Events Chapter 6. Security Mechanisms Specify the Action: An action is now defined, specifying what signatures the IDP should use when scanning data matching the rule, and what NetDefendOS should do when a possible intrusion is detected. In this example, intrusion attempts will cause the connection to be dropped, so Action is set to Protect.
6.6. Denial-of-Service Attack Prevention Chapter 6. Security Mechanisms 6.6. Denial-of-Service Attack Prevention 6.6.1. Overview By embracing the Internet, enterprises experience new business opportunities and growth. The enterprise network and the applications that run over it are business critical. Not only can a company reach a larger number of customers via the Internet, it can serve them faster and more efficiently.
6.6.4. Fragmentation overlap attacks: Teardrop, Bonk, Boink and Nestea Chapter 6. Security Mechanisms intended victim. "Jolt" is simply a purpose-written program for generating such packets on operating systems whose ping commands refuse to generate oversized packets. The triggering factor is that the last fragment makes the total packet size exceed 65535 bytes, which is the highest number that a 16-bit integer can store. When the value overflows, it jumps back to a very small number.
6.6.7. Amplification attacks: Smurf, Papasmurf, Fraggle • Chapter 6. Security Mechanisms By stripping the URG bit by default from all TCP segments traversing the system (configurable via Advanced Settings > TCP > TCPUrg). WinNuke attacks will usually show up in NetDefendOS logs as normal drops with the name of the rule in your policy that disallowed the connection attempt.
6.6.9. The Jolt2 Attack Chapter 6. Security Mechanisms 6.6.8. TCP SYN Flood Attacks The TCP SYN Flood attack works by sending large amounts of TCP SYN packets to a given port and then not responding to SYN ACKs sent in response. This will tie up local TCP stack resources on the victim machine until it is unable to respond to more SYN packets until the existing half-open connections have timed out.
6.7. Blacklisting Hosts and Networks Chapter 6. Security Mechanisms 6.7. Blacklisting Hosts and Networks Overview NetDefendOS implements a Blacklist of host or network IP addresses which can be utilized to protect against traffic coming from specific Internet sources. Certain NetDefendOS subsystems have the ability to optionally blacklist a host or network when certain conditions are encountered. These subsystems are: • Intrusion Detection and Prevention (IDP). • Threshold Rules.
6.7. Blacklisting Hosts and Networks Chapter 6. Security Mechanisms blacklisted, it still does not prevent NetDefendOS mechanisms such as Threshold Rules from dropping or denying connections from that source. What whitelisting does is prevent a source being added to a blacklist if that is the action a rule has specified. For further details on usage see Section 6.5.7, “IDP Actions”, Section 10.3.8, “Threshold Rule Blacklisting” and Section 10.3, “Threshold Rules”.
6.7. Blacklisting Hosts and Networks Chapter 6.
Chapter 7. Address Translation This chapter describes NetDefendOS address translation capabilities. • NAT, page 292 • NAT Pools, page 297 • SAT, page 300 The ability of NetDefendOS to change the IP address of packets as they pass through the NetDefend Firewall is known as address translation. The ability to transform one IP address to another can have many benefits.
7.1. NAT Chapter 7. Address Translation NAT provides many-to-one translation. This means that each NAT rule in the IP rule set will translate between several source IP addresses and a single source IP address. To maintain session state information, each connection from dynamically translated addresses uses a unique port number and IP address combination as its sender. NetDefendOS performs automatic translation of the source port number as well as the IP address.
7.1. NAT Chapter 7. Address Translation many NAT pools and a single pool can be used in more than one NAT rule. This topic is discussed further in Section 7.2, “NAT Pools”. Applying NAT Translation The following illustrates how NAT is applied in practice on a new connection: 1. The sender, for example 192.168.1.5, sends a packet from a dynamically assigned port, for instance, port 1038, to a server, for example 195.55.66.77 port 80. 192.168.1.5:1038 => 195.55.66.77:80 2.
7.1. NAT Chapter 7. Address Translation 1. Go to Rules > IP Rules > Add > IPRule 2. Specify a suitable name for the rule, for example NAT_HTTP 3. Now enter: • Action: NAT • Service: http • Source Interface: lan • Source Network: lannet • Destination Interface: any • Destination Network: all-nets 4. Under the NAT tab, make sure that the Use Interface Address option is selected 5.
7.1. NAT Chapter 7. Address Translation We shall examine the typical case where the NetDefend Firewall acts as a PPTP server and terminates the PPTP tunnel for PPTP clients. Clients that wish to be anonymous, communicate with their local ISP using PPTP. The traffic is directed to the anonymizing service provider where a NetDefend Firewall is installed to act as the PPTP server for the client, terminating the PPTP tunnel. This arrangement is illustrated in the diagram below. Figure 7.2.
7.2. NAT Pools Chapter 7. Address Translation 7.2. NAT Pools Overview As discussed in Section 7.1, “NAT”, NAT provides a way to have multiple internal clients and hosts with unique private internal IP addresses communicate to remote hosts through a single external public IP address. When multiple public external IP addresses are available then a NAT Pool object can be used to allocate new connections across these public IP addresses.
7.2. NAT Pools Chapter 7. Address Translation Stateless NAT Pools The Stateless option means that no state table is maintained and the external IP address chosen for each new connection is the one that has the least connections already allocated to it. This means two connections between one internal host to the same external host may use two different external IP addresses.
7.2. NAT Pools Chapter 7. Address Translation Web Interface A. First create an object in the address book for the address range: 1. Go to Objects > Address Book > Add > IP address 2. Specify a suitable name for the IP range nat_pool_range 3. Enter 10.6.13.10-10.16.13.15 in the IP Address textbox (a network such as 10.6.13.0/24 could be used here - the 0 and 255 addresses will be automatically removed) 4. Click OK B. Next create a stateful NAT Pool object called stateful_natpool : 1.
7.3. SAT Chapter 7. Address Translation 7.3. SAT NetDefendOS can translate entire ranges of IP addresses and/or ports. Such translations are transpositions, each address or port is mapped to a corresponding address or port in the new range, rather than translating them all to the same address or port. In NetDefendOS this functionality is known as Static Address Translation (SAT). Note: Port forwarding Some network equipment vendors use the term "port forwarding" when referring to SAT.
7.3.1. Translation of a Single IP Address (1:1) Chapter 7. Address Translation DestinationNetwork=wan_ip SATTranslate=DestinationIP SATTranslateToIP=10.10.10.5 Name=SAT_HTTP_To_DMZ Then create a corresponding Allow rule: gw-world:/main> add IPRule action=Allow Service=http SourceInterface=any SourceNetwork=all-nets DestinationInterface=core DestinationNetwork=wan_ip Name=Allow_HTTP_To_DMZ Web Interface First create a SAT rule: 1. Go to Rules > IP Rules > Add > IPRule 2.
7.3.1. Translation of a Single IP Address (1:1) Chapter 7. Address Translation hide: # Action Src Iface Src Net Dest Iface Dest Net Parameters 3 NAT lannet any all-nets All lan Now, what is wrong with this rule set? If we assume that we want to implement address translation for reasons of security as well as functionality, we discover that this rule set makes our internal addresses visible to machines in the DMZ.
7.3.1. Translation of a Single IP Address (1:1) Chapter 7. Address Translation # Action Src Iface Src Net Dest Iface Dest Net Parameters 1 SAT any all-nets core wan_ip http SETDEST wwwsrv 80 2 Allow any all-nets core wan_ip http These two rules allow us to access the web server via the NetDefend Firewall's external IP address. Rule 1 states that address translation can take place if the connection has been permitted, and rule 2 permits the connection.
7.3.2. Translation of Multiple IP Addresses (M:N) Chapter 7. Address Translation In this way, the reply arrives at PC1 from the expected address. Another possible solution to this problem is to allow internal clients to speak directly to 10.0.0.2 and this would completely avoid all the problems associated with address translation. However, this is not always practical. 7.3.2. Translation of Multiple IP Addresses (M:N) A single SAT rule can be used to translate an entire range of IP addresses.
7.3.2. Translation of Multiple IP Addresses (M:N) Chapter 7. Address Translation gw-world:/> add Address IP4Address wwwsrv_priv_base Address=10.10.10.5 Publish the public IP addresses on the wan interface using ARP publish. One ARP item is needed for every IP address: gw-world:/> add ARP Interface=wan IP=195.55.66.77 mode=Publish Repeat this for all the five public IP addresses.
7.3.3. All-to-One Mappings (N:1) Chapter 7. Address Translation • Servce: http • Source Interface:any • Source Network: all-nets • Destination Interface: wan • Destination Network: wwwsrv_pub 4. Switch to the SAT tab 5. Make sure that the Destination IP Address option is selected 6. In the New IP Address dropdown list, select wwwsrv_priv 7. Click OK Finally, create a corresponding Allow rule: 1. Go to Rules > IP Rules > Add > IPRule 2.
7.3.5. Protocols Handled by SAT Chapter 7. Address Translation # Action Src Iface Src Net Dest Iface Dest Net Parameters 1 SAT all-nets wan wwwsrv_pub TCP 80-85 SETDEST 192.168.0.50 1080 any This rule produces a 1:1 translation of all ports in the range 80 - 85 to the range 1080 - 1085. • Attempts to communicate with the web servers public address - port 80, will result in a connection to the web servers private address - port 1080.
7.3.7. SAT and FwdFast Rules Chapter 7. Address Translation if anyone tries to connect to the public address of the web server, the destination address will be changed to its private address.
7.3.7. SAT and FwdFast Rules • Chapter 7. Address Translation Return traffic from wwwsrv:80 will match rules 2 and 3. The replies will therefore be dynamically address translated. This changes the source port to a completely different port, which will not work.
7.3.7. SAT and FwdFast Rules Chapter 7.
Chapter 8. User Authentication This chapter describes how NetDefendOS implements user authentication. • Overview, page 311 • Authentication Setup, page 313 • Customizing HTML Pages, page 325 8.1. Overview In situations where individual users connect to protected resources through the NetDefend Firewall, the administrator will often require that each user goes through a process of authentication before access is allowed.
8.1. Overview • Chapter 8. User Authentication Changed on a regular basis such as every three months.
8.2. Authentication Setup Chapter 8. User Authentication 8.2. Authentication Setup 8.2.1. Setup Summary The following list summarizes the steps for User Authentication setup with NetDefendOS: • Set up a database of users, each with a username/password combination. This can exist locally in a NetDefendOS User DB object, or remotely on a RADIUS server and will be designated as the Authentication Source. Membership of an Authentication Group can optionally be specified for each user.
8.2.4. External LDAP Servers Chapter 8. User Authentication RADIUS with NetDefendOS NetDefendOS acts as a RADIUS client, sending user credentials and connection parameter information as a RADIUS message to a nominated RADIUS server. The server processes the requests and sends back a RADIUS message to accept or deny them. One or more external servers can be defined in NetDefendOS. RADIUS Security To provide security, a common shared secret is configured on both the RADIUS client and the server.
8.2.4. External LDAP Servers Chapter 8. User Authentication unreachable. The default value for this setting is 5. • Name Attribute The name of the field in the LDAP server containing the username. The default value is uid. This should be set to samaccountname if using Active Directory. • Retrieve Group Membership If this option is enabled, group memberships will be received from the database. The Membership Attribute field is enabled if the box is checked.
8.2.4. External LDAP Servers Chapter 8. User Authentication LDAP server authentication is automatically configured to work using LDAP Bind Request Authentication. This means that authentication succeeds if successful connection is made to the LDAP server. Individual clients are not distinguished from one another. LDAP server referrals should not occur with bind request authentication but if they do, the server sending the referral will be regarded as not having responded. B.
8.2.4. External LDAP Servers Chapter 8. User Authentication command: gw-world:/> show LDAPDatabase The entire contents of the database can be displayed with the command: gw-world:/> show LDAPDatabase LDAP Authentication and PPP When using a PPP based client for PPTP or L2TP access, special consideration has to be taken if LDAP authentication is to succeed with CHAP, MS-CHAPv1 or MS-CHAPv2. A.
8.2.5. Authentication Rules Chapter 8. User Authentication compare with the digest sent by the client. A successful digest match then results in successful authentication. The essential difference with the normal event sequence in A above is that it is the NetDefend Firewall itself which is performing the authentication. Figure 8.2. LDAP for PPP with CHAP, MS-CHAPv1 or MS-CHAPv2 When setting up this scenario, the administrator needs to take note of the following issues: 1.
8.2.6. Authentication Processing Chapter 8. User Authentication • The Local database defined within NetDefendOS. • A RADIUS server (discussed below). • An external LDAP server database (discussed below). A further option, Disallow, can be used so that a negative rule can be created which says "never authenticate given these conditions". This option might be used, for instance, to never authenticate connections coming in on a particular interface.
8.2.7. HTTP Authentication Chapter 8. User Authentication 8.2.6. Authentication Processing The list below describes the processing flow through NetDefendOS for username/password authentication: 1. A user creates a new connection to the NetDefend Firewall. 2.
8.2.7. HTTP Authentication Chapter 8. User Authentication Options. These are: • Login Type - This can be one of: • FORM - The user is presented with an HTML page for authentication which is filled in and the data sent back to NetDefendOS with a POST. • BASICAUTH - This sends a 401 - Authentication Required message back to the browser which will cause it to use its own inbuilt dialog to ask the user for a username/password combination.
8.2.7. HTTP Authentication Chapter 8. User Authentication The SAT rule catches all unauthenticated requests and must be set up with an all-to-one address mapping that directs them to the address 127.0.0.1 which corresponds to core (NetDefendOS itself).
8.2.7. HTTP Authentication Chapter 8. User Authentication Example 8.1. Creating an Authentication User Group In the example of an authentication address object in the Address Book, a user group "users" is used to enable user authentication on "lannet". This example shows how to configure the user group in the NetDefendOS database. Web Interface Step A 1. Go to User Authentication > Local User Databases > Add > LocalUserDatabase 2. Now enter: 3.
8.2.7. HTTP Authentication • 3. Chapter 8. User Authentication Destination Network lan_ip Click OK B. Set up the Authentication Rule 1. Go to User Authentication > User Authentication Rules > Add > User Authentication Rule 2. Now enter: • Name: HTTPLogin • Agent: HTTP • Authentication Source: Local • Interface: lan • Originator IP: lannet 3. For Local User DB choose lannet_auth_users 4. For Login Type choose HTMLForm 5. Click OK C.
8.3. Customizing HTML Pages 3. Chapter 8. User Authentication f. Shared Secret: Enter a text string here for basic encryption of the RADIUS messages g. Confirm Secret: Retype the string to confirm the one typed above Click OK 8.3. Customizing HTML Pages User Authentication makes use of a set of HTML files to present information to the user during the authentication process.
8.3. Customizing HTML Pages Chapter 8. User Authentication • %IPADDR% - The IP address which is being browsed from. • %REASON% - The reason that access was denied. • - The web page URL for redirects. The %REDIRURL% Parameter In certain banner web pages, the parameter %REDIRURL% appears. This is a placeholder for the original URL which was requested before the user login screen appeared for an unauthenticated user.
8.3. Customizing HTML Pages 2. Chapter 8. User Authentication A new Auth Banner Files object must exist which the edited file(s) is uploaded to. If the object is called ua_html, the CLI command to create this object is: gw-world:/> add HTTPAuthBanners ua_html This creates an object which contains a copy of all the Default user auth banner files. 3. The modified file is then uploaded using SCP. It is uploaded to the object type HTTPAuthBanner and the object ua_html with property name FormLogin.
8.3. Customizing HTML Pages Chapter 8.
Chapter 9. VPN This chapter describes the Virtual Private Network (VPN) functionality in NetDefendOS. • Overview, page 329 • VPN Quick Start, page 333 • IPsec Components, page 343 • IPsec Tunnels, page 357 • PPTP/L2TP, page 375 • CA Server Access, page 383 • VPN Troubleshooting, page 386 9.1. Overview 9.1.1. VPN Usage The Internet is increasingly used as a means to connect together computers since it offers efficient and inexpensive communication.
9.1.2. VPN Encryption 2. Chapter 9. VPN Client to LAN connection - Where many remote clients need to connect to an internal network over the Internet. In this case, the internal network is protected by the NetDefend Firewall to which the client connects and the VPN tunnel is set up between them. 9.1.2. VPN Encryption Encryption of VPN traffic is done using the science of cryptography.
9.1.4. Key Distribution Chapter 9. VPN • Restricting access through the VPN to needed services only, since mobile computers are vulnerable. • Creating DMZs for services that need to be shared with other companies through VPNs. • Adapting VPN access policies for different groups of users. • Creating key distribution policies.
9.1.5. The TLS Alternative for VPN Chapter 9. VPN “The TLS ALG”.
9.2. VPN Quick Start Chapter 9. VPN 9.2. VPN Quick Start Overview Later sections in this chapter will explore VPN components in detail. To help put those later sections in context, this section is a quick start summary of the steps needed for VPN setup. It outlines the individual steps in setting up VPNs for the most common scenarios.
9.2.1. IPsec LAN to LAN with Pre-shared Keys Chapter 9. VPN 9.2.1. IPsec LAN to LAN with Pre-shared Keys 1. Create a Pre-shared Key object. 2. Optionally create a new IKE Algorithms object and/or an IPsec Algorithms object if the default algorithm proposal lists do not provide a set of algorithms that are acceptable to the tunnel remote end point. This will depend on the capabilities of the device at the other end of the VPN tunnel. 3. In the Address Book create IP objects for: 4.
9.2.2. IPsec LAN to LAN with Certificates Chapter 9. VPN Action Src Interface Src Network Dest Interface Dest Network Service Allow ipsec_tunnel remote_net lan lannet All The Service used in these rules is All but it could be a predefined service. 6. Define a new NetDefendOS Route which specifies that the VPN Tunnel ipsec_tunnel is the Interface to use for routing packets bound for the remote network at the other end of the tunnel.
9.2.3. IPsec Roaming Clients with Pre-shared Keys Chapter 9. VPN considered adequate. Two self-signed certificates are required and the same two are used at either end of the tunnel but their usage is reversed. In other words: one certificate is used as the root certificate at one end, call it Side A, and as the host certificate at the other end, call it Side B. The second certificate is used in the opposite way: as the host certificate at Side A and the root certificate at Side B.
9.2.3. IPsec Roaming Clients with Pre-shared Keys Chapter 9. VPN The Group string for a user can be specified if its group's access is to be restricted to certain source networks. Group can be specified (with the same text string) in the Authentication section of an IP object. If that IP object is then used as the Source Network of a rule in the IP rule set, that rule will only apply to a user if their Group string matches the Group string of the IP object.
9.2.4. IPsec Roaming Clients with Certificates 2. Chapter 9. VPN • Create a Config Mode Pool object (there can only be one associated with a NetDefendOS installation) and in it specify the address range. • Enable the IKE Config Mode option in the IPsec Tunnel object ipsec_tunnel. If client IP addresses are to be retrieved through DHCP: • Create an IP Pool object and in it specify the DHCP server to use.
9.2.5. L2TP Roaming Clients with Pre-Shared Keys Chapter 9. VPN Note: The system time and date should be correct The NetDefendOS date and time should be set correctly since certificates have an expiry date and time. Also review Section 9.6, “CA Server Access”, which describes important considerations for certificate validation. 9.2.5. L2TP Roaming Clients with Pre-Shared Keys Due to the inbuilt L2TP client in Microsoft Windows, L2TP is a popular choice for roaming client VPN scenarios.
9.2.6. L2TP Roaming Clients with Certificates 6. Chapter 9. VPN • Set Outer Interface Filter to ipsec_tunnel. • Set Outer Server IP to ip_ext. • Select the Microsoft Point-to-Point Encryption allowed. Since IPsec encryption is used this can be set to be None only, otherwise double encryption will degrade throughput. • Set IP Pool to l2tp_pool. • Enable Proxy ARP on the int interface to which the internal network is connected.
9.2.7. PPTP Roaming Clients Chapter 9. VPN 2. Load a Gateway Certificate and Root Certificate into NetDefendOS. 3. When setting up the IPsec Tunnel object, specify the certificates to use under Authentication. This is done by: 4. a. Enable the X.509 Certificate option. b. Select the Gateway Certificate. c. Add the Root Certificate to use.
9.2.7. PPTP Roaming Clients 3. Chapter 9. VPN Define a User Authentication Rule, this is almost identical to L2TP: Agent Auth Source Src Network Interface Client Source IP PPP Local all-nets pptp_tunnel all-nets (0.0.0.0/0) 4.
9.3. IPsec Components Chapter 9. VPN 9.3. IPsec Components 9.3.1. Overview Internet Protocol Security (IPsec) is a set of protocols defined by the Internet Engineering Task Force (IETF) to provide IP security at the network layer.
9.3.2. Internet Key Exchange (IKE) Chapter 9. VPN describing the incoming traffic, and the other the outgoing. In cases where ESP and AH are used in conjunction, four SAs will be created. IKE Negotiation The process of negotiating session parameters consists of a number of phases and modes. These are described in detail in the below sections.
9.3.2. Internet Key Exchange (IKE) Chapter 9. VPN However, since we do not want to publish to much of the negotiation in plaintext, we first agree upon a way of protecting the rest of the IKE negotiation. This is done, as described in the previous section, by the initiator sending a proposal-list to the responder.
9.3.2. Internet Key Exchange (IKE) Chapter 9. VPN This way, an eavesdropper will only see encrypted traffic going from one of VPN endpoint to another. In transport mode, the traffic will not be tunneled, and is hence not applicable to VPN tunnels. It can be used to secure a connection from a VPN client directly to the NetDefend Firewall, for example for IPsec protected remote configuration. This setting will typically be set to "tunnel" in most configurations.
9.3.2. Internet Key Exchange (IKE) IKE Encryption Chapter 9. VPN This specifies the encryption algorithm used in the IKE negotiation, and depending on the algorithm, the size of the encryption key used. The algorithms supported by NetDefendOS IPsec are: • AES • Blowfish • Twofish • Cast128 • 3DES • DES DES is only included to be interoperable with other older VPN implementations.
9.3.2. Internet Key Exchange (IKE) Chapter 9. VPN PFS DH Group This specifies the Diffie-Hellman group to use with PFS. The available DH groups are discussed below. IPsec DH Group This specifies the Diffie-Hellman group to use for IPsec communication. The available DH groups are discussed below in the section titled Diffie-Hellman Groups. IPsec Encryption The encryption algorithm that will be used on the protected IPsec traffic.
9.3.3. IKE Authentication Chapter 9. VPN by NetDefendOS are as follows: • DH group 1 (768-bit) • DH group 2 (1024-bit) • DH group 5 (1536-bit) All these HA groups are available for use with IKE, IPsec and PFS. 9.3.3. IKE Authentication Manual Keying The "simplest" way of configuring a VPN is by using a method called manual keying.
9.3.4. IPsec Protocols (ESP/AH) Chapter 9. VPN One thing that has to be considered when using Pre-Shared Keys is key distribution. How are the Pre-Shared Keys distributed to remote VPN clients and firewalls? This is a major issue, since the security of a PSK system is based on the PSKs being secret. Should one PSK be compromised, the configuration will need to be changed to use a new PSK. Certificates Each VPN firewall has its own certificate, and one or more trusted root certificates.
9.3.5. NAT Traversal Chapter 9. VPN AH uses a cryptographic hash function to produce a MAC from the data in the IP packet. This MAC is then transmitted with the packet, allowing the remote endpoint to verify the integrity of the original IP packet, making sure the data has not been tampered with on its way through the Internet. Apart from the IP packet data, AH also authenticates parts of the IP header. The AH protocol inserts an AH header after the original IP header.
9.3.6. Algorithm Proposal Lists Chapter 9. VPN Achieving NAT Detection To achieve NAT detection both IPsec peers send hashes of their own IP addresses along with the source UDP port used in the IKE negotiations. This information is used to see whether the IP address and source port each peer uses is the same as what the other peer sees. If the source address and port have not changed, then the traffic has not been NATed along the way, and NAT traversal is not necessary.
9.3.7. Pre-shared Keys Chapter 9. VPN There are two types of proposal lists, IKE proposal lists and IPsec proposal lists. IKE lists are used during IKE Phase-1 (IKE Security Negotiation), while IPsec lists are using during IKE Phase-2 (IPsec Security Negotiation). Several algorithm proposal lists are already defined by default in NetDefendOS for different VPN scenarios and user defined lists can be added.
9.3.8. Identification Lists Chapter 9. VPN 9.3.7. Pre-shared Keys Pre-Shared Keys are used to authenticate VPN tunnels. The keys are secrets that are shared by the communicating parties before communication takes place. To communicate, both parties prove that they know the secret. The security of a shared secret depends on how "good" a passphrase is. Passphrases that are common words are extremely vulnerable to dictionary attacks.
9.3.8. Identification Lists Chapter 9. VPN 9.3.8. Identification Lists When certificates are used as authentication method for IPsec tunnels, the NetDefend Firewall will accept all remote devices or VPN clients that are capable of presenting a certificate signed by any of the trusted Certificate Authorities. This can be a potential problem, especially when using roaming clients.
9.3.8. Identification Lists Chapter 9. VPN 1. Go to Objects > VPN Objects > ID List > Add > ID List 2. Enter a name for the list, for example MyIDList 3. Click OK Then, create an ID: 1. Go to Objects > VPN Objects > IKE ID List > Add > ID List 2. Select MyIDList 3. Enter a name for the ID, for example JohnDoe 4. Select Distinguished name in the Type control 5. Now enter: 6.
9.4. IPsec Tunnels Chapter 9. VPN 9.4. IPsec Tunnels 9.4.1. Overview An IPsec Tunnel defines an endpoint of an encrypted tunnel. Each IPsec Tunnel is interpreted as a logical interface by NetDefendOS, with the same filtering, traffic shaping and configuration capabilities as regular interfaces.
9.4.2. LAN to LAN Tunnels with Pre-shared Keys Chapter 9. VPN IPsec Tunnel Quick Start This section covers IPsec tunnels in some detail. A quick start checklist of setup steps for these protocols in typical scenarios can be found in the following sections: • Section 9.2.1, “IPsec LAN to LAN with Pre-shared Keys”. • Section 9.2.2, “IPsec LAN to LAN with Certificates”. • Section 9.2.3, “IPsec Roaming Clients with Pre-shared Keys”. • Section 9.2.4, “IPsec Roaming Clients with Certificates”.
9.4.3. Roaming Clients Chapter 9. VPN the algorithm proposal lists that are pre-configured in NetDefendOS. 9.4.3.1. PSK based client tunnels Example 9.4. Setting up a PSK based VPN tunnel for roaming clients This example describes how to configure an IPsec tunnel at the head office NetDefend Firewall for roaming clients that connect to the office to gain remote access. The head office network uses the 10.0.1.0/24 network span with external firewall IP wan_ip. Web Interface A.
9.4.3. Roaming Clients Chapter 9. VPN clients that connect to the office to gain remote access. The head office network uses the 10.0.1.0/24 network span with external firewall IP wan_ip. Web Interface A. Create a Self-signed Certificate for IPsec authentication: The step to actually create self-signed certificates is performed outside the WebUI using a suitable software product. The certificate should be in the PEM (Privacy Enhanced Mail) file format. B. Upload all the client self-signed certificates: 1.
9.4.3. Roaming Clients Chapter 9. VPN E. Finally configure the IP rule set to allow traffic inside the tunnel. 9.4.3.3. Tunnels Based on CA Server Certificates Setting up client tunnels using a CA issued certificate is largely the same as using Self-signed certificates with the exception of a couple of steps. Most importantly, it is the responsibility of the administrator to acquire the appropriate certificate from an issuing authority.
9.4.3. Roaming Clients • 3. 4. 5. Encapsulation Mode: Tunnel For Algorithms enter: • IKE Algorithms: Medium or High • IPsec Algorithms: Medium or High For Authentication enter: • Choose X.
9.4.4. Fetching CRLs from an alternate LDAP server Chapter 9. VPN Example 9.7. Setting Up Config Mode In this example, the Config Mode Pool object is enabled by associating with it an already configured IP Pool object called ip_pool1. Web Interface 1. Go to Objects > VPN Objects > IKE Config Mode Pool 2. The Config Mode Pool object properties web page now appears 3. Select Use a predefined IPPool object 4. Choose the ip_pool1 object from the IP Pool drop-down list 5.
9.4.5. Troubleshooting with ikesnoop Chapter 9. VPN This example shows how to manually setup and specify an LDAP server. CLI gw-world:/> add LDAPServer Host=192.168.101.146 Username=myusername Password=mypassword Port=389 Web Interface 1. Go to Objects > VPN Objects > LDAP > Add > LDAP Server 2. Now enter: 3. • IP Address: 192.168.101.146 • Username: myusername • Password: mypassword • Confirm Password: mypassword • Port: 389 Click OK 9.4.5.
9.4.5. Troubleshooting with ikesnoop Chapter 9. VPN Complete ikesnoop command options can be found in the CLI Reference Guide. The Client and the Server The two parties involved in the tunnel negotiation are referred to in this section as the client and server. In this context, the word "client" is used to refer to the device which is the initiator of the negotiation and the server refers to the device which is the responder. Step 1.
9.4.5. Troubleshooting with ikesnoop Chapter 9. VPN Life type : Kilobytes Life duration : 50000 Transform 4/4 Transform ID : IKE Encryption algorithm : 3DES-cbc Hash algorithm : SHA Authentication method : Pre-Shared Key Group description : MODP 1024 Life type : Seconds Life duration : 43200 Life type : Kilobytes Life duration : 50000 VID (Vendor ID) Payload data length : 16 bytes Vendor ID : 8f 9c c9 4e 01 24 8e cd f1 47 59 4c 28 4b 21 Description : SSH Communications Security QuickSec 2.1.
9.4.5. Troubleshooting with ikesnoop Chapter 9. VPN IkeSnoop: Sending IKE packet to 192.168.0.10:500 Exchange type : Identity Protection (main mode) ISAKMP Version : 1.
9.4.5. Troubleshooting with ikesnoop Chapter 9. VPN Packet length : 220 bytes # payloads : 4 Payloads: KE (Key Exchange) Payload data length : 128 bytes NONCE (Nonce) Payload data length : 16 bytes NAT-D (NAT Detection) Payload data length : 16 bytes NAT-D (NAT Detection) Payload data length : 16 bytes Step 4. Server Sends Key Exchange Data The Server now sends key exchange data back to the client. IkeSnoop: Sending IKE packet to 192.168.0.
9.4.5. Troubleshooting with ikesnoop Chapter 9. VPN Explanation of Above Values Flags: E means encryption (it is the only flag used). ID: Identification of the client The Notification field is given as Initial Contact to indicate this is not a re-key. Step 6. Server ID Response The server now responds with its own ID. IkeSnoop: Sending IKE packet to 192.168.0.10:500 Exchange type : Identity Protection (main mode) ISAKMP Version : 1.
9.4.5. Troubleshooting with ikesnoop Chapter 9.
9.4.6. IPsec Advanced Settings Chapter 9.
9.4.6. IPsec Advanced Settings Chapter 9. VPN Tunnels if the latter is changed. This linkage is broken once IPsec Max Rules is altered manually so that subsequent changes to IPsec Max Tunnels will not cause an automatic change in IPsec Max Rules. Default: 4 times the license limit of IPsec Max Tunnels IPsec Max Tunnels Specifies the total number of tunnels allowed by NetDefendOS.
9.4.6. IPsec Advanced Settings Chapter 9. VPN When the signature of a user certificate is verified, NetDefendOS looks at the issuer name field in the user certificate to find the CA certificate the certificate was signed by. The CA certificate may in turn be signed by another CA, which may be signed by another CA, and so on. Each certificate will be verified until one that has been marked as "trusted" is found, or until it is determined that none of the certificates are trusted.
9.4.6. IPsec Advanced Settings Chapter 9. VPN This setting is used with IKEv1 only. Default: 2 (in other words, 2 x 10 = 20 seconds) DPD Expire Time The length of time in seconds for which DPD messages will be sent to the peer. If the peer has not responded to messages during this time it is considered to be dead. In other words, the length of time in seconds for which DPD-R-U-THERE messages will be sent.
9.5. PPTP/L2TP Chapter 9. VPN 9.5. PPTP/L2TP The access by a client using a modem link over dial-up public switched networks, possibly with an unpredictable IP address, to protected networks via a VPN poses particular problems. Both the PPTP and L2TP protocols provide two different means of achieving VPN access from remote clients.
9.5.2. L2TP Servers Chapter 9. VPN TCP port 1723 and/or IP protocol 47 before the PPTP connection can be made to the NetDefend Firewall. Examining the log can indicate if this problem occurred, with a log message of the following form appearing: Error PPP lcp_negotiation_stalled ppp_terminated Example 9.10. Setting up a PPTP server This example shows how to setup a PPTP Network Server. The example assumes that you have already created certain address objects in the Address Book.
9.5.2. L2TP Servers Chapter 9. VPN This example shows how to setup a L2TP Network Server. The example assumes that you have created some address objects in the Address Book. You will have to specify the IP address of the L2TP server interface, an outer IP address (that the L2TP server should listen to) and an IP pool that the L2TP server will use to give out IP addresses to the clients from.
9.5.2. L2TP Servers 5. • Username: testuser • Password: mypassword • Confirm Password: mypassword Chapter 9. VPN Click OK Now we will setup the IPsec Tunnel, which will later be used in the L2TP section. As we are going to use L2TP, the Local Network is the same IP as the IP that the L2TP tunnel will connect to, wan_ip. Furthermore, the IPsec tunnel needs to be configured to dynamically add routes to the remote network when the tunnel is established. B.
9.5.2. L2TP Servers Chapter 9. VPN Web Interface 1. Go to Interfaces > L2TP Servers > Add > L2TPServer 2. Enter a name for the L2TP tunnel, for example l2tp_tunnel 3. Now enter: • Inner IP Address: lan_ip • Tunnel Protocol: L2TP • Outer Interface Filter: l2tp_ipsec • Server IP: wan_ip 4. Under the PPP Parameters tab, check the Use User Authentication Rules control 5. Select l2tp_pool in the IP Pool control 6. Under the Add Route tab, select all-nets in the Allowed Networks control 7.
9.5.3. L2TP/PPTP Server advanced settings Chapter 9. VPN DestinationInterface=any DestinationNetwork=all-nets name=AllowL2TP gw-world:/main> add IPRule action=NAT Service=all_services SourceInterface=l2tp_tunnel SourceNetwork=l2tp_pool DestinationInterface=any DestinationNetwork=all-nets name=NATL2TP Web Interface 1. Go to Rules > IP Rules > Add > IPRule 2. Enter a name for the rule, for example AllowL2TP 3.
9.5.4. PPTP/L2TP Clients Chapter 9. VPN Max PPP Resends The maximum number of PPP layer resends. Default: 10 9.5.4. PPTP/L2TP Clients The PPTP and L2TP protocols are described in the previous section. In addition to being able to act as a PPTP or L2TP server, NetDefendOS also offers the ability to act as a PPTP or L2TP clients. This can be useful if PPTP or L2TP is preferred as the VPN protocol instead of IPsec.
9.5.4. PPTP/L2TP Clients Chapter 9. VPN If Dial On Demand is enabled then the PPTP/L2TP tunnel will not be set up until traffic is sent on the interface. The parameters for this option are: • Activity Sense - Specifies if dial-on-demand should trigger on Send or Recv or both. • Idle Timeout - The time of inactivity in seconds to wait before disconnection. Using the PPTP Client Feature One usage of the PPTP client feature is shown in the scenario depicted below.
9.6. CA Server Access Chapter 9. VPN 9.6. CA Server Access Overview Where certificates are used, the two sides of a VPN tunnel exchange their certificates during the tunnel setup negotiation and either may then try to validate the received certificate by accessing a CA server. A certificate contains a URL (the CRL Distribution Point) which specifies the validating CA server and server access is performed using an HTTP GET request with an HTTP reply.
9.6. CA Server Access 3. • Chapter 9. VPN The CA server is a commercial server on the public Internet. In this, the simplest case, public DNS servers will resolve the FQDN. The only requirement is that NetDefendOS will need to have at least one public DNS server address configured to resolve the FQDNs in the certificates it receives.
9.6. CA Server Access Chapter 9. VPN As explained previously, the address of the private CA server must be resolvable through public DNS servers for certificate validation requests coming from the public Internet. If the certificate queries are coming only from the NetDefend Firewall and the CA server is on the internal side of the firewall then the IP address of the internal DNS server must be configured in NetDefendOS so that these requests can be resolved.
9.7. VPN Troubleshooting Chapter 9. VPN 9.7. VPN Troubleshooting General Troubleshooting In all types of VPNs some basic troubleshooting checks can be made: • Check that all IP addresses have been specified correctly. • Check that all pre-shared keys and usernames/passwords are correctly entered. • Use ICMP Ping to confirm that the tunnel is working.
Troubleshooting IPsec Tunnels Chapter 9. VPN • Check that the correct certificates have been used. • Check that the certificate .cer and .key files have the same filename. For example, my_cert.key and my_cert.cer. • Check that the certificates have not expired. • Check that the NetDefendOS date and time is set correctly and consider time-zone issues with newly generated certificates (the time of generation may not be the same as the CA server's system time).
Management Interface Failure with VPN Chapter 9. VPN single tunnel by specifying the IP address of the tunnel's endpoint (this is either the IP of the remote endpoint or a client's IP address). The command takes the form: ikesnoop -on -verbose Ikesnoop can be turned off with the command: ikesnoop -off For a more detailed discussion of this topic, see Section 9.4.5, “Troubleshooting with ikesnoop”.
Management Interface Failure with VPN Chapter 9.
Chapter 10. Traffic Management This chapter describes how NetDefendOS can manage network traffic. • Traffic Shaping, page 390 • IDP Traffic Shaping, page 407 • Threshold Rules, page 412 • Server Load Balancing, page 414 10.1. Traffic Shaping 10.1.1. Introduction QoS with TCP/IP A weakness of TCP/IP is the lack of true Quality of Service (QoS) functionality. QoS is the ability to guarantee and limit network bandwidth for certain services and users.
10.1.2. Traffic Shaping in NetDefendOS Chapter 10. Traffic Management Traffic Shaping Objectives Traffic shaping operates by measuring and queuing IP packets with respect to a number of configurable parameters. The objectives are: • Applying bandwidth limits and queuing packets that exceed configured limits, then sending them later when bandwidth demands are lower. • Dropping packets if packet buffers are full.
10.1.2. Traffic Shaping in NetDefendOS Chapter 10. Traffic Management needed in an ISP scenario where individual pipes are allocated to each client. Pipe Rules Pipe Rules make up the Pipe Rule set. Each Rule is defined much like other NetDefendOS policies: by specifying the source/destination interface/network as well as the Service to which the rule is to apply. Once a new connection is permitted by the IP rule set, the Pipe rule set is then checked for any matching rules.
10.1.3. Simple Bandwidth Limiting Chapter 10. Traffic Management It is important to understand that traffic shaping will not work with connection that are established because of a FwdFast rule in the NetDefendOS IP rule set. The reason for this is that traffic shaping is implemented based on the NetDefendOS state engine and a FwdFast IP rule does not set up a connection in the state engine. Packets bypass the state engine and are forwarded to their destination outside the context of a connection.
10.1.4. Limiting Bandwidth in Both Directions Chapter 10. Traffic Management pass through the std-in pipe. CLI gw-world:/> add PipeRule ReturnChain=std-in SourceInterface=lan SourceNetwork=lannet DestinationInterface=wan DestinationNetwork=all-nets Service=all_services name=Outbound Web Interface 1. Go to Traffic Management > Traffic Shaping > Add > Pipe Rule 2. Specify a suitable name for the pipe, for instance outbound 3.
10.1.5. Creating Differentiated Limits with Chains Chapter 10. Traffic Management Example 10.2. Limiting Bandwidth in Both Directions Create a second pipe for outbound traffic: CLI gw-world:/> add Pipe std-out LimitKbpsTotal=2000 Web Interface 1. Go to Traffic Management > Traffic Shaping > Pipes > Add > Pipe 2. Specify a name for the pipe, for example std-out 3. Enter 2000 in Total textbox 4.
10.1.6. Precedences Chapter 10. Traffic Management This is not a bandwidth guarantee for web browsing but it is a 125 kbps bandwidth guarantee for everything except web browsing. For web browsing the normal rules of first-come, first-forwarded will apply when competing for bandwidth. This may mean 125 kbps, but it may also mean much slower speed if the connection is flooded. Setting up pipes in this way only puts limits on the maximum values for certain traffic types.
10.1.6. Precedences Chapter 10. Traffic Management The minimum and maximum precedences define the precedence range that the pipe will handle. If a packet arrives with an already allocated precedence below the minimum then its precedence is changed to the minimum. Similarly, if a packet arrives with an already allocated precedence above the maximum, its precedence is changed to the maximum. For each pipe, separate bandwidth limits may be optionally specified for each precedence level.
10.1.7. Guarantees Chapter 10. Traffic Management pipe's configuration is exceeded. Lower priority packets will be buffered and sent when higher priority traffic uses less than the maximum specified for the pipe. The buffering process is sometimes referred to as "throttling back" since it reduces the flow rate.
10.1.9. Groups Chapter 10. Traffic Management Keep the forward chain of both rules as std-out only. Again, to simplify this example, we concentrate only on inbound traffic, which is the direction that is the most likely to be the first one to fill up in client-oriented setups. Set the return chain of the port 22 rule to ssh-in followed by std-in. Set the return chain of the port 23 rule to telnet-in followed by std-in.
10.1.10. Recommendations Chapter 10. Traffic Management computer A is not the same as port 1024 of computer B and individual connections are identifiable. If grouping by network is chosen, the network size should also be specified (this has the same meaning as the netmask).
10.1.10. Recommendations Chapter 10. Traffic Management knows what its capacity is and the precedence mechanism is totally dependent on this. Pipe limits for VPN Traffic shaping measures the traffic inside VPN tunnels. This is the raw unencrypted data without any protocol overhead so it will be less than the actual VPN traffic.
10.1.11. A Summary of Traffic Shaping Chapter 10. Traffic Management consumed by parties outside of administrator control but sharing the same connection. Troubleshooting For a better understanding of what is happening in a live setup, the console command: pipe -u can be used to display a list of currently active users in each pipe. 10.1.11. A Summary of Traffic Shaping NetDefendOS traffic shaping provides a sophisticated set of mechanisms for controlling and prioritising network packets.
10.1.12. More Pipe Examples Chapter 10. Traffic Management The reason for using 2 different pipes in this case, is that these are easier to match to the physical link capacity. This is especially true with asynchronous links such as ADSL.
10.1.12. More Pipe Examples • Chapter 10. Traffic Management Priority 0 - Web plus remaining from other levels To implement this scheme, we can use the in-pipe and out-pipe. We first enter the Pipe Limits for each pipe.
10.1.12. More Pipe Examples Chapter 10. Traffic Management The pipe chaining can be used as a solution to the problem of VPN overhead. A limit which allows for this overhead is placed on the VPN tunnel traffic and non-VPN traffic is inserted into a pipe that matches the speed of the physical link. To do this we first create separate pipes for the outgoing traffic and the incoming traffic. VoIP traffic will be sent over a VPN tunnel that will have a high priority.
10.1.12. More Pipe Examples Chapter 10. Traffic Management If SAT is being used, for example with a web server or ftp server, that traffic also needs to be forced into pipes or it will escape traffic shaping and ruin the planned quality of service. In addition, server traffic is initiated from the outside so the order of pipes needs to be reversed: the forward pipe is the in-pipe and the return pipe is the out-pipe. A simple solution is to put a "catch-all-inbound" rule at the bottom of the pipe rule.
10.2. IDP Traffic Shaping Chapter 10. Traffic Management 10.2. IDP Traffic Shaping 10.2.1. Overview The IDP Traffic Shaping feature is traffic shaping that is performed based on information coming from the NetDefendOS Intrusion Detection and Prevention (IDP) subsystem (for more information on IDP see Section 6.5, “Intrusion Detection and Prevention”). The Problem of Bandwidth Usage A prime use of IDP Traffic Shaping is dealing with the traffic management issues caused by bandwidth hungry applications.
10.2.3. Processing Flow Chapter 10. Traffic Management afterwards when other connections will be opened and subject to traffic shaping. Connections opened after the Time Window has expired will no longer be subject to traffic shaping. A Time Window value of 0 means that only traffic flowing over the initial triggering connection will be subject to traffic shaping. Any associated connections that do not trigger an IDP rule will not be subject to traffic shaping. 5.
10.2.5. A P2P Scenario Chapter 10. Traffic Management Network range but not host X. This tells NetDefendOS that host X is not relevant in making a decision about including new non-IDP-triggering connections in traffic shaping. It may seem counter-intuitive that client B is also included in the Network range but this is done on the assumption that client B is a user whose traffic might also have to be traffic shaped if they become involved in a P2P transfer.
10.2.7. Guaranteeing Instead of Limiting Bandwidth Chapter 10. Traffic Management IDP traffic shaping has a special CLI command associated with it called idppipes and this can examine and manipulate the hosts which are currently subject to traffic shaping. To display all hosts being traffic shaped by IDP Traffic Shaping, the command would be: gw-world:/> idppipes -show Host kbps Tmout ----------- ---- ---192.168.1.1 100 58 A host, in this case with IP address 192.168.1.
10.2.8. Logging Chapter 10. Traffic Management If the administrator wants to guarantee a bandwidth level, say 10 Megabits, for an application then an IDP rule can be set up to trigger for that application with the Pipe action specifying the bandwidth required. The traffic shaping pipes that are then automatically created get the highest priority by default and are therefore guaranteed that bandwidth. 10.2.8.
10.3. Threshold Rules Chapter 10. Traffic Management 10.3. Threshold Rules 10.3.1. Overview The objective of a Threshold Rule is to have a means of detecting abnormal connection activity as well as reacting to it. An example of a cause for such abnormal activity might be an internal host becoming infected with a virus that is making repeated connections to external IP addresses. It might alternatively be some external source trying to open excessive numbers of connections.
10.3.4. Rule Actions • Chapter 10. Traffic Management Network Based - The threshold is applied to all connections matching the rules as a group. 10.3.4. Rule Actions When a Threshold Rule is triggered one of two responses are possible: • Audit - Leave the connection intact but log the event. • Protect - Drop the triggering connection. Logging would be the preferred option if the appropriate triggering value cannot be determined beforehand.
10.4. Server Load Balancing Chapter 10. Traffic Management 10.4. Server Load Balancing 10.4.1. Overview The Server Load Balancing (SLB) feature in NetDefendOS is a powerful tool that can improve the following aspects of network applications: • Performance • Scalability • Reliability • Ease of administration The primary benefit of SLB is to allow the network service load to be shared across multiple servers.
10.4.2. Identifying the Servers Chapter 10. Traffic Management The Additional Benefits of SLB Besides from improving performance and scalability, SLB provides a number of other benefits: • SLB increases the reliability of network applications by actively monitoring the servers sharing the load. SLB can detect when a server fails or becomes congested and will not direct any further requests to that server until it recovers or has less load.
10.4.4. The Distribution Algorithm Chapter 10. Traffic Management to the same host. Network Stickiness This mode is similar to IP stickiness except that by using a subnet mask, a range of hosts in a subnet can be specified. 10.4.4. The Distribution Algorithm There are several ways to determine how a load is shared across a server farm. NetDefendOS SLB supports the following algorithms: Round Robin The algorithm distributes new incoming connections to a list of servers on a rotating basis.
10.4.5. Server Health Monitoring Chapter 10. Traffic Management When the Round Robin algorithm is used, the first arriving requests R1 and R2 from Client 1 are both assigned to one sever, say Server 1, according to stickiness. The next request R3 from Client 2 is then routed to Server 2. When R4 from Client 3 arrives, Server 1 gets back its turn again and will be assigned with R4. Figure 10.10.
10.4.6. SLB_SAT Rules Chapter 10. Traffic Management 10.4.5. Server Health Monitoring SLB uses Server Health Monitoring to continuously check the condition of the servers in an SLB configuration. SLB can monitor different OSI layers to check the condition of each server. Regardless of the algorithms used, if a server is deemed to have failed, SLB will not open any more connections to it until the server is restored to full functionality.
10.4.6. SLB_SAT Rules Rule Name Chapter 10. Traffic Management Rule Type WEB_SLB_ALW Allow Src. Interface Src. Network Dest. Interface Dest. Network any all-nets core ip_ext Note that the destination interface is specified as core, meaning NetDefendOS itself deals with this. The key advantage of having a separate Allow rule is that the webservers can log the exact IP address that is generating external requests.
10.4.6. SLB_SAT Rules Chapter 10. Traffic Management 1. Go to Rules > IP Rule Sets > main > Add > IP Rule 2. Enter: 3. • Name: Web_SLB_NAT • Action: NAT • Service: HTTP • Source Interface: lan • Source Network: lannet • Destination Interface: core • Destination Network: ip_ext Click OK E. Specify an Allow IP rule for the external clients: 1. Go to Rules > IP Rule Sets > main > Add > IP Rule 2. Enter: 3.
10.4.6. SLB_SAT Rules Chapter 10.
Chapter 11. High Availability This chapter describes the high availability fault-tolerance feature in NetDefend Firewalls. • Overview, page 422 • HA Mechanisms, page 424 • HA Setup, page 427 • HA Issues, page 431 • HA Advanced Settings, page 432 11.1. Overview HA Clusters NetDefendOS High Availability (HA) provides a fault tolerant capability to NetDefend Firewall installations. HA works by adding a back-up slave NetDefend Firewall to an existing master firewall.
11.1. Overview Chapter 11. High Availability The heartbeat mechanism is discussed below in more depth in Section 11.2, “HA Mechanisms”. Cluster Management An HA Cluster of two NetDefend Firewalls is managed as a single unit with a unique cluster name which appears in the management interface as a single logical NetDefend Firewall.
11.2. HA Mechanisms Chapter 11. High Availability 11.2. HA Mechanisms This section discusses im more depth the mechanisms NetDefendOS uses to implement the high availability feature. Basic Principles D-Link HA provides a redundant, state-synchronized hardware configuration. The state of the active unit, such as the connection table and other vital information, is continuously copied to the inactive unit via the sync interface.
11.2. HA Mechanisms Chapter 11. High Availability Failover Time The time for failover is typically about one second which means that clients may experience a failover as a slight burst of packet loss. In the case of TCP, the failover time is well within the range of normal retransmit timeouts so TCP will retransmit the lost packets within a very short space of time, and continue communication. UDP does not allow retransmission since it is inherently an unreliable protocol.
11.2. HA Mechanisms Chapter 11. High Availability will lose their synchronization with each other. In other words, the inactive unit will no longer have a correct copy of the state of the active unit. A failover will not occur in this situation since the inactive unit will realize that synchronization has been lost. Failure of the sync interface results in the generation of hasync_connection_failed_timeout log messages by the active unit.
11.3. HA Setup Chapter 11. High Availability 11.3. HA Setup This section provides a step-by-step guide for setting up an HA Cluster. 11.3.1. HA Hardware Setup The steps for the setup of hardware in an HA cluster are as follows: 1. Start with two physically similar NetDefend Firewalls. Both may be newly purchased or an existing unit may have a new unit added to it.
11.3.2. NetDefendOS Manual HA Setup Chapter 11. High Availability Typical HA Cluster Network Connections The illustration below shows the arrangement of typical HA Cluster connections in a network. All interfaces on the master unit would normally also have corresponding interfaces on the slave unit and these would be connected to the same networks. This is achieved by connecting the same interfaces on both master and slave via a separate switch (or broadcast domain) to other network portions.
11.3.3. Verifying the Cluster Functions Chapter 11. High Availability 2. Go to System > High Availability. 3. Check the Enable High Availability checkbox. 4. Set the Cluster ID. This must be unique for each cluster. 5. Choose the Sync Interface. 6. Select the node type to be Master. 7. Go to Objects > Address Book and create an IP4 HA Address object for each interface pair. Each must contain the master and slave interface IP addresses for the pair.
11.3.4. Unique Shared Mac Addresses Chapter 11. High Availability number on the right is the maximum number of connections allowed by the license. The following points are also relevant to cluster setup: • If this is not the first cluster in a network then the Cluster ID must be changed for the cluster so that it is unique (the default value is 0). The Cluster ID determines that the MAC address for the cluster is unique.
11.4. HA Issues Chapter 11. High Availability 11.4. HA Issues The following points should be kept in mind when managing and configuring an HA Cluster. SNMP SNMP statistics are not shared between master and slave. SNMP managers have no failover capabilities. Therefore both firewalls in a cluster need to be polled separately. Using Individual IP Addresses The unique individual IP addresses of the master and slave cannot safely be used for anything but management.
11.5. HA Advanced Settings Chapter 11. High Availability 11.5. HA Advanced Settings The following NetDefendOS advanced settings are available for High Availability: Sync Buffer Size How much sync data, in Kbytes, to buffer while waiting for acknowledgments from the cluster peer. Default: 1024 Sync Packet Max Burst The maximum number of state sync packets to send in a burst. Default: 20 Initial Silence The time in seconds to stay silent on startup or after reconfiguration.
11.5. HA Advanced Settings Chapter 11.
Chapter 12. ZoneDefense This chapter describes the D-Link ZoneDefense feature. • Overview, page 434 • ZoneDefense Switches, page 435 • ZoneDefense Operation, page 436 12.1. Overview ZoneDefense Controls Switches ZoneDefense allows a NetDefend Firewall to control locally attached switches. It can be used as a counter-measure to stop a virus-infected computer in a local network from infecting other computers.
12.2. ZoneDefense Switches Chapter 12. ZoneDefense 12.2. ZoneDefense Switches Switch information regarding every switch that is to be controlled by the firewall has to be manually specified in the firewall configuration. The information needed in order to control a switch includes: • The IP address of the management interface of the switch • The switch model type • The SNMP community string (write access) The ZoneDefense feature currently supports the following switches: • DES-3226S (Version R4.
12.3. ZoneDefense Operation Chapter 12. ZoneDefense 12.3. ZoneDefense Operation 12.3.1. SNMP Simple Network Management Protocol (SNMP) is an application layer protocol for complex network management. SNMP allows the managers and managed devices in a network to communicate with each other. SNMP Managers A typical managing device, such as a NetDefend Firewall, uses the SNMP protocol to monitor and control network devices in the managed environment.
12.3.3. Manual Blocking and Exclude Lists Chapter 12. ZoneDefense As a complement to threshold rules, it is also possible to manually define hosts and networks that are to be statically blocked or excluded. Manually blocked hosts and networks can be blocked by default or based on a schedule. It is also possible to specify which protocols and protocol port numbers are to be blocked. Exclude Lists can be created and used to exclude hosts from being blocked when a threshold rule limit is reached.
12.3.4. ZoneDefense with Anti-Virus Scanning Chapter 12. ZoneDefense 2. For Addresses choose the object name of the firewall's interface address 192.168.1.1 from the Available list and put it into the Selected list. 3. Click OK Configure an HTTP threshold of 10 connections/second: 1. Go to Traffic Management > Threshold Rules > Add > Threshold Rule 2. For the Threshold Rule enter: 3. 4.
12.3.5. Limitations Chapter 12. ZoneDefense of latency time to implement blocking once the rule is triggered. Some models can activate blocking in less than a second while some models may require a minute or more. A second difference is the maximum number of rules supported by different switches. Some switches support a maximum of 50 rules while others support up to 800 (usually, in order to block a host or network, one rule per switch port is needed).
12.3.5. Limitations Chapter 12.
Chapter 13. Advanced Settings This chapter describes the configurable advanced settings for NetDefendOS. The settings are divided up into the following categories: Note: Activating changes After any advanced setting is changed, the new NetDefendOS configuration must be deployed in order for the new value to take effect.
13.1. IP Level Settings Chapter 13. Advanced Settings Block 0.0.0.0 as source address. Default: Drop Block 0 Net Block 0.* as source addresses. Default: DropLog Block 127 Net Block 127.* as source addresses. Default: DropLog Block Multicast Src Block multicast both source addresses (224.0.0.0 - 255.255.255.255). Default: DropLog TTL Min The minimum TTL value accepted on receipt. Default: 3 TTL on Low Determines the action taken on packets whose TTL falls below the stipulated TTLMin value.
13.1. IP Level Settings Chapter 13. Advanced Settings SecuRemoteUDP Compatibility Allow IP data to contain eight bytes more than the UDP total length field specifies. Checkpoint SecuRemote violates NAT-T drafts. Default: Disabled IP Option Sizes Verifies the size of "IP options". These options are small blocks of information that may be added to the end of each IP header.
13.1. IP Level Settings Chapter 13. Advanced Settings IP Reserved Flag Indicates what NetDefendOS will do if there is data in the "reserved" fields of IP headers. In normal circumstances, these fields should read 0. Used by OS Fingerprinting. Default: DropLog Strip DontFragment Strip the Don’t Fragment flag for packets equal to or smaller than the size specified by this setting. Default: 65535 bytes Multicast Mismatch option What action to take when ethernet and IP multicast addresses does not match.
13.2. TCP Level Settings Chapter 13. Advanced Settings 13.2. TCP Level Settings TCP Option Sizes Verifies the size of TCP options. This function acts in the same way as IPOptionSizes described above. Default: ValidateLogBad TCP MSS Min Determines the minimum permissible size of the TCP MSS. Packets containing maximum segment sizes below this limit are handled according to the next setting.
13.2. TCP Level Settings Chapter 13. Advanced Settings TCP Auto Clamping Automatically clamp TCP MSS according to MTU of involved interfaces, in addition to TCPMSSMax. Default: Enabled TCP Zero Unused ACK Determines whether NetDefendOS should set the ACK sequence number field in TCP packets to zero if it is not used. Some operating systems reveal sequence number information this way, which can make it easier for intruders wanting to hijack established connections.
13.2. TCP Level Settings Chapter 13. Advanced Settings initially intended to be used in negotiating for the use of better checksums in TCP. However, these are not understood by any today's standard systems. As NetDefendOS cannot understand checksum algorithms other than the standard algorithm, these options can never be accepted. The ALTCHKREQ option is normally never seen on modern networks. Default: StripLog TCP Option ALTCHKDATA Determines how NetDefendOS will handle alternate checksum data options.
13.2. TCP Level Settings Chapter 13. Advanced Settings TCP SYN/FIN The TCP FIN flag together with SYN; normally invalid (strip=strip FIN). Default: DropLog TCP FIN/URG Specifies how NetDefendOS will deal with TCP packets with both FIN (Finish, close connection) and URG flags turned on. This should normally never occur, as you do not usually attempt to close a connection at the same time as sending "important" data.
13.2. TCP Level Settings Chapter 13. Advanced Settings TCP sequence number validation is only possible on connections tracked by the state-engine (not on packets forwarded using a FwdFast rule). Possible values are: Ignore - Do not validate. Means that sequence number validation is completely turned off. ValidateSilent - Validate and pass on. ValidateLogBad - Validate and pass on, log if bad. ValidateReopen - Validate reopen attempt like normal traffic; validate and pass on.
13.3. ICMP Level Settings Chapter 13. Advanced Settings 13.3. ICMP Level Settings ICMP Sends Per Sec Limit Specifies the maximum number of ICMP messages NetDefendOS may generate per second. This includes ping replies, destination unreachable messages and also TCP RST packets. In other words, this setting limits how many Rejects per second may be generated by the Reject rules in the Rules section.
13.4. State Settings Chapter 13. Advanced Settings 13.4. State Settings Connection Replace Allows new additions to the NetDefendOS connection list to replace the oldest connections if there is no available space. Default: ReplaceLog Log Open Fails In some instances where the Rules section determines that a packet should be allowed through, the stateful inspection mechanism may subsequently decide that the packet cannot open a new connection.
13.4. State Settings Chapter 13. Advanced Settings Default: Log Log Connection Usage This generates a log message for every packet that passes through a connection that is set up in the NetDefendOS state-engine. Traffic whose destination is the NetDefend Firewall itself, for example NetDefendOS management traffic, is not subject to this setting. The log message includes port, service, source/destination IP address and interface.
13.5. Connection Timeout Settings Chapter 13. Advanced Settings 13.5. Connection Timeout Settings The settings in this section specify how long a connection can remain idle, that is to say with no data being sent through it, before it is automatically closed. Please note that each connection has two timeout values: one for each direction. A connection is closed if either of the two values reaches 0.
13.5. Connection Timeout Settings Chapter 13. Advanced Settings Other Idle Lifetime Specifies in seconds how long connections using an unknown protocol can remain idle before it is closed.
13.6. Length Limit Settings Chapter 13. Advanced Settings 13.6. Length Limit Settings This section contains information about the size limits imposed on the protocols directly under IP level, such as TCP, UDP and ICMP. The values specified here concern the IP data contained in packets. In the case of Ethernet, a single packet can contain up to 1480 bytes of IP data without fragmentation.
13.6. Length Limit Settings Chapter 13. Advanced Settings Specifies in bytes the maximum size of an AH packet. AH, Authentication Header, is used by IPsec where only authentication is applied. This value should be set at the size of the largest packet allowed to pass through the VPN connections, regardless of its original protocol, plus approx. 50 bytes. Default: 2000 Max SKIP Length Specifies in bytes the maximum size of a SKIP packet.
13.7. Fragmentation Settings Chapter 13. Advanced Settings 13.7. Fragmentation Settings IP is able to transport up to 65536 bytes of data. However, most media, such as Ethernet, cannot carry such huge packets. To compensate, the IP stack fragments the data to be sent into separate packets, each one given their own IP header and information that will help the recipient reassemble the original packet correctly.
13.7. Fragmentation Settings Chapter 13. Advanced Settings Default: Check8 – compare 8 random locations, a total of 32 bytes Failed Fragment Reassembly Reassemblies may fail due to one of the following causes: • Some of the fragments did not arrive within the time stipulated by the ReassTimeout or ReassTimeLimit settings. This may mean that one or more fragments were lost on their way across the Internet, which is a quite common occurrence.
13.7. Fragmentation Settings Chapter 13. Advanced Settings • NoLog - No logging is carried out under normal circumstances. • LogSuspect - Logs duplicated fragments if the reassembly procedure has been affected by "suspect" fragments. • LogAll - Always logs duplicated fragments. Default: LogSuspect Fragmented ICMP Other than ICMP ECHO (Ping), ICMP messages should not normally be fragmented as they contain so little data that fragmentation should never be necessary.
13.7. Fragmentation Settings Chapter 13. Advanced Settings Reassembly Illegal Limit Once a whole packet has been marked as illegal, NetDefendOS is able to retain this in memory for this number of seconds in order to prevent further fragments of that packet from arriving.
13.8. Local Fragment Reassembly Settings Chapter 13. Advanced Settings 13.8. Local Fragment Reassembly Settings Max Concurrent Maximum number of concurrent local reassemblies. Default: 256 Max Size Maximum size of a locally reassembled packet. Default: 10000 Large Buffers Number of large ( over 2K) local reassembly buffers (of the above size).
13.9. Miscellaneous Settings Chapter 13. Advanced Settings 13.9. Miscellaneous Settings UDP Source Port 0 How to treat UDP packets with source port 0. Default: DropLog Port 0 How to treat TCP/UDP packets with destination port 0 and TCP packets with source port 0. Default: DropLog Watchdog Time Number of non-responsive seconds before watchdog is triggered (0=disable). Default: 180 Flood Reboot Time As a final way out, NetDefendOS automatically reboots if its buffers have been flooded for a long time.
13.9. Miscellaneous Settings Chapter 13.
Appendix A. Subscribing to Security Updates Introduction The NetDefendOS Anti-Virus (AV) module, the Intrusion Detection and Prevention (IDP) module and the Dynamic Web Content Filtering module all function using external D-Link databases which contain details of the latest viruses, security threats and URL categorization. These databases are constantly being updated and to get access to the latest updates a D-Link Security Update Subscription should be taken out.
Database Console Commands Appendix A.
Appendix B. IDP Signature Groups For IDP scanning, the following signature groups are available for selection. These groups are available only for the D-Link Advanced IDP Service. There is a version of each group under the three Types of IDS, IPS and Policy. For further information see Section 6.5, “Intrusion Detection and Prevention”.
Appendix B.
Appendix B.
Appendix B.
Appendix C. Verified MIME filetypes Some NetDefendOS Application Layer Gateways (ALGs) have the optional ability to verify that the contents of a downloaded file matches the type that the filetype in the filename indicates.
Appendix C.
Appendix C.
Appendix C.
Appendix D. The OSI Framework Overview The Open Systems Interconnection Model defines a framework for inter-computer communications. It categorizes different protocols for a great variety of network applications into seven smaller, more manageable layers. The model describes how data from an application in one computer can be transferred through a network medium to an application on another computer.
Appendix E. D-Link Worldwide Offices Below is a complete list of D-Link worldwide sales offices. Please check your own country area's local website for further details regarding support of D-Link products as well as contact details for local support. Australia 1 Giffnock Avenue, North Ryde, NSW 2113, Australia. TEL: 61-2-8899-1800, FAX: 61-2-8899-1868. Website: www.dlink.com.au Belgium Rue des Colonies 11, B-1000 Brussels, Belgium. Tel: +32(0)2 517 7111, Fax: +32(0)2 517 6500. Website: www.dlink.
Appendix E. D-Link Worldwide Offices Italy Via Nino Bonnet n. 6/b, 20154 – Milano, Italy. TEL: 39-02-2900-0676, FAX: 39-02-2900-1723. Website: www.dlink.it LatinAmerica Isidora Goyeechea 2934, Ofcina 702, Las Condes, Santiago – Chile. TEL: 56-2-232-3185, FAX: 56-2-232-0923. Website: www.dlink.cl Luxemburg Rue des Colonies 11, B-1000 Brussels, Belgium TEL: +32 (0)2 517 7111, FAX: +32 (0)2 517 6500. Website: www.dlink.be Middle East (Dubai) P.O.
Alphabetical Index A access rules, 201 accounting, 56 interim messages, 58 limitations with NAT, 59 messages, 56 system shutdowns, 59 address book, 73 ethernet addresses in, 75 folders, 77 IP addresses in, 73 address groups, 76 address translation, 292 admin account, 26 changing password for, 35 multiple logins, 26 advanced settings ARP, 103 connection timeout, 453 DHCP relay, 196 DHCP server, 193 fragmentation, 457 fragment reassembly, 461 general, 441 hardware monitoring, 61 high availability, 432 ICMP, 4
Alphabetical Index Block Multicast Src setting, 442 boot menu (see console boot menu) BOOTP, 195 BPDU relaying, 184 Broadcast Enet Sender setting, 186 C CAM Size setting, 185 CAM To L3 Cache Dest Learning setting, 184 CA servers access, 383 client access, 384 FQDN resolution, 385 certificates, 114 CA authority, 114 certificate requests, 116 identification lists, 355 revocation list, 115 self-signed, 115, 335, 359 validity, 114 with IPsec, 338 VPN troubleshooting, 386 chains (in traffic shaping), 391 CLI,
Alphabetical Index Dynamic L3C Size setting, 185 Dynamic Max Connections setting, 452 dynamic routing policy, 159 DynDNS service, 125 E Enable Sensors setting, 61 end of life procedures, 71 ESMTP extensions, 217 ethernet interface, 85 changing IP addresses, 86 CLI command summary, 88 default gateway, 87 IP address, 86 with DHCP, 87 evasion attack prevention, 277 events, 51 log messages, 51 message distribution, 52 F Failed Fragment Reassembly setting, 458 filetype download block/allow in FTP ALG, 209 in
Alphabetical Index Illegal Fragments setting, 457 Initial Silence (HA) setting, 432 insertion attack prevention, 277 Interface Alias (SNMP) setting, 65 Interface Description (SNMP) setting, 65 interfaces, 84 disabling, 85 groups, 98 loopback, 84, 85 physical, 84 internet key exchange (see IKE) Interval between synchronization setting, 123 intrusion, detection and prevention (see IDP) intrusion detection rule, 276 invalid checksum in cluster heartbeats, 431 IP address objects, 76 IP Option Sizes setting, 44
Alphabetical Index Max TCP Length setting, 455 Max time drift setting, 123 Max Transactions (DHCP) setting, 196 Max UDP Length setting, 455 memlog, 52 MIME filetype verification in FTP ALG, 209 in HTTP ALG, 206 in POP3 ALG, 224 in SMTP ALG, 215 list of filetypes, 470 Min Broadcast TTL setting, 444 Minimum Fragment Length setting, 459 multicast address translation, 165 forwarding, 163 IGMP, 166 routing, 162 Multicast Enet Sender setting, 186 Multicast Mismatch setting, 444 Multicast TTL on Low setting, 442
Alphabetical Index static, 129 the all-nets route, 135 S SA (see security association) SafeStream, 270 SAT, 300 IP rules, 109 multiplex rule, 162 port forwarding, 300 second rule destination, 300 schedules, 112 SCP, 41 scripting (see CLI scripts) Secondary Time Server setting, 123 secure copy (see SCP) SecuRemoteUDP Compatibility setting, 442 secure shell (see SSH) security association, 343 Send Limit setting, 54 serial console (see console) serial console port, 34 server load balancing, 414 connection ra
Alphabetical Index in zonedefense, 436 time synchronization, 119 Time Sync Server Type setting, 123 Time Zone setting, 122 TLS ALG, 248 traffic shaping, 390 bandwidth guarantees, 398 bandwidth limiting, 393 FwdFast IP rule exclusion, 392 groups, 399 objectives, 390 precedences, 396 recommendations, 400 summary, 402 with IDP, 407 Transaction Timeout (DHCP) setting, 196 Transparency ATS Expire setting, 185 Transparency ATS Size setting, 185 transparent mode, 174 advanced settings, 184 and internet access, 17
