updated host names

networking/Activity-Filtering_with_IPTables/prompt.adoc

@@ -17,12 +17,12 @@
 
 === Task 1)
 
-. The H1 client should be allowed to initiate new telnet and SSH connections. H1 should also allow connections outbound to tcp/udp ports 1234, 9001, 9002, 1111, 2222 and 9050. Established communications should also be allowed to ensure communications are successful.
-. The H3 client should be allowed to initiate new SSH, HTTP,  and TCP 9001-9002 connections. Established communications should also be allowed to ensure communications are successful.
-. Both H1 and H3 clients should never allow traffic to/from TCP/UDP ports 7777 and 9999.
-. Deny ping (ICMP) operations on H1 and H3 hosts. (Remember ping is a two part transaction. You should be thorough and filter both parts)
+. The Net1 client should be allowed to initiate new telnet and SSH connections. Net1 should also allow connections outbound to tcp/udp ports 1234, 9001, 9002, 1111, 2222 and 9050. Established communications should also be allowed to ensure communications are successful.
+. The Net3 client should be allowed to initiate new SSH, HTTP,  and TCP 9001-9002 connections. Established communications should also be allowed to ensure communications are successful.
+. Both Net1 and Net3 clients should never allow traffic to/from TCP/UDP ports 7777 and 9999.
+. Deny ping (ICMP) operations on Net1 and Net3 hosts. (Remember ping is a two part transaction. You should be thorough and filter both parts)
 . Ensure your Policy for the INPUT, OUTPUT, and FORWARD tables default policy is ACCEPT.
-. Test Condition:  Attempt to SSH between the H1 and H3 Clients (you can use non-standard ports such as 9999 or 7777 to test and verify the DROP rules). Ensure your IPTables rules are enforcing the above requirements.
+. Test Condition:  Attempt to SSH between the Net1 and Net3 Clients (you can use non-standard ports such as 9999 or 7777 to test and verify the DROP rules). Ensure your IPTables rules are enforcing the above requirements.
 
 == Deliverables
 
@@ -35,12 +35,12 @@
 
 == Challenge
 
-. Change the TTL on H3 from 64 to 128.
+. Change the TTL on Net3 from 64 to 128.
 . Apply IPTables to mitigate SYN Floods. (Try testing with nmap)
-. Apply logging to the rule created from Task 1 that drops ping/ICMP traffic on H1. Verify that you can see the messages located in "/var/logs/messages"  file that should be created by initiating a ping on the H1 client.
+. Apply logging to the rule created from Task 1 that drops ping/ICMP traffic on Net1. Verify that you can see the messages located in "/var/logs/messages"  file that should be created by initiating a ping on the Net1 client.
 . Utilize bpf bytecode to block icmp traffic with "deadbeef" in the payload. (You must flush your current table rules)
 
 == Useful Resources
 
 * http://ipset.netfilter.org/iptables.man.html
-* http://ipset.netfilter.org/iptables-extensions.man.html
+* http://ipset.netfilter.org/iptables-extensions.man.html
\ No newline at end of file

networking/Activity-IPTables_for_NATing/prompt.adoc

@@ -10,14 +10,14 @@
 
 == Scenario
 
-* Windows clients in the topology are not allowed to directly visit the 10.2.0.0 subnet. This would prevent H2 from accessing H3's webpage. H1 is allowed to access the website since it is a Linux Host; you have access to the H1 client in order to use NAT/port forwarding to allow Windows clients (H2) to access the site on H3 via H1. The intent is that traffic leaving your H2 client will be pointed to H1, but will actually be NATed and forwarded to the webpage on H3.
-* *BEFORE YOU BEGIN*, you must ensure ip forwarding is enabled on H1. This is a feature which is disabled by default, but it order to NAT through H1, th client needs to be able to receive a packet in eth1 and then forward it back out eth1 toward it's destination. The feature for enabling forwarding is within the "/proc/sys/net/ipv4/ip_forward" file. The value of "0" indicates forwarding is disabled. You will need to change this value to 1.
-* Additionally, you should create a rule on H3 to Drop all traffic sourced from H2. This will help you to verify your results.
+* Windows clients in the topology are not allowed to directly visit the 10.2.0.0 subnet. This would prevent Net2 from accessing Net3's webpage. Net1 is allowed to access the website since it is a Linux Host; you have access to the Net1 client in order to use NAT/port forwarding to allow Windows clients (Net2) to access the site on Net3 via Net1. The intent is that traffic leaving your Net2 client will be pointed to Net1, but will actually be NATed and forwarded to the webpage on Net3.
+* *BEFORE YOU BEGIN*, you must ensure ip forwarding is enabled on Net1. This is a feature which is disabled by default, but it order to NAT through Net1, th client needs to be able to receive a packet in etNet1 and then forward it back out etNet1 toward it's destination. The feature for enabling forwarding is within the "/proc/sys/net/ipv4/ip_forward" file. The value of "0" indicates forwarding is disabled. You will need to change this value to 1.
+* Additionally, you should create a rule on Net3 to Drop all traffic sourced from Net2. This will help you to verify your results.
 
 === Task 1)
 
