D-Link DFL-1660 Operation & User’s Manual

Security Security DFL-210/ 800/1600/ 2500 DFL-260/ 860/1660/ 2560(G) Ver. 1.10 Network Security Firewall User Manual

D-Link Corporation No. 289, Sinhu 3rd Rd, Neihu District, Taipei City 114, Taiwan R.O.C. http://www.DLink.com Published 2009-09-08

Published 2009-09-08 Copyright Notice This publication, including all photographs, illustrations and software, is protected under international copyright laws, with all rights reserved. Neither this manual, nor any of the material contained herein, may be reproduced without the written consent of D-Link. Disclaimer The information in this document is subject to change without notice. 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.

Preface ...............................................................................................................12 1. NetDefendOS Overview ....................................................................................14 1.1. Features ................................................................................................14 1.2. NetDefendOS Architecture ......................................................................17 1.2.1. State-based Architecture ...............................................................17 1.2.2. NetDefendOS Building Blocks .......................................................17 1.2.3. Basic Packet Flow ........................................................................18 1.3. NetDefendOS State Engine Packet Flow .....................................................20 2. Management and Maintenance ............................................................................25 2.1. Managing NetDefendOS ..........................................................................25 2.1.1. Overview ...................................................................................25 2.1.2. The Default Administrator Account .................................................26 2.1.3. The Web Interface .......................................................................26 2.1.4. The CLI .....................................................................................30 2.1.5. CLI Scripts .................................................................................38 2.1.6. Secure Copy ...............................................................................41 2.1.7. The Console Boot Menu ...............................................................43 2.1.8. Management Advanced Settings .....................................................45 2.1.9. Working with Configurations .........................................................46 2.2. Events and Logging ................................................................................51 2.2.1. Overview ...................................................................................51 2.2.2. Log Messages .............................................................................51 2.2.3. Log Message Distribution ..............................................................52 2.2.4. Advanced Log Settings .................................................................54 2.3. RADIUS Accounting ..............................................................................56 2.3.1. Overview ...................................................................................56 2.3.2. RADIUS Accounting Messages ......................................................56 2.3.3. Interim Accounting Messages ........................................................58 2.3.4. Activating RADIUS Accounting .....................................................58 2.3.5. RADIUS Accounting Security ........................................................58 2.3.6. RADIUS Accounting and High Availability ......................................58 2.3.7. Handling Unresponsive Servers ......................................................59 2.3.8. Accounting and System Shutdowns .................................................59 2.3.9. Limitations with NAT ...................................................................59 2.3.10. RADIUS Advanced Settings ........................................................59 2.4. Hardware Monitoring ..............................................................................61 2.5. SNMP Monitoring ..................................................................................63 2.5.1. SNMP Advanced Settings .............................................................64 2.6. The pcapdump Command ........................................................................66 2.7. Maintenance ..........................................................................................69 2.7.1. Auto-Update Mechanism ...............................................................69 2.7.2. Creating Backup Files ...................................................................69 2.7.3. Restore to Factory Defaults ............................................................70 3. Fundamentals ...................................................................................................73 3.1. The Address Book ..................................................................................73 3.1.1. Overview ...................................................................................73 3.1.2. IP Addresses ...............................................................................73 3.1.3. Ethernet Addresses .......................................................................75 3.1.4. Address Groups ...........................................................................76 3.1.5. Auto-Generated Address Objects ....................................................76 3.1.6. Address Book Folders ...................................................................77 3.2. Services ................................................................................................78 3.2.1. Overview ...................................................................................78 3.2.2. TCP and UDP Based Services ........................................................79 3.2.3. ICMP Services ............................................................................81 3.2.4. Custom IP Protocol Services ..........................................................82 3.2.5. Service Groups ............................................................................83 4

3.3.1. Overview ...................................................................................84 3.3.2. Ethernet Interfaces .......................................................................85 3.3.3. VLAN .......................................................................................90 3.3.4. PPPoE .......................................................................................93 3.3.5. GRE Tunnels ..............................................................................95 3.3.6. Interface Groups ..........................................................................98 3.4. ARP ....................................................................................................99 3.4.1. Overview ...................................................................................99 3.4.2. ARP in NetDefendOS ...................................................................99 3.4.3. ARP Cache .................................................................................99 3.4.4. Static and Published ARP Entries .................................................. 101 3.4.5. Using ARP Advanced Settings ..................................................... 102 3.4.6. ARP Advanced Settings Summary ................................................ 103 3.5. The IP Rule Set .................................................................................... 106 3.5.1. Security Policies ........................................................................ 106 3.5.2. IP Rule Evaluation ..................................................................... 108 3.5.3. IP Rule Actions ......................................................................... 109 3.5.4. Editing IP rule set Entries ............................................................ 110 3.5.5. IP Rule Set Folders .................................................................... 110 3.6. Schedules ........................................................................................... 112 3.7. Certificates ......................................................................................... 114 3.7.1. Overview ................................................................................. 114 3.7.2. Certificates in NetDefendOS ........................................................ 115 3.7.3. CA Certificate Requests .............................................................. 116 3.8. Date and Time ..................................................................................... 118 3.8.1. Overview ................................................................................. 118 3.8.2. Setting Date and Time ................................................................ 118 3.8.3. Time Servers ............................................................................ 119 3.8.4. Settings Summary for Date and Time ............................................ 122 3.9. DNS .................................................................................................. 125 4. Routing ......................................................................................................... 128 4.1. Overview ............................................................................................ 128 4.2. Static Routing ...................................................................................... 129 4.2.1. The Principles of Routing ............................................................ 129 4.2.2. Static Routing ........................................................................... 133 4.2.3. Route Failover .......................................................................... 137 4.2.4. Host Monitoring for Route Failover ............................................... 139 4.2.5. Proxy ARP ............................................................................... 141 4.3. Policy-based Routing ............................................................................ 143 4.3.1. Overview ................................................................................. 143 4.3.2. Policy-based Routing Tables ........................................................ 143 4.3.3. Policy-based Routing Rules ......................................................... 143 4.3.4. PBR Table Selection .................................................................. 144 4.3.5. The Ordering parameter .............................................................. 144 4.4. Route Load Balancing ........................................................................... 148 4.5. Dynamic Routing ................................................................................. 154 4.5.1. Dynamic Routing overview ......................................................... 154 4.5.2. OSPF ...................................................................................... 155 4.5.3. Dynamic Routing Policy ............................................................. 159 4.6. Multicast Routing ................................................................................. 162 4.6.1. Overview ................................................................................. 162 4.6.2. Multicast Forwarding with SAT Multiplex Rules ............................. 162 4.6.3. IGMP Configuration .................................................................. 166 4.6.4. Advanced IGMP Settings ............................................................ 171 4.7. Transparent Mode ................................................................................ 174 4.7.1. Overview ................................................................................. 174 4.7.2. Enabling Internet Access ............................................................. 178 4.7.3. Transparent Mode Scenarios ........................................................ 180 4.7.4. Spanning Tree BPDU Support ...................................................... 184 4.7.5. Advanced Settings for Transparent Mode ....................................... 184 5. DHCP Services .............................................................................................. 189 5.1. Overview ............................................................................................ 189 User Manual 5

5.3. Static DHCP Assignment ....................................................................... 193 5.3.1. DHCP Advanced Settings ............................................................ 193 5.4. DHCP Relaying ................................................................................... 195 5.4.1. DHCP Relay Advanced Settings ................................................... 196 5.5. IP Pools .............................................................................................. 198 6. Security Mechanisms ....................................................................................... 201 6.1. Access Rules ....................................................................................... 201 6.1.1. Introduction .............................................................................. 201 6.1.2. IP Spoofing .............................................................................. 201 6.1.3. Access Rule Settings .................................................................. 202 6.2. ALGs ................................................................................................. 204 6.2.1. Overview ................................................................................. 204 6.2.2. The HTTP ALG ........................................................................ 205 6.2.3. The FTP ALG ........................................................................... 208 6.2.4. The TFTP ALG ......................................................................... 214 6.2.5. The SMTP ALG ........................................................................ 215 6.2.6. The POP3 ALG ......................................................................... 224 6.2.7. The SIP ALG ............................................................................ 224 6.2.8. The H.323 ALG ........................................................................ 234 6.2.9. The TLS ALG ........................................................................... 248 6.3. Web Content Filtering ........................................................................... 251 6.3.1. Overview ................................................................................. 251 6.3.2. Active Content Handling ............................................................. 251 6.3.3. Static Content Filtering ............................................................... 252 6.3.4. Dynamic Web Content Filtering ................................................... 254 6.4. Anti-Virus Scanning ............................................................................. 268 6.4.1. Overview ................................................................................. 268 6.4.2. Implementation ......................................................................... 268 6.4.3. Activating Anti-Virus Scanning .................................................... 269 6.4.4. The Signature Database .............................................................. 270 6.4.5. Subscribing to the D-Link Anti-Virus Service ................................. 270 6.4.6. Anti-Virus Options ..................................................................... 270 6.5. Intrusion Detection and Prevention .......................................................... 274 6.5.1. Overview ................................................................................. 274 6.5.2. IDP Availability for D-Link Models .............................................. 274 6.5.3. IDP Rules ................................................................................. 276 6.5.4. Insertion/Evasion Attack Prevention .............................................. 277 6.5.5. IDP Pattern Matching ................................................................. 278 6.5.6. IDP Signature Groups ................................................................. 279 6.5.7. IDP Actions .............................................................................. 281 6.5.8. SMTP Log Receiver for IDP Events .............................................. 281 6.6. Denial-of-Service Attack Prevention ........................................................ 285 6.6.1. Overview ................................................................................. 285 6.6.2. DoS Attack Mechanisms ............................................................. 285 6.6.3. Ping of Death and Jolt Attacks ..................................................... 285 6.6.4. Fragmentation overlap attacks: Teardrop, Bonk, Boink and Nestea ...... 286 6.6.5. The Land and LaTierra attacks ..................................................... 286 6.6.6. The WinNuke attack ................................................................... 286 6.6.7. Amplification attacks: Smurf, Papasmurf, Fraggle ........................... 287 6.6.8. TCP SYN Flood Attacks ............................................................. 288 6.6.9. The Jolt2 Attack ........................................................................ 288 6.6.10. Distributed DoS Attacks ............................................................ 288 6.7. Blacklisting Hosts and Networks ............................................................. 289 7. Address Translation ........................................................................................ 292 7.1. NAT .................................................................................................. 292 7.2. NAT Pools .......................................................................................... 297 7.3. SAT ................................................................................................... 300 7.3.1. Translation of a Single IP Address (1:1) ......................................... 300 7.3.2. Translation of Multiple IP Addresses (M:N) .................................... 304 7.3.3. All-to-One Mappings (N:1) ......................................................... 306 7.3.4. Port Translation ......................................................................... 306 7.3.5. Protocols Handled by SAT .......................................................... 307 User Manual 6

