Network Perimeter Security

Policy Lab

Writing, implementing, auditing and reviewing

network perimeter security policy.

The security of your network is evaluated daily. A rich question

to ask is, “Are you the one doing it?”
From Inside Network Perimeter Security: The Definitive Guide to Firewalls, VPNs, Routers
and Intrusion Detection Systems. New Riders, 2003.
Stephen Northcutt, et al., Director of Training and Certification, SANS Institute

Lab designed by: Christopher Rowe

GCIH, GGSC, Security+
Guilford Technical Community College
Jamestown, NC
carowe@gtcc.edu
 INTRODUCTION

Overview
This lab will demonstrate three parts of a proper security plan. First, it will demonstrate how a
security policy is implemented by stating network configuration policy and creating configuration
based on this; Second, it will test the configuration to ensure compliance with the policy; Third, it
will demonstrate how to log this information for later analysis, as well as the importance of
periodic log examination.

In Part I Writing and Implementing policy, the student will create a network security policy for
the perimeter. The policy will call for the filtering of certain types of packets. Topics the student
will learn to draft and implement include black lists, and ingress and egress filtering. Based on
this policy, the student will create and implement access lists on the appropriate device (Cisco
router or PIX firewall, Microsoft or Linux Server, or other firewall). See Lab Topology (below)
for more information on the platforms.
In Part II Auditing Policy, the student will verify (or enumerate problems with) these filters by
using a packet crafting tool. We will also analyze the results.
To enumerate, we will use either hping2 (Linux) or Engage Packet builder (Windows) to craft a
specialized packet to send from one side of the router to the other. On the opposite end, we will
use a packet sniffer (Ethereal or similar) to see if the packet was filtered or not. In addition, we
will use logging and debugs to watch the real-time traffic.
Finally, in Part III Reviewing Policy for Compliance, the student will review the results of the
policy audit. A discussion of recommended changes will follow. (Alternately, the instructor may
opt to make students prepare a professional report of the results and recommendations).

Objectives
This lab reinforces concepts of network security policy, policy enforcement, policy audits and
review. The following objectives from the Security+ exam are reinforced through this lab:

• 1.7 Understand the concept and significance of auditing, logging and system
scanning.
• 3.1 Understand security concerns and concepts of the following types of devices
o Firewalls
o Routers
• 5.4 Understand the concepts and uses of the following types of policies and
procedures.
 Lab topology
This lab will primarily rely on a packet filtering device of some sort, acting as a border router.
This can be either a Cisco (or other) router with appropriate access-lists configured, or it may be a
Microsoft or Linux server, configured as a firewall. In addition, a workstation will needed on
either side of the border router; the outside interface will be used as an “attacker”, while the
inside host will serve to verify the policy enforcement through packet analysis. Hubs or switches
should be used where needed.
Regardless of the platform, you should review any filtering rules (i.e. top-down processing, limits
on lists, etc.). The lab is designed for Cisco router ACLs, and presupposes an understanding of
those. However, it can easily be adapted to the other platform, based on student or instructor’s
background. Appendix A provides the setup for an instructor that does not have a background in
perimeter security. Please note that changing the platform (from Cisco router to PIX firewall,
Linux, etc.) may change the way the lab works, in particular if the device does tracks state or does
actual packet inspection..
NOTE: A single managed switch (Cisco Catalyst, for example) can be used by separating
designated ports into separate VLANs. The separate broadcast domains created by the VLANS
can be connected via two physical interfaces, or one physical interface configured with sub-
interfaces. However, these concepts are beyond the scope of this lab The need for hubs/switches
can be eliminated altogether if you use crossover cables to connect the workstations to the router
interfaces. FOR INSTRUTORS AND STUDENTS WITHOUT ROUTER CONFIGURATION
EXPERIENCE, APPENDIX A PROVIDES SETUP. ALTERNATELY, AN INSTRUCTOR MAY
CHOOSE TO REQUIRE STUDENTS TO SETUP THE LAB THEMSELVES.

