Watchguard Firewall overview and implemetation

126
1 Watchguard Firewall technology overview and implementation By : Kaveh Khosravi Instructor : Prof Ray hunt

description

This document explains firewall technologies and intrusion detection techniques by using the combination of watchguard firewall and snort , the widely known intrusion detection system ,.

Transcript of Watchguard Firewall overview and implemetation

Page 1: Watchguard  Firewall overview and implemetation

1

Watchguard Firewall technology

overview and implementation

By : Kaveh Khosravi

Instructor : Prof Ray hunt

Page 2: Watchguard  Firewall overview and implemetation

2

Table of Contents Page

1.0 Introduction ........................................................................................................................3

1.1 Firewall technologies .............................................................................................4

1.2 Intrusion Detection and Prevention systems .......................................................9

1.3 Next generation firewalls ....................................................................................11

1.4 Unified Threat Management (UTM) .................................................................13

2.0 Intrusion Analysis and Response Lab ..........................................................................14

3.0 Penetration testing and Intrusion Detection of Firewall policy Implementation .....96

References ......................................................................................................................126

Page 3: Watchguard  Firewall overview and implemetation

3

1.0 Introduction

The Enterprise security course objectives consists of discussing firewall technologies

and security countermeasure techniques against known and unknown threats by comparing

past packet filtering firewalls and current generation firewalls which perform basic to deep

inspection of network packets. Virtual private network (VPN) technologies is also part of the

lab exercises. VPNs offer secure connectivity for remote entities needing access to resources

inside the organizations and enterprises. Remote access and site to site VPN are the two

common type of secure access options nowadays. Snort, a well-known Intrusion detection

and prevention system, would be placed in any critical network segment to look for packet

contents and possible attack inside them as last part of the lab approaches.

Page 4: Watchguard  Firewall overview and implemetation

4

1.1 Firewall Technologies

In computer networks, a firewall is a kind of software or hardware that performs certain

limitation on network packets coming through its network interface cards (NIC). The

firewall simply nowadays can perform various roles such as: routing like router, switching

like a network switch. The NICs simply put each network broadcast domain into unique zone

and the zone could be assigned with different packet filtering rules as it needed. For example

the simple firewall with two NIC segments inside hosts by connecting their end workstations

to its Private ZONE separate from other segments. On the other hand, the described firewall

connects to an untrusted network such as Internet, so the NIC connecting the Internet could

be placed in Public ZONE. All incoming connection requests coming to the firewall get

blocked unless the hosts inside the Private ZONE initiate the connection request to Internet

as it can be seen in figure 1.1.

Figure 1.1: Private and public interfaces in common firewalls. Courtesy Cisco systems [1]

Page 5: Watchguard  Firewall overview and implemetation

5

1.1.1 First generation: packet filters [2]

The first paper published on firewall technology was in 1988, when engineers from Digital

Equipment Corporation (DEC) developed filter systems known as packet filter firewalls.

This fairly basic system was the first generation of what is now a highly involved and

technical internet security feature. At AT&T Bell Labs, Bill Cheswick and Steve

Bellovin were continuing their research in packet filtering and developed a working model

for their own company based on their original first generation architecture.

Packet filters act by inspecting the "packets" which are transferred between computers on

the Internet. If a packet matches the packet filter's set of filtering rules, the packet filter will

drop (silently discard) the packet or reject it (discard it, and send "error responses" to the

source).This type of packet filtering pays no attention to whether a packet is part of an

existing stream of traffic (i.e. it stores no information on connection "state"). Instead, it

filters each packet based only on information contained in the packet itself (most commonly

using a combination of the packet's source and destination address, its protocol, and,

for TCP and UDP traffic, the port number).

TCP and UDP protocols constitute most communication over the Internet, and because TCP

and UDP traffic by convention uses well known ports for particular types of traffic, a

"stateless" packet filter can distinguish between, and thus control, those types of traffic (such

as web browsing, remote printing, email transmission, file transfer), unless the machines on

each side of the packet filter are both using the same non-standard ports.

Packet filtering firewalls work mainly on the first three layers of the OSI reference model,

which means most of the work is done between the network and physical layers, with a little

bit of peeking into the transport layer to figure out source and destination port

numbers. When a packet originates from the sender and filters through a firewall, the device

checks for matches to any of the packet filtering rules that are configured in the firewall and

drops or rejects the packet accordingly. When the packet passes through the firewall, it

filters the packet on a protocol/port number basis (GSS). For example, if a rule in the firewall

Page 6: Watchguard  Firewall overview and implemetation

6

exists to block telnet access, then the firewall will block the TCP protocol for port number

23.

Figure 1.2: Private and public interfaces in common firewalls. [2]

1.1.2 Second generation: "stateful" filters

Second-generation firewalls perform the work of their first-generation predecessors

but operate up to layer 4 (transport layer) of the OSI model. This is achieved by retaining

packets until enough information is available to make a judgment about its state. Known

as stateful packet inspection, it records all connections passing through it and determines

whether a packet is the start of a new connection, a part of an existing connection, or not

part of any connection. Though static rules are still used, these rules can now

contain connection state as one of their test criteria. Certain denial-of-service

attacks bombard the firewall with thousands of fake connection packets in an attempt to

overwhelm it by filling its connection state memory.

Page 7: Watchguard  Firewall overview and implemetation

7

Figure 1.3: Stateful Firewall keeps track of initiated connections. [3]

Stateful packet filtering requires that the firewall look at extra parts contained within the

TCP/IP protocol Headers [3] shown in (figure 1.3). This additional information will indicate

the state of the communication session as the device sending the message believes it to be.

Typically this includes:

• Source and Destination TCP port number

• IP Status flags

• Sequence Number

• Acknowledgement Number

At the same time, the security appliance also creates an internal record that tracks its

understanding of the session state. Together the state information as received, and the state

information as previously recorded, can be used to analyze the reasonableness of each

packet.

Page 8: Watchguard  Firewall overview and implemetation

8

1.1.3 Third generation: application layer

The key benefit of application layer filtering is that it can "understand" certain [1]

applications and protocols (such as File Transfer Protocol (FTP), Domain Name

System (DNS), or (HTTP)). This is useful as it is able to detect if an unwanted protocol is

attempting to bypass the firewall on an allowed port, or detect if a protocol is being abused

in any harmful way. As of 2012, the so-called next-generation firewall (NGFW) is nothing

more than the "widen" or "deepen" inspection at application-stack. For example, the

existing deep packet inspection functionality of modern firewalls can be extended to include

1) Intrusion prevention systems (IPS);2) User identity integration (by binding user IDs to IP

or MAC addresses for "reputation"); and/or iii) Web Application Firewall (WAF).

Figure 1.4: Stateful Firewall does not inspect the contents inside the packets.

The difference between stateful packet-filtering firewall and application layer firewall is that

stateful filtering only keep track of connections only and the contents inside the content such

as Java scripts could not be inspected. On the other hand application layer packet filtering

goes deep inside the packets that traverse the firewall and looks for pattern matches for

Page 9: Watchguard  Firewall overview and implemetation

9

specific contents such viruses, malwares, malicious codes. The inspection process starts by

terminating the client’s

Connection then the contents get inspected and the clients connection regenerated by the

application firewall to the destination host.

Figure 1.5: Application Firewall inspect the contents inside the packets.

1.2 Intrusion Detection and Prevention systems

An intrusion detection system (IDS) [5] monitors network traffic and monitors for

suspicious activity and alerts the system or network administrator. In certain situations IDS

system would block the communication from the suspicious host or the more specific content

inside the packets. IDS/IPS systems often have a few functionalities overlapped with

application layer firewalls. IDS/IPS systems are designed to process heavy loads and process

them in an acceptable delay, so the current network operation would not interrupted.one the

differences is scalability in which the IDS/IPS systems can work in distributed and cluster

mode to provide load balancing and load sharing.

Page 10: Watchguard  Firewall overview and implemetation

10

Figure 1.6: Typical Intrusion detection system in computer networks

IDS/IPS systems consists of the following types:

NIDS

Network Intrusion Detection Systems are placed at a strategic point or points within the

network to monitor traffic to and from all devices on the network. Ideally you would scan

all inbound and outbound traffic, however doing so might create a bottleneck that would

impair the overall speed of the network.

HIDS

Host Intrusion Detection Systems are run on individual hosts or devices on the network. A

HIDS monitors the inbound and outbound packets from the device only and will alert the

user or administrator of suspicious activity is detected

Signature Based

