Extending Network Management Through Firewalls

Transcription

1 Extending Network Management Through Firewalls Design Secure Network Management Solutions Secure Network Management Communications Best Practice for DMZ Management Stephen Hochstetler Harry Tanner Ramachandra Kulkarni Sebastian Mika ibm.com/redbooks

2

3 SG International Technical Support Organization Extending Network Management Through Firewalls June 2001

4 Take Note! Before using this information and the product it supports, be sure to read the general information in Appendix G, Special notices on page 349. First Edition (June 2001) This edition applies to Tivoli NetView Version 6.01, Program Number 5698-NVW. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip Burnet Road Austin, Texas When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation All rights reserved. Note to U.S Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

5 Contents Figures vii Tables xv Preface xvii The team that wrote this redbook xviii Comments welcome xx Part 1. Concepts Chapter 1. Introduction to firewalls TCP/IP preview Well-known ports High ports The concept of the firewall The components of a firewall Terminologies associated with the firewall Firewall architectures Screening router Bastion Dual-homed gateway Firewall objectives and firewall rules Beyond the firewall: filtering content Virtual Private Networks Case study of VPN Chapter 2. Network management Introduction Simple Network Management Protocol (SNMP) IP network communication Network management with NetView Centralized network management Distributed network management solution Remote network management access NetView as part of a Tivoli system management platform Tivoli Decision Support (TDS) Tivoli Enterprise Console (TEC) Network management in firewall areas and secure zones Copyright IBM Corp iii

6 Part 2. Network management environments Chapter 3. Management across a single firewall Introduction Definition of terms General description of the testing environment Tivoli NetView Tivoli Mid-Level Manager (MLM) IBM SecureWay Firewall Other tools used Phase 1: Network management General topology for Phase Building network components for Phase Conclusion for Phase Phase 2: Network management across a single firewall General network topology for Phase Polling using SNMP Troubleshooting techniques NAT and firewalls Conclusion for Phase Phase 3: Distributed network management across firewalls General network topology for Phase Introducing NetView Mid-Level Manager Installing Mid-Level Manager Configuring NetView Testing communications between NetView and MLM Analysis of results MLM remote installation Conclusion to Phase Security considerations Chapter 4. Management in distributed environments Test environment Distributed management with MLMs Distributed management using NetView in unsecure networks NetView in service provider TMR NetView in its own TMR regions NetView installation recommendation TDS cooperation Sample firewall configuration rule - Oracle database connection TEC connection Forwarding events to TEC with NetView nvserverd daemon iv Extending Network Management Through Firewalls

7 4.5.2 Forwarding events to TEC with SNMP trap forwarding function Forwarding events to TEC with tecad_nv6k application Remote access to network management system Remote access with the Java Web client Secure Shell (SSH) access to network management system Chapter 5. Network management through the VPN VPN overview VPN solutions in the market IPSec-based solutions Layer 2 based VPN solutions (data link layer) VPN and network management SNMP and VPN Implementing VPN using IBM SecureWay FW for Windows NT V Static tunnel Dynamic tunnels Client to site VPN Implementing a client - site VPN using the Check Point VPN VPN client/server configuration Windows 2000 VPN configuration AIX VPN connection Firewall configuration rule Chapter 6. Network management in the DMZ The ebusiness architecture The corporate network DMZ The Internet ebusiness network management architecture Discovery and configuration polling Internet connectivity Forwarding traps Tivoli Decision Support Consolidating enterprise network management Alternative solutions Conclusion Part 3. Additional information Appendix A. IBM SecureWay Firewall installation A.1 Prerequisites A.2 Installation v

