CS6250 编程代写、代做 python 语言程序

项目预算：开发周期：发布时间：要求地区：

OMSCS/OMSCY GEORGIA TECH

SDN Firewall with POX

Summer 2024

Copyright 2024

Georgia Institute of Technology

All rights reserved.

This is solely to be used for current CS6250 students. Any public posting of the material contained within is

strictly forbidden by the Honor code.

1

SDN Firewall with POX

Table of Contents

SDN Firewall with POX Project .................................................................................................................... 2

Part 0: Project References ....................................................................................................................... 2

Part 1: Files Layout .................................................................................................................................. 2

Part 2: Before You Begin ......................................................................................................................... 4

Part 3: Review of Mininet ........................................................................................................................ 4

Part 4: Wireshark ..................................................................................................................................... 6

Part 5: SDN Firewall Implementation Details .......................................................................................... 8

Part 5a: Specifications of configure.pol .............................................................................................. 8

Part 5b: Implementing the Firewall in Code ..................................................................................... 11

Part 6: Configuration Rules .................................................................................................................. 12

What to Turn In ......................................................................................................................................... 14

What you can and cannot share ............................................................................................................... 15

Appendix A: How to Test Host Connectivity ............................................................................................ 16

Part A: How to Test Manually ........................................................................................................... 16

Part B: Automated Testing Suite ...................................................................................................... 19

Appendix B: Troubleshooting Information .............................................................................................. 21

General Coding Issues........................................................................................................................ 21

Firewall Implementation (sdn-firewall.py) Errors and Issues ........................................................... 21

Mininet/Topology Issues ................................................................................................................... 21

Appendix C: POX API Excerpt ................................................................................................................... 22

Flow Modification Object ...................................................................................................................... 22

Match Structure .................................................................................................................................... 22

OpenFlow Actions ................................................................................................................................. 24

Example: Sending a FlowMod Object ................................................................................................... 25

2

SDN Firewall with POX Project

In this project, you will use Software Defined Networking (SDN) principles to create a configurable firewall using

an OpenFlow enabled Switch. The Software Defined Networking (OpenFlow) functionality allows you to

programmatically control the flow of traffic on the network.

This project has three phrases as follows:

1. Mininet Tutorial – This phase is a brief overview of Mininet. There are no deliverables for this phase and

may be skipped, especially if you completed the Optional Simulating Networks project (Project 0).

2. Wireshark Tutorial – This phase is a brief introduction to packet capture using Wireshark/tshark. You

will examine the packet format for various traffic to learn of the different header values used in Phase 3.

There is a deliverable of a simple packet capture file.

3. SDN Firewall – This phase involves completing code to build a simple traffic blocking firewall using

OpenFlow with the POX Controller based on rules passed to it from a configuration file. In addition, you

will create a set of rules to test the firewall implementation.

Part 0: Project References

You will find the following resources useful in completing this project. It is recommended that you review these

resources before starting the project.

IP Header Format - https://erg.abdn.ac.uk/users/gorry/course/inet-pages/ip-packet.html

TCP Packet Header Format - https://en.wikipedia.org/wiki/Transmission_Control_Protocol

UDP Packet Header Format - https://en.wikipedia.org/wiki/User_Datagram_Protocol

The ICMP Protocol - https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

IP Protocols - https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers

TCP and UDP Service and Port References -

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

Wireshark - https://www.wireshark.org/docs/wsug_html/

CIDR Calculator - https://account.arin.net/public/cidrCalculator

CIDR - https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing

Part 1: Files Layout

Unzip the SDNFirewall-Summer2024zip file into your Virtual Machine. Do this by running the following

command:

unzip SDNFirewall-Summer2024.zip

3

