Support The Ethical Hacker !! - Click Here If You Like My Contents !!!

Showing posts with label header. Show all posts
Showing posts with label header. Show all posts

Wednesday, November 18, 2009

Email Header Finger Printing

When we send an Email, the SMTP server creates a header.Study of the Mail server name reveals the OS of the server. For all this ,we have to analyze the Email Header first. The email header reveals a lot of other sensitive information about the sender including his IP.We will discuss more on this topic on other posts.
Countermeasures :
Change the mail daemon settings 

A sample Email header is shown below :


Delivered-To:XXX @gmail.com
Received: by 10.142.100.4 with SMTP id x4cs39161wfb;
        Tue, 17 Nov 2009 22:37:56 -0800 (PST)
Received: by 10.90.17.29 with SMTP id 29mr1540839agq.79.1258526174775;
        Tue, 17 Nov 2009 22:36:14 -0800 (PST)
Return-Path: 
Received: from mail15-a-ac.linkedin.com (mail15-a-ac.linkedin.com [208.111.169.137])
        by mx.google.com with ESMTP id 30si16545010iwn.121.2009.11.17.22.36.13;
        Tue, 17 Nov 2009 22:36:13 -0800 (PST)
Received-SPF: pass (google.com: domain of s-qKShvR1E_bKJbE3KpcihvgYpqS5pjeiVFRKjniEn-5Sp4jYEI5tJj_@bounce.linkedin.com designates 208.111.169.137 as permitted sender) client-ip=208.111.169.137;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of s-qKShvR1E_bKJbE3KpcihvgYpqS5pjeiVFRKjniEn-5Sp4jYEI5tJj_@bounce.linkedin.com designates 208.111.169.137 as permitted sender) smtp.mail=s-qKShvR1E_bKJbE3KpcihvgYpqS5pjeiVFRKjniEn-5Sp4jYEI5tJj_@bounce.linkedin.com; dkim=pass header.i=communication@linkedin.com
DomainKey-Signature: s=prod; d=linkedin.com; c=nofws; q=dns;
  h=Sender:Date:From:To:Message-ID:Subject:MIME-Version:
   Content-Type:X-LinkedIn-fbl;
  b=LAlAw9S8qrGPLt6phtZNvQ37jeg3yvtYlApfNHApbwizFBIvNvk2D1H6
   r7PxLyDTGK5YmRBn84TgBPD5FB0gt90r9Khp4TnNFIHyM3Sy64uMytmRj
   N4agg6dfvT5H2mO;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=linkedin.com; i=communication@linkedin.com; q=dns/txt;
  s=proddkim; t=1258526173; x=1290062173;
  h=from:sender:reply-to:subject:date:message-id:to:cc:
   mime-version:content-transfer-encoding:content-id:
   content-description:resent-date:resent-from:resent-sender:
   resent-to:resent-cc:resent-message-id:in-reply-to:
   references:list-id:list-help:list-unsubscribe:
   list-subscribe:list-post:list-owner:list-archive;
  z=From:=20LinkedIn=20Communication=20
   in.com>|Sender:=20messages-noreply@bounce.linkedin.com
   |Subject:=20LinkedIn=20Messages,=2011/17/2009|Date:=20Tue
   ,=2017=20Nov=202009=2022:36:03=20-0800=20(PST)
   |Message-ID:=20<2138821644.368566.1258526163419.JavaMail.
   app@ech3-cdn09.prod>|To:=20"Mr.Swaroop=20Krishnan=20S"=20
   |MIME-Version:=201.0;
  bh=HFHniqCRWqBOKiU6PXUVuudYIJ3jsx+QLmyfTd3eFzU=;
  b=SDfsYwsz/HCedRw3aFZ2JkOkKrLzzK2R1gVWv2WDNXhKtr2kM0ioAlZi
   m230bpQm4ZzCi2fwM2yyYbY8GauwKPZav6r23wyGA4hTBwHKLheSmXFI5
   /+urlA2oJGJPlWR;
Sender: messages-noreply@bounce.linkedin.com
Date: Tue, 17 Nov 2009 22:36:03 -0800 (PST)
From: LinkedIn Communication 
To: "Mr.Swaroop Krishnan S" 
Message-ID: <2138821644.368566.1258526163419.JavaMail.app@ech3-cdn09.prod>
Subject: LinkedIn Messages, 11/17/2009
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_368565_1338859.1258526163416"
X-LinkedIn-fbl: qKShvR1E_bKJbE3KpcihvgYpqS5pjeiVFRKjniEn-5Sp4jYEI5tJj_

------=_Part_368565_1338859.1258526163416
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Thursday, November 12, 2009

TCP Header

TCP Header Format

 0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            TCP Header Format

          Note that one tick mark represents one bit position.