-. Use iptables to setup rules to forward traffic that reaches H1's port 80 and redirects it to H3's port 80.
-. Test to ensure this is working by trying to browse to H3's website from the H2, Windows client
+. Use iptables to setup rules to forward traffic that reaches Net1's port 80 and redirects it to Net3's port 80.
+. Test to ensure this is working by trying to browse to Net3's website from the Net2, Windows client
 
 == Deliverables
 
@@ -25,7 +25,7 @@
 
 == Hints
 
-* You will need a prerouting entry and a postrouting entry. For simplicity in postrouting, you can use "-j MASQUERADE". This is used for Dynamic source NATing, and will EASILY allow H1 to relay the returned traffic from H3, back to the requesting client (H2).
+* You will need a prerouting entry and a postrouting entry. For simplicity in postrouting, you can use "-j MASQUERADE". This is used for Dynamic source NATing, and will EASILY allow Net1 to relay the returned traffic from Net3, back to the requesting client (Net2).
 
 == Challenge
 
@@ -34,4 +34,4 @@
 == Useful Resources
 
 * http://ipset.netfilter.org/iptables.man.html
-* http://ipset.netfilter.org/iptables-extensions.man.html
+* http://ipset.netfilter.org/iptables-extensions.man.html
\ No newline at end of file

networking/Activity-Snort_Configuration/prompt.adoc

@@ -10,14 +10,14 @@
 
 == Scenario
 
-* Students will need to access their net1 host. The host has 2 interfaces, but we will be looking at interface eth1 (10.1.0.2)
+* Students will need to access their Net1 host and ensure their interface eth0 (10.1.0.2) is configured properly.
 
 == Task 1
 
 . Confirm that snort has been installed/configured correctly with "snort --version"
 . Be sure to have *root privileges*, then run Snort as a daemon (-D flag), on the appropriate interface. Ensure you are sending the logs to the /var/log/snort/ directory.
 (You can check that snort is running with “ps -ef | grep snort”. You may start snort on multiple interfaces; each will create its own process.)
-. Test the default rule which will trigger on ANY icmp packet. You can send a ping from net1 to or thru the router's interface and check the alerts file that snort generates. The log files can be viewed in tcpdump/wireshark.
+. Test the default rule which will trigger on ANY icmp packet. You can send a ping from Net1 to or thru the router's interface and check the alerts file that snort generates. The log files can be viewed in tcpdump/wireshark.
 . Now you will practice customizing this icmp rule.
 
 == Task 2
@@ -26,7 +26,7 @@
 . You will customize the icmp.rules file and change the matching condition. The rule should only alert if an icmp packet with the hex string of "DEADBEEF" is present in the payload.
 . Change the sid to "9000000" and the msg to "COWS".
 . Run Snort as a daemon on the appropriate interface. Ensure you are sending the logs to the /var/log/snort/ directory.
-. Send a ping fro net1 with "BEEF" ONLY in the payload and check the alert log in snort. You should NOT see the alerts for the pings that you sent with the payload information since it didn't explicitly match.
+. Send a ping fro Net1 with "BEEF" ONLY in the payload and check the alert log in snort. You should NOT see the alerts for the pings that you sent with the payload information since it didn't explicitly match.
 . Finally, go back to your host and send a ping with the "DEADBEEF" payload and ensure that snort DOES trigger for these pings. You can kill snort once you have completed this task.
 
 == Task 3