The TUN is Virtual Point-to-Point network device. TUN driver was designed as low level kernel support for IP tunneling. It provides to userland application two interfaces: - /dev/tunX - character device; - tunX - virtual Point-to-Point interface. Userland application can write IP frame to /dev/tunX and kernel will receive this frame from tunX interface. In the same time every frame that kernel writes to tunX interface can be read by userland application from /dev/tunX device. Yate is a next-generation telephony engine; while currently focused on Voice over Internet Protocol (VoIP) and PSTN , its power lies in its ability to be easily extended. Voice, video, data and instant messaging can all be unified under Yate&apos;s flexible routing engine, maximizing communicationsefficiency and minimizing infrastructure costs for businesses.

Transcript of "Group Projects Phase I"

2.
Announcements <ul><li>Last lab will be due next week due to hardware issues </li></ul><ul><li>will be working on it </li></ul><ul><li>today: Group presentations </li></ul><ul><ul><li>please save questions for end </li></ul></ul><ul><ul><li>if you have an idea, please share </li></ul></ul><ul><ul><li>need to coordinate between groups/racks </li></ul></ul>

5.
Purpose <ul><li>Learn about how VPNs establish secure channels in a volatile and inherently insecure environment </li></ul><ul><li>Explore VPN options in Windows and Linux and learn about how different implementations interact </li></ul>

6.
Phase 1 Goals <ul><li>Set up a VPN server and several VPN clients </li></ul><ul><li>The VPN server will run Windows 2000/2003 Server; the clients will run Windows XP </li></ul><ul><li>Observe traffic flow and encryption between machines with Ethereal/tcpdump </li></ul>

20.
What’s the problem with WiFi? <ul><li>You have no idea where your packets are going or where they’re coming from. </li></ul><ul><ul><li>Anybody can name their AP “Columbia University” </li></ul></ul>

22.
Exploit <ul><li>Send a bogus DNS response to a website we control. </li></ul><ul><li>Man in the middle attack </li></ul><ul><ul><li>Send a TCP reset to the server </li></ul></ul><ul><ul><li>Send traffic to the client with our exploit </li></ul></ul>

29.
<ul><li>Problem to be solved in this project: How to choose from the a access point with higher bandwidth? </li></ul>

30.
The Goal of Phase I <ul><li>Set up experimental environment. </li></ul><ul><ul><li>Install and configure 2 wireless adapter on one laptop </li></ul></ul><ul><ul><li>Set up 2 access points </li></ul></ul><ul><ul><li>Build the network between the adapters and APs, analysis the traffic by looking into the captured packets </li></ul></ul>

32.
Analysis tools <ul><li>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. </li></ul><ul><li>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 / </li></ul>

35.
Project Objective <ul><li>Investigate the resilience of network equipment and hosts against denial of service attacks in a small network. </li></ul><ul><li>To do this, we will existing malicious networking tools to </li></ul>

43.
Main point of the entire project <ul><li>The question we are trying to answer is: how resilient are networks against the DOS attacks (as will be defined)? </li></ul>

44.
Phase 1 goals <ul><li>Phase1 (network level attacks) </li></ul><ul><li>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: </li></ul><ul><li>Arp Poisoning </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Address Spoofing </li></ul><ul><ul><li>Again we will clearly define what this means and as above gather tools needed to carry out and measure the effects of such attacks. </li></ul></ul>

49.
Defence Mechanisms <ul><li>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. </li></ul>

51.
Goal of the project <ul><li>To study implementations and setup of VPN and Firewalls </li></ul><ul><li>To implement any mechanism of secure communications and test it </li></ul>

52.
Phase I Objective <ul><li>To study literature and man pages for implementation and setup of mechanisms used in VPN for Windows machines </li></ul><ul><li>To implement a version of Onion Routing mechanism (one method for anonymous communications) </li></ul>

53.
Network setup <ul><li>Source machine </li></ul><ul><li>Destination machine </li></ul><ul><li>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 </li></ul>

54.
Tools required for implementation <ul><li>Implement random routing between the two end hosts with data encryption </li></ul><ul><li>Implement Privoxy Filter to conceal the identity of client visiting a server website </li></ul>

61.
<ul><li>System Call – peer_send() / peer_recv() </li></ul><ul><li>peer_send() : System call to bypass the socket API send () / sendto () and directly pass the file name to the kernel </li></ul><ul><li>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. </li></ul>

63.
<ul><li>System Call – peer_send() / peer_recv() </li></ul><ul><li>peer_recv() : </li></ul><ul><li>peer_recv(sockfd, filename,sock_param); </li></ul><ul><li>` </li></ul><ul><li>do_peer_recv(sockfd, filename,sock_param){ </li></ul><ul><li>/* 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 */ </li></ul><ul><li>} </li></ul>(User space) (Kernel space)