Ubuntu, Sguil, InstantNSM and GSE Lab Prep

Last week I discussed Sguil and I was going to do a post on getting Sguil running on Ubuntu. Like most good plans, mine feel apart. To start with, I changed what I intended to blog about late in the game, than ran out of time.

My plan now is to include using InstantNSM and the Sguil packages to get a Network Security Monitoring (NSM) up quickly. In order to do to this I have to modify InstantNSM to “support” debian based systems. This modification will be made and tested over the next month or so. I have contacted the developer for InstantNSM to see about adding support for Ubuntu.

On the GSE Lab front I have spent time building the lab, started to read the Wireshark Network Analysis  book, and spend some time reviewing network traffic (outside of my day job of course). As I spend more time with packet captures, I am becoming more proficient writing filters in tcpdump and Wireshark.

Next week I am going on short three day trip with the wife and friends so I probably wont get a chance to post anything new, but you never know.

GSE Lab Prep – The Tao of Network Security Monitoring and Sguil

I spent the past week reading The Tao of Network Security Monitoring by Richard Bejtlich as part of my “study plan” for the GSE Lab. Fortunately, or unfortunately, take a train to work every day and that gives me 1.5 hours to do whatever I want to. This time allows me to read a 600+ page technical book cover to cover in a little over a week. I also have spent time building/playing with my GSE lab.

Since there are so many reviews of the book I will limit my review to only say Richard did an amazing job with this book and if you perform any type of Network Security Monitoring (NSM) this is a must read book. One of the great strengths of this book, is Richard discusses several NSM tools not covered elsewhere other then in passing.  I am sure some of these tools will be covered in detailed in the GSE lab, so I plan on spending some time with the ones I am not intimated familiar with.

One tool mentioned in the book that I plan on spending time with is Sguil. According to the nsmwiki, Sguil is best described as aggregation system for network security monitoring tools. Major tools used by Sguil include:

• Snort/Barnyard
• Security Analyst Network Connection Profile (SANCP)
• Passive Asset Detection (PADS)
• p0f
• tcpflow

The great thing about studying Sguil for the GSE lab is all of the tools are discussed in the GSE pre-requisite classes. That fact alone makes Sguil a great tool to spend time with in the GSE lab. One thing I do know that is described as a down side to Sguil is the installation of it. I know a few articles discuss installing Sguil on Ubuntu 10.04 Long-Term Support (LTS), but I plan on writing up a procedure and posting on the blog within the next week.

Interpreting Discovery Scan Results

Last time I discussed how to perform an nmap syn scan for host discovery. With the scan complete interpreting the results is the next step. Lets start by discussing the results and how to interpret them, followed by looking at the three output files and what they are can be used for.


The first line in the results shows what options the scan was run with.. One thing to note is the version appears to only be the major release, not the exact version used for the scan. Here is the first line in the filename.nmap showing what scan options were used during the scan.

# Nmap 5.00 scan initiated Sun Sep 19 11:46:59 2010 as: nmap -PN -n -sS -T 1 -p 21-23,25,80,110,143,443,3389 -oA hostdiscovery 192.168.1.0/24

After the scan options the next line shows the IP address of the online host. The following line breaks down the description of the output, the port, the state and the service. After the description line, the number of ports listed will vary based on the scan options. Here is the nmap output of two of the host on the target network:

Interesting ports on 192.168.1.150:
PORT STATE SERVICE
21/tcp closed ftp
22/tcp filtered ssh
23/tcp closed telnet
25/tcp filtered smtp
80/tcp open http
110/tcp closed pop3
143/tcp closed imap
443/tcp open https
3389/tcp closed ms-term-serv

Interesting ports on 192.168.1.151:
PORT STATE SERVICE
21/tcp closed ftp
22/tcp filtered ssh
23/tcp closed telnet
25/tcp filtered smtp
80/tcp open http
110/tcp closed pop3
143/tcp closed imap
443/tcp open https
3389/tcp closed ms-term-serv