198.86.106.5 192.168.1.10

OUTSIDE INSIDE
198.86.106.0 / 24 192.168.1.0 / 24

FA0/0 FA0/1
198.86.106.2 192.168.1.1
INTERNET
Two software programs are needed. The first is some sort of packet sniffer (Ethereal,
tcpdump/windump, Etherpeek, Snort, etc.) installed on both the attacker and the host. If the
packet filtering device is a server, the sniffer may be installed here, as well; if using a Cisco
router, debug commands will be provided. Second, a packet-crafting program will be needed in
Part II; suggestions include hping2 (for Linux, CLI) or Engage (for Windows; formerly Rafael/
GUI-based).

Ethereal sample capture

PART I Writing and Implementing Network Security Policy (90
minutes)
The purpose of this part of the lab will allow you to develop and implement a security policy. The
key here is remember that policies dictate WHAT is acceptable, not HOW to implement it (that
will be Part II).

"Information security policies are high-level plans that describe the

goals of the procedures ... not guidelines or standards, nor are they
procedures or controls."
-- Writing Information Security Policies. Barman, Scott. New Riders, 2002.

Step I -1
Research the basics of security policy drafting, implementation and auditing. To do this, read the
SANS policy primer at http://www.sans.org/resources/policies/Policy_Primer.pdf, then answer
the following questions.

1. List 5 purposes for policy.

2. What is the underlying concept and determinate when drafting policy? What is the first
step of determining your policy?

3. What are the three trust models? Which is best and why?

4. What is the “scope” of a policy?

5. Does a policy need to be reviewed? If so, how often?

6. What are three absolute “musts” of policy?

7. Examine the slide on “Other Important Policies”. Which one best describes this activity?
Repeat for the “Configuration Management Practice” slide.

8. Examine the sites listed on Slide 29, “Policy Resources”. List some findings from this
research.

Step I-2
Examine the objectives listed below, and write policy statements that adhere to this. If you need
assistance, use the sample policies from SANS.
• Prevent reconnaissance by blocking ping scans
• Ingress, egress filtering
• Black listing
• Acceptable protocols: HTTP, FTP outgoing; initiated-conversations
(Acknowledgements) incoming. No connections should be established from the outside.
• Log all matches except HTTP.

9. What is ingress filtering? Why is it needed? Is there an RFC for this? Cite your source.

10. What is Egress filtering? Why is it needed? Is there an RFC for this? Cite your source.
 11. Black listing? Cite your source.

12. What is packet filtering? Packet inspection?

13. What is the concept of “state”, as in “stateful inspection”.

