Cisco network GNS3 virtual - Napier40001507/CSN11111/Lab7.pdf · Aim: The aim of this lab is to introduce the concepts of stateful firewalls, using Cisco Context-based Access Control

Network Security Stateful Firewalls & Edge Router Filtering – Rich Macfarlane 1

Lab 7: Firewalls – Stateful Firewalls and Edge Router Filtering

Rich Macfarlane

7.1 Details

Aim: The aim of this lab is to introduce the concepts of stateful firewalls, using Cisco Context-

based Access Control (CBAC) to configure perimeter routers. The lab also explores static

packet filtering as used for edge router Ingress and Egress filtering. Credentials and

network addressing for the lab will be supplied separately.

7.2 Activities

7.2.1 Create Virtual Topology

Connect to our vSphere virtual environment at vc2003.napier.ac.uk using a vSphere Client.

Navigate to the Module folder such as VMs & Templates>Production>CSN11111/8. You will be

assigned a group folder to work with which contains the 3 VMs needed for the lab (check Moodle for

the Groups and IP Addressing for each Group). Lab VMs: Windows7 VM running GNS3, a

Windows2003 VM and a Linux Ubuntu VM both running network services:

Lab Machine

LOCAL MACHINE

Windows 7 PC

Virtual Machines Cluster

INTERNET

146.176.x.x

Napier Network

VM – Win7-GNS3

Windows7

GNS3 virtual

Cisco network

VM – Linux

Ubuntu

VLAN 205192.168.X.0/24

Student Laptop

REMOTE

MACHINE

VM – Win2003VLAN 206192.168.Y.0/24

Win2003

vc2003.napier.ac.uk

146.176.x.x

Web serverFTP serverTelnet server

Web serverFTP serverTelnet server

Power on your Windows7-GNS3 VM, open a console window, login to the Windows7-GNS3 VM, and

run the GNS3 network simulator AS ADMINISTRATOR


You can create a new project for Lab7, or a preconfigured starting project should be in the Projects

folder. If you wish to start with that just click Recent Projects button and select lab7_start, then

save as a project called lab7 or suchlike (save as, before you power on routers).

The topology, shown below, mimics two organisations connected via the untrusted Internet (the

serial link). The perimeter routers will be configured to explore the provision of security for the

organisations, introducing stateful firewalling and static filtering for good practise Ingress/Egress

perimeter filtering.

Starting Topology

You will be assigned two networks to attach the hosts to via Moodle: 192.168.X.0/24 and 192.168.Y.0/24 And a network for the internal network between the routers: 10.1.Z.0/30

THE CORRECT NETWORKS MUST BE USED BY EACH STUDENT AS WE ARE SHARING VIRTUAL NETWORKS.

PLEASE ONLY USE GROUP VMs AND NETWORK IP ADDRESSES ASSIGNED TO YOUR GROUP.

PLEASE DO NOT USE YOUR OWN IP ADDRESSES OR THE LAB DEMO ADDRESSES IN THIS DOCUMENT!

Note down the networks, and annotate your own network diagram in GNS/on paper:

X network: Y Network:

These must be used to configure the 2 interfaces of the GNS3 gateway routers (.254), and the 2 interfaces of the Linux and Windows VMs (.10), and the internal serial network between the routers.

7.2.2 GNS3 - Configure the Routers

On Win7-GNS3 VM, if not using the preconfigured starting project, create the topology.

On Win7-GNS3 VM, start the routers and run the console terminals. Then run the host Windows

machine’s task manager to check CPU usage. Keeping it running just behind GNS3 is good practise,

to monitor CPU usage.


The CPU should reduce to well below 100% after within a few minutes. If the vSphere VM suspends

or is left idle for long periods a reboot of GNS3 may be needed to control the CPU use. If working on

your own host machine or the CPU never comes down from 100% you may need to recalculate the

idlepc value for the 7200 router type, until you find a value which reduces the CPU usage.

Router Interfaces

