Internet Security Linux Firewall Experiment Lab Report

Internet Security Linux Firewall Experiment Lab Report

Task 1: Using Firewall

Use a tool called iptables in Linux, which is essentially a firewall. It has a nice front end program called

ufw. In this task, the objective is to use ufw to set up some firewall policies, and observe the behaviors of your system after the policies become effective

After you set up the two VMs, you should perform the following tasks:

  • Prevent A from doing telnet to Machine B.
  • Prevent B from doing telnet to Machine A.
  • Prevent A from visiting an external web site. You can choose any web site that you like to block, but keep in mind, some web servers have multiple IP addresses.

For this task, we need to set up at least two VMs. I set up two VMs, ZY_VM1 (192.168.56.101) and ZY_VM2 (192.168.56.102) that is shown in Figure 2.1.1 below.

 Image

Figure 2.1.1

Each of the VMs has two network adapters, one is host-only and the other one is NAT. In this way, the two VMs are in the same local network and they can access external website.

Now let’s start the telnet server on ZY_VM1 and ZY_VM2. Then telnet from ZY_VM1 to ZY_VM2 and telnet from ZY_VM2 to ZY_VM1. The results are shown in Figure 2.1.2 and Figure 2.1.3 below.

We can see from the two figures, without the firewall, we can successfully telnet from one VM to another VM.

Image

Figure 2.1.2

Image

Figure 2.1.3

Now it’s time to open the firewall and try this again.

First of all, we need to open the ufw on Linux and modify this configuration file. Change “DeFAULT_INPUT_POLICY” from “DROP” to “ACCEPT”. We change the default settings of ufw to allow incoming and outgoing information. Then we save it.

 Image

Figure 2.1.4

By reading the content of the url below:

https://help.ubuntu.com/community/UFW#UFW__Uncomplicated_Firewall, we know we can use “sudo ufw enable” to enable the ufw. Now let’s start the ufw.

 Image

Figure 2.1.5

As we can see from Figure 2.1.5, we can successfully start ufw. Let’s use “ufw status verbose” to check the status of ufw.

 Image

Figure 2.1.6

In Figure 2.1.6, we have no policies currently. Because we change the configuration file of ufw, the incoming and outgoing are all allowed by default. If we only want to prevent telnet from ZY_VM1 to ZY_VM2, we can use “sudo ufw deny out from 192.168.56.101 port 23 to 192.168.56.102 port 23” on ZY_VM1 to deny the telnet access to ZY_VM2. Similarly, we can use “sudo ufw deny in from 192.168.56.102 port 23 to 192.168.56.101 port 23” on ZY_VM1 to deny the telnet access to ZY_VM1 from ZY_VM2.

Figure 2.1.7

In Figure 2.1.7, it shown we successfully added two policies on ZY_VM1.

Now let’s try to telnet from ZY_VM1 to ZY_VM2 and from ZY_VM2 to ZY_VM1.

 Image

Figure 2.1.8

In Figure 2.18, it is shown that we cannot connect from one VM to the other.

There is one problem left, try to prevent ZY_VM1 to ping outside web site with a static IP address. Let’s take “syr.edu” as an example. Now we use ZY_VM1 to ping www.syr.edu. The result is shown in Figure 2.1.9 below.

Image

Figure 2.1.9

What if we try to open syr.edu in the browser on ZY_VM1? The result is shown in Figure 2.1.10 below.

 Image

Figure 2.1.10

We can see from Figure 2.1.9, we can successfully ping syr.edu with a static IP address, 128.230.171.184 under current condition.  And we can open syr.edu in our browser on ZY_VM1 in Figure 2.1.10. We need to add one more policy on ZY_VM1 to prevent this.

Image

Figure 2.1.11

We can see from Figure 2.1.11. The browser can no longer access www.syr.edu any more. It will always get connection time out. At the terminal, we successfully added the rule to deny out to www.syr.edu. And if we ping to syr.edu, we will get “Operation not permitted” and “100% packet loss”.

Task 2: How Firewall Works

Question 1

What types of hooks does Netfilter support, and what can you do with these hooks? Please draw a diagram to show how packets flow through these hooks.

Answer:

The diagram is shown in Figure 2.2.1 below.