8 Appendix B. Check Point 2000 enterprise suite with Firewall B.1 Prerequisites B.2 Installation Appendix C. Installing Check Point SecuRemote VPN client C.1 Prerequisites for SecuRemote client C.2 Locating and installing the SecuRemote client Appendix D. Scripts D.1 IBM SecureWay Log Reporter D.2 Trap forwarding script Appendix E. Installing the Ethereal Sniffer E.1 Prerequisites E.2 Installation E.2.1 Installing WinCap E.2.2 Installing Ethereal software Appendix F. Using the additional material F.1 Locating the additional material on the Internet F.2 Using the Web material F.2.1 How to use the Web material Appendix G. Special notices Appendix H. Related publications H.1 IBM Redbooks H.2 IBM Redbooks collections H.3 Other resources H.4 Referenced Web sites How to get IBM Redbooks IBM Redbooks fax order form Abbreviations and acronyms Index IBM Redbooks review vi Extending Network Management Through Firewalls

9 Figures 1. Theoretical firewall environment8 2. Screening router9 3. Dual-homed gateways10 4. VPN case study13 5. Network management concept20 6. Network management with Tivoli NetView24 7. Distributed network management with NetView26 8. Remote access to network management system30 9. Tivoli system management structure NetView in connection with TEC and TDS Phase One topology for Scenario One IP routing on Windows NT NetView IP map topology NetView for Windows NT IP map topology Phase 2 network topology for Scenario SWF configuration client Network objects Creating network objects Network object group Creating a rule SNMP response rule Creating a service Service composition Adding a connection Connection details Connection control Netmon seed file editor Log facilities Adding log facilities Sniffer host placement Start packet capture Live capture and results CNAT and NAT Network topology and communications for Phase NetView SNMP configuration for MLM NetView with APM installed MLM alias table MLM interface status table Packet capture for MLM traps to NetView TCP conversation from MLM to NetView90 Copyright IBM Corp vii

10 41. MLM remote installation from the Tivoli Desktop MLM installation output MLM remote installation analysis - Part One Remote MLM installation analysis - Part Two MLM remote installation communication summary Network management in SP networks Test environment Distributed management with MLMs NetView in SP subnetworks Distributed management with NetView in one TMR Installation managed node from TMR server Installation NetView from TMR server NetView in unsecure networks with separate TMR NetView database integration in TDS analysis NetView database connection through firewall Oracle database connection rule Forward events with nvserverd Event forwarding administration from NetView to TEC TEC server configuration in NetView for UNIX Communications between NetView and TEC Dynamic rule configuration for RPC communication Sending events from NetView to a restricted TEC port Forward all events to TEC Configuration of trap forwarding NetView trapd configuration dialog box Forward specific events to TEC Definition of specific events Forward only rule passed events to TEC Communication NetView NT and TEC Server on NT Remote access to network management servers Communication between Java Web client and NetView server Telnet connection with subsequent export of X11 GUI X11 Forwarding through encrypted tunnel SSH test environment SSH authentication setup SSH port forwarding setup SSH session startup Running SSH session VPN main menu Tunnel definition Exporting the tunnel definitions Importing a tunnel definition at the partner firewall View of the imported tunnel viii Extending Network Management Through Firewalls

11 84. Activating the tunnel Client to site VPN Check Point FireWall-1/VPN-1 login panel Create new network object Defining network object of type network Workstation properties of the network object Defining network interfaces Authentication option for the workstation VPN parameters definition FWZ encryption properties Encapsulate the traffic User creation menu User creation and configuration User authentication definition User encryption properties FWZ properties configuration Creating the VPN rule (left half of the panel) Creating the VPN rule (right half of the panel) Policy install Policy installation Accepting unauthorized FWZ traffic Policy properties Create a site on the SecuRemote client SecuRemote client authentication Tracer Route example of encryption and encapsulation Telnet to a secure host Telnet to secure host VPN traffic - sniffer output Java Web client (normal communication, non-vpn) NetView Java Web client authentication Java Web client map options Sniffer output of the Java Web client after VPN implementation SecuRemote client behind a firewall Rule definition to allow ipip Rule definition to allow port 259 on the firewall Defining the service SecuRemote Connection SecuRemote Connection Regenerate the rules VPN client/server configuration Creating a new security policy Security Policy creation wizard Define the security policy ix

