I would like to know, in case an attacker manged to capture some packets from my network traffic, can he build from them a file or any easy to understand thing?

I know that the TCP/IP protocol is using the TCP/UDP for segmenting the files (or whatever is being sent) in order to send it over the network, so if the file is large enough is segmented to some packets. In case all what you can get from sniffing is just a needle of text inside the blob (as much as i have seen that is the results of sniffing), why bother to encrypt the traffic of wireless networks, there is the SSL/TLS that are used mainly to encrypt the first authentication (username/password), why to encrypt all the traffic ?

My main concern is about the ability to build a file from the captured packets , is there an easy way to do so ?


Capturing packets already produces an output file (a capture file, actually) which includes packet contents, timing information, headers, etc. If you want to separate these packets into individual streams, a program like wireshark can do the appropriate searching and filtering for you. It can even decrypt SSL/TLS traffic if you have the certificate key.

If all you want to do is separate out the contents of individual TCP streams, a program called tcpflow will do that for you. Note that doing so discards a lot of useful data, including timing, headers, etc. But it can be very useful if you have a lot of traffic you'd like to grep. And on the subject of grepping traffic, have a look at ngrep to search traffic contents real-time.

And this barely scratches the surface of network interception, analysis, modification, and related tools.

| improve this answer | |

If the sniffer has all the packets that you sent, he can reconstruct all the data (files, mails, whatever) that you sent, for the simple reason that he has everything that the intended recipient has. If the sniffer only has some of packets, then he can still reconstruct part of your traffic — files with holes, so to speak. For example, if he has only some of the packets you received from an HTTP server, he has pieces of the file, knows in what order to put them, and has a rough idea of how much he's missed, because each TCP packet contains a sequence number that's incremented by 1 for each successive packet, and TCP packets have different sizes but often with not a lot of variance.

If the connection is encrypted (e.g. because it uses SSL), the sniffer only sees the ciphertext. So he knows who you're communicating with, and how much data you're exchanging (except for rare protocols that keep the target of packets confidential from eavesdroppers, but that makes routing difficult so is not done often).

If you have working encryption on a wireless network, then an eavesdropper who doesn't have access to the network (i.e. doesn't have the wifi password or whatever authentication is required) might still know how much traffic you're exchanging but not with whom. So there is some gain in using wifi encryption even if you're encrypting at the application level anyway. Another benefit of wifi encryption is that it doesn't leak non-encrypted data such as DNS requests, which can reveal more information about your network than you care for an eavesdropper to obtain without effort. Another benefit of wifi encryption is that someone might want to route traffic from your network, either to leech your bandwidth or to commit illegal acts that would be traced back to you. A third benefit is that if you've accidentally left some application unsecured on your local network, the wifi encryption will protect that application from an external attacker with no physical access to plug in his own device.

In summary, wifi encryption does provide significant protection against external threats. Note that I wrote “working wifi encryption” above: WEP is famously broken (takes just a few minutes to crack), WPA2 is fine against external attackers. WEP and WPA(2) are supposed to also provide protection against insiders, but that aspect is broken: under WPA2-PSK, the most common variant (with a single shared secret key), any participant can effectively eavesdrop and spoof other participants (see Any advantage to securing WiFi with a PSK, other than to keep out unauthorized and other wpa2 questions).

| improve this answer | |

If an attacker sniffs the traffic they can piece together everything that was in those packets. As an example, try running Wireshark on your network while transferring a file between two computers.

The packet trace will let you rebuild the entire file. Very easily!

Even if you only grab 50% of the packets, that will still provide you a lot of information.

So yes - this should worry you, it is easily possible, and it is why encryption is used!

| improve this answer | |

is there an easy way to do so ?

It depends, what protocols are you interested in sniffing ? HTTP, SMTP etc

With the Bro IDS you can specify mime types you wish to have decoded from HTTP traffic and ftp traffic. It will then dump these files to disc, for other protocols it can log the file contents but it will be mixed with the application layer protocol, this may not be a big deal for you.

This blog post contains most of the information you are looking for sans.edu

| improve this answer | |
  • 1
    Hi Mark, as per the faq, answers that are barely more than a link to a site are likely to be removed. If you could update your answer to include some more detail that would help. – Rory Alsop Dec 6 '11 at 12:38
  • cheers @RoryAlsop I have updated my answer. – Mark McDonagh Dec 6 '11 at 15:33
  • Excellent - have an upvote :-) – Rory Alsop Dec 6 '11 at 15:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.