Dan Siemon » Graph

Canada 3.0 Twitter graph

Dan Siemon — Tue, 13 Apr 2010 02:16:05 +0000

The other day I found Gephi which was used to create these amazing graphs based on GitHub data. So I thought it might be fun to pull some data into Gephi and play with it. I decided on using the Twitter API to obtain all of the Tweets related to the upcoming Canada 3.0 conference in Stratford, ON, CA. I used the ‘can30′ hash tag as the search term but since the Twitter search only returns Tweets less than seven days old the history is limited.

I used Python and igraph to create the graph and exported it to GraphML which Gephi can import. Here’s the resulting GraphML file if you are interested.

I also used igraph to export PNG and SVG versions.

The nodes in the graph are Twitter users. The size of the node is relative to the number of new Tweets with the #can30 hashtag. By ‘new’ tweets I mean not re-Tweets. The edges represent re-Tweets and the width of the edges are relative to how many times the source user re-Tweeted the destination.

Based on the graph, Canada3Forum is the largest source of new Tweets followed by tobidh and there are lots of users re-Tweeting Canada3Forum’s messages.

Canada 3.0 on Twitter

More fun with DNS packet captures

Dan Siemon — Tue, 29 Jul 2008 03:27:34 +0000

Following my last post on DNS query port usage, here are some more interesting DNS graphs.

The following graphs are based on a packet capture taken from the network interface of a recursive DNS server. This DNS server is one of the primary recursive DNS servers for a small Internet service provider. The capture includes all UDP DNS traffic to the DNS server as well as UDP DNS traffic from the DNS server to addresses within the local AS.

/usr/sbin/capinfos local.pcap
File name: local.pcap
File type: Wireshark/tcpdump/... - libpcap
File encapsulation: Ethernet
Number of packets: 200000
File size: 30702100 bytes
Data size: 27502076 bytes
Capture duration: 2659.328827 seconds
Start time: Sat Jul 26 01:45:31 2008
End time: Sat Jul 26 02:29:50 2008
Data rate: 10341.74 bytes/s
Data rate: 82733.89 bits/s
Average packet size: 137.51 bytes

Scatter plot of DNS query source ports

DNS query UDP port usage histogram

Scatter plot of DNS query response time

Scatter plot of failed DNS query response time

Scatter plot of successful DNS query response time

DNS queries by type

DNS query response time

Failed DNS query response time

Successful DNS query response time

IP packet size histogram

DNS query UDP source port graphs

Dan Siemon — Sat, 26 Jul 2008 05:33:26 +0000

Recently Dan Kaminsky announced a new DNS vulnerability. This isn’t a vulnerability in a particular DNS implementation but a problem with the DNS protocol itself. You can find information from CERT here. The exact details of the vulnerability were kept quiet even after DNS software vendors simultaneouslly released patches to mitigate the problem. One of the main changes made by these patches was to increase the number of source ports used for outgoing queries to other DNS servers. From this information it was wildly speculated that the vulnerability is related to cache poisoning.

Perhaps partly due to an accidental, early release of information the full vulnerability details are now available.

I happened to have some DNS captures available from before and after the patch was applied so I thought it might be interesting to graph the UDP query port usage behaviour for before and after the patch. The graphs presented below come from a RHEL 5.2 based DNS server. The post-patch DNS server version is bind-9.3.4-6.0.2.P1.el5_2. I don’t have the pre-patch version number handy but presumably it is the previous Bind package released by RedHat. Both of the captures came from the same DNS server but note that the capture length is different.

The difference is quite dramatic. Bind appears to be making good use of almost the entire port space.

DNS server source UDP query port usage before patch

DNS server source UDP query port usage after patch

Also note the interesting banding in the second graph. This behavior is not limited to the new patch. I have noticed this in other pre-patch captures as well. More on that later.