Scan of the month 23
Guy Van Sanden

This analysis was done on a SuSE Linux 8.0 system.

Tools used:

  • snort
  • ethereal
  • p0f
  • 1. What is a binary log file and how is one created?

    Snort and tcpdump can intercept packets, and write them to a file in their binary form. This binary capture is the exact data-stream (unaltered, uninterpreted) that was received by the capturing program, containing header and payload information. Viewing is done using either snort, tcpdump or ethereal by telling them to use the capture as their input, and process it as they would with live input.

    A binary capture can be created with tcpdump using the -w switch (eg. tcpdump -w dumpfile).
    Snort can also do this in several ways. One is the command line to put it in packet-logging mode with 'snort -dev -l ./log'.
    Another is to use "output log_tcpdump: snort.log " in the config file.
    In Ethereal, pressing CTRL+K will do it.

    2. What is MD5 and what value does it provide?

    MD5 is a secure message-digest algorithm, designed by Professor Ronald L. Rivest of MIT. It is described in RFC1321[1].

    MD5 produces a 128 bit fingerprint which uniquely identifies the input (mostly a file). To this date, MD5 is considered a *secure* digest algorithm, meaning that it is not yet technically feasible to falsify an MD5 fingerprint (attacking the algorithm that is, not the implementation!).

    The value of an MD5 signature is that you can verify that a message or file has not been changed (tampered with, damaged, otherwise changed) since the MD5 signature you're checking against has been created.

    Applied to this situation, I can be sure that the file sotm23.tar.gz on my disk is the exact same file as offered on the HoneyNet site, because the MD5 sums (9d28c5ee9ce7b77e3099a07ad303811f) match. It does *not* guarantee me that it actually comes from the Honeypot project, as someone who rooted the webserver could have replaced both the tar.gz file and the hash (simply generated with md5sum on Linux). To guard against this, something like PGP would be better suited.

    3. What is the attacker's IP address?

    This information can be read simply with ethereal. Every intercepted packet has a source and destination address. Simply by reading the first packet of the scan, you can determine who is the attacker and who is the target.

    The attacker is

    4. What is the destination IP address?

    Working with the assumption of question 3, the target is

    5. We scanned the honeypot using five different methods. Can you identify the five different scanning methods, and describe how each of the five works?

    1) TCP Connect scan
    As this one is particularly noisy, the snort alert log [4] has numerous entries (reporting connections to thousands of ports).
    2) TCP SYN scan
    Looking through the capture with ethereal, you see the single SYN packets launched against the host, than immediately followed by an RST to close the connection.
    3) FIN scan
    These packages can be seen once again in ethereal.
    4) XMas scan
    Reported in the snort alert log [4].
    5) NULL scan
    Reported in the snort alert log [4].

    A quick query in ethereal revealed that fragmentation was not turned on for any of these. Fragmentation can be applied to any of the scan to attempt to fool firewalls en intrusion detection systems.

    1) TCP Connect Scan

    This is one of the fastest, but most noisy type of scans. It uses the connect function of the OS to open a connection to every port on the host.
    It can be used without being root on a *nix system.

    2) TCP SYN Scan

    This type of scan sends a SYN packet to every port on the remote host. If the port is open, it sends a "SYN ACK" response.
    Because there is no actual connection established, this method is a more covert than a connect scan.

    3) FIN Scan

    A FIN packet is send to each port on the host. For every closed port on the host, an RST packet is replied, open ports return nothing.

    This scan can produce incorrect results against a Microsoft OS because their TCP stack (Windows 95,98,ME,NT ) does not conform to standards. Because Xmas and NULL scans are variations of this one, they suffer from the same problem.

    4) XMas Scan

    This is an extension to the FIN scan. It sets the FIN, URG, and PUSH flags.

    3) NULL Scan

    Another variation on the FIN scan, but with all flags turned off.

    6. Which scanning tool was used to scan our honeypot? How were you able to determine this?

    NMAP by Fyodor. The combination of scanning techniques is a good indication, most of them were created by Fyodor, the only tool (AFAIK) that has them all is nmap.
    More important, snort identifies[4] some of the scans specificly as nmap, The description in their signature database claims this is an accurate identification.

    7. What is the purpose of port scanning?

    Port scanning is used to determine which services are running on a target machine by looking at which ports are open on it. Interpreting a portscan can give information about which operating system the target is running. It is mainly used as a reconnaissance tool, probing networks or hosts for running services.

    8. What ports were found open on our honeypot?

    An open port on the host returns a "SYN ACK" response to a "SYN" packet. Using ethereal, a filter stating "ip.src == && ip.dst == && tcp.flags == 0x012" returns all these responses from the host to the remote machine.

    The answer is:
    22 ssh
    111 sunrpc
    80 http
    443 https
    53 domain

    9. Bonus Question: What operating system was the attacker using?

    Unless the attacker was devious (and clever/paranoid) enough to modify the parameters of their network stack, he was running GNU/Linux with a 2.4.x kernel.

    This can be identified using "Passive Fingerprinting". I knew that each Operating System has certain little differences in their networking stack. They set initial values differently.
    Going from this assumption, I read "Know Your Enemy: Passive Fingerprinting. Identifying remote hosts, without them knowing" [2].
    I used the tool p0f [3], mentioned in the Honeynet paper on the capture, and it reported the remote host as: " [1 hops]: Linux 2.4.2 - 2.4.14 (1)"

    X. Reference

    [1] RFC1321 [2] Know Your Enemy: Passive Fingerprinting. Identifying remote hosts, without them knowing [3] p0f [4] Snort Alerts

    Guy Van Sanden