Source Port: 16 bits

The source port number.
Destination Port: 16 bits

The destination port number.
Sequence Number: 32 bits

The sequence number of the first data octet in this segment (except
    when SYN is present). If SYN is present the sequence number is the
    initial sequence number (ISN) and the first data octet is ISN+1.
Acknowledgment Number: 32 bits

If the ACK control bit is set this field contains the value of the
    next sequence number the sender of the segment is expecting to
    receive.  Once a connection is established this is always sent.
Data Offset: 4 bits

The number of 32 bit words in the TCP Header.  This indicates where
    the data begins.  The TCP header (even one including options) is an
    integral number of 32 bits long.
Reserved: 6 bits

Reserved for future use.  Must be zero.
Control Bits: 6 bits (from left to right):

URG:  Urgent Pointer field significant
    ACK:  Acknowledgment field significant
    PSH:  Push Function
    RST:  Reset the connection
    SYN:  Synchronize sequence numbers
    FIN:  No more data from sender
Window: 16 bits

The number of data octets beginning with the one indicated in the
    acknowledgment field which the sender of this segment is willing to
    accept.
Checksum: 16 bits

The checksum field is the 16 bit one's complement of the one's
    complement sum of all 16 bit words in the header and text.  If a
    segment contains an odd number of header and text octets to be
    checksummed, the last octet is padded on the right with zeros to
    form a 16 bit word for checksum purposes.  The pad is not
    transmitted as part of the segment.  While computing the checksum,
    the checksum field itself is replaced with zeros.

    The checksum also covers a 96 bit pseudo header conceptually
    prefixed to the TCP header.  This pseudo header contains the Source
    Address, the Destination Address, the Protocol, and TCP length.
    This gives the TCP protection against misrouted segments.  This
    information is carried in the Internet Protocol and is transferred
    across the TCP/Network interface in the arguments or results of
    calls by the TCP on the IP.

                     +--------+--------+--------+--------+
                     |           Source Address          |
                     +--------+--------+--------+--------+
                     |         Destination Address       |
                     +--------+--------+--------+--------+
                     |  zero  |  PTCL  |    TCP Length   |
                     +--------+--------+--------+--------+

      The TCP Length is the TCP header length plus the data length in
      octets (this is not an explicitly transmitted quantity, but is
      computed), and it does not count the 12 octets of the pseudo
      header.
Urgent Pointer: 16 bits

This field communicates the current value of the urgent pointer as a
    positive offset from the sequence number in this segment.  The
    urgent pointer points to the sequence number of the octet following
    the urgent data.  This field is only be interpreted in segments with
    the URG control bit set.
Options: variable

Options may occupy space at the end of the TCP header and are a
    multiple of 8 bits in length.  All options are included in the
    checksum.  An option may begin on any octet boundary.  There are two
    cases for the format of an option:

      Case 1:  A single octet of option-kind.

      Case 2:  An octet of option-kind, an octet of option-length, and
               the actual option-data octets.

    The option-length counts the two octets of option-kind and
    option-length as well as the option-data octets.

    Note that the list of options may be shorter than the data offset
    field might imply.  The content of the header beyond the
    End-of-Option option must be header padding (i.e., zero).

    A TCP must implement all options.
    Currently defined options include (kind indicated in octal):

      Kind     Length    Meaning
      ----     ------    -------
       0         -       End of option list.
       1         -       No-Operation.
       2         4       Maximum Segment Size.
      

    Specific Option Definitions

      End of Option List

        +--------+
        |00000000|
        +--------+
         Kind=0

        This option code indicates the end of the option list.  This
        might not coincide with the end of the TCP header according to
        the Data Offset field.  This is used at the end of all options,
        not the end of each option, and need only be used if the end of
        the options would not otherwise coincide with the end of the TCP
        header.

      No-Operation

        +--------+
        |00000001|
        +--------+
         Kind=1

        This option code may be used between options, for example, to
        align the beginning of a subsequent option on a word boundary.
        There is no guarantee that senders will use this option, so
        receivers must be prepared to process options even if they do
        not begin on a word boundary.

      Maximum Segment Size

        +--------+--------+---------+--------+
        |00000010|00000100|   max seg size   |
        +--------+--------+---------+--------+
         Kind=2   Length=4

        Maximum Segment Size Option Data:  16 bits

          If this option is present, then it communicates the maximum
          receive segment size at the TCP which sends this segment.
          This field must only be sent in the initial connection request
          (i.e., in segments with the SYN control bit set).  If this
          option is not used, any segment size is allowed.
Padding: variable

The TCP header padding is used to ensure that the TCP header ends
    and data begins on a 32 bit boundary.  The padding is composed of
    zeros.
Ref: http://www.freesoft.org/CIE/Course/Section4/8.htm