辅导Software编程、讲解Python留学生程序、Python编程设计调试

日期：2020-11-03 08:07

SDN Firewall
(Fall 2020)
Goal
In this project, you will use Software Defined Networking (SDN) to create a configurable firewall using an OpenFlow
enabled switch and controller. This is beyond what is possible with traditional Layer 2 (L2) switches, and shows how
the simplest of SDN switches are more capable than even the fanciest of L2 switches.
You are going to create an externally configurable firewall using a SDN platform named Pyretic and the POX
OpenFlow Controller. That means that the firewall rules are provided in a configuration file which can be changed
without altering the switch code.
This firewall is of the type that allows all traffic to pass that isn't expressly disallowed (a blacklist firewall). The
alternative is to disallow all traffic that isn't expressly allowed by the policy (a whitelist firewall). A whitelist firewall is
typically used in edge situations protecting internal resources from the outside/Internet (an example is a home
internet router). The code we have provided for this project could be modified to implement this second type of
firewall, and would be a worthwhile project for those who are interested in learning further.
Before You Start
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 IP packets and what you need to match.
1. What is IP (Internet Protocol)? What are the different types of Network Layer protocols?
2. Review TCP and UDP. How does TCP or UDP differ from IP?
3. 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? (Reviewing the
material available at the following document may assist you in this project:
https://www.airuniversity.af.edu/Portals/10/CyberCollege/documents/Portal/PDF/Hands-on%20Keyboard%2
05%20-%20Wireshark.pdf
4. This is a review from earlier material, but examine what constitutes a TCP connection versus a UDP
connection. What happens if you block either side of a connection and what would you expect to see (for
example, timeout, connection drop, or connection failed)?
5. 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?
6. If you block a host from ICMP, will you be able to send TCP/UDP traffic to it?
7. Can you explain what happens if you get an ICMP Destination Unreachable response?
Project 4 Files
In the SDN-Firewall directory, there are many files, described below:
● firewall-policies-bad.pol - This is an example firewall configuration policy that is broken. When
parsing, an error message will be thrown. Each line has an error of some type. Try removing lines to see
the different possible error messages. This shows how the policy file is parsed by the parse_config function
in firewall.py
● firewall-policies-good.pol - This is an example firewall configuration policy that disallows all devices
to connect to TCP port 1080 on all other devices. You can use this as the base for the
firewall-config.pol file you will generate later in the instructions. The code to implement this firewall
policy is included in the Firewall_policy.py file.
● Firewall_policy.py - This is the file where you will implement the firewall using python and pyretic code,
based on the policy configuration that is passed in via the configuration files.
● firewall.py - This is the file that sets up pyretic application and reads the firewall config policy into a data
object. DO NOT MODIFY THIS FILE. A shell script is provided to help run it. This file contains the code
that is used to parse your firewall-config.pol file, so please look here for the import format for your
firewall-config.pol.
● firewall-topo.py - This is a mininet program to start your topology. It consists of one switch and two
groups of hosts. Modifying this file isn't necessary, but you may choose to try different topologies for testing
your code (make sure that your firewall-config.pol works with the original firewall-topo.py, however).
● pyretic_switch.py - This implements a learning switch. You do not need to modify this file.
● run-firewall.sh - This script runs the firewall using pyretic (it starts the firewall.py application.) The files
need to be in the pyretic directory trees, and this script makes that happen. Also, it allows for different
configuration files to be used by giving the filename on the command line.
● test-tcp-client.py - This acts as a TCP client: opens a connection, sends a string, then waits to hear it
echoed back. You can use this to test your firewall policies.
● test-tcp-server.py - This acts as a TCP server: listens on a specified port, echoes back whatever it
hears. You can use this together with the test-tcp-client.py program. Note that the IP Address used
for this command MUST match the IP address of the machine you run this command on.
● test-udp-client.py - This acts as a UDP client to test your firewall policies.
● test-udp-server.py - This acts as a UDP server which echoes back whatever it hears. You can use this
together with the test-udp-client.py program. Note that the IP Address used for this command MUST
match the IP address of the machine you run this command on.
References
The following documents and papers will help with completing and understanding this project:
● Pyretic Manual (especially How To Use Match and Language Basics) -
https://github.com/frenetic-lang/pyretic/wiki
● Wireshark: https://www.wireshark.org/docs/wsug_html/
● Analyzing TCP Packet Blog post: https://medium.com/@eranda/analyze-tcp-dumps-a089c2644f19
● https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml for TCP
and UDP Services
● http://www.firewall.cx/networking-topics/protocols/icmp-protocol/152-icmp-echo-ping.html (ICMP Ping)
Instructions
IMPORTANT: Read all the instructions carefully! Then read them again after you finish but before you submit, so
you can verify that what you did matches what the assignment says exactly. Even seemingly small details in the
instructions can be very important! Some of those details exist to allow our grading code to interface with your
project properly. You will lose points if your project does not work with our grader because you didn't follow
the instructions. We do not arbitrarily deduct points for not following directions, but you will not receive credit for
your project if our grader cannot tell whether or not it's working.
1. Before getting started, you will need to download SDN-Firewall.zip to the VM and unzip.
o unzip SDN-Firewall.zip
2. Next, move to the SDN-Firewall directory and try out the test-tcp-client.py, test-tcp-server.py,
test-udp-client.py, and test-udp-server.py tools to learn how to use them by following the following
steps (you will use these techniques in future steps to test your firewall implementation):
o Open a terminal and copy the pyretic_switch.py file to the pyretic modules folder:
? cp pyretic_switch.py ~/pyretic/pyretic/modules
o Start the pyretic_switch.py file:
? cd ~/pyretic
? python pyretic.py pyretic.modules.pyretic_switch
o In a second terminal, start the topology in the SDN-Firewall directory:
? sudo python firewall-topo.py
After running this step (or in Step 3 at the same point), you may see the following error in the first
terminal window:
ERROR:core:Exception while handling OpenFlowNexus!PortStatus...
Traceback (most recent call last):
File "/home/mininet/pox/pox/lib/revent/revent.py", line 231, in raiseEventNoErrors
return self.raiseEvent(event, *args, **kw)
File "/home/mininet/pox/pox/lib/revent/revent.py", line 278, in raiseEvent
rv = event._invoke(handler, *args, **kw)
File "/home/mininet/pox/pox/lib/revent/revent.py", line 156, in _invoke
return handler(self, *args, **kw)
File "/home/mininet/pyretic/of_client/pox_client.py", line 577, in _handle_PortStatus
self.switches[event.dpid]['ports'][event.port] = event.ofp.desc.hw_addr
KeyError: 1
Exit Mininet by typing in quit and then run sudo ./cleanup.sh and repeat this step.
o At the Mininet prompt, you need to open up a couple of new terminals:
? xterm e1
? xterm e2
o HINT: All IP and MAC Addresses are assigned in order based on the alphabetical order of the
host names. So client1 is 10.0.0.1 (MAC 00:00:00:00:00:01) and e1 is 10.0.0.2 (MAC
00:00:00:00:00:02). The test-*-* commands below MUST use the IP Address and NOT the
hostname.
o In the e1 terminal, start the server:
? python test-tcp-server.py 10.0.0.2 1234
? The parameters are the server’s IP and port. You can run ifconfig in the xterm window
to check the IP.
? The server simply uses an infinite loop around the accept function, so you can use Ctrl-C to
kill it when you're done running all the steps including running test-tcp-client.py.
? The UDP server works in the same manner.
o In the e2 terminal, start the client:
? python test-tcp-client.py 10.0.0.2 1234
? The parameters here are the server’s IP and port, and should be the same as specified
above.
? Likewise, the UDP client functions in a similar manner to the TCP client.
You can stop the test-*-*.py scripts by pressing Control-C.
If you get the following error, you may ignore it - it is caused by the MPTCP kernel installed on the
VM:
INFO:packet:(tcp parse_options) warning, unknown option 1e
o HINT - You must use the server IP address and Port for both the test-*-client.sh and
test-*-server.sh commands. You need to make sure that you run the test-*-server.sh script on
the xterm/host that you designate as the “server” and test-*-client.sh on the xterm/host that
you designate as the “client”. If you get this backwards, you will get an error on your “client”
that an IP address could not be assigned/used. Why is this?
o You'll be using this quite a bit, so feel free to play around with it for a bit before moving onto creating
the firewall.
o After you have finished this step, exit out of mininet and then run the sudo ./cleanup.sh command to
kill pyretic. The cleanup script will kill mininet and any orphaned python/pox/pyretic processes that
may have been left running after a potential crash.
3. The following set of steps shows how to start and run the firewall. This step will use the one included match
rule in firewall_policy.py file and the firewall-policies-good.pol file. The code in
firewall_policy.py will implement a minimal firewall that will block TCP port 1080 for all hosts. (NOTE THAT
ONCE YOU START THIS STEP, YOU WILL NOT BE ABLE TO RE-RUN STEP 2 WITHOUT ERRORS)
o Make sure that you return to the SDN-Firewall directory in the first terminal window.
o In the first terminal, start the firewall as specified below. Please provide the firewall-policies-*.pol
file that you want to test as the second parameter. DO NOT RUN THIS AS ROOT (i.e., sudo).
? ./run-firewall.sh firewall-policies-good.pol
Note: You may get the following error message when you run this command that you can
safely ignore: Couldn't import dot_parser, loading of dot files will not be possible.
o In a second terminal, start the topology:
? sudo python firewall-topo.py
o At the mininet prompt, open client and server terminals:
? xterm e1
? xterm e2
o In the e1 terminal, start the server:
? python test-tcp-server.py 10.0.0.2 1234
? The UDP server can be used in the same manner.
? Note that the IP address used in the server command MUST match the IP of the machine
you are connected to (in this case, e1).
o In the e2 terminal, start the client:
? python test-tcp-client.py 10.0.0.2 1234
? The UDP server can be used in the same manner. Note that the IP and port here should be
that of the server.
Using the provided good firewall-policies-good.pol files, the connections above (port 1234) should
connect and pass traffic.
o Stop the test client/server from the last two steps.
o In the e1 terminal, start the server:
? python test-tcp-server.py 10.0.0.2 1080
? The UDP server can be used in the same manner.
o In the e2 terminal, start the client:
? python test-tcp-client.py 10.0.0.2 1080
? The UDP server can be used in the same manner.
By default, the firewall_policy.py file has been hardcoded to block TCP connections to TCP Port 1080 on
all servers. If you test the UDP server/client, you should be able to connect (test this functionality by
replacing tcp with udp in the test-tcp-server.py and test-tcp-client.py filename). The
firewall-policies-good.pol shows the necessary configuration to block TCP Port 1080.
o Again, like in Step 2, exit out of mininet and then run sudo cleanup.sh command to kill pyretic. It is a
good practice to do this after every attempt to run the firewall.
A blocked connection will fail in many different methods depending on the way that you
implemented the firewall (See #4, #5, and #7 from the Before You Start section. As long as the
connection does not connect and pass traffic, it will be considered OK by the autograder as
being blocked.
4. Now you will create the firewall implementation by editing firewall_policy.py and
firewall-config.pol file. The firewall_policy.py file should implement code that will match all the
permutations of entries in a possible configuration file (as specified below) without hardcoding a solution
(i.e., do not specify specific addresses, and ports in your python implementation field - use the data passed
to it from your firewall configuration file - if you do hardcode the configuration, you will lose many points
when your implementation code is exercised with other topologies and rulesets). The
firewall-config.pol file will contain the ruleset specified later in this document. It is suggested that you
build this file in a stepwise approach to help you code your solution for the implementation code.
firewall-config.pol file Specifications:
The format of the parsed configuration file (i.e., firewall-config.pol ) is as follows:
rulenum, source MAC, destination MAC, source IP, destination IP, source Port, destination Port,
Protocol, IPProtocol
Each field is described as follows:
○ rulenum exists to help you debug your code. If a rule is “invalid”, the parser will give
you the number you specify.
○ MAC Addresses are specified in the form of 00:00:00:00:00:01 or “-” if you are not
specifying it.
○ IP Addresses are specified in the form of 10.0.0.1/24 in CIDR notation. “-” if you are not
specifying an IP address.
○ Port numbers are integers with a valid range of 0 to 65535. If a port is specified, you
must also specify the protocol for TCP or UDP. If no port is specified, use a “-” to
indicate that you are not matching this field
○ For Protocol, use T for TCP IP protocol, U for UDP IP protocol, I for ICMP, and O for
other IP Protocols that aren’t TCP/UDP/ICMP (i.e., IP Protocols for GRE, IPSEC, etc).
Remember, you must specify a protocol if you specify a Port number. If you are not
specifying a protocol, supply a “-” for this field.
○ The IPProtocol field is ONLY used if you specify O in the protocol field. This field
should contain the integer value of the particular IP Protocol that you are matching. If
you do not use a value of O for the protocol field, this field should have a value of “-”.
General Notes
○ Hostnames are not allowed to be used in the configuration file (i.e, you must specify an
IP address or MAC address in the appropriate field). All IP and MAC Addresses are
assigned in numerical order based on the alphabetical order of the host names.
○ Remember that every field can have a “-” as it’s value. “-” indicates that you are not
matching traffic with that particular element. For instance, if you want to match only a
destination IP address, your rule would be 1,-,-,-,destip,-,-,-,-.
○ You can get the IP Address or MAC address for any host by typing in hostname ifconfig in
the mininet CLI. For example, for host w1, use the command inside your mininet terminal:
w1 ifconfig
The IP Addresses and MAC addresses are defined in order alphabetically based on the host
name. You can also get a summary by issuing the following command in your mininet
terminal: dump
○ IP addresses do not change from machine to machine. The address for e1 will always be
the same on every machine unless you change the firewall-topo.py file.
firewall_policy.py file Specifications:
General Notes for Your Implementation:
● NOTE: Your implementation code DOES NOT NEED to validate that the format of the
rules from the firewall-config.pol file is correct. Validation logic has been provided in
firewall.py. Your code will NOT be tested with an invalid configuration file or with any
rules that are considered invalid based on this documentation
● Translating the protocol entries to their numerical value or constant is not considered hardcoding.
● The code you generate must support all possible permutation of items in the firewall
configuration file. For example, you should be able to handle a source IP address and a destination
MAC address. Also note that some parameters may need additional information. Refer to the
Pyretic How to Match (https://github.com/frenetic-lang/pyretic/wiki/How-to-use-match) and Language
Basics (https://github.com/frenetic-lang/pyretic/wiki/Language-Basics) for the information needed to
fill in the code in firewall-policy.py file.
● This project does not include IPv6 support. You may assume that all traffic is IPv4 only.
● Your code may use any particular library installed on the VM, but it should not require any third party
libraries to complete.
● Comments or debug lines will not adversely impact the autograder. The “print config” code also will
not adversely impact the autograder.
● You may make any changes you need to the make_firewall_policy function, but it is recommended
to drop any code you need in the #TODO areas. You may or may not need both areas. You may
also make auxiliary functions in this file. DO NOT ADD CODE TO OTHER FILES.
● In writing your implementation code, you may use any Pyretic functions. However, beware that
using the >>, +, and | operators may cause unexpected behavior. It is fairly trivial to
implement the project without using any of these operators. However, if you do use these,
make sure you carefully and fully test your firewall implementation (especially in maintaining
pyretic prerequisites for different items. Most point deductions for this project is as a result
of using those operators.
● To test the “O” protocol, consider simulating an ICMP block by specifying a rule with O,1 for the last
two entries for that rule and see if you can complete a PING request (ICMP is IP Protocol 1). If your
code can handle the O,1 case, it can handle any other O,# cases. You could also use a TCP or
UDP rule to likewise test to make sure your implementation of “O” is correct. There are also
possible testing solutions by using the netcat tool or modifying the test-*-*.py scripts to support other
protocols. ALSO,additional methods to test certain IP Protocols will be posted in Piazza.
● Note that you are allowed to add items into the “config” list object using your code in
firewall_policy.py if you would like.
● You may handle the empty case in any way you would like. It is not a rule that will be tested (i.e., ‘-’
in all fields except for rulenum).
The best approach to step 4 is to start coding by picking an individual field (say, destination MAC address),
write a firewall-test-config.pol entry to model only the destination MAC address, and then code your
firewall_policy.py file to handle the destination MAC address case. Test out your rule by repeating the
steps used in step 3 above (using ./run-firewall.sh firewall-test-config.pol as the first
command) to test your implementation for each field. Repeat for other fields. The most difficult to
implement will be your protocol handling.
You are free to create additional rules and topologies that you can use to test your firewall implementations
and you can share these on Piazza. You are NOT allowed to share your firewall_policy.py
implementation or the firewall-config.pol that you will be creating in subsequent
steps.
Your firewall-policy.py implementation file will be tested against alternate configuration files and
topologies, so please make sure that your code is robust to handle different combinations of
situations including using all possible permutations of IP Addresses and MAC Addresses, different
ports, and different protocols.
5. The final step of the project is to create a firewall policy configuration file that will implement the following
ruleset. This file MUST be named firewall-config.pol. The rules you need to implement are detailed
below. Please know that you need to craft the rules in such a way that you don’t over-block items (i.e., if you
are asked to block TCP port 50, make sure that you do not block UDP port 50). Please refer to the
firewall-config.pol file specifications above.
Rules to be implemented:
1. One common implementation for a virtual private network (VPN) solution utilizes PPTP
(Point-to-Point Tunnelling Protocol). It now has many issues related to the way it authenticates
users. Write a series of firewall policy rules to block PPTP that will prohibit all hosts from
sending traffic to a PPTP server running on server2. (One TCP port and the GRE IP Protocol)
2. SSH (Secure SHell) is used to provide a remote shell which can be used to forward other ports
or to bypass firewalls. Write firewall policy rule(s) that will prohibit all hosts from sending traffic
to a SSH server on the east hosts (e1-e3) (Block only one TCP and UDP Ports).
3. One common way to perform a distributed denial of service (DDOS) attack is to use an
amplification attack using the Network Time Protocol (NTP) and Domain Name Services (DNS)
taking advantage of the UDP protocol to saturate the links. Write firewall policy rule(s) to
protect the DNS and NTP services on both server1 and server2 from receiving traffic by all
hosts. However, the DNS and NTP services on server3 should be accessible to all hosts. (Only
block the UDP Ports for NTP and DNS)
4. Write a series of firewall policy rules disallowing hosts w1 and w2 from pinging client1. This
rule will be satisfied if the full ping request/response is not completed. Analyzing the
connections with Wireshark or tcpdump is helpful, but not required.
5. Write a series of firewall policies to disallow host e1 from sending traffic destined to TCP ports
9950-9952 on host e3.
6. Write a series of firewall policies to restrict host client1 from sending traffic to any of the east
hosts (e1-e3) on both TCP and UDP protocols.
7. Another common implementation for a VPN uses L2TP/IPSEC (Layer 2 Tunneling Protocol and
IPSEC). Write a series of firewall policy rules that will prohibit all hosts from sending traffic to a
L2TP/IPSEC server running on server3. L2TP uses a variety of ports. The Key Exchange for
IPSEC takes place over UDP Port 500, the Encapsulation Security Payload (ESP) IP Protocol is
also used by IPSEC, and the actual tunnel is set up on UDP Port 1701. (2 UDP Ports and 1 ESP
IP Protocol)
Notes:
All hosts mean any other possible hosts on the network.
When a protocol is specified, use the IANA Protocol Lists to find the number for the specified IP
or TCP/UDP Protocol.
Common Error Conditions and How to Handle Them
If you see the following error, please run the cleanup.sh script as a sudo and try again:
ERROR:core:Exception while handling OpenFlowNexus!PortStatus...
Traceback (most recent call last):
File "/home/mininet/pox/pox/lib/revent/revent.py", line 231, in raiseEventNoErrors
return self.raiseEvent(event, *args, **kw)
File "/home/mininet/pox/pox/lib/revent/revent.py", line 278, in raiseEvent
rv = event._invoke(handler, *args, **kw)
File "/home/mininet/pox/pox/lib/revent/revent.py", line 156, in _invoke
return handler(self, *args, **kw)
File "/home/mininet/pyretic/of_client/pox_client.py", line 577, in _handle_PortStatus
self.switches[event.dpid]['ports'][event.port] = event.ofp.desc.hw_addr
KeyError: 1
If you see the following warning, you may safely ignore it:
WARNING:openflow.of_01: raised on dummy OpenFlow nexus
If you accidentally run the run-firewall.sh script as root, you will need to run the following commands to
avoid the “access denied” error.
sudo chown mininet:mininet /home/mininet/pyretic/pyretic/modules/firewall_policy.py
sudo chown mininet:mininet /home/mininet/pyretic/pyretic/modules/firewall-policies.cfg
sudo chown mininet:mininet /home/mininet/pyretic/pyretic/modules/firewall.py
sudo chown mininet:mininet /home/mininet/pyretic/pyretic/modules/pyretic_switch.py
If you get the following error, make sure that the pyretic (run-firewall.sh) has not ended with an error
message :
Unable to contact the remote controller at 127.0.0.1:6633
If you get this error, you will want to run the cleanup.sh as a superuser (sudo). If you still get this error after
running cleanup, then the error is in your code - something in your code is causing pyretic to crash.
When running the firewall, you may get errors like:
Warning: libopenflow_01:Fields ignored due to unspecified prerequisites: nw_proto
If you get this error (or similar error messages like tp_dst), please note that this rule will be ignored and not
processed by pyretic. This indicates that there is an error in your implementation code. Any error that
indicates unspecified prerequisites indicates this. Read the How to Use Match pyretic document to help
find the error.
When running the firewall, you may get a warning like:
INFO:packet:(tcp parse_options) warning, unknown option 1e
This error is caused by the kernel that is running on the VM (MPTCP). It can be safely ignored.
If you get the following error: Error: pox not found in PYTHONPATH
Double check your PYTHONPATH environment variable to see if it is as follows:
mininet@mininet-VirtualBox:~$ echo $PYTHONPATH
/home/mininet/pyretic:/home/mininet/mininet:/home/mininet/pox
If Wireshark is installed but you cannot run it (e.g. you get an error like $DISPLAY not set, please consult the FAQ:
https://github.com/mininet/mininet/wiki/FAQ#wiki-x11-forwarding.)
What to turn in
For this project you need to turn in two files to Canvas in a ZIP file. Please name the zip file based on your GaTech
username (i.e., gburdell3_p6.zip).
Use the following command to zip the two files below using the class VM:
zip gburdell3_p6.zip firewall_policy.py firewall-config.pol
(replace “gburdell3” in “gburdell3_p6.zip” with your actual GT username). This command will zip the two files
without including the path or extraneous directories. Please test the ZIP file before submitting to Canvas to ensure
that you have the proper versions of the files listed below.
● firewall_policy.py - The SDN firewall you created in Step 4. MANDATORY
● firewall-config.pol - The configuration file you created in Step 5. MANDATORY
AFTER YOU SUBMIT THE ZIP FILE TO CANVAS, PLEASE DOUBLE CHECK AND REDOWNLOAD
YOUR SUBMISSION FROM CANVAS TO ENSURE THAT YOU DID NOT INADVERTENTLY
SUBMIT A PREVIOUS PROJECT ACCIDENTALLY.
Please refer to Piazza Post @35 for more information on how to ZIP and submit projects.
What you can and cannot share
For this project, you can and are encouraged to share testing techniques and frameworks, your testing firewall
policies, and testing topologies. What you cannot share is code for firewall_policy.py or examples of
configuration policies that address the ruleset in Step 6 that belong in firewall-config.pol. See Part 1 Step 4
for more examples of what can and cannot be shared. If you have any doubt please ask the Instructors privately on
Piazza before sharing.
Notes
Wireshark may be helpful for this project. You can start it from any terminal with the following command: sudo
wireshark & (it needs to run as root to sniff traffic) and use it to look at traffic on specific ports. You may wish to
start two instances - one either side of the switch - to see if traffic is being if actually being completed and received.
Note that you can increase the RAM or processor usage for the VM for this project to improve performance. You
can also run multiple cpus in the VM for the next project, BGP Hijacking.
You are being provided a Project 4 GUI tool developed by Sam Paulissian, a former TAs for this course. You may
find it helpful for testing, but you are not required to use it if you are more comfortable using the command line
interface. Download the SDN-FirewallGUI zip file from Canvas and follow the instructions for use found within the
folder after you unzip it using the unzip SDN-FirewallGUI.zip command.
Grading Policy and Rubric
Your firewall_policy.py will be tested with a set of known good configuration files and different topologies that
are not provided. These configurations will range from simple port blocking to others that are more complex than
what was defined for this project. Also, both simple and complex topologies will be used to evaluate your policy.
Your firewall-config.pol file will be tested for validity and functionality by using your firewall_policy.py
file.
If you have trouble coding the firewall_policy.py file, at least attempt to create the firewall-config.pol to
get partial credit.
10 pts Correct Submission for turning in all the correct files with the correct names, and significant effort has
been made in each file towards completing the project. This will be up to 5 points
for each file. The penalty will have a variance based on the effort undertaken.
45 pts Firewall Policy the policy in firewall-config.pol passes a variety of tests to ensure correct
blocking of traffic per the rules, and allows all other traffic. If there are significant
issues with your firewall_policy.py file, your work may be verified against a known
good firewall_policy.py file.
45 pts Firewall
Implementation
the firewall implementation in firewall_policy.py passes a variety of tests to
ensure it works properly with several different firewall configurations (i.e., different
firewall rules and topologies)