group projects phase i

W4140 Network Laboratory

Lecture 8Oct 30 - Fall 2006

Shlomo HershkopColumbia University

Announcements

Last lab will be due next week due to hardware issues

will be working on it

today: Group presentations please save questions for end if you have an idea, please share need to coordinate between groups/racks

Here are the group presentations

Virtual Private Networks

Gilbert Hom (gch2102@columbia.edu)Mohit Vazirani (mcv2107@columbia.edu)Eric Zhang (ehz2101@columbia.edu)

Purpose

Learn about how VPNs establish secure channels in a volatile and inherently insecure environment

Explore VPN options in Windows and Linux and learn about how different implementations interact

Phase 1 Goals

Set up a VPN server and several VPN clients

The VPN server will run Windows 2000/2003 Server; the clients will run Windows XP

Observe traffic flow and encryption between machines with Ethereal/tcpdump

Network SetupRouter2

E0/0: 10.0.2.2/24 E0/1: 10.0.3.1/24

Hub

Server/PC1E0/0: 10.0.1.11/24

This topology simulates the internet: The server and clients are on different subnets, and there may be multiple paths available to the server from the client.

Router3E0/0: 10.0.2.3/24 E0/1: 10.0.3.2/24

Router1E0/0: 10.0.1.1/24 E0/1: 10.0.2.1/24

Hub

Router4E0/0: 10.0.3.4/24E0/1: 10.0.4.1/24

PC2E0/0: 10.0.4.2/24

PC4E0/0: 10.0.4.3/24

PC3E0/0: 10.0.4.4/24

Tools

Windows 2000 Server, Windows XP – Built-in support for VPN connections and firewalls through network configuration options

Linux – Openswan (Open source IPsec implementation for Linux) for VPN and iptables for firewalling

Ethereal – To monitor network traffic and verify that the communication is encrypted.

OpenSSL – To generate certificates needed for authentication.

Research Papers

M. Blaze, J. Ioannidis, and A. Keromytis. “Trust Management and Network Layer Security Protocols.” In Proceedings of the 1999 Cambridge Security Protocols International Workshop, 1999. http://citeseer.ist.psu.edu/643312.html

R. Gawlick, C. Kamanek, and K.G. Ramakrishnan. “On-line routing for virtual private networks.” Unpublished manuscript, February 1994. http://citeseer.ist.psu.edu/186679.html

Man-in-the-middle Attackusing ARP Poisoning

Arezu Moghadam (amm2141)Armando Ramirez (alr2106)

Mark Tabry (met2105)

Project Objective

ARP protocol insecure by design Possible to impersonate

routers/clients Nature of wireless networks

compound the problem Inject our attacker between client

and router, and manipulate traffic

Phase One Goals

Poison ARP caches of router and client

Set up attacker’s IP forwarding Man-in-the-middle without analysis

or data manipulation

Phase Two Goals

Actively intercept and reply to HTTP requests

If time, attack other protocols

Network Setup

AP Client

Attacker

I am client I a

m ro

uter

To router

Network Setup

AP ClientAttacker

To router

Systems and Tools

Laptop with Linux kernel (attacker) Linux IP forwarding Linux library for packet construction

libnet? Interest Lab Access Point/Client Network Sniffer

Ethereal

Research Papers

S. Manwani. ARP cache poisoning prevention and detection. Technical report, Faculty of Computer Science, San Jose State University, December 2003.

StealingWireless

HTTPS Auth

Casey Callendrello

Eric Garrido

{cdc2107,ekg2002}@columbia.edu

The Big Idea

• Use the inherent insecurity in wireless networking to steal passwords.

• Exploit HTML vulnerabilities to silently grab passwords.

What’s the problem with WiFi?

• You have no idea where your packets are going or where they’re coming from.– Anybody can name

their AP “Columbia University”

Phase 1 Goal

• Using a Linux PC, impersonate an AP

• Intercept traffic and insert HTML exploits. Use these to capture passwords

• Two “exploit vectors”– DNS hijacking– Man-in-the-middle HTML

injection

Exploit

• Send a bogus DNS response to a website we control.

• Man in the middle attack– Send a TCP reset to

the server– Send traffic to the

client with our exploit

Javascript

• Simply sends us keypresses.

• Posts to same domain as requested site (same origin) or uses trickery*.

* - Signed code, DNS Pinning attack, etc.

Setup

Extending

• Ultimate goal: Make TCP Reset attacks work.– Make attack work from another client.

Tools

• iptables• http://gnucitizen.org• dsniff

– dnsspoof– webmitm

W 4140 Networking W 4140 Networking Laboratory Laboratory

Final Project: Wireless NetworkFinal Project: Wireless Network

Team MemberTeam Member

