Firewalls - Lab 8 - Internetwork Security | ECE 4112, Lab Reports of Electrical and Electronics Engineering

Material Type: Lab; Class: Internetwork Security; Subject: Electrical & Computer Engr; University: Georgia Institute of Technology-Main Campus; Term: Spring 2005;

Typology: Lab Reports

Pre 2010

Uploaded on 08/05/2009

koofers-user-op0-1
koofers-user-op0-1 🇺🇸

10 documents

1 / 57

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
ECE4112 Internetwork Security
Lab 8: Firewalls
Group Number: _________
Member Names: ___________________ _______________________
Date Assigned: March 8, 2005
Date Due: March 15, 2005
Last Edited: March 8, 2005
Please read the entire lab and any extra materials carefully before starting. Be sure to start early
enough so that you will have time to complete the lab. Answer ALL questions in the Answer
Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the
Date Due.
Goal: This lab will introduce to the concept of Firewalls. You will be experimenting with
different kinds of firewalls.
Summary: This lab is divided into three major parts. Part 1 explores the Linux firewall
implementation in the form of the iptables program. Part 2 is a small introduction to Zone Alarm, one of
the most popular Windows firewall programs. In Part 3, you will configure a Cisco PIX 15E firewall for a
particular network structure. Part 1 and 3 might each take 2 hours or more, to finish. Therefore it is
recommended that you start early.
Background: None
Prelab Questions: None
Lab Scenario:
NOTE: Parts 1 and 3 of the lab require you to reserve slots to use the equipment. The signup sheets will
be posted on the lab door. Since the two portions are separate from each other, you can do them in any
order.
A couple of Firewall stations have been setup for you in the lab. The virtual machine network structure on
these stations is shown below. Basically, the virtual machines have been setup with host only networking.
So any traffic they send or receive goes through the Host machine, which also acts like the Firewall. This
network structure mimics the network structures of the real world where a firewall sits between the inside
and the outside networks. Since we are only trying to show you the capabilities of the iptables program,
only two machines are sufficient.
1
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35
pf36
pf37
pf38
pf39

Partial preview of the text

Download Firewalls - Lab 8 - Internetwork Security | ECE 4112 and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity!

ECE4112 Internetwork Security

Lab 8: Firewalls

Group Number: _________

Member Names: ___________________ _______________________

Date Assigned: March 8, 2005

Date Due: March 15, 2005

Last Edited: March 8, 2005

Please read the entire lab and any extra materials carefully before starting. Be sure to start early

enough so that you will have time to complete the lab. Answer ALL questions in the Answer

Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the

Date Due.

Goal: This lab will introduce to the concept of Firewalls. You will be experimenting with

different kinds of firewalls.

Summary: This lab is divided into three major parts. Part 1 explores the Linux firewall

implementation in the form of the iptables program. Part 2 is a small introduction to Zone Alarm, one of the most popular Windows firewall programs. In Part 3, you will configure a Cisco PIX 15E firewall for a particular network structure. Part 1 and 3 might each take 2 hours or more, to finish. Therefore it is recommended that you start early.

Background: None

Prelab Questions: None

Lab Scenario:

NOTE: Parts 1 and 3 of the lab require you to reserve slots to use the equipment. The signup sheets will be posted on the lab door. Since the two portions are separate from each other, you can do them in any order. A couple of Firewall stations have been setup for you in the lab. The virtual machine network structure on these stations is shown below. Basically, the virtual machines have been setup with host only networking. So any traffic they send or receive goes through the Host machine, which also acts like the Firewall. This network structure mimics the network structures of the real world where a firewall sits between the inside and the outside networks. Since we are only trying to show you the capabilities of the iptables program, only two machines are sufficient.

Figure 1-1. Network structure on the Firewall machines System Setup Protected: A normal Linux virtual machine with IP 192.168.0.10, netmask 255.255.255.0, and gateway 192.168.0.1. The gateway is a virtual interface on the host machine which acts like a router and firewall. This is the machine that is on the inside network and needs to be protected with the firewall. Linux Firewall: RedHat 8.0 base system that is configured to act like a router and runs a firewall with ipchains. It forwards packets received on its two virtual interfaces (vmnet1 and vmnet2) to the intended destinations. You will make firewall rules on this machine to protect the inside network. BlackHat: Same configuration as the Protected machine. IP address is 131.210.231.55 and gateway is 131.210.231.1, which is the virtual interface vmnet2 on the host machine. This is the machine where you will try to attack the protected machine from. Note: All the root passwords for these machines have been set to “password”.

