Notes for Week 4

  1. sample ethereal capture for ordinary web request

    sample ethereal capture for form using GET method

    sample ethereal capture for form using POST method

  2. EXERCISES for Week 4:

    1. Modify your GET form from last week to use the calculator script. Be sure to change the input name for the text box from "name" to "text".
    2. Capture the packets transferred when you access the form from another PC. Note the escaping of the special characters. Be sure to use an arithmetic expression that contains (at least) addition, subtraction, multiplication and division.
    3. Change the form method to POST but do not change the script. Capture the packets transferred when you access the form from another PC. Note the contents of the continuation packet.
    4. Most hack attacks utilize buffer overflows: a very long GET request is sent to an HTTP server that does not adequately check incoming message lengths. The long message overflows the buffer which the programmer set aside for incoming messages, and the overflow data overwrites part of the server program. That data contains machine code which accomplishes the ends of the hack; usually a large number of NOPs ("no operation", an instruction which executes successfully but does not do anything) are followed by the attack code, and this is repeated multiple times to increase the chances that the attack code is executed. Typical hacks are the "apache-scalp" exploit, with a payload of 28898 bytes, and the "apache-nosejob" exploit, with a payload of 31413 bytes. These observations lead us to suspect that firewalling by packet length may be an effective means of thwarting some exploits.

      Capture HTTP GET packets from a variety of browser platforms. Compute the maximum HTTP payload size (the size of the HTTP protocol data unit) and subtract the length of the URL path in the GET request. This length represents the "HTTP overhead." Now add 54 bytes (for the Ethernet, IP and TCP headers) and the length of the longest path in your document root. If you are serving active content, you must include the longest possible query string as you consider the longest possible path. This number represents the longest legitimate packet you should ever receive.

      Suppose your total is 700 bytes. A firewall rule to drop excessive packets would look like this:

      iptables -A INPUT -i eth0 -p tcp --dport 80 -m length --length 701:1536 -j DROP
      Implement such a firewall rule and test it, first sending a legitimate request, and then increasing the size of the request by manually typing additional query string characters on the end of the original query string. Use iptables -L -v to examine the dropped packet and bytes counts associated with your request.

      What are the logistical difficulties in implementing such a rule on an enterprise server?


©2008, Kenneth R. Koehler. All Rights Reserved. This document may be freely reproduced provided that this copyright notice is included.

Please send comments or suggestions to the author.