Step I-3
Create a chart such as the following. List the relevant information for creating the ACLS (the first
two filters are provided as an example:

Purpose Block ping scans ingress filter

Policy direction inbound inbound
Action to take deny deny
L3 or L4 protocol Ip ip
source any 192.168.1.0
host or network? network network
protocols/ports icmp all
Destination any 192.168.1.0
host or network? any network
protocols/ports icmp All
log? yes Yes
Comments Blocks Blocks traffic
(How does ICMP with our IP
it enforce echo- as source
policy) requests from
from entering the
entering network
the
network
Step I-4
In your notebook, write the configurations that are needed to implement the policy. This will be a
series of access lists that filter the appropriate information. DO NOT ADD THE ACL
CONFIGURATIONS THE ROUTER – YET!
NOTE: If you require additional information on creating Cisco Extended ACLs, please see the
SANS whitepaper at: http://www.sans.org/rr/whitepapers/networkdevs/231.php. The paper
covers both crafting and application of the lists. It is recommended you review the rules for
implementation.

Cisco Extended ACL format (see Appendix B for alternative ideas):

Access-list [list #] [permit | deny] [L3/L4 protocol] [source address] [source-mask]
[destination address] [destination mask] [operator] [port] [log]

Sample ACL (rule #2):

A) create list
router#config t
Router(config)#Access-list 101 deny ip 192.168.1.0 0.0.0.255 any log

B) apply list
! apply to interface facing the internet, blocking inbound
router#config t
router(configu)#int s0/0
router(config-if)#ip access-group 101 in
router(config-if)#CTRL-Z

Step I-5
Have your instructor review and approve your configurations. Configure your packet filtering
border router machine (router or server). Be sure to test the network. DO NOT APPLY THE
ACLS YET!! These tests ensure that dropped packets are the result of the filters and not improper
configurations. We will do a traffic analysis before we apply the access list.
PART II Auditing your network security policy (90 minutes)
This part of the lab will allow you to perform an audit, that is, test policies that you designed and
implemented in Part I.

Step II-1

First, we will see some problems that are presented, and why we need policy to address them. If
you have not already done so, set up the lab topology as shown in the Introduction. Your
instructor may choose to provide you with a working router configuration, or have you create the
configuration yourself. When you have finished, make sure the configuration is working by
testing to make sure ICMPs can be sent out of the network. Do this by pinging the “attacker”
machine from the inside host. You should receive echo replies to this ping. In addition, ping the
inside of the network from the attacker machine. If you do not, troubleshoot before going to the
next step.

C:\>ping 198.86.106.10

Pinging 198.86.106.5 with 32 bytes of data:

Reply from 198.86.106.5: bytes=32 time=1ms TTL=127

Reply from 198.86.106.5: bytes=32 time=1ms TTL=127
Reply from 198.86.106.5: bytes=32 time=1ms TTL=127
Reply from 198.86.106.5: bytes=32 time=1ms TTL=127

Ping statistics for 198.86.106.5:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss).
Approximate round trip times in milli-seconds:
Minimum = 1 ms, Maximum = 1 ms, Average = 1 ms

Step II-2 (Windows machines)

If you are using a Windows machine to test from the outside (attacker), download and install the
packet building tool from Engage. NOTE: You will need to install WinPCAP (minimum ver. 2.3)
before installing Engage Packet builder. If you have previously installed packet-dissecting tools
(i.e., Snort, Ethereal, windump), you should already have this. The website is:
http://www.engagesecurity.com/downloads/#engagepacketbuilder
Step II-3

Here we will see potential exploits. In this case, we are going to craft a packet with a source IP
address that is on our own network. An attacker may try to do this to get malicious code past the
router and into your network; alternately, a misconfigured device may be sitting outside your
network and using an internal IP. Both of these scenarios present problems and need to be
avoided. Access lists can do that, but first let’s see the packet.

To do this, use either Engage Packet builder or hping2. On the target host, start Ethereal. On the
router (or other packet filter), if possible, make sure you are logging to the console (on a Cisco
router, use the “router(config)#logging console” command). On the attacker machine, use Engage
Packet Builder to spoof the source IP as follows:

a) In the top, left corner, select the appropriate interface to send the packet out
b) If spoofing the source IP, uncheck the “Set as source IP” box; then, in the middle, left, set
a source IP address as an inside address (192.168.1.5).
c) In the middle, left, set the inside host IP address (192.168.1.10) as the destination IP
d) Configure an appropriate destination port; while this should not matter, a common port
may be more beneficial (i.e., http=80; dns=53; smtp=25); port 0 can also be handy!.
e) On the right-hand side, be sure the TCP tab is in front
f) Push the SYN button
g) When you have set all appropriate options, press SEND in the bottom, left corner.
 Engage Packet Builder

On the router, turn on debugging in order to see the packets traverse the network:
Router#debug ip packet

You should receive the following message..

IP packet debugging is on

In addition, packets that traverse the router will be shown

00:25:02: IP: s=198.86.106.2 (local), d=255.255.255.255 (FastEthernet0/0), len 5

2, sending broad/multicast
00:25:02: IP: s=192.168.1.1 (local), d=255.255.255.255 (FastEthernet0/1), len 52

