GLOBAL GUARD MEETING
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)
TOPICS
News Items
Codebook Correlation
Connection Spoofing
Fred Cohen Attack
-
News Items
-
KL: Need some help doing viewgraphs - nothing fancy.
-
Meet this Thursday to discuss it.
-
Codebook Correlation
-
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?
-
DOB: The advantage of Smarts is that you can model your network.
-
KL: We know enough about the language to see if we could model it.
-
JR: Smarts deals with missing data and symptoms.
-
KL: Is the Smarts modeling language adequate?
-
JS: We just use their techniques, possibly find some limitations.
-
Connection Spoofing
-
JR: Use codebook to map symptoms to an attack.
-
DK: Client not responding is a symptom.
-
JR: If you only have 2 of 3 symptoms, you may have something else going
on.
-
DOB: 10% of connections will look like SYN floods due to incomplete TCP
-
Codebook approach will have assumptions that you see only as a result of
malfunctions. We couldn't necessarily assume they were attacks.
-
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?
-
DOB: Symptom of sequence number guessing - high probe packet rate. A symptom
is something you can measure - very basic.
-
Are hundreds of resets a suitable signature for sequence number guessing
or is a repeated pattern (see diagram below)
-
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
-
KL: Is it possible the reset doesn't come back because the server is flooded
with AKs?
-
JR: The true source/location of the attacker given away by his original
probe.
-
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
-
.JS: Never sends a reset -- connection was established.
-
JR: Investigate any computer that is wedged and has a connection.
-
KL: Can we determine exactly which connection is suspicious?
-
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.
-
KL: What do we watch? Is the server now a beachhead to other places?
-
JR: Look at routers -- see where attacker is in the network.
-
KL: Think of normal behavior that could occur with these symptoms in isolation
or in pairs.
-
Fred Cohen Attack
-
DOB: Fred sees tons of connections on port 23 (telnet). He's running TCP
wrappers, so telnet connections are not allowed - sends out resets.
-
One hour later, Fred sees a high stream coming from foo.edu from Arizona.
One hour time difference. Maybe the first guy is working with someone in
AZ -- testing Fred's web site.
-
Fred starts sending out email messages to everyone in those domains to
find out why he's being attacked.
-
One guy in internet was a web proxy. No one uses this machine -- it's a
web proxy. C2.org in conjunction.
-
One of the webmasters at C2.org get redirects the page to Fred's site.
Internet user looks at C2.org web page -- hidden link that goes to Fred's
machine. JS: Look at Fred's and C2.org log.
-
KL: What would be like to know about it?
-
KL: Logs for 1% of them, useful information there.
-
Fred would like to know who put the Trojan to begin with? Very hard to
find out.
-
Which side was involved? Let administering know. If you're machine is sending
something to port 23 stop it -- send message to Internet.
-
JR: What you're sending to telnet is not tell net protocols, but http protocols.
Fred gets request for a gif in html format.
-
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.
-
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.
-
DOB: Client went to C2.org. Looked at logs see series 1-6.
-
DK: You have access to none of the servers and 2 clients.
-
JR: Consider this a potential symptom -- if we're missing it; getting info
from ISP, support. Include it as a possibility.
-
DOB: A tailored query that was very specific might get results.
-
DK: Worst-case scenario -- won't have access to web proxy. IF running IDIP,
can tell it without sending mail.
-
KL: Symptomatic of class of attacks. If we're getting flooding, what could
we ask the duped client to do?
-
JR: This could be a SYN flood or randomizing addresses.
-
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.
-
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 C2.org if we can; determine source if possible, shut off
to that.
-
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.