* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Group Projects Phase I
Survey
Document related concepts
Remote Desktop Services wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Computer network wikipedia , lookup
Network tap wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Deep packet inspection wikipedia , lookup
Wireless security wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Airborne Networking wikipedia , lookup
Quality of service wikipedia , lookup
Distributed firewall wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Transcript
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 ([email protected]) Mohit Vazirani ([email protected]) Eric Zhang ([email protected]) 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) • [email protected] Yitao Wang • [email protected] Alexandre Ling Lee • [email protected] 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 ([email protected]) • Darren Tang ([email protected]) 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 [email protected] Sharmistha Roy [email protected] KaoFu Lai [email protected] 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?