Download Group Projects Phase I

W4140 Network Laboratory
Lecture 8
Oct 30 - Fall 2006
Shlomo Hershkop
Columbia 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 Setup
Router2
Server/PC1
PC3
Router4
E0/0: 10.0.2.2/24
E0/1: 10.0.3.1/24
E0/0: 10.0.1.11/24
Hub
E0/0: 10.0.4.4/24
E0/0: 10.0.3.4/24
E0/1: 10.0.4.1/24
Hub
PC4
Router1
E0/0: 10.0.1.1/24
E0/1: 10.0.2.1/24
E0/0: 10.0.4.3/24
Router3
E0/0: 10.0.2.3/24
E0/1: 10.0.3.2/24
PC2
E0/0: 10.0.4.2/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.
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.

Man-in-the-middle Attack
using 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
To router
Attacker
Network Setup
AP
To router
Attacker
Client
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.
Stealing
Wireless
HTTPS Auth
Casey Callendrello
Eric Garrido
{cdc2107,ekg2002}@co
lumbia.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
Laboratory
Final Project: Wireless Network
Team Member

Matt (Yu-Ming Chang)
• yc2345@columbia.edu

Yitao Wang
• yw2226@columbia.edu

Alexandre Ling Lee
• al2537@columbia.edu

Problem to be solved in this project:
How to choose from the a access
point with higher bandwidth?
The Goal of Phase I

Set up experimental environment.
• Install and configure 2 wireless adapter
on one laptop
• Set up 2 access points
• Build the network between the adapters
and APs, analysis the traffic by looking
into the captured packets
Connection
2
Connection
1
AP 1
AP 2
Move to AP 1
Move to AP 2
Laptop
Analysis tools


iperf (end-to-end bandwidth measurement
tool) voip clients such as yate
http://yate.null.ro and the tools from
Hennings web page for path measurement
and characterization for VoIP.
Also, read about how 802.11a/b/g
LAN/MAN Wireless standard works and
some papers about multipath routing and
tun http://vtun.sourceforge.net/tun/
Reference


http://vtun.sourceforge.net/tun/faq.
html
http://yate.null.ro/pmwiki/index.php
?n=Main.WhatsYate?
MiniDoS:
Denial of Service Attacks Over
Small Networks
Al 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
PC 1
hub
Router1
PC 2
(Zombie)
hub
Router2
Hub
PC 4
(Master)
Router3
hub
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.ana
lysis.txt)
“The ‘Tribe Flood Network’ Distributed Denial of
Service Attack Tool”
(http://staff.washington.edu/dittrich/misc/tfn.analys
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
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
Sharmini Ilankovan
si2137@columbia.edu
Sharmistha Roy
sr2488@columbia.edu
KaoFu Lai
kl2252@columbia.edu
Goal of the project

To study implementations and setup of
VPN and Firewalls

To implement any mechanism of secure
communications and test it
Phase 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)
Network 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
Tools 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
References
 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. NFHiPAC, ipset etc.)
- Testing out simple P2P application and
assuring QoS for such applications using
such packet marking queuing mechanism
NF_IP_LOCAL_OUT (imeplement the kernel hooks here to classify / mark and
queue IP datagrams
Classification / Marking / Queuing and scheduling of 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);
(User space)
(Kernel space)
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 */
}
System Call – peer_send() / peer_recv()
peer_recv() :
peer_recv(sockfd, filename,sock_param);
`
(User space)
(Kernel space)
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 */
}
Any Questions?