The port field (when scanning UDP and TCP protocols) lists the port number protocol that nmap scanned.

The state field is the critical field when determining if a host is online. For nmap there are 6 possible states. The three states from most scans, including a syn scan, is open, closed, and filtered. Be aware three other states may be seen in different types of scans. Here is a brief description of each state, but please visit the nmap website for more detailed explainations.

Open – the port is actively listening and accepting connections.

Closed – the port is not actively listenting

Filtered – the port is being filtered by a packet filtering device

For this example port state let’s focus on ports tcp/22 (ssh), tcp/25 (smtp) and tcp/80 (http) on host 192.168.1.150 (TargetA), and 192.168.1.151(TargetB).

Starting with tcp/22 on TargetA the port state is filtered. So we know that there is a packet filtering device between us and the target network. TargetB tcp/22 port state is open.

Next looking at tcp/25 on TargetA and the port state is filtered. Again it appears there is some of packet filtering device between us and the target network. TargetB tcp/25 port state is closed.

Finally looking at tcp/80 on TargetA and TargetB the port state for each host is open.

It’s important to note the service listed in the scan results uses the nmap-services database to identify the service. Suring this scan no service detection was performed and the results are relying solely on the services database. Remember it’s possible to have another service running on a port on any port. For example a web server could be listening on tcp port 21 (ftp server). During the enumeration scan, version detection should be done to ensure the correct service running on a particular port is identified.

The final line of the scan provides information about the total number of online hosts and how long the scan took to complete. Here is the last line of output from the scan results:

# Nmap done at Sun Sep 19 13:57:06 2010 -- 256 IP addresses (10 hosts up) scanned in 7807.86 seconds

Looking at the scan results a couple of items of interest can be determined. Looking at tcp/22 on the two hosts (TargetA and TargetB), there is a good chance a packet filtering device is being used. Looking at the various port states, with some ports in a filter state while others are in a closed state, it’s probable the packet filtering device policy is default permit.

By performing a discovery scan first, there is a better understanding of which systems are online and how the firewall is configured. When the information gathered during the discovery scan, the enumeration phase can be more targeted resulting in two benefits. The first benefit is time saved by focusing on only hosts online. The second benefit is there is a less likely hood of detection because later phases of the penetration test is more targeted.

With an understanding of how to interpret the results, the three different output files can be used to the testers’ advantage. The three types of output files were the normal, grepable and XML files.

The normal output file (.nmap file extension) is great when looking if looking at the entire scan result or for counting how many ports are open in a scan. If you want to search the results for how many host have a particular port, this simple search can be performed:

host#grep –i ‘80/tcp’ hostdiscovery.nmap | wc -l
10

The results from the grep shows that 10 hosts have tcp/80 open. With this information service detection scans could be used for tcp/80 or a full enumeration scan could be performed. The normal output is good for trying to gather information from an overall perspective (i.e. count all open tcp/80 ports), but if the objective is to know which specific hosts have tcp/80 open other formats should be used. The normal format output is one port per line making more complex searches much more difficult.

Searching for specific information is best done using the grep output file (.gnmap file extension). This format takes the scan results for one host and writes it on one line, making it easier to search with tools from the command line. For example to search for all host with tcp/80 open using grep this command would perform the search:

host# grep -i '80/open' hostdiscovery.gnmap
Host: 192.168.1.150 () Ports: 21/closed/tcp//ftp///, 22/filtered/tcp//ssh///, 23/closed/tcp//telnet///, 25/filtered/tcp//smtp///, 80/open/tcp//http///, 110/closed/tcp//pop3///, 143/closed/tcp//imap///, 443/closed/tcp//https///, 3389/closed/tcp//ms-term-serv///
Host: 192.168.1.151 () Ports: 21/closed/tcp//ftp///, 22/filtered/tcp//ssh///, 23/closed/tcp//telnet///, 25/closed/tcp//smtp///, 80/open/tcp//http///, 110/closed/tcp//pop3///, 143/closed/tcp//imap///, 443/open/tcp//https///, 3389/closed/tcp//ms-term-serv///
< -- output cut for brevity -- >

