Transcript 1.0 MB - CCC Event Weblog

Network Black Ops:
Extracting Unexpected Functionality
from Existing Networks
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Introduction
(Who am I?)

Fifth Year Of Public Security Research



Several books




Subjects: SSH, TCP/IP, DNS
Code: Paketto Keiretsu, OzymanDNS
Hack Proofing your Network
Stealing The Network: How To Own The Box
Aggressive Network Self-Defense
Formerly of Cisco and Avaya
What Are We Here To Do Today?
The Tiniest Shred of MD5
 IP Fragmentation
 Firewall / IPS Fingerprinting
 DNS Poisoning (and other tricks)
 DNS v. The Sony Rootkit
 Scanning The Internet
 Visualizing That Scan

Introducing IP Fragmentation



"Fragmentation…an interesting early architectural error that
shows how much experimentation was going on while IP was
being designed." -- Paul Vixie
Fragmentation: If a packet is too large for the underlying link
layer, it may be split by any router (unless behavior is
explicitly disabled) into multiple fragments
Why a problem? IP is supposed to be “stateless”




Fire a packet and forget about it
Receive a packet and be done with it
Fragmentation keeps the former but destroys reception
Systems need to keep fragments around, wait for future
fragments, reassemble...what if fragments overlap?
IP Fragmentation: Some History

Major mechanism for evading IDS


“Insertion, Evasion, and Denial of Service:
Eluding Network Intrusion Detection.” –
Newsham and Ptacek, 1998
Fragrouter, Dug Song, 1999
Remaining Adventures in Reassembly:
Adventures In Temporality


IP has been mostly “picked clean”…is there anything
left?
Timing Attacks



Successful against cryptosystems all the time
Are there any timers in IP?
The IP Fragment Reassembly Timer

Maximum amount of time a fragment will be held, unassembled,
before it “expires” and is flushed


Differs from OS to OS – yes, it’s a fingerprint


LibNIDS actually noticed that you need to handle this to
reassemble correctly!
Ofir Arkin noted IP fragment scanning, but not fingerprinting
Can we evade with this?
It’s Skew

What if the IDS has a different concept of
expiration time than the host?

If IDS expires first: Just send fragments too slow for the
IDS but fast enough for the target


But what if host expires first?



This definitely happens
Linux/FreeBSD timer: 30s
Snort frag2 timer: 60s
Is it possible to still evade an IDS when its timer lasts
longer than that of your target’s?
Protocol Inversion



Problem: IDS keeps fragments for too long
Solution: Make IDS drop fragments
Strategy: Fragments leave the reassembly
queue when either they aren’t reassembled…or
when they are.


Is it possible to give the IDS something to reassemble
against – without causing the target host to undergo a
similar reassembly?
Of course – use a timing attack!
The Temporal IP Attack





Prepare:
 Nice request, malicious request, and a shared header between the two
 Header: HTTP 1/1 GET
 OKFrag: index.html
 MalFrag:
msadc/..%255c../..%255c../..%255c../winnt/system32/cmd.exe
?/c+dir+c:%5c
1) Send IDS payload
2) Wait. Host will drop. IDS won’t.
3) Send shared header. IDS sees the two fragments it needs to
reassemble a packet – and gets a legitimate request. Host dropped the
IDS payload, so it just stores the header.
4) Send host payload. Host sees the two fragments it needs to
reassemble a packet – and gets attacked. IDS dropped the shared header,
so it just stores the host payload (and never reassembles it).
Time Anneals All Wounds




T=0: Send MalPay
 Host:
MalFrag in Reassembly Queue
 IDS:
MalFrag in Reassembly Queue
T=30: <just wait>
 Host:
Nothing in Reassembly Queue
 IDS:
MalFrag in Reassembly Queue
T=31: Send Header
 Host:
Header+MalFrag = MalPacket
 IDS:
Header in Reassembly Queue
T=32: Send OKPay
 Host:
OKPay in Queue
 IDS:
Header+OKPay = OKPacket
Changing Course

Some IPS’s will block this (they handle the IP ID overlap). What
now?

What are IPS’s?




Security products in general are under increased scrutiny



Firewalls w/ dynamic rulesets / censoring IDS
These dynamic rulesets can trigger on increasingly obscure faults across
the entire communication stack
What they’ll trigger against differs from product to product, version to
version
Combine complex state machines with a need for maximum efficiency
Over 20 advisories regarding vulnerabilities in security products
Blocking sends information