12 127. Request for secure communication Policy Wizard - Edit panel Policy properties Tunnel end point definition Policy network type Policy authentication methods IP filter list addition IP filter addition Filter wizard IP traffic source definition Traffic destination IP protocol type IP filter wizard Complete filter rule creation IP filter list Filter action Filter action wizard Filter action name Filter action general options Communication with non-ipsec computers IP traffic security Filter action wizard Filter action selection Security rule wizard IP security rules Assign the rule to the system Filter properties of the client Sniffer output of the ping packet from the client to the server VPN configuration panel IP security start options dialog Internet key management application Key management tunnel properties panel Key management policy panel Key policy property panel Key management proposals Key management proposals properties Transform properties panel Key management proposals properties after transform definition Key management policy panel after proposal definition Key management policy panel after policy definition Key management authentication method Internet Key Management Application after key tunnel definition Data management tunnel dialog x Extending Network Management Through Firewalls

13 170. Data management tunnel endpoint definition Data management policies Data management policy property panel Data management proposals panel Data management proposal definition Transforms properties definition dialog Data management proposal panel after proposal definition Data management proposals panel after new proposal definition Data management policies after new policy definition Data management options Internet Key Management Application after key tunnel definition Define the rule for IKE communication Define the rule for ESP communication Define the service for VPN rules Define the connection for the VPN The Prime Model The Primary Network Management model (PNM) DMZ discovery and configuration polling NetView IP Internet submap Object creation Internet Access object group properties Internet Access group Internet map after loadhosts command executed Relocating Internet networks to the Internet Access submap Changing symbol properties Internet management submap Internet Access disabled Sample Internet connectivity events Trap settings for NetView NT Internet Access management Performance management of exterior router without SNMP access Performance management of exterior router with SNMP access Sample router MIB-II report showing serial interface throughput Tivoli Decision Support for the enterprise VPN for secure communications Sending DMZ events directly to TEC Alternative Solution 2 - DMZ MLM Using MLM under NetView to filter traps Enable IP forwarding Installing IBM Intermediate Support Driver Insert disk for Support Driver Select IBM Intermediate Support Driver IBM Intermediate Support Driver installed xi

14 213. SecureWay Welcome Select components License agreement Installation options Confirm settings Setup in progress Hardening the system Installation summary Check Point 2000 welcome Check Point 2000 license agreement Check Point 2000 product menu Server/Gateway components selection Setup type Gateway/Server module Backward compatibility screen Destination location for firewall modules Destination location for management client Management client dialog Destination location for reporting server Reporting server modules Reporting server mail settings Web server settings of reporting server Destination location for reporting client Reporting client modules Firewall license installation Administrators dialog Firewall IP-Address Configuration of GUI clients IP Forwarding dialog Key Hit session Setup complete SecuRemote Installation Welcome panel SecuRemote license agreement Existing version dialog box SecuRemote installation directory SecuRemote Desktop Security SecuRemote Network Bindings SecuRemote setup complete Control Panel Local Area Connection Local Area Connection properties Installing Network Component Select Network Protocol xii Extending Network Management Through Firewalls

15 256. Select Driver for WinCap WinCap driver installed xiii

16 xiv Extending Network Management Through Firewalls

17 Tables 1. Comparing various gateways SNMP protocol NetView status polling MLM communication in distributed management FW1 Firewall configuration for Phase Two Service and rule Configuration for Phase Connections and services for Phase Service and rule configuration for MLM traps to NetView Connection for MLM traps to NetView Service and rule configuration - MLM remote installation from NetView Connection for MLM remote installation from NetView General communications for MLM remote installation Communication rules for distributed management with MLMs Firewall rule for installation of management node Firewall rule for NetView installation on managed node Firewall rule for NetView connection to database server Oracle databases Firewall rule for NetView connection to Oracle database Firewall rule for RPC communication Firewall rule with restricted TEC reception port Firewall rule for NetView connection to Oracle database Firewall rule for NetView NT communication with TEC NT Communication rules for Web client to NetView server Communication rule for SSH connections Firewall rule for SSH test lab Firewall rule for VPN client/server connection Copyright IBM Corp xv

