Académique Documents
Professionnel Documents
Culture Documents
1. AIM
In the early to mid 1980s, back when the World Wide Web was but a
glimmer in Tim Berners-Lee's1 eye, computer networks experienced a
period of rapid expansion as the seeds of what would evolve into our
modern Internet were sown.
1
One of the inventors of the World Wide Web and president of the World Wide Web Consortium (W3C).
2
A wide area network established by the National Science Foundation that replaced ARPANet.
1
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
Several kludges6 were developed for the 4.3 release as the result
of this research and new features were introduced in order to address
the burgeoning network congestion problems. Eventually 4.3 kludges
were refined and fully implemented, along with other improvements, into
4.4BSD TCP.
3
IMP (Interface Message Processor) - device used to connect to the ARPANet and the original NSFNet - the
IMP was a precursor to today's routers.
4
Berkeley Software Distribution UNIX - 4.3 BSD was released in June 1986; the version implementing the
recommendations in Jacobson & Karels' 1988 paper "Congestion Avoidance and Control" was designated "4.3
BSD Tahoe".
5
Latin -"After the battle comes the rewards".
6
Kludge (pronounced "klooj") - in computing, an elegant patchwork solution that is hastily implemented in
order to address problems in a software or hardware implementation.
7
The terms "segment/TCP segment" and "packet/TCP packet) are often interchangeable within RFCs.
2
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
8
The AX.25 specification is Amateur Radio's implementation of the X.25 data link layer protocol suite.
X.25 is an ITU-T standard protocol suite for WAN networks using the phone or ISDN system as the
networking hardware; it defines the first three layers of the OSI model, though in the case of AX.25, the
network layer is seldom used.
3
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
3. APPLICABLE RFCs9
3.1 RFC 1349 - Type of Service in the Internet Protocol Suite
3.5 RFC 2780 - Allocation Guidelines For Values in IP and Related Headers
9
RFC – “Request for Comments”. RFCs are a series of technical notes about the Internet first implemented
in 1969 in order to propose new Internet standards. An RFC can be submitted to the Internet Engineering
Task Force by anyone; eventually, if it gains enough interest, it may evolve into a genuine Internet
standard. Each RFC is designated by an RFC number; once published, an RFC never changes -
modifications to an original RFC are assigned a new RFC number.
4
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
5
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
The TCP receive window size is the amount of received data (in
bytes) that can be buffered during a connection; the transmitting
endpoint can send only that amount of data before it must wait for an
acknowledgment and window size update from the receiving endpoint.
DBL functions by tracking the queue length for each traffic flow
on a routing device; when the queue length of a flow exceeds its limit,
DBL will either drop packets or set the ECN/CWR bits in the TCP header
in an attempt to prevent network congestion and maintain QoS.
6
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
7
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
ECN is only used when two hosts ECN capable hosts signal that its
mutual use is desired; the use of ECN without proper negotiation could
cause non-ECN capable network equipment to drop traffic in which an ECN
bit has been set.
RFC 791 defined the ToS (Type of Service) octet in the IP header;
originally this was a field that is used for QoS purposes which
consisted of 8 bits, broken into two subfields.
The first two fields of the ToS octet were defined as the
“Precedence” and “Type of Service” (ToS) fields. In this RFC, bits 6 &
7 of the ToS octet were “reserved for future use” and as such were set
to zero:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | ToS | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
RFC 1122 included bits 6 and 7 in the ToS field but it did not
discuss any specific use for those two bits:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | ToS | Undefined |
+-----+-----+-----+-----+-----+-----+-----+-----+
8
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
The IPv4 ToS octet was redefined in RFC with an additional bit
added for future ToS types, with the last bit left undefined and set to
zero:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | ToS | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | |
| PRECEDENCE | D | T | R | 0 | 0 |
| | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
In the ECN field one bit (ECT - ECN Capable Transport) is used to
indicate that an endpoint is ECN capable; the other bit (CE -
Congestion Experienced) is used to indicate network congestion.
9
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DSF | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| Differentiated Services | E | C |
| Code Point (DSCP) | C | E |
| | T | |
+-----+-----+-----+-----+-----+-----+-----+-----+
+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE RFC 2481 RFC 3168
0 0 Not-ECT Not-ECT
0 1 unused ECN capable - ECT(1)
1 0 ECN capable ECN capable - ECT(0)
1 1 CE CE
10
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
A routing device sets the ECT bit only when the packet would have
been dropped in order to indicate congestion (e.g. Tail Drop); should
the level of congestion exceeds a maximum threshold, then the routing
device would drop the packet vice setting the CE bit in order to
protect the network from further congestion.
Endpoint A Endpoint B
IP ECT = 1 IP ECT = 1
IPCE = 0 Congested
IP CE = 1
Router
IP ECT = 1 IP ECT = 1
IP CE = 0 IP CE = 1
Router Router
11
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | U | A | P | R | S | F |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| byte 13 | byte 14 |
+---------------------------------------------------------------+
| byte offset 12 | byte offset 13 |
+---------------------------------------------------------------+
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| byte 13 | byte 14 |
+---------------------------------------------------------------+
| byte offset 12 | byte offset 13 |
+---------------------------------------------------------------+
12
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
0 1
+---------+---------+
| C | E |
| W | C |
| R | E |
+---------+---------+
| byte 14 |
+-------------------+
| byte offset 13 +
+-------------------+
+-----+-----+
| ECN FIELD |
+-----+-----+
CWR ECE
13
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
Endpoint A
SYN
DS = 00
ECN = 11
Endpoint B
SYN/ACK
DS = 00
ECN = 10
Endpoint A
ACK
DS = 01
ECN = 00
Endpoint B
10
Latin - "From Two, One".
11
Puns intended.
14
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
Once the TCP/IP stream has been established between two ECN-
capable endpoints, the TCP and IP ECN bits can be utilized to signal
congestion, perform ECN acknowledgement and reduce the congestion
window size.
TCP/IP PACKET
IP ECT = 1
IP CE = 1
Destination
TCP/IP PACKET – ACK
TCP ECE = 1
TCP CWR = 0
15
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
When the source receives the TCP/IP packet from the destination
with the ECN-Echo flag set, the source reduces its congestion window
size and sets the "congestion window reduced" (CWR) flag of the first
packet transmitted to the destination after the window size is reduced.
Source
TCP/IP PACKET
TCP ECE = 1
TCP CWR = 1
IP Differentiated
Network Congestion Status Services Field TCP ECN Field Bits
ECN Bits
No Congestion 0 1 0 0
No Congestion 1 0 0 0
Congestion 1 1 0 0
Receiving Endpoint Response 1 1 0 1
Transmitting Endpoint Response 1 1 1 1
16
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
17
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | W | E | U | A | P | R | S | F |
| Header Length | Reserved | | | | | | | | |
| | |128|64 |32 |16 | 8 | 4 | 2 | 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| byte 13 | byte 14 |
+---------------------------------------------------------------+
| byte offset 12 | byte offset 13 |
+---------------------------------------------------------------+
18
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | W | E | U | A | P | R | S | F |
| Header Length | Reserved | | | | | | | | |
| | |128|64 |32 |16 | 8 | 4 | 2 | 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| byte 13 | byte 14 |
+---------------------------------------------------------------+
| byte offset 12 | byte offset 13 |
+---------------------------------------------------------------+
194-128=66 (W/CWR)
66-64=2 (E/ECE)
2-2=0 (S/SYN)
Therefore, the SYN (S), CWR (W) and ECE (E) (thus, "SWE") flags
are set in the traffic example demonstrated in figure 16.
tcp[13] = 194
tcpheader byte offset argument
relational operator "equal to"
decimal value of the TCP flags
19
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
10. APPENDICES
20
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
Author: alt.don, Posted: Sun Mar 23, 2003 9:03 pm Post subject:
Bitmask usage 101 - TCPdump bitmasking simplified
----
Bit Masking Simplified
Where this would be of benefit is when for example we are looking over
a large port 80 scan directed against our networks.. The sheer volume
of syn packets plus possible reset packets makes looking over this
tcpdump file a chore. One that could result in missing potentially
critical packets due to analyst fatigue, and or eye strain. With a
proper bit mask in place one can filter many meg’s of traffic and
whittle it down to a very manageable size showing only psh/ack’s for
example.
This will help in looking for specific flag combinations for specific
ip addresses. In essence it you will save you time allowing you to work
more efficiently.
The examples shown below relate only to the tcp header and not icmp,
udp, or others. The same theory applies to all the protocols though.
One just needs to see what byte offset one wants to filter, and then
apply the same concepts described below.
The examples shown below as well are done using tcpdump, hence the
tcpdump style filters.
Code:
-nXvs 0 tcp and host 10.10.10.100 and (tcp[13] & 2 !=0)
b) tcp and host 10.10.10.100 This is where you are specifying that you
want to see the tcp protocol and you are specifying as well the host
address on which you are running this filter against.
21
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
c) and (tcp[13] & 2 !=0) This here is the meat of your bit mask. You
are using and because you are specifying another argument. The ( tells
tcpdump this is the beginning of an argument. The tcp denotes the tcp
protocol, and [13] denotes the byte offset in the tcpheader. The & is a
primitive allowing you to combine arguments. The 2 !=0 denotes the
decimal value in the 13th byte that you want to see. More to follow on
what decimal value equates to what flag in the next subpara. The !=0
means that the bit representing decimal value 2 should be set to 1 ie:
the flag is set vice not being set which would be a binary value of 0.
The ) denotes that this is the end of the argument.
Code:
URG - ACK - PSH - RST - SYN - FYN
32 16 8 4 2 1
With the values set out above for the 13th byte of the tcp header you
can now filter out which ever values you wish. Whether they be
combinations of flags as will be shown below of simply one flag as
shown above.
The below noted example now shows you how to specify several flag in
your bit mask.
Code:
-nXvs 0 tcp and host 192.168.2.100 and ((tcp[13] & 16 !=0) and
(tcp[13] & 8 !=0))
The above noted bit mask filter shows you that the psh and ack flags
for 192.168.2.100 tcp traffic will be pulled for. We have two ((
brackets now because we have added a second argument ie: (tcp[13] & 8
!=0) So due to this we now need a second bracket to close the argument.
You will however get all psh/ack’s associated with 192.168.2.100. This
may be undesirable if this addy has swept an entire subnet for example.
If you want to further refine your search you can specify two specific
hosts with the above mentioned bit mask as evidenced below.
Code:
22
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
Or you can also do the above with specific ports in mind whether they
be source of destination. Please see below.
Code:
-nXvs 0 tcp and host 10.10.10.100 and host 192.168.2.100 and dst
port 80 and ((tcp[13] & 16 !=0) and (tcp[13] & 8 !=0))
Code:
tcpdump -r file_name -nXvs 1514 tcp[13] = 18
Please note that the value of 18 equates to the decimal value of the
flags you want to find. In this case 18 equals both Syn and Ack flags
being set in the 13th byte in the TCP header.
Last edited by alt.don on Sun May 02, 2004 2:26 am; edited 2 times in
total
23
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Yes, I'm aware that some of these offsets are covered by tcpdump
macros. So what? Use the byte offsets instead and let them ph33r your
m@d sk1lz. Corrections, additions and so on are welcome. Send them to:
Cheers,
JQ
IP byte offsets
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
IP versions !=4
(ip[0] & 0xf0 != 0x40)
Broadcasts to x.x.x.255:
(ip[19] = 0xff)
Broadcasts to x.x.x.0
(ip[19] = 0x00)
24
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
ICMP
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
icmp[0] - type
icmp[1] - code
icmp[3:2] - checksum
Destination Unreachable:
Time Exceeded:
25
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
Parameter Problem:
Source Quench:
Redirect Message:
icmp[0] = 0x5 (5)
Echo/Echo Reply:
icmp[0] = 0x0 (0) (echo reply)
icmp[0] = 0x8 (8) (echo request)
icmp[4:2] - identifier
icmp[6:2] - sequence number
icmp[8] - data begins
Timestamp/Timestamp Reply:
icmp[1] - 0
icmp[4:2] - identifier
icmp[6:2] - sequence number
icmp[8:4] - originate timestamp
icmp[12:4] - receive timestamp
icmp[16:4] - transmit timestamp
Information Request/Reply:
26
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
icmp[1] - 0
icmp[4:2] - identifier
icmp[6:2] - sequence number
Sources:
ADDENDUM: This appendix has been reproduced on the our shared network
folder in order to facilitate analysts in the performance of their
duties; the document can be found in the path designated
\working_aides\.
27
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
NOTE: Some of these filters have never been tested in our live network
environment and may require tinkering.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
Broadcasts to x.x.x.255
ip[19] = 0xff
Broadcasts x.x.x.0
ip[19] = 0x00
Exec
dst port 512
Fragments
ip[6:2] & 0x2000 != 0
Fragmentation attack
tcp && ip[6:2]&16383 != 0
28
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
Finger
dst port 79
Gopher
dst port 70
Hostile SNMP
udp port 161 or udp port 162) and not src net x.x
ICMP
icmp and icmp[0] != 8 and icmp[0] != 0
IP options set 1
(ip[0:1] & 0x0f) > 5
IP options set 2
(ip[0] & 0x0f) != 5
29
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
IRC
tcp and port 6667
IRC - TCP port 6667 with ACK flag set and payload starting at byte 12
that does not include the ascii "PING", "PONG", "JOIN", or "QUIT".
(tcp[13] & 0x10 = 1) && (tcp[0:2]=6667 || tcp[2:2]=6667) \
&& (not ip[32:4] = 1346981447 || not ip[32:4] = 1347374663 \
|| not ip[32:4] = 1246710094 || not ip[32:4] = 1364543828)
IMAP
tcp and (tcp[13] & 2 != 0) and (dst port 143)
Kerberos admin
dst port 749t
Land attacks 1
ip[12:4] = ip[16:4]
Land attacks 2
(tcp[0:2] = tcp[2:2]) && (ip[12:4] = ip[16:4])
Loadav
dst port 750
Login
dst port 513
NetBus
tcp and (dst port 12345) or (dst port 12346)
30
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
NFS
ip and udp port 2049
NNTP
tcp and port 119
Null scans 1
tcp[13] = 0
Null scans 2
tcp[13] & 0xff = 0
Portmapper
ip and dst port 111
Pump
dst port 751
Shell
dst port 514
SMB
dst port 139 && tcp[13:1] & 18 = 2
31
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
SNMP
(udp port 161 or udp port 162) and not src net 172.17
Socks
tcp and (tcp[13] & 2 !=0) and dst port 1080)
SYN/FIN scans
tcp[13] = 3
Teardrop attacks 1
ip[6:1] & 0x20 != 0
Teardrop attacks 2
udp && (ip[6:1] & 0x20 != 0)
Telnet
dst port 23
32
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
UUCP
dst port 540
Whois
dst port 43
X11 ports
(tcp[2:2] >= 6000) and (tcp[2:2] < 7000)
*NIX R-utilities
ip and (tcp dst port 512 or tcp dst port 513 or tcp dst port 514)
ADDENDUM: This appendix has been reproduced on the our shared network
folder in order to facilitate analysts in the performance of their
duties; the document can be found in the path designated
\working_aides\.
______________________________________________________________________
33
ANALYST WORKING AIDE September 2006
Eideard "Ted" Mac Daibhidh
Allman, M. & Paxson, V. & Stevens, W. (April 1999). RFC 2581. TCP
Congestion Control. Retrieved August 20, 2005, from ftp://ftp.rfc-
editor.org/in-notes/rfc2581.txt
Alvin, C. & Fisher S. & Hardy, M. & Rodin, J. & Smith, N. & Wheeler
D.A., et al. (July 2005). Wikipedia. Network Congestion Avoidance.
Retrieved August 21, 2005, from http://en.wikipedia.org/wiki/
Explicit_Congestion_Notification
Bubenius, C. & Burnett, C. & Cardwell, N., & Green, P. & Sidwell, R., et
al. (August 2005). Wikipedia. Transmission Control Protocol. Retrieved
August 20, 2005, from http://en.wikipedia.org/wiki/Transmission_Control
_Protocol
Parker, D.D. (alias “alt.don”). (2003, March 23). Security Forums. Bit
Masking Simplified. Posted to http://www.security-forums.com/forum/
viewtopic.php?t=4489
Quinby, J. (Date unkown). Byte-offsets for IP, TCP and ICMP Packets.
Retrieved August 19, 2005, from http://packet.node.to/hacks/byte_
offsets.txt
34