W4140 Network Laboratory Lecture 8 Oct 30 - Fall 2006 Shlomo Hershkop Columbia University

1
W4140 Network LaboratoryLecture 8Oct 30 - Fall
2006Shlomo HershkopColumbia University
2
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

3

• Here are the group presentations

4
Virtual Private Networks

• Gilbert Hom (gch2102_at_columbia.edu)
• Mohit Vazirani (mcv2107_at_columbia.edu)
• Eric Zhang (ehz2101_at_columbia.edu)

5
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

6
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

7
Network Setup
Router2 E0/0 10.0.2.2/24 E0/1 10.0.3.1/24
PC3 E0/0 10.0.4.4/24
Server/PC1 E0/0 10.0.1.11/24
Router4 E0/0 10.0.3.4/24 E0/1 10.0.4.1/24
Hub
Hub
PC4 E0/0 10.0.4.3/24
Router1 E0/0 10.0.1.1/24 E0/1 10.0.2.1/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.
8
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.

9
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

10
Man-in-the-middle Attackusing ARP Poisoning

• Arezu Moghadam (amm2141)
• Armando Ramirez (alr2106)
• Mark Tabry (met2105)

11
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

12
Phase One Goals

• Poison ARP caches of router and client
• Set up attackers IP forwarding
• Man-in-the-middle without analysis or data
  manipulation

13
Phase Two Goals

• Actively intercept and reply to HTTP requests
• If time, attack other protocols

14
Network Setup
To router
I am client
I am router
15
Network Setup
To router
16
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

17
Research Papers

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

18
StealingWireless HTTPS Auth

• Casey Callendrello
• Eric Garrido
• cdc2107,ekg2002_at_columbia.edu

19
The Big Idea

• Use the inherent insecurity in wireless
  networking to steal passwords.
• Exploit HTML vulnerabilities to silently grab
  passwords.

20
Whats the problem with WiFi?

• You have no idea where your packets are going or
  where theyre coming from.
• Anybody can name their AP Columbia University

21
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

22
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

23
Javascript

• Simply sends us keypresses.
• Posts to same domain as requested site (same
  origin) or uses trickery.

- Signed code, DNS Pinning attack, etc.
24
Setup
25
Extending

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

26
Tools

• iptables
• http//gnucitizen.org
• dsniff
• dnsspoof
• webmitm

27
W 4140 Networking Laboratory

• Final Project Wireless Network

28
Team Member

• Matt (Yu-Ming Chang)
• yc2345_at_columbia.edu
• Yitao Wang
• yw2226_at_columbia.edu
• Alexandre Ling Lee
• al2537_at_columbia.edu

29

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

30
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

31
(No Transcript)
32
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/

33
Reference

• http//vtun.sourceforge.net/tun/faq.html
• http//yate.null.ro/pmwiki/index.php?nMain.WhatsY
  ate?

34
MiniDoSDenial of Service Attacks Over Small
Networks

• Al Hwang (ah2200)
• Mike Lynch (mtl2103)
• Cindy Liao (cl2229)

35
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

36
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.

37
Network Topology
PC 1
hub
Router1
PC 2 (Zombie)
PC 3 (Zombie)
Hub
Router2
Router3
hub
hub
PC 4 (Master)
38
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

39
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)

40
Research Papers (contd)

• 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

41
Project Outline/Proposal for

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

42
Group composition

• Roberto Martin (rrm2112_at_columbia.edu)
• Darren Tang (tt2191_at_columbia.edu)

43
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)?

44
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.

45
Network Topology 1
46
Network Topology 2
47
Tools being used

• Ethereal (to view packets)
• Ettercap (arp poisoning/spoofing)

48
Resources

• 1 Jelena Mirkovic, Sven Dietrich, David
  Dittrich, Peter Reiher.
• Internet Denial of Service Attack and
• Defense Mechanisms, Prentice Hall, 2005.
• 2 Ettercap Web Pagehttp//ettercap.sourceforge
  .net/
• 3 Ed Skoudis, Tom Liston
• Counter Hack Reloaded

49
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.

50
Securing Networks and CommunicationsVPN and
Firewall Setup and Configuration

• Sharmini Ilankovan
• si2137_at_columbia.edu
• Sharmistha Roy
• sr2488_at_columbia.edu
• KaoFu Lai
• kl2252_at_columbia.edu

51
Goal of the project

• To study implementations and setup of VPN and
  Firewalls
• To implement any mechanism of secure
  communications and test it

52
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)

53
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

54
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

55
References

• http//www.onion-router.net
• PublicationOnion Routing for Anonymous and
  Private Internet connections David
  GoldSchlag,Michael Reed,Paul Syverson

56
Linux Kernel 2.6 Support for Overlay Networks
57
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

58
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

59
NF_IP_LOCAL_OUT (imeplement the kernel hooks here
to classify / mark and queue IP datagrams
Classification / Marking / Queuing and
scheduling of IP Datagrams
60

• 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

61

• 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.

62

• 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)
63

• 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)
64

• Any Questions?