Once the GNS3 topology is created, configure the router interfaces (the configurations in Appendix A

can be can be used as a shortcut, or guide, to configuring any interfaces and rip routing not

configured yet on the routers). Change any default X, Y and Z network configurations to the

networks you have been assigned.

Remember to enable them with the no shut command.

Check the state of the interfaces on the routers with the show ip interface brief command,

as shown below.

Routing

Configure RIP if not already preconfigured, starting the RIP routing protocol on both routers and

advertise all connected networks, with the router rip and network 0.0.0.0 commands.

Check the routing table using the command show ip route. The connected and remote

networks should have routes (showing your X, Y and Z networks).

Save your Lab project regularly! Save the router configuration using copy run start, and

File>Save As and check the configuration file have been created, as detailed in previous labs.


7.2.3 Configure the Hosts

Power on your Windows2003 VM and Linux Ubuntu VM. Configure the 192.168.X.10 and

192.168.Y.10 network IP Addresses on the Ubuntu and Windows2003 systems respectively, and set

the Default Gateways to the Router interface addresses at X.254 and Y.254 the appropriate hosts.

To configure the Linux system for IP Address and Default Gateway:

http://www.howtogeek.com/118337/stupid-geek-tricks-change-your-ip-address-from-the-

command-line-in-linux/

The following document has a section on setting the Windows IP and default gateway:

www.dcs.napier.ac.uk/~cs342/CSN11111/GNSAddVM.pdf

(Section: Windows-Setting Static IP Address and Default Gateway)

7.2.4 Test Network Connectivity

From each router, check connectivity to each local router interface, and each of the other routers

interfaces, and then attached hosts, as shown below. (work form the local interfaces, out hop by

hop) From R2:

Q. Where the direct pings successful?

If not, troubleshoot the configuration, until connectivity is achieved.

To test connectivity from the four networks attached to the routers, such as the 192.168.X and

192.168.30 networks first check the routing table on each router using the show ip route command.

This should show routes to all connected networks (C), and remote routes advertised by other

routers (R). The R2 routing table should look something like the below.



http://www.dcs.napier.ac.uk/~cs342/CSN11111/GNSAddVM.pdf


Use the extended ping command to check connectivity to the stub networks with only switches. For

example, from the R2 router:

R2# ping

Protocol [ip]:

Target IP address: 192.168.15.254

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 192.168.30.254

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.15.254, timeout is 2 seconds:

Packet sent with a source address of 192.168.30.254

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/116/192 ms

R2#

Check connectivity from all the networks.

Q. Where the extended pings successful?

If not, troubleshoot the configuration, until connectivity is achieved.

From the two VM’s connectivity can be checked using the ping tool from cmd window/terminal

windows.

In LINUX either limit the pings with –c3 or CTRL+C to stop the ping. DO NOT LEAVE PINGS

RUNNING AS WE ARE WORKING ON SHARED VIRTUAL NETWORKS!

Again start by checking the local interface is up and then work across the network, interface by

interface:


Q. Can the Windows VM ping the Linux VM?

Q. Can the Linux VM ping the Windows VM?

Q. Can the Routers ping the Windows VM?

Q. Can the Routers ping the Linux VM?

Depending on the Windows VM you are using, the host firewall may block the incoming ICMP traffic

coming from the Linux machine or the routers. Switch off the firewall if necessary and check

connectivity from Linux VM and routers again.

7.2.5 Services - Test the Linux VM Web Server

From the Linux system, check the network services running, using the netstat command. Try netstat

–h to check the options for the command. –t is used below to only show TCP services. Try the –u flag

to see UDP services, and the -n flag to check the port numbers of the services running.

Questions:


Q. What protocol/port number combination is the web www service running on?

Q. What protocol/port number combination is the Telnet service running on?

Q. What protocol/port number combination is the FTP service running on?

From the Linux VM, check the local web server is running correctly, using the web browser:

From the Windows VM, use a web browser to test this web server can be connected to across the

network, as shown below.

Monitor Traffic

On Ubuntu, open a 2nd terminal window and resize to the width to width of the window. We can run

