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.
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.
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.
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
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.
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.
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.