Project #3: Part 3, Scan Detection

Overvew

In the final portion of the project, you will swap hats to play the part of a defender. Specifically, it is your job to implement a simple form of scan detection within the same infrastructure you used in part 2 (stub code is available here).

Your router will use "network signals" to detect scanning. The idea is simple, it will maintain a ratio per incoming source of the number of connections requests, vs. the number of positive responses. If this value is over some threshold for a given source, you will assume the source is scanning and issue a warning (note, responding to a suspected scanner by filtering is a bad idea because it can be used by a source-spoofing attacker to deny service to a legitimate client).

In the wild, attackers use many different types of tricks to port scan or enumerate hosts on a network. For example, an attacker may send crafted data packets and use RSTs to determine if a hosts exists. For the purposes of this assignment, we make some simplifying assumptions. We assume clients do not respond to data packets that are not part of an established flow and all incoming packets that are not TCP, ICMP echo request or UDP are dropped at an upstream firewall.

Project Details:

Working withing the same code base as the evil router, you will keep track of network signals to detect scanning. Your router is required to keep track of the following network events:

Connection requests: Postive Responses: Negative Responses:

For each sending source, keep track of the number of connection requests vs. positive responses. If this ratio exceeds 3 to 1, your router must issue a warning. In addition to determining that a source is scanning. Your router must be able to distinguish if a router is attempting a port scan (TCP and UDP only), or a host scan (or potentially both). The format for the warning message must be as follows:

source ip<tab>SCANNING<tab>TYPE
(where type can be PORT, HOST)

Your router is also expected to issue a warning for each negative response it receives. These warnings must be of of the following formation:

source ip<tab>NEG<tab>TYPE
(where type can be RST, ICMP_UNREACH)

Considerations

The description above, if a burst of three legitimate connection requests came in simultaneously from the same host, your router would flag the host as a scanner. This is obviously undesireable. To compensate, your router must wait defer adding a requests to the ratio until a timeout has expired, or the network issues a response. We may use a timeout of 1 second.

You will also want to timeout state as sources become silent. If a source does not send a connection request for 30 seconds, you may time out any state currently associated with it.

Testing

The easiest way to test your router is to generate traffic from the command line by hand. Traceroute can be used to send UDP packets. You may pass telnet or ssh a port on the command line for probing.

Deliverables

You are expected to submit your router code along with a file (README.3) that describes your implementation. Your router should only print out the warnings and nothing else. Your writeup is expected to be brief, no more than a page, but should describe how you implemented caching of pending events before you added them to the ratio as well as how your router differentiates between port and host scans.