Image

Figure 2.2.1

In Figure 2.2.1, the ellipses with number 1 to 5 are the hooks. When a NIC receive a packet, the machine may route the packet directly or route the packet after processing it. This logic can be seen from the arrows in Figure 2.2.1. So there are five types of hooks.

Hook 1, shown as the ellipse with number 1 in Figure 2.2.1, is pre-routing netfilter hook. It can capture the packet before routing.

Hook 2 is local in netfilter hook. It can capture the packet when the packet comes into the computer before processing.

Hook 3 is forward netfilter hook. It can grab the packet when forwarding to the other address.

Hook 4 is post routing netfilter hook. It can grab the packet after routing and check everything.

Hook 5 is local out netfilter hook. It can capture the packet when the packet going out. It can block the traffic out the whole local network. With these hooks, the netfilter can capture the packet at whatever time it wants and decide what to do next, maybe dropping the packet, processing the packet or just letting it pass through.

Question 2

Where should you place a hook for ingress filtering, and where should you place a hook for egress filtering?

Answer:

According to Figure 2.2.1. Hook 1 and Hook 2 can be used for ingress filtering. The difference is that Hook 1 can capture the packet before the packet comes into the computer. On the other hand, Hook 2 can capture the packet when the packet comes into the computer. So we can place a hook at Hook 1 or Hook 2 according to whether we want to capture the packet before the packet comes into the computer.

In Figure 2.2.1, we can see that Hook 4 and 5 can be used as egress filtering. We don’t choose Hook 3 because it pass through the packet. Hook 4 can check everything of the packet. But Hook 5 only capture the packet after processing. So which one is better really depends on our purpose. If we want to capture all the packets going out from the whole network, Hook 4 is absolutely better. Otherwise, if we only want to capture packets going out from a single computer, Hook 5 is our perfect choice.

Question 3

Can you modify packets using Netfilter?

Answer:

I think the answer should be “yes”. Since we can capture the packet, we can modify the packets.

Task 2 Process

Now let’s finish our task.

First of all, we need to set up our Debian-based Linux environment for building kernel modules. The result is shown in Figure 2.2.2 below.

Image

Figure 2.2.2

  1. sudo su
  2. apt-get install module-assistant
  3. m-a prepare

These three commands above that appear in the red box in Figure 2.2.2 will set up the appropriate build environment for you (including correct linux-headers andbuild-essential).

Since we need to support at least five different rules, we can support all the hooks described in Figure 2.2.1.

Secondly, we need to create a module. I created a file named as “task2.c”.

Remember the three small tasks in the previous task:

  • Prevent A from doing telnet to Machine B. For this, we can use Hook 5.
  • Prevent B from doing telnet to Machine A. For this, we can use Hook 2.
  • Prevent A from visiting an external web site. You can choose any web site that you like to block, but keep in mind, some web servers have multiple IP addresses. For this, we can use Hook 4 or 5. Let’s just take Hoo5 as example.

So for now we already have three rules. We need to add two more rules. Let’s try to prevent B from doing ping to A and prevent A from dong ping to external web site. So we have 5 rules now. They are:

  1. Prevent ZY_VM1 from doing telnet to ZY_VM2
  2. Prevent ZY_VM2 from doing telnet to ZY_VM1
  3. Prevent ZY_VM1 from visiting www.syr.edu
  4. Prevent ZY_VM2 from doing ping to ZY_VM1
  5. Prevent ZY_VM1 from doing ping to www.sry.edu

According to these five rules, we can see we need at least two kinds of netfilter hooks. Let’s choose Hook2, local-in hook, and Hook5, local-out hooking. The source code of task2.c is as follows. I write the code description in code comments and use italic font style.

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/net.h>

#include <linux/types.h>

#include <linux/skbuff.h>

#include <linux/string.h>

#include <linux/netdevice.h>

#include <linux/netfilter.h>

#include <linux/netfilter_ipv4.h>

#include <linux/in.h>

#include <linux/ip.h>

#include <linux/tcp.h>

// Description: In order to check the destination IP address, we need to convert it to string format.

#include <linux/byteorder/generic.h>

// Description: I create two nf_hook_ops. One for local-in, the other one for local-out.