18 xvi Extending Network Management Through Firewalls

19 Preface With the complexity of our distributed computer networks today, the discipline of Network Management requires more knowledge than ever before. Long gone are the days when knowing whether your computer network was available was simply a matter of pinging a system to check for connectivity. With the added challenge of implementing security architectures in today s networks, the growing concern in the market place is how we manage our networks without compromising on security. As our economy is quickly evolving into businesses that depend on others, the concepts of ebusiness, outsourcing and Internet Service Provider architectures are becoming commonplace. This redbook will help you understand the network security paradigm and its implications for network management using the Tivoli platform. It will explore the most popular architectures that exist in secure networks today and explain some fundamental concepts that are essential for any IT management specialist. We will also discuss distributed network management and the issues that you need to understand in light of network security. The book will teach you, step-by-step, how to analyze your network environment and acquire the knowledge you need to implement an effective and secure network management solution. Various architecture solutions will be provided to illustrate practical methods of managing your network. These architectures will range from the simple to the more complex distributed nature. These solutions can be used as building blocks to manage your network in the real world. A separate section will discuss network management architectures relating to service providers. Addressing the needs for end-to-end enterprise and network management using the Tivoli platform in such environments, we will examine the protocol requirements for Tivoli s NetView, Tivoli Enterprise Console (TEC), Framework (TMR), and Tivoli Decision Support (TDS) software. In an effort to address the security requirements for today s networks, we will also describe how to use different VPN tunneling techniques to enhance the security of network management communications. This will be especially useful for implementing solutions that allow remote network managers to securely manage their network from practically any location. We will describe the implementation of a VPN tunnel from Check Point FireWall-1 to the Check Copyright IBM Corp xvii

20 Point s VPN-1 SecuRemote/SecureClient and to tunnel this established VPN through IBM SecureWay Firewall product. Finally, we will examine various solutions to manage DMZ and ebusiness environments. This section will also discuss and compare different high level architectures and methods to most effectively manage your DMZ and ebusiness environment using the Tivoli platform, as well as highlight some of the security concerns that influence how we design a solution. This information will be useful for network architects and managers that need to understand key network management and security concerns pertaining to such environments. This redbook will be useful for network and IT architects, support staff and network managers who require a much more in-depth understanding of the how to architect, design, and implement network management solutions in secure networked environments. A working knowledge of the Tivoli NetView Platform is assumed, as well as a general understanding of Tivoli Enterprise Console, Tivoli Decision Support, firewalls, and TCP/IP networking. The team that wrote this redbook This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center. Stephen Hochstetler is a Project Leader at the International Technical Support Organization, Austin Center. He applies his 17 years of experience as an IT Tivoli Specialist to his work at the ITSO, where he writes extensively on all areas of Systems Management. Before joining the ITSO, Stephen worked in the Tivoli Services organization of Tivoli as a Network Management Specialist. For the last four years, he has concentrated on architectural work and the design of network management solutions for large customer environments and service providers. Harry Tanner is a Network Management Specialist in the Network Services arm of IBM Global Services Australia in Sydney. He has five years of experience in systems and network management. Prior to assuming his duties in IBM, he spent six months as a HP Openview consultant for various major corporations. He holds a degree in Computer Engineering, is a qualified MCSE, and is a certified Tivoli NetView and HP Openview consultant. His areas of expertise include network management systems, integration, and the design and development of network and systems xviii Extending Network Management Through Firewalls