the tcpdump packet sniffer to monitor packets passing through the ethernet interface.

Try refreshing the web page, and you should see some traffic:

Keep the tcpdump trace window open to review traffic throughout the lab.


7.2.6 Services - Test the Linux VM Telnet server

From the Windows VM, connect to the Telnet service running on the Linux VM, using the Windows

telnet client from the command window, or the Putty GUI client (should be on the Windows VM

desktop). You can also telnet from the R1 router if you prefer.

Log in with the Linux VM napier user’s credentials.

Once logged in you should have command line access to the Linux system. Use commands

ifconfig pwd etc to check you are logged into the Linux VM:

7.2.7 Services - Test the Linux VM FTP Server

From the Windows VM, connect to the FTP Server from, via a web browser using the URL

ftp://192.168.X.10 Log in with the napier user’s credentials.

You should get something like the following in your browser window: (it may take some time to

respond - move on to next section while its loading)


7.2.8 Scan the R1 Perimeter Router for Services

Using the nmap network scanning tool, attackers can map networks and identify vulnerabilities on target systems. Before we create a firewall on the R1 router, use nmap to scan for network services running on the router, by running a port scan against the routers outside interface. A typical scan would be a Port Scan which is used to determine the network services which are running on a specific target machine by sending packets to each port and reporting the replies, as shown below.

Eve

Scanning …

Port 21 - closed

Port 22 - closed

Port 23 – closed

…

Port 80 - open

…

Port 65,000

TCP SYN

TCP SYN ACK

The nmap users manual is available at:

http://nmap.org/book/man.html

From the Linux VM open a console window and use nmap -h | less to check the help to get an idea of the variety of options.

Then run a default port scan against the router, as shown below.

Q. What services are running on the router?

Q. How many ports did nmap scan?

On the R1 Router, from a console window, start the routers web server with:

R2# config t

Enter configuration commands, one per line. End with CNTL/Z.

R2(config)# ip http server

R2(config)#

From the Linux VM run the nmap port scan against the router again.

Q. What services are running on the router now?

http://nmap.org/book/man.html


From the Linux VM use nmap to to run a port scan against the Windows VM, to determine what public network services it is running.

Q. List some of the well known services which are running on the Windows VM?

As there is no perimeter firewalling, and the Windows host firewall is off, the port scan should produce good results from the 1000 ports scanned, as shown below. In this way an intruder can map possible target systems, and determine if they might have vulnerable services to exploit.

If the Windows firewall was on, the scan packets would have been blocked. (you can try turning on the firewall and scanning again if you are not convinced)


7.2.9 R1 Closed Perimeter Firewall using Cisco ACL Packet Filtering

Behind the R1 Router, we switched the XP host stateful Windows firewall off, so the system has no

protection. As we have seen from the nmap scans, the R1 edge router is also vulnerable to attack.

We can protect the network by creating a perimeter firewall on the R1 router. Static packet filtering

ACLs could be used.

Block All Ingress Traffic from the Untrusted Outside Network

On R1, configure an ACL to block all traffic originating from the outside network. This creates a

closed firewall. A closed security stance is generally best practice if possible, only allowing specific

traffic and denying everything else.

R1(config)# ip access-list extended OUT-IN

Allow RIP routing traffic.

R1(config-ext-nacl)# permit udp any any eq rip

Allow ICMP return traffic to the router so it can test connectivity.

R1(config-ext-nacl)# permit icmp any host 10.1.Z.1 echo-reply

Explicit deny all other traffic, and to log blocked packets.

R1(config-ext-nacl)# deny ip any any log

R1(config-ext-nacl)# exit

Check your ACL rules with:

R1# show access-lists

If the ACL is correct, apply the firewall rules to the R1 edge routers interface for inbound traffic.

R1(config)# interface s1/0

R1(config-if)# ip access-group OUT-IN in

R1(config-if)# exit


S1/0

R1(config)# interface S1/0

R1(config-if)# ip access-group OUT-IN

Trusted, Internal