static struct nf_hook_ops local_in_nfho;        // net filter used for local-in

static struct nf_hook_ops local_out_nfho;       // net filter used for local-out

struct sk_buff *sock_buff;

// Description: In order to prevent two virtual machines from doing telnet, we nee tcphdr.

struct tcphdr *tcp_header;              //tcp header struct

struct iphdr *ip_header;                //ip header struct

// Description: This function is used for local in hook function.

unsigned int local_in_hook_func(unsigned int hooknum, struct sk_buff **skb, const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *))

{

sock_buff = skb;

ip_header = (struct iphdr *)skb_network_header(sock_buff);    //grab network header using accessor

if(!sock_buff) { return NF_ACCEPT;}

// Description: Hard coding ZY_VM2’s IP address and www.syr.edu ‘s IP address

char *ZY_VM2 = “192.168.56.102 “;       // hardcoding ZY_VM2’s IP address

char *SYR = “128.230.171.184 “;         // hardcoding SYR’s IP address

// Description: if we got tcp packet

// Rule 2: prevent ZY_VM2 from doing telnet to ZY_VM1

if (ip_header->protocol == 6)

{

// Description: In order to check the destination IP address, we need to convert it to string format

int size = 15;

char *str[size];

snprintf(str, size, “%pI4”, &ip_header->saddr);

if(strcmp(str, ZY_VM2))

{

tcp_header = (struct tcphdr *)skb_transport_header(sock_buff);

char *TELNET_PORT = “23”;

int port_size = 2;

char *port_str[size];

snprintf(port_str, port_size, “%pI4”, &tcp_header->dest);

if(strcmp(str, TELNET_PORT))

{

// Description: Only if we got tcp packet and its destination port is 23, we will drop it and print

// information to the kernel. Other packets will not be dropped.

printk(KERN_INFO “got and dropped tcp packet incoming from %s to port %s\n”, str, TELNET_PORT);

return NF_DROP;

}

}

}

// Description: if we got icmp packet

// Rule 4: prevent ZY_VM2 from doing ping to ZY_VM1

if (ip_header->protocol==1)

{

int size = 15;

char* str[size];

snprintf(str, size, “%pI4”, &ip_header->saddr);

if(strcmp(str, ZY_VM2))

{

printk(KERN_INFO “got and dropped icmp packet incoming from %s \n”, str);

return NF_DROP;

}

}

return NF_ACCEPT;

}

// Description: This function is used for local out hook function.

unsigned int local_out_hook_func(unsigned int hooknum, struct sk_buff **skb, const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *))

{

sock_buff = skb;

ip_header = (struct iphdr *)skb_network_header(sock_buff);    //grab network header using accessor

if(!sock_buff) { return NF_ACCEPT;}

// Description: Hard coding ZY_VM2’s IP address and www.syr.edu ‘s IP address

char *ZY_VM2 = “192.168.56.102 “;       // hardcoding ZY_VM2’s IP address

char *SYR = “128.230.171.184 “;         // hardcoding SYR’s IP address

// Description: if we got tcp packet

// Rule 1: prevent ZY_VM1 from doing telnet to ZY_VM2

if (ip_header->protocol == 6)

{

int size = 15;

char *str[size];

snprintf(str, size, “%pI4”, &ip_header->daddr);

if(strcmp(str, ZY_VM2))

{

tcp_header = (struct tcphdr *)skb_transport_header(sock_buff);

char *TELNET_PORT = “23”;

int port_size = 2;

char *port_str[size];

snprintf(port_str, port_size, “%pI4”, &tcp_header->dest);

if(strcmp(str, TELNET_PORT))

{

printk(KERN_INFO “got and dropped tcp packet going out to %s with port %s\n”, str, TELNET_PORT);

return NF_DROP;

}

}

}

// Description: if we got icmp packet

// Rule 5: prevent ZY_VM1 from doing ping to http://www.syr.edu

if (ip_header->protocol==1)

{

int size = 16;

char* str[size];

snprintf(str, size, “%pI4”, &ip_header->daddr);

if(strcmp(str, SYR))

{

printk(KERN_INFO “got and dropped icmp packet out going to %s \n”, str);

return NF_DROP;

}

}

// Rule 3: prevent ZY_VM1 visiting http://www.syr.edu

/*

// Description: If you want to use this rule, please uncomment these lines of code

int size = 16;

char* str[size];

snprintf(str, size, “%pI4”, &ip_header->daddr);

if(strcmp(str, SYR))

{

printk(KERN_INFO “prevent visiting %s \n”, SYR);

return NF_DROP;

}

*/

return NF_ACCEPT;

}

