tshark: display filters + reporting using csv

You can do pretty nifty things with tshark. The absolute life saver is thsark's ability to dump to a csv/tsv file using a user specified display filter.

As an example, I'd like to point out some packet retransmission issues to my provider in a nice (manager friendly) spreadsheet.  Here we go:

Manager friendly output:

ip.src	tcp.srcport	ip.dst	tcp.dstport	tcp.flags.syn	tcp.flags.ack	tcp.flags.push	tcp.flags.reset	tcp.analysis.bytes_in_flight	tcp.len
a.b.c.d	8645	e.f.g.h7	9999	1	0	0	0		0
e.f.g.h7	9999	a.b.c.d	8645	1	1	0	0		0
a.b.c.d	8645	e.f.g.h7	9999	0	1	0	0		0
a.b.c.d	8645	e.f.g.h7	9999	0	1	1	0	168	168
e.f.g.h7	9999	a.b.c.d	8645	0	1	0	0		0
e.f.g.h7	9999	a.b.c.d	8645	0	1	1	0	1154	1154
a.b.c.d	8645	e.f.g.h7	9999	0	1	0	0		0
a.b.c.d	8645	e.f.g.h7	9999	0	1	0	0	1448	1448
a.b.c.d	8645	e.f.g.h7	9999	0	1	1	0	1502	54
e.f.g.h7	9999	a.b.c.d	8645	0	1	0	0		0

How do we get there?
1. Identify the fields that you want. A wireshark display filter cheat-sheet is a good place to start. You can home in on the fields that you want by firing up Wireshark and using the expression builder (button right next to the filter input box) then selecting the protocol that you want.

2. Choose your TCP stream.

3. Assemble your command. The one used to display the output above is:

RPKI CRLs

Each engine (rpki instance with a certificate) is expected to maintain an update to date CRL that is generated at regular intervals. The CRL records any keys revoked due to product expiry or security incidences. Each certificate points to it's parent CRL by using the X509v3 CRL Distribution Points attribute (It's the parent that issued a certificate. Consequently, revocation responsibility lies with the parent).
An example CRL is shown below. The important bits:

• Authority Key Identifier and Issuer point to the issuer (certificate in previous article).
• CRL number which is incremented with each issue.
• Last update and next update time constraints.
• Revocation number and date of each certificate identified by a serial number. 

Sample CRL

Decrypting SSL using tshark/wireshark

I was banging my head on the keyboard last week trying to figure out why wireshar/tshark was not decrypting my SSL packets. Turns out that you cannot do this if the key exchange is Diffie-Hellman. You can get around this by telling the server to ignore DH, In apache's case, changing the SSLCipherSuite to something like:

SSLCipherSuite !DH:!DH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

The server hello changes from

Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

to

Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)

Q'apla!

 tshark   -o "ssl.desegment_ssl_records: TRUE" -o "ssl.desegment_ssl_application_data: TRUE" -o "ssl.keys_list:10.0.0.1,443,http,/path/to/server.key.pem" -o "ssl.debug_file: /tmp/wireshark-log" -r /path/to/example.pcap  -V| awk '/^Frame.*/;/Source: 2/;/Secure Socket Layer.*/,/^$/;' |tail -n 40

....

     Version: TLS 1.0 (0x0301)
        Length: 61
        Encrypted Application Data: 6C6423B17A7211C8F8E9E60B5F726D0C7C40B5645B234A36...
    SSL segment data (41 bytes)