Is it possible to use this leaked information to fingerprint security
architectures?
Hopcount Desync (SLIDE FROM
2003 – FW fingerprinting is not new)






root@arachnadox:~# scanrand -b1k -e
local.doxpara.com:80,21,443,465,139,8000,31337
UP:
64.81.64.164:80
[11]
0.477s
DOWN:
64.81.64.164:21
[12]
0.478s
UP:
64.81.64.164:443
[11]
0.478s
DOWN:
64.81.64.164:465
[12]
0.478s
DOWN:
64.81.64.164:139
[22]
0.488s
What’s going on:
The host is genuinely 11 or 12 hops away. All of the up ports reflect that, but
only a few of the downed ports. The rest are showing double the remote
distance. This is due to the a PIX firewall interspersed between myself and the
target. It’s (too) quickly reflecting the SYN I sent to it right back to me as a
RST|ACK, without resetting values like the TTL. Thus, the same source value
decrements twice across the network – 22 = 11*2 – and we can detect the filter.
Firewall/IPS Fingerprinting:
Other products





Tipping Point: Does not allow out-of-order TCP segments – everything
must arrive on the edge of a window
Checkpoint: Does not allow (by default) DNS packets that declare EDNS0
(DNSSec!) support
L3/L4 Mechanisms
 Invalid Checksums (at IP, TCP, UDP, ICMP)
 Invalid Options (at IP and TCP, and actually UDP too)
 Out of order fragments/segments (at IP and TCP)
 Invalid ICMP type, code
Application Layer Mechanisms
 Invalid HTTP request types, or TRACE/WebDAV
 SQL Injection in TCP payloads (WITHOUT the necessary line
terminator)
 Invalid DNS
Using Schiffman’s “Firewalk” methodology, each query leaks the location of
the blockage – and I can always walk to the host _before_ the FW
IPv6 Reassembly A Coming
Fingerprint

What encapsulations will a given IDS/IPS
support?



There are so many variations
They chain – IPv6 in IPv4 in IPv6 in IPv4, etc.
Nowhere near all could possibly be parsed by
every client

Thus many different possible signatures – blocks
4in6 exploits, blocks 6in4in6 exploits, blocks
Teredo exploits, etc.
A Problem for IDS/IPS people

There are an astonishing number of ways to
bridge IPv4 and IPv6.



Here’s another: Name servers hosted on both IPv4 and
IPv6 can resolve names against either protocol, using
addresses delivered via either protocol.
These ways all chain – Teredo in IPv4 in IPv6 in
IpV4 over DNS, etc.
Not all chains can (or should) work for every client

How can an IDS/IPS have any hope of predicting what its
clients will perceive?
Three approaches to IPv6
Encapsulation Management

1) Enforce only a few encapsulations

So you drop traffic from a few hosts


2) Scrub (unpack and repack) all encapsulations down to
one mode you make decisions on


This strategy makes the Internet fall apart
I very much like packet scrubbing, but there’s not been a
scalable scrubber deployed yet
3) Ask.

Upon seeing a new encapsulation style, synthesize a new, safe
packet – an ICMP Ping, in particular – and submit it to a target
host with the same encapsulation pattern

Will return both whether a packet can be encapsulated like that and
the precise policy used to resolve fragmentation conflicts
However, IPS’s should not do this.

“After sufficient amounts of invalid traffic,
we just ban you from our network.
Fingerprint THIS!”



I’ve heard this a lot lately. Some of you know
why.
Many automatic shunning systems deployed
Not a good idea.

To understand why automatic shunning is bad –
just dig.
It Might Be Bad To Shun These Guys.













; <<>> DiG 9.3.0rc2 <<>>
.
511355 IN
.
511355 IN
.
511355 IN
.
511355 IN
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.
NS
NS
NS
NS
172766
604777
604782
604786
604791
604797
172766
F.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
IN
IN
IN
IN
IN
IN
IN
A
A
A
A
A
A
A
198.41.0.4
192.228.79.201
192.33.4.12
128.8.10.90
192.203.230.10
192.5.5.241
192.58.128.30
Something More Elegant

Spoofing malicious traffic from the root servers –
ugly, yes, kills a net connection, sure, but:



Too large scale
Been whispered about for years
But there are other name servers…


I’ve been investigating DNS poisoning
Is it possible, given networks that implement automatic
network shunning, to poison name server caches and
thus selectively hijack network traffic?
The Name Game