int init_module()

{

// Description: set two nf_hook_ops and register them

local_in_nfho.hook = local_in_hook_func;

local_in_nfho.hooknum = NF_INET_LOCAL_IN;       /* Local-in hook */

local_in_nfho.pf = PF_INET;                     /* IPV4 protocol hook */

local_in_nfho.priority = NF_IP_PRI_FIRST;       /* Hook to come first */

nf_register_hook(&local_in_nfho);               /* And register… */

local_out_nfho.hook = local_out_hook_func;

local_out_nfho.hooknum = NF_INET_LOCAL_OUT;     /* Local-out hook */

local_out_nfho.pf = PF_INET;                    /* IPV4 protocol hook */

local_out_nfho.priority = NF_IP_PRI_FIRST;      /* Hook to come first */

nf_register_hook(&local_out_nfho);              /* And register… */

return 0;

}

void cleanup_module()

{

nf_unregister_hook(&local_in_nfho);             /* Remove IPV4 hook */

nf_unregister_hook(&local_out_nfho);            /* Remove IPV4 hook */

}

Because I commented the code for Rule 3. I will explain Rule 1, 2, 4 and 5 first. Then I will come back to Rule 3. This is because Rule 3 prevent ZY_VM1 from any type of visiting towww.syr.edu and we cannot ping to www.syr.edu either. However, Rule 5 only prevent ZY_VM1 from doing ping to www.syr.edu and we should still be able to visit www.syr.edu. That’s the difference from these two rules.

Rule 1: prevent ZY_VM1 (192.168.56.101) from doing telnet to ZY_VM2 (192.168.56.102).

Let’s first make the module and activate it. The result is shown in Figure 2.2.3 below.

 Image

Figure 2.2.3

In Figure 2.2.3, we can see the module is successfully activated. And we can see task2 is running by using “lsmod”. Let’s use “sudo lsmod” to see the result.

Now that’s try to telnet ZY_VM2, 192.168.56.102. The result is shown in Figure 2.2.4.

 Image

Figure 2.2.4

We can see from Figure 2.2.5, if we telnet to ZY_VM2, we will get “connection timed out”. And now let’s see the log messages using “dmesg”.

 Image

Figure 2.2.5

We can see a lot of “got and dropped tcp packet going out to 192.168.56.102 with port 23”. This is exactly what we want to see.

Rule 2: prevent ZY_VM2 (192.168.56.102) from doing telnet to ZY_VM1 (192.168.56.101).

Now let’s just try to telnet from ZY_VM2 to ZY_VM1. The result is shown in Figure 2.2.6 below.

Image

Figure 2.2.6

We can see from Figure 2.2.6, we are still on the same state of ZY_VM1 as the previous rule and we cannot telnet from ZY_VM2 to ZY_VM1. Now let’s see the log messages on ZY_VM1.

 Image

Figure 2.2.7

We can see lots of “got and dropped tcp packet incoming from 192.168.56.102 to port 23”.

Rule 4: prevent ZY_VM2 from doing ping to ZY_VM1

Now let’s just ping from ZY_VM2 to ZY_VM1.

 Image

Figure 2.2.8

We can see from Figure 2.2.8, we are still on the same state of ZY_VM1 as the previous rule and we cannot ping from ZY_VM2 to ZY_VM1. We cannot get any reply back. It will always be waiting. If we stop the ping, we will see “100% packet loss”. On ZY_VM1, we can see lots of “got and dropped icmp packet incoming from 192.168.56.102”.

Rule 5: prevent ZY_VM1 from doing ping to www.syr.edu

Now let’s try to ping from ZY_VM1 to www.syr.edu.

Image

Figure 2.2.10