21 management tools. He has also been leading the development of network management systems for IBM s Shared Network Infrastructure (SNI) in Australia for the past year. Ramachandra Kulkarni is a security consultant with iflex solutions ltd - India. iflex is part of the Citigroup worldwide and caters to banking and financial domains of the industry. He has a total of eight years of experience in network design, administration, and network security consulting, as well as training on network security products. He has worked with IBM Global Services, as well as with IBM India, as a consultant and trainer prior to joining iflex. He currently consults on security implementations for various major clients of iflex worldwide. He also conducts information system audits for various corporate clients. He is certified by Microsoft and Novell, and is a certified solution expert on the Tivoli SecureWay firewall. Sebastian Mika is an advisory IT-Specialist of IBM Global Services Germany in Berlin. He has a total of five years of experience in software development, systems, and network management. He holds a degree in telecommunications and business and is a qualified MCSE. He is involved in major consulting and implementation projects for systems and network management in the banking, finance, and service provider sectors. His areas of expertise include software development, UNIX, Tivoli systems, and network management platforms, as well as other multi-vendor management software, such as HP Openview. Thanks to the following people for their invaluable contributions to this project: International Technical Support Organization, Austin Center Caroline Cooper, Morten Moeller, Axel Bücker, Wade Wallace Tivoli Systems, Austin Urs Schwarzenbach Tivoli Systems, Raleigh Rick Reed, James Shanks, George desocio IBM SNI Development Team, Boulder CO Andrew J. Bernoth cbi, Reno Richard T.Nall xix

22 Comments welcome Your comments are important to us! We want our Redbooks to be as helpful as possible. Please send us your comments about this or other Redbooks in one of the following ways: Fax the evaluation form found in IBM Redbooks review on page 375 to the fax number shown on the form. Use the online evaluation form found at ibm.com/redbooks Send your comments in an Internet note to xx Extending Network Management Through Firewalls

23 Part 1. Concepts Copyright IBM Corp

24

25 Chapter 1. Introduction to firewalls What does security mean? There is always a trade-off to be made between making a computer secure and the functions it can provide. This balance is very difficult to achieve and has led to a common comment among security experts that the most secure computer is one that is completely turned off. With the advent of networking technologies and the Internet, the problem of security has been compounded, because the communication channel on which the network depends is itself prone to attacks. An attack can be defined as a process in which computing resources are rendered inaccessible by authorized /unauthorized people. Attacks can be of two types 1. Passive attacks: Tapping or tracing the communication. These are the most difficult attacks to predict. Theoretically, any and every communication can be tapped by an intruder who could then take advantage of the communication to gain access to other resources in an organization. 2. Active attacks: This is a direct taking-over the functionality of the computer and using the information stored in these resources to render the network of computer unusable. It does not matter if an attack is done for fun or for profit; it is always your invaluable data which will be at stake. 1.1 TCP/IP preview Although it is assumed that the user who is reading this redbook has fair knowledge of TCP/IP, the following section gives a brief overview of the ports and other related subjects used in this redbook. As you will later appreciate during the configuration of the firewall, an in-depth knowledge of ports and general security principles will be very beneficial. Each process that wants to communicate with another process identifies itself to the TCP/IP protocol suite by one or more ports. A port is a 16-bit number used by the host-to-host protocol to identify to which higher-level protocol or application program (process) it must deliver incoming messages. We refer to ports as belonging to one of two major groups: well-known and high ports. Copyright IBM Corp