7.3.7. SAT and FwdFast Rules .............................................................. 308 8. User Authentication ........................................................................................ 311 8.1. Overview ............................................................................................ 311 8.2. Authentication Setup ............................................................................. 313 8.2.1. Setup Summary ......................................................................... 313 8.2.2. The Local Database .................................................................... 313 8.2.3. External RADIUS Servers ........................................................... 313 8.2.4. External LDAP Servers ............................................................... 314 8.2.5. Authentication Rules .................................................................. 318 8.2.6. Authentication Processing ........................................................... 320 8.2.7. HTTP Authentication ................................................................. 320 8.3. Customizing HTML Pages ..................................................................... 325 9. VPN ............................................................................................................. 329 9.1. Overview ............................................................................................ 329 9.1.1. VPN Usage ............................................................................... 329 9.1.2. VPN Encryption ........................................................................ 330 9.1.3. VPN Planning ........................................................................... 330 9.1.4. Key Distribution ........................................................................ 331 9.1.5. The TLS Alternative for VPN ...................................................... 331 9.2. VPN Quick Start .................................................................................. 333 9.2.1. IPsec LAN to LAN with Pre-shared Keys ....................................... 334 9.2.2. IPsec LAN to LAN with Certificates ............................................. 335 9.2.3. IPsec Roaming Clients with Pre-shared Keys .................................. 336 9.2.4. IPsec Roaming Clients with Certificates ......................................... 338 9.2.5. L2TP Roaming Clients with Pre-Shared Keys ................................. 339 9.2.6. L2TP Roaming Clients with Certificates ........................................ 340 9.2.7. PPTP Roaming Clients ............................................................... 341 9.3. IPsec Components ................................................................................ 343 9.3.1. Overview ................................................................................. 343 9.3.2. Internet Key Exchange (IKE) ....................................................... 343 9.3.3. IKE Authentication .................................................................... 349 9.3.4. IPsec Protocols (ESP/AH) ........................................................... 350 9.3.5. NAT Traversal .......................................................................... 351 9.3.6. Algorithm Proposal Lists ............................................................. 352 9.3.7. Pre-shared Keys ........................................................................ 354 9.3.8. Identification Lists ..................................................................... 355 9.4. IPsec Tunnels ...................................................................................... 357 9.4.1. Overview ................................................................................. 357 9.4.2. LAN to LAN Tunnels with Pre-shared Keys ................................... 358 9.4.3. Roaming Clients ........................................................................ 358 9.4.4. Fetching CRLs from an alternate LDAP server ................................ 363 9.4.5. Troubleshooting with ikesnoop ..................................................... 364 9.4.6. IPsec Advanced Settings ............................................................. 371 9.5. PPTP/L2TP ......................................................................................... 375 9.5.1. PPTP Servers ............................................................................ 375 9.5.2. L2TP Servers ............................................................................ 376 9.5.3. L2TP/PPTP Server advanced settings ............................................ 380 9.5.4. PPTP/L2TP Clients .................................................................... 381 9.6. CA Server Access ................................................................................ 383 9.7. VPN Troubleshooting ........................................................................... 386 10. Traffic Management ...................................................................................... 390 10.1. Traffic Shaping .................................................................................. 390 10.1.1. Introduction ............................................................................ 390 10.1.2. Traffic Shaping in NetDefendOS ................................................. 391 10.1.3. Simple Bandwidth Limiting ....................................................... 393 10.1.4. Limiting Bandwidth in Both Directions ........................................ 394 10.1.5. Creating Differentiated Limits with Chains ................................... 395 10.1.6. Precedences ............................................................................ 396 10.1.7. Guarantees .............................................................................. 398 10.1.8. Differentiated Guarantees .......................................................... 398 10.1.9. Groups ................................................................................... 399 10.1.10. Recommendations .................................................................. 400 User Manual 7

10.1.12. More Pipe Examples ............................................................... 402 10.2. IDP Traffic Shaping ............................................................................ 407 10.2.1. Overview ................................................................................ 407 10.2.2. Setup ..................................................................................... 407 10.2.3. Processing Flow ....................................................................... 408 10.2.4. The Importance of Specifying a Network ...................................... 408 10.2.5. A P2P Scenario ........................................................................ 409 10.2.6. Viewing Traffic Shaping Objects ................................................ 409 10.2.7. Guaranteeing Instead of Limiting Bandwidth ................................. 410 10.2.8. Logging ................................................................................. 411 10.3. Threshold Rules ................................................................................. 412 10.3.1. Overview ................................................................................ 412 10.3.2. Limiting the Connection Rate/Total Connections ........................... 412 10.3.3. Grouping ................................................................................ 412 10.3.4. Rule Actions ........................................................................... 413 10.3.5. Multiple Triggered Actions ........................................................ 413 10.3.6. Exempted Connections .............................................................. 413 10.3.7. Threshold Rules and ZoneDefense .............................................. 413 10.3.8. Threshold Rule Blacklisting ....................................................... 413 10.4. Server Load Balancing ........................................................................ 414 10.4.1. Overview ................................................................................ 414 10.4.2. Identifying the Servers .............................................................. 415 10.4.3. The Load Distribution Mode ...................................................... 415 10.4.4. The Distribution Algorithm ........................................................ 416 10.4.5. Server Health Monitoring .......................................................... 418 10.4.6. SLB_SAT Rules ....................................................................... 418 11. High Availability .......................................................................................... 422 11.1. Overview .......................................................................................... 422 11.2. HA Mechanisms ................................................................................. 424 11.3. HA Setup .......................................................................................... 427 11.3.1. HA Hardware Setup ................................................................. 427 11.3.2. NetDefendOS Manual HA Setup ................................................. 428 11.3.3. Verifying the Cluster Functions .................................................. 429 11.3.4. Unique Shared Mac Addresses ................................................... 430 11.4. HA Issues ......................................................................................... 431 11.5. HA Advanced Settings ........................................................................ 432 12. ZoneDefense ................................................................................................ 434 12.1. Overview .......................................................................................... 434 12.2. ZoneDefense Switches ......................................................................... 435 12.3. ZoneDefense Operation ....................................................................... 436 12.3.1. SNMP .................................................................................... 436 12.3.2. Threshold Rules ....................................................................... 436 12.3.3. Manual Blocking and Exclude Lists ............................................. 436 12.3.4. ZoneDefense with Anti-Virus Scanning ........................................ 438 12.3.5. Limitations ............................................................................. 438 13. Advanced Settings ......................................................................................... 441 13.1. IP Level Settings ................................................................................ 441 13.2. TCP Level Settings ............................................................................. 445 13.3. ICMP Level Settings ........................................................................... 450 13.4. State Settings ..................................................................................... 451 13.5. Connection Timeout Settings ................................................................ 453 13.6. Length Limit Settings .......................................................................... 455 13.7. Fragmentation Settings ........................................................................ 457 13.8. Local Fragment Reassembly Settings ..................................................... 461 13.9. Miscellaneous Settings ........................................................................ 462 A. Subscribing to Security Updates ........................................................................ 464 B. IDP Signature Groups ..................................................................................... 466 C. Verified MIME filetypes ................................................................................. 470 D. The OSI Framework ....................................................................................... 474 E. D-Link Worldwide Offices ............................................................................... 475 Alphabetical Index ............................................................................................. 477 User Manual 8

1.1. Packet Flow Schematic Part I ...........................................................................20 1.2. Packet Flow Schematic Part II ..........................................................................21 1.3. Packet Flow Schematic Part III .........................................................................22 1.4. Expanded Apply Rules Logic ............................................................................23 3.1. VLAN Connections ........................................................................................90 3.2. Simplified NetDefendOS Traffic Flow ............................................................. 108 4.1. Using Local IP Address with an Unbound Network ............................................ 132 4.2. A Route Failover Scenario for ISP Access ......................................................... 137 4.3. The RLB Round Robin Algorithm ................................................................... 149 4.4. The RLB Spillover Algorithm ......................................................................... 149 4.5. A Route Load Balancing Scenario ................................................................... 152 4.6. Virtual Links Example 1 ................................................................................ 157 4.7. Virtual Links Example 2 ................................................................................ 158 4.8. Multicast Forwarding - No Address Translation ................................................. 163 4.9. Multicast Forwarding - Address Translation ...................................................... 165 4.10. Multicast Snoop ......................................................................................... 167 4.11. Multicast Proxy .......................................................................................... 167 4.12. Non-transparent Mode Internet Access ........................................................... 178 4.13. Transparent Mode Internet Access ................................................................. 179 4.14. Transparent Mode Scenario 1 ........................................................................ 180 4.15. Transparent Mode Scenario 2 ........................................................................ 181 4.16. An Example BPDU Relaying Scenario ........................................................... 184 6.1. Deploying an ALG ....................................................................................... 204 6.2. HTTP ALG Processing Order ......................................................................... 207 6.3. SMTP ALG Processing Order ......................................................................... 217 6.4. DNSBL SPAM Filtering ................................................................................ 219 6.5. TLS Termination .......................................................................................... 248 6.6. Dynamic Content Filtering Flow ..................................................................... 255 6.7. IDP Database Updating ................................................................................. 275 7.1. NAT IP Address Translation .......................................................................... 293 7.2. Anonymizing with NAT ................................................................................ 296 8.1. Normal LDAP Authentication ........................................................................ 317 8.2. LDAP for PPP with CHAP, MS-CHAPv1 or MS-CHAPv2 .................................. 318 9.1. The AH protocol .......................................................................................... 350 9.2. The ESP protocol ......................................................................................... 351 9.3. PPTP Client Usage ....................................................................................... 382 9.4. Certificate Validation Components .................................................................. 384 10.1. Packet Flow of Pipe Rule Set to Pipe .............................................................. 392 10.2. FwdFast Rules Bypass Traffic Shaping ........................................................... 393 10.3. The Eight Pipe Precedences .......................................................................... 396 10.4. Minimum and Maximum Pipe Precedence ....................................................... 397 10.5. Traffic grouped per IP address ...................................................................... 399 10.6. A Basic Traffic Shaping Scenario .................................................................. 402 10.7. IDP Traffic Shaping P2P Scenario ................................................................. 409 10.8. A Server Load Balancing Configuration .......................................................... 414 10.9. Connections from Three Clients .................................................................... 416 10.10. Stickiness and Round-Robin ....................................................................... 417 10.11. Stickiness and Connection Rate ................................................................... 417 D.1. The 7 Layers of the OSI Model ...................................................................... 474 9

