Watch the new video comparing Google searches using HTTP and HTTPS -
now available at www.wiresharkbook.com/coffee. Note that the two trace files
used in the video are in the download section of that site.
If you haven't been following Google lately, you might have missed their "secure
search" announcement. It's HTTPS-based, but don't think you're totally secure
from prying eyes when you web browse (also see Chapter 23 of the Wireshark
Network Analysis book for details on HTTPS analysis).
Secure Search Doesn't Hide Target Browsing
Just because your Google search process is running with HTTPS and is
encrypted, this doesn't mean that when you click that link your browsing
session that follows is encrypted. Some chatter last week indicated that
Google's "secure search" somehow protected you more than it really does.
Sure, your browsing session is encrypted, but the minute you click on an HTTP
link, I can read the DNS query issued (if any) and the HTTP session to the target
site.
Yes, Removing the Referrer Data will Screw up Analytics
One "side effect" of Google's secure search option is that when you click on the
target link from the Google's secure search page, the referrer information is not
sent to the target - they can't tell from whence you came. Oh, boy - this really is
going to mess up the analytics.
Analytics-hounds are going to freak out on this one!
Get an All Access Pass at here and check out the video detailing the two Google
search processes.
Enjoy life... one bit at a time!
Laura
Tuesday, May 25, 2010
Sunday, May 2, 2010
Talking Tech with RunAs Radio
Last week I had the chance to talk with Richard Campbell and Greg Hughes of
RunAs Radio. You can listen here.
Don't know about RunAs Radio?
RunAs Radio started back in 2007 and offers weekly radio shows primarily for a
Microsoft-centric audience. My episode #160! I got interested in RunAs Radio
when I learned that Andy Malone had been interviewed recently on RunAs Radio
(I'm on a Cloud Computing panel with Andy at TechEd next month).
Grey Hair, Fire Extinguishers, Needles in a Haystack, Vegas and More
Although the session started with a reference to my ever-increasing grey hairs
and the need for a fire extinguisher in the kitchen, Richard pushed towards the
issues related to wireless analysis. "It's been abused so much."
We chatted about "jacked up access points" and saturation of the WLAN
environment in a Vegas casino.
Cool Topics/Presenters
Visit the RunAs Radio archives to check out the other 159 programs. Here are
some that I really enjoyed listening to.
Go check out the podcasts at RunAs Radio and enjoy life... one bit at a time!
Laura
RunAs Radio. You can listen here.
Don't know about RunAs Radio?
RunAs Radio started back in 2007 and offers weekly radio shows primarily for a
Microsoft-centric audience. My episode #160! I got interested in RunAs Radio
when I learned that Andy Malone had been interviewed recently on RunAs Radio
(I'm on a Cloud Computing panel with Andy at TechEd next month).
Grey Hair, Fire Extinguishers, Needles in a Haystack, Vegas and More
Although the session started with a reference to my ever-increasing grey hairs
and the need for a fire extinguisher in the kitchen, Richard pushed towards the
issues related to wireless analysis. "It's been abused so much."
We chatted about "jacked up access points" and saturation of the WLAN
environment in a Vegas casino.
Cool Topics/Presenters
Visit the RunAs Radio archives to check out the other 159 programs. Here are
some that I really enjoyed listening to.
- Doug Toombs - free tools - although he missed Wireshark for some
unknown reason - at least he got Nmap in there. Listen here. - Nick Simons - he's the guy that killed Clippy - Nick talks about some free
tools for IT pros. I know you all love free tools! Listen here. - Steve Riley - now over at Amazon's Cloud Computing division - it's
always interesting to listen to Steve. Listen here.
Go check out the podcasts at RunAs Radio and enjoy life... one bit at a time!
Laura
The "Death of" Series
I've been having a great time working on some really lousy networks! You too?! What a coincidence!
As conference season approaches (June), I've just finished writing up my draft presentations. I'll be starting a series of presentations inspired by the Dexter series on Showtime. As we've run through the entire season just recently, the
images of death were first and foremost on my mind when I started sketching out these presentations.
I'm going to have fun with this one! This is my "finger pointing" session and I have some major pointing to do! I'm not going to sugar coat some of the more recent causes of pathetic performance and I'll be showing the trace files used
to nail down who's really killing the network.
DEATH OF SECURITY: Breached Hosts/Stolen Data/IP Espionage
A long conversation with a buddy at a 3-letter agency gave me some ideas of what to share in this session. We'll talk some recent case stuff before looking at suspicious traffic and have a heart-to-heart about the methods in which your
network security may fail you.
ADD SOME HUMOR TOO...
It's not all death and doom though. I added some "ugly network" humor in there. In fact I'm going to have difficulty keeping a straight face as I walk through the traffic of a certain hip phone that exudes attitude on the network. Hmmm.... who could that be?
ALL ACCESS PASS MEMBERS
I'll be recording these "Death of" presentations for our All Access Pass members, so get a membership if you want to
catch these new presentations without heading to a conference.
Of course, I won't be serving wine or beer, but you'll probably remember the information better that way!
Enjoy life... one bit at a time!
Laura
As conference season approaches (June), I've just finished writing up my draft presentations. I'll be starting a series of presentations inspired by the Dexter series on Showtime. As we've run through the entire season just recently, the
images of death were first and foremost on my mind when I started sketching out these presentations.
I'm going to have fun with this one! This is my "finger pointing" session and I have some major pointing to do! I'm not going to sugar coat some of the more recent causes of pathetic performance and I'll be showing the trace files used
to nail down who's really killing the network.
DEATH OF SECURITY: Breached Hosts/Stolen Data/IP Espionage
A long conversation with a buddy at a 3-letter agency gave me some ideas of what to share in this session. We'll talk some recent case stuff before looking at suspicious traffic and have a heart-to-heart about the methods in which your
network security may fail you.
ADD SOME HUMOR TOO...
It's not all death and doom though. I added some "ugly network" humor in there. In fact I'm going to have difficulty keeping a straight face as I walk through the traffic of a certain hip phone that exudes attitude on the network. Hmmm.... who could that be?
ALL ACCESS PASS MEMBERS
I'll be recording these "Death of" presentations for our All Access Pass members, so get a membership if you want to
catch these new presentations without heading to a conference.
Of course, I won't be serving wine or beer, but you'll probably remember the information better that way!
Enjoy life... one bit at a time!
Laura
Wednesday, April 28, 2010
When Wireshark Gets Confused...
Note:
SIP/VoIP call setup is covered in Chapter 27 of Wireshark Network Analysis.]
I was scrambling around in preparation for a VoIP training session recently
when I opened a new VoIP trace file that depicted a simple call set up routine
followed by the actual call.
Strangely, Wireshark had an issue identifying one side of the SIP connection -
as you can see in the graphic above. Wireshark dissected one-half of the
conversation as FF (Foundation Fieldbus) traffic.
What in the world is going on here?
Wireshark defines the protocol column value based on the highest layer of
decode that it can apply to the packet. In this case, Wireshark found something
in these packets to indicate the traffic was Foundation Fieldbus packets.
I compared the packets defined as "FF" to the packets correctly interpreted as
SIP.
Aha! The port number fields tell the story. In the UDP header, packets that
contained the source port of 1089 are dissected as Foundation Fieldbus. Ok -
let's just skip past the fact that the sender in Frame 2 above is not responding
to the correct port number defined in Frame 1.
My focus was on getting Wireshark to dissect the packets marked Foundation
Fieldbus as SIP packets. I certainly don't want to alter the preferences of
Wireshark so that all packets containing source port 1089 are dissected as SIP
packets (as they likely are just ephemeral ports and not SIP at all).
The quick solution is to right click on the packets dissected as Foundation
Fieldbus and select Decode As. Selecting SIP as the desired dissection and
applying this to the trace file fixed the problem quickly. Wireshark now
dissected source port 1089 as SIP. Clicking the "Show Current" button in the
Decode As window displays all manually altered dissection configurations.
It's not often that I have to apply Wireshark's Decode As function - typically I hit
companies using non-standard port numbers for applications for various
understandable and just plain whacky reasons).
It's a great feature to know - just in case you hit a strange dissection.
Enjoy life... in the Netherlands... one bit at a time!
Laura
SIP/VoIP call setup is covered in Chapter 27 of Wireshark Network Analysis.]
I was scrambling around in preparation for a VoIP training session recently
when I opened a new VoIP trace file that depicted a simple call set up routine
followed by the actual call.
Strangely, Wireshark had an issue identifying one side of the SIP connection -
as you can see in the graphic above. Wireshark dissected one-half of the
conversation as FF (Foundation Fieldbus) traffic.
What in the world is going on here?
Wireshark defines the protocol column value based on the highest layer of
decode that it can apply to the packet. In this case, Wireshark found something
in these packets to indicate the traffic was Foundation Fieldbus packets.
I compared the packets defined as "FF" to the packets correctly interpreted as
SIP.
Aha! The port number fields tell the story. In the UDP header, packets that
contained the source port of 1089 are dissected as Foundation Fieldbus. Ok -
let's just skip past the fact that the sender in Frame 2 above is not responding
to the correct port number defined in Frame 1.
My focus was on getting Wireshark to dissect the packets marked Foundation
Fieldbus as SIP packets. I certainly don't want to alter the preferences of
Wireshark so that all packets containing source port 1089 are dissected as SIP
packets (as they likely are just ephemeral ports and not SIP at all).
The quick solution is to right click on the packets dissected as Foundation
Fieldbus and select Decode As. Selecting SIP as the desired dissection and
applying this to the trace file fixed the problem quickly. Wireshark now
dissected source port 1089 as SIP. Clicking the "Show Current" button in the
Decode As window displays all manually altered dissection configurations.
It's not often that I have to apply Wireshark's Decode As function - typically I hit
companies using non-standard port numbers for applications for various
understandable and just plain whacky reasons).
It's a great feature to know - just in case you hit a strange dissection.
Enjoy life... in the Netherlands... one bit at a time!
Laura
Tuesday, April 20, 2010
Europe Welcomes Wireshark University
On May 31st, the first Wireshark University course opens in the Netherlands!
The Core 1 course registration is now open with our first European partner,
SCOS. For information, visit www.wiresharkuniversity.nl.
You do not want to miss this event!
This course teaches you how to capture wired and wireless traffic and interpret
the most common TCP/IP communications including IP, ICMP, UDP, TCP,
DNS, ARP, DHCP, HTTP and email traffic.
Register online today at http://www.wiresharkuniversity.eu/trainingdates.htm.
For more information, email info@scos.nl.
In addition, SCOS is a European distributor of the new Wireshark Network
Analysis book (www.wiresharkbook.nl). There should be copies of the book
available at the training to help you prepare for the upcoming Wireshark
Certified Network Analyst Exam (due Q2/2010). For more information on the
Exam, visit Wireshark University.
Betty DuBois, Lead Wireshark University Instructor, will be presenting this 5-day
event focusing on the key capabilities of Wireshark, the world's most popular
network analyzer, and TCP/IP communications analysis.
Special thanks to Matt Hamburg of SCOS for hosting this very special event.
Enjoy life... in the Netherlands... one bit at a time!
Laura
The Core 1 course registration is now open with our first European partner,
SCOS. For information, visit www.wiresharkuniversity.nl.
You do not want to miss this event!
This course teaches you how to capture wired and wireless traffic and interpret
the most common TCP/IP communications including IP, ICMP, UDP, TCP,
DNS, ARP, DHCP, HTTP and email traffic.
Register online today at http://www.wiresharkuniversity.eu/trainingdates.htm.
For more information, email info@scos.nl.
In addition, SCOS is a European distributor of the new Wireshark Network
Analysis book (www.wiresharkbook.nl). There should be copies of the book
available at the training to help you prepare for the upcoming Wireshark
Certified Network Analyst Exam (due Q2/2010). For more information on the
Exam, visit Wireshark University.
Betty DuBois, Lead Wireshark University Instructor, will be presenting this 5-day
event focusing on the key capabilities of Wireshark, the world's most popular
network analyzer, and TCP/IP communications analysis.
Special thanks to Matt Hamburg of SCOS for hosting this very special event.
Enjoy life... in the Netherlands... one bit at a time!
Laura
Wednesday, April 14, 2010
Baseline Today!
In one of the early book reviews, Marcos Christodonte II states “I’m a firm
believer in baselining network traffic. In this section, Wireshark Network
Analysis details the importance of baselining and the types of traffic to focus on.
Like other sections, this section also provides screenshots, showing how to
analyze traffic and packet statistics.” [Read the full review here.]
Every IT professional should take baselining seriously. It’s not difficult to do and
will save you time, money, frustration and possibly your job when all hell breaks
loose on the network.
Baselines define your network’s vital signs when it is healthy. Baselines are
used to define not only the basic traffic flows of an application or process – they
also help define the number of connections required by a process, the type of
connection, the port numbers, interdependencies with other hosts, typical round
trip times, average packet per second rates, average load time and more.
Chapter 28 includes my baseline checklists - listing the traffic you should be
capturing and what you should be looking for when characterizing "normal"
behavior.
For example, if you want to create a baseline of your login/logout sequences,
consider the following questions:
When someone complains about a slow login process, compare the current
ugly login to the baseline you created.
You don't have to know everything about every packet and protocol in use. Use
the ugly trace and the baseline trace to identify large gaps in time, large
differences in packets, unusual error responses. All of this enables you to point
the finger at the problem.
Remember - in a finger-pointing world, the only finger
that counts is the network analyst's finger!
So… schedule some time to create your baselines now – before you need
them.
Enjoy life... one bit at a time!
Laura
believer in baselining network traffic. In this section, Wireshark Network
Analysis details the importance of baselining and the types of traffic to focus on.
Like other sections, this section also provides screenshots, showing how to
analyze traffic and packet statistics.” [Read the full review here.]
Every IT professional should take baselining seriously. It’s not difficult to do and
will save you time, money, frustration and possibly your job when all hell breaks
loose on the network.
Baselines define your network’s vital signs when it is healthy. Baselines are
used to define not only the basic traffic flows of an application or process – they
also help define the number of connections required by a process, the type of
connection, the port numbers, interdependencies with other hosts, typical round
trip times, average packet per second rates, average load time and more.
Chapter 28 includes my baseline checklists - listing the traffic you should be
capturing and what you should be looking for when characterizing "normal"
behavior.
For example, if you want to create a baseline of your login/logout sequences,
consider the following questions:
- What discovery process takes place during login?
- What server does the client connect to?
- What are the processes seen during login?
- How many packets does a typical login require?
- Are there any login dependencies?
When someone complains about a slow login process, compare the current
ugly login to the baseline you created.
- Are there any large gaps in time?
- Are there any Expert Info notifications?
- Do you see the same number of conversations as in your baseline?
- Do you see the same number of endpoints as in your baseline?
- Do you see the same protocols as in your baseline?
- Do you see the same number of packets as in your baseline?
- Do you see the same dependencies as in your baseline?
- Did the name resolutions process match your baseline?
You don't have to know everything about every packet and protocol in use. Use
the ugly trace and the baseline trace to identify large gaps in time, large
differences in packets, unusual error responses. All of this enables you to point
the finger at the problem.
Remember - in a finger-pointing world, the only finger
that counts is the network analyst's finger!
So… schedule some time to create your baselines now – before you need
them.
Enjoy life... one bit at a time!
Laura
Tuesday, April 6, 2010
HELP! I've Been Tooned
If you went to BrainShare 2010 and watched the Monday or Thursday keynotes,
they were preceded by two short behind-the-scenes videos. In each video a
domineering packet geekess prepares systems for the show while "Fred"
(likely the user from hell) sweats it out through last-minute stress.
Yup - the geekess was my voice and a toon of me (although my boobs are
smaller as I told the project coordinator, Russ Dastrup, after seeing the initial
animation images).
Russ asked me to prepare a script of some of the geeky things that I might say
- if you're an old-timer, you might have caught the reference to Compsurf
(remember those good old days?). There was also a reference to Wireshark in
there.
Chris Miller supplied the voice talent for Geeko and Fred - from what I heard at
the recording studio, Chris is a pretty famous voice talent (Geppetto in Shrek is
listed as one of his credits - cool!). Those voices were recorded before mine. I
meandered into Soundtek Studios here in Campbell, California for my voice-
overs. When I walked in I was spending more time looking at their recording
equipment (they are a Mac shop) than the instruments (although I did consider
playing a little tambourine).
It was ironic when they had network problems (an unplugged Ethernet cable)
before we started. The technician, Pat, was speaking another language most of
the time - "too hot" "too out there" "more eeeee". At one point he told me to be
"less orgasmic" when I was trying to add some energy to my voice (I'd been up
almost all night working book edits and I was in dire need of a triple espresso).
At the keynote a few people said "Hey! That's Laura!" and they were right. Ya just
never know where I'll show up.
Enjoy life... one bit at a time!
Laura
they were preceded by two short behind-the-scenes videos. In each video a
domineering packet geekess prepares systems for the show while "Fred"
(likely the user from hell) sweats it out through last-minute stress.
Yup - the geekess was my voice and a toon of me (although my boobs are
smaller as I told the project coordinator, Russ Dastrup, after seeing the initial
animation images).
Russ asked me to prepare a script of some of the geeky things that I might say
- if you're an old-timer, you might have caught the reference to Compsurf
(remember those good old days?). There was also a reference to Wireshark in
there.
Chris Miller supplied the voice talent for Geeko and Fred - from what I heard at
the recording studio, Chris is a pretty famous voice talent (Geppetto in Shrek is
listed as one of his credits - cool!). Those voices were recorded before mine. I
meandered into Soundtek Studios here in Campbell, California for my voice-
overs. When I walked in I was spending more time looking at their recording
equipment (they are a Mac shop) than the instruments (although I did consider
playing a little tambourine).
It was ironic when they had network problems (an unplugged Ethernet cable)
before we started. The technician, Pat, was speaking another language most of
the time - "too hot" "too out there" "more eeeee". At one point he told me to be
"less orgasmic" when I was trying to add some energy to my voice (I'd been up
almost all night working book edits and I was in dire need of a triple espresso).
At the keynote a few people said "Hey! That's Laura!" and they were right. Ya just
never know where I'll show up.
Enjoy life... one bit at a time!
Laura
Subscribe to:
Posts (Atom)