DHCP: No IP, to IP!

DHCP stands for Dynamic Host Configuration Protocol, used to assign an IP address to a machine connected to a network. DHCP uses ports 67 and 68 on top of UDP.

In this post we will see how a machine gets an IP Address.

Figure DHCP Client Communication Sequence

    Source     Dest        Source     Dest              Packet
   MAC addr   MAC addr    IP addr    IP addr           Description
   -----------------------------------------------------------------
   Client     Broadcast   0.0.0.0    255.255.255.255   DHCP Discover
   DHCPsrvr   Broadcast   DHCPsrvr   255.255.255.255   DHCP Offer
   Client     Broadcast   0.0.0.0    255.255.255.255   DHCP Request
   DHCPsrvr   Broadcast   DHCPsrvr   255.255.255.255   DHCP ACK

Source (Microsoft)

Broadcast MAC Address is ff:ff:ff:ff:ff:ff

Below 4 packets (Packet number 2 to 5) are mainly used for fetching an IP. Lets get into packet level details of communication.

Machine which is connected to the network sends a broadcast packet using 255.255.255.255 as destination address which is an IP Address lease request will be responded back by the DHCP Server as DHCP Offer message. A DHCP client migh also send it's previous IP Address part of the discover packet.

Figure DHCP Discover

DHCP server takes a non assigned IP address from the address pool and makes a lease offer to client.

Figure DHCP Offer

Figure DHCP Request

Figure DHCP ACK

In the above communication, we need to mainly observer the source and destination MAC addresses used.

Point to remember, bootp is the wireshark filter, not dhcp.

http://support.microsoft.com/KB/169289

DNS PTR Record Query/Response

DNS PTR Record Query

DNS PTR Record Response

DNS CNAME Record Query/Response

DNS CNAME Query

DNS CNAME Response

DNS A Record Query/Response

A Record Query for www.google.co.in

A Record Response for www.google.co.in

A Record Query for domain www.google.com

A Record Response for domain www.google.com

OpenFlow 1.3 Protocol Packet Structure: OFPT_HELLO

OpenFlow protocol is used for communication between ODL Controller and Switches supporting OpenFlow (OVSK, CPqD, Cisco Switches(N3K, Cat3K etc.), Brocade, HP, Juniper etc.). Each OpenFlow message begins with OpenFlow header which has Version(0x04, 1 byte), Type(1 byte), length(2 bytes), transaction ID (4 bytes). In OF1.3 we have 30 different types of Messages which start with OFPT_

192.168.56.103        Controller
192.168.56.104        Mininet (OVSK)
192.168.56.102         Mininet (CPqD)

If Protocol field is seen as TCP instead of OpenFlow, right click on the packet of interest -> Decode As -> Transport tab -> select Openflow -> OK

Following are different messages as per OF v1.3.2
1) OFPT_HELLO     /* Symmetric message */
2) OFPT_ERROR     /* Symmetric message */
3) OFPT_ECHO_REQUEST     /* Symmetric message */
4) OFPT_ECHO_REPLY /* Symmetric message */
5) OFPT_EXPERIMENTER    /* Symmetric message */
6) OFPT_FEATURES_REQUEST /* Controller/switch message */
7) OFPT_FEATURES_REPLY /* Controller/switch message */
8) OFPT_GET_CONFIG_REQUEST /* Controller/switch message */
9) OFPT_GET_CONFIG_REPLY /* Controller/switch message */
10) OFPT_SET_CONFIG /* Controller/switch message */
11) OFPT_PACKET_IN /* Async message */
12) OFPT_FLOW_REMOVED /* Async message */
13) OFPT_PORT_STATUS /* Async message */
14) OFPT_PACKET_OUT /* Controller/switch message */
15) OFPT_FLOW_MOD /* Controller/switch message */
16) OFPT_GROUP_MOD /* Controller/switch message */
17) OFPT_PORT_MOD /* Controller/switch message */
18) OFPT_TABLE_MOD /* Controller/switch message */
19) OFPT_MULTIPART_REQUEST /* Controller/switch message */
20) OFPT_MULTIPART_REPLY /* Controller/switch message */
21) OFPT_BARRIER_REQUEST /* Controller/switch message */
22) OFPT_BARRIER_REPLY /* Controller/switch message */
23) OFPT_QUEUE_GET_CONFIG_REQUEST /* Controller/switch message */
24) OFPT_QUEUE_GET_CONFIG_REPLY /* Controller/switch message */
25) OFPT_ROLE_REQUEST /* Controller/switch message */
26) OFPT_ROLE_REPLY /* Controller/switch message */
27) OFPT_GET_ASYNC_REQUEST /* Controller/switch message */
28) OFPT_GET_ASYNC_REPLY /* Controller/switch message */
29) OFPT_SET_ASYNC /* Controller/switch message */
30) OFPT_METER_MOD /* Controller/switch message */
Writing Flow entries to Switches Programmaticallyhttp://blog.disects.com/2014/04/opendayligtht-odl-controller-write-flow.html