To debug the access-lists use:

Router#debug ip packet 101
IP packet debugging is on for access list 101

Finally, you can view matches to the ACL with the following:
Router#sh access-list 101
Extended IP access list 101
deny ip 192.168.1.0 0.0.0.255 any (9 matches)
On the target host, you may see the packet making it past the router, even though the packet
should not have come from the 198.86.106.0 network. Ethereal verifies that the packet showed
up. In addition, since the target host did not recognize the address, it sent an ARP request to find
the missing information. Bonus: Check the ARP table (arp –a). If the outside host MAC
address is shown with the crafted IP, you have the foundation for a Man-in-the-middle
attack.
Step II-4

In this step we will test the accuracy of your access-lists. First, create a compliance list from your
rules you listed above.
After testing, you will check each rule that complies. Test the first rule by pinging the internal
network from the attacker machine. If your policy is in compliance (responds appropriately),
check off the first rule; add any appropriate comments. If it is not, make a note of the problem;
later, determine whether failure is a configuration problem or device problem; then consider and
provide a suggestion for improvement.

To test compliance of rule #12, it will be necessary to craft an ACK packet. Again, we can use
Engage Packet Builder. Repeat steps a-e in the last step; in f) set the ACK bit. Use Ethereal again
to verify policy compliance or non-compliance.
PART III Reviewing Policy for compliance (30 minutes)
Review the results of your audit and answer the following questions (answers may vary
depending on filtering device):

Which rules complied?

Which did not? If not, why not? What (if anything) can be done to bring them into compliance?

Is your security policy effective?

If not, what changes need to be made in order to bring your organization into compliance?

Why should these results be monitored on a regular basis?

Discuss the results as a class, or with a lab partner.

 APPENDIX A
INSTRUCTOR SETUP (30-45 minutes)
This appendix is designed to assist an instructor in setting up the lab topology. While a CCNA or
equivalent knowledge is recommended for best results, it is not required. This appendix serves to
fill in that gap.

Setup Step 1
Install two operating systems.
Either Windows or Linux may be used for this lab, depending on what the instructor or students
feels comfortable with. Any combination may be used for the two hosts (i.e. Windows-Windows,
Windows-Linux, Linux-Windows, Linux-Linux). You will need an Ethernet connection to the
router. Connect patch cables via a hub or switch, or use crossovers to directly connect.

Setup Step 2
Router setup

The following configuration is based on a Cisco 2600. The configuration provides IP

addressing for interfaces, routing protocol, and telnet configuration for remote access.
You may need to make changes, depending on your equipment. NOTE: If using a Cisco
2500, you will need to change the interfaces as follows: fa0/0 = e0; fa0/1 = e1.
To set up the router, plug a console (rollover) cable into the console interface of the router.
Connect the other end to a 9-pin serial port on the PC (you may need a transceiver if you have RJ-
45 connectors on both sides). Open HyperTerminal. Select the following options:
 Bits per second (9600)
Data bits (8)
Parity (none)
Stop bits (1)
Flow control (hardware or none)

Hit return a few times to get a prompt. If you get strange characters, you may need to download
Hyperterminal Private Edition.
Setup Step 3
Basic router configuration.
If everything is working correctly, you should have a router “user mode” prompt (router>). Cut
and paste the following configuration into HyperTerminal:

En
Configure terminal
Enable secret security+
Int fa0/0
Ip address 198.86.106.5 255.255.255.0
No shutdown
Int fa0/1
Ip address 192.168.1.1 255.255.255.0
No shutdown
Router rip
Network 192.168.1.0
Network 198.86.106.0
Exit
Line vty 0 4
Password security+
Login
Exit
Exit
Copy run start

When you have finished, you should be able to ping both hosts from the router. The hosts should
be able to ping each other as well. If you have problems, this is the time to troubleshoot!

Step 4 (optional; for Linux users)