1. Example Notation .............................................................................................12 2.1. Enabling remote management via HTTPS ...........................................................30 2.2. Enabling SSH Remote Access ..........................................................................35 2.3. Listing Configuration Objects ...........................................................................46 2.4. Displaying a Configuration Object .....................................................................47 2.5. Editing a Configuration Object .........................................................................47 2.6. Adding a Configuration Object .........................................................................48 2.7. Deleting a Configuration Object ........................................................................49 2.8. Undeleting a Configuration Object ....................................................................49 2.9. Listing Modified Configuration Objects ..............................................................49 2.10. Activating and Committing a Configuration .......................................................50 2.11. Enable Logging to a Syslog Host .....................................................................53 2.12. Sending SNMP Traps to an SNMP Trap Receiver ...............................................54 2.13. RADIUS Accounting Server Setup ..................................................................60 2.14. Enabling SNMP Monitoring ...........................................................................64 2.15. Backing up the Entire System .........................................................................70 2.16. Complete Hardware Reset to Factory Defaults ...................................................70 3.1. Adding an IP Host ..........................................................................................74 3.2. Adding an IP Network .....................................................................................74 3.3. Adding an IP Range ........................................................................................74 3.4. Deleting an Address Object ..............................................................................75 3.5. Adding an Ethernet Address .............................................................................75 3.6. Listing the Available Services ...........................................................................78 3.7. Viewing a Specific Service ..............................................................................78 3.8. Adding a TCP/UDP Service .............................................................................80 3.9. Adding an IP Protocol Service ..........................................................................82 3.10. Enabling DHCP ...........................................................................................87 3.11. Defining a VLAN .........................................................................................92 3.12. Configuring a PPPoE client ............................................................................94 3.13. Creating an Interface Group ............................................................................98 3.14. Displaying the ARP Cache ........................................................................... 100 3.15. Flushing the ARP Cache .............................................................................. 100 3.16. Defining a Static ARP Entry ......................................................................... 101 3.17. Adding an Allow IP Rule .............................................................................. 111 3.18. Setting up a Time-Scheduled Policy ............................................................... 112 3.19. Uploading a Certificate ................................................................................ 116 3.20. Associating Certificates with IPsec Tunnels ..................................................... 116 3.21. Setting the Current Date and Time ................................................................. 118 3.22. Setting the Time Zone ................................................................................. 119 3.23. Enabling DST ............................................................................................ 119 3.24. Enabling Time Synchronization using SNTP .................................................... 120 3.25. Manually Triggering a Time Synchronization .................................................. 121 3.26. Modifying the Maximum Adjustment Value .................................................... 121 3.27. Forcing Time Synchronization ...................................................................... 122 3.28. Enabling the D-Link NTP Server ................................................................... 122 3.29. Configuring DNS Servers ............................................................................. 125 4.1. Displaying the Routing Table ......................................................................... 134 4.2. Displaying the Core Routes ............................................................................ 136 4.3. Creating a Policy-based Routing Table ............................................................. 145 4.4. Creating the Route ........................................................................................ 145 4.5. Policy-based Routing Configuration ................................................................. 145 4.6. Setting Up RLB ........................................................................................... 152 4.7. Importing Routes from an OSPF AS into the Main Routing Table ......................... 160 4.8. Exporting the Default Route into an OSPF AS ................................................... 160 4.9. Forwarding of Multicast Traffic using the SAT Multiplex Rule ............................. 164 4.10. Multicast Forwarding - Address Translation .................................................... 166 4.11. IGMP - No Address Translation .................................................................... 168 4.12. if1 Configuration ........................................................................................ 169 10

4.14. Setting up Transparent Mode for Scenario 1 .................................................... 180 4.15. Setting up Transparent Mode for Scenario 2 .................................................... 182 5.1. Setting up a DHCP server .............................................................................. 191 5.2. Checking DHCP Server Status ........................................................................ 191 5.3. Setting up Static DHCP ................................................................................. 193 5.4. Setting up a DHCP Relayer ............................................................................ 195 5.5. Creating an IP Pool ....................................................................................... 199 6.1. Setting up an Access Rule .............................................................................. 203 6.2. Protecting an FTP Server with an ALG ............................................................. 210 6.3. Protecting FTP Clients .................................................................................. 213 6.4. Protecting Phones Behind NetDefend Firewalls .................................................. 236 6.5. H.323 with private IP addresses ...................................................................... 238 6.6. Two Phones Behind Different NetDefend Firewalls ............................................ 239 6.7. Using Private IP Addresses ............................................................................ 240 6.8. H.323 with Gatekeeper .................................................................................. 241 6.9. H.323 with Gatekeeper and two NetDefend Firewalls .......................................... 243 6.10. Using the H.323 ALG in a Corporate Environment ........................................... 244 6.11. Configuring remote offices for H.323 ............................................................. 247 6.12. Allowing the H.323 Gateway to register with the Gatekeeper .............................. 247 6.13. Stripping ActiveX and Java applets ................................................................ 252 6.14. Setting up a white and blacklist ..................................................................... 253 6.15. Enabling Dynamic Web Content Filtering ....................................................... 256 6.16. Enabling Audit Mode .................................................................................. 257 6.17. Reclassifying a blocked site .......................................................................... 259 6.18. Editing Content Filtering HTTP Banner Files ................................................... 266 6.19. Activating Anti-Virus Scanning ..................................................................... 272 6.20. Configuring an SMTP Log Receiver .............................................................. 281 6.21. Setting up IDP for a Mail Server .................................................................... 282 6.22. Adding a Host to the Whitelist ...................................................................... 290 7.1. Adding a NAT Rule ...................................................................................... 294 7.2. Using NAT Pools ......................................................................................... 298 7.3. Enabling Traffic to a Protected Web Server in a DMZ ......................................... 300 7.4. Enabling Traffic to a Web Server on an Internal Network .................................... 302 7.5. Translating Traffic to Multiple Protected Web Servers ........................................ 304 8.1. Creating an Authentication User Group ............................................................ 323 8.2. User Authentication Setup for Web Access ....................................................... 323 8.3. Configuring a RADIUS Server ....................................................................... 324 8.4. Editing Content Filtering HTTP Banner Files .................................................... 326 9.1. Using an Algorithm Proposal List .................................................................... 353 9.2. Using a Pre-Shared key ................................................................................. 354 9.3. Using an Identity List .................................................................................... 355 9.4. Setting up a PSK based VPN tunnel for roaming clients ....................................... 359 9.5. Setting up a Self-signed Certificate based VPN tunnel for roaming clients ............... 359 9.6. Setting up CA Server Certificate based VPN tunnels for roaming clients ................. 361 9.7. Setting Up Config Mode ................................................................................ 363 9.8. Using Config Mode with IPsec Tunnels ............................................................ 363 9.9. Setting up an LDAP server ............................................................................. 363 9.10. Setting up a PPTP server .............................................................................. 376 9.11. Setting up an L2TP server ............................................................................ 376 9.12. Setting up an L2TP Tunnel Over IPsec ........................................................... 377 10.1. Applying a Simple Bandwidth Limit .............................................................. 393 10.2. Limiting Bandwidth in Both Directions ........................................................... 395 10.3. Setting up SLB ........................................................................................... 419 12.1. A simple ZoneDefense scenario .................................................................... 437 User Manual 11

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 a 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. CLI 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 12

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. Preface 13

This chapter outlines the key features of NetDefendOS. • Features, page 14 • NetDefendOS Architecture, page 17 • NetDefendOS State Engine Packet Flow, page 20 1.1. Features D-Link NetDefendOS is the base software engine that drives and controls the range of NetDefend Firewall hardware products. 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 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. Firewalling Policies 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, “The IP Rule Set”, describes how to set up these policies to determine what traffic is allowed or rejected by 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. 14