We can see from Figure 2.2.10, we cannot ping from ZY_VM1 to www.sry.edu. We will always get “Operation not permitted”. And if we stop the ping, we will get “100% packet loss”. But we can visit it. Now let’s see the log messages on ZY_VM1.

 Image

Figure 2.2.11

We can see lots of “got and dropped icmp packet out going to 128.230.171.184”.

Rule 3: prevent ZY_VM1 visiting http://www.syr.edu

Now let’s uncomment the code in local_out_hook_func for Rule 3.

 Image

Figure 2.2.12

With this code, let’s stop the module and re-make it. Then we re-activate it.

 Image

Figure 2.2.13

We can see task2 is successfully re-made and re-activated. Now let’s tyr to visit www.syr.edu.

 Image

Figure 2.2.14

We can see if we open a new tag on Firefox and visit www.syr.edu again. We cannot visit it any more. Let’s see the log messages.

 Image

Figure 2.2.15

We can see lots of “prevent visiting 128.230.171.184”.

Task 3: Evading Egress Filtering

Task 3.a: Telnet to Machine B through the firewall

For this task, we need to start the telnet server on ZY_VM2 and ZY_VM3.

First of all, before we set the firewall on ZY_VM1. Let’s try to telnet from ZY_VM1 to ZY_VM2.

 Image

Figure 3.a.1

In Figure 3.a.1, we can see that we successfully start the telnet server on ZY_VM2 and ZY_VM3 and we can successfully telnet from ZY_VM1 to ZY_VM2.

Now let’s start the ufw firewall on ZY_VM1 and try to telnet to ZY_VM3 again. Here, the setting of ufw is the same as shown in Figure 2.1.4 in Task 1.

 Image

Figure 3.a.2

We can see from Figure 3.a.2, we successfully added two policies to the firewall and we cannot telnet 192.168.56.102 which is ZY_VM2 anymore.

OK. Now we have set the background. Let’s try to build SSH tunnel between ZY_VM1 and ZY_VM3.

 Image

Figure 3.a.3

Figure 3.a.3 shows that we successfully build the SSH tunnel between ZY_VM1 and ZY_VM3 and the IP address has changed to ZY_VM3. Now that try to telnet from ZY_VM1 to ZY_VM2 again.

Image

Figure 3.a.4

We can see from Figure 3.a.4 that we successfully telnet to ZY_VM2 again and the IP address changed to ZY_VM2. When I modify this lab report, I realize that we can use two terminals on ZY_VM1, one for building the SSH tunnel to ZY_VM3. The other one is used for telnet localhost 8000 to see if we can login to ZY_VM2. The following is the result.

Image

Figure Modify1

In Figure Modify1, we can see that, when we disable ufw, we can telnet to ZY_VM2. But when we enable the ufw, we cannot telnet to it. However, after we use another terminal to build the SSH tunnel to ZY_VM3, we can telnet localhost 8000 to telnet to ZY_VM2. And we can see after the telnet, our IP address become 192.168.56.102 which is ZY_VM2.

Let’s exit the ssh tunnel and try to telnet to ZY_VM2 again.

 Image

Figure 3.a.5

We can see in Figure 3.a.5 that if we exit the SSH tunnel between ZY_VM1 and ZY_VM3, we cannot telnet to ZY_VM2 anymore.

Task 3.b: Connecting to www.syr.eduusing SSH Tunnel.

To achieve this goal, we can use the approach similar to that in Task 3.a, i.e., establishing a tunnel between you localhost:port and Machine B, and ask B to forward packets to Facebook. To do that, you can use the following command to set up the tunnel: “ssh -L 8000:128.230.171.184:80 …”. We will not use this approach, and instead, we use a more generic approach, called dynamic port forwarding, instead of a static one like that in Task 3.a. To do that, we only specify the local port number, not the final destination. When Machine C receives a packet from the tunnel, it will dynamically decide where it should forward the packet to based on the destination information of the packet.

Before we set up the SSH tunnel. We need to clear the history of Firefox. Then we cannot visitwww.syr.edu when the ufw firewall is enabled.

 Image

Figure 3.b.1

Figure 3.b.1 shows that we cannot visit www.syr.edu. Now let’s build the SSH tunnel between ZY_VM1 and ZY_VM3.

Image

Figure 3.b.2

