Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision |
airtun-ng [2009/09/25 22:55] – Fixed typos darkaudax | airtun-ng [2010/11/21 16:14] – typos sleek |
---|
In order to perform wIDS data gathering, you must have the encryption key and the bssid for the network you wish to monitor. Airtun-ng decrypts all the traffic for the specific network and passes it to a traditional IDS system such as [[http://www.snort.org|snort]]. | In order to perform wIDS data gathering, you must have the encryption key and the bssid for the network you wish to monitor. Airtun-ng decrypts all the traffic for the specific network and passes it to a traditional IDS system such as [[http://www.snort.org|snort]]. |
| |
Traffic injection can be fully bidirectional if you have the full encyption key. It is outgoing unidirectional if you have the PRGA obtained via [[korek_chopchop|chopchop]] or [[fragmentation]] attacks. The prime advantage of airtun-ng over the other injection tools in the aircrack-ng suite is that you may use any tool subsequently to create, inject or sniff packets. | Traffic injection can be fully bidirectional if you have the full encryption key. It is outgoing unidirectional if you have the PRGA obtained via [[korek_chopchop|chopchop]] or [[fragmentation]] attacks. The prime advantage of airtun-ng over the other injection tools in the aircrack-ng suite is that you may use any tool subsequently to create, inject or sniff packets. |
| |
Airtun-ng also has repeater and tcpreplay-type functionality. There is a repeater function which allows you to replay all traffic sniffed through a wireless device (interface specified by -i at0) and optionally filter the traffic by a bssid together with a network mask and replay the remaining traffic. While doing this, you can still use the tun interface while repeating. As well, a pcap file read feature allows you to replay stored pcap-format packet captures just the way you captured them in the first place. This is essentially tcpreplay functionality for wifi. | Airtun-ng also has repeater and tcpreplay-type functionality. There is a repeater function which allows you to replay all traffic sniffed through a wireless device (interface specified by -i at0) and optionally filter the traffic by a bssid together with a network mask and replay the remaining traffic. While doing this, you can still use the tun interface while repeating. As well, a pcap file read feature allows you to replay stored pcap-format packet captures just the way you captured them in the first place. This is essentially tcpreplay functionality for wifi. |
*-t tods : send frames to AP (1) or to client (0) (optional / defaults to 0) | *-t tods : send frames to AP (1) or to client (0) (optional / defaults to 0) |
*-r file : read frames out of pcap file (optional) | *-r file : read frames out of pcap file (optional) |
| *-h MAC : source MAC address |
| *-H : Display help. Long form --help |
| |
Repeater options (the following all require double dashes): | Repeater options (the following all require double dashes): |
*- -bssid <mac> : BSSID to repeat. Short form -d. | *- -bssid <mac> : BSSID to repeat. Short form -d. |
*- -netmask <mask> : netmask for BSSID filter. Short form -m. | *- -netmask <mask> : netmask for BSSID filter. Short form -m. |
| |
| |
===== Scenarios ===== | ===== Scenarios ===== |
FromDS bit set in all frames. | FromDS bit set in all frames. |
| |
You notice above that it created the **at0** interface. Switch to another console sesssion and you must now bring this interface up in order to use it: | You notice above that it created the **at0** interface. Switch to another console session and you must now bring this interface up in order to use it: |
| |
ifconfig at0 up | ifconfig at0 up |
This is how to setup airtun-ng for this scenario: | This is how to setup airtun-ng for this scenario: |
| |
airtun-ng -t 2 ath0 -s BB:BB:BB:BB:BB:BB -a AA:AA:AA:AA:AA:AA -i ath0 | airtun-ng -t 1 ath0 -h BB:BB:BB:BB:BB:BB -a AA:AA:AA:AA:AA:AA -i ath0 |
| |
If you are able to see both sides of a WDS/Bridge network, you can enable bidirectional mode. This enables communication with both endpoint's networks. Be aware that bidirectional mode keeps track of clients behind each node in a list in memory, since it needs to know to which of the two endpoints it needs to send a packet to reach a certain client. If you use an embedded system, or there are large amounts of clients connected, this may slow down your machine. | If you are able to see both sides of a WDS/Bridge network, you can enable bidirectional mode. This enables communication with both endpoint's networks. Be aware that bidirectional mode keeps track of clients behind each node in a list in memory, since it needs to know to which of the two endpoints it needs to send a packet to reach a certain client. If you use an embedded system, or there are large amounts of clients connected, this may slow down your machine. |
| |
airtun-ng -t 2 ath0 -s BB:BB:BB:BB:BB:BB -a AA:AA:AA:AA:AA:AA -i ath0 -b | airtun-ng -t 1 ath0 -h BB:BB:BB:BB:BB:BB -a AA:AA:AA:AA:AA:AA -i ath0 -f |
| |
WDS mode is fully compatible with WEP encryption, so you can use the -w and -y flags as usual. | WDS mode is fully compatible with WEP encryption, so you can use the -w and -y flags as usual. |
| |
This loads the "tun" module. You can confirm it is loaded by running "lsmod | grep tun". If it does not load or there are problems, running "dmesg" and reviewing the end should show errors, if any. | This loads the "tun" module. You can confirm it is loaded by running "lsmod | grep tun". If it does not load or there are problems, running "dmesg" and reviewing the end should show errors, if any. |
| |
| ==== Error creating tap interface: Permission denied ==== |
| |
| See the following [[faq#why_do_i_get_error_creating_tap_interfacepermission_denied_or_a_similar_message|FAQ entry]]. |
| |