(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”. TLS Termination 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.9, “The TLS ALG”. Anti-Virus Scanning 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. Intrusion Detection and Prevention 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, “Intrusion Detection and Prevention”. 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.. Web Content Filtering 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. Traffic Management 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 1.1. Features Chapter 1. NetDefendOS Overview 15

load to multiple hosts. These features are discussed in detail in Chapter 10, Traffic Management. Note Threshold Rules are only available on certain D-Link NetDefend product models. Operations and Maintenance Adminstrator management of NetDefendOS is possible through either a Web-based User Interface (the WebUI) or via a Command Line Interface (the CLI). 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 and Maintenance. ZoneDefense 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. 1.1. Features Chapter 1. NetDefendOS Overview 16

1.2.1. State-based Architecture The NetDefendOS architecture is centered around the concept of state-based connections. Traditional IP routers or switches commonly inspect all packets and then perform forwarding decisions based on information found in the packet headers. 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. 1.2. NetDefendOS Architecture Chapter 1. NetDefendOS Overview 17

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 other words, by default, an interface will only accept source IP addresses that belong to networks routed over that interface. If the Access Rules 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: • Source and destination interfaces • Source and destination network • IP protocol (for example TCP, UDP, ICMP) 1.2.3. Basic Packet Flow Chapter 1. NetDefendOS Overview 18

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. 1.2.3. Basic Packet Flow Chapter 1. NetDefendOS Overview 19

The diagrams in this section provide a summary of the flow of packets through the NetDefendOS state-engine. There are three diagrams, each flowing into the next. Figure 1.1. Packet Flow Schematic Part I The packet flow is continued on the following page. 1.3. NetDefendOS State Engine Packet Flow Chapter 1. NetDefendOS Overview 20

The packet flow is continued on the following page. 1.3. NetDefendOS State Engine Packet Flow Chapter 1. NetDefendOS Overview 21

1.3. NetDefendOS State Engine Packet Flow Chapter 1. NetDefendOS Overview 22

Flow Schematic Part II” above. Figure 1.4. Expanded Apply Rules Logic 1.3. NetDefendOS State Engine Packet Flow Chapter 1. NetDefendOS Overview 23

This chapter describes the management, operations and maintenance related aspects of NetDefendOS. • Managing NetDefendOS, page 25 • Events and Logging, page 51 • RADIUS Accounting, page 56 • Hardware Monitoring, page 61 • SNMP Monitoring, page 63 • The pcapdump Command, page 66 • Maintenance, page 69 2.1. Managing NetDefendOS 2.1.1. Overview NetDefendOS is designed to give both high performance and high reliability. 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 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 CLI 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 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. 25

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 Boot Menu”. 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 2.1.2. The Default Administrator Account Chapter 2. Management and Maintenance 26

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 2560, the default management interface IP address is 192.168.1.1. • On the NetDefend DFL-1660 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 on the same IP network for inital communication between them to succeed so the static IP address of the workstation must be set to the following 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 2.1.3. The Web Interface Chapter 2. Management and Maintenance 27

Web Interface page. First Time Web Interface Logon and the Setup Wizard When logging on for the first time, the default username is admin and the password is admin. After successful login, the WebUI user interface will be presented in the browser window. If no configuration changes have yet been uploaded to the NetDefend Firewall, the NetDefendOS Setup Wizard will also run 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 switched off in the web browser to allow the NetDefendOS Setup Wizard to run. 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 may 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. 2.1.3. The Web Interface Chapter 2. Management and Maintenance 28

Administrator Account”. Note: Remote management access Access to the Web Interface is regulated by the configured remote management policy. By default, the system will only allow web access from the internal network. Interface Layout The main Web Interface page is divided into three major sections: 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. • 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. Navigator 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. Main Window The main window contains configuration or status details corresponding to the section selected in the navigator or the menu bar. 2.1.3. The Web Interface Chapter 2. Management and Maintenance 29

By default, the Web Interface is accessible only from the internal network. If you need to enable access from other parts of the network, you can do so by modifying the remote management policy. Example 2.1. Enabling remote management via HTTPS CLI gw-world:/> add RemoteManagement RemoteMgmtHTTP https Network=all-nets Interface=any LocalUserDatabase=AdminUsers HTTPS=Yes Web Interface 1. Go to System > Remote Management > Add > HTTP/HTTPS Management 2. Enter a Name for the HTTP/HTTPS remote management policy, for example https 3. Check the HTTPS checkbox 4. Select the following from the dropdown lists: • User Database: AdminUsers • Interface: any • Network: all-nets 5. Click OK Caution: Don't expose the management interface 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. 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. 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 2.1.4. The CLI Chapter 2. Management and Maintenance 30

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: . 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: gw-world:/> add IP4Address my_address Address=10.49.02.01 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 a 2.1.4. The CLI Chapter 2. Management and Maintenance 31

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 Data A very 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 LogSeverity=Emergency 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 LogSeverity=Emergency,Alert,Critical,Error,Warning,Notice,Info This list can then be edited with the back arrow and backspace keys. Object Categories 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. 2.1.4. The CLI Chapter 2. Management and Maintenance 32

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: gw-world:/main> add Route Name=new_route1 Interface=lan Network=lannet 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 2.1.4. The CLI Chapter 2. Management and Maintenance 33

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. 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 stop 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. 2.1.4. The CLI Chapter 2. Management and Maintenance 34

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. CLI gw-world:/> add RemoteManagement RemoteMgmtSSH ssh Network=lannet Interface=lan LocalUserDatabase=AdminUsers Web Interface 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 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 2.1.4. The CLI Chapter 2. Management and Maintenance 35

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 automatically undone and the old configuration restored. 2.1.4. The CLI Chapter 2. Management and Maintenance 36

After changing a configuration on the NetDefend Firewall, and before the activate/commit commands, it is possible to explicitly check for any problems in a configuration using the command: gw-world:/> show -errors This will cause NetDefendOS to scan the configuration about to be activated and list any problems. 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: gw-world:/> add RemoteManagement RemoteMgmtHTTP HTTP_if2 Interface=if2 Network=all-nets LocalUserDatabase=AdminUsers AccessLevel=Admin HTTP=Yes If we now activate and commit the new configuration, reemote management access via the IP address 10.8.1.34 is now possible using a web browser. If SSH management access is required then a RemoteMgmtSSH object should be added. 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. • Secure Copy (SCP) sessions. 2.1.4. The CLI Chapter 2. Management and Maintenance 37

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: gw-world:/> sessionmanager -list User Database IP Type Mode Access -------- ---------------- --------- ------- ------- -------- local (none) 0.0.0.0 local console admin 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. 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 2.1.5. CLI Scripts Chapter 2. Management and Maintenance 38

$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: :/> script -execute -name=my_script.sgs 126.12.11.01 "If1 address" When the script file runs, the variable replacement would mean that the file becomes: add IP4Address If1_ip Address=126.12.11.01 Comments="If1 address" Error Handling 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: gw-world:/> script -execute -name=my_script2.sgs -force 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: gw-world:/> script -execute -name=my_script2.sgs -verbose Saving Scripts 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. 2.1.5. CLI Scripts Chapter 2. Management and Maintenance 39

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 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 Name Storage Size (bytes) -------------- ------------ -------------- my_script.sgs RAM 8 my_script2.sgs Disk 10 To list the content of a specific uploaded script file, for example my_script.sgs the command would be: 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: gw-world:/> script -create Address IP4Address -name new_script.sgs 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: add IP4Address If1_ip Address=10.6.60.10 add IP4Address If1_net Address=10.6.60.0/24 add IP4Address If1_br Address=10.6.60.255 add IP4Address If1_dns1 Address=141.1.1.1 " " " The file new_script_sgs can then be downloaded with SCP to the local management workstation and 2.1.5. CLI Scripts Chapter 2. Management and Maintenance 40

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 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 2.1.6. Secure Copy Chapter 2. Management and Maintenance 41

> scp The source or destination NetDefend Firewall is of the form: @:. For example: [email protected]:config.bak. The 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 that follow. The following table summarizes the operations that can be performed between an SCP client and NetDefendOS: File type Upload possible Download 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) Firmware upgrades Yes No Certificates Yes No SSH public keys Yes No Web auth banner files Yes Yes Web content filter banner files Yes Yes 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. The resulting output is shown below: gw-world:/> ls HTTPALGBanners/ HTTPAuthBanners/ certificate/ config.bak full.bak script/ sshclientkey/ 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 2.1.6. Secure Copy Chapter 2. Management and Maintenance 42

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 [email protected]: To download a configuration backup to the current local directory, the command would be: > scp [email protected]:config.bak ./ 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 [email protected]: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 [email protected]: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: 2.1.7. The Console Boot Menu Chapter 2. Management and Maintenance 43

console boot menu is displayed. Initial Boot Menu Options without a Password Set When NetDefendOS is started for the first time with no console password set for console access then the full set of boot menu options are displayed as shown below: The options available in the boot menu are: 1. 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. 2.1.7. The Console Boot Menu Chapter 2. Management and Maintenance 44

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: 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. 2.1.8. Management Advanced Settings Chapter 2. Management and Maintenance 45

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 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. CLI 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 2.1.9. Working with Configurations Chapter 2. Management and Maintenance 46

• 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. CLI gw-world:/> show Service ServiceTCPUDP telnet Property Value ----------------- ------- Name: telnet DestinationPorts: 23 Type: TCP SourcePorts: 0-65535 SYNRelay: No PassICMPReturn: No ALG: (none) MaxSessions: 1000 Comments: Telnet 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 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. CLI gw-world:/> set Service ServiceTCPUDP telnet Comments="Modified Comment" 2.1.9. Working with Configurations Chapter 2. Management and Maintenance 47

gw-world:/> show Service ServiceTCPUDP telnet Property Value ----------------- ------- Name: telnet DestinationPorts: 23 Type: TCP SourcePorts: 0-65535 SYNRelay: No PassICMPReturn: No ALG: (none) MaxSessions: 1000 Comments: Modified Comment 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. 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. CLI gw-world:/> add Address IP4Address myhost Address=192.168.10.10 Show the new object: gw-world:/> show Address IP4Address myhost Property Value --------------------- ------------- Name: myhost Address: 192.168.10.10 UserAuthGroups: (none) NoDefinedCredentials: No Comments: (none) Web Interface 1. Go to Objects > Address Book 2. Click on the Add button 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 2.1.9. Working with Configurations Chapter 2. Management and Maintenance 48