VoIP STUN Request/Response Packet Structure

STUN stands for Session Traversal Utilities for NAT mainly used in NAT Traversal for IP Applications (say Voice, Video, Messaging).

Below snapshot shows STUN Request Packet

Below snapshot shows STUN Response Packet 

Text view of full capture
Request
No.     Time        Source                Destination           Protocol Length Info
    264 200.289545  10.0.0.2              77.72.169.158         CLASSIC-STUN 62     Message: Binding Request

Frame 264: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
    Arrival Time: Aug 23, 2012 16:36:32.609220000 India Standard Time
    Epoch Time: 1345719992.609220000 seconds
    [Time delta from previous captured frame: 7.022449000 seconds]
    [Time delta from previous displayed frame: 15.027355000 seconds]
    [Time since reference or first frame: 200.289545000 seconds]
    Frame Number: 264
    Frame Length: 62 bytes (496 bits)
    Capture Length: 62 bytes (496 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:udp:classicstun]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: Vmware_ef:18:30 (00:0c:29:ef:18:30), Dst: (00:bb:f7:00:8b:1f)
    Destination: (00:bb:f7:00:8b:1f)
        Address: (00:bb:f7:00:8b:1f)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Vmware_ef:18:30 (00:0c:29:ef:18:30)
        Address: Vmware_ef:18:30 (00:0c:29:ef:18:30)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 10.0.0.2 (10.0.0.2), Dst: 77.72.169.158 (77.72.169.158)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 48
    Identification: 0x3eea (16106)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0xfaea [correct]
        [Good: True]
        [Bad: False]
    Source: 10.0.0.2 (10.0.0.2)
    Destination: 77.72.169.158 (77.72.169.158)
User Datagram Protocol, Src Port: 8006 (8006), Dst Port: stun (3478)
    Source port: 8006 (8006)
    Destination port: stun (3478)
    Length: 28
    Checksum: 0x1f88 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Simple Traversal of UDP Through NAT
    [Response In: 265]
    Message Type: Binding Request (0x0001)
    Message Length: 0x0000
    Message Transaction ID: 000000007e5634120000000000000000


Response
No.     Time        Source                Destination           Protocol Length Info
    265 200.465322  77.72.169.158         10.0.0.2              CLASSIC-STUN 98     Message: Binding Response

Frame 265: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
    Arrival Time: Aug 23, 2012 16:36:32.784997000 India Standard Time
    Epoch Time: 1345719992.784997000 seconds
    [Time delta from previous captured frame: 0.175777000 seconds]
    [Time delta from previous displayed frame: 0.175777000 seconds]
    [Time since reference or first frame: 200.465322000 seconds]
    Frame Number: 265
    Frame Length: 98 bytes (784 bits)
    Capture Length: 98 bytes (784 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:udp:classicstun]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: (00:bb:f7:00:8b:1f), Dst: Vmware_ef:18:30 (00:0c:29:ef:18:30)
    Destination: Vmware_ef:18:30 (00:0c:29:ef:18:30)
        Address: Vmware_ef:18:30 (00:0c:29:ef:18:30)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: (00:bb:f7:00:8b:1f)
        Address: (00:bb:f7:00:8b:1f)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 77.72.169.158 (77.72.169.158), Dst: 10.0.0.2 (10.0.0.2)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 84
    Identification: 0x19c5 (6597)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 238
    Protocol: UDP (17)
    Header checksum: 0x71eb [correct]
        [Good: True]
        [Bad: False]
    Source: 77.72.169.158 (77.72.169.158)
    Destination: 10.0.0.2 (10.0.0.2)