26 1.1.1 Well-known ports Well-known ports belong to standard services, for example, Telnet uses port 23 and Tivoli s oserv uses port 94. Well-known port numbers range from 1 to 1023 (prior to 1992, the range between 256 and 1023 was used for UNIX-specific servers). On UNIX, the ports up to 1023 are privileged in the sense that the daemons using them are generally run as root. This does not apply to Windows NT. Well-known ports are typically odd numbers, because early systems using the port concept required an odd/even pair of ports for duplex operations. Most servers require only a single port. There are exceptions such as the FTP server, which uses two (20 and 21). Originally documented in RFCs, the well-known ports are now managed and assigned by the Internet Assigned Numbers Authority (IANA). The reason for having well-known ports is to allow clients to be able to find servers without the need for implementation-specific configuration information. On most systems, these ports can only be controlled by system processes or by programs executed by privileged users. The well-known port number list is available at: High ports High ports are those above Given that a port is a 16-bit number, the range of high ports is from 1024 to Note that organizations can request IANA to track ports - either well-known or in the range of 1024 to These tracked ports are known as Registered ports. However, as any application can make use of ports in the 1024 to range, there is no guarantee that a port named in this range will be used by the registered service. The range of ports between and are usually referred to as dynamic or private. High ports are not controlled by IANA beyond the registration of ports already described. On most systems, any high port can be used by ordinary user-developed programs. Confusion due to two different applications trying to use the same port numbers on one host is avoided by writing those applications to request an available port from the host TCP/IP implementation. Because this port number is dynamically assigned, it may differ from one invocation of an application to the next. 1.2 The concept of the firewall Every time an organization wants its internal computer network to be connected to the Internet, it faces a challenge in terms of how to keep the internal network safe from the outside intruders while allowing employees access to the external world in order to meet various business requirements. Hackers (a term used to describe users on the Internet who indulge in 4 Extending Network Management Through Firewalls

27 unauthorized attempts to get into the company network) can theoretically break into the company network and steal or damage the important data, damage important computer systems or the entire network. To overcome this challenge and allow themselves to be protected against hackers, companies build firewalls to give their employees legitimate access to the resources outside the company network and prevent an unauthorized external entry into their network. A firewall is a combination of hardware and software that will sit in the entry point to the company network (or the point where company network is connected to the Internet) and will monitor the type of traffic coming into the company network and make decisions if the packet is going to be let in or not. To understand how a firewall works, consider this example. Imagine a building where you want to restrict access and to control people who enter in. You define, in the architecture of the building, a single lobby as the only entrance point. In this lobby, you have some receptionists that welcome, some security guards that watch, some video cameras that record, and some badge readers to authenticate people who enter the building. This works very well to control a private building. But imagine that a non-authorized person succeeds in entering. To protect the building against any actions from this person is more difficult. However, if you supervise his or her movements, you at least have a chance to detect any suspicious behavior and repair any damage. When you are defining your firewall strategy, you may think it is sufficient to prohibit everything that presents a risk for the organization and allow the rest. However, because of new attack methods, you may not be able to prevent every attack and, as in the case of the building, you need to monitor for signs that somehow your defenses have been breached. Generally, it is much more damaging and costly to recover from a break-in than to prevent it in the first place. Now, coming to what a firewall is, in the above example, it is the TCP/IP equivalent of a security gate at the entrance to your company. All traffic (data packets) must be screened by it and the security guard (firewall) there allows only authorized people (packets) to gain entry into the company building (network). 1.3 The components of a firewall The components of a firewall include: 1. Packet filtering (also called a screening router) 2. Application Proxies Chapter 1. Introduction to firewalls 5

28 3. Circuit level gateways 4. Virtual Private Networking Screening Routers can look at the packet IP address (Network layer), and even the types of connections (Transport layer) and then provide filtering based on that information. A screening router may be a stand-alone routing device or a computer that contains two network interface cards (dual-homed system). The router connects two networks and performs packet filtering to control traffic between the networks. Administrators program the device with a set of rules that define how packet filtering is done. Ports can also be blocked; for example, if your company security policy is that only Web browsing (HTTP) is allowed and the rather dangerous FTP not to be allowed, packet filtering by the screening routers can achieve this by implementing appropriate rules. An application-level proxy server provides all the basic proxy features and also provides extensive packet analysis. When packets from the outside arrive at the gateway, they are examined and evaluated to determine if the security policy allows the packet to enter into the internal network. Not only does the server evaluate IP addresses, it also looks at the data in the packets to stop hackers from hiding information in the packets In case any employee of the company wants to access a server on the Internet: 1. A request from the computer is sent to the proxy server. 2. The proxy server contacts the server on the Internet with its address as the source address (not the actual computer which requested it). 3. The proxy server then sends the information back from the Internet server to the actual computer which requested the data. By doing this, the IP address of the internal (company) computer is never known outside of its own network. Proxy servers also log the information on who has requested and what are the transfer details to make an analysis of the Internet access. The IBM SecureWay Firewall provides application level proxies (FTP, Telnet, and HTTP). Circuit level gateways - This type of proxy server provides a controlled network connection between internal and external systems. A virtual "circuit" exists between the internal client and the proxy server. Internet requests go through this circuit to the proxy server, and the proxy server delivers those 6 Extending Network Management Through Firewalls