This will extract the files for this project into a directory named SDNFirewall at your current path (it is

recommended that your use the mininet root directory to aid in troubleshooting ( cd ~ ). The following files will

be extracted:

cleanup.sh – this file called by using following command line: ./cleanup.sh

This file will clean up the Mininet Environment and kill all zombie Python and POX processes.

sdn-topology.py – this file creates the Mininet topology used in this assignment. This is like what you

created in the Simulating Networks project. When evaluating your code against the ruleset specified in

this project, do not change it. However, you are encouraged to make your own topologies (and rules) to

test the firewall. Look at the start-topology.sh file to see how to start a different topology.

ws-topology.py – this file is substantially like sdn-topology, but it does not call the POX Controller. You

will use this during the Wireshark exercise.

setup-firewall.py – this file sets up the frameworks used in this project. DO NOT MODIFY THIS FILE. This

file will create the appropriate POX framework and then integrates the rules implemented in sdn-

firewall.py into the OpenFlow engine. It will also read in the values from the configure.pol file and

validate that the entries are valid. If you make changes to this file, the autograder will likely have issues

with your final code as the autograder uses the unaltered distribution version of this file.

start-firewall.sh – this is the shell script that starts the firewall. This file must be started before the

topology is started. It will copy files to the appropriate directory and then start the POX OpenFlow

controller. This file is called by using following command line: ./start-firewall.sh

start-topology.sh – this is the shell script that starts the Mininet topology used in the assignment. All it

does is call the sdn-topology.py file with superuser permissions. This file is called by using following

command line: ./start-topology.sh

test-client.py – this is a python test client program used to test your firewall. This file is called using the

following command line: python test-client.py PROTO SERVERIP PORT SOURCEPORT where PROTO is

either T for TCP, U for UDP, or G for GRE, SERVERIP is the IP address of the server (destination), PORT is

the destination port, and optionally SOURCEPORT allows you to configure the source port that you are

using. Example: python test-client.py T 10.0.1.1 80

test-server.py – this is a python test server program used to test your firewall. This file is called using the

following command line: python test-server.py PROTO SERVERIP PORT where PROTO is either T for

TCP, U for UDP, G for GRE, SERVERIP is the IP address of the server (the server you are running this script

on), and PORT is the service port.

Example: python test-server.py T 10.0.1.1 80

test-suite – This is a student developed test script that was developed in 2021 that can be used to test

your implementation AFTER YOU FINISH BOTH THE IMPLEMENTATION FILES. The test cases in the main

folder will be used to evaluate your implementations for the first run. An alternate configuration and

topology will also be used to evaluate your implementations. This will be similar to, but not identical to

what is found in the extra sub-folder. See Appendix A for information on how to use the test suite.

Project Deliverables

configure.pol - this file is where you will supply the configuration to the firewall that specifies the traffic

that should either be blocked or allowed (override blocks). The format of this file will be specified later

in this document. This file is one of the deliverables that must be included in your ZIP submission to

Canvas.

4

? sdn-firewall.py –This file implements the firewall using POX and OpenFlow functions. It receives a copy

of the contents of the configure.pol file as a python list containing a dictionary for each rule and you will

need to implement the code necessary to process these items into POX policies to create the firewall.

This file is one of the deliverables that must be included in your ZIP submission to Canvas.

packetcapture.pcap – This will be the packet capture completed in Part 4. This file is one of the

deliverables that must be included in your ZIP submission to Canvas.

Part 2: Before You Begin

This project assumes basic knowledge about IP and TCP/UDP Protocols. It is highly encouraged that you review

the following items before starting. This will help you in understanding the contents of IP packet headers and

what you may need to match.

o What is the IP (Internet Protocol)? What are the different types of Network Layer protocols?

o Review TCP and UDP? How does TCP or UDP differ from IP?

o Examine the packet header for a generic IP protocol entry. Contrast that with the packet header for a

TCP packet, and for a UDP packet. What are the differences? What does each field mean?

o What constitutes a TCP Connection? How does this contrast with a UDP connection.

o A special IP protocol is ICMP. Why is ICMP important? What behavior happens when you do an ICMP

Ping? If you block an ICMP response, what would you expect to see?

o If you block a host from ICMP, will you be able to send TCP/UDP traffic to it?

o Can you explain what happens if you get a ICMP Destination Unreachable response?

o What is CIDR notation? How do you subnet a network?

o What IP Protocols use Source or Destination Ports?

Part 3: Review of Mininet

IF YOU HAVE FAMILIARITY WITH MININET OR IF YOU COMPLETED THE OPTIONAL PROJECT SIMULATING

NETWORKS, YOU MAY SKIP THIS SECTION AND START WITH PART 4: WIRESHARK

Mininet is a network simulator that allows you to explore SDN techniques by allowing you to create a network

topology including virtual switches, links, hosts/nodes, and controllers. It will also allow you to set the

parameters for each of these virtual devices and will allow you to simulate real-world applications on the

different hosts/nodes.

The following code sets up a basic Mininet topology similar to what is used for this project:

#!/usr/bin/python

from mininet.topo import Topo

from mininet.net import Mininet

from mininet.node import CPULimitedHost, RemoteController

from mininet.util import custom

from mininet.link import TCLink

from mininet.cli import CLI

class FirewallTopo(Topo):

def __init__(self, cpu=.1, bw=10, delay=None, **params):

5

super(FirewallTopo,self).__init__()

# Host in link configuration

hconfig = {'cpu': cpu}

lconfig = {'bw': bw, 'delay': delay}

# Create the firewall switch

s1 = self.addSwitch('s1')

hq1 = self.addHost('hq1',ip='10.0.0.1',mac='00:00:00:00:00:1e', **hconfig)

self.addLink(s1,hq1)

us1 = self.addHost( 'us1', ip='10.0.1.1', mac='00:00:00:01:00:1e', **hconfig)

self.addLink(s1,us1)

This code defines the following virtual objects:

Switch s1 – this is a single virtual switch with the label ‘s1’. In Mininet, you may have as many virtual

ports as you need – for Mininet, “ports” are considered to be a virtual ethernet jack, not an application

port that you would use in building your firewall.

Hosts hq1 and us1 – these are individual virtual hosts that you can access via xterm and other means.

You can define the IP Address, MAC/Hardware Addresses, and configuration parameters that can define

cpu speed and other parameters using the hconfig dictionary.

? Links between s1 and hq1 and s1 and us1 – consider these like an ethernet cable that you would run

between a computer and the switch port. You can define individual port numbers on each side (i.e., port

on the host and port on the virtual switch), but it is advised to let Mininet automatically wire the

network. Like hosts, you can define configuration parameters to set link speed, bandwidth, and latency.

REMINDER – PORTS MENTIONED IN MININET TOPOLOGIES ARE WIRING PORTS ON THE VIRTUAL

SWITCH, NOT APPLICATION PORT NUMBERS.

Useful Mininet Commands:

For this project, you can start Mininet and load the firewall topology by running the ./start-topology.sh

from the project directory. You can quit Mininet by typing in the exit command.

After you are done running Mininet, it is recommended that you cleanup Mininet. There are two ways of

doing this. The first is to run the sudo mn -c command from the terminal and the second is to use the

./cleanup.sh script provided in the project directory. Do this after every run to minimize any problems

that might hang or crash Mininet.

You can use the xterm command to start an xterm window for one of the virtual hosts. This command is

run from the mininet> prompt. For example, you can type in us1 xterm & to open a xterm window for

the virtual host us1. The & causes the window to open and run in the background. In this project, you

will run the test-*-client.py and test-*-server.py in each host to test connectivity.

The pingall command that is run from the mininet> prompt will cause all hosts to ping all other hosts.

Note that this may take a long time. To run a ping between two hosts, you can specify host1 ping host2

(for example, us1 ping hq1 which will show the result of host us1 pinging hq1).

The help command will show all Mininet commands and dump will show information about all hosts in

the topology.

6

Part 4: Wireshark

Wireshark is a network packet capture program that will allow you to capture a stream of network packets and

examine them. Wireshark is used extensively to troubleshoot computer networks and in the field of information

security. We will be using Wireshark to examine the packet headers to learn how to use this information to

match traffic that will be affected by the firewall we are constructing.

tshark is a command line version of Wireshark that we will be using to capture the packets between mininet

hosts and we will use Wireshark for the GUI to examine these packets. However, you will be allowed to use the

Wireshark GUI if you would like in doing the packet capture.

Please watch the video referenced in Part 2 if you would like to follow along in time for a live packet capture.

Step 1: Open up a Terminal Window and change directory to the SDNFirewall directory that was

extracted in Part 1.

Step 2: The first action is to start up the Mininet topology used for the Wireshark capture exercise. This

topology matches the topology that you will be using when creating and testing your firewall. To start

this topology, run the following command:

sudo python ws-topology.py

This will startup a Mininet session with all hosts created.

Step 3: Start up two xterm windows for hosts us1 and us2. After you start each xterm window, it is

recommended that you run the following command in each xterm window as you load them to avoid

confusion about which xterm belongs to which host:

export PS1=”hostname >” replacing hostname with the actual hostname.

Type in the following commands at the Mininet prompt.

us1 xterm & (then run export PS1=”us1 >” in the xterm window that pops up)

us2 xterm & (likewise, run export PS1=”us2 >” in the second xterm window)

Step 4: In this step, we want to start capturing all the traffic that traverses through the ethernet port on

host us1. We do this by running tshark (or alternatively, wireshark) as follows from the mininet prompt:

us1 sudo tshark -w /tmp/packetcapture.pcap

This will start tshark and will output a pcap formatted file to /tmp/capture.pcap. Note that this file is

created as root, so you will need to change ownership to mininet to use it in future steps – chown

mininet:mininet /tmp/packetcapture.pcap

If you wish to use the Wireshark GUI instead of tshark, you would call us1 sudo wireshark &. You may

7

use this method, but the TA staff will not provide support for any issues that may occur.

Step 5: Now we need to capture some traffic. Do the following tasks in the appropriate xterm window:

in us1 xterm: ping 10.0.1.2 (hit control C after a few ping requests)

In us2 xterm: ping 10.0.1.1 (likewise hit control C after a few ping requests)

In us1 xterm: python test-server.py T 10.0.1.1 80

In us2 xterm: python test-client.py T 10.0.1.1 80

After the connection completes, in the us1 xterm, press Control-C to kill theserver.

In us1 xterm: python test-server.py U 10.0.1.1 8000

In us2 xterm: python test-client.py U 10.0.1.1 8000

In us1 xterm: press Control C to kill the server

In Mininet Terminal: press Control C to stop tshark

Step 6: At the mininet prompt, type in exit and press enter. Next, do the chown command as described

in step 4 above to your packet capture. You may also close the two xterm windows as they are finished.

Copy the /tmp/packetcapture.pcap to your project directory. This file is the deliverable for this phase of

the project.

Step 7: At the bash prompt on the main terminal, run:

sudo wireshark

Go to the File => Open menu item, browse to the /tmp directory and select the pcap file that you saved

using tshark.

You will get a GUI that looks like the example packet capture. You will have a numbered list of all the captured

packets with brief information consisting of source/destination, IP protocol, and a description of the packet. You

can click on an individual packet and will get full details including the Layer 2 and Layer 3 packet headers,

TCP/UDP/ICMP parameters for packets using those IP protocols, and the data contained in the packet.

8

Example Packet Capture – Host us1 making web request to Host us2

Note the highlighted fields. You will be using the information from these fields to help build your firewall

implementation and ruleset. Note the separate header information for TCP. This will also be the case for UDP

packets.

Also, examine the three-way handshake that is used for TCP. What do you expect to find for UDP? ICMP?

Example TCP Three-Way Handshake

Please examine the other packets that were captured to help you familiarize yourself with Wireshark.

Part 5: SDN Firewall Implementation Details

Using the information that you learned above in running Wireshark, you will be creating two files – one is a

firewall configuration file that will specify different header parameters to match in order to allow or block

certain traffic and the second is the implementation code to create OpenFlow Flow Modification objects that

will create the firewall using the parameters given in the firewall configuration file.

You may create temporary rulesets to help you complete Part 5b below.

Part 5a: Specifications of configure.pol

The configure.pol file is used by the firewall implementation code to specify the rules that the firewall will use to

govern a connection. You do not need to code this first, but the format of the file is important as your

9

implementation code will need to use these items. The format of the file is a collection of lines that have the

proper format:

Rule Number, Action, Source MAC, Destination MAC, Source IP, Destination IP, Protocol, Source Port,

Destination Port, Comment/Note

o Rule Number = this is a rule number to help you track a particular rule - it is not used in the firewall

implementation. It can be of any value and is NOT validated in setup-firewall.py. The value need not be

unique and can be numeric or text.

o Action = Block or Allow Block rules will block traffic that matches the remaining parameters of this

rule. Allow rules will override Block rules to allow specific traffic to pass through the firewall (see below

for an example). The entry is a string in (Block,Allow).

o Source / Destination MAC address in form of xx:xx:xx:xx:xx:xx (example: 00:a2:c4:3f:11:09) or a “-“ if

you are not matching this item. You may use MAC Addresses to match an individual host. In the real

world, you would use it to match a particular piece of hardware. The MAC address of a particular host is

defined inside the sdn-topology.py file.

o Source / Destination IP Network Address in form of xxx.xxx.xxx.xxx/xx in CIDR notation or a “-“ if you

are not matching this item.. You can use this to match either a single IP Address (using it’s IP address and

a subnet mask of /32, or a particular Subnet. An entry here would look like: 10.0.0.1/32. NOTE: If you

are using a CIDR mask other than /32 (individual host), make sure that the IP Address shown is the

Network Address.

PRIMER ABOUT CIDR NOTATION:

An IP Address consists of 32 bits which contain both the network and the host addresses. These 32

bits are divided into 4 sections consisting of 8 bits. The subnet mask /24 defines how many bits of the

IP Address define the network. For a /24 network, there are 24 bits defining the network and 8 bits

that define the host. Thus, if you specify 192.168.10.0/24, the first 24 bits (the 192.168.10) define the

network address, and the 0 specifies the host (255 hosts). The IP specified here must be the network

address (for a /24, it must represent the first 24 bits). For the /32 address, the entire 32 bits is a

network address and represents a single host.

The IP address of a particular host is defined inside the sdn-topology.py file.

o Protocol = integer IP protocol number per IANA (0-254) or a “-“ if you are not matching this item.. An

example is ICMP is IP Protocol 1, TCP is IP Protocol 6, etc. This must be an integer.

o Source / Destination Port = if Protocol is TCP or UDP, this is the Application Port Number per IANA. For

example, web traffic is generally TCP Port 80. Do not try to use port numbers to differentiate the

different elements of the ICMP protocol. If you are not matching this item or are using an IP Protocol

other than TCP or UDP, this field should be a “-“.

o Comment/Note = this is for your use in tracking rules.

10

Special Notes About Firewall Configurations:

o Any field not being used for a match should have a '-' character as its entry. A ‘-‘ means that the item is

not being used for matching traffic. It is valid for any rule element except for Action to have a ‘-‘. (i.e.,

a rule like: 1,Block,-,-,-,-,-,-,-,Block the world is valid, but not a rule that will be tested). HINT: Do not

use any item that has a “-“ in its field as an element that you will match. If you pass a “-“ to a field in

a match rule, you will cause POX to crash and your firewall will not work.

A “-“ is valid for ALL FIELDS except Action DO NOT PASS A “-“ INTO ONE OF THE OPENFLOW MATCH

VARIABLES OR YOUR CODE WILL CRASH..

o When a rule states to block the world from accessing a particular host, this means that you are

matching against all possible hosts which may include hosts that are not in your topology. HINT:

Think about how you would match arbitrary traffic from anywhere on the network. Don’t overthink

this. Also, due to restrictions placed on the implementation by POX, please do not use 0.0.0.0/0 as an

address for “world”. In a real-world situation, this address would be valid as addressing any host on

the internet.

o Note that a rule does not necessarily need a MAC or IP Address. Also, it is possible to have a rule that

only has network addresses and no ports/protocols. What won’t ever be tested is using a src/dst port

WITHOUT an IP Protocol.

o What is the difference between source and destination? Source makes a request of the destination. For

ports, you will most often use destination ports, but make sure that your firewall implements both

source and destination ports. For IP and MAC addresses, you will use both most of the time.

o When should I use MAC vs IP Addresses? You will want to interchange them in this file to test the

robustness of your implementation. It is valid to specify a Source MAC address and a Destination IP

Address.

Example Rules (included in the project files:

1,Block,-,-,10.0.0.1/32,10.0.1.0/24,6,-,80,Block 10.0.0.1 host from accessing a web server on the 10.0.1.0/24 network

2,Allow,-,-,10.0.0.1/32,10.0.1.125/32,6,-,80,Allow 10.0.0.1 host to access a web server on 10.0.1.125 overriding rule

What do these rules do?

The first rule basically blocks host hq1 (IP Address 10.0.0.1/32) from accessing a web server on any host on the

us network (the subnet 10.0.1.0/24 network). The web server is running on the TCP IP Protocol (6) and uses TCP

Port 80.

The second rule overrides the initial rule to allow hq1 (IP Address 10.0.0.1/32) to access a web server running on

us5 (IP Address 10.0.1.125/32)

By definition – from the sdn-topology.py file:

11

This class defines the Mininet Topology for the network used in this project. This

network consists of the following hosts/networks:

Headquarters Network (hq1-hq5). Subnet 10.0.0.0/24

US Network (us1-us5). Subnet 10.0.1.0/24

India Network (in1-in5). Subnet 10.0.20.0/24

China Network (cn1-cn5). Subnet 10.0.30.0/24

UK Network (uk1-uk5). Subnet 10.0.40.0/24

In Part 6, you will be given a set of firewall conditions that you will need to create the configure.pol needed for

your submission.

You may create temporary rulesets to help you complete Part 5b below.

Part 5b: Implementing the Firewall in Code

After reviewing the format of the configure.pol file, you will now code a generic implementation of a firewall

that will use the values provided from the configuration file (passed to you as dictionary items). As it is

provided, the firewall implementation code blocks no traffic. You must implement code that does the following:

o Create an OpenFlow Flow Modification object

o Create a POX Packet Matching object that will integrate the elements from a single entry in

the firewall configuration rule file (which is passed in the policy dictionary) to match the

different IP and TCP/UDP headers if there is anything to match (i.e., no “-“ should be passed

to the match object, nor should None be passed to a match object if a “-“ is provided).

o Create a POX Output Action, if needed, to specify what to do with the traffic.

Please reference code examples in Appendix C, or you may refer to the POX API documentation

(WARNING, this is long and the API is confusing).

You will need to rewrite the rule = None to reference your Flow Modification object.

Your code will go into a section that will repeat itself for every line in the firewall configuration file that is passed

to it. The “rule” item that is added to the “rules” list is an OpenFlow Modification object. The process of injecting

this rule into the POX controller is handled automatically for you in the start-firewall.py file.

TIP: If your implementation code segment is more than 25-30 lines, you are making it too difficult. The POX API

can provide many features that are not used in this project. The Appendix provides all of the information that

you will need to code the project.

Key Information:

12

o policies is a python list that contains one entry for each rule line contained in your configure.pol file.

Each individual line of the configure.pol file is represented as a dictionary object named policy. This

dictionary has the following keys:

o policy[‘mac-src’] = Source MAC Address (00:00:00:00:00:00) or “-“

o policy[‘mac-dst’] = Destination MAC Address (00:00:00:00:00:00) ) or “-“

o policy[‘ip-src’] = Source IP Address (10.0.1.1/32) in CIDR notation ) or “-“

o policy[‘ip-dst’] = Destination IP Address (10.0.1.1/32) ) or “-“

o policy[‘ipprotocol’] = IP Protocol (6 for TCP) ) or “-“

o policy[‘port-src’] = Source Port for TCP/UDP (12000) ) or “-“

o policy[‘port-dst’] = Destination Port for TCP/UDP (80) ) or “-“

o policy[‘rulenum’] = Rule Number (1)

o policy[‘comment’] = Comment (Example Rule)

o policy[‘action’] = Allow or Block

Use these to match traffic. Please note that all fields are strings and may contain a ‘-‘ character. You may

either use policy[‘ip-dst’] or the split policy[‘ip-dst-address’]/[policy[‘ip-dst-subnet’] in your

implementation (the split was requested by prior semesters), but realize that if you use the ip-dst-

address and ip-dst-subnet, you will need to carefully check your implementation to ensure that it is

blocking the addresses you intend to block.

o You will need to assume that all traffic is IPV4. It is acceptable to hardcode this value. Do not hardcode

other values. Your code should be generic enough to handle any possible configuration.

o Hints:

o The difference between an Allow or a Block is dependent on an Action and th