User Datagram Protocol, Src Port: stun (3478), Dst Port: 8006 (8006)
    Source port: stun (3478)
    Destination port: 8006 (8006)
    Length: 64
    Checksum: 0xac24 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Simple Traversal of UDP Through NAT
    [Request In: 264]
    [Time: 0.175777000 seconds]
    Message Type: Binding Response (0x0101)
    Message Length: 0x0024
    Message Transaction ID: 000000007e5634120000000000000000
    Attributes
        Attribute: MAPPED-ADDRESS
            Attribute Type: MAPPED-ADDRESS (0x0001)
            Attribute Length: 8
            Protocol Family: IPv4 (0x0001)
            Port: 8006
            IP: 61.12.12.132 (61.12.12.132)
        Attribute: SOURCE-ADDRESS
            Attribute Type: SOURCE-ADDRESS (0x0004)
            Attribute Length: 8
            Protocol Family: IPv4 (0x0001)
            Port: 3478
            IP: 77.72.169.158 (77.72.169.158)
        Attribute: CHANGED-ADDRESS
            Attribute Type: CHANGED-ADDRESS (0x0005)
            Attribute Length: 8
            Protocol Family: IPv4 (0x0001)
            Port: 3479
            IP: 77.72.169.159 (77.72.169.159)

Other articles of your interest might be
http://darshanams.blogspot.in/2012/06/sip-security1-scanning-voippbx-servers.html
http://darshanams.blogspot.in/2008/11/deciphering-google-talk-jabber.html
http://darshanams.blogspot.in/2009/03/i-was-just-checking-my-mails.html

Bittorrent: Detection Mechanisms

Bittorrent is a Peer to Peer(P2P) protocol used to share files and data in internet. In this article we are going to see what are the different mechanisms which can be used to detect and block Bittorrent communication across network.

Below snapshot shows HTTP request which Bittorrent Client uses to communicate with Bittorrent Servers. In the request we can see different parameters like client id, port number.

We can observe that Bittorrent client uses different User Agent request headers like BTWebClient, Bittorrent etc.

UDP is using Source port as 24615, which is being communicated to Bittorrent Server as HTTP Request.

So we can detect or block Bittorrent based on HTTP Request URI or User-Agent header strings or UDP protocol communication.

Below are few Signatures which we can use to detect Bittorrent.

alert udp any any -> any any ( msg: "Bit Torrent UDP"; content:"41 02"; offset:0; depth:2; content:"38"; offset:13;depth:1; content:"08"; offset:21;depth:1; sid:8888881; rev: 1; )
alert udp any any -> any any ( msg: "Bit Torrent Protocol"; content:"|13|bittorrent|20|protocol";  offset:0; sid:8888882; rev: 1; )
alert udp any any -> any any ( msg: "Bit Torrent UDP Communication"; content:"d1|3a|ad2|3a|id20|3a|"; sid:8888883; rev: 1; )  
 

Below Signature triggers and alerts when the content is seen in HTTP Request URI
alert tcp any any -> any 80 ( msg: "Bit Torrent: HTTP Request"; content:"info_hash=";  pcre:"/announce\?info_hash=/Ui"; sid:8888884; rev: 1; )


Observed following User-Agent strings as part of HTTP Requests
        User-Agent: BitTorrent/7610(27328)
        User-Agent: BTWebClient/7610(27328)
which can be detected using following Signatures
alert tcp any any -> any 80 ( msg: "Bit Torrent: HTTP User Agent 1"; content:"User-Agent: BitTorrent";  sid:8888885; rev: 1; ) 
alert tcp any any -> any 80 ( msg: "Bit Torrent: HTTP User Agent 2"; content:"User-Agent: BTWebClient";  sid:8888886; rev: 1; ) 

Posts related to Snort IDS/IPS which might be of interest to you.
http://darshanams.blogspot.in/2011/05/snort-logging-alerts-to-syslog-server.html
http://darshanams.blogspot.in/2010/06/snort-preprocessors-and-alerts.html
http://darshanams.blogspot.in/2012/05/installing-snort-from-source-as-ips.html

To know about Google Talk Jabber protocol communication
http://darshanams.blogspot.in/2008/11/deciphering-google-talk-jabber.html

For Zebra/Bittorrent protocol communication
http://darshanams.blogspot.in/2009/03/i-was-just-checking-my-mails.html

P.S Signatures given above are neither tested nor fine tuned. Just an 
idea how to detect Bit Torrent communication.

Server Message Block (SMB) Protocol Dissection

Primary goal of SMB is File Transfer within LAN.

SMB Header Structure:
SMB_Header
{
UCHAR Protocol[4];
UCHAR Command;
SMB_ERROR Status;
UCHAR Flags;
USHORT Flags2;
USHORT PIDHigh;
UCHAR SecurityFeatures[8];
USHORT Reserved;
USHORT TID;
USHORT PIDLow;
USHORT UID;
USHORT MID;
}