NetworkUntrusted

Internet

Check the ACL was created, and applied to the interface correctly, by viewing R1’s running configuration.

Q. Has the ACL been created correctly, and applied to the correct interface?

Q. Which type of firewalling is this? Static Packet filtering / Stateful / Application Inspection

Q. Which layer are we filtering at for the rule on rip traffic?

Test the R1 Closed Perimeter Firewall

Have the console window for R1 visible for the testing, as firewall logging is sent to the console window by default.

From R1, ping R2, then ping the Linux VM server.

Q. Was the ping successful?

Q. Did R1 block any packets, or did the console display any firewall log information?

Q. Why?

From R2, ping R1, then ping the Windows VM from the Linux VM server.

ping c-2 192.168.Y.10

Q. Were the pings successful?

Q. Did R1 console display any log information? If so, detail the ip addresses and protocol:

In the R1 router console you should see the log of the packets being dropped, as shown below:


From Windows VM ping the Linux VM server.

Q. Were the pings successful?

Q. Did R1 console display any log information? Which traffic is blocked? (IP Addresses, protocol,

port?)

Test the Linux Web Server

From the Windows VM, use a web browser to connect to the Apache web server running on the

Linux VM Server (Use CTRL+F5 to refresh the web page from the server, and not just the local

cache).

Q. Did R1 console display any log information? Which traffic is blocked? (IP Addresses, protocol,

ports)

Test the Linux Telnet server

From the Windows VM use the web browser to try and connect to the FTP server as before.

Test the Linux Telnet server

From the Windows VM, Telnet to the Linux VM, using Windows telnet client or Putty – logging in

with the napier user credentials.

Q. Was the Web, FTP and Telnet traffic successful?

Q. Did R1 console display any log information? If so, detail the IP Addresses, protocols and port

numbers blocked:

Q. Why is this traffic being blocked?


The return traffic is being blocked by the ingress filtering on R1. The R1 console should show the

firewall log, similar to below.

To allow the return traffic needed for the various network services, we would need to implement all

the return firewall rules in the OUT-IN firewall ruleset. This can lead to large, complex, and insecure

rulesets.

Q. For the Web traffic what rule might be used? (such as for all client ports > 1024)

Q. Why is this type of rule not ideal?

Instead of creating these types of rules, stateful firewalls can be used keep track of connections

originated in the trusted inside network, and dynamically create return rules as necessary. Cisco

routers provide stateful inspection for individual protocols through the CBAC commands.

7.2.10 Stateful Perimeter Firewall on R1 Router using Cisco Context-Based Access Control (CBAC)

To enhance the basic closed firewall, a stateful firewall can be created on the router, using Cisco

CBAC. We can configure a simple stateful firewall, similar in functionality to the Windows personal

firewall, on the outside interface of the R1 perimeter router.

A CBAC stateful inspection rule can be created for services originating in the trusted network. This

will allow the router to cache connection information for this egress traffic, and allow return traffic

automatically. Create a rule called IN-OUT-IN for ICMP and Web traffic:

R1(config)# ip inspect name IN-OUT-IN icmp

R1(config)# ip inspect name IN-OUT-IN http

Apply the Rule to the R1 edge routers internal interface for outbound traffic (traffic originating in the trusted inside network which the Windows VM is in).

R1(config)# interface fa0/1

R1(config-if)# ip inspect IN-OUT-IN in

R1(config-if)# end


S1/0

Router(config)# interface fa0/1

Router(config-if)# ip inspect IN-OUT-IN in

Trusted, Internal

Network Untrusted

Internetfa0/1

R1

View the current connections being cached by CBAC (the firewall state table):

R1# show ip inspect sessions

Q. Are any details of any connection states being stored?

Test ICMP Traffic

From Windows VM, ping the Linux VM server.


Q. Did R1 console display any log information?

The ICMP return traffic should now be allowed back through the stateful firewall

View the current connections being cached by CBAC (the firewall state table):

R1# show ip inspect sessions

Q. Are any details of any connection states being stored?