The results return every host with tcp/80 open but they are difficult to read, especially when looking at large networks. Since the objective is to find hosts with tcp/80 open, the grep command can be combined with awk to find hosts with tcp/80 open as seen here:

grep -i '80/open' hostdiscovery.gnmap | awk '{print $2}'
192.168.1.150
192.168.1.151
192.168.1.152
192.168.1.200

The final format, XML output (.xml file extension) can be read by many different application including scanpnbj. Using scanpnbj the results in the XML file can be imported and stored in a sqlite database. Then using outputpbnj the results can be query using sql statements. Remember many other applications also can import XML formatted output as well.

Performing a discovery scan and properly interpreting the results increases the value of the penetration test for the client. Correctly identify online targets allows the penetration test more time to focus on known live hosts. The customer receives a more accurate understanding of the risk to their organization.

Detecting live hosts on a target network.

When performing a penetration test it is imperative that all hosts on the target network are identified. Typically when performing a penetration test all that is provided to the tester is the IP range, sometimes that is not even provided. With just a network range you must identify all live hosts in that range.

In the past, ping sweeps was reliable enough that a pen tester could be comfortable in those results. Today this is not the case, as many organizations block ALL unsolicited ICMP traffic at their border, so other methods must be used to identify live host on the network. Not only are organizations blocking ICMP but they are using tools to identify this type of activity such as firewalls, IPS/IDS and possibly even a Security Event Incident Manager (SEIM).

Since just a ping sweep can’t be performed other methods must used to identify live hosts. To accomplish this I typically use the tool nmap to perform a TCP SYN scan.

To understand how this scan works you must first understand how TCP connections are established on open ports, what happens if the port is closed and finally what happens if the target host is not online. When two hosts want to communicate over TCP a TCP connection called a TCP session must be established. To establish the connection the TCP three way handshake must be completed.

The first step is for the host initiating the connection (Host A) to send a TCP packet to a specific port, for example 80, with the SYN flag set to the target host (Host B) it is attempting to establish the connection with as seen in this lovely ASCII art.

Host A ------SYN------- > Host B

Since Host B is listening on port 80, Host B sends a TCP packet with both the SYN/ACK flag set back to Host A as seen here.

Host A <------SYN/ACK-----Host B

Host A, after receiving the packet from Host B, sends a TCP packet with the ACK flag set to Host B to acknowledge it received the 2nd packet, and the connection is now established and data can be transferred as seen here.

Host A ------ACK------- > Host B

So now that there is understanding of how a TCP session is established, let’s examine what happens if the Host B is not listening on port 80.

The first step is the same with Host A initiating a connection to port 80 on Host B with the SYN flag set.

Host A ------SYN------- > Host B

Since Host B is not listening port 80, Host B will reply with a TCP packet with the RST flag set.

Host A <------RST-----Host B

Although the Host B is not listening on that port a response from Host B is still sent to Host A indicating it’s online.

Finally let’s look at attempting to establish a TCP connection for a host that is not online.

Again the first step is the same with Host A initiating a connection to port 80 on Host B with the SYN flag set and a timeout of 1 second.

Host A ------SYN------- > Host B

Since Host B is offline there is no response, Host A will send another packet these time waiting 2 seconds for Host B to respond. After not hearing from Host B a second time it will send a third packet waiting 4 seconds for Host B to respond. After the third packet Host A will assume Host B is unavailable and quit trying to reach it.

Understanding how TCP sessions are establish can be useful in identifying live host on the network. With this knowledge it is time to start discovery live hosts.

The objective of this scan is Host discovery, with a secondary objective of being stealthy to avoid detection. To meet these objectives nmap’s TCP SYN or “half open” scan will be used.

Nmap’s SYN scan sends a TCP packet with SYN flag set to the target. The target host will reply if online with the appropriate response (SYN/ACK for open ports, or RST for closed ports) depending on the state of the port. If the target host sends a TCP packet with the SYN/ACK flags set, the scanning host will not complete, resulting in a half open connection. If the target host is offline there should be no response.