Linux information
Configuring the Ethernet interface: The easiest way is to use the netconfig program. You will be
presented with DOS-style window, and can configure a static IP, subnet mask and gateway. Use
the following information:

Attacker IP 198.86.106.5 Victim IP 192.168.1.10

Subnet mask 255.255.255.0 Subnet mask 255.255.255.0
Default gateway 198.86.106.2 Default gateway 192.168.1.1

Alternately, you use the command line (need to be at root (#) prompt):

ifconfig eth0 198.86.106.5 netmask 255.255.255.0 up

route add default gw 198.86.106.2
Make sure a working version of hping is installed. (Hping2 RC3 as of 2/05; Hping3 available in
beta). If it is not, you can download it from this link:

From hping.org:

While hping was mainly used as a security tool in the past, it can be used in many
ways by people that don't care about security to test networks and hosts. A subset of
the stuff you can do using hping:
• Firewall testing
• Advanced port scanning
• Network testing, using different protocols, TOS, fragmentation
• Manual path MTU discovery
• Advanced traceroute, under all the supported protocols
• Remote OS fingerprinting
• Remote uptime guessing
• TCP/IP stacks auditing
• hping can also be useful to students that are learning TCP/IP.

Hping should work without problems on the following unix-like systems:

• Linux, FreeBSD, NetBSD, OpenBSD, Solaris, MacOs X

If using hping for Step II-4, use the following commands at the shell prompt:

Send three packets with the source address 192.168.1.5 from the attacker machine. Result should
be blocked.

Hping2 –c 3 –v –a 192.168.1.5

This command sends three packets with the ACK bit set. Used to audit no conversations
originating from the outside.
Hping2 –c 3 –v –A
 Appendix B
Additional topics for experienced instructors
The main problem with the policy audit should have been with the inability to stop packets that
are not part of a conversation from entering. While an extended access-list can block SYN
packets from entering, it does not track state (exchanges that are part of a single TCP connection);
therefore, other packets (ACK, FIN, etc.) can be crafted to get through – and carry potentially
deadly payload.
On the other hand, reflexive access-lists “mirror” the outgoing traffic, creating dynamic ACLs on
an as-needed basis. You may want to have the students research this topic. They could then write
and audit the reflexive ACLs. Discuss the differences.

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter
09186a00800ca7c3.html

http://www.netcraftsmen.net/welcher/papers/reflexiveacl.html

Other ideas for consideration, discussion or alternative labs:

• Ingress and egress filtering have been used commonly to refer to filtering inbound and
outbound packets, respectively. However, this lab assumes the more formal definition, as
stated in Inside Network Perimeter Security (Northcutt, Stephen, et al.; New Riders
2003).
o Ingress filtering is the blocking of reserved IP addresses, as defined in RFC 1918.
o Egress filtering is the blocking of packets with a source IP other than yours (in
the lab, 192.168.1.0 / 24).
• If you have the Cisco Fundmentals of Network Security router bundle, you can use the
CBAC software to do stateful inspection on a router.
• Alternately, you could replace the router with a PIX firewall for the same purpose.
• Even Linksys routers will do stateful packet inspection. These can be had for around $50.
• Another option would be to have the students research devices that would do stateful
inspection.
• You could implement other alternatives for a firewall (Linux IP tables, MS server packet
filtering, ISA server, etc.). I would encourage you to send me any configurations for these
alternate topologies.
• Mix and match the ideas above; that is, after seeing the problems with the router, replace
with a PIX and retest. This would be part of a policy improvement scenario.
• Run Ethereal on the attacker machine. Examine returned packets for ICMP type. Note the
“type” field in the ICMP packets; they should have a “Administratively prohibited” flag
set. For more information on the various headers, see the SANS “TCP/IP and tcpdump
flyer” network protocol headers.
• Discuss how packet spoofing can lead to Man-in-the-middle attacks. Consider a
demonstration or lab using Ettercap on a local segment to show this concept.