The CBAC state table should show the ICMP entry:

From Linux VM server send some ICMP packets to the Windows VM using ping.


Q. Did R1 console display any log information?

Q. Why is this?


You should find that the stateful firewall allows the ICMP return traffic if the ping was initiated from inside the trusted network (from the Windows VM), but not if the traffic originated from outside (from the Linux VM).

The firewall should log the firewall rule matches to the console, such as the following, and that it was filtered.

Test the Linux Web Server

From the Windows VM, use a web browser to connect to the Apache web server running on the

Linux VM Server (CTRL+F5 to refresh the page web from the server).

Q. Can we now access the Linux VM Web server from the Windows VM?

Q. What is allowing this traffic to flow?

Check the current connections being cached by the CBAC statefull firewall:

Q. Are any the states of any connections being stored?

Q. What are the source and destination IP Addresses and port numbers, and protocol?

Q. Which would change if we access the web server again?

Test your theory

The Web traffic connection should be cached, and the client (browser) port no should change.

Test the FTP Server

Use the browser on the Windows VM to try and connect to the FTP server as before.


Test the Telnet server

From the Windows VM, Telnet to the Linux VM, using Windows telnet client or Putty.

Q. Was the FTP or Telnet traffic successful?

Q. Why?

Add FTP and Telnet to the Stateful Firewall

The stateful firewall is not configured for these protocols, so should still be blocking the return

traffic.

The ip inspect interfaces command can be used to check which stateful rules are

implemented on which interfaces, as shown below.

Create your own FTP and Telnet CBAC Stateful Inspection Rules for outgoing traffic .

Q. What are the stateful inspection rules?

To apply them, first remove the CBAC stateful firewall from the interface, and then add it to the

interface again.

R1(config-if)# no ip inspect IN-OUT-IN in

R1(config-if)# ip inspect IN-OUT-IN in

Test the Telnet Server

Use Putty to connect to the Telnet server on the Linux VM.

Q. Was the Telnet traffic successful?

Check the current connections being cached by CBAC:


Q. Are there states of any connections being stored?

Q. What are the source and destination IP Addresses and port numbers?

Test the FTP server

From the Windows VM, connect to the FTP server using a browser.

Q. Was the FTP and Telnet traffic successful?

With the telnet connection (or on the Linux system) you can use netstat –ant to check the TCP

services/connections to the Linux box:

Q. What is different about the FTP connection(s), from the Telnet session?

Q. Why is this?

On the router, check the current connections being cached by CBAC.

Q. Are there any connections being stored?

Q. What are the source and destination IP Addresses and port numbers?

Q. As the filtering is looking into the FTP application payload to find the port numbers of the data

connection, which type of firewalling is this?

Static Packet filtering / Stateful / Application Inspection


Scan the R1 Perimeter Router for Services

From the Linux VM open a console window and run nmap against the R1 router again, then against the Windows VM.

Q. Is nmap able to report what public services are running on the router?

Q. Is nmap able to report what public services are running on the Windows VM?

The R1 perimeter firewall should now be blocking the nmap scan packets, as shown below.

Q. From the linux tcpdump window, which type of scan packets are being sent? Protocol/flag?

Nmap is only getting as far as sending host discovery packets – in this case TCP SYN to 80 and 443,

and as hosts seem down does not scan for open ports.

Review the Stateful Firewall Configuration

Check the current connections being cached by CBAC again.

Q. Are there any connections being stored?

Q. Are all the recent connections still being stored?

Q. Why not?

Use the show ip inspect config command to check the current configuration.

Q. What is the time out in seconds, for standard TCP sessions?


Q. What is the current threshold for half open connections?

Q. What problems could this cause for the firewall?

The CBAC stateful firewall is configurable, and has time outs for connections being stored,

thresholds for open, and half open connections. This can be configured to help with management of

the state cache, and mitigate against DoS attacks.

7.2.11 R2 Perimeter Egress/Ingress Static Packet Filtering

Internet Service Providers (ISP) should implement RFC2827 filtering on their upstream devices, to