A signature based IDS will monitor packets on the network and compare them against a

database of signatures or attributes from known malicious threats. This is similar to the way

Page 11: Watchguard  Firewall overview and implemetation

11

most antivirus software detects malware. The issue is that there will be a lag between a new

threat being discovered in the wild and the signature for detecting that threat being applied

to your IDS. During that lag time your IDS would be unable to detect the new threat.

Anomaly Based

An IDS which is anomaly based will monitor network traffic and compare it against an

established baseline. The baseline will identify what is “normal” for that network- what

sort of bandwidth is generally used, what protocols are used, what ports and devices

generally connect to each other- and alert the administrator or user when traffic is detected

which is anomalous, or significantly different, than the baseline.

1.2 Next generation firewalls

Next generation firewalls combine all the previous packet filtering and application layer

filtering firewalls to provide a comprehensive protection against today’s sophisticated

attacks. The common features of a next generation firewall for a Watchguard firewall [5]

Key Next-Generation Firewall Characteristics:

High-performance security inspection that blocks attacks and unwanted traffic

without hindering mission-critical Internet usage

A platform for network traffic inspection and network security policy enforcement, with

the following minimum features:

- Standard Firewall Capabilities:

Packet Filtering

Network Address Translation (NAT)

Stateful Protocol Inspection

Virtual Private Networking (VPN)

Integrated Network Intrusion Prevention (IPS)

Page 12: Watchguard  Firewall overview and implemetation

12

Application Awareness and Control

Additional Intelligence: Directory integration to tie security policies to users and

groups; cloud-based reputation services to stop traffic from dangerous sources

Real-time and historical visibility into user, network, and security activity.

Figure 1.7: Next Generation Firewalls capabilities [6]

Page 13: Watchguard  Firewall overview and implemetation

13

1.4 Unified Threat Management (UTM)

Unified threat management (UTM) [7] is an emerging trend in the network security market.

UTM appliances have changed from traditional firewall and Virtual Private Network (VPN)

products into a solution with many additional capabilities. UTM features that Watchguard

security solutions provides listed below.

Figure 1.8: Watchguard® UTM features

Spam blocking: spamBlocker provides real-time spam detection for protection from

outbreaks. It's the best solution in the industry at distinguishing legitimate

communication from spam in real time, blocking nearly 100% of unwanted emails.

This easy-to-deploy subscription for the XTM platform incorporates industry-leading

Recurrent Pattern Detection (RPD™) technology to detect spam outbreaks as they

emerge for immediate and continuous protection.

Gateway Antivirus: (GatewayAV) is a fully integrated security subscription for

WatchGuard XTM appliances. It works in tandem with the application layer content

inspection of the XTM to provide real-time protection against known viruses, trojans,

Page 14: Watchguard  Firewall overview and implemetation

14

worms, spyware, and rogueware. Gateway AV scans traffic on all major protocols,

using- continually updated signatures to detect and block all types of malware. And

because Gateway AV is integrated with WatchGuard XTM security appliances,

Intrusion prevention: Intrusion Prevention Service (IPS) is a fully integrated security

subscription for all WatchGuard XTM appliances. It works in tandem with the

application layer content inspection of the XTM to provide real-time protection

against network threats, including spyware, SQL injections, cross-site scripting, and

buffer overflows. IPS scans traffic on all major protocols, using continually updated

signatures to detect and block all types of threats.

Webblocker: WebBlocker is a fully integrated security subscription for WatchGuard

XTM and Firebox appliances. It allows IT administrators to manage web access and

content for stronger security and control of web surfing. WebBlocker blocks

malicious sites to keep network protected from risky web content. It helps conserve

network bandwidth, prevent legal liability from inappropriate content, and increase

employee productivity while it guards the network against malicious attacks from

rogue websites.

2.0 Intrusion Analysis and Response Lab

The lab exercises would be discussed in this chapter. The lab diagram in figure 2.1

shows the watchguard firewall in the middle where two of its network interfaces used for

connecting (Trusted Network) in the left to (External Network) on the right to provide wide

range of network services such as Network address translation (NAT), Web Access to

Trusted Network users, Remote Access and Site to Site VPN and authentication. The first

physical computer used for virtualizing a inside host to serve as management system and

Page 15: Watchguard  Firewall overview and implemetation

15

inside user emulation (ex: web browsing, Internet access) by using VMware Workstation

software [8] as a virtualization software.

Figure 2.1: Firewall lab diagram

The second physical system used for virtualizing an External host that acts as HTTP ,HTTPS

,FTP and Remote VPN client.

Page 16: Watchguard  Firewall overview and implemetation

16

Figure 2.2: VMware Workstation window showing Trusted Host

IP addresses are preconfigured in all of the systems involved in the lab. Table 2.1 shows IP

addresses and type of services run on host computers.

Table 2.1 IP addresses and Network Services

2.1 Web Management Interface

Page 17: Watchguard  Firewall overview and implemetation

17

The next step is to access the firewalls web management page and configure the

policies. It is recommended by most network security solution providers to keep management

traffic isolated from less trusted network since the compromise of firewall management

means the loss of security. This lab allows authorized people to access the web management

