May 4, 1999
3:00-4:00 pm
3085 ENG II
In attendance:
Karl Levitt (KL), David Klotz (DK), Jeff Rowe (JR), Jason Schatz (JS), David O'Brien (DOB)


News Items
Codebook Correlation
Connection Spoofing
Fred Cohen Attack
    1. News Items
      1. KL: Need some help doing viewgraphs - nothing fancy.
      2. Meet this Thursday to discuss it.
    2. Codebook Correlation
      1. JR: List of symptoms is starting to sound like Yemini's codebook correlation. Are we going in that direction or doing our own codebook. Can we get Smarts and what would we do with it?
        1. DOB: The advantage of Smarts is that you can model your network.
        2. KL: We know enough about the language to see if we could model it.
        3. JR: Smarts deals with missing data and symptoms.
        4. KL: Is the Smarts modeling language adequate?
        5. JS: We just use their techniques, possibly find some limitations.
    3. Connection Spoofing

      1. JR: Use codebook to map symptoms to an attack.
        1. DK: Client not responding is a symptom.
        2. JR: If you only have 2 of 3 symptoms, you may have something else going on.
        3. DOB: 10% of connections will look like SYN floods due to incomplete TCP
          1. Codebook approach will have assumptions that you see only as a result of malfunctions. We couldn't necessarily assume they were attacks.
        4. DK: Take a number of attacks, enumerate the symptoms, charts, and look and see whether or not it might work - if we miss one symptom what will that do?
          1. DOB: Symptom of sequence number guessing - high probe packet rate. A symptom is something you can measure - very basic.
          2. Are hundreds of resets a suitable signature for sequence number guessing or is a repeated pattern (see diagram below)

          3. DOB: This pattern is a truer signature than just looking for AKs. If you see a SYN, start a state machine, you know the state that you're in at this point. Todd does this. Once a connection starts, you can drop it. . Todd and others look at sections; they verify that a connection was established
            1. KL: Is it possible the reset doesn't come back because the server is flooded with AKs?
            2. JR: The true source/location of the attacker given away by his original probe.
          4. JR: We could do something simpler: ask the server if it has any open connections to the client. If the client is wedged and there is an open connection, then something is wrong. There's a row in you codebook that has a successful or unsuccessful attack
            1. .JS: Never sends a reset -- connection was established.
            2. JR: Investigate any computer that is wedged and has a connection.
          5. KL: Can we determine exactly which connection is suspicious?
            1. JR: If I give you ACK with a sequence number, source and destination, ports used, etc., we can figure out that it comes from that because it has consecutive sequence number. We can figure out which packets belong to the handshake -- can filter through router logs if connection is over.
            2. KL: What do we watch? Is the server now a beachhead to other places?
              1. JR: Look at routers -- see where attacker is in the network.
              2. KL: Think of normal behavior that could occur with these symptoms in isolation or in pairs.
    4. Fred Cohen Attack
      1. DOB: Fred sees tons of connections on port 23 (telnet). He's running TCP wrappers, so telnet connections are not allowed - sends out resets.
      2. One hour later, Fred sees a high stream coming from from Arizona. One hour time difference. Maybe the first guy is working with someone in AZ -- testing Fred's web site.
      3. Fred starts sending out email messages to everyone in those domains to find out why he's being attacked.
        1. One guy in internet was a web proxy. No one uses this machine -- it's a web proxy. in conjunction.
        2. One of the webmasters at get redirects the page to Fred's site. Internet user looks at web page -- hidden link that goes to Fred's machine. JS: Look at Fred's and log.
      4. KL: What would be like to know about it?
        1. KL: Logs for 1% of them, useful information there.
        2. Fred would like to know who put the Trojan to begin with? Very hard to find out.
        3. Which side was involved? Let administering know. If you're machine is sending something to port 23 stop it -- send message to Internet.
          1. JR: What you're sending to telnet is not tell net protocols, but http protocols. Fred gets request for a gif in html format.
          2. DOB: Can put web site on various ports -- 80 is most common. If you see HELO new line, probably mail. Search for mail message protocol. EHLO. Any initial get will have protocol in it. Todd did this several years ago.
          3. KL: Possible symptoms -- minimal info to maximal. People are running sniffers; they see lots of activity come in inconsistent with that particular port. They see it coming in from a lot of different sites, at the same time; some stuff comes in an hour later. All possible at Fred's side --unusual junk coming in. Now correlate this with activity at other site. It can be more than 1 web page that is attacked. 1% of user site are running logs. Somebody made a perfectly normal connection to web site, then abnormal connection.
      1. DOB: Client went to Looked at logs see series 1-6.
        1. DK: You have access to none of the servers and 2 clients.
          1. JR: Consider this a potential symptom -- if we're missing it; getting info from ISP, support. Include it as a possibility.
          2. DOB: A tailored query that was very specific might get results.
          3. DK: Worst-case scenario -- won't have access to web proxy. IF running IDIP, can tell it without sending mail.
        2. KL: Symptomatic of class of attacks. If we're getting flooding, what could we ask the duped client to do?
          1. JR: This could be a SYN flood or randomizing addresses.
          2. DOB: What if they're password guessing? Java applet sending out 2 password guess and results. Another attack is signing up to high volume mailing lists.
          3. KL: We get this attack, certain characteristic of connection. So our correlator searches rules to see if it looks similar to others; relating to temporal, ports, users correlation -- replies to 1% of the world. We get this info from everyone who's monitoring. Based upon any info that we can provide, trace back to if we can; determine source if possible, shut off to that.
            1. JS: Two is enough to same web page. If we search logs for our friends logs. JR: Somebody is keeping track of web data sources. KL: For next time, look at 3 scenarios, look at the language, related to each other. Sure things or generalize, it could be a variant.