We successfully built the SSH tunnel between ZY_VM1 and ZY_VM3. Now we need to set up Firefox.

Image

Figure 3.b.3

OK. After we set up the Firefox, let’s try to visit www.syr.edu and use Wireshark to check the network traffic.

Image

Figure 3.b.4

Now we can visit www.syr.edu again and in the Wireshark we can see there are lots of traffic between ZY_VM1, 192.168.56.101 and ZY_VM3, 192.168.56.103.

Now let’s exit the SSH tunnel, clear history of Wireshark and visit www.syr.edu again.

Image

Figure 3.b.5

Figure 3.b.5 shows that we cannot visit www.syr.edu again. And the difference between once that we cannot visit before is that this time it says “Proxy server is refusing connections”. I think this is because I once set up the Firefox as shown in Figure 3.b.3. All the packets will be transport to localhost 9000. And with the SSH tunnel we built in Figure 3.b.2, all the packets to localhost 9000 will be sent to ZY_VM3 192.168.56.103 within the SSH tunnel. And then ZY_VM3 will deliver the packets to www.syr.edu.

However, if we break the SSH tunnel, localhost 9000 is refusing connections. So we will see “Proxy server is refusing connections” on Firefox. And in Wireshark, we cannot see any traffic between ZY_VM1 and ZY_VM3 anymore.

Now let’s build the SSH tunnel again. If we can visit www.syr.edu again. My explanation will be proved.

Image

Figure 3.b.6

Now we can visit www.syr.edu again and in Wireshark we can see there are lots of traffic between ZY_VM1 and ZY_VM3 again.

According to the observation above, we can get the conclusion that with a tunnel between ZY_VM1 and ZY_VM3, they can send SSH packets without being blocked by firewall. This is because ufw firewall only blocked port 23 and SSH is using port 22. And by using these packet, ZY_VM1 can visit any external website by sending packets to ZY_VM3. ZY_VM3 will send the packets to the destination website. The destination will send reply to ZY_VM3 and ZY_VM3 will receive the reply packets. And ZY_VM3 will send the reply packets back to ZY_VM1 using SSH tunnel.

Question 4

If ufw blocks the TCP port 22, which is the port used by SSH, can you still set up an SSH tunnel to evade egress filtering?

Answer:

The answer is yes. We can change the port number of SSH from 22 to the other number, for example 1106. And we can activate port 1106. Then we can build SSH tunnel with port 1106 next time.

We open the configuration file of SSH using “vi /etc/ssh/sshd_config”.

 Image

Figure Q4.1

We can change the port number from 22 to 1106 and save the file as shown in Figure Q4.1.

Task 4: Web Proxy (Application Firewall)

Task 4.a: Setup.

Let’s set up two VMs, ZY_VM1, 192.168.56.101 and ZY_VM2, 192.168.56.102. ZY_VM1 is the one whose browsing behaviors need to restricted, and ZY_VM2 is where you run the web proxy. We need to configure ZY_VM1’s Firefox browser, so it always use the web proxy server on ZY_VM2. To achieve that, we can tell Firefox to use ZY_VM2:3128 as its proxy (by default, squid uses port 3128, but this can be changed in squid.conf). The following procedure configures ZY_VM2:3128 as the proxy for Firefox.

 Image

Figure 4.a.1

In Figure 4.a.1, now we have configured the Firefox on ZY_VM1 according to the description of the previous paragraph. Let’s try to visit some web sites from ZY_VM1’s Firefox browser.

 Image

Figure 4.a.2

Figure 4.a.2 shows that we cannot visit www.syr.edu. And if we open the Wireshark we can see ZY_VM2 forbidden the traffic to it. So the external web sites are blocked.

Image

Figure 4.a.3

In Figure 4.a.3, we can see that the default rule is http_access deny all on ZY_VM2. When we start the service of squid3 on ZY_VM2, we cannot visit external websites using this proxy on ZY_VM1. And we also see there is a space where we can insert our own rules. Now let’s insert our own rules “http_access allow all”, restart it and try to visit external websites on ZY_VM1 again.

Figure 4.a.4 next page clearly shows that, after we insert our own rule and restart the squid service on ZY_VM2 again, we can visit www.syr.edu. And in the Wireshark on both virtual machines, we can see lots of traffic between ZY_VM1 and ZY_VM3.