from the Trusted interface only. By browsing (https://204.137.98.158:8080) Graphical User

Interface comes up. web browser generates a security warning about the untrusted security

certificate. The problem is that an untrusted certificate is a certificate that a certification

authority has revoked, or a certificate that for other reasons has been placed in the Untrusted

Certificates folder on your computer. If a certification authority discovers that the

identification information someone provided to get a certificate is false, that certificate will

be revoked. When a certificate is revoked, it is moved to the Untrusted Certificates folder

and can no longer be used.

The short term solution for this problem is to simply add the untrusted security certificate

to the trusted certificate store, so all subsequent connection attempts will successfully

establish. On the other hand the long term solution is to subscribe with a well-known

Certification authorities such as Verisign, RSA and Symante to have trusted certificate while

connecting securely to remote administration web interface.

Page 18: Watchguard  Firewall overview and implemetation

18

Figure 2.3: Security Certificate warning message

The image below shows security certificate Symantec corporation [9] issues based on services

needed and the scale of business.

Page 19: Watchguard  Firewall overview and implemetation

19

Once the security certificate confirmed as a trusted interface, the web GUI appears. The

username “admin” and the password “readwrite” are defaults for all Watchguard firewall

appliances.

Figure 2.4: Watchguard web interface

The web interface consists of the following sections:

DASHBOARD: which provides firewall logs, real time traffic analysis, connected users

and their established connections. Several examples of Dashboard shown in figure 2.5 and

figure 2.6

SYSTEM STATUS: includes information about the system specific functions including:

ARP Table, Authentication List, Blocked Sites, Checksum, Components List, DHCP

LeasesDiagnostics, Dynamic DNS, Hotspot Clients, Live Security, Processes, Routes,

Server- Connection, Traffic Management, and VPN Statistics.

Page 20: Watchguard  Firewall overview and implemetation

20

Figure 2.4: Watchguard Front Panel

Figure 2.5: Watchguard Front Panel available in Watchguard OS v 11.8.3

Figure 2.6: Firewatch feature available in Watchguard OS v 11.8.3

Page 21: Watchguard  Firewall overview and implemetation

21

Figure 2.7: Live Traffic monitor

2.2 Watchguard system manager:

The main management tool to configure and monitor Watchguard XTM security products

is the Watchguard System Manager shown in figure 2.8. System manager has several main

sub management parts including:

Firebox system manager: provides the same functions as Dashboard in web

management.

Host watch: Displays established network connections between clients and

watchguard firewall

Policy manager: used for configuring policies inside Watchguard security appliance

with additional capabilities such as policy reordering and renaming.

Page 22: Watchguard  Firewall overview and implemetation

22

Figure 2.8: System Manager

Figure 2.9: Policy Manager

Page 23: Watchguard  Firewall overview and implemetation

23

Figure 2.10: Firebox system Manager

Page 24: Watchguard  Firewall overview and implemetation

24

Figure 2.11: Hostwatch window

2.3 Setting up an FTP proxy service

Unlike classic FTP packet filtering rules, FTP proxy service allows to have more control over

the kind of FTP protocol commands, contents such executables, images, scripts. Scanning

for viruses and malicious traffic is also part of FTP proxy service. As it can be seen in figure

2.12 and 2.13, classic FTP packet filtering rule windows does not have much control

mechanism for deep FTP protocol inspection.

Page 25: Watchguard  Firewall overview and implemetation

25

Figure 2.12: Initial FTP packet filtering window

Figure 2.13: Detailed FTP packet filtering window without deep inspection features

Page 26: Watchguard  Firewall overview and implemetation

26

FTP proxy service allows to perform the following features including:

Limits:

Set the maximum user name length

Set the maximum password length

Set the maximum file name length

Set the maximum command line length

Set the maximum number of failed logins per connection

FTP commands:

(?) : to request help or information about the FTP commands

(ascii) : to set the mode of file transfer to ASCII (default and transmits seven bits per

character)

(binary) : to set the mode of file transfer to binary (the binary mode transmits all eight bits)

(bye) : to exit the FTP environment (same as quit)

(cd) : to change directory on the remote machine

(close) : to terminate a connection with another computer

(delete) : to delete (remove) a file in the current remote directory (same as rm in UNIX)

(get) : to copy one file from the remote machine to the local machine

Download: detection of file patterns is available by regular expression language inspection.

Figure 2.14: Watchguard FTP proxy

Page 27: Watchguard  Firewall overview and implemetation

27

The FTP proxy service experiment continues by defining the Proxy Action to block (windows

media file type (*.wma) shown in figure 2.15), thus the FTP traffic, travelling between Inside

host and External host, inspected and blocks the (*.wma) by the rule defined. From the

Internal system, Windows FTP client application’s attempt to access External FTP server

(204.137.98.190), then the anonymous access would granted to the server, however the WMA

file could not get downloaded.

Figure 2.14: Watchguard FTP proxy pattern matching

Figure 2.15 illustrate the FTP application layer filtering impact on the file transfers, the files

(center.exe) and (blues.wma) blocked byWatchguard firewall. (test.txt) transferred

successfully because Watchguard has not been configured to block (*.txt) files.one of the

problems encountered during lab was that the order of policies caused FTP proxy filtering

to get bypassed by previously created classic FTP packet filtering. To fix such policy

ordering, Watchguard system manager must be used since, it is the only configuration tool

that allows modifying policy orders.

Page 28: Watchguard  Firewall overview and implemetation

28

Figure 2.15: Windows XP FTP client attempts to download files from FTP server

2.3 Setting up an HTTP Packet Filter and Proxy Service

HTTP packet filters offer basic filtering over HTTP protocol. Unlike HTTP proxy service,

HTTP packet filters do not inspect content to look for viruses, illegal HTTP commands and

Javascript.to setup HTTP packet filter with proxy service, it is possible to use either System

manger or Web management GUI. The web management approach would be shown here.

Page 29: Watchguard  Firewall overview and implemetation

29

Figure 2.16: Setting up HTTP packet filtering with proxy service

Figure 2.17: Setting up HTTP packet filtering with proxy service

Page 30: Watchguard  Firewall overview and implemetation

30

Figure 2.16 and 2.17 shows initial steps to configure HTTP packet filtering with proxy

service. Since HTTP inspection should be performed on packet, the Proxy option must be

checked. Later it can be modified based on security policy. For example (Proxy Actions) tab

under FIREWALL tab in web management allows to change default HTTP-Client

inspection settings that can be seen in figure 2.18.

2.18: HTTP Client Proxy Action settings

The lab requires to block java scripts from getting executed by trusted clients’ web

browsers. HTTP response tab allows to search for specific HTTP response content and

perform certain action, such as ALLOW, DENY, BLOCK, AV-SCAN, and DROP.as it can

be seen in figure 2.19, Deny action would happen as result of Java script detection.

Page 31: Watchguard  Firewall overview and implemetation

31

2.19: HTTP Client Proxy Deny Action to block Java scripts

The external web server address (http://204.137.98.190/external) can be accessed by trusted

admin machine (204.137.98.145) that can be seen in figure 2.20.the calendar Java script

based application cannot be lunched since the HTTP proxy is blocking Java script. To

observe this behavior , Wireshark should be lunched by the Trusted machine and http filer

should also applied to filter HTTP traffic only.Whireshark display’s blocked Java script

packets in line No 51 and 61 respectively shown in figure 2.21.

Page 32: Watchguard  Firewall overview and implemetation

32

2.20: external web server address (http://204.137.98.190/external)

Page 33: Watchguard  Firewall overview and implemetation

33

2.21 Wireshark capturing HTTP packets

2.4 Setting up an HTTPS Packet Filter

The next stage is to set up a secure web server and access to this can only occur via HPPTS

on port 443 through the firewall. Further, in the following section we will generate an X.509

digital certificate which customarily operates in conjunction with a secure web server.

The steps involved are as follows:

Configure HTTPS on the firewall

Generate an X.509 digital certificate for the web server (204.37.98.190)

Install this new digital certificate and test

Our trusted server is to be the external server (204.137.98.190). Add an HTTPS

filter to the firewall, enabling SSL traffic to operate between the web client

(204.137.98.145) and the secure web server (204.137.98.190). Save configuration

as https.xml.

Why is a packet filter adequate in this case whereas it was not adequate in the

HTTP case previously?

The reason is HTTPS packets are encrypted by Public key/Private key

cryptography, thus the HTTP only packet filtering could not inspect and

block certain type of web traffic. The solution is to use HTTPS packet filters

which allows to terminate client’s HTTPS requests on the firewall, then

firewall decrypts the packets, inspects them and finally send them to the

destination secure web server shown in figure 2.22.

Page 34: Watchguard  Firewall overview and implemetation

34

Figure 2.22 HTTPS inspection via HTTPS packet filter and proxy service

Using your client, request a default web page of the web server using HTTP

(204.137.98.180/external). Even though you have an HPPS packet filter – you are allowed to

access a web page (essentially HTTP) but you are warned that this is an insecure operation.

The firewall expects that all web-based operations will be via HTTPS. In the case of HTTPS

the web server must have a digital certificate installed which can be viewed by the client and

accepted/rejected.

Establishing a digital certificate:

The following figure shows the steps required to create a new certificate and assign it a secure

web server on External machine.

Page 35: Watchguard  Firewall overview and implemetation

35

Figure 2.23: Internet Information Services (IIS)

It is required to ask for a certificate from a certificate authority, in our experiment we use Open

SSL as Trusted Certificate authority to ask for a certificate. The Bit Length depends on security

strength we intend to have on our web server. The bigger the key is, the more secure the

communication is.

Page 36: Watchguard  Firewall overview and implemetation

36

Figure 2.24: Certificate Request Wizard in IIS

Figure 2.25: Filling up information about a requested certificate

Page 37: Watchguard  Firewall overview and implemetation

37

Figure 2.26: finishing the certificate request form

Figure 2.27: End of Certificate request wizard

Page 38: Watchguard  Firewall overview and implemetation

38

Next step is to save the requested certificate in “request folder” under openssl directory in

C drive. The Date and time must be accurate since any unsynchronized clock cause error in

generating private key by openssl library. Later we should delete any old certificate request

in “request folder”.

Figure 2.28: Old certificates sored in openssl folder

Now it is necessary to delete database.txt, serial.txt silverfire.cer and silverfirex509.cer but not

ca.cer as this is the root signing certificate. The reason for doing this is because previous

students might had created certificate requests and obviously enough, we do not want to

struggle in case of anything goes wrong as result of their work. Later we create empty

database and serial file by doing the following:

Create the file database.txt - an empty (zero-byte) text file. This can be done by creating an

empty file manually:

C:\openssl> copy con database.txt [con stands for console] CTL Z

<enter>

Create the serial number file serial.txt. This is a plain ASCII file containing the string "01"

on the first line, followed by a newline.

Page 39: Watchguard  Firewall overview and implemetation

39

C:\openssl> copy con serial.txt [con stands for console] 01 CTL Z

<enter>

The certificate request certreq.txt should already be in the folder: C:\openssl\requests

folder.

Now navigate to:

cd openssl

cd bin

Next we run the following command shown in figure 2.29 last step is to convert signed

certificate from PEM format to X509, so IIS can import the certificate to its cert store.

Figure 2.29: Generating Private Key for IIS Certificate request.

Page 40: Watchguard  Firewall overview and implemetation

40

Figure 2.30: X509 type certificate ready for IIS.

Figure 2.31: X509 type certificate ready for IIS.

Figure 2.31 on the right side shows certificate import wizard, where we import the X509

certificate and examine the details of “issuer” and “subject” and other properties such as

public key, expiry date etc. On the left we have a view of certificate while we browsed a secure

web server’s front page in figure 2.3

Page 41: Watchguard  Firewall overview and implemetation

41

Figure 2.32: Secure page browsing via trusted host

Figure 2.33: Detailed view of the certificate inside Internet Explorer 6

Page 42: Watchguard  Firewall overview and implemetation

42

To make sure we are accessing securely to the web application, IIS must be configured to

enforce 128-bit encryption in figure 2.34.

Figure 2.34: Secure communication window under directory secure communication tab in IIS

Page 43: Watchguard  Firewall overview and implemetation

43

Steps required to enable HTTPS inspection in Watchguard:

Enabling HTTPS proxy requires to create a new policy and selecting a PROXY-ACTION

that should have defined before in Proxy Actions tab shown in figure 2.35

Figure 2.35: Enabling deep inspection of HTTPS content.

The interesting fact is that the Proxy-Action defined by HTTP-Client, since the packet decrypted,

usual HTTP-PROXY can be applied to inspect and scan web content. Last step involves defining

source and destination network in figure 2.36.

Page 44: Watchguard  Firewall overview and implemetation

44

Figure 2.36: Main HTTPS-PROXY policy page

Page 45: Watchguard  Firewall overview and implemetation

45

SSL traffic Interception:

A Wireshark capture is required to intercept communication between Trusted client and

external secure server. Figure 2.35 shows incepted traffic while we accessed secure web

server.

Figure 2.35: Secure communication intercepted between Trusted client and External secure web

server

Page 46: Watchguard  Firewall overview and implemetation

46

The secure communication starts by trusted client sending (client hello) and it offers certain

type of RSA encryption algorithms compatible with Trusted client. Secure web server offers

SSLv3 with (server hello message). Later client confirms cypher spec with server and server

acknowledges client’s confirmation by sending the last ack packet in line (No 462).

Questions:

What port is being used for SSL? TCP-443 Secure Sockets Layer

Is your application data encrypted? [To verify look at frame and compare with

same frame when “require secure channel (SSL) 128 bit option is on”. On the client

machine (204.137.98.145) go to Directory Settings → Edit → require secure channel

SSL]. Does this make any difference?

The initial connection establishment is not secure since 128-bit encryption is not enforced in

IIS configuration to secure application data. It can be observed in first Wireshark capture

in figure 2.36

i) What is the certificate used for?

Page 47: Watchguard  Firewall overview and implemetation

47

Figure 2.36: No 450 through 455 are not encrypted

However once we force 128-bit encryption, all of application data establish securely.

Observation can be seen in figure 2.37, lines two through four

Figure 2.37: all application data encrypted as result of 128-bit encryption

When the SSL session commences, how many cipher suites (cryptographic and

hashing algorithms) does the client offer to the server? Note: these are offered as

combined suites. Look in the first Client Hello / Server Hello for this negotiation

[SSL → SSLv3 → Handshake → Handshake Protocol → Cipher Suites.]

20 cipher suites as can be seen in client hello message below:

Page 48: Watchguard  Firewall overview and implemetation

48

How long is the certificate? 128-bit

Which of the ones offered does the server select and what encryption method and

hashing algorithm does the server machine reply with? This is exactly your Internet

banking in operation.

Cipher suite secure server offer: TLS_RSA_WITH_RC4_128_MD5

Page 49: Watchguard  Firewall overview and implemetation

49

2.5 Network address translation (NAT) [9]

NAT is a methodology of modifying network address information in Internet

Protocol (IP) datagram packet headers while, they are traversing network nodes. The idea

is to change the source IP of end client nodes and send their packets with different network

address. The advantage of doing this is to save IP address pools, thus hundreds of source IP

addresses can appear as one IP address. Network address translation was originally used to

map every address of one address space to a corresponding address in another space,

however as the number of Internet users started to grow, Network engineers developed a

new way of translating private IP addresses to public IP addresses. The concept described in

RFC 1918. Figure 2.38 shows IP address translation from two different network to a

different network on router’s serial interface (s0).

Figure 2.38: Network address translation, courtesy Cisco systems

Dynamic NAT: With dynamic NAT, translations do not exist in the NAT table until the

router receives traffic that requires translation. Dynamic translations have a timeout period

after which they are purged from the translation table.

Page 50: Watchguard  Firewall overview and implemetation

50

Static NAT: translations exist in the NAT translation table as soon as static NAT configured

and they remain in the translation table until the static NAT get deleted.

Set up a static NAT for an FTP service:

By defining static NAT for FTP service, it is possible to provide external access to internal

network resources such as FTP.

Figure 2.39: Static NAT translation for FTP service

External clients browse Firewall’s external IP address on their address bar, and the firewall

translate their request with IP address changed and relay back to FTP server while keeping

the source and destination address of the client. FTP server sends back the response to

Firewall and Firewall changes the source IP address of FTP server’s reply to its external IP

address. Finally external client receive a reply from the Firewall.

The step to configure static NAT for FTP is as the following:

Adding FTP server policy shown in figure

Once the FTP server configured, then the FTP connection test is required to ensure that FTP

server is accessible. From the external machine, a FTP connection establishes with external

Page 51: Watchguard  Firewall overview and implemetation

51

IP address of Firewall while traffic being captured by Wireshark. By looking at the

Wireshark’s output shown in figure 2.41

Figure 2.40 FTP policy with static NAT entry

Page 52: Watchguard  Firewall overview and implemetation

52

Figure 2.41 FTP client establishes a connection to FIrewall

Figure 2.41 Wireshark capture of inbound FTP connections

Page 53: Watchguard  Firewall overview and implemetation

53

2.42 FTP Static NAT added to Watchguard Firewall

Results from the Static FTP server publishing:

Static Nat allowed to save public address space, no matter how big or small the

company is. Without static NAT, all external clients needing access to FTP server,

had to get mapped to a unique public IP address.

Page 54: Watchguard  Firewall overview and implemetation

54

2.6 Firewall Monitor (Watchguard Demo)

Watchguard demo is preconfigured and loaded with valuable sample data of network

traffic generated to and from the Firewall. The application has already been installed in

Trusted host.to lunch the application, center.exe must be lunched from

(c:\ProgramFiles\WatchGuardDemo\centre.exe).

2.43 Demo Application main window

From this application, it is possible to start any of the Watchguard reporting tools:

Policy Manager.

Firebox Monitor

LogViewer

HostWatch

Historical Reports

Policy Manager

Page 55: Watchguard  Firewall overview and implemetation

55

2.44 Firebox Monitor

2.45: Log viewer

Page 56: Watchguard  Firewall overview and implemetation

56

2.46: HostWatch

2.47: Policy Manager

Page 57: Watchguard  Firewall overview and implemetation

57

2.48: Historical Reports

2.6 Firewall Monitor (Questions)

Given that the firewall resides on a 10 Mbps network link in this demonstration, is

the network load close to saturation? Explain your answer.

No, by looking at image below, it can be concluded that the 10Mbps link has

not saturated yet and has so much capacity to handle new connections.

Page 58: Watchguard  Firewall overview and implemetation

58

Staying with the same Firebox Monitor window look at the Status Report tab near

bottom of the screen. What is the host address of the trusted eth1 interface?

192.168.149.254

One of the users had problems getting Outlook going. Which machines were

probably involved? (Hint: Under the Edit menu, do a keyphrase search for

dce_rpc).

As it can be seen in figure below, there are two hosts involve:

1: 208.152.24.123

2: 10.1.1.2 on port 135

Page 59: Watchguard  Firewall overview and implemetation

59

How would you recognize a network mapping attempt using this tool? The sample

capture of a HostWatch trace below may assist.

By looking at Hostwatch window, it is possible to see all live incoming and outgoing traffic

to and from the firewall. For example a computer with a hostname of GoldenGate established

a connection ucla.edu server.

Page 60: Watchguard  Firewall overview and implemetation

60

Page 61: Watchguard  Firewall overview and implemetation

61

From the Control Center, start up the HostWatch. Now pause this service. What do the four

Miscellaneous select the sampling interval and list the four most common applications that

are running.

Line colors represent the following:

The four most common applications are:

HTTP, FTP, TELNET, MAIL

From the Control Center, start up the Historical Reports application and open the logdb

database.

Page 62: Watchguard  Firewall overview and implemetation

62

Which host has generated the most outgoing traffic over the last year (byte count by

host) and the most connections (usage by host)? Which port (service) had the most

traffic (usage by service) – and what is this name of the service on this port?

To answer this question, Usage by host statistics should be opened and the query

must be changed to annually and the duration to last year shown below.

Page 63: Watchguard  Firewall overview and implemetation

63

Host-142 is the host generated the most outgoing traffic.

Venice has generated most of the connections.

Page 64: Watchguard  Firewall overview and implemetation

64

The most used service (usage by service)

epmap port: 135/tcp loc-srv #DCE endpoint resolution

epmap port: 135/udp loc-srv #DCE endpoint resolution

1. There is a complaint that the outgoing network connection is extremely slow. It has

been suggested that someone might be busy with a major data transfer – how would

you track down the source of the problem using these tools?

There are multiple ways to look for the reason of slow network connectivity. For example

live security control center allows to monitor processing load on Firewall and network traffic

load as well. Firebox traffic monitor provides ways to plan for network bandwidth upgrades,

since it shows link saturation across different network interfaces.

Page 65: Watchguard  Firewall overview and implemetation

65

Watchguard Historical reports show valuable information about users, hosts and service

during certain times. A few slow network access symptoms might appear in these historical

reports.

2.7 Extending Security Policy to include Roaming Clients - PPTP,

Page 66: Watchguard  Firewall overview and implemetation

66

SSL & IPSec and the RSAv8 Authentication Engine

PPTP VPN implementation

A PPTP tunnel is instantiated by communication to the peer on TCP port 1723. This TCP

connection is then used to initiate and manage a second GRE tunnel to the same peer.

The PPTP GRE packet format is nonstandard, including a field replacing the

typical routing field in the GRE header. However, as in a normal GRE connection, those

modified GRE packets are directly encapsulated into IP packets, and seen as IP protocol

number 47.The GRE tunnel is used to carry encapsulated PPP packets, allowing the

tunneling of any protocols that can be carried within PPP, including IP, NetBEUI and IPX.In

the Microsoft implementation, the tunneled PPP traffic can be authenticated

with PAP, CHAP, MS-CHAP v1/v2 or EAP-TLS. The PPP payload is encrypted

using Microsoft Point-to-Point Encryption (MPPE) when using MS-CHAPv1/v2 or EAP-

TLS. MPPE is described by RFC 3078.

In order to activate PPTP VPN service, VPN tab from the Watchguard web management

interface should be opened and (Activate mobile VPN with PPTP) in figure 2.49 should be

checked.

Page 67: Watchguard  Firewall overview and implemetation

67

Figure 2.49: PPTP service activation

Later the IP pool should be defined because PPTP clients should lease IP addresses from

Watchguard firewall. (Allow drop from 128-bit to 40-bit encryption) should be checked to

make PPTP VPN downward compatible.

Page 68: Watchguard  Firewall overview and implemetation

68

Figure 2.50: PPTP IP pool available

Figure 2.51: An overview of PPTP setup

Page 69: Watchguard  Firewall overview and implemetation

69

Next step is to configure to configure authentication server where user names and password

are stored for remote PPTP clients.

Figure 2.52: Authentication servers menu in Policy Manager

Local database used for storing usernames and passwords. Other type of authentication

servers are also available for configuration as well.

Page 70: Watchguard  Firewall overview and implemetation

70

Figure 2.53: Firebox Authentication servers’ window

Page 71: Watchguard  Firewall overview and implemetation

71

Figure 2.54: User creation window under Firebox User window

Finally the configuration saved to Firewall for activation.

Figure 2.55: Saving policy to XTM device

Page 72: Watchguard  Firewall overview and implemetation

72

A Firewall policy is required to enable PPTP service on Watchguard firewall in addition to

PPTP service setup.

Figure 2.56: PPTP policy creation to allow PPTP service inbound

The next step is to establish PPTP connection to Watchguard from external host. a PPTP

connection profile should be created in Windows XP Virtual machine.

Page 73: Watchguard  Firewall overview and implemetation

73

Figure 2.57: PPTP connection profile main window

Figure 2.58: Virtual Private Network connection selected as type of VPN

Page 74: Watchguard  Firewall overview and implemetation

74

Figure 2.59: 204.137.98.189 defined as VPN gateway

Next the wireshark stated to capture network traffic while the PPTP connection is

established on Untrusted host virtual machine. The Firebox system manager would also

show the established PPTP connections.

Page 75: Watchguard  Firewall overview and implemetation

75

Figure 2.60: Firebox showed connation initiated from 204.137.98.149

Figure 2.61: Wireshark capture before and after PPTP connection establishment

Page 76: Watchguard  Firewall overview and implemetation

76

Figure 2.62: Firebox live traffic monitor shows PPTP user connected

Page 77: Watchguard  Firewall overview and implemetation

77

Figure 2.63: Service watch shows graph view of VPN connections

Figure 2.64: Authentication list shows authenticated users, protocols and IP addresses

Page 78: Watchguard  Firewall overview and implemetation

78

PPTP (Questions) already answered

To answer the following questions open the Firewall System Manager window and use the

first two tabs (Front Panel and Traffic Monitor). What information does the Firewall

System Manager provide about Fred’s connection?

(Already Answered)

Logging in, crypto (pptp), packets sent and received (look in log) and look in Control

Centre -> Remote VPN Tunnel.

What type of encryption is in use?

The logs refer to MPPE but this incorporates RSA’s RC4 symmetric encryption cipher.

Microsoft Point-to-Point Encryption (MPPE) is a protocol for encrypting data across Point-

to-Point Protocol (PPP) and virtual private network (VPN) links. It uses the RSA RC4

encryption algorithm which supports 40-bit and 128-bit session keys, which can be changed

frequently to improve security. The exact frequency that the keys are changed is negotiated,

but may be as frequent as every packet. MPPE alone does not compress or expand data, but

the protocol is often used in conjunction with Microsoft Point-to-Point Compression which

compresses data across PPP or VPN links.

RC4 – 128 bit. PPTP can operate with a range of RSA encryption keys (40-128) but is not as

secure as IPSec which uses AES. However SSL still commonly uses RC4 – e.g. for Internet

Banking.

Having logged in as a PPTP user such as ‘Fred’, open a browser in the admin machine

(204.137.98.145/admin) to track traffic to/from this roaming client. Startup Wireshark and

ping the Admin host from the PPTP client. Examine the resulting network trace.

Page 79: Watchguard  Firewall overview and implemetation

79

What packet type is used to carry the ping requests in each case? Include a brief

explanation

What are the source and destination addresses on these packets? Include a brief

explanation

Outside trace: PPP packets carry the requests as compressed data (204.137.98.190 ->

204.137.98.189 – external firewall interface) using IP/GRE/PPP.

Admin trace: The ICMP packets appear as usual – without any wrapping protocol.

(204.137.98.148 (as assigned to pptp_user) -> 204.137.98.145 (admin host).

On the PPTP client, run ipconfig from the command line. What is the IP address for the

current machine (associated with PPTP)? What is the network mask and why is it this value?

IP: 204.137.98.148 (allocated from pool)

Netmask: 255.255.255.255 – subnet of 1 machine (/32)

Default Gateway: 204.137.98.148 (PPTP Tunnel)

204.137.98.189 (Encapsulating IP Packet)

1.8 Authentication Engine

Most practical and commercial implementations of such a roaming client operation will

utilize an authentication system such as RSAv8 [10] Authentication Engine with RADIUS

using SecurID Tokens. RSA SecurID Authentication Engine (SAE) is a compact set of

Application Programming Interfaces (APIs) that provide the backend authentication

functions of RSA SecurID without requiring significant infrastructure and application

changes.

Page 80: Watchguard  Firewall overview and implemetation

80

This lightweight, easily implemented authentication software solution can be integrated

directly into an organization’s homegrown applications, whether externally or internally

facing.After integrating the APIs, organizations can use them to authenticate SecurID users.

SAE supports strong two-factor authentication for both SecurID hardware and software

tokens.

SAE is the ideal solution for organizations that have functions for user management, security

policy, password management, and reporting built into their applications – but want to

enable users to log in securely to specific applications with a SecurID authenticator. On the

market for more than a decade, RSA SecurID Authentication Engine is a simple,

straightforward, mature solution.

Below are two important feature of RSA hardware authenticator retrieved from RSA web

site:

QUALITY AUTHENTICATORS

Benefit from one of the industry’s highest-quality authenticator-manufacturing processes,

which means fewer token failures in the field.

MULTI-USE TOKENS

Enable users with multiple uses for their authenticators, such as two-factor authentication

along with hard-disk encryption, email signing, and more.

This RSA Authentication Engine VM can be started up but never needs to be logged into. It

has an IP address of 204.137.98.150 and must reside on the trusted side of the firewall as

shown in the following diagram.

Page 81: Watchguard  Firewall overview and implemetation

81

Figure 2.65: RSA Authentication engine lab diagram

The introduction of this lab is to import hardware token XML configuration files to RSA

authentication engine which is done by the lab instructor. The imported token can be seen in figure

2.66

Figure 2.66: RSA security token configuration files imported from RSA accompanied CD

The users should be created in RSA authentication engine in order to have necessary

credentials to access internal network resources. Figure 2.67 and Figure 2.68 show user

creation pages in RSA authentication engine.

Page 82: Watchguard  Firewall overview and implemetation

82

Figure 2.67: user creation page

Once the hardware based token configuration finished, users should be assigned with tokens.

Page 83: Watchguard  Firewall overview and implemetation

83

Figure 2.68: user creation page (second half)

Figure 2.69: user creation page (second half)

Page 84: Watchguard  Firewall overview and implemetation

84

Radius client must be configured in RSA authentication engine in order to establish

connectivity between RSA and Watchguard. Later in this exercise Watchguard would

configured to add Radius server, thus users logon authentication attempts transfer to RSA

authentication engine for verification.

Figure 2.70: Radius Client parameters

The next steps involve configuring Watchguard as radius client and enabling Mobile VPN

with SSL.shown in figure 2.71. The external authentication server should be configured as

SECURID and other authentication protocols must be disabled.

Page 85: Watchguard  Firewall overview and implemetation

85

Figure 2.71: Radius Server configuration page

Page 86: Watchguard  Firewall overview and implemetation

86

Figure 2.72: Mobile VPN with SSL activation

Like previous PPTP server configuration, Mobile VPN service must be accessible from External

Interface of Watchguard Firewall only. 204.137.98.189 used as Primary IP address for clients to

connect to Firewall. Virtual IP address Pool defines a virtual subnet for Mobile VPN clients to

connect to firewall. Advanced tab in figure 2.73 define encryption algorithm strengths and

authentication protocol.

Page 87: Watchguard  Firewall overview and implemetation

87

Figure 2.73: Authentication, Encryption and port number configuration

After Mobile VPN configuration completed, it is time to establish a connection to external IP

address of Watchguard by external client virtual machine.

Page 88: Watchguard  Firewall overview and implemetation

88

Figure 2.74: Secure web page for Mobile SSL VPN

The user testlab already assigned a token in RSA authentication engine logs in with a token generated

by hardware token linked with the user testlab. Once a user authenticates, Watchguard prompts

user to download Mobile VPN SLL package relevant to operating system shown in figure 2.75.then

the package for windows OS should be downloaded and installed. A problem appeared during this

lab was that RSA authentication engine put so much system load on host machine and caused a few

short service timeouts. The reason to see the user testclass authenticating in Mobile SSL VPN is that

several attempts made to a find a solution to fix RSA service timeouts and different username with

different tokens were used.

Page 89: Watchguard  Firewall overview and implemetation

89

Figure 2.75: Watchguard XTM Mobile VPN package download page

Figure 2.7

Page 90: Watchguard  Firewall overview and implemetation

90

Figure 2.76: Watchguard SSL VPN installation security warning page

Figure 2.77: Firebox Mobile SSL VPN application on Windows XP

Figure 2.78: Mobile VPN is about to establish and negotiates configuration with Firewall

Page 91: Watchguard  Firewall overview and implemetation

91

Questions:

We now want to test our SSL VPN from the external machine (204.137.98.190) so we will

access a web server on the admin machine (204.137.98.145/admin). However alter the HTTP

to the firewall before you open the browser from the external machine. Also ensure that you

have Wireshark running on the external machine.

What (security) protocol is carrying the web traffic?

Based on figure 2.79, protocol is SSL

Figure 2.79: wireshark capture while browsing 204.137.98.145/admin web page

Can you confirm that all traffic above the TCP layer is encrypted under SSL?

Yes, all traffic pass through virtual interface created by Mobile VPN, thus they become

encrypted.

Now disconnect the SSL VPN tunnel and access the same web server.

What protocol is now carrying the web traffic? Can you confirm that all traffic above the

TCP layer is not encrypted?

Page 92: Watchguard  Firewall overview and implemetation

92

HTTP is use to carry web traffic. All traffic pass unencrypted and goes through main

physical interface instead of virtual SSL VPN interface.

Figure 2.80: wireshark capture while browsing 204.137.98.145/admin web page

Go to Firebox System Manager > Traffic Monitor log on 204.137.98.145 to check

connection/disconnection and connect the SSL VPN once again.

Once a connection has been established right click on the Mobile VPN SSL client in the

lower tray and select “Status”. Answer the following questions:

What port is being used? 443

What encryption algorithm is being used and what is the length of the encryption key

used? AES-256

What hashing algorithm is being used? SHA-512

Who is the authenticated used and how many bytes have been transferred in each direction?

Testclass, 3020bytes send, 4100 receive

Page 93: Watchguard  Firewall overview and implemetation

93

1.9 VPN Access Manager running IPSec which has been

downloaded and installed on the external client.

The reason to use IPSec VPN over SSL VPN is the amount overhead involved in

Public/Private key generation calculation. IPSec VPN works well for bulk data transfer.

The configuration involve setting up IPSec gateway IP address on firewall’s external

interface , configuring IP pool addresses available to remote clients connecting

Watchguard firewall, configuring authentication and encryption algorithm show below

in order.

Figure 2.81: Main IPSec VPN configuration window

Figure 2.81 allows to select type VPN client such Windows or MAC-OS packages.

In Figure 2.82 authentication server settings and passphrase to connect to Database

configured. Gateway IP address defined as publicly accessible (204.137.98.189).

Page 94: Watchguard  Firewall overview and implemetation

94

Figure 2.82: defining authentication server and gateway IP address

Page 95: Watchguard  Firewall overview and implemetation

95

Figure 2.83: IPSec phase 1 settings

Figure 2.84: Allowed network resources and virtual IP Address Pool

Page 96: Watchguard  Firewall overview and implemetation

96

Figure 2.84 shows allowed network hosts or subnets configured to be accessible for remote

IPSec clients. Once a client established an IPSec VPN with watchguard, wireshark capture

show all packets destined internal network resources are encrypted with Encapsulated

Security Protocol (ESP) shown in figure 2.85. User accessed (http://204.137.98.145/admin)

page and all connection passed through a tunnel between (204.137.98.190) and

(204.137.98.189).

Figure 2.85: ESP encryption used to encrypt all communication

3.0 Penetration testing and Intrusion Detection of Firewall policy

Implementation

Penetration testing and Intrusion detection lab starts by evaluating network port scanning

utility Zenmap which provide graphical user interface to Nmap network scanner. Zenmap

could scan network hosts in large number .giving detail of what network ports and services

are running in each scanned host, mapping hosts into a graphical view with their connection

to different hosts. Once port scanning is done, Nessus runs to detect vulnerabilities. Snort

intrusion detection and prevention system would initiate and run in the last part of this lab

Page 97: Watchguard  Firewall overview and implemetation

97

to detect any port scanning and malicious code injection into trusted network. Steps used for

network scanning involve the following:

ping sweeps: used to check if hosts are live or not; commonly done by using ICMP

pings.

Traceroute: used to provide a basic map of the target network architecture

OS identification: used to predict which services might be running on a system and

hence the port scans can be modified accordingly

port scanning: used to provide a list of open ports and thus potential running

applications

application enumeration: uses banner grabbing to identify the services running on a

port

3.1 Lab setup

Previous virtual machines would be used to run the lab objectives. External machine runs

Zenmap and Nessus to scan and detect vulnerabilities in Trusted machine. Firewall

configuration would be modified in order to pass scanning traffic since Watchguard

firewall blocks port scanning packets by default. Figure 3.1 shows diagram for lab.

Figure 3.1: Lab setup diagram

Page 98: Watchguard  Firewall overview and implemetation

98

The instruction requires to add more services in firewall to allow port scanner gather more

information about Trusted network and more specifically Admin Host virtual machine.

Changes made in firewall shown below:

Figure 3.2: More service added to firewall

However, the better approach to these changes is to make inbound traffic filter from

External to Trusted network and allow all (ANY) protocols .Intrusion detection policy

should also be disabled in order to not block scanning attempts. Default packet filtering

policy needs a few changes to disable malformed packet detection.

Page 99: Watchguard  Firewall overview and implemetation

99

Figure 3.3: Alternative changes to firewall

Page 100: Watchguard  Firewall overview and implemetation

100

Figure 3.4: Intrusion Detection should also be disabled

Page 101: Watchguard  Firewall overview and implemetation

101

Figure 3.5: Any-packet-passes policy rule definition

Page 102: Watchguard  Firewall overview and implemetation

102

3.2 Zenmap scanning

Zenmap graphical window has several input boxes to specify target hostname or IP address,

type of scanning (Quick, Intensive) shown in figure 3.6.

Figure 3.6: Zenmap GUI for Nmap scanner

Nmap scan takes several minutes to finish depending on number hosts scanned and network link

speed. Once scan finished, results get printed on screen. Namap quick scan gives fast result compared

to intensive scan shown in figure 3.7.

Page 103: Watchguard  Firewall overview and implemetation

103

Figure 3.7: Nmap Quick scan results

Questions

Provide a brief summary of the information you have obtained in the box below.

Output of Nmap shows port numbers and services running on them. Filtered ports have

also appeared in scan result window. Trusted host (204.137.98.145) has ports (21, 25,

80,135,139,443,445 and 1028) open. Ports (111, 513, 514, 2049, 6000, and 6001) are filtered

based results obtained. Different view of results can be seen in figure 3.8.

Page 104: Watchguard  Firewall overview and implemetation

104

Figure 3.8: Ports/Host tab in Zenmap GUI

Next scan attempt is intensive scan which scan all 65536 network ports, obviously enough

scan takes around 10 minutes to finish. During scan firewall blocked many of scan attempts

since the IPS policy had not been disabled. Figure 3.9 shows final intensive scan details.

Page 105: Watchguard  Firewall overview and implemetation

105

Figure 3.9: Ports/Host tab in Zenmap GUI

Page 106: Watchguard  Firewall overview and implemetation

106

Explain in the box below what the Intense Scan shows you that the quick scan did not

Intensive scan gives more details about target hosts by scanning all network ports and

performing more accurate Operating system detection. For example intensive scan

managed to detect Windows XP show in figure 3.10.

Figure 3.10: Windows XP detection by intensive scan

Page 107: Watchguard  Firewall overview and implemetation

107

Figure 3.11: Intensive scan’sHosts/IP tab view in Zenmap GUI

Topology view in Zenmap shows graphical node view of hosts involved in scanning. Process.

Shown in figure 3.12. Target host represented by red and scanner by black circle. Firewall

also represented by black.

Page 108: Watchguard  Firewall overview and implemetation

108

Figure 3.12: Topology view in Zenmap after intensive scanning

Wireshark will show the packets originating from Nmap scans (quick and intensive). To

select a filter right click on a source address in a trace and add it to the filter. Alternatively

select “Apply a filter”. We need to obtain a filter of the form source == a.b.c.d or ip.src ==

a.b.c.d or ip.dst == a.b.c.d briefly detail your Wireshark results in the box below comparing

the results obtained between the two scans. Referring to the Wireshark traces, give three

examples of protocols and processes being carried out by the intensive scan that were not

carried out by the Quick Scan.

By comparing previous results between quick scan and intensive scan, (quick scan) scans

limited number of ports and protocols and OS detection is not as accurate as intensive scan.

Below in figure 3.13 intensive scan capture shows destination port 52891 scanned.

Page 109: Watchguard  Firewall overview and implemetation

109

Figure 3.13: Wireshark capture of intensive scan

A few not widely used protocols like the ones shown in figure 3.14 appeared in wireshark

capture as a result of Nmap intensive scan. Protocols are (simplifymedia , nimreg, mdqs)

Figure 3.14: Wireshark capture of intensive scan

Page 110: Watchguard  Firewall overview and implemetation

110

HTTP and HTTPS protocols have also been scanned by intensive scan, though quick scan

has not. Total packets generated by intensive scan is 3739 compared to quick scan generated

only 365.

3.3 Nessus scanner

Nessus provides betters understanding of vulnerabilities of service running on network

ports. Nessus has many versions, from free of charge to enterprise class subscription based

scanning tools. Each version is accompanied by database of vulnerabilities for wide range of

networking devices. No matter the device is an android enabled phone or Windows 81.first

step to start nessus lab is to run Nessus service on external machine. Service configuration

window can be seen in figure 3.15. After starting the Nessus service, it is need to access Nessus

web management from web interface on External virtual machine. The username and

password for Nessus management is (Pen-Test / silverfire).

Page 111: Watchguard  Firewall overview and implemetation

111

Next step is to perform vulnerability scanning on Trusted machine to find security holes. In

order to start scan , ADD SCAN button must be used and IP address of Trusted machine

must be entered in scan targets text box shown below in figure 3.16

Figure 3.15: Nessus Service configuration window

Page 112: Watchguard  Firewall overview and implemetation

112

Figure 3.16: Nessus Add Scan window

Figure 3.17: Nessus Scan report window

Page 113: Watchguard  Firewall overview and implemetation

113

Questions:

In the box below provide a summary of the port scan including the number of

vulnerabilities ranked by high, medium and low?

After scan finished, results scan be analyzed from the report Nessus generated. An

example report can be seen in figure 3.17. Figure has several columns named port,

protocol, SVC name and total which show port number and services running on these

ports. The following columns show severity level of vulnerabilities found. Vulnerability

severity level range is from Low to High according to risk level.

Which two ports are most vulnerable and why?

HTTPS service on port 443 and Microsoft CIFS service on port 445

HTTPS has five low risk and two medium risk level and CIFS service has five low and

one medium.

Using Wireshark on each machine (or using the Zenmap Output log), determine

approximately how many packets were received/sent on the (i) external interface and

(ii) trusted interface?

Page 114: Watchguard  Firewall overview and implemetation

114

To obtain more details about a particular port and service running on it click on the

relevant row and the details of the vulnerabilities will be displayed as shown below.

For example the scan of your victim should reveal some bad things about port 445

and in particular Plugin ID 26920 – Microsoft Window SMB Null Session

authentication. Why is this a risk?

By looking at vulnerability description on each row it is possible to see the details of

security issue about scanned protocol by Nessus.

For example Microsoft Windows NULL session authentication feature can be

compromised by security issue described in figures 3.17 and 3.18

Page 115: Watchguard  Firewall overview and implemetation

115

Figure 3.18: CIFS Protocol vulnerabilities description

Figure 3.19: Microsoft security bulletin about SMB NULL authentication

Page 116: Watchguard  Firewall overview and implemetation

116

Why are there significant vulnerabilities associated with ports upon which SMB/CIFS

operate?

SMB protocol is a file sharing stack for many Operating systems and many security

incidents had happened in past years. It should be used over the untrusted network

such Internet and it must heavily monitored in environment where it is needed to be

used such Microsoft Active Directory environments.

3.4 Snort Intrusion detection system.

Snort® is an open source network intrusion prevention and detection system (IDS/IPS)

developed by Sourcefire. Combining the benefits of signature, protocol, and anomaly-based

inspection, Snort is the most widely deployed IDS/IPS technology worldwide. With millions

of downloads and nearly 400,000 registered users, Snort has become the de facto standard

for IPS. Few of approaches to detect network attacks are:

Misuse detectors look for sets of events that match a predefined pattern of a known

attack. These patterns are also called signatures and so misuse detectors are also

called signature-based detectors. Misuse detectors generate a low rate of false-

positives. However, they need to be constantly upgraded with the signatures of the

attacks that need to be detected.

Anomaly detectors operate on the assumption that attacks are significantly different

from legitimate activity and by detecting these differences the attacks can be

identified. They construct profiles representing legitimate activity of users, hosts and

network devices over a period of time. Currently threshold detection and statistical

measures are widely used in the anomaly detection. Other measures like neural

Page 117: Watchguard  Firewall overview and implemetation

117

networks, genetic algorithms etc. are less frequently used. However, anomaly

detectors produce a large number for false positives and also require a large number

of legitimate activities to be trained to recognize valid actions.

The lab consists of putting snort as Intrusion detection software in Admin machine

(04.137.98.145) and start to scanning the admin machine from external machine , thus it is

possible to observer how snort detects attacks in Internet network. In order to run snort on

admin machine the following in figure 3.20 must be done.

Figure 3.20 Executing snort to start sniffing network traffic

To test snort functionality, external machine configured to run FileZilla , a FTP client

application, to run concurrently with Zenmap. Figure 3.21 shows Zenmap and FileZilla are

both configured to connect as FTP client and scan admin machine.

Page 118: Watchguard  Firewall overview and implemetation

118

Figure 3.21: FTP client and Zenmap scanner are about to run

Next both of them started to run smoothly as shown in figure 3.22

Figure 3.22 Zemap scanner and FTP client access in action

Page 119: Watchguard  Firewall overview and implemetation

119

Questions

Next navigate to the log folder on the admin machine (204.137.98.145), i.e.

C:\Snort\log but SNORT will have to be terminated (CTL C) before viewing alertlog.

There will be folders/files named:

alertlog

portscan

merged

tcpdump.log.xxxxxxx

Alert log view logged network attacks like ICMP unreachables. It is classified as

potentially bad traffic.

Page 120: Watchguard  Firewall overview and implemetation

120

Open the Portscan file using Notepad and examine the results resulting from

SNORT’s detection of the Zenmap scan and operation of FileZilla. List the open ports

through which this scan has come and which have been detected by SNORT noting

the source and destination addresses

Time: 05/18-19:04:55.769872

event_ref: 82

204.137.98.190 -> 204.137.98.145 (portscan) Open Port

Open Port: 21

Time: 05/18-19:04:55.769873

event_ref: 82

204.137.98.190 -> 204.137.98.145 (portscan) Open Port

Open Port: 443

Time: 05/18-19:04:55.769874

event_ref: 82

204.137.98.190 -> 204.137.98.145 (portscan) Open Port

Open Port: 25

Time: 05/18-19:04:55.769875

event_ref: 82

204.137.98.190 -> 204.137.98.145 (portscan) Open Port

Open Port: 135

Time: 05/18-19:04:55.769876

event_ref: 82

204.137.98.190 -> 204.137.98.145 (portscan) Open Port

Open Port: 139

Page 121: Watchguard  Firewall overview and implemetation

121

Time: 05/18-19:04:55.775332

event_ref: 82

204.137.98.190 -> 204.137.98.145 (portscan) Open Port

Open Port: 80

Time: 05/18-19:04:55.781002

event_ref: 82

204.137.98.190 -> 204.137.98.145 (portscan) Open Port

Open Port: 445

Draw a diagram showing the machine upon which Zenmap and Nessus runs, the

firewall and the machine upon which SNORT runs. Include all IP addresses so you

demonstrate a clear and logical picture of the penetration testing and intrusion

detection activities.

Page 122: Watchguard  Firewall overview and implemetation

122

Next open up alertlog using Notepad.

Observe how SNORT has reported on your ping as well as the ping resulting from

running Zenmap. Use Wireshark and examine the protocol details of the two ping

Methods. From the alertlog file how does SNORT identify that a particular ping

emanates from a tool like Zenmap in comparison with a normal ping?

[Xref => http://cve.mitre.org/cgi-

bin/cvename.cgi?name=2005-0068][Xref =>

http://cve.mitre.org/cgi-

bin/cvename.cgi?name=2004-0790]

Such ICMP patterns are in snorts database and has been considered

as network attack. Each attack has a unique signature, however

attacks can be altered to create new ones.to avoid such alteration

in attacks, snort implemented anomaly based attack detection

technique. Below is Wireshark’s capture of attack traffic. ICMP

patterns can be seen in the first few lines.

Page 123: Watchguard  Firewall overview and implemetation

123

Alert log file shows scans generated by nmap [**] [1:402:8] ICMP Destination Unreachable Port Unreachable [**]

[Classification: Misc activity] [Priority: 3]

05/18-19:04:15.464381 204.137.98.158 -> 204.137.98.145

ICMP TTL:64 TOS:0xC0 ID:20477 IpLen:20 DgmLen:106

Type:3 Code:3 DESTINATION UNREACHABLE: PORT UNREACHABLE

** ORIGINAL DATAGRAM DUMP:

204.137.98.145:137 -> 204.137.98.158:137

UDP TTL:128 TOS:0x0 ID:18721 IpLen:20 DgmLen:78

Len: 50 Csum: 39006

(50 more bytes of original packet)

** END OF DUMP

[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2005-0068][Xref

=> http://cve.mitre.org/cgi-bin/cvename.cgi?name=2004-0790]

[**] [1:399:6] ICMP Destination Unreachable Host Unreachable [**]

[Classification: Misc activity] [Priority: 3]

05/18-19:04:15.833949 204.137.98.158 -> 204.137.98.145

ICMP TTL:64 TOS:0xC0 ID:20478 IpLen:20 DgmLen:106

Type:3 Code:1 DESTINATION UNREACHABLE: HOST UNREACHABLE

** ORIGINAL DATAGRAM DUMP:

204.137.98.145:137 -> 204.137.98.187:137

UDP TTL:127 TOS:0x0 ID:18562 IpLen:20 DgmLen:78

Len: 50 Csum: 38984

(50 more bytes of original packet)

** END OF DUMP

What has SNORT observed about the use of FTP anonymous access and what port

numbers were used at each end?

SNORT log ftp protocol as ordinary access attempt with priority 0.

Page 124: Watchguard  Firewall overview and implemetation

124

For what reason does SNORT class DCE-RPC as potentially bad traffic?

Metasploit, a hacking platform, has following information about DCE-RPC.

This module allows remote attackers to execute arbitrary code by exploiting the Snort service

via crafted SMB traffic. The vulnerability is due to a boundary error within the DCE/RPC

preprocessor when reassembling SMB Write AndX requests, which may result a stack-based

buffer overflow with a specially crafted packet sent on a network that is monitored by Snort.

Vulnerable versions include Snort 2.6.1, 2.7 Beta 1 and SourceFire IDS 4.1, 4.5 and 4.6. Any

host on the Snort network may be used as the remote host. The remote host does not need to

be running the SMB service for the exploit to be successful.

What other interesting things has SNORT reported on?

1. In alertlog a normal ping has a payload of about 32 bytes

(abcdefg.... ) of padded data and the hex code is 0x0200. For the

ping from Zenmap there is no payload and the identifier is 0x02e9.

SNORT also provided a warning for ICMP pings as well.

“Attempted information leakage”.[2]

2. SNORT has detected FTP anonymous access between ports 4604

(Varies) on 204.137.98.190 and port 21 on 204.137.98.145 [2]

3. File sharing possible without login ID and password [1]

See further details below but examples are classification of

Page 125: Watchguard  Firewall overview and implemetation

125

Open the final file in the SNORT log folder (tcpdump.log.xxxxx) with Wireshark.

Explain what you see from the traces of the packet exchanges and how this relates to

what you observed in the Portscan and alertlog files.

Snort’s engine captures network packets by TCPDUMP program. TCPDUMP acts

similarto wireshark. Snort interprets network packets with its database to detect and

potentially block malicious packets.as it can be seen in figure below all traffic flow

logged in wireshark.

Page 126: Watchguard  Firewall overview and implemetation

126

References

[1] Firewall (computing), 2014. . Wikipedia, the free encyclopedia.

[2] Zone-Based Policy Firewall Design and Application Guide [WWW Document], n.d. Cisco.

URL http://cisco.com/c/en/us/support/docs/security/ios-firewall/98628-zone-design-

guide.html (accessed 5.22.14).

[3] Why SCADA Firewalls Need to be Stateful – Part 3 of 3 | Tofino Industrial Security

Solution [WWW Document], n.d. URL http://www.tofinosecurity.com/blog/why-scada-

firewalls-need-be-stateful-%E2%80%93-part-3-3 (accessed 5.22.14).

[4] Next Generation Network Security Firewall - WatchGuard Technologies [WWW

Document], n.d. URL https://www.watchguard.com/solutions/next-generation-firewall.asp

(accessed 5.23.14).

[5] Introduction to Intrusion Detection Systems (IDS) [WWW Document], n.d. URL

http://netsecurity.about.com/cs/hackertools/a/aa030504.htm (accessed 5.23.14).

[6 Why should you think about a next generation firewall? [WWW Document], n.d. URL

http://www.resolvesolutions.co.uk/article/nextgen-firewalls (accessed 5.23.14).

[7]

[8 VMware Workstation: Run Multiple OS, Linux, Windows 8 & More; | United States

[WWW Document], n.d. URL http://www.vmware.com/products/workstation (accessed

5.23.14).

[9] Network address translation, 2014. . Wikipedia, the free encyclopedia.

[10] RSA SecurID Authentication Engine (SAE) - Authentication API – EMC [WWW

Document], n.d. URL http://www.emc.com/security/rsa-securid/rsa-securid-authentication-

engine.htm#!details (accessed 5.25.14).