Watchguard Firewall technology
overview and implementation
By : Kaveh Khosravi
Instructor : Prof Ray hunt
Table of Contents Page
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
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.
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.1.1 First generation: packet filters 
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
exists to block telnet access, then the firewall will block the TCP protocol for port number
Figure 1.2: Private and public interfaces in common firewalls. 
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.
Figure 1.3: Stateful Firewall keeps track of initiated connections. 
Stateful packet filtering requires that the firewall look at extra parts contained within the
TCP/IP protocol Headers  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
1.1.3 Third generation: application layer
The key benefit of application layer filtering is that it can "understand" certain 
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
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)  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.
Figure 1.6: Typical Intrusion detection system in computer networks
IDS/IPS systems consists of the following types:
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.
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
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
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.
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 
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:
Network Address Translation (NAT)
Stateful Protocol Inspection
Virtual Private Networking (VPN)
Integrated Network Intrusion Prevention (IPS)
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 
1.4 Unified Threat Management (UTM)
Unified threat management (UTM)  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,
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
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
inside user emulation (ex: web browsing, Internet access) by using VMware Workstation
software  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.
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
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://22.214.171.124: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.
Figure 2.3: Security Certificate warning message
The image below shows security certificate Symantec corporation  issues based on services
needed and the scale of business.
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
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
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.
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
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
Host watch: Displays established network connections between clients and
Policy manager: used for configuring policies inside Watchguard security appliance
with additional capabilities such as policy reordering and renaming.
Figure 2.8: System Manager
Figure 2.9: Policy Manager
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.
Figure 2.12: Initial FTP packet filtering window
Figure 2.13: Detailed FTP packet filtering window without deep inspection features
FTP proxy service allows to perform the following features including:
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
(?) : 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
(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
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
(126.96.36.199), 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.
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
manger or Web management GUI. The web management approach would be shown here.
Figure 2.16: Setting up HTTP packet filtering with proxy service
Figure 2.17: Setting up HTTP packet filtering with proxy service
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.
2.19: HTTP Client Proxy Deny Action to block Java scripts
The external web server address (http://188.8.131.52/external) can be accessed by trusted
admin machine (184.108.40.206) 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.
2.20: external web server address (http://220.127.116.11/external)
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 (18.104.22.168)
Install this new digital certificate and test
Our trusted server is to be the external server (22.214.171.124). Add an HTTPS
filter to the firewall, enabling SSL traffic to operate between the web client
(126.96.36.199) and the secure web server (188.8.131.52). Save configuration
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.
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
(184.108.40.206/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
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.
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
Figure 2.24: Certificate Request Wizard in IIS
Figure 2.25: Filling up information about a requested certificate
Figure 2.26: finishing the certificate request form
Figure 2.27: End of Certificate request wizard
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
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.
C:openssl> copy con serial.txt [con stands for console] 01 CTL Z
The certificate request certreq.txt should already be in the folder: C:opensslrequests
Now navigate to:
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.
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
Figure 2.32: Secure page browsing via trusted host
Figure 2.33: Detailed view of the certificate inside Internet Explorer 6
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
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.
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
Figure 2.35: Secure communication intercepted between Trusted client and External secure web
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).
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 (220.127.116.11) 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?
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:
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
2.5 Network address translation (NAT) 
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.
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
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
Figure 2.41 FTP client establishes a connection to FIrewall
Figure 2.41 Wireshark capture of inbound FTP connections
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.
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
2.43 Demo Application main window
From this application, it is possible to start any of the Watchguard reporting tools:
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.
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?
One of the users had problems getting Outlook going. Which machines were
probably involved? (Hint: Under the Edit menu, do a keyphrase search for
As it can be seen in figure below, there are two hosts involve:
2: 10.1.1.2 on port 135
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.
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
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
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.
Host-142 is the host generated the most outgoing traffic.
Venice has generated most of the connections.
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.
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
2.7 Extending Security Policy to include Roaming Clients - PPTP,
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
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.
Figure 2.50: PPTP IP pool available
Figure 2.51: An overview of PPTP setup
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.
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
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.
Figure 2.57: PPTP connection profile main window
Figure 2.58: Virtual Private Network connection selected as type of VPN
Figure 2.59: 18.104.22.168 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.
Figure 2.60: Firebox showed connation initiated from 22.214.171.124
Figure 2.61: Wireshark capture before and after PPTP connection establishment
Figure 2.62: Firebox live traffic monitor shows PPTP user connected
Figure 2.63: Service watch shows graph view of VPN connections
Figure 2.64: Authentication list shows authenticated users, protocols and IP addresses
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?
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
Having logged in as a PPTP user such as ‘Fred’, open a browser in the admin machine
(126.96.36.199/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.
What packet type is used to carry the ping requests in each case? Include a brief
What are the source and destination addresses on these packets? Include a brief
Outside trace: PPP packets carry the requests as compressed data (188.8.131.52 ->
184.108.40.206 – external firewall interface) using IP/GRE/PPP.
Admin trace: The ICMP packets appear as usual – without any wrapping protocol.
(220.127.116.11 (as assigned to pptp_user) -> 18.104.22.168 (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: 22.214.171.124 (allocated from pool)
Netmask: 255.255.255.255 – subnet of 1 machine (/32)
Default Gateway: 126.96.36.199 (PPTP Tunnel)
188.8.131.52 (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  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
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
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
Benefit from one of the industry’s highest-quality authenticator-manufacturing processes,
which means fewer token failures in the field.
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 184.108.40.206 and must reside on the trusted side of the firewall as
shown in the following diagram.
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
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.
Figure 2.67: user creation page
Once the hardware based token configuration finished, users should be assigned with tokens.
Figure 2.68: user creation page (second half)
Figure 2.69: user creation page (second half)
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.
Figure 2.71: Radius Server configuration page
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. 220.127.116.11 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
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.
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.
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
We now want to test our SSL VPN from the external machine (18.104.22.168) so we will
access a web server on the admin machine (22.214.171.124/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 126.96.36.199/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
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?
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 188.8.131.52/admin web page
Go to Firebox System Manager > Traffic Monitor log on 184.108.40.206 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
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
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
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 (220.127.116.11).
Figure 2.82: defining authentication server and gateway IP address
Figure 2.83: IPSec phase 1 settings
Figure 2.84: Allowed network resources and virtual IP Address Pool
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://18.104.22.168/admin)
page and all connection passed through a tunnel between (22.214.171.124) and
Figure 2.85: ESP encryption used to encrypt all communication
3.0 Penetration testing and Intrusion Detection of Firewall policy
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
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
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
application enumeration: uses banner grabbing to identify the services running on a
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
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.
Figure 3.3: Alternative changes to firewall
Figure 3.4: Intrusion Detection should also be disabled
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.
Figure 3.7: Nmap Quick scan results
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 (126.96.36.199) 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.
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.
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
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.
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.
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
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
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).
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
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
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?
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
Figure 3.18: CIFS Protocol vulnerabilities description
Figure 3.19: Microsoft security bulletin about SMB NULL authentication
Why are there significant vulnerabilities associated with ports upon which SMB/CIFS
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
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.
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
Next navigate to the log folder on the admin machine (188.8.131.52), i.e.
C:Snortlog but SNORT will have to be terminated (CTL C) before viewing alertlog.
There will be folders/files named:
Alert log view logged network attacks like ICMP unreachables. It is classified as
potentially bad traffic.
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
184.108.40.206 -> 220.127.116.11 (portscan) Open Port
Open Port: 21
18.104.22.168 -> 22.214.171.124 (portscan) Open Port
Open Port: 443
126.96.36.199 -> 188.8.131.52 (portscan) Open Port
Open Port: 25
184.108.40.206 -> 220.127.116.11 (portscan) Open Port
Open Port: 135
18.104.22.168 -> 22.214.171.124 (portscan) Open Port
Open Port: 139
126.96.36.199 -> 188.8.131.52 (portscan) Open Port
Open Port: 80
184.108.40.206 -> 220.127.116.11 (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
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-
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.
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 18.104.22.168 -> 22.214.171.124
ICMP TTL:64 TOS:0xC0 ID:20477 IpLen:20 DgmLen:106
Type:3 Code:3 DESTINATION UNREACHABLE: PORT UNREACHABLE
** ORIGINAL DATAGRAM DUMP:
126.96.36.199:137 -> 188.8.131.52: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
[**] [1:399:6] ICMP Destination Unreachable Host Unreachable [**]
[Classification: Misc activity] [Priority: 3]
05/18-19:04:15.833949 184.108.40.206 -> 220.127.116.11
ICMP TTL:64 TOS:0xC0 ID:20478 IpLen:20 DgmLen:106
Type:3 Code:1 DESTINATION UNREACHABLE: HOST UNREACHABLE
** ORIGINAL DATAGRAM DUMP:
18.104.22.168:137 -> 22.214.171.124: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.
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. SNORT has detected FTP anonymous access between ports 4604
(Varies) on 126.96.36.199 and port 21 on 188.8.131.52 
3. File sharing possible without login ID and password 
See further details below but examples are classification of
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.
 Firewall (computing), 2014. . Wikipedia, the free encyclopedia.
 Zone-Based Policy Firewall Design and Application Guide [WWW Document], n.d. Cisco.
guide.html (accessed 5.22.14).
 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).
 Next Generation Network Security Firewall - WatchGuard Technologies [WWW
Document], n.d. URL https://www.watchguard.com/solutions/next-generation-firewall.asp
 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).
[8 VMware Workstation: Run Multiple OS, Linux, Windows 8 & More; | United States
[WWW Document], n.d. URL http://www.vmware.com/products/workstation (accessed
 Network address translation, 2014. . Wikipedia, the free encyclopedia.
 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).