Example 2.7. Deleting a Configuration Object This example shows how to delete the newly added IP4Address object. CLI gw-world:/> delete Address IP4Address myhost Web Interface 1. Go to Objects > Address Book 2. Right-click on the row containing the myhost object 3. 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. 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. CLI 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. CLI gw-world:/> show -changes Type Object ------------- ------ - IP4Address myhost 2.1.9. Working with Configurations Chapter 2. Management and Maintenance 49

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 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. CLI 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 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. 2.1.9. Working with Configurations Chapter 2. Management and Maintenance 50

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 Event Receivers. 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 2.2. Events and Logging Chapter 2. Management and Maintenance 51

troubleshooting only and should only be turned on if required to try and solve a problem. Messages of all severity levels are found listed in the NetDefendOS Log Reference Guide. 2.2.3. Log Message Distribution To distribute and log the event messages generated, 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 in the following ways: Memlog NetDefendOS has a built in logging mechanism known as the Memory Log. This retains all event log messages in memory and allows direct viewing of log messages through the Web Interface. Syslog 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. 2.2.3.1. Logging to Memlog Memlog is an optional NetDefendOS feature that allows logging direct to memory in the NetDefend Firewall instead of sending messages to an external server. Memlog messages can be examined through the standard user interfaces. The Memlog memory is limited to a fixed predetermined size since hardware resources are limited. 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. 2.2.3.2. Logging to Syslog Hosts Overview 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. 2.2.3. Log Message Distribution Chapter 2. Management and Maintenance 52

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 195.11.22.55, follow the steps outlined below: CLI gw-world:/> add LogReceiverSyslog my_syslog IPAddress=195.11.22.55 Web Interface 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. 2.2.3.3. 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 2.2.3. Log Message Distribution Chapter 2. Management and Maintenance 53

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: CLI gw-world:/> add LogReceiver EventReceiverSNMP2c my_snmp IPAddress=195.11.22.55 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.4. Advanced Log Settings The following advanced settings for logging are available to the administrator: 2.2.4. Advanced Log Settings Chapter 2. Management and Maintenance 54

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 ICMP Unreachable 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) 2.2.4. Advanced Log Settings Chapter 2. Management and Maintenance 55

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" 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 2.3. RADIUS Accounting Chapter 2. Management and Maintenance 56

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. 2.3.2. RADIUS Accounting Messages Chapter 2. Management and Maintenance 57

The asterisk "*" symbol in the above list indicates that the sending of the parameter is user configurable. 2.3.3. Interim Accounting Messages In addition to START and STOP messages NetDefendOS can optionally periodically send Interim Accounting Messages to update the accounting server with the current status of an authenticated user. 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 2.3.3. Interim Accounting Messages Chapter 2. Management and Maintenance 58

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 2.3.7. Handling Unresponsive Servers Chapter 2. Management and Maintenance 59

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 2.3.10. RADIUS Advanced Settings Chapter 2. Management and Maintenance 60

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. The hardware monitor queries are performed through the CLI but enabling and confguring the feature is done 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 Name Current value (unit) --------------- -------------------- SYS Temp = 44.000 (C) (x) CPU Temp = 41.500 (C) (x) Note The "(x)" on the left side of the sensor listing indicates that the sensor is enabled. 2.4. Hardware Monitoring Chapter 2. Management and Maintenance 61

gw-world:/> hwm -a -v 2 sensors available Poll interval time = 500ms Name [type][number] = low_limit] current_value [high_limit (unit) ----------------------------------------------------------------- SYS Temp [TEMP ][ 0] = 44.000] 45.000 [ 0.000 (C) CPU Temp [TEMP ][ 1] = 42.000] 42.500 [ 0.000 (C) Time to probe sensors: 2.980000e-05 seconds 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 models have different sensors and values 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. 2.4. Hardware Monitoring Chapter 2. Management and Maintenance 62

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 SNMPBeforeRules 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 2.5. SNMP Monitoring Chapter 2. Management and Maintenance 63

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 SNMPReqLimit 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.) CLI gw-world:/> add RemoteManagement RemoteMgmtSNMP my_snmp Interface=lan Network=mgmt-net SNMPGetCommunity=Mg1RQqR Should it be necessary to enable SNMPBeforeRules (which is enabled by default) then the command is: gw-world:/> set Settings RemoteMgmtSettings SNMPBeforeRules=Yes Web Interface 1. Goto System > Remote Management > Add > SNMP management 2. For Remote access type enter: • Name: a suitable name • Community: Mg1RQqR 3. For Access Filter enter: • Interface: lan • Network: mgmt-net 4. Click OK Should it be necessary to enable SNMPBeforeRules (which is enabled by default) then the setting can be found in System > Remote Management > Advanced Settings. 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. 2.5.1. SNMP Advanced Settings Chapter 2. Management and Maintenance 64

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 2.5.1. SNMP Advanced Settings Chapter 2. Management and Maintenance 65

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: > pcapdump -size 1024 -start int > pcapdump -stop int > pcapdump -show > pcapdump -write int -filename=cap_int.cap > 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. > pcapdump -size 1024 -start int 2. The recording is stopped for the int interface. > pcapdump -stop int 3. The dump output is displayed on the console in a summarized form. > pcapdump -show 4. The same information is written in its complete form to a file called cap_int.cap. > 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. > 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 2.6. The pcapdump Command Chapter 2. Management and Maintenance 66

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= - Filter on source or destination MAC address. -ethsrc= - Filter on source MAC address. -ethdest= - Filter on destination MAC address. -ip= - Filter source or destination IP address. -ipsrc= - Filter on source IP address. -ipdest= - Filter on destination IP address. -port= - Filter on source or destination port number. -srcport= - Filter on source port number. -destport= - Filter on destination port number. -proto= - Filter on protocol where id is the decimal protocol id. - - 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 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 the files so cleanup should only be done after file download is complete. Output File Naming Restrictions 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. 2.6. The pcapdump Command Chapter 2. Management and Maintenance 67

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. 2.6. The pcapdump Command Chapter 2. Management and Maintenance 68

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. Creating Backup Files 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 2.7. Maintenance Chapter 2. Management and Maintenance 69

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 Ant-Virus databases are lost and must be reloaded. Example 2.16. Complete Hardware Reset to Factory Defaults CLI 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. 2.7.3. Restore to Factory Defaults Chapter 2. Management and Maintenance 70

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 2560 models. The management interface IP address for the DFL-1660 and 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”. DO NOT ABORT THE RESET TO FACTORY DEFAULTS PROCESS. 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. 2.7.3. Restore to Factory Defaults Chapter 2. Management and Maintenance 71

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 73 • Services, page 78 • Interfaces, page 84 • ARP, page 99 • The IP Rule Set, page 106 • Schedules, page 112 • Certificates, page 114 • Date and Time, page 118 • DNS, page 125 3.1. The Address Book 3.1.1. Overview The Address Book contains named objects representing various types of addresses, including IP addresses, networks and Ethernet MAC addresses. Using Address Book objects has three distinct benefits; it increases readability, reduces the danger of entering incorrect network addresses, and makes it easier to change addresses. By using objects instead of numerical addresses, you only need to make changes in a single location, rather than in each configuration section where the address appears. 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 host (a single IP address), 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. 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 73

The numbers 0-32 correspond to the number of binary ones in the netmask. For example: 192.168.0.0/24. IP Range A range of IP addresses is represented on the form a.b.c.d - e.f.g.h. Note that ranges are not limited to netmask boundaries. They may include any span of IP addresses. For example, 192.168.0.10-192.168.0.15 represents six hosts in consecutive order. Example 3.1. Adding an IP Host This example adds the IP host www_srv1 with IP address 192.168.10.16 to the Address Book: CLI gw-world:/> add Address IP4Address www_srv1 Address=192.168.10.16 Web Interface 1. Go to Objects > Address Book > Add > IP address 2. Specify a suitable name for the IP host, in this case wwww_srv1 3. Enter 192.168.10.16 for the IP Address 4. Click OK Example 3.2. Adding an IP Network This example adds an IP network named wwwsrvnet with address 192.168.10.0/24 to the Address Book: CLI gw-world:/> add Address IP4Address wwwsrvnet Address=192.168.10.0/24 Web Interface 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 This example adds a range of IP addresses from 192.168.10.16 to 192.168.10.21 and names the range wwwservers: CLI gw-world:/> add Address IP4Address wwwservers Address=192.168.10.16-192.168.10.21 3.1.2. IP Addresses Chapter 3. Fundamentals 74

2. Specify a suitable name for the IP Range, for example wwwservers. 3. Enter 192.168.10.16-192.168.10.21 as the IP Address 4. Click OK Example 3.4. Deleting an Address Object To delete an object named wwwsrv1 in the Address Book, do the following: CLI gw-world:/> delete Address IP4Address wwwsrv1 Web Interface 1. Go to Objects > Address Book 2. 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 The following example adds an Ethernet Address object named wwwsrv1_mac with the numerical MAC address 08-a3-67-bc-2e-f2. CLI gw-world:/> add Address EthernetAddress wwwsrv1_mac Address=08-a3-67-bc-2e-f2 3.1.3. Ethernet Addresses Chapter 3. Fundamentals 75

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. 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. As an example, a group containing two IP ranges, one with addresses 192.168.0.10 - 192.168.0.15 and the other with addresses 192.168.0.14 - 192.168.0.19, will result in a single IP range with addresses 192.168.0.10 - 192.168.0.19. Keep in mind, however, that for obvious reasons, IP address objects cannot be combined with Ethernet MAC addresses. 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 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 _ip and network objects are named _net. As an example, an interface named lan will have an associated interface IP object named lan_ip, and a network object named lannet. Default Gateway 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. 3.1.4. Address Groups Chapter 3. Fundamentals 76

address will be 0.0.0.0/0). all-nets The all-nets IP address object is initialized to the IP address 0.0.0.0/0, which represents all possible IP addresses. The all-nets IP object is used extensively in the configuration of NetDefendOS and it is important to understand its significance. 3.1.6. 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 IP rule sets, where related IP rules can be grouped together in administrator created folders. 3.1.6. Address Book Folders Chapter 3. Fundamentals 77

