November 24, 2016
For packet geeks like me, the annual Wireshark conference SharkFest is the place to be in order to meet and network with other packet geeks. However, for various reasons I haven't been able to attend SharkFest before. So when my friend Jasper Bongertz mentioned that there was going to be a SharkFest conference here in Europe I felt that this was a chance I just couldn't miss.
One thing I really liked about SharkFest Europe (#sf16eu) was the unique chance to discuss topics such as network traffic analysis and protocol specifications with other attendees. One example of such a discussion was an interesting breakfast conversation regarding whether the TCP receive window size is affected when TCP segments are SACK'ed.
Many Wireshark core developers are flown in to the Sharkfest events, so this is a golden opportunity to discuss feature requests or bugs you might have encountered in Wireshark. I grabbed the opportunity to talk to many of the core developers and I was amazed by how very friendly and humble all the developers were. I get a feeling that this great atmosphere is set by the tone of Gerald Combs. As a direct result of talking to the Wireshark developers I was able to read packets from PacketCache directly from Wireshark.
There were, of course, also several great presentations at SharkFest Europe. Many of these talks were recorded and can now be found on the SharkFest'16 Europe Retrospective page.
One of my favorite presentations was Jasper's talk titled “Tackling the Haystack: How to Process Large Numbers of Packets”, where he provided some reflections from working with large PCAP datasets to find network problems or intrusions. Jasper gave lots of good advice on how to approach the task of analyzing PCAP datasets containing several hundred gigabytes of captured traffic.
One particular wisdom that Jasper shared with the audience was, ”I never filter on port during captures. […] Capture everything, sort it out later”. This is fully in line with how I perform network sniffing for forensic purposes. I even have a name for sniffing traffic without capture filter; I call it is sniffing in “Pokemon mode”, which of course refers to the “catch 'em all” slogan.
I also enjoyed Eddi Blenkers' talk “Windows Filesharing De-Mystified: SMB with a Eureka! Effect” where Eddi took us for a trip down memory lane to revisit the early days of NetBIOS and the “Yellow Cable” a.k.a. Thick Ethernet (10BASE5).
Eddi's talk was extra interesting for me since he did a deep dive into the NetBIOS, SMB and SMB2 protocols. Several things that Eddi mentioned were actually new to me, even though I have personally spent many hours reading protocol specifications and implementing parsers in for all these protocols.
The fact that I and Eddie have approached these protocols from different angles and for different purposes is most likely the reason why we have both deep-dived into different aspects of these protocols. I usually analyze SMB traffic when performing network forensics in order to find out what commands and resources an attacker accesses on a compromised network, while the work Eddi presented focused on finding bottlenecks and performance problems in a Windows file sharing environment.
For me, who has primarily worked with incident response and network forensics, meeting all these experts in network performance troubleshooting was a refreshing change of crowd compared to the security researchers and hackers that I usually meet at security conferences. Nevertheless, there were many SharkFest visitors working in the security field as well as within law enforcement, so I felt quite at home as well.
It's interesting to see, that in this great mix of different professions and industries, all attendees at SharkFest Europe come together for a common interest; to better learn how to analyze captured network traffic.
Erik Hjelmvik is the Developer of NetworkMiner, a Network Forensic Analysis Tool (NFAT) and a frequent contributor to Garland Technology's Expert Corner and Tap into Technology blog.
Read more from Erik.
Photo: Garland's Chris Bihary with Erik at Sharfest '16 Europe
If the inline security tool goes off-line, the TAP will bypass the tool and automatically keep the link flowing. The Bypass TAP does this by sending heartbeat packets to the inline security tool. As long as the inline security tool is on-line, the heartbeat packets will be returned to the TAP, and the link traffic will continue to flow through the inline security tool.
If the heartbeat packets are not returned to the TAP (indicating that the inline security tool has gone off-line), the TAP will automatically 'bypass' the inline security tool and keep the link traffic flowing. The TAP also removes the heartbeat packets before sending the network traffic back onto the critical link.
While the TAP is in bypass mode, it continues to send heartbeat packets out to the inline security tool so that once the tool is back on-line, it will begin returning the heartbeat packets back to the TAP indicating that the tool is ready to go back to work. The TAP will then direct the network traffic back through the inline security tool along with the heartbeat packets placing the tool back inline.
Some of you may have noticed a flaw in the logic behind this solution! You say, “What if the TAP should fail because it is also in-line? Then the link will also fail!” The TAP would now be considered a point of failure. That is a good catch – but in our blog on Bypass vs. Failsafe, I explained that if a TAP were to fail or lose power, it must provide failsafe protection to the link it is attached to. So our network TAP will go into Failsafe mode keeping the link flowing.
Single point of failure: a risk to an IT network if one part of the system brings down a larger part of the entire system.
Heartbeat packet: a soft detection technology that monitors the health of inline appliances. Read the heartbeat packet blog here.
Critical link: the connection between two or more network devices or appliances that if the connection fails then the network is disrupted.