Using wire shark, how can capture or filter communication between two devices on a larger network. Eg, say we have this system:
PC1 ----|
|
| ______
PC2 ----|---| |--- Special Device
| |Router|
| |______|
PC3 ----|
If i want the packets of communication between PC1 (ip 139.136.59.13) and the Special device (ip 139.136.59.14). What is the filter command?
While you can use filters such as
(ip.src == 139.136.59.13 && ip.dst == 139.136.59.14) ||
(ip.dst == 139.136.59.13 && ip.src == 139.136.59.14)
This is complex. Better is to use ip.addr which will match on either src or dst:
(ip.addr == 139.136.59.13 && ip.addr == 139.136.59.14)
Related
I want to capture some network traffic with the filter like "src x.x.x.x and dst x.x.x.x".
Ususally it works, but it doesn't work when the network traffic is encapsulated by protocls like Gre or Vxlan.
For example, the Gre encapsulate a message like this:
Ethernet II, Src: VMware_91:f6:ad (00:0c:29:91:f6:ad), Dst: VMware_dc:c7:71 (00:0c:29:dc:c7:71)
Internet Protocol Version 4, Src: 10.75.2.161, Dst: 10.75.2.140
Generic Routing Encapsulation (Transparent Ethernet bridging)
Ethernet II, Src: Micro-St_e3:51:57 (4c:cc:6a:e3:51:57), Dst: VMware_91:f6:ad (00:0c:29:91:f6:ad)
Internet Protocol Version 4, Src: 10.75.2.11, Dst: 10.75.2.160
So what should I do to capture those inner traffic?
I use "src 10.75.2.160" to capture but it tcpdump captured nothing.
tcpdump -i eth0 "src 10.75.2.11"
It doesn't work.
I use "ip[54:4]" to capture, it works, but my leader tell me it's not accurate.
So what else can I try?
I don't know how accurate your leader wants the filter, but if we can make a few assumptions about the outer IP and GRE headers, then the filter isn't too complicated. So here are the 2 assumptions:
The outer IP header is a standard 20 bytes. If this isn't the case or can't be relied upon, then everywhere I use 20 in the filter will need to be replaced with the IP header length calculation, which is (ip[0] & 0x0f) * 4.
The GRE header is a standard size of 4 bytes. If options are present and you can guarantee that all GRE headers are exactly the same size, then you can substitute 4 for the actual GRE header length, but if GRE options could vary, then it should still be possible to specify a capture filter that works with any size GRE header, but it will be much more complicated and hard to follow. I leave that as an exercise for the reader.
With those assumptions out of the way, here's a filter that would be the equivalent of "src 10.75.2.11" but for the inner source IP address of a IP/GRE/IP packet:
(ip proto 47) && (ip[20 + 2:2] = 0x0800) && (ip[20 + 4 + 12:4] = 0x0a4b0x0b)
Explanation:
ip proto 47: This captures only IP/GRE packets as GRE is assigned protocol number 47.
ip[20 + 2:2] = 0x0800: Since 0x0800 is the assigned Ethertype for IPv4, this captures only GRE packets where the Protocol Type field is IP, so only IP/GRE/IP packets. (NOTE: RFC 1701 states, "The Protocol Type field contains the protocol type of the payload packet. In general, the value will be the Ethernet protocol type field for the packet.")
ip[20 + 4 + 12:4] = 0x0a4b020b: This captures only the IP/GRE/IP packets where the source IP address field of the inner IP header is 10.75.2.11. (NOTE: To get 0x0a4b020b from 10.75.2.11, you just need to convert each decimal octet to hexadecimal and combine them into a single 4 byte value.)
To verify the resulting BPF code, you can run tcpdump with the -d option to check that the filter meets your expectations, for example:
tcpdump -i eth0 "(ip proto 47) && (ip[20 + 2:2] = 0x0800) && (ip[20 + 4 + 12:4] = 0x0a4b020b)"
You should see output of the following form:
(000) ldh [12]
(001) jeq #0x800 jt 2 jf 9
(002) ldb [23]
(003) jeq #0x2f jt 4 jf 9
(004) ldh [36]
(005) jeq #0x800 jt 6 jf 9
(006) ld [50]
(007) jeq #0xa4b020b jt 8 jf 9
(008) ret #262144
(009) ret #0
If you're not familiar with BPF code, then I would suggest further reading elsewhere, as providing a BPF tutorial here is beyond the scope of this answer.
Finally, if you need to filter for the source IP address whether it's in the outer IP header or the inner IP header, then you can basically just combine the 2 filters, i.e.:
"(ip src 10.75.2.11) || ((ip proto 47) && (ip[20 + 2:2] = 0x0800) && (ip[20 + 4 + 12:4] = 0x0a4b020b))"
According to RFC 1928, we know the UDP request and reply header as follow:
+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable |
+----+------+------+----------+----------+----------+
ATYP address type of following addresses:
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
In reply scenario, when the ATYP is 0x03 (domain), how can the client know the real IP address of the remote destination?
When receiving a datagram from a remote host, the ATYP should not be X'03'. It should always be either X'01' or X'04' to carry the IP address of the reply sender. But, if for some reason, the UDP relay decides to set ATYP to X'03', it means the IP is being hidden, so there is no way for the receiving client to know what the sender's IP is.
When sending a datagram to a remote host, the ATYP may be X'03', if the sender wishes the UDP relay to use its own DNS resolution to determine the remote IP to send to.
I would like to capture all wifi traffic from a specific device manufacturer using Wireshark/Tshark/TCPDump/etc. I want to use a CAPTURE filter, not a display filter. Basically, I want to capture all packets from the MAC address 11:22:33:xx:xx:xx and nothing else. Or, put another way, the first 3 octets or OUI of the MAC address using Berkeley Packet Filtering Syntax. Anyone have a preferred method?
Per this post, use syntax like ether[A:B] in your capture filter where
A = start byte location in ethernet frame, starting at 0
B = number of bytes, must be 1, 2, or 4
So to match 3 bytes, you have to have 2 comparisons: Match 2 bytes and 1 byte separately.
If you only want about packets coming from this OUI (per question):
tcpdump 'ether[0:2] == 0x1122 && ether[2:1] == 0x33'
If you want all packets going to/from this OUI:
tcpdump 'ether[0:2] == 0x1122 && ether[2:1] == 0x33 \
|| ether[6:2] == 0x1122 && ether[8:1] == 0x33'
The first 12 bytes (0-11) of the ethernet header consist of the destination and then source mac addresses. So to select both sets of 3 bytes 0-2 and 6-8, select 2 bytes at 0, 1 byte at 2, 2 bytes at 6 and 1 byte at 8.
You should also be able to use this with tshark as long as you preface this with the -f capture filter flag.
Regarding the filters in Wireshark, what is the differencebetween !(ip.addr == 192.0.2.1) and (ip.addr != 192.0.2.1)? When check the result, it's not giving the same result and I don't know why...
Plus, when I apply the filter (ip.addr != 192.0.2.1) appears a different color as background in filters (Yellow).
image
Does anyone can help me? Thanks in advance.
In Boolean Logic, A not equals B and not A equals B are the same test.
But, the relevant part of the WireShark documentation linked by Jürgen Thelen explains that in WireShark, ip.addr covers both the source and destination field, so the test is more like:
not ((A or B) equals C)
which filters packets where source or destination match, and then hides them (correctly).
Compared to:
(A or B) not equals C
which filters packets where either the source OR the destination is not C, and that's every packet, so it shows every packet.
6.4.6. A Common Mistake
Using the != operator on combined expressions like eth.addr, ip.addr, tcp.port, and udp.port will probably not work as expected.
Often people use a filter string to display something like ip.addr == 1.2.3.4 which will display all packets containing the IP address 1.2.3.4.
Then they use ip.addr != 1.2.3.4 to see all packets not containing the IP address 1.2.3.4 in it. Unfortunately, this does not do the expected.
Instead, that expression will even be true for packets where either source or destination IP address equals 1.2.3.4. The reason for this, is that the expression ip.addr != 1.2.3.4 must be read as “the packet contains a field named ip.addr with a value different from 1.2.3.4”. As an IP datagram contains both a source and a destination address, the expression will evaluate to true whenever at least one of the two addresses differs from 1.2.3.4.
The reason it takes a yellow background is because of this potentially surprising behaviour, and there is a matching warning at the bottom of the screen, in the status bar, suggesting checking the user guide for more details:
Suppose we want to filter out any traffic to or from 10.43.54.65. We might try the following:
ip.addr != 10.43.54.65.
This translates to "pass all traffic except for traffic with a source IPv4 address of 10.43.54.65 and a destination IPv4 address of 10.43.54.65".
! ( ip.addr == 10.43.54.65 ).
This translates to "pass any traffic except with a source IPv4 address of 10.43.54.65 or a destination IPv4 address of 10.43.54.65".
You can see more on this at Wireshark: DisplayFilters.
I've capture a pcap file and display it on wireshark.
I want to analysis those udp packets with 'Length' column equals to 443.
On wireshark, I try to found what's the proper filter.
udp && length 443 # invalid usage
udp && eth.len == 443 # wrong result
udp && ip.len == 443 # wrong result
By the way, could the wireshark's filter directly apply on libpcap's filter?
All these work on Wireshark's filter
frame.len==243 <- I use this
ip.len==229
udp.length==209
data.len==201