[Reassembled SSL Segments (227 bytes): #60(186), #60(41)]
    [Frame: 60, payload: 0-185 (186 bytes)]
    [Frame: 60, payload: 186-226 (41 bytes)]
Hypertext Transfer Protocol
    HTTP/1.1 200 Script output follows\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 Script output follows\r\n]
            [Message: HTTP/1.1 200 Script output follows\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Version: HTTP/1.1
        Response Code: 200
    Date: Mon, 16 May 2011 13:41:11 GMT\r\n
    Server: Apache/2.2.8 (CentOS)\r\n
    Content-Length: 41\r\n
        [Content length: 41]
    Connection: close\r\n
    Content-Type: application/mercurial-0.1\r\n
    \r\n
Media Type
    Media Type: application/mercurial-0.1 (41 bytes)

Libvirt utilities over TLS

If you are running libvirt on a different host and you don't trust the devices in your network path, you should use TLS. You can of course use ssh :). To use TLS/SSL with libvirt, you should have:

• Access to CA henceforth known as 'the CA'.
• Server key, server cert signed by the CA.
• Client key, client cert signed by the CA.

If you don't have a CA, it's easy to generate one using openSSL or better use certtool (man 1 certtool) from gnutls binaries.

Once you have a CA, have a look at the libvirtd help on your server.

xen02:~/pki# libvirtd -h

libvirtd: invalid option -- 'h'

Usage:

libvirtd [options]

Options:

-v | --verbose Verbose messages.

-d | --daemon Run as a daemon & write PID file.

-l | --listen Listen for TCP/IP connections.

-t | --timeout Exit after timeout period.

-f | --config Configuration file.

| --version Display version information.

-p | --pid-file Change name of PID file.

.......

TLS:

CA certificate: /etc/pki/CA/cacert.pem

Server certificate: /etc/pki/libvirt/servercert.pem

Server private key: /etc/pki/libvirt/private/serverkey.pem

.......

From the output above, it's evident that you will need to copy the CA's certificate to /etc/pki/CA/cacert.pem, generate a server key, a server CSR then get the CSR to the CA. The CA will then provision you with a server cert which you can place in the appropriate path.

You will need to enable TLS in /etc/libvirt/libvirtd.conf

listen_tls = 1

You will probably want to enable TLS authentication for VNC as well as listening on interfaces other than localhost:

vnc_listen = "0.0.0.0"

vnc_tls = 1

#Read the documentation for this

vnc_tls_x509_cert_dir = "/etc/pki/libvirt-vnc"

vnc_tls_x509_verify = 1

Here's my PKI directory

PKI directory listing

$ find /etc/pki/

/etc/pki/

/etc/pki/libvirt-vnc

/etc/pki/libvirt-vnc/ca-cert.pem

/etc/pki/libvirt-vnc/server-key.pem

/etc/pki/libvirt-vnc/server-cert.pem

/etc/pki/libvirt

/etc/pki/libvirt/servercert.pem

/etc/pki/libvirt/private

/etc/pki/libvirt/private/serverkey.pem

/etc/pki/CA

/etc/pki/CA/cacert.pem

To make life easier, You can make VNC and libvirt to share the same keys and certs.

Restart the libvirt service

/etc/init.d/libvirt-bin restart

The client requires a similar PKI setup. The same CA should sign the server and client certs.

$ find /etc/pki/

/etc/pki/

/etc/pki/CA

/etc/pki/CA/cacert.pem

/etc/pki/libvirt

/etc/pki/libvirt/private

/etc/pki/libvirt/private/clientkey.pem

/etc/pki/libvirt/clientcert.pem

Add a connection from your virt-manager that utilizes TLS or use the virsh tools:

virt-viewer -c qemu+tls://xen02.example.net/system box2

virsh -c qemu+tls://xen02.example.net/system list

Id Name State

----------------------------------

7 box1 running

10 box2 running

11 box3 running

13 box4 running

14 box5 running

15 box6 running

16 box7 running

OpenSSL compatible encryption

I wanted to have a Perl program that encrypted a file using perl's Crypt::CBC and be able to decrypt it using the OpenSSL enc application. It took me awhile to figure this one out.

my $cipher = Crypt::CBC->new(
-key => "123",
-cipher => 'Blowfish',
-keysize => 128/8,
-header => 'salt'
);

This works with

openssl enc -bf-cbc -d -in /tmp/staging/passwd.gz.enc -out ah -pass pass:123

The same applies for other ciphers e.g

my $cipher = Crypt::CBC->new(
-key => "123",
-cipher => 'Rijndael',
-keysize => 128/8,
-header => 'salt'
);

This works with

openssl enc -aes-128-cbc -d -in /tmp/staging/passwd.gz.enc -out ah -pass pass:123

Inspiration from stackoverflow