1. Linux Firewalls

In this section of the lab you will explore the Linux firewall iptables. The initial sections give an overview of basic firewall concepts with exercises and examples. In the later sections, you will implement all the rules in the iptables.firewall file available from the Lab8 directory on the NAS server. The effects of these rules are to be examined. Setting up routing and iptables Some of the information given in this section will be only be clear and useful later on when you actually use iptables.

Think of it as Internet customs and immigration. The firewall is the agent that checks each item entering or leaving the network. Each item must pass the right criteria in order to make it through. So a hacker attempting to enter the network of California with a Florida orange would be stopped at the border. Firewalls use one or more of three methods to control traffic flowing in and out of the network:  Packet filtering - Packets (small chunks of data) are analyzed against a set of filters. Packets that make it through the filters are sent to the requesting system and all others are discarded.  Proxy service - Information from the Internet is retrieved by the firewall and then sent to the requesting system and vice versa.  Stateful inspection - A newer method that doesn't examine the contents of each packet but instead compares certain key parts of the packet to a database of trusted information. Information traveling from inside the firewall to the outside is monitored for specific defining characteristics, then incoming information is compared to these characteristics. If the comparison yields a reasonable match, the information is allowed through. Otherwise it is discarded. Exercise 1 No firewall functionality running From the BlackHat machine, use nmap to scan the Linux Machine behind the firewall. You can use the graphical interface for nmap with these options: SCAN -> SYN Stealth DISCOVER -> Don’t Ping OPTIONS -> Don’t resolve Fast Scan You can also use the command line with nmap –sS –P0 –n –F Q1.1. Write down which ports are open:

1.1.2. Firewall Configuration

Firewalls are customizable. This means that you can add or remove filters based on several conditions. Some of these are:  IP addressesDomain namesProtocols -IP (Internet Protocol) - the main delivery system for information over the Internet  TCP (Transport Control Protocol) - used to break apart and rebuild information that travels over the Internet  HTTP (Hyper Text Transfer Protocol) - used for Web pages  FTP (File Transfer Protocol) - used to download and upload files  UDP (User Datagram Protocol) - used for information that requires no response, such as streaming audio and video  ICMP (Internet Control Message Protocol) - used by a router to exchange the information with other routers  SMTP (Simple Mail Transport Protocol) - used to send text-based information (e-mail)

SNMP (Simple Network Management Protocol) - used to collect system information from a remote computer  Telnet - used to perform commands on a remote computer  PortsSpecific words and phrases - This can be anything. The firewall will sniff (search through) each packet of information for an exact match of the text listed in the filter. For example, you could instruct the firewall to block any packet with the word "X-rated" in it. The key here is that it has to be an exact match. The "X-rated" filter would not catch "X rated" (no hyphen). But you can include as many words, phrases and variations of them as you need. A software firewall, such as ZoneAlarm, can be installed on the computer in your home that has an Internet connection. This computer is considered a gateway because it provides the only point of access between your home network and the Internet. With a hardware firewall, the firewall unit itself is normally the gateway. A good example is the Linksys Cable/DSL router. It has a built-in Ethernet card and hub. Computers in your home network connect to the router, which in turn is connected to either a cable or DSL modem. You configure the router via a Web-based interface that you reach through the browser on your computer. You can then set any filters or additional information. Hardware firewalls are incredibly secure and not very expensive. Home versions that include a router, firewall, and Ethernet hub for broadband connections can be found for well under $100.

1.1.3. What It Protects You From:

There are many creative ways that unscrupulous people use to access or abuse unprotected computers. The level of security you establish will determine how many of these threats can be stopped by your firewall. The highest level of security would be to simply block everything. Obviously that defeats the purpose of having an Internet connection. But a common rule of thumb is to block everything, and then begin to select what types of traffic you will allow. You can also restrict traffic that travels through the firewall so that only certain types of information, such as e-mail, can get through. This is a good rule for businesses that have an experienced network administrator that understands what the needs are and knows exactly what traffic to allow through. For most of us, it is probably better to work with the defaults provided by the firewall developer unless there is a specific reason to change it. One of the best things about a firewall from a security standpoint is that it stops anyone on the outside from logging onto a computer in your private network. While this is a big deal for businesses, most home networks will probably not be threatened in this manner. Still, putting a firewall in place provides some peace of mind.

