Final Presentation

Download Report

Transcript Final Presentation

E-SNIFF
The embedded ethernet packet sniffer
A Senior Design Project by Alex Hoyland
Advisors: Mr. Steve Gutschlag
and Dr. Aleksander Malinowski
Project Summary
 Packet Sniffers are devices or programs capable of intercepting and
logging data traveling over a computer network.
 Sniffers are used for a variety of purposes, including monitoring,
network troubleshooting, intrusion detection and surveillance.
 The typical packet sniffer is a software program that runs on a PC.
This wastes CPU time that could be used for other tasks. Also, PCs
are bulky and difficult to hide, making them less practical for
surveillance purposes.
 E-Sniff is a small special-purpose embedded system for capturing
and logging network data. It is implemented in an FPGA, and uses
a soft processor and custom hardware to capture packets and
display them on a VGA monitor. The user can also enter commands
using a PS/2 keyboard to control packet processing.
Project Summary
 The E-sniff project is implemented in an Altera DE2 board.
 This board contains numerous peripherals.
 The ones used for this project are: a Cyclone II FPGA, an 8MB
SDRAM, 4MB CFI flash, an 8MB Serial Flash, a 16x2 Optrex LCD, a
high-speed Video DAC, a PS/2 serial port and a DM9000A 10/100
Mbps Ethernet Controller. These are highlighted below in red.
How it works
 Ethernet networks use a physical bus topology. All devices on the
same bus segment are said to be in the same “collision domain.”
 All hosts in a collision domain can see all the data on the bus
segment, i.e. they can intercept traffic meant for other hosts.
 This means our packet sniffer can intercept traffic going to/from
any host in the same collision domain.
 In modern networks, switches are used to break up collision
domains. Each port on a switch corresponds to a single collision
domain. This means our sniffer cannot see any traffic if it is
plugged into the switch!!!
 To sidestep this problem, E-Sniff is plugged into a hub, which is
inlined between the host and the switch. This puts the sniffer on
the host’s collision domain. Now we can read our coworker’s email!
How it works
Hardware - CPU
 The CPU is an Altera Nios II customizable soft processor. It is
clocked at 100 MHz and is implemented in the Cyclone II FPGA.
 The CPU was generated with Altera’s SOPC builder tool
 The Nios II can be completely customized, and can interface
directly with any memory or peripheral device on the board.
 The E-sniff CPU interfaces with several chips on the DE2 and has
access to over 20 MB of memory, as shown below:
 8MB EPCS serial flash - holds software image and FPGA config data
 8MB SDRAM - main program memory, holds heap, stack, text, etc.
 4MB CFI Flash - non-volatile packet storage and software config data
 4KB On-chip memory - fast memory on the FPGA, used to hold the
exception stack/interrupt service routines.
Hardware - CPU
 The CPU also interfaces with the following onboard peripherals:
 Davicom DM9000A Fast Ethernet MAC/PHY
 Keyboard/VGA on-chip text memory
 Keyboard receive module
 Optrex LCD
 25 LEDs, 17 switches, 4 buttons
 It contains the following peripheral modules:
 Hardware system ID module
 JTAG Debug/Trace module
 1s interval timer - generates interrupts for per-second tasks
 1ms interval timer - generates interrupts for CPU usage monitoring
Hardware - CPU
This is the memory map of the main
CPU as shown in SOPC builder.
Hardware - VGA
 The VGA monitor is controlled by a custom hardware module.
 The module generates VGA sync signals to drive a 640x480 display.
 It maps ASCII character codes from a small on-chip memory into
pixel patterns on the screen.
 This way, the processor can quickly write a string to the memory
and have it appear on screen. The processor also does not have to
bother with generating VGA sync signals.
 Line returns are also handled in hardware. When the CPU wants to
advance to the next line, it briefly asserts an ‘enter’ signal that is
read by the VGA controller. This adds to an internal memory offset
that effectively shifts the top line off of the display and adds a blank
line to the bottom. This saves the CPU the trouble of redrawing the
text one line higher on the screen.
Hardware - VGA
Hardware - VGA
Hardware - VGA
Hardware - Keyboard
 The keyboard hardware receives scan codes from a PS/2 keyboard,
translates them into ASCII and writes them to the screen.
 The first module in the keyboard controller receives 11-bit keyboard
messages, checks them for parity and alignment errors, and outputs the 8bit scan codes contained in them.
 The second module is a hardware look-up table, which takes the scan
codes and translates them into ASCII.
 The ASCII characters are then written to an on-chip memory in the vga
module, which displays them on the screen.
 This is all done without interrupting the processor.
 When the user has typed an entire line of text, they press the enter key.
 This interrupts the processor, which reads the line of text out of the input