The general theme: Block communication between two
name servers


Bad: Targeted Denial of Service – Customers from a particular
network are unable to contact a particular bank/merchant/email
provider
Worse: Targeted DNS Poisoning – Being unable to
communicate, a window is left open for an extended period of
time for a flood of fake replies to eventually hit on the correct
answer



It’s a race, and the other guy now has a broken leg
Welcome to Worst Case Scenario Engineering
Can either block server at client net, or client at server
net
Double Sided

Spoof malicious traffic from the client network to
the server network


Client will have outstanding requests to the server – if
they’re using a fixed DNS port*, only 32K requests on
average to find their TXID’s
How do we make them look up a given network on
demand?


Recursion – Just ask them to look up www.merchant.com
PTR NS Forwarding – Claim that, to look up your IP, it’s
necessary to ask the nameserver at www.merchant.com.
Then use your IP to go to their web server
Double Density

Spoof malicious traffic from the server network to the client
network


Client can make requests, but server responses are blocked
But wait? Aren’t our own forged responses blocked too?


Funny thing about DNS…about 15% of servers reply from a
different IP address than you talked to in the first place!
With a lack of interface affinity in servers, comes an ignorance of
incoming IP address on clients
 This is BTW why UDP NAT2NAT works


So while the legitimate server responds in vain, our attacks can
come in from anywhere
Moral of the story: Automated network shunning is a
very bad idea. Do not give the world access to your
firewall tables.
Poppa’s Got A New Pair Of Shoes

Prolexic – who I worked with on the Opte internet mapping
project – has given me a very high bandwidth connection to
work with



They’re a third-party spam filter for IP – your data is BGP’d to
them, they forward you a filtered stream.
I actually can’t generate packets faster than this network can
route 
Been actively probing the Internet DNS Infrastructure


Partnering with Mike Schiffman of Cisco Critical Infrastructure
Assurance Group and Sebastian Krahmer at the University of
Potsdam (and maybe you – send me a proposal?)
Extremely large scale scans – every IP, every name server,
everywhere
Always Bet On Black


100% legitimate packets – this isn’t a global pen
test, this is an investigation in to the largest
cooperative caching architecture on the Internet –
one that is getting poisoned again
Asking: How is this architecture laid out? How
prevalent is DNSSec support? Where do we
need to invest resources in protection? And what
is going on with DNS poisoning?


We can’t manage what we can’t measure. This is an
attempt to measure.
Not the first to do a large scale network scan
DON’T TRY THIS AT HOME

“Where’d my colo go?” 



You will get complaints
You will get calls from scary sounding places
As well you should. This is behavior that
normally precedes an attack.

So why am I doing it? Because the attackers
should not have better intel than we do.
Open And Honest

Reverse DNS


deluvian root # nslookup 209.200.133.226
Non-authoritative answer:
226.133.200.209.in-addr.arpa name = infrastructureaudit-1.see-port-80.doxpara.com.
Web info




Technical details
Explanation of motivation
Links to papers, news articles
My phone #
ARIN Updated

NetRange: 209.200.133.224 209.200.133.255 CIDR:
209.200.133.224/27 NetName:
DANKAMINSKY-SECURITY-RESEARCH
NetHandle: NET-209-200-133-224-1
Parent: NET-209-200-128-0-1 NetType:
Reassigned Comment: This is a
security research project, please
send all Comment: abuse and alert
requests to [email protected].
RegDate: 2005-07-08 Updated: 200507-08
And even with…

Still, large scale analysis does not go
unnoticed, uninvestigated, and
uncomplained about

After further explanation, almost all
administrators have been courteous

“Thank you for the information. See you in
Vegas.”
Some Early Results



Priority 1: Google was taken out by an exploit that hit MSDNS
systems forwarding to BIND4/8. Find all of these.
To begin with – need to identify all name servers on the Internet
 Requirement: Legitimate lookup that worked on every normal
name server, but would not be of a type to require recursion
 Disabling the recursion desired bit doesn’t always work,
apparently
 Lookup: 1.0.0.127.in-addr.arpa PTR
 Expected reply: localhost.
 Actual replies: Rather more complicated.
 Could also have sent traffic on TCP/53 but not all servers accept
Now can set about finding which ones are related to which other
ones
Interrelationship Reminder


Recursion Desired: Able to control whether a server looks values up for you, or
if it just tells you what it already knows
Three mechanisms for determining interrelationships:
 Simple Injection: Inject a value into one server using a recursive unique