help mitigate attacks, including DoS and DDoS. This does not always happen, and it is good practice

to implement this on the perimeter firewall or edge router (located outside the perimeter firewall)

on ingress and egress traffic. RFC2827 filtering should block traffic with invalid source addresses

coming from the untrusted outside network, as well as blocking traffic leaving the inside trusted

network with invalid source addresses.

Ingress Filtering

Invalid source addresses in inbound traffic would include: (not an exhaustive list)

RFC1918 – spoofed private addresses, such as 10.0.0.0/8, 192.168.0.0/16 etc

RFC 2365 – spoofed multicast addresses, such as 239.0.0.0/8

IANA reserved addresses – such as 0.0.0.0/8, 127.0.0.0/8 etc

Q. Can you think of other invalid source addresses should be blocked, inbound?

Traffic with source addresses of the inside network, or destination addresses of the outside network

should also be blocked.


Egress Filtering

Similarly, invalid source addresses in outbound traffic include: (not an exhaustive list)

Source address of the outside network.

Destination address of the inside network.

RFC1918 – spoofed private addresses, such as 10.0.0.0/8, 192.168.0.0/16 etc

RFC 2365 – spoofed multicast addresses, such as 239.0.0.0/8

IANA reserved addresses – such as 0.0.0.0/8, 127.0.0.0/8 etc

Create R2 Static Packet Filtering Firewall for Ingress Traffic Filtering

Configure an ACL to block all invalid traffic originating from the outside network. This creates a

closed firewall on R2.

R2(config)#

R2(config)# ip access-list extended INGRESS

Allow RIP routing traffic.

R2(config-ext-nacl)# permit udp any any eq rip

Allow ICMP return traffic to the router so it can test connectivity.

R2(config-ext-nacl)# permit icmp any host 10.1.Z.2 echo-reply

RFC2827 Filtering - deny traffic with invalid source addresses of the inside networks, and to log

blocked packets.

R2(config-ext-nacl)# deny ip 192.168.X.0 0.0.0.255 any log

Q. What other ACL would be needed for the other inside network?

Add this ACL

RFC1918 Filtering - deny traffic with invalid source addresses of Private network addresses and Local

loopback addresses, and to log blocked packets.

R2(config-ext-nacl)# deny ip 172.16.0.0 0.15.255.255 any log

R2(config-ext-nacl)# deny ip 127.0.0.0 0.255.255.255 any log

Q. Suggest other ACLs for Private networks (RFC1918), and for the other invalid source addresses?

(DO NOT add any firewall rules to block 10.0.x.x, or 192.168.x.x, as these are part of our lab

addressing scheme)

Explicit deny all other traffic, and to log blocked packets.

R2(config-ext-nacl)# deny ip any any log


R2(config-ext-nacl)# end

R2#

Check the ACL was created correctly the show access-lists command

Before you apply the INGRESS firewall ruleset to R2, make sure you can ping from R1 to R2, from R1 to Linux VM, and can access the web server on the Linux VM from the Windows VM.

Apply the ACL to the R2 routers outside interface for inbound traffic.


R2(config-if)# ip access-group INGRESS in

R2(config-if)# end

S1/0


R1(config-if)# ip access-group INGRESS

Trusted, Internal

NetworkUntrusted

Internet

Check the ACL was created, and apply correctly to the interface correctly, by viewing R2’s running configuration.

Test the Closed Firewall

Have the console window for R2 visible for the testing, as the log is being sent to the console window (standard output ).

From R2, ping R1, then ping the Linux VM server from R1.


Q. Did R1 console display any log information? Which protocols?

In the R2 router console you should see the log of the packets being dropped.

Test the Ingress RFC Filtering

Change the R1 f0/0 interface to have the IP Address of the 192.168.30.254 ip address, and perform

extended ping to the Linux VM server.

Q. Does the ping to the Linux server succeed?

Q. Where is it being blocked?


The traffic should be blocked by the RFC2827 filtering rule, as the source address is that of an