If we change the rule to “http_access www.google.com”, we suppose we can only visitwww.google.com and we cannot visit any other external websites. The result is shown in Figure 4.a.6 and Figure 4.a.7 next page.

Image

Figure 4.a.4

Figure 4.a.4 shows we successfully use our new rule to visit external website. By reading the comments of squid.conf, we can know we can use the commands like the followings in Figure 4.a.5 to define a acl name.

 Image

Figure 4.a.5

As Figure 4.a.5 shows, we can use “acl google_domain dstdomain .google.com” and “http_access google_domain” to only allow visiting to www.google.com.

 Image

Figure 4.a.6

Figure 4.a.6 shows that we successfully add the new rule to our proxy. And after we restart squid and visit www.google.com on ZY_VM1, the Wireshar on ZY_VM2 will capture the traffic between ZY_VM1 and ZY_VM2. Because one screenshot cannot clear contain both ZY_VM1 and ZY_VM2’s whole screen. ZY_VM1’s screen shot is shown in Figure 4.a.7 below.

 Image

Figure 4.a.7

Figure 4.a.7 shows that we cannot visit www.syr.edu but we can visit www.google.com and the Wireshark on ZY_VM1 captures lots of traffic between ZY_VM1 and ZY_VM2. We can see the time of the packets on both ZY_VM1 and ZY_VM2’s Wiresharks are the same.

Based on the observation above, we can see that if we are using web proxy, when we visit external websites, the packets first are sent to the web proxy, then the web-proxy will decide whether to send the packets or not according to its own configuration. What’s more, by reading the configuration file of squid, we can know that the web-proxy can deny or allow not only websites but also the port numbers.

Task 4.b: Using Web Proxy to evade Firewall.

Ironically, web proxy, which is widely used to do the egress filtering, is also widely used to bypass egress filtering. Some networks have packet-filter type of firewall, which blocks outgoing packets by looking at their destination addresses and port numbers. For example, in Task 1, we use ufw to block the access of www.syr.edu. In Task 3, we have shown that we can use a SSH tunnel to bypass that kind of firewall. In this task, we should do it using a web proxy.

 Image

Figure 4.b.1

Figure 4.b.1 shows that if we change the settings of Firefox on ZY_VM1 to use no proxy. We can visit www.syr.edu on Firefox. But if we turn on the lwfw on ZY_VM1, we cannot visit it.

 Image

Figure 4.b.2

Figure 4.b.2 shows that with the ufw firewall blocking traffic to www.syr.edu, we cannot visit it. However, if we use the web proxy in the previous task and add a rule “http_access allow all” to ZY_VM2’s squid.conf. We suppose we can visit www.sry.edu even if the ufw firewall is still running on ZY_VM1.

 Image

Figure 4.b.3

In Figure 4.b.3, we can see the ufw firewall on ZY_VM1 is still running since the time 13:12. We change the setting of Firefox on ZY_VM1 to use the previous web proxy. On ZY_VM2 we add our rule to allow all external websites. And restart the squid service on ZY_VM2 and the time is 13:20. If we open the Wireshark on ZY_VM1 and visit www.syr.edu again, Wireshark can capture lots of traffic between the two VMs and the time is 13:22.

Question 5

If ufwblocks the TCP port 3128, can you still use web proxy to evade the firewall?

Answer:

The answer is yes. We can use the other port, for example 1106 and modify the squid.conf on ZY_VM2 to use port 1106. Then we can still use web proxy to evade the firewall even if the ufw on ZY_VM1 block TCP port 3128.

Before we change the squid port on ZY_VM2.

Image

Figure Q5.1

Figure Q5.1 shows that, the port number of squid on ZY_VM2 is still 3128. The ufw on ZY_VM1 has blocked access to port 3128. Then we use the same settings of Firefox on ZY_VM1. But we cannot visit www.syr.edu and Wireshark cannot find traffic to ZY_VM2. I don’t want to explain the time sequence again. We can clearly see the time sequence in the Figure and they are making sense. Now let’s change the port number of squid to 1106 on ZY_VM2 and change the settings of Firefox using HTTP proxy 192.168.56.102 with port 1106 on ZY_VM1. Then visitwww.syr.edu again on ZY_VM1.