request. Then non-recursively query other servers for that name
 Accurate, but slow (N^2)
 TTL Offset Measurement: Recursively request a unique value from each
server, and analyze the Time To Live on the response data.
 Response may be “fresh” – have original TTL, “3600 seconds”
 Response may be “stale” – have offset TTL, “3540 seconds”
 See who we were scanning 60 seconds ago to see which lookup
caused this cache entry to already exist
 Server/Recurser Correlation: Recursively request a unique value in a
domain you control, then see who comes to that domain to service that
request
 Ask Alice to look up Alice.Doxpara.Com. If Bob comes looking for
Alice, Alice and Bob appear to be linked.
What was found?

2.5M verified name servers


Up to nine million possible, but 2.5M have been / remain responsive
All 2.5M have been run through Roy Arend’s FPDNS



NOTE: FPDNS gives more data than CH TXT (explicit version requesting),
and…er…doesn’t set off nearly as many alarms.
At least 230K forwarding to Bind8, as specifically forbidden as per
ISC BIND documentation – almost 10% of the sampled DNS!
At least 13K Windows name servers still forwarding to Bind8!


At least 53K “OTHER”
BIND8->BIND8 forwardings must be further analyzed, to determine
multihomed vs. a true forwarding relationship


This can be found by – can data enter one cache, without entering the
other? If so, one is higher in a hierarchy than another
Is BIND9->BIND8 forwarding problematic? 18.7K instances.
Anything else?

Many, many hosts out there do reverse lookups, not
expecting the target they’re investigating to be aware of this

38K name servers doing lookups


Exponential curve of requests – most only have 1, maximum
has 14,221


Some who are invisible to direct querying
Cable modem DNS
Warning: Possible to backwards map from scanned IP to
elicited PTR request by shuffling scan orders and looking for
correlation between a particular IP being contacted and the PTR
request returning!
So What’s New

Scans have been repeated, analysis is under way

Over 50GB of compressed traffic


Writing a custom anonymizer for research consumption
Original Thought: Most interrelationships are
shallow – maybe one hop deep. Reality more
complicated.



Majority of hosts resolve for themselves
About 40K connected graphs, most 2 deep (ask Alice, get
request from Bob).
Then…there’s this other guy.
I LIKE BIG GRAPHS AND I
CANNOT LIE




220K node
330K edge
22 deep?
One case:
Ask one
host, 1200
different IP’s
forward the
request???
But Just In Case You Think Pretty
Pictures Are Meaningless…
The Need for Accurate Maps:
Measuring The Sony Rootkit

Sony did a bad thing – placed malicious code on 2.1M CDs
 Some people think the malice is contained to the cloaking
code.




Malice Through Overstayed Welcome: If you are my friend, but
you refuse to leave my home, you very quickly become not my
friend. If you do this to all your friends, quickly you have no friends.
Sony’s DRM was designed to achieve bare minimum, if any,
consent – and then to avoid any situation where that consent could
be effectively revoked
If your reaction to “If people knew we were here, they’d try to
get rid of us” is to try to make people not know you’re there,
you are a criminal and you apparently know it
Repeatedly releasing broken uninstallers – one of which
actually just updated your code to the latest version – doesn’t
help
No Data!

But how widespread was the problem?



Security professionals: We have different responses to
something on 100 hosts, vs, +10K vs. +1M
Could have been a mountain out of a molehill – what if we found
a rootkit and nobody was silly enough to install it?
Where’s our normal data?



Sony: Likely advised not to release accurate figures
Microsoft: Likely in some sort of Blu-Ray deathmatch
AV Vendors: Sony approached them days after the story broke.
They’ve released no figures since.
 Bruce Schneier: What do we do when the makers of malware are
colluding with the very people we pay to protect us from malware?

Rather than waiting…
Data: Any Port In A Sony Storm

All discs with the XCP-Aurora rootkit also had
code that connected to a Sony owned site,
connected.sonymusic.com


This is not an IP address that the Internet can route. To
retrieve traffic from this address, a DNS lookup from a
local name server is required
When a server looks content up, it caches the response in
case the results would be useful to anyone


They’re useful to me
Non-recursive queries allow a client to non-destructively
query caches – I’d only get responses if someone had
recently caused that server to look up a name

Paper: “DNS Cache Snooping” by Luis Grangeia
Original Results

556K hosts w/ Sony linked names

