tshark capture and filter HTTP in WPA2 secured network

asked 2019-04-12 15:54:49 +0000

dizcza
3 ●1 ●1 ●3

updated 2019-04-13 08:21:25 +0000

I want to capture HTTP traffic of WPA/WPA2 secured network through Alfa adapter, put in a monitor mode, Since, without any capture filter, file size grows quite fast, I want to save only HTTP and EAPOL handshakes to be able to decrypt HTTP packets. I suppose, the filter option should be

tshark -i wlan0mon -f "ether proto 0x888e or tcp port 80" -w tshark.pcap

But tcp port 80 filter works well only in open wifi. In WPA2, it filters out all packets. What options do I have? Or rather what filters might I use to capture as little irrelevant packets (not HTTP or not EAPOL) as possible in WPA network?

Update

The goal is to monitor which unsecured HTTP sites nearby users of some AP of a particular channel visit. For a reliable estimate, statistics should be gathered for a few hours / a day. Users might connect and disconnect at any time so I don't know their MACs beforehand. However, if I don't use any capture filter, or for example drop beacons only (wlan[0] != 0x80), I often see "TCP previous segment not captured" and "TCP ACKed unseen segment". Using wlan host <MAC> results in a more stable capture. But as I've already said, I might not know all potential users' MACs since not all clients might be connected. Wired capture is not an option.

edit retag flag offensive close merge delete

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2019-04-12 20:06:19 +0000

Ross Jacobs
71 ●3 ●32 ●13

updated 2019-04-12 20:06:35 +0000

You'll want to filter by as many elements as are unique to the traffic you are looking at. If you can filter only by your wlan MAC address of the Alfa device, you should do so. Such a filter looks like

<existing filter> and (wlan addr1 <wlan mac> or wlan addr2 <wlan mac>).

You should also take a look at, ring buffers (-b) and snaplen (-s) to further decrease the size of the capture. Ultimately, this is a chicken-and-egg problem because you want to use a capture filter to limit traffic to http, but can only ascertain whether the packets are http after decrypting post-capture.

Noting that this is semi-related to your previous question about Wireshark not decrypting HTTP POSTs.

edit flag offensive delete link

Comments

I suppose this is the same as wlan host <mac1> or wlan host <mac2>? I don't see such a filter in CaptureFilters wiki.

dizcza ( 2019-04-13 08:23:00 +0000 )edit

tcpdump syntax is going to mostly be the same as tshark -f capture filter syntax (which are technically both forms of Berkeley Packet Filer. Valid identifiers for host are IP addresses and FQDNs vs wlan addr1/addr2/src/dst, which are layer 2.

Ross Jacobs ( 2019-04-13 09:32:35 +0000 )edit

I suppose this is the same as wlan host <mac1> or wlan host <mac2>?

No. wlan host <mac> checks both the DA and the SA in both management and data frames. The DA might be addr1 or addr3; the SA might be addr2, addr3, or addr4 - the generated code figures that out based on the frame type and the To DS and From DS flags.

wlan addr1 <mac> always checks the addr1 field; wlan addr2 <mac> always checks the addr2 field.

I don't see such a filter in CaptureFilters wiki.

The CaptureFilters page on the Wireshark Wiki is not an exhaustive manual for capture filters; it gives some examples, but doesn't document the complete syntax.

It says

A complete reference can be found in the expression section of the pcap-filter(7) manual page.

so go there for a reference; it documents all the filter expressions supported.

Guy Harris ( 2019-04-13 09:35:27 +0000 )edit

tcpdump syntax is going to mostly be the same as tshark -f capture filter syntax (which are technically both forms of Berkeley Packet Filer.

tcpdump syntax is going to be exactly the same as tshark -f capture filter syntax if tcpdump and tshark are using the same version of libpcap, as both filter syntaxes are libpcap filter syntax.

Guy Harris ( 2019-04-13 09:41:36 +0000 )edit

Is there a way not to filter by mac in wlan addr1/addr2? Something like wlan addr1 *?

dizcza ( 2019-04-16 16:18:54 +0000 )edit

add a comment

answered 2019-04-12 22:44:59 +0000

Bob Jones
1496 ●2 ●179 ●22 Boston, MA

You are going to have to decrypt prior to filtering. Have a look at this answer: https://osqa-ask.wireshark.org/questions/24249/decrypt-wpa-with-tshark

I'm not sure it will meet your needs but it is a start - it may only work on capture files already collected, not decrypt --> filter --> store.

If it works, this capture scheme falls into the category of 'just because you can doesn't mean you should'. What do you think will happen when your capture system misses an EAPOL frame? Packet loss is a big issue with wireless networks, so your whole scheme will cease to work until the next plain text EAPOL handshake comes through cleanly. You have already chased packet loss in one of your previous questions, but that was a decrypted data packet. If you miss an EAPOL frame then you can't decrypt at all. If you move to WPA2-Enterprise, the EAPOL handshake will not be enough, either, to decrypt as the PMK is not precomputed (perhaps not a problem in your use case). Also note that most wifi systems have session timeouts which trigger rekeys at certain intervals; sometimes, these rekey events are encrypted themselves, so the next 4-way EAPOL handshake to freshen the PTK and GTK is itself encrypted with the previous PTK. So it's a daisy chain: if you miss one, you would not get the subsequent ones until the wireless client gets a deauth() and the EAPOL handshake occurs unencrypted.

May I suggest you move to a wired capture? Capture at the exit of the AP or the router, for instance. Less traffic to deal with, no decryption problems, and no issue with loss at the capture adapter. Port mirroring switches can be had on Amazon for $25 if your infrastructure does not support it already.

edit flag offensive delete link

Comments

it may only work on capture files already collected, not decrypt --> filter --> store.

Yes, it makes sense. I thought why not decrypt on the fly and then save the relevant packets only. But decryption requires capturing all potential packets with additional decryptions time cost overhead.

dizcza ( 2019-04-13 08:33:16 +0000 )edit

add a comment

answered 2019-04-13 03:38:50 +0000

Guy Harris
19890 ●3 ●659 ●207

Capture filters work on raw packets; they're executed either in the kernel (on Linux, *BSD, macOS, Solaris 11, AIX, and Windows) or in libpcap (HP-UX, Solaris 10 and earlier) before they get to Wireshark and thus before any decryption is done.

This means they do not work on the payload of 802.11 packets on a protected network; you can only filter on 802.11 MAC header fields.

edit flag offensive delete link

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

tshark capture and filter HTTP in WPA2 secured network

3 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

tshark capture and filter HTTP in WPA2 secured network edit

3 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

tshark capture and filter HTTP in WPA2 secured network