definition is usually based on one of the major transport protocols such as TCP or UDP, with the associated port number(s). The HTTP service, for instance, is defined as using the TCP protocol with associated port 80. However, service objects are not restricted to just TCP or UDP. They can be used to define ICMP messages, as well as a user-definable IP protocol. Services as Objects Services are passive objects in that they cannot carry out any action in the system on their own. Instead, Service objects are used frequently in the various security policies defined by rule sets. For instance, a rule in the IP rule set can use a Service object as a filter to decide whether or not to allow certain traffic through the NetDefend Firewall. For more information on how service objects are being used with IP rules, see Section 3.5, “The IP Rule Set”. Predefined Services A large number of Service objects come predefined with NetDefendOS. These include common services such as HTTP, FTP, Telnet and SSH. Predefined Services can be used and also modified just like user-defined Services. However, it is recommended NOT to make any changes to predefined services, but instead create new ones with the desired parameters. Example 3.6. Listing the Available Services To produce a listing of the available services in the system: CLI gw-world:/> show Service The output will look similar to the following listing: ServiceGroup Name Comments ------------ -------------------------------------------------- all_services All ICMP, TCP and UDP services all_tcpudp All TCP and UDP services ipsec-suite The IPsec+IKE suite l2tp-ipsec L2TP using IPsec for encryption and authentication l2tp-raw L2TP control and transport, unencrypted pptp-suite PPTP control and transport ServiceICMP ... Web Interface 1. Go to Objects > Services Example 3.7. Viewing a Specific Service 3.2. Services Chapter 3. Fundamentals 78

CLI gw-world:/> show Service ServiceTCPUDP echo The output will look similar to the following listing: Property Value ----------------- ---------------- Name: echo DestinationPorts: 7 Type: TCPUDP (TCP/UDP) SourcePorts: 0-65535 PassICMPReturn: No ALG: (none) MaxSessions: 1000 Comments: Echo service Web Interface 1. Go to Objects > Services 2. Select the specific service object in the table 3. A listing all services will be presented 3.2.2. TCP and UDP Based Services Most applications are using TCP and/or UDP as transport protocol for transferring application data over IP networks. TCP (Transmission Control Protocol) is a connection-oriented protocol that, among other things, includes mechanisms for reliable transmission of data. TCP is used by many common applications where error-free transfers are mandatory, such as HTTP, FTP and SMTP. Streaming Applications For other types of applications where data delivery speed is of greater importance, for example with streaming audio and video, 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 can be specified in a number of ways. These are: Single Port For many services, a single destination port is sufficient. HTTP, for instance, uses destination port 80 in most cases. SMTP uses port 25 and so on. For these types of Service, the single port number is simply specified in the TCP/UDP service object. 3.2.2. TCP and UDP Based Services Chapter 3. Fundamentals 79

example, the NetBIOS protocol used by Microsoft Windows uses destination ports 137 to 139. To define a range of ports in a TCP/UDP service object, the format mmm-nnn is used. A port range is inclusive, meaning that a range specified as 137-139 covers ports 137, 138 and 139. Multiple Ports and Port Ranges Multiple ranges or individual ports may also be entered, separated by commas. This provides the possibility to cover a wide range of ports using only a single TCP/UDP Service object. For instance, all Microsoft Windows networking can be covered using a port definition specified as 135-139,445. HTTP and Secure HTTP (HTTPS) can be covered by stating destination ports 80,443. Tip: Source port values The above methods of specifying port numbers are used not just for destination ports. Source port definitions can follow the same conventions, although it is usual that the source ports are left as their default value which are the range 0-65535 (corresponding to all possible source ports). Example 3.8. Adding a TCP/UDP Service This example shows how to add a TCP/UDP Service, using destination port 3306, which is used by MySQL: CLI gw-world:/> add Service ServiceTCPUDP MySQL DestinationPorts=3306 Type=TCP 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 Apart from protocol and port information, TCP/UDP Service objects also contain several other parameters that are being described in more detail in other sections of this users guide: SYN Flood Protection A TCP based service can be configured to enable protection against SYN Flood attacks. For more details on how this feature works see Section 6.6.8, “TCP SYN Flood Attacks”. Passing 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. These ICMP errors can either be ignored or allowed to pass through, back to the requesting application. Application Layer Gateways A TCP/UDP Service can be linked to an Application Layer 3.2.2. TCP and UDP Based Services Chapter 3. Fundamentals 80

protocols. For more information see Section 6.2, “ALGs”. Max Sessions An important parameter associated with a Service is Max Sessions. This parameter is allocated a default value when the Service is associated with an ALG. The default value varies according to the ALG it is associated with. 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 instance 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 to refer to all protocols. If, for example, the requirement is only to filter on the principal protocols of TCP, UDP and ICMP then the service group all_tcpudpicmp can be used instead. 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. 3.2.3. ICMP Services Internet Control Message Protocol (ICMP), is a protocol integrated with IP for error reporting and transmitting control information. The PING service, for example, uses ICMP to test an Internet connectivity. ICMP messages are delivered in IP packets, and includes a Message Type that specifies the type, that is, 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. The ICMP message types that can be configured in NetDefendOS are listed as follows: • Echo Request: sent by PING to a destination in order to check connectivity. • Destination Unreachable: 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 3.2.3. ICMP Services Chapter 3. Fundamentals 81

• Code 5: Source Route Failed • Redirect: 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: identifies an incorrect parameter on the datagram. • Echo Reply: the reply from the destination which is sent as a result of the Echo Request. • Source Quenching: the source is sending data too fast for the receiver, the buffer has filled up. • Time Exceeded: the packet has been discarded as it has taken too long to be delivered. 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. NetDefendOS supports these types of IP protocols by using the concept of Custom IP Protocol Services. A Custom IP Protocol service is a service definition giving a name to an IP protocol number. Some of the common IP protocols, such as IGMP, are already predefined in the NetDefendOS system configuration. 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. Tip: 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. CLI 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 3.2.4. Custom IP Protocol Services Chapter 3. Fundamentals 82

5. Click OK 3.2.5. Service Groups A Service Group is, exactly as the name suggests, a NetDefendOS object that consists of a collection of services. Although the group concept is simple, it can be very useful when constructing security policies. For example, there may be a need for a set of IP rules that are identical to each other except for the service parameter. 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 that uses the group. Groups Can Contain Other Groups When a group is defined then it too can be included in a new group. This ability to have groups within groups should be used with caution since it can increase the complexity of a configuration and decrease the ability to understand any problems that arise. 3.2.5. Service Groups Chapter 3. Fundamentals 83

traffic that passes through or gets terminated in the system is done so through one or several interfaces. An interface can be seen as a doorway for network traffic to or from the system. Thus, when traffic enters the system through an interface, that interface would be referred to as the receiving interface (or sometimes ingress or incoming interface). Consequently, when traffic is leaving the system, the interface used to send the traffic is referred to as the sending interface (or sometimes egress interface). NetDefendOS supports a number of interface types, which can be divided into the following four major groups: Physical Interfaces Each physical interface represents a physical port in a NetDefendOS-based product. Thus, all network traffic that originates from or is terminated in the system will eventually pass through any 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”. Physical 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 physical 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 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. 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: • 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”. • PPTP/L2TP interfaces are used as end-points for PPTP or L2TP tunnels. More information about this topic can be 3.3. Interfaces Chapter 3. Fundamentals 84

• GRE interfaces are used to establish GRE tunnels. More information about this topic can be found in Section 3.3.5, “GRE Tunnels”. Even though the various types of interfaces are very different in the way they are implemented and how they work, NetDefendOS treats all interfaces as logical IP interfaces. This means that all types of interfaces can be used almost interchangeably in the various subsystems and policies. The result of this is a very high flexibility in how traffic can be controlled and routed in the system. Each interface in NetDefendOS is given a unique name to be able to select it into other subsystems. Some of the interface types provide relevant default names that are possible to modify should that be needed, while other interface types require a user-provided name. 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 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 -disable Where is the interface to be disabled. To re-enable an interface, the command is: gw-world:/> set Interface Ethernet -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. Devices broadcast data as frames and the 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, 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 becomes 3.3.2. Ethernet Interfaces Chapter 3. Fundamentals 85

then Gigabit Ethernet. Each NetDefendOS Ethernet interface corresponds to a physical Ethernet port in the system. The number of ports, their link speed and the way the ports are realized, is dependent on the hardware model. Note: Additional switch ports Some systems use an integrated layer 2 switch for providing additional physical Ethernet ports. Such additional ports are seen as a single interface by NetDefendOS. Ethernet Interface Names 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 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. Ethernet IP Addresses 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”). 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 instance, 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. 3.3.2. Ethernet Interfaces Chapter 3. Fundamentals 86

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”. Network Addresses 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. Specifying a 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. Using DHCP on Ethernet Interfaces NetDefendOS includes a DHCP client feature for dynamic assignment of address information. 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”. The enabling of DHCP on an interface is an option in the properties of an interface and can be enabled or disabled by the administrator. By default, it is disabled. If the interface is being used for connection to the public Internet via an ISP using a fixed IP address for the interface then DHCP shouldn't be used. Note: A gateway IP address 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. Example 3.10. Enabling DHCP CLI gw-world:/> set Interface Ethernet wan DHCPEnabled=Yes 3.3.2. Ethernet Interfaces Chapter 3. Fundamentals 87