internal network.

Test the Linux Web Server from Windows VM

From the Windows VM, use a web browser to connect to the web server running on the Linux VM

Server (CTRL+F5 to refresh the cache).


From the Windows VM, Telnet to the Linux VM, using Putty – logging in with the napier user

credentials.

Q. Can the Windows VM get Web traffic, or Telnet traffic, from the Linux Server?

Q. Where is it being blocked? Which rule?

The R2 router should now be blocking the traffic with its INGRESS ruleset, as shown below.

The network behind R2 provides the public web server, so rules need to be added to allow web

traffic through the firewall.

Good practice is to remove the current ACL from the interface, then remove the ACL ruleset, then

recreate the entire ruleset from an offline text file (rather than attempting to edit/delte/insert

individual rules).

Copy the ACL rules to a text file, and remove the ACL from the interface.


R2(config-if)# no ip access-group INGRESS in

Remove the INGRESS ACL from the router. R2(config)# no ip access-list extended INGRESS

Check it has been removed using show access-lists

Add a new rule to the txt file to allow web traffic from the outside network to the Web server

machine only.

permit tcp any host 192.168.X.10 eq 80

Create a new INGRESS ACL ruleset from the text file, either pasting one line at a time, or all can be

pasted at once, from the correct command mode.


Review the ACL checking the ruleset was created correctly, with the show access-lists command.

Apply the ACL to the R2 routers for inbound traffic.

Review R2’s running configuration, checking that the ACL was applied to the interface correctly.

Test the Telnet and Web servers

From the Windows VM, Telnet to the Linux VM, using a telnet client.

Test the Linux Web Server from Windows VM

From the Windows VM, use a web browser to connect to the web server running on the Linux VM

Server (CTRL+F5 to refresh the cache).

Q. Can the Windows VM connect to the Web server on the Linux box?

Q. What is allowing this?

Q. Can the Windows VM connect to the Telnet server on the Linux box?

Q. Where is it being blocked? Which rule?

The Telnet traffic should still be blocked at the R2 firewall with the drop any, and the Web traffic

passed with our specific rule.

You should be able to connect to the Linux VM Web server as shown below, but not to any other

services on the server.

Similar to our change for Web server access, change the R2 INGRESS ACL ruleset to allow Telnet

access to the Linux Server only.


Q. What is the new ACL rule which has been added?


From the Windows VM, Telnet to the Linux VM, using Putty – logging in with the napier user

credentials.

Q. Was the FTP or Telnet traffic successful?

Create Firewall ruleset on R2 for EgressTraffic Filtering

Configure an ACL to block all invalid traffic originating from the inside network.

R1(config)#

R1(config)# ip access-list extended EGRESS

RFC2827 Filtering – Create explicit deny ACL for traffic with invalid source addresses of the outside

network (10.1.0.0/16), and to log blocked packets.

Q. What is the ACL?

Add this rule to the EGRESS ACL

RFC2827 Filtering – Create explicit deny ACLs for traffic with invalid destination addresses of the

inside networks (192.168.X.0/24 and 192.168.30.0/24), and to log blocked packets.

Q. What are the ACLs?

Add these Rules to EGRESS ACL

RFC1918 Filtering – Create explicit deny ACL for traffic with invalid source address of the local

loopback (127.0.0.0/8), and to log blocked packets.

Q. What are the ACLs?

Add these Rules to EGRESS ACL

Q. What other RFC1918 ACLs might be needed?

Configure an ACL to allow all other traffic originating from the inside network out.


R1(config-ext-nacl)# permit ip any any

R1(config-ext-nacl)# end

R1#

Apply the ACL to the R2 routers inside interface for outbound traffic. R2(config)# interface fa0/1

R2(config-if)# ip access-group EGRESS in

R2(config-if)# exit

Check the ACL was created, and applied to the interface correctly, by viewing R2’s running configuration, and using the show access-lists command.

7.2.12 (Optional Challenge) Create R2 Stateful Firewall