165 countries



.mil / .gov penetration detected


Very odd – discs only sold in the US
Theory: CD Piracy – just because Sony didn’t sell it, doesn’t
mean it wasn’t sold. We got here because of CD Piracy,
remember? RIAA confiscated 6M pirate CDs in the US in
2003 – and they didn’t get them all.
Not just American
Mappage


Partiview – software for Astrophysicists…and white hats 
Used libipgeo and IP2Location to place IP’s on shiny
OpenGL globe
Signal To Noise Ratio[0]

Already Filtered Noise

RD-ignorance: Some number of servers will do recursive
lookups anyway, even if you ask them not to – and if
they’re forwarding to anyone, they’ll pollute these
upstream caches



Handled by looking up a “control” name – any host that is
able to return a control name has been polluted
Knocks out 350K hosts – actually +900K hosts that returned
links
Also filtered out any server that returned incorrect records
for any name, and any entry with a fixed TTL divisible by
100 (often signs of fresh data instead of cached)
Signal To Noise Ratio[1]

Problems

updates.xcp-aurora.com




Very popular name
Supposedly connected to directly by rootkit
75% agreement between servers that connect to updates
and connect to connected.sonymusic.com
Not actually linked to by Sony rootkit
 High correlation between those who thought they might be
infected and those who investigated removal?
 Not just a geek story?!?
 Cannot disclose accurate numbers regarding what percentage
of connected.sonymusic.com CDs also had the rootkit.
Appears to be 100% for all Sony-BMG releases since March.
Signal To Noise Ratio[2]

xcpupdates.sonybmg.com: 302 redirect on
connected.sonymusic.com for XCP infected discs

Thank you J. Alex Halderman for actually going to Sony and seeing what
happens if you go to the connected.sonymusic.com address


Limitations





May not have been in place when story broke
Actually hosts a banner ad informing people they’ve got a problem (this is
good, responsible behavior, and deserves to be specifically identified
as such)
Covers discs that may have run the uninstaller by now
Problems


Thank you DMCA for making me afraid to do this myself.
Does uninstaller prevent immediate reinstallation?
Presumably does not apply to discs that never shipped w/ the potentially
risky code, as the banner ad is pretty clear that There Be Dragons
Site useful for measuring deployment rates
Xcpimages data

350K+ positive hits





Again, after control nodes are filtered out
70K+ in Europe
135 countries
Still finding .gov/.mil
Conclusion: Best available data suggests
this remains a large scale problem

Sony continues to be invited to provide better data
Hello Attorneys General










12588 'FLORIDA'
9719 'CALIFORNIA'
7962 'MASSACHUSETTS‘
6310 'NEW JERSEY'
5018 'TEXAS'
4228 'PENNSYLVANIA'
3713 'TENNESSEE'
3362 'VIRGINIA'
3047 'NEW YORK‘
…2017 'ILLINOIS'
Projects



Try to recover some of the filtered nodes by
managing the connected graphs
Estimate backend clients per name server by
measuring traffic at central authoritative DNS
aggregation points
Better scheduling – determine “least impact” on
topology so we can scan faster

Internet Scale Flow Control required

Where else have I seen this problem…
Rapid Infrastructure Mapping
HOWTO [0]


1) Collect a list of subnets that have at least one host with one
service. This will be the destination canary.
2) Setting a “max_ttl” value to your average distance to a host,
transmit canary connection attempts w/ Scanrand from 1 to max_ttl.
 Run the scan such that the last byte of the IP address is
maintained
 This minimizes bandwidth load per subnet
 Scanrand places the original TTL in the ipid – can be recovered
 scanrand2 -b2m -f hostlist+:53 –l1-$MAX_TTL –t0
–H –M1 –T infra_map > results.sql; cat
results.sql | mysql dns
 2mbit, select port 53 for each IP, scan up to maximum TTL,
disable timeouts, output SQL to table name “infra_map”.
Then cat the file into mysql.
Rapid Infrastructure Mapping
HOWTO[1]

3) After importing the data into MySQL, reorder it back into normalseeming traceroutes as such:
select trace_hop,trace_mid,trace_dst from newscan
group by trace_dst,trace_mid order by
trace_dst,trace_hop
------------------------------------------------1
209.200.133.225 12.10.41.178
2
67.17.168.1
12.10.41.178
3
67.17.68.33
12.10.41.178
4
208.50.13.254
12.10.41.178
5
12.123.9.86
12.10.41.178
6
12.122.10.53
12.10.41.178
7
12.122.9.129
12.10.41.178
8
12.122.10.2
12.10.41.178
9
12.123.4.153
12.10.41.178
10
12.125.165.250 12.10.41.178
Rapid Infrastructure Mapping
HOWTO[2]

