pen-test
[Top] [All Lists]

RE: First TCP packet

To: <va.pentest@gmail.com>, <pen-test@securityfocus.com>
Subject: RE: First TCP packet
From: "Dario Ciccarone (dciccaro)" <dciccaro@cisco.com>
Date: Sat, 21 Jul 2007 10:10:49 -0400
Authentication-results: rtp-dkim-1; header.From=dciccaro@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Delivered-to: sp-com-lists@consult.net
Delivered-to: pentest-list2@consult.net
Delivered-to: mailing list pen-test@securityfocus.com
Delivered-to: moderator for pen-test@securityfocus.com
Dkim-signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4103; t=1185027051; x=1185891051; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dciccaro@cisco.com; z=From:=20=22Dario=20Ciccarone=20\(dciccaro\)=22=20<dciccaro@cisco.com> |Subject:=20RE=3A=20First=20TCP=20packet |Sender:=20 |To:=20<va.pentest@gmail.com>,=20<pen-test@securityfocus.com>; bh=qv4AZui60it6oxw9jpRswQxNjm7697ZPEcG+kSHwuss=; b=BJ34w7nTglalCLKRP6mwVA4YDXCoOXbGNE7WXdi0J9QbwMhK3vQL5eQTiHleCwoJa7sOSfGn DVUXk7SvD6SQ0m5JUNyrHtbHylG9S1D24ByHnLMojtbFQEKH3xClimS3;
In-reply-to: <20070721071120.9724.qmail@securityfocus.com>
List-help: <mailto:pen-test-help@securityfocus.com>
List-id: <pen-test.list-id.securityfocus.com>
List-post: <mailto:pen-test@securityfocus.com>
List-subscribe: <mailto:pen-test-subscribe@securityfocus.com>
List-unsubscribe: <mailto:pen-test-unsubscribe@securityfocus.com>
Mailing-list: contact pen-test-help@securityfocus.com; run by ezmlm
References: <20070721071120.9724.qmail@securityfocus.com>
Resent-date: Sat, 21 Jul 2007 11:56:25 -0600 (MDT)
Resent-from: pen-test-return-1078484657@securityfocus.com
Resent-message-id: <20070721175625.1601A143DB5@outgoing2.securityfocus.com>
Resent-sender: listbounce@securityfocus.com
Sender: listbounce@securityfocus.com
Thread-index: AcfLaQQ5J2b5l+inTa2ZASS/N2ZdrgANYbew
Thread-topic: First TCP packet
The TCP datagram travels inside an IP packet, which would then be
encapsulated in some kind of L2 frame. Let's start by using the right
names :)

Generically speaking, the only thing that should change in route from A
to B should be the TTL on the IP Header. This assumes both the source
host and destination being directly connected to the Internet (no
firewalls/load balancers/others in the path) and no SP doing
QoS/rewriting headers.

That said, some of the things that might change in route, depending of
the combination of devices between source and destination:

IP Header:

* Version: doesn't change
* IP Header length - might change - if a firewall in the path
drops/removes IP options
* TOS - might change if a device in the path is rewriting it for QoS
purposes
* Total length (affected by (1))
* IPID: never heard of anyone doing IPID randomization - but you could
conceivably do so, and hence it would change
* Flags: can change if an intermediate device has to fragment the
datagram
* Fragment offset: can change if packet has been fragmented
* TTL: would certainly change ;)
* Protocol: doesn't change
* Header checksum: might change if any of the other possible changes
happen. I don't remember (and I'm feeling too lazy right now) which
fields are included into the checksum - check the RFC.
* Source IP address: might change - think NAT
* Destination IP address: might also change. Imagine a server farm
behind a load balancer - one DNS record (www.example.com) might actually
translate to N machines
* Options: as said, might change depending of devices on the path


TCP header:
* Source port: might change if NAT/specially PAT in the path
* Destination port: might be changed at destination - again, load
balancer, firewall
* Sequence number: might change - load balancers, firewalls performing
SEQ number randomization
* ACK number: same as sequence number - both might be doing SEQ number
randomization ;)
* Data offset: might change if firewall/other device adds/drops TCP
options
* Reserved: shouldn't change ;)
* Control bits: shouldn't change, but I can imagine a device setting
PSH. Might change
* Window: might change - host itself might change it, devices in the
path
* Checksum: might change depending on other fields changing
* Urgent pointer: makes sense if URG set - shouldn't change (IMHO :))
* Options: might change depending on devices on the path as we said
before
* padding: again, might change depending on previous
* data: shouldn't change from source/destination point of view - might
change while in transit between end hosts (think transparent
compression)

Almost everything can change. You would at least need a capture from
both ends - but if firewalls/load balancers/transparent compression is
changing stuff in the path, you might not see it (unless you sniff at
the entry and exit interface of each intermediate hop ;))

Good luck.

Dario


> -----Original Message-----
> From: listbounce@securityfocus.com 
> [mailto:listbounce@securityfocus.com] On Behalf Of 
> va.pentest@gmail.com
> Sent: Saturday, July 21, 2007 3:11 AM
> To: pen-test@securityfocus.com
> Subject: First TCP packet
> 
> Hi Friends,
> 
> 
>      Somebody please explain me the following:
> 
> 
> A client and server are seperated by 5 HOPS. When I send a 
> TCP syn packet from client to server,
> 
> What are the parameters that changes in a tcp packet by the 
> time the packet reaches server.
> 
> I just want to know the changes happened to the first packet. 
> 
> 
> How to to test/check this with Wireshark.  
> 
> 
> Thanks
> 
> kpr
> 
> --------------------------------------------------------------
> ----------
> This list is sponsored by: Cenzic
> 
> Need to secure your web apps NOW?
> Cenzic finds more, "real" vulnerabilities fast.
> Click to try it, buy it or download a solution FREE today!
> 
> http://www.cenzic.com/downloads
> --------------------------------------------------------------
> ----------
> 

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!

http://www.cenzic.com/downloads
------------------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>
  • First TCP packet, va . pentest
    • RE: First TCP packet, Dario Ciccarone (dciccaro) <=