Create CBAC Stateful Inspection rules for the R2 router allowing the Linux VM access out to the Windows VM web server and back.

A firewall rule would also need to be added to the R1 Ingress ACL to allow access to the web server.

7.3 Appendix A – Sample Starting configurations

R1 !

interface FastEthernet0/0

ip address 192.168.15.254 255.255.255.0

duplex auto

speed auto

!


ip address 192.168.Y.254 255.255.255.0

duplex auto

speed auto

!

interface Serial1/0

ip address 10.1.Z.1 255.255.255.252

serial restart-delay 0

!

!

router rip

network 0.0.0.0

!


End

R2 !


ip address 192.168.30.254 255.255.255.0

duplex auto

speed auto

!


ip address 192.168.X.254 255.255.255.0

duplex auto

speed auto

!

interface Serial1/0

ip address 10.1.Z.2 255.255.255.252


!

!

router rip

network 0.0.0.0

!

end

7.4 Appendix B – Sample Stateful Firewall and Edge Router Filtering configurations

R1 !

upgrade fpd auto

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname R1

!

boot-start-marker

boot-end-marker

!

logging message-counter syslog

!

no aaa new-model

ip source-route

ip cef

!

!

ip inspect name IN-OUT-IN icmp

ip inspect name IN-OUT-IN http

ip inspect name IN-OUT-IN ftp

ip inspect name IN-OUT-IN telnet

no ipv6 cef

!

multilink bundle-name authenticated

!

!

archive

log config

hidekeys

!

!



ip address 192.168.30.254 255.255.255.0

duplex auto

speed auto

!


ip address 192.168.Y.254 255.255.255.0

ip inspect IN-OUT-IN out

duplex auto

speed auto

!

interface Serial1/0

ip address 10.1.Z.1 255.255.255.252

ip access-group OUT-IN in


!

!

router rip

network 0.0.0.0

!

ip forward-protocol nd

ip http server

no ip http secure-server

!

!

ip access-list extended OUT-IN

permit udp any any eq rip

permit icmp any host 10.1.Z.1 echo-reply

deny ip any any log

!

control-plane

!

mgcp fax t38 ecm

mgcp behavior g729-variants static-pt

!

!

gatekeeper

shutdown

!

!

line con 0

stopbits 1

line aux 0

stopbits 1

line vty 0 4

login

!

end

R2 !

upgrade fpd auto

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname R2

!

boot-start-marker

boot-end-marker

!

logging message-counter syslog

!

no aaa new-model

ip source-route

ip cef

!


no ipv6 cef

!

multilink bundle-name authenticated

!

!

archive

log config

hidekeys

!

!


ip address 192.168.30.254 255.255.255.0

duplex auto

speed auto

!


ip address 192.168.X.254 255.255.255.0

ip access-group EGRESS in

duplex auto

speed auto

!

interface Serial1/0

ip address 10.1.Z.2 255.255.255.252

ip access-group INGRESS in


!

!

router rip

network 0.0.0.0

!

ip forward-protocol nd

ip http server

no ip http secure-server

ip http path flash:

!

!

ip access-list extended EGRESS

deny ip 10.1.0.0 0.0.255.255 any log

deny ip any 192.168.X.0 0.0.0.255 log

deny ip any 192.168.30.0 0.0.0.255 log

deny ip 127.0.0.0 0.255.255.255 any log

permit ip any any

ip access-list extended INGRESS

permit tcp any host 192.168.X.10 eq www

permit udp any any eq rip

permit icmp any host 10.1.Z.2 echo-reply

deny ip 192.168.X.0 0.0.0.255 any log

deny ip 192.168.30.0 0.0.0.255 any log

deny ip 172.16.0.0 0.15.255.255 any log

deny ip 127.0.0.0 0.255.255.255 any log

deny ip any any log

!

!

control-plane

!

!

!

end

Documents

Cisco network GNS3 virtual - Napier40001507/CSN11111/Lab7.pdf · Aim: The aim of this lab is to introduce the concepts of stateful firewalls, using Cisco Context-based Access Control