Hi all, Here is what I want to do, and the solutions I considered. Project : Sniff packets from my local network to identify DNS queries, store them in a plain database with host IP, timestamp and URL as attributes. Solution 1 - Promiscuous mode : I want to sniff only one network at a time, and since it is my own, the ideal solution would be to be connected to the network but capture every packet even if directed to some other IP. As far as I understand, this is called promiscuous mode, but it does not seem to work with my adapter (internal wifi card or external dongle). For instance, when starting a Wireshark/tshark capture, I am not able to sniff packets from/to different IP than mine (except broadcast). Obviously, everything directed from/to is captured. Solution 2 - Monitor mode : My wifi adapters can be switched to monitor mode (scan everything on the channel). Then, if I can sniff every packet on the channel (if possible with wlan capture filter to get rid off packets which do not belong to my network) and decrypt them on the fly, it would do the trick. But I am struggling with the decryption part... Of course I followed the wiki steps (https://wiki.wireshark.org/HowToDecrypt802.11), tried with wpa-psk and wpa-pwd, without success. My first thought was that, since I sniff a whole channel, packets may not be decrypted correctly, and Wireshark would think it is better not to apply decryption. Is this behaviour normal ? However, I am able to decrypt the traffic from the pcap file of this tutorial : http://www.lovemytool.com/blog/2010/05/wireshark-and-tshark-decrypt-sample-capture-file-by-joke-snelders.html. Thus, I am sure that Wireshark is able to decrypt and that I do the right thing. Then, either it is the wifi adapter fault (is it possible ?) or the way I proceed to filter my packets... Every suggestion is appreciated. And, by the way, I am more likely to use tshark than Wireshark, so command lines are welcome. C. asked 09 Sep '16, 08:30  thefiercerabbit edited 09 Sep '16, 08:36 |
2 Answers:
It's like when you take an appointment to your doctor because you're sick, and before you can get there you are already healed ! I should have been more careful. Quoting from https://wiki.wireshark.org/HowToDecrypt802.11. WPA and WPA2 use keys derived from an EAPOL handshake, which occurs when a machine joins a Wi-Fi network, to encrypt traffic. Unless all four handshake packets are present for the session you're trying to decrypt, Wireshark won't be able to decrypt the traffic. You can use the display filter eapol to locate EAPOL packets in your capture. In order to capture the handshake for a machine, you will need to force the machine to (re-)join the network while the capture is in progress. One way to do this is to put the machine to sleep (for smartphones and tablets, "turning off" the machine puts it to sleep) before you start the capture, start the capture, and then wake the machine up. You will need to do this for all machines whose traffic you want to see. WPA and WPA2 use individual keys for each device. Older versions of Wireshark may only be able to use the most recently calculated session key to decrypt all packets. Therefore, when several devices have attached to the network while the trace was running, the packet overview shows all packets decoded, but in the detailed packet view, only packets of the last device that activated ciphering are properly deciphered. Newer Wireshark versions are able to handle up to 256 associations and should be able to decode any packets all the time. Nevertheless decoding can still fail if there are too many associations. Filtering out only the relevant packets (e.g. with "wlan.addr") and saving into a new file should get decryption working in all cases. Wireshark only frees used associations when editing keys or when it's closed. So you may try that when decoding fails for unknown reasons. This also allows you to decode files without any eapol packets in it, as long as Wireshark did see the eapol packets for this communication in another capture after the last start and key edit. If decoding suddenly stops working make sure the needed eapol packetes are still in it. I guess both solutions 1 and 2 are affected by the fact I did not capture EAPOL handshake first. Then, even if the promiscuous mode works, I have to wait the handshake for each host. Some more tests are now necessary to know if this is enough to decrypt DNS queries... answered 09 Sep '16, 08:51 thefiercerabbit |
To collect frames for wireless diagnostics at application layer (e.g. DNS, per your specific case) requires several things:
Don't assume monitor mode == promiscuous mode in the wifi world. Sounds as if your adapter supports both, so you are all set. I would argue there is only one solution if using wireless sniffing for what you need and that is to have both of these features. As an alternative, could you have just grab wired traffic at the router or DNS server? No need to decrypt then, and less overhead handling all the CONTROL and MGMT frames. Perhaps you don't have wired access. answered 11 Sep '16, 06:09  Bob Jones
Actually I have wired access, but I want my script to be able to do without it. However, if I believe my previous tests, packets sent over WiFi are not repeated on the wire. Then, a DNS query would reach the router by the air, and my machine would not see any of it since it is only connected via the wire. I guess I should grab the traffic after the router, which is not possible in my case. (11 Sep '16, 13:46) thefiercerabbit I guess Bob's idea was that since you are interested specifically in DNS requests, these have to be sent to an external DNS server in the internet over the WAN, so he didn't come even close to an idea that WLAN frames should be mirrored on a LAN interface bridged with the WLAN one. But as you say you have no possibility to capture at the WAN side of your access point, you have to continue your way. In an environment you administer yourself, using any wireless AP which supports bridge mode gives you a chance to capture DNS traffic of clients at an Ethernet wire if you insert the capturing PC between the AP and the router, which would simplify the task a lot; in an environment administered by someone else, you are not likely to get access to the WPA passphrases so even the WLAN monitoring mode won't help you much. (12 Sep '16, 02:24) sindy |
Okay, now that I've finally finished my project, here is a link to the code.
This version only print the sniffed DNS traffic and the DHCP packets (to figure out when a client has joined to the network, etc...). The traffic can only be decrypted if the EAPOL packets have been captured before.
Remember to be in monitor mode and to have correctly set the channel.
Link : https://github.com/thefiercerabbit/dns-sniffer