The Systems Engineer organized chaos: tcpdump

Showing posts with label tcpdump. Show all posts

Sunday, May 5, 2013

How to copy a pcap file from ASA firewall

Cisco uses a different way to run and save packet captures on its ASA firewall than a popular Linux tcpdump/Wireshark tools. Below is a quick recipe how to copy out a pcap file from the firewall for offline analysis.

Problem

How to copy pcap file from ASA.

Solution

This is our exmaple capture session running on ASA

 
capture mycap type raw-data access-list myacl buffer 100000 interface outside

By using scp method.

 
ssh FW
# conf t
# (config) ssh scopy enable

# copy /pcap capture: flash:myfile.pcap

Source capture name []? mycap

Destination filename [myfile.pcap]?

!!!!!!!!!!!!!!!!!
433 packets copied in 0.170 secs

# now from another box you can download the file 
# scp user@fw-ip:myfile.pcap .

By using https mothod.

 
# if you want to restrict access to https specify ip and netmask instead of 0
http 0.0.0.0 0.0.0.0 outside
http server enable

https://user:pass@fw-ip/capture/capure-name
https://user:pass@fw-ip/capture/capure-name/pcap

References

Sunday, April 28, 2013

How to capture HTTP traffic using tcpdump

Everyone knows tcpdump but not everyone knows how to use it in efficient way. Below is a nice trick how to capture the HTTP GET request and the server response in plain text.

 
root@server:~# tcpdump -c100 -A -l -tttt -s0 -qpnni any port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes

2013-04-28 13:57:16.725851 IP6 2a00:1a48:7805:111:8cfc:cf10:1111:111.54909 > 2a00:1450:4009:808::1011.80: tcp 0
`....(.@*..Hx...........*..P@   ...........}.P/.Hp......8@.     .........
..b.........
2013-04-28 13:57:16.728057 IP6 2a00:1450:4009:808::1011.80 > 2a00:1a48:7805:111:8cfc:cf10:1111:111.54909: tcp 0
`....(.7*..P@   ..........*..Hx............P.}}.[./.Hq..7..{.........
^.....b.....
2013-04-28 13:57:16.728093 IP6 2a00:1a48:7805:111:8cfc:cf10:1111:111.54909 > 2a00:1450:4009:808::1011.80: tcp 0
`.... .@*..Hx...........*..P@   ...........}.P/.Hq}.[............
..b.^...
2013-04-28 13:57:16.728445 IP6 2a00:1a48:7805:111:8cfc:cf10:1111:111.54909 > 2a00:1450:4009:808::1011.80: tcp 166
`......@*..Hx...........*..P@   ...........}.P/.Hq}.[............
..b.^...GET / HTTP/1.1
User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: www.google.com
Accept: */*


2013-04-28 13:57:16.729989 IP6 2a00:1450:4009:808::1011.80 > 2a00:1a48:7805:111:8cfc:cf10:1111:111.54909: tcp 0
`.... .7*..P@   ..........*..Hx............P.}}.[./.I.....^E.....
^.....b.
2013-04-28 13:57:16.742677 IP6 2a00:1450:4009:808::1011.80 > 2a00:1a48:7805:111:8cfc:cf10:1111:111.54909: tcp 988
`......7*..P@   ..........*..Hx............P.}}.[./.I......h.....
^.....b.HTTP/1.1 302 Found
Location: http://www.google.co.uk/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=ID=0241f520b15aae6e:FF=0:TM=1367157332:LM=1367157332:S=5lVTK-ZqTfrki7HN; expires=Tue, 28-Apr-2015 13:55:32 GMT; path=/; domain=.google.com
Set-Cookie: NID=67=OyloOHElfW8AKOcsRJ4DeQnfMhqfmnqJgcpYXlsSrN2ouREV9KHjS9boJZTfBoFZvYtVg0ugcBa2lJQKX-WrQ_uMxoIvPg-4JehPfFEdyGl_oh0RS37x_V6a_ozMElzJ; expires=Mon, 28-Oct-2013 13:55:32 GMT; path=/; domain=.google.com; HttpOnly
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Date: Sun, 28 Apr 2013 13:55:32 GMT
Server: gws
Content-Length: 221
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.co.uk/">here</A>.
</BODY></HTML>

2013-04-28 13:57:16.742700 IP6 2a00:1a48:7805:111:8cfc:cf10:1111:111.54909 > 2a00:1450:4009:808::1011.80: tcp 0
`.... .@*..Hx...........*..P@   ...........}.P/.I.}._w...........
..b.^...
2013-04-28 13:57:16.743753 IP6 2a00:1a48:7805:111:8cfc:cf10:1111:111.54909 > 2a00:1450:4009:808::1011.80: tcp 0
`.... .@*..Hx...........*..P@   ...........}.P/.I.}._w...........
..b.^...
2013-04-28 13:57:16.745725 IP6 2a00:1450:4009:808::1011.80 > 2a00:1a48:7805:111:8cfc:cf10:1111:111.54909: tcp 0
`.... .7*..P@   ..........*..Hx............P.}}._w/.I.....ZS.....
^.....b.
2013-04-28 13:57:16.745743 IP6 2a00:1a48:7805:111:8cfc:cf10:1111:111.54909 > 2a00:1450:4009:808::1011.80: tcp 0
`.... .@*..Hx...........*..P@   ...........}.P/.I.}._x...........
..b.^...

10 packets captured
10 packets received by filter
0 packets dropped by kernel

Friday, November 9, 2012

How to forcibly kill an established TCP connection in Linux

During one of the repros I needed to find a way to kill an already established TCP session but without killing the process that opened it.

Problem

How to kill an ESTABLISHED TCP connection in Linux.

Solution #1: passive mechanism

We can use a little tool called tcpkill that you can find desription and example usage here link

tcpkill -i eth0 { expression }

When started it first listens on a wire for any traffic matching your expression filter (that is compatible with tcpdump expressions). This is passive mechanism to learn about the TCP ACK and SEQ numbers. Once it knows the numbers it spoofs a TCP segments and try to reset the TCP session on both sides.

If the TCP session is idle or in generic there is no data being exchanged than this passive mechanism unfortunately is not going to work.

Solution #2: active mechanism

This killcx tool is taking a different approach and tries to generate traffic on the wire to discover what the ACK and SEQ numbers are. Once it forces the peer to replay to its spoofed traffic it kills the TCP session immediately after.

killcx.pl dest_ip:dest_port

Simple demonstration

tcpkill (passive)

On 2 different hosts we simulate a daemon that actively listens on incoming traffic and a client that initiate a connection to a server. Once a TCP session is created the client sent single byte. The commands show the outputs.

root@server:~# nc -v -l 7777                                                                                       
Connection from 164.177.146.87 port 7777 [tcp/*] accepted
a

root@client:~# nc -D 5.79.21.166 7777
a
b

Below are tcpdumps showing TCP handshaking and 1 byte exchange on both hosts.

root@server:~# tcpdump -i any -nn port 7777
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
23:15:59.049739 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [S], seq 2946797440, win 14600, options [mss 1460,sackOK,TS val 726987371 ecr 0,nop,wscale 2], length 0
23:15:59.049803 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [S.], seq 2303834803, ack 2946797441, win 14480, options [mss 1460,sackOK,TS val 350774705 ecr 726987371,nop,wscale 3], length 0
23:15:59.051394 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [.], ack 1, win 3650, options [nop,nop,TS val 726987375 ecr 350774705], length 0
23:16:00.815434 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [P.], seq 1:3, ack 1, win 3650, options [nop,nop,TS val 726987816 ecr 350774705], length 2
23:16:00.815493 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [.], ack 3, win 1810, options [nop,nop,TS val 350775146 ecr 726987816], length 0

root@client:~# tcpdump -i any -nn port 7777
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
23:20:38.159839 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [S], seq 2946797440, win 14600, options [mss 1460,sackOK,TS val 726987371 ecr 0,nop,wscale 2], length 0
23:20:38.174837 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [S.], seq 2303834803, ack 2946797441, win 14480, options [mss 1460,sackOK,TS val 350774705 ecr 726987371,nop,wscale 3], length 0
23:20:38.174880 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [.], ack 1, win 3650, options [nop,nop,TS val 726987375 ecr 350774705], length 0
23:20:39.938895 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [P.], seq 1:3, ack 1, win 3650, options [nop,nop,TS val 726987816 ecr 350774705], length 2
23:20:39.939313 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [.], ack 3, win 1810, options [nop,nop,TS val 350775146 ecr 726987816], length 0

At this point from another terminal on the server we can verify that the connection exists and start the tcpkill to try to kill it.

root@server:~# netstat -tulpan | grep 7777
tcp        0      0 0.0.0.0:7777            0.0.0.0:*               LISTEN      1338/nc
tcp        0      0 5.79.21.166:7777        164.177.146.87:50185    ESTABLISHED 1338/nc
root@server:~# tcpkill -i eth0 -9 port 50185

At this stage nothing is going to happen because neither the client or server sending any data. The tcpkill simply hangs and waits. The open TCP session continue to exists. But as soon as we sent another byte from the client to the server these is being logged on the tcpdump sessions for the tcpkill, client and server.

tcpkill

root@server:~# tcpkill -i eth0 -9 port 50185
tcpkill: listening on eth0 [port 50185]
164.177.146.87:50185 > 5.79.21.166:7777: R 2303834804:2303834804(0) win 0             
164.177.146.87:50185 > 5.79.21.166:7777: R 2303838454:2303838454(0) win 0
164.177.146.87:50185 > 5.79.21.166:7777: R 2303845754:2303845754(0) win 0
164.177.146.87:50185 > 5.79.21.166:7777: R 2303856704:2303856704(0) win 0
164.177.146.87:50185 > 5.79.21.166:7777: R 2303871304:2303871304(0) win 0
164.177.146.87:50185 > 5.79.21.166:7777: R 2303889554:2303889554(0) win 0
164.177.146.87:50185 > 5.79.21.166:7777: R 2303911454:2303911454(0) win 0
164.177.146.87:50185 > 5.79.21.166:7777: R 2303937004:2303937004(0) win 0
164.177.146.87:50185 > 5.79.21.166:7777: R 2303966204:2303966204(0) win 0
5.79.21.166:7777 > 164.177.146.87:50185: R 2946797445:2946797445(0) win 0
5.79.21.166:7777 > 164.177.146.87:50185: R 2946799255:2946799255(0) win 0
5.79.21.166:7777 > 164.177.146.87:50185: R 2946802875:2946802875(0) win 0
5.79.21.166:7777 > 164.177.146.87:50185: R 2946808305:2946808305(0) win 0
5.79.21.166:7777 > 164.177.146.87:50185: R 2946815545:2946815545(0) win 0
5.79.21.166:7777 > 164.177.146.87:50185: R 2946824595:2946824595(0) win 0
5.79.21.166:7777 > 164.177.146.87:50185: R 2946835455:2946835455(0) win 0
5.79.21.166:7777 > 164.177.146.87:50185: R 2946848125:2946848125(0) win 0
5.79.21.166:7777 > 164.177.146.87:50185: R 2946862605:2946862605(0) win 0

client

root@client:~# tcpdump -i any -nn port 7777
...
23:21:03.938535 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [P.], seq 3:5, ack 1, win 3650, options [nop,nop,TS val 726993816 ecr 350775146], length 2
23:21:03.943047 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [.], ack 5, win 1810, options [nop,nop,TS val 350781146 ecr 726993816], length 0
23:21:03.943070 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303834804, win 0, length 0
23:21:03.943082 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303838454, win 0, length 0
23:21:03.943086 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303845754, win 0, length 0
23:21:03.943090 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303856704, win 0, length 0
23:21:03.943093 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303871304, win 0, length 0
23:21:03.943096 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303889554, win 0, length 0
23:21:03.943099 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303911454, win 0, length 0
23:21:03.943102 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303937004, win 0, length 0 
23:21:03.943106 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303966204, win 0, length 0

Server

root@server:~# tcpdump -i any -nn port 7777
...
23:16:24.815402 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [P.], seq 3:5, ack 1, win 3650, options [nop,nop,TS val 726993816 ecr 350775146], length 2
23:16:24.815449 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [.], ack 5, win 1810, options [nop,nop,TS val 350781146 ecr 726993816], length 0
23:16:24.816040 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303834804, win 0, length 0
23:16:24.816080 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303838454, win 0, length 0
23:16:24.816103 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303845754, win 0, length 0
23:16:24.816130 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303856704, win 0, length 0
23:16:24.816153 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303871304, win 0, length 0
23:16:24.816177 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303889554, win 0, length 0
23:16:24.816199 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303911454, win 0, length 0
23:16:24.816225 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303937004, win 0, length 0
23:16:24.816245 IP 5.79.21.166.7777 > 164.177.146.87.50185: Flags [R], seq 2303966204, win 0, length 0
23:16:24.816280 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [R], seq 2946797445, win 0, length 0
23:16:24.816314 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [R], seq 2946799255, win 0, length 0
23:16:24.816339 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [R], seq 2946802875, win 0, length 0
23:16:24.816362 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [R], seq 2946808305, win 0, length 0
23:16:24.816384 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [R], seq 2946815545, win 0, length 0
23:16:24.816407 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [R], seq 2946824595, win 0, length 0
23:16:24.816429 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [R], seq 2946835455, win 0, length 0
23:16:24.816451 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [R], seq 2946848125, win 0, length 0
23:16:24.816474 IP 164.177.146.87.50185 > 5.79.21.166.7777: Flags [R], seq 2946862605, win 0, length 0

We can see that as soon as the new byte generate 2 TCP segment the tcpkill learns about the SEQ and ACK numbers and generate its RST packet to desynchronize and kill the TCP session.

killcx (active)

We start the 2 client and server sessions in a similar way. These are the command output showing what is happening on the wire this time.

server

root@server:~# tcpdump -i any -nn port 7777
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
23:46:06.228566 IP 164.177.146.87.50189 > 5.79.21.166.7777: Flags [S], seq 11257294, win 14600, options [mss 1460,sackOK,TS val 727439173 ecr 0,nop,wscale 2], length 0
23:46:06.228625 IP 5.79.21.166.7777 > 164.177.146.87.50189: Flags [S.], seq 1319656020, ack 11257295, win 14480, options [mss 1460,sackOK,TS val 351226499 ecr 727439173,nop,wscale 3], length 0
23:46:06.233328 IP 164.177.146.87.50189 > 5.79.21.166.7777: Flags [.], ack 1, win 3650, options [nop,nop,TS val 727439174 ecr 351226499], length 0
23:46:07.960259 IP 164.177.146.87.50189 > 5.79.21.166.7777: Flags [P.], seq 1:3, ack 1, win 3650, options [nop,nop,TS val 727439605 ecr 351226499], length 2
23:46:07.960322 IP 5.79.21.166.7777 > 164.177.146.87.50189: Flags [.], ack 3, win 1810, options [nop,nop,TS val 351226932 ecr 727439605], length 0
# at this moment the TCP is estabilished and the server received one byte

# we see this as soon as the killcx is started
23:46:32.411167 IP 164.177.146.87.50189 > 5.79.21.166.7777: Flags [S], seq 10, win 65535, length 0
23:46:32.411194 IP 5.79.21.166.7777 > 164.177.146.87.50189: Flags [.], ack 3, win 1810, options [nop,nop,TS val 351233045 ecr 727439605,nop,nop,sack 1 {4283710012:4283710013}], length 0
23:46:32.413315 IP 164.177.146.87.50189 > 5.79.21.166.7777: Flags [R], seq 11257297, win 65535, length 0
23:46:32.414945 IP 5.79.21.166.7777 > 164.177.146.87.50189: Flags [R], seq 1319656021, win 65535, length 0

client

root@client:~# tcpdump -i any -nn port 7777
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
23:50:45.365610 IP 164.177.146.87.50189 > 5.79.21.166.7777: Flags [S], seq 11257294, win 14600, options [mss 1460,sackOK,TS val 727439173 ecr 0,nop,wscale 2], length 0
23:50:45.370015 IP 5.79.21.166.7777 > 164.177.146.87.50189: Flags [S.], seq 1319656020, ack 11257295, win 14480, options [mss 1460,sackOK,TS val 351226499 ecr 727439173,nop,wscale 3], length 0
23:50:45.370059 IP 164.177.146.87.50189 > 5.79.21.166.7777: Flags [.], ack 1, win 3650, options [nop,nop,TS val 727439174 ecr 351226499], length 0
23:50:47.097391 IP 164.177.146.87.50189 > 5.79.21.166.7777: Flags [P.], seq 1:3, ack 1, win 3650, options [nop,nop,TS val 727439605 ecr 351226499], length 2
23:50:47.098888 IP 5.79.21.166.7777 > 164.177.146.87.50189: Flags [.], ack 3, win 1810, options [nop,nop,TS val 35122693221:20:14439605], length 0
# at this moment the TCP is estabilished and the client sent one byte

# we see this as soon as the killcx is started
23:51:11.550122 IP 5.79.21.166.7777 > 164.177.146.87.50189: Flags [.], ack 3, win 1810, options [nop,nop,TS val 351233045 ecr 727439605,nop,nop,sack 1 {4283710012:4283710013}], length 0
23:51:11.552854 IP 5.79.21.166.7777 > 164.177.146.87.50189: Flags [R], seq 1319656021, win 65535, length 0

killcx

root@server:~# netstat -tulpan | grep 7777
tcp        0      0 0.0.0.0:7777            0.0.0.0:*               LISTEN      10568/nc
tcp        0      0 5.79.21.166:7777        164.177.146.87:50189    ESTABLISHED 10568/nc

root@manage2:~# ./killcx.pl 164.177.146.87:50189
killcx v1.0.3 - (c)2009-2011 Jerome Bruandet - http://killcx.sourceforge.net/

[PARENT] checking connection with [164.177.146.87:50189]
[PARENT] found connection with [5.79.21.166:7777] (ESTABLISHED)
[PARENT] forking child
[CHILD]  interface not defined, will use [eth0]
[CHILD]  setting up filter to sniff ACK on [eth0] for 5 seconds
[PARENT] sending spoofed SYN to [5.79.21.166:7777] with bogus SeqNum
[CHILD]  hooked ACK from [5.79.21.166:7777]
[CHILD]  found AckNum [11257297] and SeqNum [1319656021]
[CHILD]  sending spoofed RST to [5.79.21.166:7777] with SeqNum [11257297]
[CHILD]  sending RST to remote host as well with SeqNum [1319656021]
[CHILD]  all done, sending USR1 signal to parent [10726] and exiting
[PARENT] received child signal, checking results...
         => success : connection has been closed !

As before the TCP session is established and idle waiting. As soon as we start the killcx it successfully spoofs a SYN packet on behalf of the client and sent it to the server. The server than replays with a valid TCP packet revealing the ACK and SEQ numbers. As soon as this this is on a wire the killcx sniffs this up and sent RST to kill the active session.

References

Thursday, October 25, 2012

How to extract a duration of a tcp session from tcpdump file

I took a tcpdump to capture all my application connections to data base server. I can filter the tcpudmp data and extract the session that are relevant by using standard tcpdump filters.

Problem

How to find a duration of a tcp session without manually checking packets and calculating the elapsed time.

Solution

There are many tools that can read and understand a tcpudmp file. One of them is tcptrace. An example of how to use it to find the time is demonstrated below.

root@db1:~# tcptrace -n -l -o1 
1 arg remaining, starting with 'google.pcap'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov  4, 2004

12 packets seen, 12 TCP packets traced
elapsed wallclock time: 0:00:00.001738, 6904 pkts/sec analyzed
trace file elapsed time: 0:00:07.092266
TCP connection info:
1 TCP connection traced:
TCP connection 1:
        host a:        2a00:1a48:7805:0111:8cfc:cf10:ff08:0a2f:55939
        host b:        2a00:1450:400c:0c05::0063:80
        complete conn: yes
        first packet:  Wed Oct 24 22:49:59.166611 2012
        last packet:   Wed Oct 24 22:50:06.258878 2012
        elapsed time:  0:00:07.092266
        total packets: 12
        filename:      google.pcap
   a->b:                              b->a:
     total packets:             6           total packets:             6
     ack pkts sent:             5           ack pkts sent:             6
     ...

References

Thursday, August 16, 2012

How to calculate a number of new SSL/TCP connections per every 10ms

Hardware load balancers like F5 are a graet product that offers a lot of featreus still combined with a simple and intuitive management GUI. The only problem is the price you have to pay to buy it and than further to pay the support and the license fees.

When working with F5 I have run once into an interesting SSL/TLS problem. It is documented and described SOL6475: Overview of SSL TPS licensing limits.

The most important part from the solutions is:

The BIG-IP system measures SSL TPS based on client-side connection attempts to any
virtual server configured with a Client SSL profile. SSL TPS is enforced across a
sliding time window. The BIG-IP system utilizes a 10ms window (1/100 of a second)
to calculate the current TPS. If the number of TPS requests within any 10ms window
exceeds 1/100 of the licensed TPS, an error message regarding the TPS limit being
reached is sent to the /var/log/ltm file.

Problem

How to know what clients IPs cause the error to be logged. How to measure and calculate the number of SSL connection per seconds for even 10ms.

Solution

As there are no tools on F5 that helps you to find this out I thought that a simple way to get some visibility of it would be to capture all TCP SYN packets hitting the LB and then later do some analysis of it. An implementation of this ideas in a form of a python script can be found here [1].

Demonstration

To test sslAnalyze.py script we need first a tcpdump file. For this purpose we can use the nmap command and run a SYN flood. For the desciption of the nmap options you can take a look here [2].

$ nmap -P0 -TNormal -D 1.2.3.4,1.2.3.5,1.2.3.6,1.2.3.7,1.2.3.8,1.2.3.9,1.2.3.10 -iR 10

All what we have to do now is to run on one session a tcpump and on the other the nmap command. As we are only interested in the TCP SYN packets we should tailor the tcpdump filtering syntax properly. A tcpdump that will capture only the SYN packets:

$ tcpdump -vvv -nn -i eth0 -w /var/tmp/syn-flood-example.pcap 'tcp[13]&2!=0 and tcp[13]&16==0'

All what we have to do is not run our script to see the statistics.

I have to quickly explain the script itself. Once run it will prints on stdout a listing of found connections and additionally will create a log file with a name sslConnHigh.txt for only these connections that are over the threshold.

The parameters that you have to specify are:

param1 - tcpdump file (it has to have only SYN packets)
param2 - time fractions in microseconds ( 1000000 microseconds -> 1 second )
param3 - connection threshold per time to log this result to a sslConnHigh.txt file

Examples

# Example 1: to see a  number of connection per 1 second 

$ python sslAnalyze.py  syn-flood-example.pcap 1000000 1

# Example 2: to see a number of connection per every 500ms (half a second)

$ python sslAnalyze.py  syn-flood-example.pcap 500000 1

# Example3: to see a number of connection per every 500ms (half a second) and log only
# these timestamps that have more than 100 connection in a single half a second
# some example output has been attached as well below

$ python sslAnalyze.py  syn-flood-example.pcap 500000 100

keeping the line: reading from file syn-flood-example.pcap, link-type EN10MB (Ethernet)
                     date     timestamp     sumOfConn [... 500000 microsecond periods ... ]
 Tue Aug 14 23:33:30 2012    1344983610       sum:183     0  183 
 Tue Aug 14 23:33:31 2012    1344983611        sum:95     6   89 
 Tue Aug 14 23:33:32 2012    1344983612       sum:614   430  184 
 Tue Aug 14 23:33:33 2012    1344983613       sum:520   216  304

To better understand why F5 logs the error message and what trigger the TPS log error messages we have to run this command:

# 10 milliseconds = 10000 microseconds
$ python sslAnalyze.py  syn-flood-example.pcap 10000 [F5_SSL_total_TPS]
$ cat sslConnHigh.txt

In the output you are going to see the timestamps (rounded to 1 second) where the number of connections in a single 10ms window are above the licensing limit you device has. For further analize you can extract these data from the tcpdump with a help of tcpslice tool.

# 1268649656 is an example timestamp from above
$ tcpslice 1268649656  +1 syn-flood-example.pcap -w 1268649656.pcap

$ tcpdump -tt -nr 1268649656.pcap

reading from file 1268649656.pcap, link-type EN10MB (Ethernet)
1268649656.042723 vlan 4093, p 0, IP 19.26.168.192.4598 - 19.26.225.215.443: S 2973530156:2973530156(0) win 64512 mss 1460,nop,nop,sackOK
1268649656.056163 vlan 4093, p 0, IP 19.89.139.199.1622 - 19.26.225.23.443: S 1522394445:1522394445(0) win 64512 mss 1460,nop,wscale 0,nop,nop,sackOK

References

Saturday, January 7, 2012

Hacking the UDP protocol - how to sent data using the UDP source port of UDP packets

Security has become one of the major concerns in current system architectures. The emerging new cloud technologies like Openstack ( IaaS cloud offering) try to address it in a better way in every new software release. When implementing and integrating bigger infrastructure solution we could say that the difficulty is proportional to the number of technologies that are involved to create a final solution.

One of the most important technology that works as a glue between the components is of course a network infrastructure and the supported protocol stack like TCP/IP that allows application to communicate. As our history of Internet proves a network layer has been since ever a fascination of many hackers. And as we know when it comes to programming and deciding what your program should do the sky is the limit.

As part of my network and security fascination i decided to conduct a small research project to confirm one of my ideas.

Research project description

How to transmit data using the UDP as transport protocols but without relaying on the UDP payload functionality.

Proposed solution description

The ideas is to use the available UDP headers to encode and to encapsulate the the data payload. In my example I decided to use the UDP source port value to store there my payload [1]

The UDP source port is a 16 bit length variable. That means that for a multi byte stream of data to transfer we have to implement effective way to divide it into chunks and sent them separately in many UDP datagrams. On the server site we have to de-encapsulate it and build up the original stream.

Examples and prove of concept (POC)
The client is a simple shell using the hping [2] to sent our specially designed UDP packets.

The server has been written in C to allow it an access to all functions of a network socket. The server has to implement the necessary logic to assemble the original data as well.

The example code can be found on github under the udptx project link [4]

Results presentation

For the below DemoA and DemoB illustrations we are going to use
a) One Debian base Rackspace Cloud Server (RCS) [3].
b) Locally hosted VM (in VMware Workstation) on my PC at home.

On any of the below mentioned machines we work on I assume you have already the necessary programs installed like hping2 (you can use the hping3 as well) and the compiler to compile the server.c code.

This is only an example what you may need to install if you use Debian or Ubuntu base RCS.

debian-leny:~# aptitude install git-core #to check out our source code from github
debian-leny:~# aptitude install gcc
debian-leny:~# uname -a
debian-leny:~# aptitude install linux-headers-2.6.26-2-xen-amd64
debian-leny:~# aptitude install libc6-dev
debian-leny:~# aptitude install hping2

To check out the code and to compile the server code you can do:

debian-leny:~# git clone git://github.com/rtomaszewski/udptx.git
debian-leny:~# cd udptx
debian-leny:~/udptx# gcc -o server server.c

# after a successful compilation the code should look like this
debian-leny:~/udptx# ls -la server
-rwxr-xr-x 1 root root 11862 2012-01-05 22:15 server

debian-leny:~/udptx# ldd server
        linux-vdso.so.1 =>  (0x00007fff6bbff000)
        libc.so.6 => /lib/libc.so.6 (0x00007f95f19c3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f95f1d16000)

DemoA - using the loop back interface on the RCS

Open first SSH session to the RCS server and start the server.

ssh 31.222.171.250
debian-leny:~/udptx# cd udptx
debian-leny:~/udptx# ./server

If the server starts successfully the output will look like this.

debian-leny:~/udptx# ./server
created a UPD socket on port 5555
listening on our UPD socket

On the second SSH session on the RCS server let's run the client. The client requires 2 options: the ip of a host where the data should be sent and a string parameter representing the data we want to sent. In our example we use the loopback address and we try to sent a 3 character string "az;".

ssh  31.222.171.xyz
debian-leny:~/udptx# cd udptx

debian-leny:~/udptx# ./client.sh 127.0.0.1 'az;'
DEBUG: Output interface address: 219.127.0.0
DEBUG: if lo: OK
using lo, addr: 127.0.0.1, MTU: 16436
DEBUG: Trying to open PF_PACKET socket... DEBUG: PF_PACKET, SOCK_RAW open OK
HPING 127.0.0.1 (lo 127.0.0.1): udp mode set, 28 headers + 0 data bytes
45 00 00 1C BC A6 00 00 40 11 00 00 7F 00 00 01 7F 00 00 01 26 19 15 B3 00 08 C6 0F

--- 127.0.0.1 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
DEBUG: Output interface address: 191.127.0.0
DEBUG: if lo: OK
using lo, addr: 127.0.0.1, MTU: 16436
DEBUG: Trying to open PF_PACKET socket... DEBUG: PF_PACKET, SOCK_RAW open OK
HPING 127.0.0.1 (lo 127.0.0.1): udp mode set, 28 headers + 0 data bytes
45 00 00 1C 11 B3 00 00 40 11 00 00 7F 00 00 01 7F 00 00 01 2F DD 15 B3 00 08 BC 4B

--- 127.0.0.1 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
DEBUG: Output interface address: 28.127.0.0
DEBUG: if lo: OK
using lo, addr: 127.0.0.1, MTU: 16436
DEBUG: Trying to open PF_PACKET socket... DEBUG: PF_PACKET, SOCK_RAW open OK
HPING 127.0.0.1 (lo 127.0.0.1): udp mode set, 28 headers + 0 data bytes
45 00 00 1C A9 27 00 00 40 11 00 00 7F 00 00 01 7F 00 00 01 17 41 15 B3 00 08 D4 E7

--- 127.0.0.1 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
DEBUG: Output interface address: 209.127.0.0
DEBUG: if lo: OK
using lo, addr: 127.0.0.1, MTU: 16436
DEBUG: Trying to open PF_PACKET socket... DEBUG: PF_PACKET, SOCK_RAW open OK
HPING 127.0.0.1 (lo 127.0.0.1): udp mode set, 28 headers + 0 data bytes
45 00 00 1C 7F DE 00 00 40 11 00 00 7F 00 00 01 7F 00 00 01 00 35 15 B3 00 08 EB F3

--- 127.0.0.1 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

If the data were sent successfully to the server we should see there the following output.

debian-leny:~/udptx# ./server
created a UPD socket on port 5555
listening on our UPD socket
received from ip: 127.0.0.1 port: hex 0x2619 dec 9753
received from ip: 127.0.0.1 port: hex 0x2fdd dec 12253
received from ip: 127.0.0.1 port: hex 0x1741 dec 5953
received from ip: 127.0.0.1 port: hex 0x35 dec 53
Received 3 characters:
msg[0]=char a hex 0x61 dec 97
msg[1]=char z hex 0x7a dec 122
msg[2]=char ; hex 0x3b dec 59

A tcpdump file with captured session between the client and sever can be found here udptx.lo.pcap.

debian-leny:~/udptx# tcpdump -s0 -nn -i lo -w /tmp/udptx.lo.pcap
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
4 packets captured
8 packets received by filter
0 packets dropped by kernel

DemoB - test over the Internet

The assumptions here are the same as before with the exception that the client is run from a local VM and it connects over the Internet to our Rackspace Cloud Server.

This time the output from the client is a little different than before.

root@ubuntuserver:~/udptx# uname  -a
Linux ubuntuserver 2.6.38-11-server #50-Ubuntu SMP Mon Sep 12 21:34:27 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
root@ubuntuserver:~/udptx# ip addr
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:0c:29:93:ee:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.6/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::20c:29ff:fe93:eeff/64 scope link
       valid_lft forever preferred_lft forever

root@ubuntuserver:~/udptx# ls -la /usr/sbin/hping2
lrwxrwxrwx 1 root root 6 2012-01-05 23:28 /usr/sbin/hping2 -> hping3

root@ubuntuserver:~/udptx# tracepath  31.222.171.250

 1 :  192.168.0.6                                           0.207ms pmtu 1500
 1:  10.95.xyz.xyz                                           10.674ms
 1:  10.95.52.1                                           13.559ms
 2:  80.3.177.253                                         13.320ms
 3:  195.182.179.85                                       14.875ms asymm  5
 4:  212.43.163.117                                       13.964ms
 5:  212.43.162.218                                       12.821ms
 6:  213.105.159.34                                       18.455ms
 7:  62.253.184.2                                         26.880ms
 8:  195.66.224.116                                       15.280ms asymm  7
 9:  92.52.76.246                                         31.758ms asymm  8
10:  92.52.77.107                                         50.107ms asymm  9
11:  31.222.171.250                                       15.384ms reached
     Resume: pmtu 1500 hops 11 back 55

root@ubuntuserver:~/udptx# ./client.sh 31.222.171.250 'az;'
DEBUG: Output interface address: 0.0.0.0
DEBUG: if lo: The address doesn't match
DEBUG: if eth0: OK
using eth0, addr: 192.168.0.6, MTU: 1500
DEBUG: pcap_open_live(eth0, 99999, 0, 1, 0x628220)
DEBUG: dltype is 1
HPING 31.222.171.250 (eth0 31.222.171.250): udp mode set, 28 headers + 0 data bytes
45 00 00 1C 81 DF 00 00 40 11 00 00 C0 A8 00 06 1F DE AB FA 26 19 15 B3 00 08 37 8B
DEBUG: under pcap_recv()
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL

--- 31.222.171.250 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss

round-trip min/avg/max = 0.0/0.0/0.0 ms
DEBUG: Output interface address: 0.0.0.0
DEBUG: if lo: The address doesn't match
DEBUG: if eth0: OK
using eth0, addr: 192.168.0.6, MTU: 1500
DEBUG: pcap_open_live(eth0, 99999, 0, 1, 0x628220)
DEBUG: dltype is 1
HPING 31.222.171.250 (eth0 31.222.171.250): udp mode set, 28 headers + 0 data bytes
45 00 00 1C 1F E2 00 00 40 11 00 00 C0 A8 00 06 1F DE AB FA 2F DD 15 B3 00 08 2D C7 
DEBUG: under pcap_recv()
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL

--- 31.222.171.250 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

DEBUG: Output interface address: 0.0.0.0
DEBUG: if lo: The address doesn't match
DEBUG: if eth0: OK
using eth0, addr: 192.168.0.6, MTU: 1500
DEBUG: pcap_open_live(eth0, 99999, 0, 1, 0x628220)
DEBUG: dltype is 1
HPING 31.222.171.250 (eth0 31.222.171.250): udp mode set, 28 headers + 0 data bytes
45 00 00 1C 9F 7F 00 00 40 11 00 00 C0 A8 00 06 1F DE AB FA 17 41 15 B3 00 08 46 63 
DEBUG: under pcap_recv()
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL

--- 31.222.171.250 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss

round-trip min/avg/max = 0.0/0.0/0.0 ms
DEBUG: Output interface address: 0.0.0.0

DEBUG: if lo: The address doesn't match
DEBUG: if eth0: OK
using eth0, addr: 192.168.0.6, MTU: 1500
DEBUG: pcap_open_live(eth0, 99999, 0, 1, 0x628220)
DEBUG: dltype is 1
HPING 31.222.171.250 (eth0 31.222.171.250): udp mode set, 28 headers + 0 data bytes
45 00 00 1C 8C BC 00 00 40 11 00 00 C0 A8 00 06 1F DE AB FA 00 35 15 B3 00 08 5D 6F 
DEBUG: under pcap_recv()
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL

--- 31.222.171.250 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

The outputs from the server has changed as well.

debian-leny:~/udptx# ./server
created a UPD socket on port 5555
listening on our UPD socket
received from ip: 80.194.5.191 port: hex 0x2619 dec 9753
received from ip: 80.194.5.191 port: hex 0x2fdd dec 12253
received from ip: 80.194.5.191 port: hex 0x1741 dec 5953
received from ip: 80.194.5.191 port: hex 0x35 dec 53
Received 3 characters:
msg[0]=char a hex 0x61 dec 97
msg[1]=char z hex 0x7a dec 122
msg[2]=char ; hex 0x3b dec 59

A new tcpdump file with the captured session between the client and sever can be found here udptx.eth.pcap

debian-leny:~/udptx# tcpdump -s0 -nn -i eth0 -w /tmp/udptx.eth.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
19 packets captured
20 packets received by filter
0 packets dropped by kernel

Summary and further work

The presented code shows that it is possible to sent and receive data without relaying on the UDP payload mechanism. Of course the code is very simple and doesn't implement all the necessary protocol features to make it useful on a bigger scale. To name only a few missing key points that would have to be implemented:
- packet lost
- packet duplication
- packets reordering

To better understand the limitation of our code and learn more about protocol implementation issues it is highly recommend to read at least the official RFC documents about for UDP and TCP protocols [5].

References

[1] http://www.networksorcery.com/enp/protocol/udp.htm
[2] http://www.hping.org/

[3]
http://www.rackspace.com/cloud/cloud_hosting_products/servers/
http://www.rackspace.com/cloud/cloud_hosting_faq/
http://www.rackspace.com/knowledge_center/node/1875

[4] https://github.com/rtomaszewski/udptx
[5] http://www.diigo.com/user/rtomaszewski/rfc

Sunday, April 10, 2011

tshark in network troubleshooting

As described in another of my posts, there is not good and elegant way of printing on stdout and to a file the data captured on the wire when using 'tcpdump'.

In help the 'tshark' that comes with the 'wireshark' packet sniffer comes handy to do the job in a simple and elegant way.

To capture all network packets and to write them to a file you would use a syntax similar to this one:

# tshark -nn -i any -w /tmp/net.pcap
Running as user "root" and group "root". This could be dangerous.
Capturing on Pseudo-device that captures on all interfaces
24

If you don't like the packet counter constantly being updated when tshark runs use the '-q' options like that:

# tshark -nn -i any -w /tmp/net.pcap.pcap -q

And finally when you want to observe the packet in live and in the same time have a raw copy of the network dump on your disk use the '-S' option like that:

# tshark -nn -i any -w /tmp/net.pcap.pcap -S
Running as user "root" and group "root". This could be dangerous.
Capturing on Pseudo-device that captures on all interfaces
  0.000000    127.0.0.1 -> 127.0.0.1    ICMP Echo (ping) request
  0.028908    127.0.0.1 -> 127.0.0.1    ICMP Echo (ping) request
  0.297138 192.168.122.1 -> 192.168.122.255 UDP Source port: 17500  Destination port: 17500
  1.036921    127.0.0.1 -> 127.0.0.1    ICMP Echo (ping) request
  2.045086    127.0.0.1 -> 127.0.0.1    ICMP Echo (ping) request
5 packets captured

After all, when you are done with the troubleshooting and need to convenience someone you can sent him the saved file /tmp/net.pcap for review.

More info
man tshark

Saturday, March 26, 2011

tcpdump wrapper for all network and systems troubleshooter

UPDATE:
This other post describe a more elegant way how to do the job tshark in network troubleshooting

Origin post:

One of the tool that a network engineers relay every day is a network sniffer. One of the most famous I believe is the 'tcpdump'.

Very often when you troubleshoot a problem you run it many time to verify the traffic on the wire. Let say that at some point you see where the problem may be and you need to sent an email with your analyze to another person.

Documenting your results can be very time consuming. To minimize our time and increase the quality of the results we would like to attach the dump files we review ourself of course. Unfortunately it can be a little annoying if we need to repeat our troubleshooting again only to save the dumps on the disk this time. Often sending the analyzed text output form tcpdumps is not enough as well.

This small tcpdump wrapper bellow can save you a lot of time by saving the tcpdump data to file and still letting you to follow the data on the screen in a live troubleshooting.

For couple of examples how to run in please scroll down.

The file with source code can be found here mytcpdump.sh

# you can define the filter and options in your bash variables
# example: 
# T_FILTER='arp or icmp or not ip ( net 10.0.0.0/8 )
# T_OPTIONS='-s0 -nn'

# ------------------------------------------

# arg1 - filter to the wireshark
# arg2 - options to wireshark
mytcpdump () {
 # parse args
 
 DEFAULT_OPT='-s0 -l -nn -w - -i any'
 
 if [ 'x-h' = x"$1" ] ; then 
  echo 
  echo "usage: mytcpdump [arg1] [arg2]"
  echo " arg1 - wireshark network filter, by example: 'arp and (net 10/8)'"
  echo " arg2 - wireshark options, default: '$DEFAULT_OPT'"
  echo ""
  echo " example:"
  echo "   mytcpdump"
  echo "   mytcpdump '(net 10.0.0.0/8 and not net 11.0.0.0/8) and port 22'"
  echo "   mytcpdump '(net 10.0.0.0/8 and not net 11.0.0.0/8) and port 22' '-s0 -l -nn -i eth0 -w -' "
  echo
  
  return 
 fi
 
 # filters
 if [ '1' != 1"$1" ] ; then 
  filter="$1"
 elif [ '2' != 2"$T_FILTER" ]; then
  filter=$T_FILTER
 else
  filter=""
 fi

 # options
 if [ '1' != 1"$2" ] ; then 
  opts="$2"
 elif [ '2' != 2"$T_OPTIONS" ]; then
  opts=$T_OPTIONS
 else
  opts="$DEFAULT_OPT"
 fi 
 
 t=`date +%s`;
 echo "[$t]: timestamp is $t" 
 echo "[$t]: wireshark optoins are <$opts>"
 echo "[$t]: wireshark filter is <$filter>"

 cmd="tcpdump $opts $filter"
 echo "[$t]: tcpdump cmd is <$cmd>"
 
 f="/var/tmp/tcpdump.$t.pcap"
 echo "[$t]: tcpdump pcap file <$f>"
 
 chain="$cmd | tee $f | tcpdump -r- -nn"
 echo "[$t]: running the bash command chains <$chain>" 
 
 $cmd | tee $f | tcpdump -r- -nn
}

alias myt='mytcpdump'

Usage help

# myt -h

usage: mytcpdump [arg1] [arg2]
 arg1 - wireshark network filter, by example: 'arp and (net 10/8)'
 arg2 - wireshark options, default: '-s0 -l -nn -w - -i any'

 example:
   mytcpdump
   mytcpdump '(net 10.0.0.0/8 and not net 11.0.0.0/8) and port 22'
   mytcpdump '(net 10.0.0.0/8 and not net 11.0.0.0/8) and port 22' '-s0 -l -nn -i eth0 -w -'

Examples:

These 2 examples bellow show how to use this small wrapper. Each time we can monitor live traffic on the console output from tcpdump and in the same time be sure that a copy of the raw tcpdump data is written to the disk.

The file you may want to copy then later is shown at the beginning after the header '[timestmap]'. In our examples the file names are:

/var/tmp/tcpdump.1301166859.pcap
/var/tmp/tcpdump.1301166869.pcap

# myt 
[1301166859]: timestamp is 1301166859
[1301166859]: wireshark optoins are <-s0 -l -nn -w - -i any>
[1301166859]: wireshark filter is <>
[1301166859]: tcpdump cmd is <tcpdump -s0 -l -nn -w - -i any >
[1301166859]: tcpdump pcap file </var/tmp/tcpdump.1301166859.pcap>
[1301166859]: running the bash command chains <tcpdump -s0 -l -nn -w - -i any  | tee /var/tmp/tcpdump.1301166859.pcap | tcpdump -r- -nn>
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
reading from file -, link-type LINUX_SLL (Linux cooked)
19:14:19.837101 IP 192.168.43.111 > 212.77.100.101: ICMP echo request, id 42106, seq 5396, length 64
^Ctcpdump: pcap_loop: error reading dump file: Interrupted system call
4 packets captured
6 packets received by filter
0 packets dropped by kernel

# myt 'icmp or arp'
[1301166869]: timestamp is 1301166869
[1301166869]: wireshark optoins are <-s0 -l -nn -w - -i any>
[1301166869]: wireshark filter is <icmp or arp>
[1301166869]: tcpdump cmd is <tcpdump -s0 -l -nn -w - -i any icmp or arp>
[1301166869]: tcpdump pcap file </var/tmp/tcpdump.1301166869.pcap>
[1301166869]: running the bash command chains <tcpdump -s0 -l -nn -w - -i any icmp or arp | tee /var/tmp/tcpdump.1301166869.pcap | tcpdump -r- -nn>
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
reading from file -, link-type LINUX_SLL (Linux cooked)
19:14:29.847649 IP 192.168.43.111 > 212.77.100.101: ICMP echo request, id 42106, seq 5406, length 64
^C2 packets captured
2 packets received by filter
0 packets dropped by kernel
tcpdump: pcap_loop: error reading dump file: Interrupted system call

The Systems Engineer organized chaos

Search This Blog

Sunday, May 5, 2013

How to copy a pcap file from ASA firewall

Sunday, April 28, 2013

How to capture HTTP traffic using tcpdump

Friday, November 9, 2012

How to forcibly kill an established TCP connection in Linux

Thursday, October 25, 2012

How to extract a duration of a tcp session from tcpdump file

Thursday, August 16, 2012

How to calculate a number of new SSL/TCP connections per every 10ms

Saturday, January 7, 2012

Hacking the UDP protocol - how to sent data using the UDP source port of UDP packets

Sunday, April 10, 2011

tshark in network troubleshooting

Saturday, March 26, 2011

tcpdump wrapper for all network and systems troubleshooter

Popular posts last week

Last posts

About Me

Linux enthusiast

My links

Friendly sites

Visitor locations

Total Pageviews

Blog Archive

Labels

Search This Blog

Sunday, May 5, 2013

Sunday, April 28, 2013

Friday, November 9, 2012

Thursday, October 25, 2012

Thursday, August 16, 2012

Saturday, January 7, 2012

Sunday, April 10, 2011

Saturday, March 26, 2011

RSS/Atom feed

Popular posts last week

Last posts

About Me

Linux enthusiast

My links

Friendly sites

Visitor locations

Total Pageviews

Blog Archive

Labels