4) For each line in the mass traceroute, if the
destination of the previous line is the same as this one,
and if the hop number for the last line is one less than
the previous line, then there can be assumed a link
between the last midpoint and the present midpoint.



1 a bar
2 b bar
3 c bar
5 d bar
1 a car
Links can be assumed between a and b, and b and c.
There is probably a SQL mechanism to automate this – “if
hop > 1 and hop-1 exists, column one is hop-1.trace_mid
and column two is hop.trace_mid”
Rapid Infrastructure Mapping
HOWTO[3]

OPTIONAL:
 1) Find Faraway Hosts: For each IP where a hop was found
at max_ttl, scan that IP up to a new max_ttl
 2) Manage The Non-Flat Network: Scanrand allows scans to
come from different points in the network, but arrive at the same
collector. Use this to collect routes invisible from your own
position.
 3) Mind The Gap: Schedule “gap filling” scans for packets
dropped during an initial run
 4) Choose Your Path: Attempt to source route packets,
though so many networks block them
 5) Map Latency: Apparently, latency maps are useful. I get
full latency information statelessly (timestamp in cookie)
 5) Pretty Pictures: Throw it into an OpenGL grapher
Rapid Infrastructure Mapping: IPv6?

I need a high speed node w/ IPv6 access



I don’t think Hurricane Electric wants to tunnel what
I’ve got in mind… 
Traceroute, DNS most obvious legitimate
mechanisms for discovering populated space
Some IP options – source routing, potentially
spoofs from multicast may help

Routing Headers back to self allows for bidirectional
traceroute – able to detect and analyze asymmetric
routes!
Understanding The Flood

We could import the received data into LGL
(Large Graph Library)



Get huge graphs like Opte or Cheswick/Lumeta
Static, very resource intensive to compile, can’t
be really monitored in real time
Our data is streaming in but we’re only viewing a
static summary of it?
Xovi: Streaming Graph Visualizer

Input: Text description of each edge




Process: Lay nodes out according to Fruchterman-Reingold algorithm




Code from Doug Gregor, Boost Graph Library
Algorithm very interesting – handles anything, new nodes in the middle
of layout, disconnected graphs, etc.
Height: Optional, but it’s (out_degree – in_degree)
Output: Dump to OpenGL



Alice Bob
10.0.1.11 10.0.5.100
“www.cnn.com” “/foo”
SDL implementation – portable to whatever
BSD licensed
So lets see it!
Xovi Tips and Tricks

Pipe stuff in via SSH



ssh user@host “tcpdump –ln not port
22” | ./xovi –
Can’t SSH into your server? Pipe
sflowtool’s CSV mode into Xovi
Web hits: Graph resources to referrers


Cat http.log | cut –d
ssh cat http.log | cut –d” “ –f 7,11
| xovi.exe –
TODO







0) DIRECTED GRAPHS SHOULD APPEAR DIRECTED 
1) Multi-Sets – I should be able to compare different sets against
eachother
 Port 80 vs. Not Port 80
2) More Visual Differentiators
 Color, Shape, Motion, Vibration
3) Active Highlighting
 Highlight an area with your mouse to get details – not just “there is
structure” but “what is this structure”
 Hello splunk
4) A slightly more complex grammar for input
 Print timestamps on graph
 Add labels to graph
5) Dynamic configuration of system
 Sliders for expiration, etc.
6) History receding into Z? A Cheswick Stack
Why use graphs?



There’s more than just pretty pictures
Ultimately, services that do not adapt to broken networks are isolated onto
very broken networks
Traditional adaptation mechanisms completely fail, since we’re only
sending a few packets to every host
 What we need are canaries – they are sent, a few a second, to each
hop we’re scanning through. When the canaries die, we know we’ve
overloaded that network.
 Graphs work perfectly for this
 For every destination, we know which routers will get a traffic spike
from us communicating with it
 For every router we are canary-monitoring, we know which
destinations we are now closer to
 We would thus be able to model outbound transmissions as a
high pressure water system, against which taps may be made
Done



That’s all folks 
Any questions?
Email is [email protected] – I’m very
interested in collaborating / sharing data