SMB Parameter Block:
SMB_Parameters
{
UCHAR WordCount;
USHORT Words[WordCount] (variable);
}

SMB Data Block:
SMB_Data
{
USHORT ByteCount;
UCHAR Bytes[ByteCount] (variable);
}

For further details
http://msdn.microsoft.com/en-us/library/ee441466%28v=PROT.13%29.aspx
http://www.hsc.fr/ressources/articles/win_net_srv/

ZEBRA Protocol and BitTorrent !

I was just checking my mails. Got bored, started Wireshark!!!

To my surprise I saw packets with Zebra Protocol over TCP port 27756.


I didn't understand which application is using this protocol. I googled for the same which said that Zebra is a routing protocol, I was not convinced with the result.

I further analyzed the Packet Capture and used netstat, Task Manager etc. from which I came to know that BitTorrent is using Zebra Protocol. One more thing to add, BitTorrent also uses "BitTorrent" Protocol for communication over TCP.


Further analysis of the PCAP and googling gave information like Zebra is a streaming protocol for P2P communication.

To know about Google Talk Jabber protocol communication with wireshark captures follow below link
http://darshanams.blogspot.in/2008/11/deciphering-google-talk-jabber.html

For Bittorrent detection signatures
http://darshanams.blogspot.in/2012/07/bittorrent-useragents-and-detection.html

Deciphering Google Talk's Jabber Communication

Google Talk communicates through HTTPS (TCP Port 443) and Jabber (TCP Port 5222) Protocols. Google talk initially communicates through HTTPS and switches to Jabber. When 5222 is blocked using firewall Google Talk works on port 443 (HTTPS). Suppose HTTPS, port 443 is blocked and port 5222 is allowed in this case Google Talk doesn't work.

When the communication is through TCP Port 5222 for Google Talk we can see Octal (OCT) pattern in the pay load. We can see Description and Hex pattern in the payload of HTTPS communication.

Below payload is seen in “Client Hello” packet which is sent after three way handshake on port 443 and three way handshake on port 5222 if both the ports are allowed. This is the mapping between Octal and Hex Patterns.

Oct/Jabber Hex/HTTPS Description
--------------- --------------- -------------------------------------
\200L 804c Length: 76
\001 01 Handshake Message Type: Client Hello (1)
\003\001 0301 Version: TLS 1.0 (0x0301)
\0003 0033 Cipher Spec Length: 51
\000\000 0000 Session ID Length: 0
\000\020 0010 Challenge Length: 16
\000\000\004 000004 Cipher Specs: TLS_RSA_WITH_RC4_128_MD5 (0x000004)
\000\000\005 000005 Cipher Specs: TLS_RSA_WITH_RC4_128_SHA (0x000005)
\000\000\n 00000a Cipher Specs: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a)
\001\000\200 010080 Cipher Specs: SSL2_RC4_128_WITH_MD5 (0x010080)
\a\000\300 0700c0 Cipher Specs: SSL2_ DES_192_ EDE3_CBC_WITH_MD5 (0x0700c0)
\003\000\200 030080 Cipher Specs: SSL2_RC2_CBC_128_CBC_WITH _MD5 (0x030080)
\000\000\t 000009 Cipher Specs: TLS_RSA_WITH_DES_CBC_SHA (0x000009)
\006\000@ 060040 Cipher Specs: SSL2_DES_64_CBC_WITH _MD5 (0x060040)
\000\000d 000064 Cipher Specs: TLS_RSA_WITH_RC4_128_MD5 (0x000064)
\000\000b 000062 Cipher Specs: TLS_RSA_ EXPORT1024_WITH_DES_CBC_SHA (0x000062)
\000\000\003 000003 Cipher Specs: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x000003)
\000\000\006 000006 Cipher Specs: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x000006)
\002\000\200 020080 Cipher Specs: SSL2_RC4_128_ EXPORT40_WITH_MD5 (0x020080)
\004\000\200 040080 Cipher Specs: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080)
\000\000\023 000013 Cipher Specs: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x000013)
\000\000\022 000012 Cipher Specs: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x000012)
\000\000c 000063 Cipher Specs: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x000063)
e72b7909ff36880aa266262537c83988 Challenge

Google Talk communication through gmail uses "User Agent: Google Talk\r\n" which can be seen through Ethereal/Wireshark capture.

For Bittorrent detection signatures
http://darshanams.blogspot.in/2012/07/bittorrent-useragents-and-detection.html 

For Zebra protocol
http://darshanams.blogspot.in/2009/03/i-was-just-checking-my-mails.html