A few days ago, Olli, one of our team members, sent me a funny trace that he’d taken while configuring the security settings on a Netoptics Bypass kit. This device has an SNMP and HTTP management service, and when he disabled the HTTP service he verified if the setting was accepted (like you should). Usually, there would either be a Reset packet coming back when a SYN is sent, or no answer at all. To his surprise, the device behaved a little different than expected.
It’s a funny thing about using Wireshark – I think I am pretty good at using it in an efficient way, but there are always some new tricks that I learn every once in a while.
The Multi IP layer problem
For a current IPS/IDS project I was looking for a test system to benchmark various IDS/IPS engines. The idea was to record network captures carrying malware samples in HTTP, SMTP or other protocols, and replaying them against the various detection engines. Problem with that is that tools like tcpreplay, bittwist or Ostinato all replay the trace on a single network card, which means that both “client” and “server” side of the communication are injected into the same NIC of the detection engine.
…before I found some time to post something on this blog. Mostly because of the summer break, but also because I was attending DefCon 2013 in Las Vegas, after a break of 3 years. I used to be at DefCon every year while it was held at the Riviera, working for the hotel as a network security expert (“We need protection! Evil hackers everywhere!”) with my buddies Eddi and Landi. Funniest thing the Riv guys did back then was to disconnect all public network ports accessible to the public (“the hackers”) like we told them too – well, all except one. That one, they put a small padlock in front of it. Our question to them was “uhm… did you know they have lock picking contests? What do you think will happen when they see this?” 😉
15 years ago, Wireshark was “born”, so happy birthday!
Take a look at the official Wireshark Blog for Gerald’s post. And watch Gerald’s keynote he did at Sharkfest 2013. And, of course, the funny video about how it was all Karen’s idea – which Gerald, at the time it was shown at Sharkfest, had no idea about (the video, I mean) 🙂
Trace file anonymization, trace file sanitization… it seems like I can’t decide whether to call it “Sanitization” or “Anonymization” – even in my code base it is sometimes called the first, sometimes the latter. Of course there is a small difference between the two – one is removing sensitive data by cutting it away, while the other replaces it with something generic.
Yesterday I returned from the annual Wireshark conference, Sharkfest 2013, and once again it has been a great conference. I had four talks (well, actually I had three, but one was scheduled to run twice and it looks like I never do a talk the same way), and one of them I did together with my coworker, Christian.
Update: since Wireshark version 1.12 is out, lots of people look for the meaning of “spurious retransmissions”, so I changed the post a little to make it easier to find what you’re looking for.
Today, while doing a lot of testing of my trace handling code as well as in preparation for the upcoming Sharkfest 2013, I got a trace sample from Landi that he wanted me to take a look at because he wondered about some SSL decoding stuff. So I did, and while we were talking about what the SSL dissector was doing I saw a new TCP expert message I had never seen before: “TCP Spurious Retransmission”.
Today I was using a combination of dumpcap and Wireshark to run a network forensics investigation against a server that may have been compromised. A couple of malicious files had been reported by the virus scanner, so I had to take a closer look at what it was doing in the network. Actually, dumpcap was already running for a couple of days in front of the firewall using a capture filter set to the server IP, recording everything that the server sent or received to and from the internet. So basically I wanted to separate good from bad traffic, if any, and see what was transferred.
It is one of the most common question on the Wireshark Q&A site: “I have xyz gigabyte of memory, but still Wireshark crashes when I try to capture data”, with xyz being a more or less impressive (or even ridiculous) amount of memory. This is how a typical crash looks like (your mileage may vary):