Image

Figure Q5.2

We can see from Figure Q5.2, we changed the port number of squid to 1106 on ZY_VM2 and restart the squid service. On ZY_VM1 we change the web proxy’s port number to 1106. And we can see the ufw is still running on ZY_VM1 since 13:32. Then if we open Wireshark on ZY_VM1 and visit www.sry.edu again, we can see we can successfully open the website and Wireshark can capture lots of traffic between the two VMs.

Task 4.c: URL Rewriting/Redirection.

No. 1

This is the code of myprog.cl in Figure 4.c.1. I put this file in the folder of /home/seed/.

 Image

Figure 4.c.1

The program in Figure 4.c.1 aims at rewriting the url of www.cis.syr.edu to www.yahoo.com.

Image

Figure 4.c.2

Figure 4.c.2 shows that if we start the squid service on ZY_VM2 and we visit www.cis.syr.edu on ZY_VM1 we will be directed to www.yahoo.com. This is because we add the previous url_rewrite_program. One more important thing is that in order to run the url_rewrite_program we need to change the privilege of the file using “sudo chmod a+x myprog.pl”. Then we can use the program. Once we start the squid service, the url rewriting program is called. When we visitwww.cis.syr.edu on ZY_VM1, there will be traffic between ZY_VM1 and ZY_VM2 as we can see in the Wireshark on both sides. And then the url rewriting program will rewrite the url towww.yahoo.com. So we will see yahoo page on ZY_VM1. And In the
Wireshark on ZY_VM2 we can see once the original url should be www.cis.syr.edu.

Image

Figure 4.c.3

I move the window of ZY_VM2 so that we can clearly see the Wireshark in ZY_VM1. We can see that once the orginal url is www.cis.syr.edu but we are directed to www.yahoo.com.

No. 2

For this task, I found a red stop sign onhttp://humanproductivitylab.com/images/website_pics/stop_sign.jpg. Let’s use this url to replacewww.cis.syr.edu.

First of all we need to change myprog.pl as followings:

Image

Figure 4.c.4

As we can see from Figure 4.c.4 we change print “http://www.yahoo.com” to “http:://www.humanproductivitylab.com/images/website_pics/stop_sign.jpg”.

Let’s restart the squid service, clear the history of Firefox on ZY_VM1 and then visitwww.cis.syr.edu on ZY_VM1 again.

Image

Figure 4.c.5

Figure 4.c.5 shows that when we visit www.cis.syr.edu, the whole page is a red stop sign that I found on the internet. In the Wireshark on ZY_VM2, we can clearly see lots of traffic between ZY_VM1 and ZY_VM2. And there is a HTTP packet sending an JPEG image to ZY_VM1’s IP address. This image is what we see on Firefox on ZY_VM1.

No. 3

For this task, let’s use the same red stop sign image in the previous task.

First of all, we also need to modify myprog.pl.

Image

Figure 4.c.6

In Figure 4.c.6, if the url is a jpg file, let’s rewrite the url to our red stop sign.

Now let’s restart the squid service on ZY_VM2 and visit www.syr.edu on ZY_VM1.

Image

Figure 4.c.7

In Figure 4.c.7, we can see if we visit www.syr.edu, we wil see that all the images are replaced by our red stop sign. That’s because our url rewriting program have rewrote all the jpg url to our stop sign. And we can see on the Wireshak of ZY_VM2, there are lots of traffic between ZY_VM1 and ZY_VM2.

Question 6

We can use the SSH and HTTP protocols as tunnels to evade the egress filtering. Can we use the ICMP protocol as a tunnel to evade the egress filtering? Please briefly describe how.

Answer:

The answer is yes.

ICMP tunneling works by injecting arbitrary data into an echo packet sent to a remote computer. The remote computer replies in the same manner, injecting an answer into another ICMP packet and sending it back. The client performs all communication using ICMP echo request packets, while the proxy uses echo reply packets. [1]

 Image

Figure Q6.1 [2]

The client will perform all its communications using ICMP echo request (ping) packets (type 8), whereas the proxy will use echo reply packets (type 0). They all use raw sockets.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s