2. Select the Ethernet interface of interest 3. Enable the Enable DHCP client option 4. Click OK 3.3.2.1. Useful CLI Commands for Ethernet Interfaces This section summarizes the CLI commands most commonly used for examining and manipulating NetDefendOS Ethernet interfaces. Ethernet interfaces can also be examined through the Web Interface but for some operations the CLI must be used. To show the current interface assigned to the IP address wan_ip: gw-world:/> show Address IP4Address InterfaceAddresses/wan_ip Property Value --------------------- --------------------------- Name: wan_ip Address: 0.0.0.0 UserAuthGroups: NoDefinedCredentials: No Comments: IP address of interface wan To show the current interface assigned to the network wan_net: gw-world:/> show Address IP4Address InterfaceAddresses/wan_net Property Value --------------------- ------------------------ Name: wan_net Address: 0.0.0.0/0 UserAuthGroups: NoDefinedCredentials: No Comments: Network on interface wan To show the current interface assigned to the gateway wan_gw: gw-world:/> show Address IP4Address InterfaceAddresses/wan_gw Property Value --------------------- --------------------------------- Name: wan_gw Address: 0.0.0.0 UserAuthGroups: NoDefinedCredentials: No Comments: Default gateway for interface wan By using the tab key at the end of a line, tab completion can be used to complete the command: gw-world:/> show Address IP4Address InterfaceAddresses/wan_ [] [ []]: InterfaceAddresses/wan_br InterfaceAddresses/wan_gw InterfaceAddresses/wan_dns1 InterfaceAddresses/wan_ip InterfaceAddresses/wan_dns2 InterfaceAddresses/wan_net 3.3.2. Ethernet Interfaces Chapter 3. Fundamentals 88

gw-world:/> set Address IP4Address [] []: dnsserver1_ip InterfaceAddresses/wan_br timesyncsrv1_ip InterfaceAddresses/aux_ip InterfaceAddresses/wan_dns1 InterfaceAddresses/aux_net InterfaceAddresses/wan_dns2 InterfaceAddresses/dmz_ip InterfaceAddresses/wan_gw InterfaceAddresses/dmz_net InterfaceAddresses/wan_ip InterfaceAddresses/lan_ip InterfaceAddresses/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 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 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= PCIBus= PCISlot= PCIPort= 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 EthernetDriver=IXP4NPEEthernetDriver PCIBus=0 PCISlot=0 PCIPort=2 3.3.2. Ethernet Interfaces Chapter 3. Fundamentals 89

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. 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 Mechanisms NetDefendOS follows the IEEE 802.1Q specification for VLAN which functions by adding a Virtual LAN Identifier (VLAN ID) to Ethernet frame headers. A 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 interface. With NetDefendOS, the VLAN ID must be unique for the physical interface and the same VLAN ID can be used on different physical interfaces. Packets received through Ethernet frames 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 interface for further rule set processing. If VLAN tagged traffic is received on a physical interface and there is no VLAN defined for that interface with a corresponding VLAN ID then that traffic is dropped by NetDefendOS and an unknown_vlanid log message is generated. A NetDefend Firewall interface does not need to be dedicated to VLANs and can carry a mixture of VLAN and non-VLAN traffic. 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. Physical VLAN Connection with VLAN The illustration below shows the connections for a typical NetDefendOS VLAN scenario. Figure 3.1. VLAN Connections 3.3.3. VLAN Chapter 3. Fundamentals 90

• One of more VLANs are configured on a physical NetDefend Firewall interface and this is connected directly to a switch. This link acts as a VLAN trunk. The switch used must support port based VLANs. This means that each port on the switch can be configured with the ID of the VLAN or VLANs that the port is connected to. 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-access VLAN. 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. License Limitations 3.3.3. VLAN Chapter 3. Fundamentals 91

the parameters of the license used. Different hardware models have different licenses and different limits on VLANs. Summary of VLAN Setup It is important to understand that the administrator should treat a VLAN interface just like a physical interface in that they require at least IP rules and routes to be defined in order to function. If, for instance, no Allow rule is defined in the IP rule set for a VLAN interface then packets arriving on that interface will be dropped. 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. Example 3.11. Defining a VLAN This simple example defines a virtual LAN called VLAN10 with a VLAN ID of 10. Note that this Virtual LAN interface will use the IP address of the corresponding Ethernet interface, as no IP address is specified. CLI gw-world:/> add Interface VLAN VLAN10 Ethernet=lan Network=all-nets VLANID=10 Web Interface 1. Go to Interfaces > VLAN > Add > VLAN 2. Enter a suitable name for the VLAN, in this case VLAN10 3. Now enter: • Interface: lan • VLAN ID: 10 4. Click OK 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 3.3.4. PPPoE Chapter 3. Fundamentals 92

users on an Ethernet network to the Internet through a common serial interface, such as a single DSL line, wireless device or cable modem. All the users on the Ethernet share a common connection, while access control can be done on a per-user basis. Internet server providers (ISPs) often require customers to connect through PPPoE to their broadband service. Using PPPoE the ISP can: • Implement security and access-control using username/password authentication • Trace IP addresses to a specific user • Allocate IP address automatically for PC users (similar to DHCP). IP address provisioning can be per user group The PPP Protocol Point-to-Point Protocol (PPP), is a protocol for communication between two computers using a serial interface, such as the case of a personal computer connected through a switched telephone line to an ISP. In terms of the OSI model, PPP provides a layer 2 encapsulation mechanism to allow packets of any protocol to travel through IP networks. PPP uses Link Control Protocol (LCP) for link establishment, configuration and testing. Once the LCP is initialized, one or several Network Control Protocols (NCPs) can be used to transport traffic for a particular protocol suite, so that multiple protocols can interoperate on the same link, for example, both IP and IPX traffic can share a PPP link. PPP Authentication PPP authentication is optional with PPP. Authentication protocols supported are Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP) and Microsoft CHAP (version 1 and 2). If authentication is used, at least one of the peers has to authenticate itself before the network layer protocol parameters can be negotiated using NCP. During the LCP and NCP negotiation, optional parameters such as encryption, can be negotiated. 3.3.4.2. PPPoE Client Configuration The PPPoE interface Since the PPPoE protocol runs PPP over Ethernet, the firewall needs to use one of the normal Ethernet interfaces to run PPPoE over. Each PPPoE Tunnel is interpreted as a logical interface by the NetDefendOS, with the same routing and configuration capabilities as regular interfaces, with the IP rule set being applied to all traffic. Network traffic arriving at the firewall through the PPPoE tunnel will have the PPPoE tunnel interface as its source interface. For outbound traffic, the PPPoE tunnel interface will be the destination interface. As with any interface, one or more routes are defined so NetDefendOS knows what IP addresses it should accept traffic from and which to send traffic to through the PPPoE tunnel. The PPPoE client can be configured to use a service name to distinguish between different servers on the same Ethernet network. IP address information PPPoE uses automatic IP address allocation which is similar to DHCP. When NetDefendOS 3.3.4. PPPoE Chapter 3. Fundamentals 93

address of the interface. User authentication If user authentication is required by the ISP, the username and password can be setup in NetDefendOS for automatic sending to the PPPoE server. Dial-on-demand If dial-on-demand is enabled, the PPPoE connection will only be up when there is traffic on the PPPoE interface. It is possible to configure how the firewall should sense activity on the interface, either on outgoing traffic, incoming traffic or both. Also configurable is the time to wait with no activity before the tunnel is disconnected. Unnumbered PPPoE When NetDefendOS acts as a PPPoE client, support for unnumbered PPPoE is provided by default. The additional option also exists to force unnumbered PPPoE to be used in PPPoE sessions. Unnumbered PPPoE is typically used when ISPs want to allocate one or more preassigned IP addresses to users. These IP addresses are then manually entered into client computers. The ISP does not assign an IP address to the PPPoE client at the time it connects. A further option with the unnumbered PPPoE feature in NetDefendOS is to allow the specification of a single IP address which is used as the address of the PPPoE client interface. This address can serve the following purposes: • The IP address specified will be sent to the PPPoE server as the "preferred IP". If unnumbered PPPoE is not forced, the server may choose to not accept the preferred IP and instead assign another IP address to the PPPoE client. When the option to force unnumbered PPPoE is selected, the client (that is to say NetDefendOS) will not accept assignment of another IP address by the server. • The IP address specified, or possibly the address assigned by the PPPoE server when unnumbered PPPoE is not forced, will serve as the IP address of the PPPoE client interface. This will be used as the local IP address for traffic leaving the interface when the traffic is originated or NATed by the NetDefend Firewall. Example 3.12. Configuring a PPPoE client This example shows how to configure a PPPoE client on the wan interface with traffic routed over PPPoE. CLI gw-world:/> add Interface PPPoETunnel PPPoEClient EthernetInterface=wan Network=all-nets Username=exampleuser Password=examplepw Web Interface 1. Go to Interfaces > PPPoE > Add > PPPoE Tunnel 2. Then enter: • Name: PPPoEClient • Physical Interface: wan • Remote Network: all-nets (as we will route all traffic into the tunnel) 3.3.4. PPPoE Chapter 3. Fundamentals 94

• Username: Username provided by the service provider • Password: Password provided by the service provider • Confirm Password: Retype the password • Under Authentication specify which authentication protocol to use (the default settings will be used if not specified) • Disable the option Enable dial-on-demand • Under Advanced, if Add route for remote network is enabled then a new route will be added for the interface 3. Click OK Note: PPPoE has a discovery protocol To provide a point-to-point connection over Ethernet, each PPP session must learn the Ethernet address of the remote peer, as well as establish a unique session identifier. PPPoE includes a discovery protocol that provides this. 3.3.5. GRE Tunnels Overview The Generic Router Encapsulation (GRE) protocol is a simple, encapsulating protocol that can be used whenever there is a need to tunnel traffic across networks and/or through network devices. GRE does not provide any security features but this means that its use has extremely low overhead. Using GRE GRE is typically used to provide a method of connecting two networks together across a third network such as the Internet. The two networks being connected together communicate with a common protocol which is tunneled using GRE through the intervening network. Examples of GRE usage are: • Traversing network equipment that blocks a particular protocol. • Tunneling IPv6 traffic across an IPv4 network. • Where a UDP data stream is to be multicast and it is necessary to transit through a network device which does not support multicasting. GRE allows tunneling though the network device. GRE Security and Performance A GRE tunnel does not use any encryption for the communication and is therefore not, in itself, secure. Any security must come from the protocol being tunneled. The advantage of GRE's lack of encryption is the high performance which is achievable because of the low traffic processing overhead. The lack of encryption can be acceptable in some circumstances if the tunneling is done across an internal network that is not public. Setting Up GRE 3.3.5. GRE Tunnels Chapter 3. Fundamentals 95