Matt (Yu-Ming Chang) Matt (Yu-Ming Chang) • yc2345@columbia.eduyc2345@columbia.edu

Yitao WangYitao Wang• yw2226@columbia.eduyw2226@columbia.edu

Alexandre Ling LeeAlexandre Ling Lee• al2537@columbia.edual2537@columbia.edu

Problem to be solved in this project: Problem to be solved in this project: How to choose from the a access How to choose from the a access point with higher bandwidth?point with higher bandwidth?

The Goal of Phase IThe Goal of Phase I

Set up experimental environment.Set up experimental environment.• Install and configure 2 wireless adapter Install and configure 2 wireless adapter

on one laptopon one laptop• Set up 2 access points Set up 2 access points • Build the network between the adapters Build the network between the adapters

and APs, analysis the traffic by looking and APs, analysis the traffic by looking into the captured packetsinto the captured packets

AP 1 AP 2

Laptop

Connection 2

Connection 1

Move to AP 2Move to AP 1

Analysis toolsAnalysis tools

iperf (end-to-end bandwidth measurement iperf (end-to-end bandwidth measurement tool) voip clients such as yate tool) voip clients such as yate http://http://yate.null.royate.null.ro and the tools from Hennings and the tools from Hennings web page for path measurement and web page for path measurement and characterization for VoIP.characterization for VoIP.

Also, read about how 802.11a/b/g Also, read about how 802.11a/b/g LAN/MAN Wireless standard works and LAN/MAN Wireless standard works and some papers about multipath routing and some papers about multipath routing and tun tun http://http://vtun.sourceforge.net/tunvtun.sourceforge.net/tun//

ReferenceReference

http://vtun.sourceforge.net/tun/faq.hthttp://vtun.sourceforge.net/tun/faq.htmlml

http://yate.null.ro/pmwiki/index.php?http://yate.null.ro/pmwiki/index.php?n=Main.WhatsYate?n=Main.WhatsYate?

MiniDoS:Denial of Service Attacks Over Small NetworksAl Hwang (ah2200)

Mike Lynch (mtl2103)

Cindy Liao (cl2229)

Project Objective

Investigate the resilience of network equipment and hosts against denial of service attacks in a small network.

To do this, we will existing malicious networking tools to

Phase 1 Goals

Research different types of DoS attacks: SYN Floods, ACK Floods, ICMP Flood, Smurf

Attacks Testing attacks and documenting resilience of

target hosts Analyze means to improve effectiveness of

attack.

Network Topology

Hub

Router1

Router2 Router3

hub

hub hub

PC 4(Master)

PC 2(Zombie)

PC 1

PC 3(Zombie)

Tools

We will look into various published malicious tools to employ these attacks, including: mstream – primitive tool, contains errors, but still

causes significant disruption to network trinoo – employs SYN attacks with encrypted

communications between master and zombie attackers

TFN (Tribe Flood Network) – advanced tool that implements a number of different DoS attack methods

Research Papers

Security Analyses by Dr. David Dittrich (University of Washington): “The ‘mstream’ Distributed Denial of Service