memory, then clears it, then processes the command.
Hardware - Keyboard
 Features:
 The user can press backspace to clear a character
 The module supports repeating, i.e holding down a key will write the same
character multiple times until the key is released
 Supports capital and lowercase letters, numbers and punctuation
 Problems:
 Only a subset of the keys on a normal keyboard are supported because my head
hurt from writing giant lookup tables
 Transmission to the keyboard is not currently supported, so the CAPS LOCK,
NUM LOCK and SCROLL LOCK LEDs cannot be lit.
 Also, if a message is misaligned or contains a parity-bit error, the controller
cannot signal the keyboard to retransmit and the user must type the character
again. Full-featured PS/2 controllers can tell the keyboard to retransmit the last
character code if this happens.
Hardware - Keyboard
Hardware - Top
This is what it looks like when you put it all together:
Software
 The E-Sniff software was built using the Altera Nios II EDS, an
Eclipse-style IDE for writing Nios II software.
 The software consists of five main routines distributed over 21
source files. The source files contain over 3000 lines of C code.
 The
 The
 The
 The
 The
first routine initializes the system.
second routine monitors CPU usage.
third routine updates the status bar, system run timer and LEDs.
fourth routine handles user input from the keyboard.
fifth routine handles interrupts from the Ethernet controller.
Software - Init
Software - CPU monitor
Software - 1s interrupt
Software - Keyboard
Software - Keyboard
 Supported commands:
 capture - starts/stops packet capture
 filter - sets filter rules, turns filter off/on
 verbosity - controls the amount of text displayed about each packet
 log - turn the packet log off or on
 status - change what is displayed in the status bar
 debug - debug commands, read/write memory
 splash - show the splash screen
 sysinfo - display system info
 praise - show reviews from classmates
 homer - ascii art of homer simpson
 help - display a help menu
 <command> help - help for any command
Software - Ethernet
Software - Filtering
 To look at a particular subset of traffic, the user can set a filter.
 The E-Sniff filter has up to five filter rules. If a packet matches any
of these rules, it will be displayed.
 Each rule consists of the following subrules:
 Source IP/netmask
 Destination IP/netmask
 Source Port
 Destination Port
 Source MAC address
 Destination MAC Address
 Network/Transport protocol
 For a packet to match a filter rule, it must match all of the subrules.
Software - Dissectors
 The dissectors perform the actual work of dismantling and parsing a
packet. One dissector is implemented for each protocol to be read.
 Ethernet packets have a layered structure. For example, HTTP data
is encapsulated in a TCP datagram, which is encapsulated in an IP
packet, which is encapsulated in an Ethernet frame.
 As a result, packet dissection is similar to peeling an onion.
 Every packet starts in the frame dissector parse_eth_frame().
 parse_eth_frame() parses the Ethernet Frame data and strips it off.
A lookup table is consulted to determine what dissector to call next.
 The data is passed to the next dissector, which parses a layer, strips
it off, consults a lookup table to find the next dissector, and passes
it on.
 This continues until the actual application data is parsed.
Software - Dissectors
Performance
 E-Sniff can capture packets from a busy 10 Mbps half-duplex line
with about 99% reliability.
 No test have been performed on a 100 Mbps line due to
unavailability of required test equipment (new model Cisco switch)
 Filtering works properly.
 Dropped/Received/Filtered packet counters work correctly
 Link state change monitoring works correctly.
Known Issues
 The keyboard controller cannot transmit to the keyboard. This means that
incorrectly received scan codes cannot be retransmitted and the lights on
the keyboard cannot be lit.
 CAPS LOCK key “capitalizes” numbers - 2 becomes @, etc.
 The keyboard controller occasionally writes incorrect or multiple characters
to the screen when a misaligned scan code is received.
 The keyboard controller does not support all the keys on a standard
keyboard, and does not support the arrow keys.
 The LCD does not display text on the bottom line. This is believed to be
caused by a glitch in the hardware
 The link state change interrupt occasionally stops working when changes
are made to unrelated code - may be due to a problem with the ethernet
controller interface hardware
 There is no command history - could be implemented without much trouble
 The output buffer is only slightly bigger than the screen - needs to be
enlarged - this could also be done without much trouble.
Future Work
Correct known issues
Add a web interface for issuing commands and reading the log
Add the ability to flash in new firmware over the network
Add the ability to identify gateways and nameservers
Add the ability to cache routing information and build a route table
Add the ability to log and display current DHCP leases
Add the ability to track website usage by each host
Add DNS name resolution to packet dissectors
Write dissectors for the hundreds of protocols left unimplemented
Allow eavesdropping on VoIP phone calls
Add support for basic network testing tools - ping, tracert,
nslookup, port scanning, etc.
 Identify network servers and determine their weaknesses











Questions?