FAQ
(and comments that could be posed as questions with little effort ..)
Part 1
The host: HTTP header is truncated in the trace file, what gives? Yes, the
packet traces are truncated to 96 bytes. You are going to have to be
a bit more clever when trying to figure out the domain names of the
HTTP queries (hint, you have all the DNS traffic ...)
Part 2
The stub code won't compile The stub code only compiles on
Linux. Be sure to use one of the campus Linux clusters
When I try the reference router I don't see the banner: Like
your solution, the reference router only supports a single flow at a
time. If the banner happens not to be displayed, try refreshing.
My application servers don't work!: The topology e-mails
mailed before Sunday afternoon contain a mistake regarding the IP your
web-servers are running on. Your application server's IP is shown below
the web-server ASCII box at the top of the e-mail (it should be two
greater than the one specified in the example).
How do I call the ip_checksum(..) method? The length argument
expects the total number of bytes to compute the checksum over. e.g.
ip_checksum(ip_hdr, ip_hdr->ip_hl * 4);
Do we have to support HTTP chunking?
No
Part 3
If an attacker sends to packets to a non-existent host is that
one or two events? It's one. You should only count events between a
sending/receiving pair once. The same goes for ports on a host.
If an attackers sends a TCP or UDP packet to a single host, how
many events is it? It's one (you don't double count the port). So
if a host sends two packets to IP:port it is one event, a third to
IP:port + 1, it is two events and IP2:port it is three events
How can you implement guarantees on timeouts in the absence of
packets? The correct answer to this is use timers (man setitimer)
or threads (man pthread_create). Solutions that do this will profoundly
impress the TAs (a good thing). However it is not required, and a
solution can get full points assuming packets arrive with enough
frequency to guarantee accurate timeouts.
Can you print that a source is scanning multiple times? Yes, you are only required
to print the warning once, but multiple times is OK.
How can you test host scanning with two IPs This is a
limitation of the development environment (a common theme in security)
so you may have to get a bit creative. The first thing you'll want to
do is modify the routing table (rtable) so that the send route goes out
of the wrong interface (eth1 instead of eth2) -- this will create a
blackhole from the second IP of your app server. Secondly, since you
only have one IP you'll want to use another part of the packet within
the router to emulate multiple destination IPs. One suggestion is to
xor the source port into the destination IP address within the router.
How do I know when my scan detection is sufficient? If your
router can reasonably handle the following:
- timeouts
- correctly parse and interpret all packet types on the web-page?
- does it detect port scans
- avoid false positives from a normal TCP stream
- does it catch a simple host scan (e.g. using the port trick mentioned above)
you're good to go. Wrap it up, submit, profit ..