Attack Tool” (http://staff.washington.edu/dittrich/misc/mstream.analysis.txt)

“The DoS Project's ‘trinoo’ Distributed Denial of Service Attack Tool” (http://staff.washington.edu/dittrich/misc/trinoo.analysis.txt)

“The ‘Tribe Flood Network’ Distributed Denial of Service Attack Tool” (http://staff.washington.edu/dittrich/misc/tfn.analysis.txt)

Research Papers (cont’d)

“DDoS Attacks and Defense Mechanisms: Classification and State-of-the-art” by Christos Douligeris and Aikaterini Mitrokotsa (Oct. 13, 2003) Overview of DDoS attacks in general and

concepts involved in preventing them

Project Outline/Proposal for:

Project 3: Resilience of network equipment and hosts against Denial of Service Attacks (DoS)

Group composition

• Roberto Martin (rrm2112@columbia.edu)

• Darren Tang (tt2191@columbia.edu)

Main point of the entire project

• The question we are trying to answer is: how resilient are networks against the DOS attacks (as will be defined)?

Phase 1 goals

Phase1 (network level attacks) • As the project outline states this will involve Arp

poisoning attacks and also router resilience to packet fragmentation and address spoofing. We will take the following approach to investigate these attacks:

• Arp Poisoning– First we will clearly define what this means and investigate

exactly how it is done. From this information we will gather all the tools needed to carry out such an attack, then we will experiment with this in the lab and observe the resilience of the switches.

• Address Spoofing– Again we will clearly define what this means and as above

gather tools needed to carry out and measure the effects of such attacks.

Network Topology 1

Network Topology 2

Tools being used

• Ethereal (to view packets)

• Ettercap (arp poisoning/spoofing)

Resources

[1] Jelena Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher.

Internet Denial of Service: Attack and

Defense Mechanisms, Prentice Hall, 2005.

[2] Ettercap Web Page:http://ettercap.sourceforge.net/

[3] Ed Skoudis, Tom Liston

Counter Hack Reloaded

Defence Mechanisms

• 1. Use static ARP tables between important hosts (not very practical in most cases).2. Use ARPWatch to spot when someone is pulling off an ARP poisoning attack.

Securing Networks and Communications

VPN and Firewall Setup and Configuration

Securing Networks and Communications

VPN and Firewall Setup and Configuration

Sharmini Ilankovansi2137@columbia.edu

Sharmistha Roy sr2488@columbia.edu

KaoFu Lai kl2252@columbia.edu

Sharmini Ilankovansi2137@columbia.edu

Sharmistha Roy sr2488@columbia.edu

KaoFu Lai kl2252@columbia.edu

Goal of the projectGoal of the project

To study implementations and setup of VPN and Firewalls

To implement any mechanism of secure communications and test it

To study implementations and setup of VPN and Firewalls

To implement any mechanism of secure communications and test it

Phase I ObjectivePhase I Objective

To study literature and man pages for implementation and setup of mechanisms used in VPN for Windows machines

To implement a version of Onion Routing mechanism (one method for anonymous communications)

To study literature and man pages for implementation and setup of mechanisms used in VPN for Windows machines

To implement a version of Onion Routing mechanism (one method for anonymous communications)

Network setupNetwork setup

Source machine Destination machine The path between the two will consist of

routers forwarding the packets to the hosts. A layer of encryption is added for each router in the path and each router decrypts the layer as a packet reaches it

Source machine Destination machine The path between the two will consist of

routers forwarding the packets to the hosts. A layer of encryption is added for each router in the path and each router decrypts the layer as a packet reaches it

Tools required for implementationTools required for implementation

Implement random routing between the two end hosts with data encryption

Implement Privoxy Filter to conceal the identity of client visiting a server website

Implement random routing between the two end hosts with data encryption

Implement Privoxy Filter to conceal the identity of client visiting a server website

ReferencesReferences

http://www.onion-router.net Publication:Onion Routing for Anonymous

and Private Internet connections: David GoldSchlag,Michael Reed,Paul Syverson

http://www.onion-router.net Publication:Onion Routing for Anonymous

and Private Internet connections: David GoldSchlag,Michael Reed,Paul Syverson

Linux Kernel 2.6 Support for Overlay Networks

Introduction

Objective of the project:

- Reduce Application Layer / Kernel Layer switching latency due to standard socket API system call

- Reduce Indirection Delay induced due to the inherent indirection infrastructure of the modern overlay networks and achieve better network characteristics such as low latency, high bandwidth etc.

- Support packet classification and scheduling for providing QoS guarantees

Breakup of Tasks

- Phase 1: (Classification / Marking / Queuing of IP datagrams based on type)

Group : 1 (Aniruddha , Ankur , Dhruva) - Linux Packet Scheduling , Queuing , - Tools to queue and mark packets (eg. NF- HiPAC, ipset etc.) - Testing out simple P2P application and assuring QoS for such applications using

such packet marking queuing mechanism

Classification / Marking / Queuing and scheduling of IP Datagrams

NF_IP_LOCAL_OUT (imeplement the kernel hooks here to classify / mark and queue IP datagrams

- Phase 1:Group : 2

(Implementation of kernel hooks to bypass user space / kernel space switching)

(Sambuddho , Tarun) - Design and implementation of the

system call to directly send the file across to the peer host

- Design and implementation of the system call to directly receive the file across to the peer host

System Call – peer_send() / peer_recv()

peer_send() : System call to bypass the socket API send () / sendto () and directly pass the file name to the kernel

peer_recv () : System call to bypass the kernel recv() / recvfrom() system call and directly get the filename to write to. This should be a blocking system call which blocks till the file is received and copied into the file.

System Call – peer_send() / peer_recv()

peer_send() : peer_send(sockfd, filename,sock_param);

do_peer_send(sockfd, filename,sock_param){

/* open the file and mmap() it to a kernel space

block of memory and then call the actual UDP/IP stack operations to transfer the file */

}

(User space)

(Kernel space)

System Call – peer_send() / peer_recv()

peer_recv() : peer_recv(sockfd, filename,sock_param);

`

do_peer_recv(sockfd, filename,sock_param){

/* read multiple blocks of data from the sockfd socket and buffer them to a block of kernel memory and when the block is full transfer it to a file and then again call the actual UDP/IP stack operations to receive the next block of memory of the file */

}

(User space)

(Kernel space)

Any Questions?