interface by NetDefendOS, with the same filtering, traffic shaping and configuration capabilities as a standard interface. The GRE options are: • IP Address - This is the IP address of the sending interface. This is optional and can be left blank. If it is left blank then the sending IP address will default to the local host address of 127.0.0.1. • Remote Network - The remote network which the GRE tunnel will connect with. • Remote Endpoint - This is the IP address of the remote device which the tunnel will connect with. • Use Session Key - A unique number can optionally be specified for the tunnel. This allows more than one GRE tunnel to run between the same two endpoints. The Session Key value is used to distinguish between them. • Additional Encapsulation Checksum - The GRE protocol allows for an additional checksum over and above the IPv4 checksum. This provides an extra check of data integrity. The Advanced settings for a GRE interface are: • Automatically add route for remote network - This option would normally be checked in order that the routing table is automatically updated. The alternative is to manually create the required route. • Address to use as source IP - It is possible to specify a particular IP address as the source interface IP for the tunnel. GRE and the IP Rule Set An established GRE tunnel does not automatically mean that all traffic coming from or to that GRE tunnel is trusted. On the contrary, network traffic coming from the GRE tunnel will be transferred to the NetDefendOS IP rule set for evaluation. The source interface of the network traffic will be the name of the associated GRE Tunnel. The same is true for traffic in the opposite direction, that is, going into a GRE tunnel. Furthermore a Route has to be defined so NetDefendOS knows what IP addresses should be accepted and sent through the tunnel. An Example GRE Scenario 3.3.5. GRE Tunnels Chapter 3. Fundamentals 96

communicate with each other through the intervening internal network 172.16.0.0/16. Any traffic passing between A and B is tunneled through the intervening network using a GRE tunnel and since the network is internal and not public there is no need for encryption. Setup for NetDefend Firewall "A" Assuming that the network 192.168.10.0/24 is lannet on the lan interface, the steps for setting up NetDefendOS on A are: 1. In the address book set up the following IP objects: • remote_net_B: 192.168.11.0/24 • remote_gw: 172.16.1.1 • ip_GRE: 192.168.0.1 2. Create a GRE Tunnel object called GRE_to_B with the following parameters: • IP Address: ip_GRE • Remote Network: remote_net_B • Remote Endpoint: remote_gw • Use Session Key: 1 • Additional Encapulation Checksum: Enabled 3. Define a route in the main routing table which routes all traffic to remote_net_B on the GRE_to_B GRE interface. This is not necessary if the option Add route for remote network is enabled in the Advanced tab, since this will add the route automatically. 4. Create the following rules in the IP rule set that allow traffic to pass through the tunnel: Name Action Src Interface Src Network Dest Interface Dest Network Service To_B Allow lan lannet GRE_to_B remote_net_B All From_B Allow GRE_to_B remote_net_B lan lannet All Setup for NetDefend Firewall "B" Assuming that the network 192.168.11.0/24 is lannet on the lan interface, the steps for setting up NetDefendOS on B are as follows: 1. In the address book set up the following IP objects: • remote_net_A: 192.168.10.0/24 • remote_gw: 172.16.0.1 • ip_GRE: 192.168.0.2 2. Create a GRE Tunnel object called GRE_to_A with the following parameters: • IP Address: ip_GRE • Remote Network: remote_net_A 3.3.5. GRE Tunnels Chapter 3. Fundamentals 97

• Use Session Key: 1 • Additional Encapulation Checksum: Enabled 3. Define a route in the main routing table which routes all traffic to remote_net_A on the GRE_to_A GRE interface. This is not necessary if the option Add route for remote network is enabled in the Advanced tab, since this will add the route automatically. 4. Create the following rules in the IP rule set that allow traffic to pass through the tunnel: Name Action Src Interface Src Network Dest Interface Dest Network Service To_A Allow lan lannet GRE_to_A remote_net_A All From_A Allow GRE_to_A remote_net_A lan lannet All 3.3.6. Interface Groups Multiple NetDefendOS interfaces can be grouped together to form an Interface Group. Such a logical group can then be subject to common policies and be referred to using a group name in the IP rule set and User Authentication Rules. A group can consist of regular Ethernet interfaces, VLAN interfaces, or VPN Tunnels and the members of a group need not be of the same type. A group might consist, for example, of two Ethernet interfaces and four VLAN interfaces. Example 3.13. Creating an Interface Group CLI gw-world:/> add Interface InterfaceGroup examplegroup Members=exampleif1,exampleif2 Web Interface 1. Go to Interfaces > Interface Groups > Add > InterfaceGroup 2. Enter the following information to define the group: • Name: The name of the group to be used later • Security/Transport Equivalent: If enabled, the interface group can be used as a destination interface in rules where connections might need to be moved between the interfaces - examples of such usage are Route Fail-Over and OSPF • Interfaces: Select the interfaces to be in the group 3. Click OK 3.3.6. Interface Groups Chapter 3. Fundamentals 98

data link layer hardware address and it is used to resolve an IP address into its corresponding Ethernet address. ARP operates at the OSI Data Link Layer (Layer 2 - see Appendix D, The OSI Framework) and is encapsulated by Ethernet headers for transmission. A host in an Ethernet network can communicate with another host only if it knows the Ethernet address (MAC address) of that host. Higher level protocols such as IP make use of IP addresses which are fundamentally different from a lower level hardware addressing scheme like the MAC address. ARP is used to retrieve the Ethernet MAC address of a host by using its IP address. When a host needs to resolve an IP address to the corresponding Ethernet address, it broadcasts an ARP request packet. The ARP request packet contains the source MAC address, the source IP address and the destination IP address. Each host in the local network receives this packet. The host with the specified destination IP address, sends an ARP reply packet to the originating host with its MAC address. 3.4.2. ARP in NetDefendOS NetDefendOS provides not only standard support for ARP, but also adds a number of security checks on top of the protocol implementation. As an example, NetDefendOS will by default not accept ARP replies for which the system has not sent out a corresponding ARP query for. Without this type of protection, the system would be vulnerable to "connection hijacking". NetDefendOS supports both Dynamic ARP as well as Static ARP, and the latter is available in two modes: Publish and XPublish. Dynamic ARP is the main mode of operation for ARP, where NetDefendOS sends out ARP requests whenever it needs to resolve an IP address to an Ethernet address. The ARP replies are stored in the ARP cache of the system. Static ARP is used for manually lock an IP address to a specific Ethernet address. This is explained in more detail in the sections below. 3.4.3. ARP Cache The ARP Cache is the temporary table in NetDefendOS for storing the mapping between IP and Ethernet addresses. The ARP cache is empty at system startup and will be populated with entries as needed. The contents of a typical (minimal) ARP Cache looks similar to the following table: Type IP Address Ethernet Address Expire Dynamic 192.168.0.10 08:00:10:0f:bc:a5 45 Dynamic 193.13.66.77 0a:46:42:4f:ac:65 136 Publish 10.5.16.3 4a:32:12:6c:89:a4 - The first item in this ARP Cache is a dynamic ARP entry which tells us that IP address 192.168.0.10 is mapped to an Ethernet address of 08:00:10:0f:bc:a5. The second item dynamically maps the IP address 193.13.66.77 to Ethernet address 0a:46:42:4f:ac:65. Finally, the third item is a static ARP entry binding the IP address 10.5.16.3 to Ethernet address 4a:32:12:6c:89:a4. The third column in the table, Expire, is used to indicate for how much longer the ARP entry will be valid. The first item, for example, has an expiry value of 45 which means that this entry will be rendered invalid and removed from the ARP Cache in 45 seconds. If traffic is going to be sent to the 192.168.0.10 IP address after the expiration, NetDefendOS will issue a new ARP request. 3.4. ARP Chapter 3. Fundamentals 99

changed by modifying the advanced setting ARP Expire. The setting ARP Expire Unknown specifies how long NetDefendOS will remember addresses that cannot be reached. This is done to ensure that NetDefendOS does not continuously request such addresses. The default value for this setting is 3 seconds. Example 3.14. Displaying the ARP Cache The contents of the ARP Cache can be displayed from within the CLI. CLI gw-world:/> arp -show ARP cache of iface lan Dynamic 10.4.0.1 = 1000:0000:4009 Expire=196 Dynamic 10.4.0.165 = 0002:a529:1f65 Expire=506 Flushing the ARP Cache If a host in your network has recently been replaced with a new hardware but keeping the same IP address, it is most likely to have a new Ethernet address. If NetDefendOS has an ARP entry for that host, the Ethernet address of that entry will be invalid, causing data sent to the host to never reach its destination. Naturally, after the ARP expiration time, NetDefendOS will learn the new Ethernet address of the requested host, but sometimes it might be necessary to manually force a re-query. This is easiest achieved by flushing the ARP cache, an operation which will delete all dynamic ARP entries from the cache, thereby forcing NetDefendOS to issue new ARP queries. Example 3.15. Flushing the ARP Cache This example shows how to flush the ARP Cache from within the CLI. CLI gw-world:/> arp -flush ARP cache of all interfaces flushed. Size of the ARP Cache By default, the ARP Cache is able to hold 4096 ARP entries at the same time. This is feasible for most deployments, but in rare occasions, such as when there are several very large LANs directly connected to the firewall, it might be necessary to adjust this value. This can be done by modifying the advanced setting ARP Cache Size. So-called "hash tables" are used to rapidly look up entries in the ARP Cache. For maximum efficiency, a hash should be twice as large as the table it is indexing, so if the largest directly-connected LAN contains 500 IP addresses, the size of the ARP entry hash should be at least 1000 entries. The administrator can modify the advanced setting ARP Hash Size to reflect specific network requirements. The default value of this setting is 512. The setting ARP Hash Size VLAN setting is similar to the ARP Hash Size setting, but affects the 3.4.3. ARP Cache Chapter 3. Fundamentals 100