I came across this today and thought I’d share this helpful little wireshark capture filter. Based on wireshark’s documentation if you use
“ip.addr != 10.10.10.10” that should show you everything except for packets with the IP addrress 10.10.10.10. The problem is … it doesn’t work. It turns yellow like this, and doesn’t filter that IP.
The trick is to negate the whole statement, then it will work. Instead of doing “ip.addr!=10.10.10.10” run “!ip.addr==10.10.10.10”. Wireshark then is able to read it as NOT ip equal to, instead of IP is not equal to. Once you do that, you’re golden (well, green).
Simple enough, and it works with any statement — IE if you RDP into a machine and run a capture you should probably include “!tcp==3389” somewhere in your filter statement.
I hope I’ve made your day, at least a little bit easier!
A few days ago the phone rings, I get an ear-full about how some application isn’t working correctly and how it’s all the network’s fault and the repercussions of this outage will possibly cause so much damage that the world will start turning…the OTHER DIRECTION. Unfortunately for us IT Professionals, this is all too common of an occurrence. Nonetheless, I jumped in to see what I could do. I had never seen this application before so I had to start troubleshooting from the ground up. Very quickly I noticed it was running (or supposed to be running) over web protocols, so I whipped out the handy-dandy wireshark to get a look. Hm…it establishes a TLSv1 tunnel and shoots all the data at the server that way. Well, the Apps team was no where to be found so I had to find out what was moving across the wire here to figure out the issue. This is where fiddler comes in to play *Trumpets Fanfare*.
Fiddler is a fantastic little tool that does different things with packet captures and things of the sort. For this blog, I want to talk about its’ ability to man in the middle your own machine to provide visibility into an encrypted tunnel. Lets do a little demonstration here.
I’ve done a quick search in on bing, using HTTPS — thing fancy here at all.
I started fiddler prior to performing the search above, and this is what it shows up with, a whole bunch of nothing. Tunnel Tunnel Tunnel Tunnel…dang security.
Alas, fiddler has an option to man in the middle yourself and decrypt the tunnel! Just go to Tools > Fiddler Options > HTTPS > and check the box that says “Decrypt HTTPS traffic”. I chose browsers only for this demonstration, though you can do all traffic for other uses and applications.
It lets you know that you’re doing something that defies the laws of CAs.
Now here we go, re-launch the browser and go to https://bing.com, it throws a security error stating that the certificate is untrusted.
For this to work, you will need to add the exception, if you view the cert you can see that it was assigned to fiddler, when it’s clearly stating that it is for bing.com
Once that is all excepted, you can do the same search we did before — plain and simple.
Back to Fiddler, and ta-da! Congratulations, you’ve bypassed the security of your own data and now have visibility into the tunnel.
That’s it, very simple. You can view inside your SSL/TLS tunnel using fiddler in just a few simple steps. Side note, I was able to use that to determine what was happening on the wire for my application failure and was able to remedy the failure.
I hope I’ve made your day at least a little bit easier!