To perform the SYN scan using nmap is the command line options:

nmap –Pn –n –sS –T 1 –p 21-23,25,80,110,143,443,3389 TARGET -oA OUTPUTFILES

The first option (-Pn) treats all host online, skipping the Host Discovery phase. Nmap’s Discovery Host sends an ICMP echo request, ICMP timestamp request, a TCP SYN packet to port 443, and a TCP ACK packet to port 80. This type of discovery is good if there are no packet filtering devices between the scanner and the target, but this typically will not be successful over the Internet.

The second option (-n) turns off name resolution. Other tools such as nslookup, dig, can be used for DNS enumeration. Turning off name resolution has an additional benefit of speeding up the scan, especially when scanning large networks.

The third option (-sS) is the SYN scan option.

The fourth option (-T 1) is the speed of the scan. The speed range of the scan is 1 through 5 with 1 being the slowest and 5 being the fastest. This option can be used to assist in evading detection during a scan. Since an objective is to scan undetected slow scans are preferred, but not always an option.

The fifth option (-p) selects the ports to scan.

The TARGET is of course the target of the scan. For nmap this can be a single host, a subnet, a range of host (such as 10.0.0.1-10.0.0.23) or a combination of any or all of them (such as 10.0.0.1,10.10.10.0/25,10.10.20.4-56).

The last option (-oA) is to output the scan results in normal, XML, and grepable formats. Following that flag is the base name of the output files. The normal (-oN) output is great if you want to look through all of the results. The grepable (-oG) output is for using grep and other shell commands to search through the output. The XML (-oX) output produces the output formatted in XML.

For demonstration purposes the target network to be scanned is 192.168.1.0/24. To simulate a typical Internet connected target network this network is protected by a firewall. To begin host discovery, type this command:

nmap –Pn –n –sS –T 1 –p 21-23,25,80,110,143,443,3389 192.168.1.0/24 -oA hostdiscovery

Once the scan completes the following information will appear.

Nmap done: 256 IP addresses (10 hosts up) scanned in 7807.86 seconds

From these results we see 10 hosts are up. The benefit is there is a likely chance, not guaranteed though, most online host are detected. Now more extensive scans can be performed against known live targets.

Another thing to note it took over two hours to complete the scan, even though the scan host and the target network are connected to same switch. This could have been performed quicker using the timing option, but the likely hood of detection would have been higher.

Also looking in the directory there will be three files containing the output of the scan named hostdiscovery.gnmap (-oG), hostdiscovery.nmap (-oN) and hostdiscovery.xml (-oX). These file will be used to determine if host are on online.

With the discovery scan complete, the results have to be interpreted. The interpretation of the results is critical to determine online host that should have more intensive port scans. Next time I will discuss how to interpret the scan results.

WEP cracked in under 10 seconds………….

In a previous post I discussed taking the Offensive-Security Wireless Attacks course. I went through the first technical section which focuses on using aircrack-ng (and associated tools) to detect and attack wireless networks in a lab. The lab I built for this class consists of an Alfa USB Wifi Card and a Linksys WRT-54G (Linux) that supports WEP, WPA and WPA2 encryption.

Most Information Security professionals with exposure to wireless security understand why WEP is insecure, why not to use it and the risk associated with using it. However there are people who still believe WEP is sufficient for security of a wireless network.

During one of the exercises cracking WEP keys, I came across something that I could not believe at first. I was able to capture packets for my lab SSID using airodump. Typically you want about 40000 IV’s to start cracking WEP, to get a decent opportunity at successfully cracking it.

On this exercise though I thought I would take a shot at 20000 IV’s. Well, I should have bought a lottery ticket because my WEP key was cracked in 8 seconds. Now this WEP key uses a “64” bit key and is quicker to crack, but the fact that it took me longer to enter in the commands to crack the key then it took to actually crack the key shows how insecure WEP is.