29 requests to the Internet after changing the IP address. External users only see the IP address of the proxy server. Responses are then received by the proxy server and sent back through the circuit to the client. While traffic is allowed through, external systems never see the internal systems. The IBM SecureWay Firewall provides a circuit level gateway that is called as the socks server. Table 1 shows the differences between the application level gateway and the circuit level gateway Table 1. Comparing various gateways Particulars Application level Gateway Circuit level Gateway Operates in OSI Layer Application Transport through session Require proxies for each service (for example, HTTP, FTP, and so on) Yes No TCP/IP Translation Done at the Proxy Done at the client Logging Provided Usually no logging Modified Client Required No Yes URL filtering capability Yes No Virtual Private Network - Section 1.7, Virtual Private Networks on page 11 gives an introduction on VPN and also gives a case study of VPN. 1.4 Terminologies associated with the firewall Secure Network (SN) Firewall (FW) Typically, this is the organization network where all the safe data resides. This is the area where all the applications that are required for the day to day business of the company are run. Examples of these could be the company accounting function as well as the company payroll function. See Figure 1 on page 8. A combination of hardware and software, with the help of expertly built Chapter 1. Introduction to firewalls 7

30 Demilitarized Zone (DMZ) access rules, that ensure the perimeter security of the organization. A network added between the company network and the external network to facilitate layered security. Typical elements that we will find in DMZ would be the Web servers and mail servers. Dual homed host A general purpose computer which has at least two network interfaces. Network Address Translation (NAT) The procedure by which a router/firewall modifies the source IP address. This is done for security reason as this process will enable to hide the actual internal address. Virtual Private Network (VPN) A connection which normally spans geographic location and uses the Internet as the connecting medium. It also uses tunneling and encryption techniques to ensure the security of the data. Firewall DMZ Router X Internet Secure Network Figure 1. Theoretical firewall environment 1.5 Firewall architectures The following section will describe the various firewall architectures Screening router The first and most commonly used strategy is to separate the private IP network from the Internet by inserting a router between them. This router 8 Extending Network Management Through Firewalls

31 filters all IP packets passing through and is called a screening filter. This way, you can prevent access to machines or to ports in the private network and also do the reverse: prevent an inside machine from accessing the Internet. The connections are made as shown in Figure 2. But if you do this, there is no way to control what happens at the application layer. That is, you may want to allow one type of traffic across the gateway but not another. You could manage this at the application host itself, but the more machines on which you have to impose controls, the less control you have. Nonetheless, a screening filter is a very useful tool to use in conjunction with other tools as a security building block. Secure Network Internet Screening Router X Figure 2. Screening router Bastion A bastion is a machine placed between the secure and non-secure network where the IP forwarding is broken, which means no IP packet can go through this machine. As the routing is broken, the only place from which you can access both networks is the bastion itself. Therefore, only users who have an account on the bastion, with a double identification (one for the bastion and one for the remote host), can use services on both the networks. This has some disadvantages, because the bastion may have to support many users. It is important to enforce good password control here, because if a hacker manages to break into a user ID, he or she can then impersonate the user and get into the private network. Besides this security point, supporting a great number of users will require a big machine. To avoid having users logged in to this machine and to reduce load on the machine, application proxies and SOCKS are now being used Dual-homed gateway In this case, you can protect the dual-homed gateway from external attacks with filtering. For example, if you forbid external access to the telnet daemon, Chapter 1. Introduction to firewalls 9