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. D-Link makes no
representations or warranties with respect to the contents hereof and specifically disclaims any
implied warranties of merchantability or fitness for a particular purpose. D-Link reserves the right to
revise this publication and to make changes from time to time in the content hereof without any
obligation to notify any person or parties of such revision or changes.
Limitations of Liability
UNDER NO CIRCUMSTANCES SHALL D-LINK OR ITS SUPPLIERS BE LIABLE FOR
DAMAGES OF ANY CHARACTER (E.G. DAMAGES FOR LOSS OF PROFIT, SOFTWARE
RESTORATION, WORK STOPPAGE, LOSS OF SAVED DATA OR ANY OTHER
COMMERCIAL DAMAGES OR LOSSES) RESULTING FROM THE APPLICATION OR
IMPROPER USE OF THE D-LINK PRODUCT OR FAILURE OF THE PRODUCT, EVEN IF
D-LINK IS INFORMED OF THE POSSIBILITY OF SUCH DAMAGES. FURTHERMORE,
D-LINK WILL NOT BE LIABLE FOR THIRD-PARTY CLAIMS AGAINST CUSTOMER FOR
LOSSES OR DAMAGES. D-LINK WILL IN NO EVENT BE LIABLE FOR ANY DAMAGES IN
EXCESS OF THE AMOUNT D-LINK RECEIVED FROM THE END-USER FOR THE
PRODUCT.
9.1. Using an Algorithm Proposal List .................................................................... 401
9.2. Using a Pre-Shared key .................................................................................402
9.3. Using an Identity List .................................................................................... 404
9.4. Setting up a PSK based VPN tunnel for roaming clients .......................................409
9.5. Setting up a Self-signed Certificate based VPN tunnel for roaming clients ...............409
9.6. Setting up CA Server Certificate based VPN tunnels for roaming clients .................411
9.7. Setting Up Config Mode ................................................................................ 412
9.8. Using Config Mode with IPsec Tunnels ............................................................ 413
9.9. Setting up an LDAP server ............................................................................. 413
9.10. Setting up a PPTP server .............................................................................. 426
9.11. Setting up an L2TP server ............................................................................ 427
9.12. Setting up an L2TP Tunnel Over IPsec ........................................................... 427
10.1. Applying a Simple Bandwidth Limit .............................................................. 447
10.2. Limiting Bandwidth in Both Directions ........................................................... 449
10.3. Setting up SLB ........................................................................................... 478
12.1. A simple ZoneDefense scenario .................................................................... 500
13
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. An index is included at the end of the document to aid with
alphabetical lookup of subjects.
Where a "See chapter/section" link (such as: see Chapter 9, VPN) is provided in the main text, this
can be clicked to take the reader directly to that reference.
Text that may appear in the user interface of the product is designated by being in bold case. Where
a term is being introduced for the first time or being stressed it may appear in italics.
Where console interaction is shown in the main text outside of an example, it will appear in a box
with a gray background.
Where a web address reference is shown in the text, clicking it will open the specified URL in a
browser in a new window (some systems may not allow this).
For example, http://www.dlink.com.
Screenshots
This guide contains a minimum of screenshots. This is deliberate and is done because the manual
deals specifically with NetDefendOS and administrators have a choice of management user
interfaces. It was decided that the manual would be less cluttered and easier to read if it concentrated
on describing how NetDefendOS functions rather than including large numbers of screenshots
showing how the various interfaces are used. Examples are given but these are largely textual
descriptions of management interface usage.
Examples
Examples in the text are denoted by the header Example and appear with a gray background as
shown below. They contain a CLI example and/or a Web Interface example as appropriate. (The
NetDefendOS CLI Reference Guide documents all CLI commands.)
Example 1. Example Notation
Information about what the example is trying to achieve is found here, sometimes with an explanatory image.
Command-Line Interface
The Command Line Interface example would appear here. It would start with the command prompt followed by
the command:
gw-world:/> somecommand someparameter=somevalue
Web Interface
The Web Interface actions for the example are shown here. They are also typically a numbered list showing what
14
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. Such sections are of the
following types with the following purposes:
Note
This indicates some piece of information that is an addition to the preceding text. It
may concern something that is being emphasized, or something that is not obvious or
explicitly stated in the preceding text.
Tip
This indicates a piece of non-critical information that is useful to know in certain
situations but is not essential reading.
Caution
This indicates where the reader should be careful with their actions as an undesirable
situation may result if care is not exercised.
Important
This is an essential point that the reader should read and understand.
Warning
This is essential reading for the user as they should be aware that a serious situation
may result if certain actions are taken or not taken.
Trademarks
Certain names in this publication are the trademarks of their respective owners.
Windows, Windows XP, Windows Vista and Windows 7 are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.
15
Chapter 1. NetDefendOS Overview
This chapter outlines the key features of NetDefendOS.
• Features, page 16
• NetDefendOS Architecture, page 19
• NetDefendOS State Engine Packet Flow, page 23
1.1. Features
D-Link NetDefendOS is the base software engine that drives and controls the range of NetDefend
Firewall hardware products.
NetDefendOS as a Network Security Operating System
Designed as a network security operating system, NetDefendOS features high throughput
performance with high reliability plus super-granular control. In contrast to products built on top of
standard operating systems such as Unix or Microsoft Windows, NetDefendOS offers seamless
integration of all its subsystems, in-depth administrative control of all functionality, as well as a
minimal attack surface which helps to negate the risk from security attacks.
NetDefendOS Objects
From the administrator's perspective the conceptual approach of NetDefendOS is to visualize
operations through a set of logical building blocks or objects. These objects allow the configuration
of NetDefendOS in an almost limitless number of different ways. This granular control allows the
administrator to meet the requirements of the most demanding network security scenarios.
Key Features
NetDefendOS has an extensive feature set. The list below presents the key features of the product:
IP Routing
Firewalling Policies
NetDefendOS provides a variety of options for IP routing
including static routing, dynamic routing, as well as multicast
routing capabilities. In addition, NetDefendOS supports
features such as Virtual LANs, Route Monitoring, Proxy ARP
and Transparency. For more information, please see
Chapter 4, Routing.
NetDefendOS provides stateful inspection-based firewalling
for a wide range of protocols such as TCP, UDP and ICMP.
The administrator can define detailed firewalling policies
based on source/destination network/interface, protocol,
ports, user credentials, time-of-day and more. Section 3.5, “IPRule Sets”, describes how to set up these policies to
determinewhattrafficisallowedorrejectedby
NetDefendOS.
Address Translation
For functionality as well as security reasons, NetDefendOS
supports policy-based address translation. Dynamic Address
Translation (NAT) as well as Static Address Translation
(SAT) is supported, and resolves most types of address
translation needs. This feature is covered in Chapter 7,Address Translation.
16
1.1. FeaturesChapter 1. NetDefendOS Overview
VPN
TLS Termination
Anti-Virus Scanning
Intrusion Detection and
Prevention
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”.
NetDefendOS supports TLS termination so that the
NetDefend Firewall can act as the end point for connections
by HTTP web-browser clients (this feature is sometimes
called SSL termination). For detailed information, see
Section 6.2.10, “The TLS ALG”.
NetDefendOS features integrated anti-virus functionality.
Traffic passing through the NetDefend Firewall can be
subjected to in-depth scanning for viruses, and virus sending
hosts can be black-listed and blocked. For details of this
feature, seeSection 6.4, “Anti-Virus Scanning”.
Note
Anti-Virus scanning is only available on certain
D-Link NetDefend product models.
To mitigate application-layer attacks towards vulnerabilities
in services and applications, NetDefendOS provides a
powerful Intrusion Detection and Prevention (IDP) engine.
The IDP engine is policy-based and is able to perform
high-performance scanning and detection of attacks and can
perform blocking and optional black-listing of attacking
hosts. More information about the IDP capabilities of
NetDefendOS can be found in Section 6.5, “IntrusionDetection and Prevention”.
Web Content Filtering
Traffic Management
Note
Full IDP is available on all D-Link NetDefend
product models as a subscription service. On
some models, a simplified IDP subsystem is
provided as standard..
NetDefendOS provides various mechanisms for filtering web
content that is deemed inappropriate according to a web usage
policy. With Web Content Filtering (WCF) web content can
be blocked based on category (Dynamic WCF), malicious
objects can be removed from web pages and web sites can be
whitelisted or blacklisted. More information about this topic
can be found in Section 6.3, “Web Content Filtering”.
Note
Dynamic WCF is only available on some D-Link
NetDefend product models.
NetDefendOS provides broad traffic management capabilities
through Traffic Shaping, Threshold Rules (certain models
only) and Server Load Balancing.
Traffic Shaping enables limiting and balancing of bandwidth;
Threshold Rules allow specification of thresholds for sending
alarms and/or limiting network traffic; Server Load Balancing
17
1.1. FeaturesChapter 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
ZoneDefense
Administrator management of NetDefendOS is possible
through either a Web-based User Interface (the WebUI) or via
a Command Line Interface (the CLI). NetDefendOS also
provides detailed event and logging capabilities plus support
for monitoring through SNMP. More detailed information
about this topic can be found in Chapter 2, Management andMaintenance.
NetDefendOS can be used to control D-Link switches using
the ZoneDefense feature. This allows NetDefendOS to isolate
portions of a network that contain hosts that are the source of
undesirable network traffic.
Note
NetDefendOS ZoneDefense is only available on
certain D-Link NetDefend product models.
NetDefendOS Documentation
Reading through the available documentation carefully will ensure that you get the most out of your
NetDefendOS product. In addition to this document, the reader should also be aware of the
companion reference guides:
•The CLI Reference Guide which details all NetDefendOS CLI commands.
•The NetDefendOS Log Reference Guide which details all NetDefendOS log event messages.
Together, these documents form the essential reference material for NetDefendOS operation.
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. With this approach, packets are
forwarded without any sense of context which eliminates any possibility to detect and analyze
complex protocols and enforce corresponding security policies.
Stateful Inspection
NetDefendOS employs a technique called stateful inspection which means that it inspects and
forwards traffic on a per-connection basis. NetDefendOS detects when a new connection is being
established, and keeps a small piece of information or state in its state table for the lifetime of that
connection. By doing this, NetDefendOS is able to understand the context of the network traffic
which enables it to perform in-depth traffic scanning, apply bandwidth management and a variety of
other functions.
The stateful inspection approach additionally provides high throughput performance with the added
advantage of a design that is highly scalable. The NetDefendOS subsystem that implements stateful
inspection will sometimes be referred to in documentation as the NetDefendOS state-engine.
1.2.2. NetDefendOS Building Blocks
The basic building blocks in NetDefendOS are interfaces, logical objects and various types of rules
(or rule sets).
Interfaces
Interfaces are the doorways through which network traffic enters or leaves the NetDefend Firewall.
Without interfaces, a NetDefendOS system has no means for receiving or sending traffic.
The following types of interface are supported in NetDefendOS:
•Physical interfaces - These correspond to the actual physical Ethernet ports.
•Sub-interfaces - These include VLAN and PPPoE interfaces.
•Tunnel interfaces - Used for receiving and sending traffic through VPN tunnels.
Interface Symmetry
The NetDefendOS interface design is symmetric, meaning that the interfaces of the device are not
fixed as being on the "insecure outside" or "secure inside" of a network topology. The notion of
what is inside and outside is totally for the administrator to define.
Logical Objects
Logical objects can be seen as predefined building blocks for use by the rule sets. The address book,
for instance, contains named objects representing host and network addresses.
Another example of logical objects are services which represent specific protocol and port
combinations. Also important are the Application Layer Gateway (ALG) objects which are used to
define additional parameters on specific protocols such as HTTP, FTP, SMTP and H.323.
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. The Traffic Shaping Rules define the policy for bandwidth management, the
IDP Rules control the behavior of the intrusion prevention engine and so on.
1.2.3. Basic Packet Flow
This section outlines the basic flow in the state-engine for packets received and forwarded by
NetDefendOS. The following description is simplified and might not be fully applicable in all
scenarios, however, the basic principles will be valid for all NetDefendOS deployments.
1.An Ethernet frame is received on one of the Ethernet interfaces in the system. Basic Ethernet
frame validation is performed and the packet is dropped if the frame is invalid.
2.The packet is associated with a Source Interface. The source interface is determined as follows:
•If the Ethernet frame contains a VLAN ID (Virtual LAN identifier), the system checks for a
configured VLAN interface with a corresponding VLAN ID. If one is found, that VLAN
interface becomes the source interface for the packet. If no matching interface is found, the
packet is dropped and the event is logged.
•If the Ethernet frame contains a PPP payload, the system checks for a matching PPPoE
interface. If one is found, that interface becomes the source interface for the packet. If no
matching interface is found, the packet is dropped and the event is logged.
•If none the above is true, the receiving Ethernet interface becomes the source interface for
the packet.
3.The IP datagram within the packet is passed on to the NetDefendOS Consistency Checker. The
consistency checker performs a number of sanity checks on the packet, including validation of
checksums, protocol flags, packet length and so on. If the consistency checks fail, the packet
gets dropped and the event is logged.
4.NetDefendOS now tries to lookup an existing connection by matching parameters from the
incoming packet. A number of parameters are used in the match attempt, including the source
interface, source and destination IP addresses and IP protocol.
If a match cannot be found, a connection establishment process starts which includes steps
from here to 9 below. If a match is found, the forwarding process continues at step 10 below.
5.The Access Rules are evaluated to find out if the source IP address of the new connection is
allowed on the received interface. If no Access Rule matches then a reverse route lookup will
be done in the routing tables.
In other words, by default, an interface will only accept source IP addresses that belong to
networks routed over that interface. A reverse lookup means that we look in the routing tables
to confirm that there is a route where if this network is the destination then the same interface
could be used.
If the Access Rule lookup or the reverse route lookup determine that the source IP is invalid,
then the packet is dropped and the event is logged.
6.A route lookup is being made using the appropriate routing table. The destination interface for
the connection has now been determined.
7.The IP rules are now searched for a rule that matches the packet. The following parameters are
part of the matching process:
•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.
If the action is Allow, the packet is allowed through the system. A corresponding state will be
added to the connection table for matching subsequent packets belonging to the same
connection. In addition, the service object which matched the IP protocol and ports might have
contained a reference to an Application Layer Gateway (ALG) object. This information is
recorded in the state so that NetDefendOS will know that application layer processing will have
to be performed on the connection.
Finally, the opening of the new connection will be logged according to the log settings of the
rule.
Note: Additional actions
There are actually a number of additional actions available such as address
translation and server load balancing. The basic concept of dropping and
allowing traffic is still the same.
8.The Intrusion Detection and Prevention (IDP) Rules are now evaluated in a similar way to the
IP rules. If a match is found, the IDP data is recorded with the state. By doing this,
NetDefendOS will know that IDP scanning is supposed to be conducted on all packets
belonging to this connection.
9.The Traffic Shaping and the Threshold Limit rule sets are now searched. If a match is found,
the corresponding information is recorded with the state. This will enable proper traffic
management on the connection.
10. From the information in the state, NetDefendOS now knows what to do with the incoming
packet:
•If ALG information is present or if IDP scanning is to be performed, the payload of the
packet is taken care of by the TCP Pseudo-Reassembly subsystem, which in turn makes use
of the different Application Layer Gateways, layer 7 scanning engines and so on, to further
analyze or transform the traffic.
•If the contents of the packet is encapsulated (such as with IPsec, PPTP/L2TP or some other
type of tunneled protocol), then the interface lists are checked for a matching interface. If
one is found, the packet is decapsulated and the payload (the plaintext) is sent into
NetDefendOS again, now with source interface being the matched tunnel interface. In other
words, the process continues at step 3 above.
•If traffic management information is present, the packet might get queued or otherwise be
subjected to actions related to traffic management.
11. Eventually, the packet will be forwarded out on the destination interface according to the state.
If the destination interface is a tunnel interface or a physical sub-interface, additional
processing such as encryption or encapsulation might occur.
The next section provides a set of diagrams illustrating the flow of packets through NetDefendOS.
22
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. It is not necessary to understand
these diagrams, however, they can be useful as a reference when configuring NetDefendOS in
certain situations.
Figure 1.1. Packet Flow Schematic Part I
The packet flow is continued on the following page.
23
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.
24
1.3. NetDefendOS State Engine Packet
Flow
Chapter 1. NetDefendOS Overview
Figure 1.3. Packet Flow Schematic Part III
25
1.3. NetDefendOS State Engine Packet
Flow
Apply Rules
The figure below presents the detailed logic of the Apply Rules function in Figure 1.2, “Packet
Flow Schematic Part II” above.
Chapter 1. NetDefendOS Overview
Figure 1.4. Expanded Apply Rules Logic
26
1.3. NetDefendOS State Engine Packet
Flow
Chapter 1. NetDefendOS Overview
27
Chapter 2. Management and Maintenance
This chapter describes the management, operations and maintenance related aspects of
NetDefendOS.
• Managing NetDefendOS, page 28
• Events and Logging, page 55
• RADIUS Accounting, page 60
• Hardware Monitoring, page 65
• SNMP Monitoring, page 67
• The pcapdump Command, page 70
• Maintenance, page 73
2.1. Managing NetDefendOS
2.1.1. Overview
NetDefendOS is designed to give both high performance and high reliability. Not only does it
provide an extensive feature set, it also enables the administrator to be in full control of almost every
detail of the system. This means the product can be deployed in the most challenging environments.
A good understanding on how NetDefendOS configuration is performed is crucial for proper usage
of the system. For this reason, this section provides an in-depth presentation of the configuration
subsystem as well as a description of how to work with the various management interfaces.
Management Interfaces
NetDefendOS provides the following management interfaces:
The Web Interface
The CLI
Secure Copy
The Web Interface (also known as the Web User Interface or WebUI) is
built into NetDefendOS and provides a user-friendly and intuitive
graphical management interface, accessible from a standard web
browser (Microsoft Internet Explorer or Firefox is recommended). The
browser connects to one of the hardware's Ethernet interfaces using
HTTP or HTTPS and the NetDefendOS responds like a web server,
allowing web pages to be used as the management interface.
This feature is fully described in Section 2.1.3, “The Web Interface”.
The Command Line Interface (CLI), accessible locally via serial console
port or remotely using the Secure Shell (SSH) protocol, provides the
most fine-grained control over all parameters in NetDefendOS.
This feature is fully described in Section 2.1.4, “The CLI”.
Secure Copy (SCP) is a widely used communication protocol for file
transfer. No specific SCP client is provided with NetDefendOS
distributions but there exists a wide selection of SCP clients available
for nearly all workstation platforms. SCP is a complement to CLI usage
and provides a secure means of file transfer between the administrator's
workstation and the NetDefend Firewall. Various files used by
NetDefendOS can be both uploaded and downloaded with SCP.
28
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.
This feature is fully described in Section 2.1.7, “The Console BootMenu”.
Note: Recommended browsers
Microsoft Internet Explorer (version 7 and later), Firefox (version 3.0 and later) and
Netscape (version 8 and later) are the recommended web-browsers to use with the
WebUI. Other browsers may also provide full support.
Remote Management Policies
Access to remote management interfaces can be regulated by a remote management policy so the
administrator can restrict management access based on source network, source interface and
username/password credentials. Access to the Web Interface can be permitted for administrative
users on a certain network, while at the same time allowing CLI access for a remote administrator
connecting through a specific IPsec tunnel.
By default, Web Interface access is enabled for users on the network connected via the LAN
interface of the D-Link firewall (on products where more than one LAN interface is available,
LAN1 is the default interface).
2.1.2. The Default Administrator Account
By default, NetDefendOS has a local user database, AdminUsers, that contains one predefined
administrator account. This account has the username admin with password admin. This account
has full administrative read/write privileges for NetDefendOS.
Important
For security reasons, it is recommended to change the default password of the default
account as soon as possible after connecting with the NetDefend Firewall.
Creating Additional Accounts
Extra user accounts can be created as required. Accounts can either belong to the Administrator
user group, in which case they have complete read/write administrative access. Alternatively, they
can belong to the Auditor user group, in which case they have read-only access.
Multiple Administration Logins
NetDefendOS doesn't allow more than one administrator account to be logged in at the same time. If
one administrator logs in, then a second or more will be allowed to login but they will only have
audit privileges. In other words the second or more administrators who login will only be able to
read configurations and will not be able to change them.
2.1.3. The Web Interface
29
2.1.3. The Web InterfaceChapter 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.
Assignment of a Default IP Address
For a new D-Link NetDefend firewall with factory defaults, a default internal IP address is assigned
automatically by NetDefendOS to the hardware's LAN1 interface (or the LAN interface on models
wihout multiple LAN interfaces). The IP address assigned to the management interface differs
according to the NetDefend model as follows:
•On the NetDefend DFL-210, 260, 800, 860, 1600 and 2500, the default management interface IP
address is 192.168.1.1.
•On the NetDefend DFL-1660, 2560 and 2560G, the default management interface IP address is
192.168.10.1.
Setting the Workstation IP
The assigned NetDefend Firewall interface and the workstation interface must be members of the
same logical IP network for initial communication between them to succeed so the connecting
interface of the workstation must be manually given the following static IP values:
•IP address: 192.168.1.30
•Subnet mask: 255.255.255.0
•Default gateway: 192.168.1.1
Logging on to the Web Interface
To access the Web Interface using the factory default settings, launch a web browser on the
workstation (the latest version of Internet Explorer or Firefox is recommended) and point the
browser at the address 192.168.1.1.
When performing initial connection to NetDefendOS, the administrator must use https:// as the
URL protocol in the browser (in other words, https://192.168.1.1). Using HTTPS as the protocol
makes communication with NetDefendOS secure.
If communication with the NetDefendOS is successfully established, a user authentication dialog
similar to the one shown below will then be shown in the browser window.
Enter your username and password and click the Login button. The factory default username and
30
2.1.3. The Web InterfaceChapter 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 always admin and the password is
admin.
After successful login, the WebUI user interface will be presented in the browser window. If no
configuration changes have yet been uploaded to the NetDefend Firewall, the NetDefendOS SetupWizard will start automatically to take a new user through the essential steps for NetDefendOS setup
and establishing public Internet access.
Important: Switch off popup blocking
Popup blocking must be disabled in the web browser to allow the NetDefendOS Setup
Wizard to run since this appears in a popup window.
Multi-language Support
The Web Interface login dialog offers the option to select a language other than English for the
interface. Language support is provided by a set of separate resource files. These files can be
downloaded from the D-Link website.
It may occasionally be the case that a NetDefendOS upgrade can contain features that temporarily
lack a complete non-english translation because of time constraints. In this case the original english
will be used as a temporary solution in place of a translation to the selected language.
The Web Browser Interface
On the left hand side of the Web Interface is a tree which allows navigation to the various sets of
NetDefendOS objects. The central area of the Web Interface displays information about those
modules. Current performance information is shown by default.
31
2.1.3. The Web InterfaceChapter 2. Management and Maintenance
For information about the default user name and password, see Section 2.1.2, “The DefaultAdministrator 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.
Interface Layout
The main Web Interface page is divided into three major sections:
A. Menu bar
The menu bar located at the top of the Web Interface contains a number of
buttons and drop-down menus that are used to perform configuration tasks
as well as for navigation to various tools and status pages.
•Home - Navigates to the first page of the Web Interface.
•Configuration
•Save and Activate - Saves and activates the configuration.
•Discard Changes - Discards any changes made to the configuration
during the current session.
•View Changes - List the changes made to the configuration since it
was last saved.
•Tools - Contains a number of tools that are useful for maintaining the
system.
•Status - Provides various status pages that can be used for system
diagnostics.
•Maintenance
•Update Center - Manually update or schedule updates of the
intrusion detection and antivirus signatures.
•License - View license details or enter activation code.
B. Navigator
C. Main Window
•Backup - Make a backup of the configuration to your local
computer or restore a previously downloaded backup.
•Reset - Restart the firewall or reset to factory default.
•Upgrade - Upgrade the firewall's firmware.
•Technical support - This option provides the option to download a
file from the firewall which can be studied locally or sent to a
technical support specialist to analyze a problem. This can be very
useful since the information provided automatically includes many
details that are required for troubleshooting.
The navigator located on the left-hand side of the Web Interface contains a
tree representation of the system configuration. The tree is divided into a
number of sections corresponding to the major building blocks of the
configuration. The tree can be expanded to expose additional sections.
The main window contains configuration or status details corresponding to
the section selected in the navigator or the menu bar.
32
2.1.4. The CLIChapter 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.
The above example is provided for informational purposes only. It is never
recommended to expose any management interface to any user on the Internet.
Logging out from the Web Interface
When you have finished working in the Web Interface, you should always logout to prevent other
users with access to your workstation to get unauthorized access to the system. Logout by clicking
on the Logout button at the right of the menu bar.
2.1.4. The CLI
NetDefendOS provides a Command Line Interface (CLI) for administrators who prefer or require a
command line approach to administration, or who need more granular control of system
configuration. The CLI is available either locally through the serial console port (connection to this
Tip: Correctly routing management traffic
If there is a problem with the management interface when communicating alongside
VPN tunnels, check the main routing table and look for an all-nets route to the VPN
tunnel. Management traffic may be using this route.
If no specific route is set up for the management interface then all management traffic
coming from NetDefendOS will automatically be routed into the VPN tunnel. If this is
the case then a route should be added by the administrator to route management
traffic destined for the management network to the correct interface.
33
2.1.4. The CLIChapter 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. For a complete reference for all CLI
commands, see the separate D-Link CLI Reference Guide.
The most often used CLI commands are:
•add - Adds an object such as an IP address or a rule to a NetDefendOS configuration.
•set - Sets some property of an object to a value. For example, this might be used to set the source
interface on an IP rule.
•show - Displays the current categories or display the values of a particular object.
•delete - Deletes a specific object.
CLI Command Structure
CLI commands usually begin with the structure: <command> <object_type> <object_name>. For
example, to display an IP address object called my_address, the command would be:
gw-world:/> show Address IP4Address my_address
The second part of the command specifies the object type and is necessary to identify what category
of object the object name refers to (consider that the same name might exist in two different
categories).
Note: Category and Context
The term category is sometimes referred to as the context of an object.
A command like add can also include object properties. To add a new IP4Address object with an IP
address of 10.49.02.01, the command would be:
The object type can be optionally preceded by the object category. A category groups together a set
of types and mainly used with tab completion which is described below.
Tip: Getting help about help
Typing the CLI command:
gw-world:/> help help
will give information about the help command itself.
The CLI Command History
Just like the console in many versions of Microsoft Windows™, the up and down arrow keys allow
the user to move through the list of commands in the CLI command history. For example, pressing
the up arrow key once will make the last command executed appear at the current CLI prompt. After
34
2.1.4. The CLIChapter 2. Management and Maintenance
a 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. If completion is not possible then pressing the tab key will
alternatively display the possible command options that are available.
Tab Completion of Parameters
Another useful feature with tab completion is the ability to automatically fill in the current values of
data parameters in a command line. This is done by typing a period "." character followed by the tab
key after the "=" character. For example, we may have typed the unfinished command:
set Address IP4Address lan_ip Address=
If we now type "." followed by a tab, NetDefendOS will display the current value for the Address
parameter. If that value is, for example, 10.6.58.10 then the unfinished command line will
automatically become:
set Address IP4Address lan_ip Address=10.6.58.10
NetDefendOS automatically inserts the current value of 10.6.58.10 and this can then be easily
changed with the backspace or back arrow keys before completing the command.
In a similar way, the "<" character before a tab can be used to automatically fill in the default value
for a parameter if no value has yet been set. For example:
add LogReceiverSyslog example Address=example_ip LogSeverity=< (tab)
Will fill in the default value for LogSeverity:
add LogReceiverSyslog example Address=example_ip
However, if the "." character is used instead:
add LogReceiverSyslog example Address=example_ip LogSeverity=. (tab)
A list of all possible values is given:
add LogReceiverSyslog example Address=example_ip
This list can then be edited with the back arrow and backspace keys.
It has been mentioned that objects are grouped by type, such as IP4Address. Types themselves are
grouped by category. The type IP4Address belongs to the category Address. The main use of
categories is in tab completion when searching for the right object type to use.
If a command such as add is entered and then the tab key is pressed, NetDefendOS displays all the
available categories. By choosing a category and then pressing tab again all the object types for that
category is displayed. Using categories means that the user has a simple way to specify what kind of
object they are trying to specify and a manageable number of options are displayed after pressing
tab.
35
2.1.4. The CLIChapter 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. This is the case, for example,
with routes. There can be more than one routing table, so when adding or manipulating a route we
first have to use the cc command to identify which routing table we are interested in.
Suppose a route is to be added to the routing table main. The first command would be:
gw-world:/> cc RoutingTable main
gw-world:/main>
Notice that the command prompt changes to indicate the current category. We can now add the
route:
To deselect the category, the command is cc on its own:
gw-world:/main> cc
gw-world:/>
The categories that require an initial cc command before object manipulation have a "/" character
following their names when displayed by a show command. For example: RoutingTable/.
Specifying Multiple Property Values
Sometimes a command property may need multiple values. For example, some commands use the
property AccountingServers and more than one value can be specified for this property. When
specifying multiple values, they should be separated by a comma "," character. For example, if three
servers server1, server2, server3 need to be specified then the property assignment in the command
would be:
AccountingServers=server1,server2,server3
Inserting into Rule Lists
Rule lists such as the IP rule set have an ordering which is important. When adding using the CLI
add command, the default is to add a new rule to the end of a list. When placement at a particular
position is crucial, the add command can include the Index= parameter as an option. Inserting at the
first position in a list is specified with the parameter Index=1 in an add command, the second
position with the parameter Index=2 and so on.
Referencing by Name
The naming of some objects is optional and is done with the Name= parameter in an add command.
An object, such as a threshold rule, will always have an Index value which indicates its position in
the rule list but can optionally be allocated a name as well. Subsequent manipulation of such a rule
36
2.1.4. The CLIChapter 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. Reference by name is particularly useful when writing CLI scripts.
For more on scripts see Section 2.1.5, “CLI Scripts”.
The CLI will enforce unique naming within an object type. For reasons of backward compatibility
to earlier NetDefendOS releases, an exception exists with IP rules which can have duplicate names,
however it is strongly recommended to avoid this. If a duplicate IP rule name is used in two IP rules
then only the Index value can uniquely identify each IP rule in subsequent CLI commands.
Referencing an IP rule with a duplicated name will fail and result in an error message.
Using Hostnames in the CLI
For certain CLI commands, IP addresses can optionally be specified as a textual hostname instead
an IP4Address object or raw IP address such as 192.168.1.10. When this is done, the hostname must
be prefixed with the letters dns: to indicate that a DNS lookup must be done to resolve the hostname
to an IP address. For example, the hostname host.company.com would be specified as
dns:host.company.com in the CLI.
The parameters where URNs might be used with the CLI are:
•The Remote Endpoint for IPsec, L2TP and PPTP tunnels.
•The Host for LDAP servers.
When DNS lookup needs to be done, at least one public DNS server must be configured in
NetDefendOS for hostnames to be translated to IP addresses.
Serial Console CLI Access
The serial console port is a local RS-232 port on the NetDefend Firewall that allows direct access to
the NetDefendOS CLI through a serial connection to a PC or dumb terminal. To locate the serial
console port on your D-Link hardware, see the D-Link Quick Start Guide .
To use the console port, you need the following equipment:
•A terminal or a computer with a serial port and the ability to emulate a terminal (such as using
the Hyper Terminal software included in some Microsoft Windows™ editions). The serial
console port uses the following default settings: 9600 bps, No parity, 8 data bits and 1 stop bit.
•A RS-232 cable with appropriate connectors. An appliance package includes a RS-232
null-modem cable.
To now connect a terminal to the console port, follow these steps:
1.Set the terminal protocol as described previously.
2.Connect one of the connectors of the RS-232 cable directly to the console port on your system
hardware.
3.Connect the other end of the cable to the terminal or the serial connector of the computer
running the communications software.
37
2.1.4. The CLIChapter 2. Management and Maintenance
4.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.
NetDefendOS supports version 1, 1.5 and 2 of the SSH protocol. SSH access is regulated by the
remote management policy in NetDefendOS, and is disabled by default.
Example 2.2. Enabling SSH Remote Access
This example shows how to enable remote SSH access from the lannet network through the lan interface by
adding a rule to the remote management policy.
1. Go to System > Remote Management > Add > Secure Shell Management
2. Enter a Name for the SSH remote management policy, for example ssh_policy
3. Select the following from the dropdown lists:
• User Database: AdminUsers
• Interface: lan
• Network: lannet
4. Click OK
Interface=lan LocalUserDatabase=AdminUsers
Logging on to the CLI
When access to the CLI has been established to NetDefendOS through the serial console or an SSH
client, the administrator will need to logon to the system before being able to execute any CLI
command. This authentication step is needed to ensure that only trusted users can access the system,
as well as providing user information for auditing.
When accessing the CLI remotely through SSH, NetDefendOS will respond with a login prompt.
Enter your username and press the Enter key, followed by your password and then Enter again.
After a successful logon, the CLI command prompt will appear:
gw-world:/>
If a welcome message has been set then it will be displayed directly after the logon. For security
reasons, it is advisable to either disable or anonymize the CLI welcome message.
Changing the admin User Password
It is recommended to change the default password of the admin account from admin to something
38
2.1.4. The CLIChapter 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. First
we must change the current category to be the LocalUserDatabase called AdminUsers (which exists
by default):
gw-world:/> cc LocalUserDatabase AdminUsers
We are now in AdminUsers and can change the password of the admin user:
gw-world:/AdminUsers> set User admin Password="my-password"
Finally, we return the current category to the top level:
gw-world:/AdminUsers> cc ..
Note: The console password is separate
The password that can be set to protect direct serial console access is a separate
password and should not be confused with the passwords related to user accounts. The
console password is described in Section 2.1.7, “The Console Boot Menu”.
Changing the CLI Prompt
The default CLI prompt is:
gw-world:/>
where Device is the model number of the NetDefend Firewall. This can be customized, for example,
to my-prompt:/>, by using the CLI command:
gw-world:/> set device name="my-prompt"
The CLI Reference Guide uses the command prompt gw-world:/> throughout.
Tip: The CLI prompt is the WebUI device name
When the command line prompt is changed to a new string value, this string also
appears as the new device name in the top level node of the WebUI tree-view.
Activating and Committing Changes
If any changes are made to the current configuration through the CLI, those changes will not be
uploaded to NetDefendOS until the command:
gw-world:/> activate
is issued. Immediately following the activate command, the command:
gw-world:/> commit
should be issued to make those changes permanent.
If a commit command is not issued within a default time period of 30 seconds then the changes are
39
2.1.4. The CLIChapter 2. Management and Maintenance
automatically undone and the old configuration restored.
Checking Configuration Integrity
After changing a NetDefendOS configuration and before issuing the activate and 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.
A possible problem that might be found in this way is a reference to an IP object in the address book
that does not exist in a restored configuration backup.
Logging off from the CLI
After finishing working with the CLI, it is recommended to logout in order to avoid letting anyone
getting unauthorized access to the system. Log off by using the exit or the logout command.
Configuring Remote Management Access on an Interface
Remote management access may need to be configured through the CLI. Suppose management
access is to be through Ethernet interface if2 which has an IP address 10.8.1.34.
Firstly, we set the values for the IP address objects for if2 which already exist in the NetDefendOS
address book, starting with the interface IP:
gw-world:/> set Address IP4Address if2_ip Address=10.8.1.34
The network IP address for the interface must also be set to the appropriate value:
gw-world:/> set Address IP4Address if2_net Address=10.8.1.0/24
In this example, local IP addresses are used for illustration but these could be public IP addresses
instead.
Next, create a remote HTTP management access object, in this example called HTTP_if2:
The assumption made with the above commands is that an all-nets route exists to the ISP's gateway.
In other words, Internet access has been enabled for the NetDefend Firewall.
Managing Management Sessions with sessionmanager
The CLI provides a command called sessionmanager for managing management sessions
themselves. The command be used to manage all types of management sessions, including:
•Secure Shell (SSH) CLI sessions.
•Any CLI session through the serial console interface.
40
2.1.5. CLI ScriptsChapter 2. Management and Maintenance
•Secure Copy (SCP) sessions.
•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:3
Maximum allowed connections :64
Local idle session timeout:900
NetCon idle session timeout :600
To see a list of all sessions use the -list option. Below is some typical output showing the local
console session:
If the user has full administrator privileges, they can forcibly terminate another management session
using the -disconnect option of the sessionmanager command.
The sessionmanager command options are fully documented in the CLI Reference Guide.
2.1.5. CLI Scripts
To allow the administrator to easily store and execute sets of CLI commands, NetDefendOS
provides a feature called CLI scripting. A CLI script is a predefined sequence of CLI commands
which can be executed after they are saved to a file and the file is then uploaded to the NetDefend
Firewall.
The steps for creating a CLI script are as follows:
1.Create a text file with a text editor containing a sequential list of CLI commands, one per line.
The D-Link recommended convention is for these files to use the file extension .sgs (Security
Gateway Script). The filename, including the extension, should not be more than 16 characters.
2.Upload the file to the NetDefend Firewall using Secure Copy (SCP). Script files must be stored
in a directory under the root called /scripts. SCP uploading is discussed in detail in
Section 2.1.6, “Secure Copy”.
3.Use the CLI command script -execute to run the script file.
The CLI script command is the tool used for script management and execution. The complete
syntax of the command is described in the CLI Reference Guide and specific examples of usage are
detailed in the following sections. See also Section 2.1.4, “The CLI” in this manual.
Only Four Commands are Allowed in Scripts
The commands allowed in a script file are limited to four and these are:
add
set
41
2.1.5. CLI ScriptsChapter 2. Management and Maintenance
delete
cc
If any other command appears in a script file, it is ignored during execution and a warning message
is output. For example, the ping command will be ignored.
Executing Scripts
As mentioned above, the script -execute command launches a named script file that has been
previously uploaded to the NetDefend Firewall. For example, to execute the script file my_script.sgs
which has already been uploaded, the CLI command would be:
gw-world:/> script -execute -name=my_script.sgs
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. The variable $0 is reserved and is
always replaced before execution by the name of the script file itself.
For example, a script called my_script.sgs is to be executed with IP address 126.12.11.01 replacing
all occurrences of $1 in the script file and the string If1 address replacing all occurrences of $2.
The file my_script.sgs contains the single CLI command line:
add IP4Address If1_ip Address=$1 Comments=$2
To run this script file after uploading, the CLI command would be:
CLI scripts are not, by default, validated. This means that the written ordering of the script does not
matter. There can be a reference to a configuration object at the beginning of a script which is only
created at the end of the script. Although this might seem illogical, it is done to improve the
readability of scripts. If something always has to be created before it is referred to then this can
result in a confused and disjointed script file and in large script files it is often preferable to group
together CLI commands which are similar.
Error Handling
42
2.1.5. CLI ScriptsChapter 2. Management and Maintenance
If an executing CLI script file encounters an error condition, the default behavior is for the script to
terminate. This behavior can be overridden by using the -force option. To run a script file called
my_script2.sgs in this way, the CLI command is:
If -force is used, the script will continue to execute even if errors are returned by a command in the
script file.
Script Output
Any output from script execution will appear at the CLI console. Normally this output only consists
of any error messages that occur during execution. To see the confirmation of each command
completing, the -verbose option should be used:
When a script file is uploaded to the NetDefend Firewall, it is initially kept only in temporary RAM
memory. If NetDefendOS restarts then any uploaded scripts will be lost from this volatile memory
and must be uploaded again to run. To store a script between restarts, it must explicitly be moved to
non-volatile NetDefendOS disk memory by using the script -store command.
To move the example my_script.sgs to non-volatile memory the command would be:
gw-world:/> script -store -name=my_script.sgs
Alternatively, all scripts can be moved to non-volatile memory with the command:
gw-world:/> script -store -all
Removing Scripts
To remove a saved script. the script -remove command can be used.
To remove the example my_script.sgs script file, the command would be:
gw-world:/> script -remove -name=my_script.sgs
Listing Scripts
The script on its own, command without any parameters, lists all the scripts currently available and
indicates the size of each script as well as the type of memory where it resides (residence in
non-volatile memory is indicated by the word "Disk" in the Memory column).
gw-world:/> script
NameStorageSize (bytes)
----------------------------------------
my_script.sgsRAM8
my_script2.sgsDisk10
To list the content of a specific uploaded script file, for example my_script.sgs the command would
be:
43
2.1.5. CLI ScriptsChapter 2. Management and Maintenance
gw-world:/> script -show -name=my_script.sgs
Creating Scripts Automatically
When the same configuration objects needs to be copied between multiple NetDefend Firewalls,
then one way to do this with the CLI is to create a script file that creates the required objects and
then upload to and run the same script on each device.
If we already have a NetDefendOS installation that already has the objects configured that need to
be copied, then running the script -create command on that installation provides a way to
automatically create the required script file. This script file can then be downloaded to the local
management workstation and then uploaded to and executed on other NetDefend Firewalls to
duplicate the objects.
For example, suppose the requirement is to create the same set of IP4Address objects on several
NetDefend Firewalls that already exist on a single unit. The administrator would connect to the
single unit with the CLI and issue the command:
This creates a script file called new_script_sgs which contains all the CLI commands necessary to
create all IP4Address address objects in that unit's configuration. The created file's contents might,
for example, be:
The file new_script_sgs can then be downloaded with SCP to the local management workstation and
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.
"
"
"
Tip: Listing commands at the console
To list the created CLI commands on the console instead of saving them to a file, leave
out the option -name= in the script -create command.
Certain aspects of a configuration which are hardware dependent cannot have a script created using
the -create option. This is true when the CLI node type in the script -create command is one of:
COMPortDevice
Ethernet
EthernetDevice
Device
If one of these node types is used then the error message script file empty is returned by
NetDefendOS.
Commenting Script Files
44
2.1.6. Secure CopyChapter 2. Management and Maintenance
Any line in a script file that begins with the # character is treated as a comment. For example:
# The following line defines the If1 IP address
add IP4Address If1_ip Address=10.6.60.10
Scripts Running Other Scripts
It is possible for one script to run another script. For example, the script my_script.sgs could contain
the line:
"
"
script -execute -name my_script2.sgs
"
"
NetDefendOS allows the script file my_script2.sgs to execute another script file and so on. The
maximum depth of this script nesting is 5.
2.1.6. Secure Copy
To upload and download files to or from the NetDefend Firewall, the secure copy (SCP) protocol
can be used. SCP is based on the SSH protocol and many freely available SCP clients exist for
almost all platforms. The command line examples below are based on the most common command
format for SCP client software.
SCP Command Format
SCP command syntax is straightforward for most console based clients. The basic command used
here is scp followed by the source and destination for the file transfer.
Upload is performed with the command:
> scp <local_filename> <destination_firewall>
Download is done with the command:
> scp <source_firewall> <local_filename>
The source or destination NetDefend Firewall is of the form:
<user_name>@<firewall_ip_address>:<filepath>.
For example: admin@10.62.11.10:config.bak. The <user_name> must be a defined NetDefendOS
user in the administrator user group.
Note: SCP examples do not show the password prompt
SCP will normally prompt for the user password after the command line but that
prompt is not shown in the examples given here.
The following table summarizes the operations that can be performed between an SCP client and
NetDefendOS:
File typeUpload possibleDownload possible
Configuration Backup (config.bak)Yes (also with WebUI)Yes (also with WebUI)
System Backup (full.bak)Yes (also with WebUI)Yes (also with WebUI)
45
2.1.6. Secure CopyChapter 2. Management and Maintenance
File typeUpload possibleDownload possible
Firmware upgradesYesNo
CertificatesYesNo
SSH public keysYesNo
Web auth banner filesYesYes
Web content filter banner filesYesYes
NetDefendOS File organization
NetDefendOS maintains a simple 2 level directory structure which consists of the top level root and
a number of sub-directories. However, these "directories" such as sshlclientkey should be more
correctly thought of as object types. All the files stored in the NetDefendOS root as well as all the
object types can be displayed using the CLI command ls.
Apart from the individual files, the objects types listed are:
•HTTPALGBanners/ - The banner files for user authentication HTML. Uploading these is
described further in Section 6.3.4.4, “Customizing HTML Pages”.
•HTTPAuthBanner/ - The banner files for HTML ALG dynamic content filtering. Uploading
these is described further in Section 6.3.4.4, “Customizing HTML Pages”.
•certificate/ - The object type for all digital certificates.
•script/ - The object type for all CLI scripts. Scripts are described further in Section 2.1.5, “CLI
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. NetDefendOS
checks this header and ensures the file is stored only in the root (all files do not have a header).
If an administrator username is admin1 and the IP address of the NetDefend Firewall is 10.5.62.11
then to upload a configuration backup, the SCP command would be:
> scp config.bak admin1@10.5.62.11:
To download a configuration backup to the current local directory, the command would be:
> scp admin1@10.5.62.11:config.bak ./
46
2.1.7. The Console Boot MenuChapter 2. Management and Maintenance
To upload a file to an object type under the root, the command is slightly different. If we have a
local CLI script file called my_script.sgs then the upload command would be:
> scp my_script.sgs admin1@10.5.62.11:script/
If we have the same CLI script file called my_scripts.sgs stored on the NetDefend Firewall then the
download command would be:
> scp admin1@10.5.62.11:script/my_script.sgs ./
Activating Uploads
Like all configuration changes, SCP uploads only become active after the CLI commands activate
have been issued and this must be followed by commit to make the change permanent.
Uploads of firmware upgrades (packaged in .upg files) or a full system backup (full.bak) are the
exception. Both of these file types will result in an automatic system reboot. The other exception is
for script uploads which do not affect the configuration.
2.1.7. The Console Boot Menu
The NetDefendOS loader is the base software on top of which NetDefendOS runs and the
administrator's direct interface to this is called the console boot menu (also known simply as the
boot menu). This section discusses the boot menu options.
Accessing the Console Boot Menu
The boot menu is only accessible through a console device attached directly to the serial console
located on the NetDefend Firewall. It can be accessed through the console after the NetDefend
Firewall is powered up and before NetDefendOS is fully started.
After powering up the NetDefend Firewall, there is a 3 second interval before NetDefendOS starts
up and in that time the message Press any key to abort and load boot menu is displayed as shown
below:
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:
47
2.1.8. Management Advanced SettingsChapter 2. Management and Maintenance
The options available in the boot menu are:
1.Start firewall
This initiates the complete startup of the NetDefendOS software on the NetDefend Firewall.
2.Reset unit to factory defaults
This option will restore the hardware to its initial factory state. The operations performed if this
option is selected are the following:
•Remove console security so there is no console password.
•Restore default NetDefendOS executables along with the default configuration.
3.Revert to default configuration
This will only reset the configuration to be the original, default NetDefendOS configuration
file. Other options, such as console security, will not be affected.
4.Set console password
Set a password for console access. Until a password is set, anyone can utilize the console so
selecting setting the password as soon as possible is recommended. After it is set, the console
will prompt for the password before access is allowed to either the boot menu or the command
line interface (CLI).
Initial Options with a Console Password Set
If a console password is set then the initial options that appear when NetDefendOS loading is
interrupted with a key press are shown below.
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.
The Console Password is Only for the Console
The password set for the console is not connected to the management username/password
combinations used for administrator access through a web browser. It is valid only for console
access.
2.1.8. Management Advanced Settings
Under the Remote Management section of the Web Interface a number of advanced settings can be
found. These are:
48
2.1.9. Working with ConfigurationsChapter 2. Management and Maintenance
SSH Before Rules
Enable SSH traffic to the firewall regardless of configured IP Rules.
Default: Enabled
WebUI Before Rules
Enable HTTP(S) traffic to the firewall regardless of configured IP Rules.
Default: Enabled
Local Console Timeout
Number of seconds of inactivity until the local console user is automatically logged out.
Default: 900
Validation Timeout
Specifies the amount of seconds to wait for the administrator to log in before reverting to the
previous configuration.
Default: 30
WebUI HTTP port
Specifies the HTTP port for the Web Interface.
Default: 80
WebUI HTTPS port
Specifies the HTTP(S) port for the Web Interface.
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. Examples of configuration objects are routing table entries, address
book entries, service definitions, IP rules and so on. Each configuration object has a number of
properties that constitute the values of the object.
Object Types
49
2.1.9. Working with ConfigurationsChapter 2. Management and Maintenance
A configuration object has a well-defined type. The type defines the properties that are available for
the configuration object, as well as the constraints for those properties. For instance, the IP4Address
type is used for all configuration objects representing a named IPv4 address.
Object Organization
In the Web Interface the configuration objects are organized into a tree-like structure based on the
type of the object.
In the CLI, similar configuration object types are grouped together in a category. These categories
are different from the structure used in the Web Interface to allow quick access to the configuration
objects in the CLI. The IP4Address, IP4Group and EthernetAddress types are, for instance, grouped
in a category named Address, as they all represent different addresses. Consequently, Ethernet and
VLAN objects are all grouped in a category named Interface, as they are all interface objects. The
categories have actually no impact on the system configuration; they are merely provided as means
to simplify administration.
The following examples show how to manipulate objects.
Example 2.3. Listing Configuration Objects
To find out what configuration objects exist, you can retrieve a listing of the objects. This example shows how to
list all service objects.
Command-Line Interface
gw-world:/> show Service
A list of all services will be displayed, grouped by their respective type.
Web Interface
1. Go to Objects > Services
2. A web page listing all services will be presented.
A list contains the following basic elements:
• Add Button - Displays a dropdown menu when clicked. The menu will list all types of configuration items that
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.
A single row in the list can be selected by clicking on the row on a spot where there is no hyperlink. The
background color of the row will turn dark blue. Right-clicking the row will display a menu where you can choose
to edit or delete the object as well as modify the order of the objects.
Example 2.4. Displaying a Configuration Object
The simplest operation on a configuration object is to show its contents, in other words the values of the object
properties. This example shows how to display the contents of a configuration object representing the telnet
service.
Command-Line Interface
gw-world:/> show Service ServiceTCPUDP telnet
----------------- ------DestinationPorts: 23
Property Value
Name: telnet
50
2.1.9. Working with ConfigurationsChapter 2. Management and Maintenance
SourcePorts: 0-65535
PassICMPReturn: No
MaxSessions: 1000
The Property column lists the names of all properties in the ServiceTCPUDP class and the Value column lists the
corresponding property values.
Web Interface
1. Go to Objects > Services
2. Click on the telnet hyperlink in the list
3. A web page displaying the telnet service will be presented
Type: TCP
SYNRelay: No
ALG: (none)
Comments: Telnet
Note
When accessing object via the CLI you can omit the category name and just use the
type name. The CLI command in the above example, for instance, could be simplified
to:
gw-world:/> show ServiceTCPUDP telnet
Example 2.5. Editing a Configuration Object
When you need to modify the behavior of NetDefendOS, you will most likely need to modify one or several
configuration objects. This example shows how to edit the Comments property of the telnet service.
Command-Line Interface
gw-world:/> set Service ServiceTCPUDP telnet
Show the object again to verify the new property value:
gw-world:/> show Service ServiceTCPUDP telnet
----------------- ------DestinationPorts: 23
PassICMPReturn: No
Web Interface
1. Go to Objects > Services
2. Click on the telnet hyperlink in the list
3. In the Comments textbox, enter your new comment
4. Click OK
Verify that the new comment has been updated in the list.
Property Value
Name: telnet
SourcePorts: 0-65535
MaxSessions: 1000
Type: TCP
SYNRelay: No
ALG: (none)
Comments: Modified Comment
Comments="Modified Comment"
51
2.1.9. Working with ConfigurationsChapter 2. Management and Maintenance
Important: Configuration changes must be activated
Changes to a configuration object will not be applied to a running system until the new
NetDefendOS configuration is activated.
Example 2.6. Adding a Configuration Object
This example shows how to add a new IP4Address object, here creating the IP address 192.168.10.10, to the
address book.
3. In the dropdown menu displayed, select IP Address
4. In the Name text box, enter myhost
5. Enter 192.168.10.10 in the IP Address textbox
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.
Command-Line Interface
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. In the dropdown menu displayed, select Delete
The row will be rendered with a strike-through line indicating that the object is marked for deletion.
52
2.1.9. Working with ConfigurationsChapter 2. Management and Maintenance
Example 2.8. Undeleting a Configuration Object
A deleted object can always be restored until the configuration has been activated and committed. This example
shows how to restore the deleted IP4Address object shown in the previous example.
Command-Line Interface
gw-world:/> undelete Address IP4Address myhost
Web Interface
1. Go to Objects > Address Book
2. Right-click on the row containing the myhost object
3. In the dropdown menu displayed, select Undo Delete
Listing Modified Objects
After modifying several configuration objects, you might want to see a list of the objects that were
changed, added and removed since the last commit.
Example 2.9. Listing Modified Configuration Objects
This example shows how to list configuration objects that have been modified.
Command-Line Interface
gw-world:/> show -changes
TypeObject
------------- ------
- IP4Addressmyhost
* ServiceTCPUDP 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. Go to Configuration > View Changes in the menu bar
A list of changes is displayed
Activating and Committing a Configuration
After changes to a configuration have been made, the configuration has to be activated for those
changes to have an impact on the running system. During the activation process, the new proposed
configuration is validated and NetDefendOS will attempt to initialize affected subsystems with the
new configuration data.
Important: Committing IPsec Changes
The administrator should be aware that if any changes that affect the configurations of
live IPsec tunnels are committed, then those live tunnels connections will be
terminated and must be re-established.
If the new configuration is validated, NetDefendOS will wait for a short period (30 seconds by
53
2.1.9. Working with ConfigurationsChapter 2. Management and Maintenance
default) during which a connection to the administrator must be re-established. As described
previously, if the configuration was activated via the CLI with the activate command then a commit
command must be issued within that period. If a lost connection could not be re-established or if the
commit command was not issued, then NetDefendOS will revert to using the previous configuration.
This is a fail-safe mechanism and, amongst others things, can help prevent a remote administrator
from locking themselves out.
Example 2.10. Activating and Committing a Configuration
This example shows how to activate and commit a new configuration.
Command-Line Interface
gw-world:/> activate
The system will validate and start using the new configuration. When the command prompt is shown again:
gw-world:/> commit
The new configuration is now committed.
Web Interface
1. Go to Configuration > Save and Activate in the menu bar
2. Click OK to confirm
The web browser will automatically try to connect back to the Web Interface after 10 seconds. If the connection
succeeds, this is interpreted by NetDefendOS as confirmation that remote management is still working. The new
configuration is then automatically committed.
Note: Changes must be committed
The configuration must be committed before changes are saved. All changes to a
configuration can be ignored simply by not committing a changed configuration.
54
2.2. Events and LoggingChapter 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. Examples of such events are the establishment and teardown
of connections, receipt of malformed packets as well as the dropping of traffic according to filtering
policies.
Whenever an event message is generated, it can be filtered and distributed to all configured EventReceivers. Multiple event receivers can be configured by the administrator, with each event receiver
having its own customizable event filter.
2.2.2. Log Messages
Event Types
NetDefendOS defines several hundred events for which log messages can be generated. The events
range from high-level, customizable, user events down to low-level and mandatory system events.
The conn_open event, for example, is a typical high-level event that generates an event message
whenever a new connection is established, given that the matching security policy rule has defined
that event messages should be generated for that connection.
An example of a low-level event would be the startup_normal event, which generates a mandatory
event message as soon as the system starts up.
Message Format
All event messages have a common format, with attributes that include category, severity and
recommended actions. These attributes enable easy filtering of messages, either within
NetDefendOS prior to sending to an event receiver, or as part of the analysis after logging and
storing messages on an external log server.
A list of all event messages can be found in the NetDefendOS Log Reference Guide. That guide also
describes the design of event messages, the meaning of severity levels and the various attributes
available.
Event Severity
The severity of each event is predefined and it can be, in order of severity, one of:
Emergency
Alert
Critical
Error
Warning
Notice
Info
Debug
55
2.2.3. Creating Log ReceiversChapter 2. Management and Maintenance
By default, NetDefendOS sends all messages of level Info and above to configured log servers. The
Debug category is intended for troubleshooting only and should only be turned on if required when
trying to solve a problem. All log messages of all severity levels are found listed in the
NetDefendOS Log Reference Guide.
2.2.3. Creating Log Receivers
To distribute and log the event messages generated by NetDefendOS, it is necessary to define one or
more event receivers that specify what events to capture, and where to send them.
NetDefendOS can distribute event messages to different types of receivers and these are enabled by
creating any of the following Log Receiver objects.
•MemoryLogReceiver
NetDefendOS has a single built in logging mechanism also known as the MemLog. This retains
all event log messages in memory and allows direct viewing of recent log messages through the
Web Interface.
This is enabled by default but can be disabled.
Thisreceivertype isdiscussedfurtherbelow inSection2.2.4,“Loggingto
MemoryLogReceiver”.
•Syslog Receiver
Syslog is the de-facto standard for logging events from network devices. If other network
devices are already logging to Syslog servers, using syslog with NetDefendOS messages can
simplify overall administration.
This receiver type is discussed further below in Section 2.2.5, “Logging to Syslog Hosts”.
2.2.4. Logging to MemoryLogReceiver
The MemoryLogReceiver (also known as Memlog) is an optional NetDefendOS feature that allows
logging direct to memory in the NetDefend Firewall instead of sending messages to an external
server. These messages can be examined through the standard user interfaces.
Memory for Logging is Limited
Memlog memory available for new messages is limited to a fixed predetermined size. When the
allocated memory is filled up with log messages, the oldest messages are discarded to make room
for newer incoming messages. This means that MemLog holds a limited number of messages since
the last system initialization and once the buffer fills they will only be the most recent. This means
that when NetDefendOS is creating large numbers of messages in systems with, for example, large
numbers of VPN tunnels, the Memlog information becomes less meaningful since it reflects a
limited recent time period.
Disabling Memory Logging
The MemoryLogReceiver object exists by default in NetDefendOS. If this receiver is not required
then it can be deleted and this type of logging will be switched off.
2.2.5. Logging to Syslog Hosts
Overview
56
2.2.6. SNMP TrapsChapter 2. Management and Maintenance
Syslog is a standardized protocol for sending log data although there is no standardized format for
the log messages themselves. The format used by NetDefendOS is well suited to automated
processing, filtering and searching.
Although the exact format of each log entry depends on how a Syslog receiver works, most are very
much alike. The way in which logs are read is also dependent on how the syslog receiver works.
Syslog daemons on UNIX servers usually log to text files, line by line.
Message Format
Most Syslog recipients preface each log entry with a timestamp and the IP address of the machine
that sent the log data:
Feb 5 2000 09:45:23 firewall.ourcompany.com
This is followed by the text the sender has chosen to send.
Feb 5 2000 09:45:23 firewall.ourcompany.com EFW: DROP:
Subsequent text is dependent on the event that has occurred.
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.
The Prio and Severity fields
The Prio= field in SysLog messages contains the same information as the Severity field
for D-Link Logger messages. However, the ordering of the numbering is reversed.
Example 2.11. Enable Logging to a Syslog Host
To enable logging of all events with a severity greater than or equal to Notice to a Syslog server with IP address
1. Go to System > Log and Event Receivers > Add > Syslog Receiver
2. Specify a suitable name for the event receiver, for example my_syslog
3. Enter 195.11.22.55 as the IP Address
4. Select an appropriate facility from the Facility list - the facility name is commonly used as a filter parameter in
most syslog daemons.
5. Click OK
The system will now be logging all events with a severity greater than or equal to Notice to the syslog server at
195.11.22.55.
Note: Syslog server configuration
The syslog server may have to be configured to receive log messages from
NetDefendOS. Please see the documentation for your specific Syslog server software
in order to correctly configure it.
57
2.2.6. SNMP TrapsChapter 2. Management and Maintenance
2.2.6. SNMP Traps
The SNMP protocol
Simple Network Management Protocol (SNMP) is a means for communicating between a Network
Management System (NMS) and a managed device. SNMP defines 3 types of messages: a Read
command for an NMS to examine a managed device, a Write command to alter the state of a
managed device and a Trap which is used by managed devices to send messages asynchronously to
an NMS about a change of state.
SNMP Traps in NetDefendOS
NetDefendOS takes the concept of an SNMP Trap one step further by allowing any event message
to be sent as an SNMP trap. This means that the administrator can set up SNMP Trap notification of
events that you consider significant for the operation of a network.
The file DFLNNN-TRAP.MIB (where NNN indicates the model number of the firewall) is provided
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). This object includes the
following parameters:
•System - The system generating the trap
•Severity - Severity of the message
•Category - What NetDefendOS subsystem is reporting the problem
•ID - Unique identification within the category
•Description - A short textual description
•Action - What action is NetDefendOS taking
This information can be cross-referenced to the Log Reference Guide.
Note: SNMP Trap standards
NetDefendOS sends SNMP Traps which are based on the SNMPv2c standard as
defined by RFC1901, RFC1905 and RFC1906.
Example 2.12. Sending SNMP Traps to an SNMP Trap Receiver
To enable generation of SNMP traps for all events with a severity greater than or equal to Alert to an SNMP trap
receiver with an IP address of 195.11.22.55, follow the steps outlined below:
2.2.7. Advanced Log SettingsChapter 2. Management and Maintenance
Web Interface
1. Go to Log & Event Receivers > Add > SNMP2cEventReceiver
2. Specify a name for the event receiver, for example my_snmp
3. Enter 195.11.22.55 as the IP Address
4. Enter an SNMP Community String if needed by the trap receiver
5. Click OK
The system will now be sending SNMP traps for all events with a severity greater than or equal to Alert to an
SNMP trap receiver at 195.11.22.55.
2.2.7. Advanced Log Settings
The following advanced settings for logging are available to the administrator:
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. The server will send back an ICMPUnreachable message, which may cause NetDefendOS to send another log message, which in turn
will result in another ICMP Unreachable message, and so on. By limiting the number of log
messages NetDefendOS sends every second, the administrator can avoid encountering such an
undesirable situation where bandwidth is consumed unnecessarily.
Default: 3600 (once per hour)
Alarm Repetition Interval
The delay in seconds between alarms when a continuous alarm is used. Minimum 0, Maximum
10,000.
Default: 60 (one minute)
-->
59
2.3. RADIUS AccountingChapter 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. The Remote Authentication Dial-in User Service (RADIUS) is an Authentication,Authorization and Accounting (AAA) protocol widely used to implement this approach and is used
by NetDefendOS to implement user accounting.
RADIUS Architecture
The RADIUS protocol is based on a client/server architecture. The NetDefend Firewall acts as the
client of the RADIUS server, creating and sending requests to a dedicated server(s). In RADIUS
terminology the firewall acts as the Network Access Server (NAS).
For user authentication, the RADIUS server receives the requests, verifies the user's information by
consulting its database, and returns either an "accept" or "reject" reply. decision to the requested
client. In RFC2866, RADIUS was extended to handle the delivery of accounting information and
this is the standard followed by NetDefendOS for user accounting. The benefits of having
centralized servers are thus extended to user connection accounting. (For details of the usage of
RADIUS for NetDefendOS authentication see Section 8.2, “Authentication Setup”).
2.3.2. RADIUS Accounting Messages
Statistics, such as number of bytes sent and received, and number of packets sent and received are
updated and stored throughout RADIUS sessions. All statistics are updated for an authenticated user
whenever a connection related to an authenticated user is closed.
When a new client session is started by a user establishing a new connection through the NetDefend
Firewall, NetDefendOS sends an AccountingRequest START message to a nominated RADIUS
server, to record the start of the new session. User account information is also delivered to the
RADIUS server. The server will send back an AccountingResponse message to NetDefendOS,
acknowledging that the message has been received.
When a user is no longer authenticated, for example, after the user logs out or the session time
expires, an AccountingRequest STOP message is sent by NetDefendOS containing the relevant
session statistics. The information included in these statistics is user configurable. The contents of
the START and STOP messages are described in detail below:
START Message Parameters
Parameters included in START messages sent by NetDefendOS are:
•Type - Marks this AccountingRequest as signalling the beginning of the service (START).
•ID - A unique identifier to enable matching of an AccountingRequest with Acct-Status-Type set
to STOP.
•User Name - The user name of the authenticated user.
•NAS IP Address - The IP address of the NetDefend Firewall.
•NAS Port - The port of the NAS on which the user was authenticated (this is a physical port and
not a TCP or UDP port).
•User IP Address - The IP address of the authenticated user. This is sent only if specified on the
60
2.3.2. RADIUS Accounting MessagesChapter 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. This can be subtracted from the time of arrival
on the server to find the approximate time of the event generating this AccountingRequest. Note
that this does not reflect network delays. The first attempt will have this parameter set to 0.
•Timestamp - The number of seconds since 1st January, 1970. Used to set a timestamp when this
packet was sent from NetDefendOS.
STOP Message Parameters
Parameters included in STOP messages sent by NetDefendOS are:
•Type - Marks this accounting request as signalling the end of a session (STOP).
•ID - An identifier matching a previously sent AccountingRequest packet, with Acct-Status-Type
set to START.
•User Name - The user name of the authenticated user.
•NAS IP Address - The IP address of the NetDefend Firewall.
•NAS Port - The port on the NAS on which the user was authenticated. (This is a physical port
and not a TCP or UDP port).
•User IP Address - The IP address of the authenticated user. This is sent only if specified on the
authentication server.
•Input Bytes - The number of bytes received by the user. (*)
•Output Bytes - The number of bytes sent by the user. (*)
•Input Packets - The number of packets received by the user. (*)
•Output Packets - The number of packets sent by the user. (*)
•Session Time - The number of seconds this session lasted. (*)
•Termination Cause - The reason why the session was terminated.
•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 - See the above comment about this parameter.
•Timestamp - The number of seconds since 1970-01-01. Used to set a timestamp when this
packet was sent from the NetDefend Firewall.
In addition, two more attributes may be sent:
•Input Gigawords - Indicates how many times the Input Bytes counter has wrapped. This is only
sent if Input Bytes has wrapped, and if the Input Bytes attribute is sent.
•Output Gigawords - Indicates how many times the Output Bytes counter has wrapped. This is
only sent if Output Bytes has wrapped, and if the Output Bytes attribute is sent.
61
2.3.3. Interim Accounting MessagesChapter 2. Management and Maintenance
Tip: The meaning of the asterisk after a list entry
The asterisk "*" symbol after an entry in the list above indicates that the sending of the
parameter is optional and is 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. An Interim Accounting Message can be seen as a snapshot of the network resources that an
authenticated user has used up until a given point. With this feature, the RADIUS server can track
how many bytes and packets an authenticated user has sent and received up until the point when the
last message was sent.
An Interim Accounting Message contains the current values of the statistics for an authenticated
user. It contains more or less the same parameters as found in an AccountingRequest Stop message,
except that the Acct-Terminate-Cause is not included (as the user has not disconnected yet).
The frequency of Interim Accounting Messages can be specified either on the authentication server,
or in NetDefendOS. Switching on the setting in NetDefendOS will override the setting on the
accounting server.
2.3.4. Activating RADIUS Accounting
In order to activate RADIUS accounting a number of steps must be followed:
•The RADIUS accounting server must be specified.
•A user authentication object must have a rule associated with it where a RADIUS server is
specified.
Some important points should be noted about activation:
•RADIUS Accounting will not function where a connection is subject to a FwdFast rule in the IP
rule set.
•The same RADIUS server does not need to handle both authentication and accounting; one
server can be responsible for authentication while another is responsible for accounting tasks.
•Multiple RADIUS servers can be configured in NetDefendOS to deal with the event when the
primary server is unreachable.
2.3.5. RADIUS Accounting Security
Communication between NetDefendOS and any RADIUS accounting server is protected by the use
of a shared secret. This secret is never sent over the network but instead a 16 byte long
Authenticator code is calculated using a one way MD5 hash function and this is used to authenticate
accounting messages.
The shared secret is case sensitive, can contain up to 100 characters, and must be typed exactly the
same for NetDefendOS and for the RADIUS server.
Messages are sent using the UDP protocol and the default port number used is 1813 although this is
user configurable.
2.3.6. RADIUS Accounting and High Availability
In an HA cluster, accounting information is synchronized between the active and passive NetDefend
62
2.3.7. Handling Unresponsive ServersChapter 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. This specifies that accounting information should
be stored for a specific authenticated user.
•A problem with accounting information synchronization could occur if an active unit has an
authenticated user for whom the associated connection times out before it is synchronized on the
inactive unit. To get around this problem, a special AccountingUpdate event is sent to the
passive unit on a timeout and this contains the most recent accounting information for
connections.
2.3.7. Handling Unresponsive Servers
A question arises in the case of a client that sends an AccountingRequest START packet which the
RADIUS server never replies to. NetDefendOS will re-send the request after the user-specified
number of seconds. This will however mean that a user will still have authenticated access while
NetDefendOS is trying to contact to the accounting server.
Only after NetDefendOS has made three attempts to reach the server will it conclude that the
accounting server is unreachable. The administrator can use the NetDefendOS advanced setting
Allow on error to determine how this situation is handled. If this setting is enabled then an already
authenticated user's session will be unaffected. If it is not enabled, any affected user will
automatically be logged out even if they have already been authenticated.
2.3.8. Accounting and System Shutdowns
In the case that the client for some reason fails to send a RADIUS AccountingRequest STOP packet,
the accounting server will never be able to update its user statistics, but will most likely believe that
the session is still active. This situation should be avoided.
In the case that the NetDefend Firewall administrator issues a shutdown command while
authenticated users are still online, the AccountingRequest STOP packet will potentially never be
sent. To avoid this, the advanced setting Logout at shutdown allows the administrator to explicitly
specify that NetDefendOS must first send a STOP message for any authenticated users to any
configured RADIUS servers before commencing with the shutdown.
2.3.9. Limitations with NAT
The User Authentication module in NetDefendOS is based on the user's IP address. Problems can
therefore occur with users who have the same IP address.
This can happen, for example, when several users are behind the same network using NAT to allow
network access through a single external IP address. This means that as soon as one user is
authenticated, traffic coming through that NAT IP address could be assumed to be coming from that
one authenticated user even though it may come from other users on the same network.
NetDefendOS RADIUS Accounting will therefore gather statistics for all the users on the network
together as though they were one user instead of individuals.
2.3.10. RADIUS Advanced Settings
The following advanced settings are available with RADIUS accounting:
Allow on error
If there is no response from a configured RADIUS accounting server when sending accounting data
for a user that has already been authenticated, then enabling this setting means that the user will
63
2.3.10. RADIUS Advanced SettingsChapter 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.
If this option is not enabled, NetDefendOS will shutdown even though there may be RADIUS
accounting sessions that have not been correctly terminated. This could lead to the situation that the
RADIUS server will assume users are still logged in even though their sessions have been
terminated.
Default: Enabled
Maximum Radius Contexts
The maximum number of contexts allowed with RADIUS. This applies to RADIUS use with both
accounting and authentication.
Default: 1024
Example 2.13. RADIUS Accounting Server Setup
This example shows configuring of a local RADIUS server known as radius-accounting with IP address
123.04.03.01 using port 1813.
Web Interface
1. Go to User Authentication > Accounting Servers > Add > Radius Server
2. Now enter:
• Name: radius-accounting
• IP Address: 123.04.03.01
• Port: 1813
• Retry Timeout: 2
• Shared Secret:enter a password
• Confirm Secret:re-enter the password
• Routing Table: main
3. Click OK
64
2.4. Hardware MonitoringChapter 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.
Configuring and performing hardware monitoring can be done either through the CLI or through the
Web Interface.
Enabling Hardware Monitoring
The System > Hardware Monitoring section of the Web Interface provides the administrator with
the following settings for enabling hardware monitoring when it is available:
Enable Sensors
Enable/disable all hardware monitoring functionality.
Default: Disabled
Poll Interval
Polling interval for the Hardware Monitor which is the delay in milliseconds between readings of
hardware monitor values.
Minimum value: 100
Maximum value: 10000
Default: 500
Using the hwm CLI Command
To get a list current values from all available sensors, the following command can be used:
gw-world:/> hwm -all
This can be abbreviated to:
gw-world:/> hwm -a
Some typical output from this command for two temperature sensors is shown below:
gw-world:/> hwm -a
NameCurrent value (unit)
-----------------------------------
SYS Temp=44.000 (C)(x)
CPU Temp=41.500 (C)(x)
Note: The meaning of "(x)"
The "(x)" at the side of each the sensor listing indicates that the sensor is enabled.
65
2.4. Hardware MonitoringChapter 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)
Each physical attribute listed on the left is given a minimum and maximum range within which it
should operate. When the value returned after polling falls outside this range, NetDefendOS
optionally generates a log message that is sent to the configured log servers.
Note: Different hardware has different sensors and ranges
Each hardware model may have a different set of sensors and a different operating
range. The above output and its values are for illustration only.
Setting the Minimum and Maximum Range
The minimum and maximum values shown in the output from the hwm command are set through
the Web Interface by going to System > Hardware Monitoring > Add and selecting the hardware
parameter to monitor. The desired operating range can then be specified.
A sensor is identified in the Web Interface by specifying a unique combination of the following
parameters:
•Type
This is the type of sensor shown in the CLI output above and is presented as a list of choices in
the Web Interface. For example, Temp.
•Sensor
This is the number of the sensor as shown in the CLI output above. For example, the SYS Temp
number is 0.
•Name
This is the Name of the sensor as shown in the CLI output above. For example, SYS Temp.
•Enabled
An individual sensor can be enabled or disabled used this setting. When enabled, an "(x)" is
displayed next to the sensor in the output from the hwm command.
66
2.5. SNMP MonitoringChapter 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. Specifically, NetDefendOS supports the following SNMP request operations by a
client:
•The GET REQUEST operation
•The GET NEXT REQUEST operation
•The GET BULK REQUEST operation (SNMP Version 2c only)
The NetDefendOS MIB
The Management Information Base (MIB) is a database, usually in the form of a file, which defines
the parameters on a network device that an SNMP client can query or change. The MIB file for a
device running NetDefendOS is distributed with the standard NetDefendOS distribution pack as a
file with the name DFLNNN-TRAP.MIB (where NNN indicates the model number of the firewall)
and this should be transferred to the hard disk of the workstation that will run the SNMP client so it
can be imported by the client software. When the client runs, the MIB file is accessed to inform the
client of the values that can be queried on a NetDefendOS device.
Defining SNMP Access
SNMP access is defined through the definition of a NetDefendOS Remote object with a Mode value
of SNMP. The Remote object requires the entry of:
•Interface - The NetDefendOS interface on which SNMP requests will arrive.
•Network - The IP address or network from which SNMP requests will come.
•Community - The community string which provides password security for the accesses.
The Community String
Security for SNMP Versions 1 and 2c is handled by the Community String which is the same as a
password for SNMP access. The Community String should be difficult to guess and therefore be
constructed in the same way that any other password, using combinations of upper and lower case
letters with digits.
Enabling an IP Rule for SNMP
The advanced setting SNMP Before Rules in the RemoteAdmin section controls if the IP rule set
checks all accesses by SNMP clients. This is by default disabled and the recommendation is to
always enable this setting.
The effect of enabling this setting is to add an invisible Allow rule at the top of the IP rule set which
automatically permits accesses on port 161 from the network and on the interface specified for
67
2.5.1. SNMP Advanced SettingsChapter 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. It is therefore advisable to have remote access take place over an encrypted VPN
tunnel or similarly secure means of communication.
Preventing SNMP Overload
The advanced setting SNMP Request Limit restricts the number of SNMP requests allowed per
second. This can help prevent attacks through SNMP overload.
Example 2.14. Enabling SNMP Monitoring
This example enables SNMP access through the internal lan interface from the network mgmt-net using the
community string Mg1RQqR. (Since the management client is on the internal network it is not required to
implement a VPN tunnel for it.)
Should it be necessary to enable SNMPBeforeRules (which is enabled by default) then the setting can be found
in System > Remote Management > Advanced Settings.
Network=mgmt-net SNMPGetCommunity=Mg1RQqR
2.5.1. SNMP Advanced Settings
The following SNMP advanced settings can be found under the Remote Management section in
the WebUI.
SNMP Before RulesLimit
Enable SNMP traffic to the firewall regardless of configured IP Rules.
68
2.5.1. SNMP Advanced SettingsChapter 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.
Default: N/A
Interface Description (SNMP)
What to display in the SNMP MIB-II ifDescr variables.
Default: Name
Interface Alias
What to display in the SNMP ifMIB ifAlias variables.
Default: Hardware
69
2.6. The pcapdump CommandChapter 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.
The packets that are filtered out by pcapdump can then be saved in a file of type .cap which is the
defacto libpcap library file format standard for packet capture.
The complete syntax of the pcapdump command is described in the CLI Reference Guide.
A Simple Example
An example of pcapdump usage is the following sequence:
gw-world:/> pcapdump -size 1024 -start int
gw-world:/> pcapdump -stop int
gw-world:/> pcapdump -show
gw-world:/> pcapdump -write int -filename=cap_int.cap
gw-world:/> pcapdump -cleanup
Going through this line by line we have:
1. Recording is started for the int interface using a buffer size of 1024 Kbytes.
gw-world:/> pcapdump -size 1024 -start int
2. The recording is stopped for the int interface.
gw-world:/> pcapdump -stop int
3. The dump output is displayed on the console in a summarized form.
gw-world:/> pcapdump -show
4. The same information is written in its complete form to a file called cap_int.cap.
gw-world:/> pcapdump -write int -filename=cap_int.cap
At this point, the file cap_int.cap should be downloaded to the management workstation for
analysis.
5. A final cleanup is performed and all memory taken is released.
gw-world:/> pcapdump -cleanup
Re-using Capture Files
Since the only way to delete files from the NetDefend Firewall is through the serial console, the
recommendation is to always use the same filename when using the pcapdump -write option. Each
new write operation will then overwrite the old file.
Running on Multiple Interfaces
70
2.6. The pcapdump CommandChapter 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.
If a clearer picture of packets flowing between interfaces is required in the output then it is best
to issue one pcapdump command with the interfaces of interest specified.
2.If no interface is specified then the capture is done on all interfaces.
3.The -stop option without an interface specified will halt capture on all interfaces.
4.pcapdump prevents capture running more than once on the same interface by detecting
command duplication.
Filter Expressions
Seeing all packets passing through a particular interface often provides an excess of information to
be useful. To focus on particular types of traffic the pcapdump command has the option to add an
filter expression which has one of the following forms:
-eth=<macaddr> - Filter on source or destination MAC address.
-ethsrc=<macaddr> - Filter on source MAC address.
-ethdest=<macaddr> - Filter on destination MAC address.
-ip=<ipaddr> - Filter source or destination IP address.
-ipsrc=<ipaddr> - Filter on source IP address.
-ipdest=<ipaddr> - Filter on destination IP address.
-port=<portnum> - Filter on source or destination port number.
-srcport=<portnum> - Filter on source port number.
-destport=<portnum> - Filter on destination port number.
-proto=<id> - Filter on protocol where id is the decimal protocol id.
-<protocolname> - Instead of the protocol number, the protocol name alone can be specified and
can be one of -tcp, -udp or -icmp.
Downloading the Output File
As shown in one of the examples above, the -write option of pcapdump can save buffered packet
information to a file on the NetDefend Firewall.
These output files are placed into the NetDefendOS root directory and the file name is specified in
the pcapdump command line, usually with a filetype of .cap. The name of output files must follow
certain rules which are described below. Files can then be downloaded to the local workstation using
Secure Copy (SCP) (see Section 2.1.6, “Secure Copy”). A list of all files in the NetDefendOS root
directory can be viewed by issuing the ls CLI command.
The -cleanup option will erase any saved pcapdump files (including any left over from earlier uses
of the command) so cleanup should only be done after file download is complete.
Note: NetDefendOS keeps track of saved files
NetDefendOS keeps track of all files created by pcapdump. This is true even between
system restarts so the -cleanup option is always able to delete all files from the
firewall's memory.
Output File Naming Restrictions
71
2.6. The pcapdump CommandChapter 2. Management and Maintenance
The name of the file used for pcapdump output must comply with the following rules:
•Excluding the filename extension, the name may not exceed 8 characters in length.
•The filename extension cannot exceed 3 characters in length.
•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.
Compatibility with Wireshark
The open source tool Wireshark (formerly called Ethereal) is an extremely useful analysis tool for
examining logs of captured packets. The industry standard .pcap file format used by pcapdump with
its -write option means that it is compatible with Wireshark.
For more complete information about this topic, see http://www.wireshark.org.
72
2.7. MaintenanceChapter 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.
To facilitate the Auto-Update feature D-Link maintains a global infrastructure of servers providing
update services for NetDefend Firewalls. To ensure availability and low response times,
NetDefendOS employs a mechanism for automatically selecting the most appropriate server to
supply updates.
For more details on these features see the following sections:
•Section 6.5, “Intrusion Detection and Prevention”
•Section 6.4, “Anti-Virus Scanning”
•Section 6.3, “Web Content Filtering”
2.7.2. Backing Up Configurations
The administrator has the ability to take a snapshot of a NetDefendOS system at a given point in
time and restore it when necessary. The snapshot can be of two types:
•A configuration backup which does not include the installed NetDefendOS version. This is
useful if the NetDefendOS version does not change.
•A system backup which is a complete backup of both the configuration and the installed
NetDefendOS software. This is useful if both the configuration is to be changed and the
NetDefendOS version upgraded.
Backup files can be created both by downloading the files directly from the NetDefend Firewall
using SCP (Secure Copy) or alternatively using the WebUI. It cannot be done though the CLI.
Operation Interruption
Backups can be created at any time without disturbing NetDefendOS operation. After restoring a
backup it is necessary to perform an Activate to make the restored configuration/system active.
Restoring and activating a configuration-only backup should not, in most cases, disturb system
operation. Complete system restore, however, is more involved and will require that NetDefendOS
reinitializes, with the loss of all existing connections. Initialization may require some seconds to
complete depending on the hardware type and normal operation will not be possible during this
time.
Backup and Restore using SCP
There are two files located in the NetDefendOS root directory:
•config.bak - This is the backup of the current configuration.
•full.bak - This is the backup of the complete system.
SCP can be used to download either of these files. When the download is complete the filename will
73
2.7.3. Restore to Factory DefaultsChapter 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.
Backup and Restore using the WebUI
As an alternative to using SCP, the administrator can initiate a backup or restore of the configuration
or complete system directly through the WebUI. The example below illustrates how this is done.
Example 2.15. Backing up the Entire System
In this example we will backup the entire system on 12 December 2008.
Web Interface
1. Go to Maintenance > Backup
2. The Backup dialog will be shown
3. Press the Backup configuration button
4. A file dialog is shown - choose a directory for the created file
5. Download of the backup file will then start
The same maintenance menu option can be used for restoring a previously created backup.
Note: Backups do not contain everything
Backups include only static information from the NetDefendOS configuration.
Dynamic information such as the DHCP server lease database or Anti-Virus/IDP
databases will not be backed up.
2.7.3. Restore to Factory Defaults
A restore to factory defaults can be applied so that it is possible to return to the original hardware
state that existed when the NetDefend Firewall was shipped by D-Link. When a restore is applied all
data such as the IDP and Anti-Virus databases are lost and must be reloaded.
Example 2.16. Complete Hardware Reset to Factory Defaults
Command-Line Interface
gw-world:/> reset -unit
Web Interface
1. Go to Maintenance > Reset
2. Select Restore the entire unit to factory defaults then confirm and wait for the restore to complete.
74
2.7.3. Restore to Factory DefaultsChapter 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. After that, release the reset button and
the unit will continue to load and startup with its default factory settings.
The IP address 192.168.1.1 will be assigned to the LAN interface.
Reset Procedure for the NetDefend DFL-1600, 1660, 2500, 2560 and 2560G
To reset the DFL-1600/1660/2500/2560/2560G models, press any key on the keypad when the
Press keypad to Enter Setup message appears on the front display. Now, select the Reset firewall
option and confirm by selecting Yes. Then wait for the reset process to complete after which the unit
will startup with its default factory settings.
The IP address 192.168.1.1 will be assigned to the default management interface LAN1 on the
DFL-1600 and DFL-2500 models. The management interface IP address for the DFL-1660,
DFL-2560 and DFL-2560G models will default to 192.168.10.1.
The default IP address factory setting for the default management interface is discussed further in
Section 2.1.3, “The Web Interface”.
Warning: Do NOT abort a reset to defaults
If the process of resetting to factory defaults is aborted before it finishes, the
NetDefend Firewall can then cease to function properly with the complete loss of all
stored user data.
End of Life Procedures
The restore to factory defaults option should also be used as part of the end of life procedure when a
NetDefend Firewall is taken out of operation and will no longer be used. As part of the
decommissioning procedure, a restore to factory defaults should always be run in order to remove
all sensitive information such as VPN settings.
As a further precaution at the end of the product's life, it also recommended that the memory media
in a NetDefend Firewall is destroyed and certified as destroyed by a suitable provider of computer
disposal services.
75
2.7.3. Restore to Factory DefaultsChapter 2. Management and Maintenance
76
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.
• The Address Book, page 77
• Services, page 82
• Interfaces, page 90
• ARP, page 108
• IP Rule Sets, page 116
• Schedules, page 126
• Certificates, page 128
• Date and Time, page 132
• DNS, page 139
3.1. The Address Book
3.1.1. Overview
The NetDefendOS Address Book contains named objects representing various types of IP addresses,
including single IP addresses, networks as well as ranges of IP addresses.
Using address book objects has a number of important benefits:
•It increases understanding of the configuration by using meaningful symbolic names.
•By defining an IP address object just once in the address book and then referencing this
definition, changing the definition automatically also changes all references to it.
3.1.2. IP Addresses
IP Address objects are used to define symbolic names for various types of IP addresses. Depending
on how the address is specified, an IP Address object can represent either a single IP address (a
specific host), a network or a range of IP addresses.
In addition, IP Address objects can be used for specifying the credentials used in user
authentication. For more information about this topic, see Chapter 8, User Authentication.
The following list presents the various types of addresses an IP Address object can hold, along with
what format that is used to represent that specific type:
Host
A single host is represented simply by its IP address.
For example, 192.168.0.14.
77
3.1.2. IP AddressesChapter 3. Fundamentals
IP Network
An IP Network is represented using Classless Inter Domain Routing (CIDR) form.
CIDR uses a forward slash and a digit (0-32) to denote the size of the network as a
postfix. This is also known as the netmask.
/24 corresponds to a class C net with 256 addresses (netmask 255.255.255.0), /27
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 with 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. Adding an IP Host
This example adds the IP host www_srv1 with IP address 192.168.10.16 to the address book:
1. Go to Objects > Address Book > Add > IP address
2. Specify a suitable name for the IP network, for example wwwsrvnet
3. Enter 192.168.10.0/24 as the IP Address
4. Click OK
Example 3.3. Adding an IP Range
78
3.1.3. Ethernet AddressesChapter 3. Fundamentals
This example adds a range of IP addresses from 192.168.10.16 to 192.168.10.21 and names the range
wwwservers:
Command-Line Interface
gw-world:/> add Address IP4Address wwwservers
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
Address=192.168.10.16-192.168.10.21
Example 3.4. Deleting an Address Object
To delete an object named wwwsrv1 in the address book, do the following:
Command-Line Interface
gw-world:/> delete Address IP4Address wwwsrv1
Web Interface
1. Go to Objects > Address Book
2. Select the address object wwwsrv1
3. Choose Delete from the menu
4. Click OK
Deleting In-use IP Objects
If an IP object is deleted that is in use by another object then NetDefendOS will not allow the
configuration to be deployed and will produce a warning message. In other words, it will appear that
the object has been successfully deleted but NetDefendOS will not allow the configuration to be
saved to the NetDefend Firewall.
3.1.3. Ethernet Addresses
Ethernet Address objects are used to define symbolic names for Ethernet addresses (also known as
MAC addresses). This is useful, for example, when populating the ARP table with static ARP
entries, or for other parts of the configuration where symbolic names are preferred over numerical
Ethernet addresses.
When specifying an Ethernet address the format aa-bb-cc-dd-ee-ff should be used. Ethernet
addresses are also displayed using this format.
Example 3.5. Adding an Ethernet Address
79
3.1.4. Address GroupsChapter 3. Fundamentals
The following example adds an Ethernet Address object named wwwsrv1_mac with the numerical MAC address
08-a3-67-bc-2e-f2.
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. The servers have IP addresses that are not in a
sequence, and can therefore not be referenced to as a single IP range. Consequently, individual IP
Address objects have to be created for each server.
Instead of having to cope with the burden of creating and maintaining separate filtering policies
allowing traffic to each server, an Address Group named, for example web-servers, could be created
with the web server hosts as group members. Now, a single policy can be used with this group,
thereby greatly reducing the administrative workload.
Address=08-a3-67-bc-2e-f2
IP Addresses Can Be Excluded
When groups are created with the Web Interface, it is possible to not only add address objects to a
group but also to explicitly exclude addresses from the group. However, exclusion is not possible
when creating groups with the CLI.
For example, if a network object is the network 192.168.2.0/24 and this is added to a group, it is
possible to then explicitly exclude the IP address 192.168.2.1. This means that the group will then
contain the range 192.168.2.2 to 192.168.2.255.
Groups Can Contain Different Subtypes
Address Group objects are not restricted to contain members of the same subtype. IP host objects
can be teamed up with IP ranges, IP networks and so on. All addresses of all group members are
then combined by NetDefendOS, effectively resulting in the union of all the addresses.
For example, if a group contains the following two IP address ranges:
•192.168.0.10 - 192.168.0.15
•192.168.0.14 - 192.168.0.19
The result of combining these two will be a single address range containing 192.168.0.10 -
192.168.0.19.
80
3.1.6. Address Book FoldersChapter 3. Fundamentals
3.1.5. Auto-Generated Address Objects
To simplify the configuration, a number of address objects in the address book are automatically
created by NetDefendOS when the system starts for the first time and these objects are used in
various parts of the initial configuration.
The following address objects are auto-generated:
Interface Addresses
Default Gateway
all-nets
For each Ethernet interface in the system, two IP Address objects are
predefined; one object for the IP address of the actual interface, and
one object representing the local network for that interface.
Interface IP address objects are named <interface-name>_ip and
network objects are named <interface-name>_net. As an example,
an interface named lan will have an associated interface IP object
named lan_ip, and a network object named lannet.
An IP Address object named wan_gw is auto-generated and
represents the default gateway of the system. The wan_gw object is
used primarily by the routing table, but is also used by the DHCP
client subsystem to store gateway address information acquired from
a DHCP server. If a default gateway address has been provided
during the setup phase, the wan_gw object will contain that address.
Otherwise, the object will be left empty (in other words, the IP
address will be 0.0.0.0/0).
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. Address Book Folders
In order to help organise large numbers of entries in the address book, it is possible to create address
book folders. These folders are just like a folder in a computer's file system. They are created with a
given name and can then be used to contain all the IP address objects that are related together as a
group.
Using folders is simply a way for the administrator to conveniently divide up address book entries
and no special properties are given to entries in different folders. NetDefendOS continues to see all
entries as though they were in large table of IP address objects.
The folder concept is also used by NetDefendOS in other contexts such as IP rule sets, where related
IP rules can be grouped together in administrator created folders.
81
3.2. ServicesChapter 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 which is
associated with a specific source and/or destination port number(s). For example, the HTTP service
is defined as using the TCP protocol with the associated destination port 80 and any source port.
However, service objects are not restricted to just the TCP or UDP protocols. They can be used to
encompass ICMP messages as well as a user-definable IP protocol.
A Service is Passive
Services are passive NetDefendOS objects in that they do not themselves carry out any action in the
configuration. Instead, service objects must be associated with the security policies defined by
various NetDefendOS rule sets and then act as a filter to apply those rules only to a specific type of
traffic.
For example, an IP rule in a NetDefendOS IP rule set has a service object associated with it as a
filtering parameter to decide whether or not to allow a specific type of traffic to traverse the
NetDefend Firewall. Inclusion in IP rules is one the most important usage of service objects and it is
also how ALGs become associated with IP rules since an ALG is associated with a service and not
directly with an IP rule.
For more information on how service objects are used with IP rules, see Section 3.5, “IP Rule Sets”.
Predefined Services
A large number of service objects are predefined in NetDefendOS. These include common services
such as HTTP, FTP, Telnet and SSH.
Predefined services can be used and also modified just like custom, user defined services. However,
it is recommended to NOT make any changes to predefined services and instead create custom
services with the desired characteristics.
Custom service creation in detail later in Section 3.2.2, “Creating Custom Services”.
Example 3.6. Listing the Available Services
To produce a listing of the available services in the system:
Command-Line Interface
gw-world:/> show Service
The output will look similar to the following listing with the services grouped by type with the service groups
appearing first:
ServiceGroup
NameComments
------------ -------------------------------------------------all_services All ICMP, TCP and UDP services
all_tcpudpAll TCP and UDP services
ipsec-suiteThe IPsec+IKE suite
l2tp-ipsecL2TP using IPsec for encryption and authentication
l2tp-rawL2TP control and transport, unencrypted
pptp-suitePPTP control and transport
2. Select the specific service object in the table
3. A listing all services will be presented
Property Value
Name: echo
SourcePorts: 0-65535
MaxSessions: 1000
Type: TCPUDP (TCP/UDP)
ALG: (none)
Comments: Echo service
3.2.2. Creating Custom Services
If the list of predefined NetDefendOS service objects does not meet the requirements for certain
traffic then a new service can be created. Reading this section will explain not only how new
services are created but also provides an understanding of the properties of predefined services.
The Type of service created can be one of the following:
•TCP/UDP Service - A service based on the UDP or TCP protocol or both. This type of service
is discussed further in this section.
•ICMP Service - A service based on the ICMP protocol. This is discussed further in
Section 3.2.3, “ICMP Services”.
•IP Protocol Service - A service based on a user defined protocol. This is discussed further in
Section 3.2.4, “Custom IP Protocol Services”.
•Service Group - A service group consisting of a number of services. This is discussed further in
Let us now take a closer look at TCP/UDP services.
TCP and UDP Based Services
Most applications use TCP and/or UDP as transport protocol for transferring data over IP networks.
Transmission Control Protocol (TCP) is a connection-oriented protocol that includes mechanisms
for reliable point to point transmission of data. TCP is used by many common applications where
error-free transfers are mandatory, such as HTTP, FTP and SMTP.
UDP Orientated Applications
For applications where data delivery speed is of greatest importance, for example with streaming
audio and video, the User Datagram Protocol (UDP) is the preferred protocol. UDP is
connectionless, provides minimal transmission error recovery, and has a much lower overhead when
compared with TCP. Due to the lower overhead, UDP is also used for some non-streaming services
and in those cases the applications themselves must provide any error recovery mechanisms.
TCP and UDP Service Definition
To define a TCP or UDP based protocol to NetDefendOS, a TCP/UDP service object is used. Apart
from a unique name describing the service, the object contains information about what protocol
(TCP, UDP or both) and what source and destination ports are applicable for the service.
Specifying Port Numbers
Port numbers are specified with all types of services and it is useful to understand how these can be
entered in user interfaces. They can be specified for both the Source Port and/or the DestinationPort of a service in the following ways:
Single Port
Port Ranges
Multiple Ports and Port Ranges
For many services, a single destination port is sufficient. For
example, HTTP usually uses destination port 80. The SMTP
protocol uses port 25 and so on. For these types of service,
the single port number is simply specified in the service
definition as a single number.
Some services use a range of destination ports. As an
example,the NetBIOSprotocol usedby 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 ranges or individual ports may also be entered,
separated by commas. This provides the ability to cover a
wide range of ports using only a single TCP/UDP service
object.
For example, all Microsoft Windows networking can be
covered using a port definition specified as 135-139,445.
HTTP and HTTPS can be covered by specifying destination
ports 80,443.
It is usual with many services that the source ports are left as their default value which
is the range 0-65535 (corresponding to all possible source ports).
With certain application, it can be useful to also specify the source port if this is
always within a limited range of values. Making the service definition as narrow as
possible is the recommended approach.
Other Service Properties
Apart from the basic protocol and port information, TCP/UDP service objects also have several
other properties:
•SYN Flood Protection
This option allows a TCP based service to be configured with protection against SYN Flood
attacks. This option only exists for the TCP/IP service type.
For more details on how this feature works see Section 6.6.8, “TCP SYN Flood Attacks”.
•Pass ICMP Errors
If an attempt to open a TCP connection is made by a user application behind the NetDefend
Firewall and the remote server is not in operation, an ICMP error message is returned as the
response. Such ICMP messages are interpreted by NetDefendOS as new connections and will be
dropped unless an IP rule explicitly allows them.
The Pass returned ICMP error messages from destination option allows such ICMP
messages to be automatically passed back to the requesting application. In some cases, it is
useful that the ICMP messages are not dropped. For example, if an ICMP quench message is
sent to reduce the rate of traffic flow. On the other hand, dropping ICMP messages increases
security by preventing them being used as a means of attack.
•ALG
A TCP/UDP service can be linked to an Application Layer Gateway (ALG) to enable deeper
inspection of certain protocols. This is the way that an ALG is associated with an IP rule. First,
associate the ALG with a service and then associate the service with an IP rule.
For more information on this topic 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. If the default is, for example 100, this would mean that only 100
connections are allowed in total for this service across all interfaces.
For a service involving, for example, an HTTP ALG the default value can often be too low if
there are large numbers of clients connecting through the NetDefend Firewall. It is therefore
recommended to consider if a higher value is required for a particular scenario.
Specifying All Services
When setting up rules that filter by services it is possible to use the service object called all_services
85
3.2.3. ICMP ServicesChapter 3. Fundamentals
to refer to all protocols. However, using this is not recommended and specifying a narrower service
provides better security.
If, for example, the requirement is only to filter using the principal protocols of TCP, UDP and
ICMP then the service group all_tcpudpicmp can be used instead.
Tip: The http-all service does not include DNS
A common mistake is to assume that the predefined service http-all includes the DNS
protocol. It does not so the predefined service dns-all is usually also required for most
web surfing. This could be included in a group with http-all and then associated with
the IP rules that allow web surfing.
Restrict Services to the Minimum Necessary
When choosing a service object to construct a policy such as an IP rule, the protocols included in
that object should be as few as necessary to achieve the traffic filtering objective. Using the
all_services object may be convenient but removes any security benefits that a more specific service
object could provide.
The best approach is to narrow the service filter in a security policy so it allows only the protocols
that are absolutely necessary. The all_tcpudpicmp service object is often a first choice for general
traffic but even this may allow many more protocols than are normally necessary and the
administrator can often narrow the range of allowed protocols further.
Example 3.8. Creating a Custom TCP/UDP Service
This example shows how to add a TCP/UDP service, using destination port 3306, which is used by MySQL:
Command-Line Interface
gw-world:/> add Service ServiceTCPUDP MySQL
Web Interface
1. Go to Objects > Services > Add > TCP/UDP service
2. Specify a suitable name for the service, for example MySQL
3. Now enter:
• Type: TCP
• Source: 0-65535
• Destination: 3306
4. Click OK
3.2.3. ICMP Services
DestinationPorts=3306 Type=TCP
Another type of custom service that can be created is an ICMP Service.
The Internet Control Message Protocol (ICMP) is a protocol that is integrated with IP for error
reporting and transmitting control information. For example, the ICMP Ping feature uses ICMP to
test Internet connectivity.
ICMP Types and Codes
86
3.2.4. Custom IP Protocol ServicesChapter 3. Fundamentals
ICMP messages are delivered in IP packets, and includes a Message Type that specifies the format
of the ICMP message and a Code that is used to further qualify the message. For example, the
message type Destination Unreachable uses the Code parameter to specify the exact reason for the
error.
Either all ICMP message types can be accepted by a service (there are 256 possible types) or it is
possible to filter the types.
Specifying Codes
If a type is selected then the codes for that type can be specified in the same way that port numbers
are specified. For example, if the Destination Unreachable type is selected with the comma
deliminated code list 0,1,2,3 then this will filter Network unreachable, Host unreachable, Protocolunreachable and Port unreachable.
When a message type is selected but no code values are given then all codes for that type is
assumed.
ICMP Message Types
The message types that can be selected are as follows:
Echo Request
Destination Unreachable
Redirect
Sent by PING to a destination in order to check connectivity.
The source is told that a problem has occurred when delivering
a packet. There are codes from 0 to 5 for this type:
•Code 0: Net Unreachable
•Code 1: Host Unreachable
•Code 2: Protocol Unreachable
•Code 3: Port Unreachable
•Code 4: Cannot Fragment
•Code 5: Source Route Failed
The source is told that there is a better route for a particular
packet. Codes assigned are as follows:
•Code 0: Redirect datagrams for the network
•Code 1: Redirect datagrams for the host
•Code 2: Redirect datagrams for the Type of Service and the
network
•Code 3: Redirect datagrams for the Type of Service and the
host
Parameter Problem
Echo Reply
Source Quenching
Time Exceeded
Identifies an incorrect parameter on the datagram.
The reply from the destination which is sent as a result of the
Echo Request.
The source is sending data too fast for the receiver, the buffer
has filled up.
The packet has been discarded as it has taken too long to be
delivered.
87
3.2.5. Service GroupsChapter 3. Fundamentals
3.2.4. Custom IP Protocol Services
Services that run over IP and perform application/transport layer functions can be uniquely
identified by IP protocol numbers. IP can carry data for a number of different protocols. These
protocols are each identified by a unique IP protocol number specified in a field of the IP header.
For example, ICMP, IGMP and EGP have protocol numbers 1, 2 and 8 respectively.
Similar to the TCP/UDP port ranges described previously, a range of IP protocol numbers can be
used to specify multiple applications for one service. For example, specifying the range 1-4,7 will
match the protocols ICMP, IGMP, GGP, IP-in-IP and CBT.
IP protocol numbers
The currently assigned IP protocol numbers and references are published by the Internet Assigned
Numbers Authority (IANA) and can be found at:
http://www.iana.org/assignments/protocol-numbers
Example 3.9. Adding an IP Protocol Service
This example shows how to add an IP Protocol service, with the Virtual Router Redundancy Protocol.
Command-Line Interface
gw-world:/> add Service ServiceIPProto VRRP IPProto=112
Web Interface
1. Go to Objects > Services > Add > IP protocol service
2. Specify a suitable name for the service, for example VRRP
3. Enter 112 in the IP Protocol control
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 since the group can be used instead of an individual service.
The Advantage of Groups
For example, there may be a need for a set of IP rules that are identical to each other except for the
service parameter. By defining a service group which contains all the service objects from all the
individual rules, we can replace all of them with just one IP rule that uses the group.
Suppose that we create a service group called email-services which combines the three services
objects for SMTP, POP3 and IMAP. Now only one IP rule needs to be defined that uses this group
service to allow all email related traffic to flow.
Groups Can Contain Other Groups
When a group is defined then it can contain individual services and/or service groups. This ability to
have groups within groups should be used with caution since it can increase the complexity of a
88
3.2.6. Custom Service TimeoutsChapter 3. Fundamentals
configuration and decrease the ability to troubleshoot problems.
3.2.6. Custom Service Timeouts
Any service can have its custom timeouts set. These can also be set globally in NetDefendOS but it
is more usual to change these values individually in a custom service.
The timeout settings that can be customized are as follows:
•Initial Timeout
This is the time allowed for a new connection to be open.
•Establish (Idle) Timeout
If there is no activity on a connection for this amount of time then it is considered to be closed
and is removed from the NetDefendOS state table. The default setting for this time with
TCP/UDP connections is 3 days.
•Closing Timeout
The is the time allowed for the connection to be closed.
The administrator must make a judgement as what the acceptable values should be for a particular
protocol. This may depend, for example, on the expected responsiveness of servers to which clients
connect.
89
3.3. InterfacesChapter 3. Fundamentals
3.3. Interfaces
3.3.1. Overview
An Interface is an important logical building block in NetDefendOS. All network traffic that transits
through, originates from or is terminated in the NetDefend Firewall, does so through one or more
interfaces.
Source and Destination Interfaces
An interface can be viewed as a doorway through which network traffic passes to or from
NetDefendOS. A NetDefendOS interface has one of two functions:
•The Source Interface
When traffic arrives through an interface, that interface is referred to in NetDefendOS as the
source interface (also sometimes known as the receiving or incoming interface).
•The Destination Interface
When traffic leaves after being checked against NetDefendOS's security policies, the interface
used to send the traffic is referred to in NetDefendOS as the destination interface (also
sometimes known as the sending interface).
All traffic passing through NetDefendOS has both a source and destination interface. As explained
in more depth later, the special logical interface core is used when NetDefendOS itself is the source
or destination for traffic.
Interface Types
NetDefendOS supports a number of interface types, which can be divided into the following four
major groups:
•Ethernet Interfaces
Each Ethernet interface represents a physical Ethernet port on a NetDefendOS-based product.
All network traffic that originates from or enters a NetDefend Firewall will pass through one of
the physical interfaces.
NetDefendOS currently supports Ethernet as the only physical interface type. For more
information about Ethernet interfaces, see Section 3.3.2, “Ethernet Interfaces”.
•Sub-interfaces
Some interfaces require a binding to an underlying physical interface in order to transfer data.
This group of interfaces is called Physical Sub-Interfaces.
NetDefendOS has support for two types of sub-interfaces:
•Virtual LAN (VLAN) interfaces as specified by IEEE 802.1Q. When routing IP packets over
a Virtual LAN interface, they will be encapsulated in VLAN-tagged Ethernet frames. For
more information about Virtual LAN interfaces, please see Section 3.3.3, “VLAN”.
•PPPoE (PPP-over-Ethernet) interfaces for connections to PPPoE servers. More information
about this topic can be found in Section 3.3.4, “PPPoE”.
•Tunnel Interfaces
90
3.3.1. OverviewChapter 3. Fundamentals
Tunnel interfaces are used when network traffic is being tunneled between the system and
another tunnel end-point in the network, before it gets routed to its final destination. VPN
tunnels are often used to implement virtual private networks (VPNs) which can secure
communication between two firewalls.
To accomplish tunneling, additional headers are added to the traffic that is to be tunneled.
Furthermore, various transformations can be applied to the network traffic depending on the type
of tunnel interface. For example, when routing traffic over an IPsec interface, the payload is
usually encrypted to achieve confidentiality.
NetDefendOS supports the following tunnel interface types:
i.IPsec interfaces are used as end-points for IPsec VPN tunnels. More information about this
topic can be found in Section 9.3, “IPsec Components”.
ii.PPTP/L2TP interfaces are used as end-points for PPTP or L2TP tunnels. More information
about this topic can be found in Section 9.5, “PPTP/L2TP”.
iii. GRE interfaces are used to establish GRE tunnels. More information about this topic can be
found in Section 3.3.5, “GRE Tunnels”.
All Interfaces are Logically Equivalent
Even though the different types of interfaces may be very different in the way they function,
NetDefendOS treats all interfaces as logically equivalent. This is an important and powerful concept
and means that all types of interfaces can be used almost interchangeably in the various
NetDefendOS rule sets and other configuration objects. This results in a high degree of flexibility in
how traffic can be examined, controlled and routed.
Interfaces have Unique Names
Each interface in NetDefendOS is given a unique name to be able to identify and select it for use
with other NetDefendOS objects in a configuration. Some interface types, such as physical Ethernet
interfaces, are already provided by NetDefendOS with relevant default names that are possible to
modify if required. New interfaces defined by the administrator will always require a user-provided
name to be specified.
Warning
If an interface definition is removed from a NetDefendOS configuration, it is important
to first remove or change any references to that interface. For example, rules in the IP
rule set that refer to that interface should be removed or changed.
The any and core Interfaces
In addition, NetDefendOS provides two special logical interfaces which are named any and core.
The meaning of these are:
•any represents all possible interfaces including the core interface.
•core indicates that it is NetDefendOS itself that will deal with traffic to and from this interface.
Examples of the use of core are when the NetDefend Firewall acts as a PPTP or L2TP server or
responds to ICMP "Ping" requests. By specifying the Destination Interface of a route as core,
NetDefendOS will then know that it is itself that is the ultimate destination of the traffic.
Disabling an Interface
91
3.3.2. Ethernet InterfacesChapter 3. Fundamentals
Should it be desirable to disable an interface so that no traffic can flow through it, this can be done
with the CLI using the command:
gw-world:/> set Interface Ethernet <interface-name> -disable
Where <interface-name> is the interface to be disabled.
To re-enable an interface, the command is:
gw-world:/> set Interface Ethernet <interface-name> -enable
3.3.2. Ethernet Interfaces
The IEEE 802.3 Ethernet standard allows various devices to be attached at arbitrary points or
"ports" to a physical transport mechanism such as a coaxial cable. Using the CSMA/CD protocol,
each Ethernet connected device "listens" to the network and sends data to another connected device
when no other is sending. If 2 devices broadcast simultaneously, algorithms allow them to re-send at
different times.
Ethernet Frames
Devices broadcast data as Ethernet frames and other devices "listen" to determine if they are the
intended destination for any of these frames. A frame is a sequence of bits which specify the
originating device plus the destination device plus the data payload along with error checking bits.
A pause between the broadcasting of individual frames allows devices time to process each frame
before the next arrives and this pause is progressively smaller with the faster data transmission
speeds found in normal Ethernet, then Fast Ethernet and finally Gigabit Ethernet.
Physical Ethernet Interfaces
Each logical 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. Such additional ports are seen as a single interface by NetDefendOS.
Ethernet Interface Parameters
The following are the various parameters that can be set for an Ethernet interface:
•Interface Name
The names of the Ethernet interfaces are predefined by the system, and are mapped to the names
of the physical ports; a system with a wan port will have an Ethernet interface named wan and so
on.
The names of the Ethernet interfaces can be changed to better reflect their usage. For example, if
an interface named dmz is connected to a wireless LAN, it might be convenient to change the
interface name to radio. For maintenance and troubleshooting, it is recommended to tag the
corresponding physical port with the new name.
Note: Interface enumeration
The startup process will enumerate all available Ethernet interfaces. Each
92
3.3.2. Ethernet InterfacesChapter 3. Fundamentals
interface will be given a name of the form lanN, wanN and dmz, where N
represents the number of the interface if your NetDefend Firewall has more than
one of these interfaces. In most of the examples in this guide lan is used for LAN
traffic and wan is used for WAN traffic. If your NetDefend Firewall does not have
these interfaces, please substitute the references with the name of your chosen
interface.
•IP Address
Each Ethernet interface is required to have an Interface IP Address, which can be either a static
address or an address provided by DHCP. The interface IP address is used as the primary
address for communicating with the system through the specific Ethernet interface.
NetDefendOS IP4 Address objects are usually used to define the IP addresses of Ethernet
interfaces. Those objects are normally auto-generated by the system. For more information,
please see Section 3.1.5, “Auto-Generated Address Objects”.
Tip: Specifying multiple IP addresses on an interface
Multiple IP addresses can be specified for an Ethernet interface by using the ARP
Publish feature. (For more information, see Section 3.4, “ARP”).
•Network
In addition to the interface IP address, a Network address is also specified for an Ethernet
interface. The Network address provides information to NetDefendOS about what IP addresses
are directly reachable through the interface. In other words, those residing on the same LAN
segment as the interface itself. In the routing table associated with the interface, NetDefendOS
will automatically create a direct route to the specified network over the actual interface.
•Default Gateway
A Default Gateway address can optionally be specified for an Ethernet interface. This is a
normally the address of a router and very often the router which acts as the gateway to the
Internet.
Normally, only one default all-nets route to the default gateway needs to exist in the routing
table.
•Enable DHCP Client
NetDefendOS includes a DHCP client feature for dynamic assignment of address information by
a connected DHCP server. This feature is often used for receiving external IP address
information from an ISP's DHCP server for public Internet connection.
The information that can be set using DHCP includes the IP address of the interface, the local
network that the interface is attached to, and the default gateway.
All addresses received from the DHCP server are assigned to corresponding IP4Address objects.
In this way, dynamically assigned addresses can be used throughout the configuration in the
same way as static addresses. By default, the objects in use are the same ones as defined in
Section 3.1.5, “Auto-Generated Address Objects”.
By default, DHCP is disabled on Ethernet interfaces. If the interface is being used for connection
to the public Internet via an ISP using fixed IP addresses then DHCP shouldn't be used.
DNS server addresses received through DHCP on an interface named <interface-name> will be
93
3.3.2. Ethernet InterfacesChapter 3. Fundamentals
allocated to NetDefendOS address objects with the names <interface-name>_dns1 and
<interface-name>_dns2.
Note: A gateway IP cannot be deleted with DHCP enabled
If DHCP is enabled for a given Ethernet interface then any gateway IP address
that is defined for that interface cannot be deleted. To remove the gateway address,
the DHCP option must be first disabled.
If DHCP is enabled then there is a set of interface specific advanced settings:
i.A preferred IP address can be requested.
ii.A preferred lease time can be requested.
iii. Static routes can be sent from the DHCP server.
iv. Do not allow IP address collisions with static routes.
v.Do not allow network collisions with static routes.
vi. Specify an allowed IP address for the DHCP lease.
vii. Specify an address range for DHCP servers from which leases will be accepted.
•DHCP Hostname
In some, infrequent cases a DHCP server may require a hostname to be sent by the DHCP client.
•Enable Transparent Mode
The recommended way to enable Transparent Mode is to add switch routes, as described in
Section 4.7, “Transparent Mode”. An alternative method is to enable transparent mode directly
on an interface with this option.
When enabled, default switch routes are automatically added to the routing table for the
interface and any corresponding non-switch routes are automatically removed.
•Hardware Settings
In some circumstances it may be necessary to change hardware settings for an interface. The
available options are:
i.The speed of the link can be set. Usually this is best left as Auto.
ii.The MAC address can be set if it needs to be different to the MAC address inbuilt into the
hardware. Some ISP connections might require this.
•Virtual Routing
To implement virtual routing where the routes related to different interfaces are kept in separate
routing table, there are a number of options:
i.Make the interface a member of all routing tables. This option is enabled by default and
means that traffic arriving on the interface will be routed according to the main routing
table. Routes for the interface IP will be inserted into all routing tables.
ii.The alternative to the above is to insert the route for this interface into only a specific
routing table. The specified routing table will be used for all route lookups unless
overridden by a routing rule.
•Automatic Route Creation
94
3.3.2. Ethernet InterfacesChapter 3. Fundamentals
Routes can be automatically added for the interface. This addition can be of the following types:
i.Add a route for this interface for the given network. This is enabled by default.
ii.Add a default route for this interface using the given default gateway. This is enabled by
default.
•MTU
This determines the maximum size of packets in bytes that can be sent on this interface. By
default, the interface uses the maximum size supported.
•High Availability
There are two options which are specific to high availability clusters:
1.A private IP address can be specified for this interface.
2.An additional option is to disable the sending of HA cluster heartbeats from this interface.
•Quality Of Service
The option exists to copy the IP DSCP precedence to the VLAN priority field for any VLAN
packets. This is disabled by default.
Changing the IP Address of an Ethernet Interface
To change the IP address on an interface, we can use one of two methods:
•Change the IP address directly on the interface. For example, if we want to change the IP
address of the lan interface to 10.1.1.2, we could use the CLI command:
gw-world:/> set Interface Ethernet lan IP=10.1.1.2
As explained next, this way of changing the IP address is not recommended.
•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.1, “Useful CLI Commands for Ethernet Interfaces”.
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.
To show the current interface assigned to the IP address wan_ip:
gw-world:/> show Address IP4Address InterfaceAddresses/wan_ip
95
3.3.2. Ethernet InterfacesChapter 3. Fundamentals
------------------------------------------------
UserAuthGroups:<empty>
NoDefinedCredentials:No
To show the current interface assigned to the network wan_net:
gw-world:/> show Address IP4Address InterfaceAddresses/wan_net
---------------------------------------------
UserAuthGroups:<empty>
NoDefinedCredentials:No
To show the current interface assigned to the gateway wan_gw:
gw-world:/> show Address IP4Address InterfaceAddresses/wan_gw
Here, tab completion is used again at the end of the command line:
gw-world:/> set Address IP4Address<tab>
[<Category>] <Type> [<Identifier>]:
dnsserver1_ipInterfaceAddresses/wan_br timesyncsrv1_ip
InterfaceAddresses/aux_ipInterfaceAddresses/wan_dns1
InterfaceAddresses/aux_net InterfaceAddresses/wan_dns2
InterfaceAddresses/dmz_ipInterfaceAddresses/wan_gw
InterfaceAddresses/dmz_net InterfaceAddresses/wan_ip
InterfaceAddresses/lan_ipInterfaceAddresses/wan_net
InterfaceAddresses/lan_net Server
The CLI can be used to set the address of the interface:
gw-world:/> set Address IP4Address
InterfaceAddresses/wan_ip Address=172.16.5.1
Modified IP4Address InterfaceAddresses/wan_ip.
The CLI can be used to enable DHCP on the interface:
gw-world:/> set Interface Ethernet wan DHCPEnabled=yes
96
3.3.3. VLANChapter 3. Fundamentals
Modified Ethernet wan.
Some interface settings are accessible only through a related set of CLI commands. These are
particularly useful if D-Link hardware has been replaced and Ethernet card settings are to be
changed, or if configuring the interfaces when running NetDefendOS on non-D-Link hardware. For
example, to display Ethernet port information use the command:
gw-world:/> show EthernetDevice
This command shows all Ethernet interfaces defined. This list includes those interfaces deleted but
before an activate has been done. Deletions will be indicated with a "-" symbol before their name. If
a deleted interface in the list is to be restored, this can be done with the undelete command:
gw-world:/> undelete EthernetDevice <interface>
The following command can also be used to list interface information:
gw-world:/> show Ethernet Interface
The set command can be used to control an Ethernet interface. For example, to enable an interface
lan we can use the command:
gw-world:/> set EthernetDevice lan -enable
To set the driver on an Ethernet interface card the command is:
gw-world:/> set EthernetDevice lan EthernetDriver=<driver>
For example, if the driver name is IXP4NPEEthernetDriver for the bus, slot, port combination 0, 0,
2 on the wan interface, the set command would be:
gw-world:/> set EthernetDevice lan
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. A typical application is to allow one Ethernet
interface to appear as many separate interfaces. This means that the number of physical Ethernet
ports on a NetDefend Firewall need not limit how many totally separated external networks can be
connected.
Another typical usage of VLANs is to group together clients in an organisation so that the traffic
belonging to different groups is kept completely separate in different VLANs. Traffic can then only
flow between the different VLANs under the control of NetDefendOS and is filtered using the
security policies described by the NetDefendOS rule sets.
97
3.3.3. VLANChapter 3. Fundamentals
As explained in more detail below, VLAN configuration with NetDefendOS involves a combination
of VLAN trunks from the NetDefend Firewall to switches and these switches are configured with
port based VLANs on their interfaces. Any physical firewall interface can, at the same time, carry
both non-VLAN traffic as well VLAN trunk traffic for one or multiple VLANs.
VLAN Processing
NetDefendOS follows the IEEE 802.1Q specification. The specifies how VLAN functions by
adding a Virtual LAN Identifier (VLAN ID) to Ethernet frame headers which are part of a VLAN's
traffic.
The VLAN ID is a number between 0 and 4095 which is used to identify the specific Virtual LAN
to which each frame belongs. With this mechanism, Ethernet frames can belong to different Virtual
LANs but can still share the same physical Ethernet link.
The following principles underlie the NetDefendOS processing of VLAN tagged Ethernet frames at
a physical interface:
•Ethernet frames received on a physical interface by NetDefendOS, are examined for a VLAN
ID. If a VLAN ID is found and a matching VLAN interface has been defined for that interface,
NetDefendOS will use the VLAN interface as the logical source interface for further rule set
processing.
•If there is no VLAN ID attached to an Ethernet frame received on an interface then the source of
the frame is considered to be the physical interface and not a VLAN.
•If VLAN tagged traffic is received on a physical interface and there is no VLAN defined for that
interface in the NetDefendOS configuration with a corresponding VLAN ID then that traffic is
dropped by NetDefendOS and an unknown_vlanid log message is generated.
•The VLAN ID must be unique for a single NetDefendOS physical interface but the same VLAN
ID can be used on more than one physical interface. In other words, a same VLAN can span
many physical interfaces.
•A physical interface does not need to be dedicated to VLANs and can carry a mixture of VLAN
and non-VLAN traffic.
Physical VLAN Connection with VLAN
The illustration below shows the connections for a typical NetDefendOS VLAN scenario.
98
3.3.3. VLANChapter 3. Fundamentals
Figure 3.1. VLAN Connections
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 a port is connected to. The port on the switch that connects to the firewall
should be configured to accept the VLAN IDs that will flow through the trunk.
In the illustration above the connections between the interfaces if1 and if2 to the switches
Switch1 and Switch2 are VLAN trunks.
•Other ports on the switch that connect to VLAN clients are configured with individual VLAN
IDs. Any device connected to one of these ports will then automatically become part of the
VLAN configured for that port. In Cisco switches this is called configuring a Static-accessVLAN.
On Switch1 in the illustration above, one interface is configured to be dedicated to VLAN1 and
two others are dedicated to VLAN2.
The switch could also forward trunk traffic from the firewall into another trunk if required.
•More than one interface on the firewall can carry VLAN trunk traffic and these will connect to
separate switches. More than one trunk can be configured to carry traffic with the same VLAN
ID.
Note: 802.1ad is not supported
NetDefendOS does not support the IEEE 802.1ad (provider bridges) standard which
allows VLANs to be run inside other VLANs.
99
3.3.3. VLANChapter 3. Fundamentals
License Limitations
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
Below are the key steps for setting up a VLAN interface.
1.Assign a name to the VLAN interface.
2.Select the physical interface for the VLAN.
3.Assign a VLAN ID that is unique on the physical interface.
4.Optionally specify an IP address for the VLAN.
5.Optionally specify an IP broadcast address for the VLAN.
6.Create the required route(s) for the VLAN in the appropriate routing table.
7.Create rules in the IP rule set to allow traffic through on the VLAN interface.
It is important to understand that the administrator should treat a VLAN interface just like a physical
interface in that they require both appropriate IP rules and routes to exist in the NetDefendOS
configuration for traffic to flow through them. For example, if no IP rule with a particular VLAN
interface as the source interface is defined allowing traffic to flow then packets arriving on that
interface will be dropped.
VLAN advanced settings
There is a single advanced setting for VLAN:
Unknown VLAN Tags
What to do with VLAN packets tagged with an unknown ID.
Default: DropLog
Example 3.10. Defining a VLAN
This simple example defines a virtual LAN called VLAN10 with a VLAN ID of 10. The IP address of the VLAN is
assumed to be already defined in the adress book as the object vlan10_ip.