I saved the packet capturefor demonstration purposes when I hear people discuss WEP security/insecurity. Like the say a picture is worth a 1000 words!

Internet Network Filtering Part 4

With the inbound filtering configure it is time for filtering the DMZ’s. The focus of the 4th part of the series will be configuring the ACL’s for the customer DMZ.

The perimeter architecture consists of two DMZ’s. The first DMZ is called “Service” DMZ, the second is called “customer”. The customer DMZ consists of systems used by Widgets to interact with Widgets customers, these systems include the web site, online shopping and online support database.

When configuring network access its’ important to ensure exposing only required ports. Because there are requirements for two DMZ’s we must create two ACL’s. To create the customer DMZ ACL we must identify we systems, their IP addresses and the required ports for the customer DMZ.

Listed below are the requirements for the customer DMZ:

Widgets Website – 5.2.3.80 (192.168.1.80) [tcp/80]
Widgets Extranet Website – 5.2.3.143 (192.168.1.143) [tcp/80 & tcp/443]
Widgets Online Database – 5.2.3.44 (192.168.1.44) [tcp/80 & tcp/443]
Widgets 3rd Party Online Database Support Applications – 5.2.3.250 (192.168.1.250) [tcp/12345, tcp/23456, & tcp/34567]

With requirements defined its time to create the access-list. Since this is the ACL for the customer DMZ the ACL name will be customer_access_in. Because traffic will be responding to the request we must ensure that we permit traffic from our DMZ host back to the original request. Here is how the ACL will be configured:

access-list customer_access_in permit tcp any 192.168.1.80 eq 80
access-list customer_access_in permit tcp 192.168.1.80 eq 80 any
access-list customer_access_in permit tcp any 192.168.1.143 eq 80
access-list customer_access_in permit tcp 192.168.1.143 eq 80 any
access-list customer_access_in permit tcp any 192.168.1.143 eq 443
access-list customer_access_in permit tcp 192.168.1.143 eq 443 any
access-list customer_access_in permit tcp any 192.168.1.44 eq 80
access-list customer_access_in permit tcp 192.168.1.44 eq 80 any
access-list customer_access_in permit tcp any 192.168.1.44 eq 443
access-list customer_access_in permit tcp 192.168.1.44 eq 443 any
access-list customer_access_in permit tcp any 192.168.1.44 eq 12345
access-list customer_access_in permit tcp 192.168.1.44 eq 12345 any
access-list customer_access_in permit tcp any 192.168.1.44 eq 23456
access-list customer_access_in permit tcp 192.168.1.44 eq 23456 any
access-list customer_access_in permit tcp any 192.168.1.44 eq 34567
access-list customer_access_in permit tcp 192.168.1.44 eq 34567 any
access-list customer_access_in deny ip any any

With the customer DMZ ACL built it must be applied. Cisco ASA firewall ACL’s are not applied to an interface so to bind the customer ACL we type the following commands:

asa(config)#access-group customer_access_in in interface dmz1

The customer DMZ is should not be accessible from the Internet! The next article will focus on the service DMZ.

Until next time.........

Internet Network Filtering Part 3

After configuring filtering on the border router, it is time to perform filtering on the firewall. I believe in one rule for inbound Internet traffic to the firewall, only allow what is REQUIRED for the organizations business to function. For the purpose of this article the following services are required for the organization to function:

Widgets Website - 5.2.3.80 [tcp/80]
Widgets Extarnet Site - 5.2.3.143 [tcp/80 & tcp/443]
Widgets Online Database - 5.2.3.44[tcp/80 & tcp/443]
Widgets Email Server - 5.1.2.25 [tcp/25]
Widgets DNS - 5.1.2.53 [udp/53]
Widgets DNS - 5.1.2.54 [udp/53]
Widgets VPN - 5.1.2.123 [udp/500 & udp/4500]
Widgets SSL VPN - 5.1.2.43 [tcp/80 & tcp/443]
Widgets 3rd party Online Database Support - 5.2.3.250 [tcp/12345, tcp/23456 & tcp/34567]