1.1.4. Demilitarized Zone

The firewall code in the current Linux kernel ( http://www.netfilter.org/ ) is called iptables or

netfilter (while there is a technical distinction, they're equivalent names for this discussion). The

crucial feature of this firewall is its modular design. You have the ability to add new types of

tests to perform on a packet and actions to take on it. These tests and action modules can be

added to a running kernel.

1.3.1. What’s going on in the kernel?

(taken from netfilter HOWTO by Rusty Russell) The kernel starts with three lists of rules in the ‘filter’ table; these lists are called firewall chains or just chains. The three chains are called INPUT , OUTPUT and FORWARD. The chains are arranged like so: (Note: this is a very different arrangement from the 2.0 and 2. kernels!) Figure 1-2 – Routing chains The three circles represent the three chains mentioned above. When a packet reaches a circle in the diagram, that chain is examined to decide the fate of the packet. If the chain says to DROP the packet, it is killed there, but if the chain says to ACCEPT the packet, it continues traversing the diagram. A chain is a checklist of rules. Each rule says ‘if the packet header looks like this, then here’s what to do with the packet’. If the rule doesn’t match the packet, then the next rule in the chain is consulted. Finally, if there are no more rules to consult, then the kernel looks at the chain policy to decide what to do. In a security-conscious system, this policy usually tells the kernel to DROP the packet.

  1. When a packet comes in (say, through the Ethernet card) the kernel first looks at the destination of the packet: this is called ‘routing’.
  2. If it’s destined for this box, the packet passes downwards in the diagram, to the INPUT chain. If it passes this, any processes waiting for that packet will receive it.
  1. Otherwise, if the kernel does not have forwarding enabled, or it doesn’t know how to forward the packet, the packet is dropped. If forwarding is enabled, and the packet is destined for another network interface (if you have another one), then the packet goes rightwards on our diagram to the FORWARD chain. If it is ACCEPTed, it will be sent out.
  2. Finally, a program running on the box can send network packets. These packets pass through the OUTPUT chain immediately: if it says ACCEPT, then the packet continues out to whatever interface it is destined for.

1.3.2. Creating your own rules

The iptables tool inserts and deletes rules form the kernel’s packet filtering table. Initially all chains are set to ACCEPT by default. A detailed description can be obtained from the man pages (man iptables). Commands to change chains:

  1. create a new chain (-N) NOTE: use upper case letters
  2. delete an empty chain (-X)
  3. list the rules for a chain (-L)
  4. flush a chain (delete all rules in a chain) (-F) Commands to add/delete rules:
  5. Append a new rules to a chain (-A)
  6. Delete a rule at some position in a chain, or the first that matches (-D) The sections Note: The examples in these sections only demonstrate particular rules. They may or may not work for the network setup for the lab.

1.4.0. Iptables Parameters

Parameters specify the type of packet that you are looking to match with your rule.

1.4.1. Specifying jump

If a packet matches one of your rules, you can tell the packet to jump to another chain with the ‘-j’ option

Example:

#jump all packets in INPUT chain to the drop CHAIN

iptables –A INPUT –j DROP

1.4.2. Specifying protocol

The protocol can be specified with the ‘–p’ option. Protocols can either be the number in the IP header or ‘tcp’, ‘udp’, or ‘icmp’ (case insensitive).

Example:

ESTABLISHED

A packet which belongs to an existing connection (i.e., a reply packet, or outgoing packet on a connection which has seen replies). RELATED A packet which is related to, but not part of, an existing connection, such as an ICMP error, or (with the FTP module inserted), a packet establishing an ftp data connection. INVALID A packet which could not be identified for some reason: this includes running out of memory and ICMP errors which don’t correspond to any known connection. Generally these packets should be dropped. An example of this powerful extension would be: iptables –A FORWARD –i eth0 –m state! –state NEW –j DROP

1.4.7 - Limit explanation

This module must be explicitly specified with -m limit' or--match limit'. It is used to restrict the rate of matches, such as for suppressing log messages. It will only match a given number of times per second (by default 3 matches per hour, with a burst of 5). It takes two optional arguments: --limit Followed by a number; specifies the maximum average number of matches to allow per second. The number can specify units explicitly, using /second',/minute', /hour' or/day', or parts of them (so 5/second' is the same as5/s'). --limit-burst Followed by a number, indicating the maximum burst before the above limit kicks in. This match can often be used with the LOG target to do rate-limited logging. To understand how it works, let's look at the following rule, which logs packets with the default limit parameters:

iptables -A FORWARD -m limit -j LOG

The first time this rule is reached, the packet will be logged; in fact, since the default burst is 5, the first five packets will be logged. After this, it will be twenty minutes before a packet will be logged from this rule, regardless of how many packets reach it (60 minutes / 3 packets per hour). This value of twenty minutes is because the default limit is 3/hour. Also, every twenty minutes which passes without matching a packet, one of the burst will be regained; if no packets hit the rule for 100 minutes, the burst will be fully recharged to 5 packets (100 minutes / 20mintes per packet); back where we started. Note: you cannot currently create a rule with a recharge time greater than about 59 hours, so if you set an average rate of one per day, then your burst rate must be less than 3.

You can also use this module to avoid various denial-of-service attacks (DoS) with a faster rate to increase responsiveness. Syn-flood protection (recall Datapool utility from Lab 3 for DoS using Syn Flood):

iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

or

iptables –N SYN-FLOOD

iptables –A SYN-FLOOD –m limit –-limit 20/s –-limit-burst 100 –j

RETURN

iptables –A SYN-FLOOD –j LOG –-log-prefix “SYN-FLOOD: ”

iptables –A INPUT –p tcp –-syn –j SYN-FLOOD

Furtive port scanner:

iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --

limit 1/s -j ACCEPT Ping of death:

iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit

1/s -j ACCEPT UDP Attack (from Lab 3):

iptables –N UDP-FLOOD

iptables –A UDP-FLOOD –m limit –-limit 20/s –-limit-burst 100 –j

RETURN

iptables –A UDP-FLOOD –j LOG –-log-prefix “UDP-FLOOD: “

iptables –A UDP-FLOOD –j DROP

iptables –A INPUT –p udp –j UDP-FLOOD

1.5.0. Network Address Translation (NAT)

There are two types of NAT, source NAT and destination NAT. Source NAT is when you alter the source address of the first packet: i.e. you are changing where the connection is coming from. Source NAT is always done post-routing, just before the packet goes out onto the wire. Masquerading is a specialized form of SNAT. A router might do masquerading for packets going from one of its internal machines to an outside connection. In this case it will change the source address of the machine to its own address. The external machine will see the packets coming from the router. Destination NAT is when you alter the destination address of the first packet: i.e. you are changing where the connection is going to. Destination NAT is always done before routing, when the packet first comes off the wire. Port forwarding, load sharing, and transparent proxying are all forms of DNAT. In the router example, the incoming packets intended for the internal machine are routed to it by changing the destination address to the internal address of the machine.

1.5.1 - NAT in the kernel

The most important option for the iptables command is the table selection option, -t'. For all NAT operations, you will want to use-t nat' for the NAT table. The second most important option to use is - A' to append a new rule at the end of the chain (e.g.-A POSTROUTING'), or -I' to insert one at the beginning (e.g.-I PREROUTING'). You can specify the source (-s' or--source') and destination (-d' or--destination') of the packets you want to NAT. These options can be followed by a single IP address (e.g. 192.168.1.1), a name (e.g. www.gnumonks.org), or a network address (e.g. 192.168.1.0/24 or 192.168.1.0/255.255.255.0). You can specify the incoming (-i' or--in-interface') or outgoing (-o' or--out-interface') interface to match, but which you can specify depends on which chain you are putting the rule into: at PREROUTING you can only select incoming interface, and at POSTROUTING you can only select outgoing interface. If you use the wrong one, iptables will give an error. You want to do Source NAT; change the source address of connections to something different. This is done in the POSTROUTING chain, just before it is finally sent out; this is an important detail, since it means that anything else on the Linux box itself (routing, packet filtering) will see the packet unchanged. It also means that the -o' (outgoing interface) option can be used. DNAT is done in the PREROUTING chain, just as the packet comes in; this means that anything else on the Linux box itself (routing, packet filtering) will see the packet going to itsreal' destination. It also means that the `-i' (incoming interface) option can be used.

1.5.3. Port Forwarding

When running a web server behind your firewall, you want to forward packets destined for that server through the firewall to that box.

Example:

Linux 2.

Append a rule before routing (-A PREROUTING) to the NAT table (-t nat) that

TCP packets (-p tcp) going to 1.2.3.4 (-d 1.2.3.4) port 80 (--dport 80)

have their destination mapped (-j DNAT) to 192.168.1.1, port 80

(--to 192.168.1.1:80).

iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 --dport 80 -j DNAT --to 192.168.1.1: NOTE: This only changes the destination of the packet, it does not automatically accept it in the forwarding chain. A rule must be made in the forwarding chain also.

1.5.4. Masquerading

There is a specialized case of Source NAT called masquerading: it should only be used for dynamically- assigned IP addresses, such as standard dialups. You don't need to put in the source address explicitly with masquerading: it will use the source address of the interface the packet is going out from. But more importantly, if the link goes down, the connections

(which are now lost anyway) are forgotten, meaning fewer glitches when connection comes back up with a new IP address.

Masquerade everything out ppp0.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

packet itself is considered to be part of the established connection, so no special rule is needed to allow the SYNACK packet itself. Allow all inputs to firewall from the internal network and local interfaces iptables -A INPUT -i vmnet1 -s 0/0 -d 0/0 -j ACCEPT iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT

1.6.3.Forwarding

Forward all http packets (port 80) to the internal VMware machine iptables -A PREROUTING -t nat –d 131.210.231.1 -p tcp --dport 80 -j DNAT --to 192.168.0.10: iptables –A FORWARD –i vmnet2 –p tcp -–dport 80 –j ACCEPT Forward all ssh packets (port 22) to the inside machine iptables -A PREROUTING -t nat –d 131.210.231.1 -p tcp --dport 22 -j DNAT --to 192.168.0.10: iptables –A FORWARD –i vmnet2 –p tcp -–dport 22 –j ACCEPT Turn on ip forwarding in case it wasn't already enabled echo "1" > /proc/sys/net/ipv4/ip_forward

1.6.4. Alternative to SNAT -- MASQUERADE

If your firewall has a dynamic IP number (Tech uses static IPs while most cable/DSL providers, such as ATT and Bellsouth, and all dial-up connections only offer dynamic IPs) because it connects to the internet itself via DHCP, then you probably cannot predict what the IP number is of your firewall's interface connected to the internet. In this case, you need a rule like the following that assigns the (an) IP number associated with vmnet2 to outgoing connections without you needing to know in advance (at time of writing this rule) what that IP number is: iptables -A POSTROUTING -t nat -o vmnet2 -j MASQUERADE Deny any packet coming in on the public internet interface vmnet2 which has a spoofed source address from our local networks: iptables -A INPUT -i vmnet2 -s 192.168.0.0/24 -j DROP iptables -A INPUT -i vmnet2 -s 127.0.0.0/8 -j DROP If you query a particular remote DNS server, permit UDP responses from it.

iptables -A INPUT -p udp -s --source-port 53 -d 0/0 -j ACCEPT

1.6.5. Defending against ICMP Ping Floods

ICMP ping floods are commonly used attacks, especially by “script kiddies.” The attack is really simple, the attacker ping floods you and if he has more upstream than your downstream, you won’t be able to access anything. Iptables allows you to specify how many ICMP “echo” packets you want to reply to. This can be done by adding the following: iptables -A INPUT –p icmp –-icmp-type echo-request –m limit -–limit 30/minute –-limit-burst 1 –j ACCEPT

“30/minute’ means accept every other packet. An attacker may still ping flood you, but you

won’t reply to it anyways, and he will give up soon. However, this also allows other people to ping

you, just to test the network connection. The burst is set to 1 packet, so this limit will immediately take effect. Our Linux based firewall is already completely setup since the iptables.firewall file is provided for us, and all of the machines behind the firewall are protected from harmful traffic. We will now run some tests to show the results of the firewall installation.

Exercise 3

Turn on the firewall rules by typing ./iptables.firewall (in the directory where your iptables.firewall is placed) If you have enabled the firewall before, you will need to flush the rules before executing the above command. Now rerun nmap from outside the firewall (BlackHat) on the Linux machine behind the firewall (Protected). Run nmap with these options: SCAN -> SYN Stealth DISCOVER -> Don’t Ping OPTIONS -> Don’t resolve Fast Scan TIMING -> Max RTT 40ms The command is _nmap –sS –P0 –n –F –max_rtt_timeout 40 _

iptables -A FORWARD -i vmnet2 -o vmnet1 -m state --state ESTABLISHED,RELATED -j ACCEPT Restart the firewall with the command /etc/rc.d/init.d/iptables stop ./iptables.firewall Repeat the previous ping and record and comment on the differences. Q1.6. Uncomment line 29 and restart the firewall. Explain what you saw and why:

Exercise 7

Restart ethereal on the firewall machine. Run with the options capture packets on ‘any’ interface, update packets in real time, and automatic scrolling. From BlackHat, ssh to 131.210.231. Q1.7. Record these output in ethereal and comment on what you saw happen:

Exercise 8

Now we are going to log any packets attempting to telnet to the firewall using the LOG chain.

iptables –A INPUT –d 131.210.231.1 –p tcp --dport 23 –j LOG --log-prefix ‘TELNET ATTEMPT: ‘

Attempt to telnet from your machine to the firewall. Check /var/log/messages for these telnet attemps and record the output from the messages file. type tail /var/log/messages to see the end of the /var/log/messages file. Q1.8. What did you see:

Exercise 9

Q1.9. Write down three rules that you think might be useful and explain what they do.

Now that you have set up a Firewall to filter unwanted traffic and block ports we are going to

explore a way to get around firewalls. One such way is through tunneling. Tunneling is

wrapping one protocol within another one, the protocol you are wrapping is one that would not

get by the firewall and the protocol you wrap it with is something that would get through the

firewall. For example, you could hide shell commands inside of an http get tcp command.

Since you are allowing users to use the internet in your DMZ their port 80s will be open and

those packets will not be filtered.

Reverse WWW Shell

Reverse WWW Shell is a tunneling program that uses an interesting approach to tunneling.

Instead of having the server listening on a port which can easily be detected it has the server

connect to the client to get instructions the client has left in a certain directory. The shell

commands in the Reverse WWW Shell look like http get calls and go through port 80 and look

like innocuous web traffic, even proxy firewalls will have a hard time determining if the packets

are malicious. It also has a random time frame for accessing the client so that it doesn't appear to

be automated, to help evade sysadmins even more.

Download the source from the NAS

(http://www.thc.org/releases/rwwwshell-2.0.pl.gz)

This is a shell script. So open it up in your favorite text editor and go to these lines

# MASTER CONFIG (specific for the MASTER)

$LISTEN_PORT=8080; # on which port to listen (80 [needs root] or 8080)

$SERVER="127.0.0.1"; # the host to run on (ip/dns) (the SLAVE needs this!)

We need to change the listen port to 80, since we have root on our master machine this is no

problem, now enter the IP address of your machine that the slave will access.

Now look at some of the options for the slave, we are going to need to change the timing of the

system in order to get immediate feedback from our system, choose a time within the next 20

minutes for your SLAVE to check for commands. Also set the DEBUG field to no. You can

also set eh delay between executing commands.

Now that we have the slave set up we need to install it on our slave system. Open your Redhat

7.2 Virtual machine and transfer the perl file to it. Now run:

$ rwwwshell.pl slave

now on the master run

$ rwwwshell.pl

If you were successful the slave will connect to the master at the time entered in the code and

allow you to type in root commands that will be executed on the slave system.

If you have your firewall running you can check to see whether the packets were filtered or not,

they shouldn't be with the standard 80 port open.

Q1.10 Open ethereal and capture a few of the shell packets, what is their format?

Q1.12 Why does the format of the protocol make it specially hard to catch with a firewall?

Q1.13 A common way network administrators check for backdoors running on their system is to

do a “netstat -na” Do this on your slave system, do you see an open port for the reverse www

shell? Why not?