Widgets perimeter network is protected with a Cisco ASA firewall. The firewall has an outside interface(outside), customer DMZ interface (DMZ1), service DMZ interface (DMZ2), and an inside interface(inside).

Because ASA's uses the concept of security levels each interface must be assigned one. For more information understanding the ASA security level concept please visit the Cisco website.

The IP address of servers in the DMZ use the RFC 1918 192.168.1.0/24 and 192.168.2.0/24 addresses. The use of these address require address translation to be performed. For more information on understanding and configuration a Cisco ASA for address translation please visit the Cisco website.

To configure access list for the required service we must use this command syntax:

access-list NAME action protocol source destination service

For detailed information for ASA access-list configuration please visit the Cisco website.

When configuring an ACL unless there is a legitimate business case I always take a default deny stance. When ordering an ACL I prefer to place entries that will hit more often at the top of the ACL.

Using the requirements listed above we will create an ACL named outside_access_in.

access-list outside_access_in permit udp any 5.1.2.53 eq 53
access-list outside_access_in permit udp any 5.1.2.54 eq 53
access-list outside_access_in permit tcp any 5.2.3.80 eq 80
access-list outside_access_in permit tcp any 5.2.3.44 eq 443
access-list outside_access_in permit tcp any 5.2.3.44 eq 80
access-list outside_access_in permit tcp any 5.2.3.143 eq 443
access-list outside_access_in permit tcp any 5.2.3.143 eq 80
access-list outside_access_in permit tcp any 5.1.2.25 eq 25
access-list outside_access_in permit udp any 5.1.2.123 eq 500
access-list outside_access_in permit udp any 5.1.2.123 eq 4500
access-list outside_access_in permit tcp any 5.1.2.43 eq 80
access-list outside_access_in permit tcp any 5.1.2.43 eq 443
access-list outside_access_in permit tcp any 5.2.3.250 eq 12345
access-list outside_access_in permit tcp any 5.2.3.250 eq 23456
access-list outside_access_in permit tcp any 5.2.3.250 eq 34567
access-list oustide_access_in deny ip any any

If a syslog server with sufficient disk space is available I prefer to log every Access Control Entry (ACE). After logging all my ACE's if there additional space on the syslog server I will add this last entry:

access-list outside_access_in deny ip any any log

When logging every hit on the ACL you will have a great understanding of your network. However this type of logging can be very storage expensive. If storage space becomes an issue, I always keep logging on my permits.

With the ACL built it must be applied to the outside interface of the ASA firewall. Unlike Cisco IOS it is not applied in the interface configuration. To bind the ACL to the outside interface we must enter in the following commands:

asa(config)#access-group outside_access_in in interface outside

With the ACL's and NAT setup (check out the Cisco website for more information) you must next permit traffic to the physical servers in the DMZ. The next article in this series will describe creating the ACL in the DMZ.

Internet Network Filtering Part 2

The first part of this series covered ingress filtering on your organizations Internet router. The goal of ingress filtering was to filter illegitimate traffic hitting your firewall. The next part of this series will cover egress filtering on the Internet router.

Egress filtering is filtering traffic leaving an organizations network. For a more in-depth explanation of egress filtering please read the paper I authored titled Performing Egress Filtering.

To review the organization Internet architecture consists of the following equipment.

One Cisco IOS router
Serial (s0/0) Interface connecting a T-1 to the Internet
Ethernet (e0/0) Interface connecting to firewall outside interface
One Cisco ASA firewall

The first step implementing egress filtering is to determine all Internet connections into your organizations network. Create a list with each location and all address ranges in that location. In some organizations their Internet connection may consist of multiple address ranges and/or ISPs.

For these articles the IP address range assigned by our fake ISP is 5.1.2.0/24 and 5.2.3.0/24. These ranges are currently not allocated and are for demonstration purposes only.

As with the ingress filter, extended ACL’s are used for the egress filters. To create the ACL type these commands in:

Inetrt01(config)#access-list 101 permit ip 5.1.2.0 0.0.0.255 any
Inetrt01(config)#access-list 101 permit ip 5.2.3.0 0.0.0.255 any
Inetrt01(config)#access-list 101 permit ip any 5.1.2.0 0.0.0.255
Inetrt01(config)#access-list 101 permit ip any 5.2.3.0 0.0.0.255
Inetrt01(config)#access-list 101 deny ip any any log

The first two permit access control entries (ACE) allow traffic sourced from our public address space to access the Internet through the Internet router. The next two permitted ACE’s allow traffic on the Internet to access resources in the IP ranges of 5.1.2.0/24 and 5.2.3.0/24. The final ACE is used to identify systems using source address other than the ones assigned to our organization. Any system that hits on the deny ACE must be investigated. The two likely causes of the hits could be mis-configured or infected with malware.

To maintain direction consistency, easier management, and better system performance the ACL will be applied inbound on the Ethernet interface. Use the following commands to apply the ACL to e0/0

Inetrtr01(config)#interface e0/0
Inetrtr01(config-if)#ip access-group 101 in

Two test must be performed to ensure the egress filtering is working correctly. First make a connection to a website such as www.google.com. Review the ACL and hits should appear on your source range and traffic bound for your source range. Next make a connection to www.google.com, this time send traffic with a spoofed IP address of 1.1.1.1. Review the ACL and hits should appear on the deny statement. If you see other hits on this ACE you should investigate these hits.

Congratulations you have now successfully implemented egress filtering on your edge router. Next time I will start on filtering on the firewall.

Internet Network Filtering part 1

The architecture for connecting organizations to the Internet typically comes in two flavors. The first architecture consist of a single device, usually a router but sometimes a firewall. The second architecture consist of multiple devices, typically a router and a firewall. No matter what architecture is chosen it is important the proper filtering is implemented. This is the first in a series discussing the implementation of proper filtering for an organizations Internet connection.

For this series of post the organization Internet architecture consist of the following equipment.

One Cisco IOS router
Serial (s0/0) Interface connecting a T-1 to the Internet
Ethernet (e0/0) Interface connecting to firewall outside interface
One Cisco ASA firewall

For a review of network ingress filtering review RFC 2827.

To properly implement ingress filtering begin by determining addresses currently allocated by IANA. To review the current address spaces allocated review the IANA website by following this link:

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

Review the list and note every prefix whose status is either unallocated or reserve. The unallocated status is for prefix's that IANA has not issued. The reserved status is for prefixes reserved for various reasons such as being used in RFC 1918 private address, multicast networks, research networks, etc. These prefixes have no legitimate reason for being routed on the Internet, and if seen entering the organization should be dropped.

With the list of prefix's to be dropped the next step is to build the access control list (ACL). Before building the ACL it is important to understand which traffic direction the list will be applied to.

Since the filtering decision is based only on address space simple IP ACL will be used. To create the ACL type these commands in:

inetrtr01(config)#access-list 10 deny 5.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 deny 10.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 deny 14.0.0.0 255.0.0.0
.
input omitted
.
inetrtr01(config)##access-list 10 deny 253.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 deny 254.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 deny 255.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 permit any any

The permit statement allows all traffic from valid prefix's to access the organization resources.

With the ACL built use the following commands to apply the ACL to the s0/0 interface

inetrtr01(config)#interface s0/0
inetrtr01(config-if)#ip access-group 10 in

Now test the ACL by sending traffic to the organization with spoofed source address of 10.0.0.1. After sending this traffic check the ACL and there should be hits on the line for 10.0.0.0/8 network. Once you are happy with the ACL save the configuration.

Congratulations you have now successfully implemented ingress filtering. Now all spoofed traffic from illegal sources will be dropped by the Internet router. Dropping this illegitimate traffic at the router reduces the workload on the firewall.

Next week I will cover egress filtering on the Internet router to ensure no spoofed traffic is leaving the organization.