TCP/IP Miscs

TCP/IP Miscs

What is this flags(In packet): URG, ACK, PSH, RST, SYN, FIN?
# CWR - Congestion Window Reduced
# ECE - Explicit Congestion Notification echo
# URG - Urgent
# ACK - Acknowledgement
# PSH - Push
# RST - Reset
# SYN - Synchronize
# FIN - Finished
A TCP connection is managed by an operating system through a programming interface that represents the local end-point for communications, the Internet socket. During the lifetime of a TCP connection it undergoes a series of state changes:
1. LISTEN : In case of a server, waiting for a connection request from any remote client.
2. SYN-SENT : waiting for the remote peer to send back a TCP segment with the SYN and ACK flags set. (usually set by TCP clients)
3. SYN-RECEIVED : waiting for the remote peer to send back an acknowledgment after having sent back a connection acknowledgment to the remote peer. (usually set by TCP servers)
4. ESTABLISHED : the port is ready to receive/send data from/to the remote peer.
10. TIME-WAIT : represents waiting for enough time to pass to be sure the remote peer received the acknowledgment of its connection termination request. According to RFC 793 a connection can stay in TIME-WAIT for a maximum of four minutes.

Three-way Connection Establishment Handshake

A (virtual) connection is established via what is commonly known as a three-way handshake.
To establish a TCP connection:
1. (B) --> [SYN] --> (A)
The requesting end (normally called the client) sends a SYN segment specifying the port number of the server that
the client wants to connect to, and the client's initial sequence number.
Note: A SYN packet is a TCP packet with the SYN flag set only (see TCP header diagram in Resources). It's important to note that unless a SYN packet is received by A from B, there is no way to establish a TCP connection. Therefore, if your firewall drops all SYN packets to your internal network (and to itself), there is no way for anyone to establish a TCP connection to you.
2. (B) <-- [SYN/ACK] <--(A)
The server responds with its own SYN segment containing the server's initial sequence number. The
server also acknowledges the client's SYN by ACKing the client's ISN plus one. A SYN consumes one sequence
Note: A SYN/ACK packet is a TCP packet with the SYN and ACK flag set and no other TCP flags.
3. (B) --> [ACK] --> (A)
When the (B) receives the SYN/ACK packet from (A), The client completes the final part of the three-way handshake, returns acknowledge this SYN from the server by ACKing the server's ISN plus one.
Note: An ACK packet is a TCP packet with the ACK flag set only. The important thing to note here is that after the three-way handshake is completed, and the connection is complete, every packet that is part of this TCP connection will always have the ACK bit set.
This is also the reason why connection tracking is so important. Without connection tracking, there is no way for your firewall to know whether an arriving ACK packet is really a part of an established connection. When simple packet filters (and Ipchains) receives a packet with the ACK flag set, it simply allows the packet through (does this sound like a good idea?). When a stateful firewall received an ACK packet, it'll consult a connection table to see if the packet belongs to an established connection. If it does not, the packet is dropped.
Four-way Connection Termination Handshake
What goes up, must come down. A four-way handshake tears down a previously established TCP connection. Again, using the same scheme as above:
1. (B) --> ACK/FIN --> (A)
2. (B) <-- ACK <-- (A)
3. (B) <-- ACK/FIN <-- (A)
4. (B) --> ACK --> (A)
Note: Since a TCP connection is a two way connection, it needs to be torn down in both directions. An ACK/FIN packet (ACK and FIN flags set) is sometimes referred to as a FIN (Finish) packet . However, since the connection is not yet torn down, it is always accompanied by the ACK flag. A packet with only the FIN flag set is NOT legal and is likely maliciously generated.
Resetting a connection
The four-way handshake is not the only way to tear down an established TCP connection. Sometimes, if either hosts need to tear down the connection quickly (timeout, port or host unreachable, etc.), a RST (Reset) packet is sent. Note that since a RST packet is not necessarily always part of a TCP connection, it can be sent by itself. RST packets that are part of a TCP connection is usually accompanied by the ACK flag as well.
Note that RST packets are not acknowledged.
Normal TCP Flag combination
* SYN, SYN ACK, and ACK are used during the three-way handshake which establishes a TCP connection.
* Except for the initial SYN packet, every packet in a connection must have the ACK bit set.
* FIN ACK and ACK are used during the graceful teardown of an existing connection.
* RST ACK can be used to immediately terminate an existing connection.
* Packets during the "conversation" portion of the connection (after the three-way handshake but before the teardown or termination) contain just an ACK by default.
* Optionally, they may also contain PSH and/or URG.
Abnormal TCP Flag combination
* SYN FIN is probably the best known illegal combination. Remember that SYN is used to start a connection, while FIN is used to end an existing connection. It is nonsensical to perform both actions at the same time. Many scanning tools use SYN FIN packets, because many intrusion detection systems did not catch these in the past, although most do so now. You can safely assume that any SYN FIN packets you see are malicious.
* SYN FIN PSH, SYN FIN RST, SYN FIN RST PSH, and other variants on SYN FIN also exist. These packets may be used by attackers who are aware that intrusion detection systems may be looking for packets with just the SYN and FIN bits set, not additional bits set. Again, these are clearly malicious.
* Packets should never contain just a FIN flag. FIN packets are frequently used for port scans, network mapping and other stealth activities.
* Some packets have absolutely no flags set at all; these are referred to as "null" packets. It is illegal to have a packet with no flags set.
What is a FIN_WAIT_1, FIN_WAIT_2 state?
FIN_WAIT_2 seems to occur when the server has an active connection with a client and it wants to shut down the TCP connection (probably in response to a normal application layer "exit"). The server sends the client a packet with a "FIN" bit set. At this point, the server is in FIN_WAIT_1 state. The client gets the FIN packet and goes into CLOSE_WAIT state, and sends an acknowledgment packet back to the server. When the server gets that packet, it goes into FIN_WAIT_2 state. From the server's perspective, the connection is now closed, and the server can't send any more data. However, under the TCP protocol, the client needs to shut down also by sending a FIN packet, which the server TCP implementation should ACK. The server should close about two milliseconds later.

Post a Comment


Java (159) Lucene-Solr (112) Interview (61) All (58) J2SE (53) Algorithm (45) Soft Skills (38) Eclipse (33) Code Example (31) Linux (25) JavaScript (23) Spring (22) Windows (22) Web Development (20) Tools (19) Nutch2 (18) Bugs (17) Debug (16) Defects (14) Text Mining (14) J2EE (13) Network (13) Troubleshooting (13) PowerShell (11) Chrome (9) Design (9) How to (9) Learning code (9) Performance (9) Problem Solving (9) UIMA (9) html (9) Http Client (8) Maven (8) Security (8) bat (8) blogger (8) Big Data (7) Continuous Integration (7) Google (7) Guava (7) JSON (7) Shell (7) ANT (6) Coding Skills (6) Database (6) Lesson Learned (6) Programmer Skills (6) Scala (6) Tips (6) css (6) Algorithm Series (5) Cache (5) Dynamic Languages (5) IDE (5) System Design (5) adsense (5) xml (5) AIX (4) Code Quality (4) GAE (4) Git (4) Good Programming Practices (4) Jackson (4) Memory Usage (4) Miscs (4) OpenNLP (4) Project Managment (4) Spark (4) Testing (4) ads (4) regular-expression (4) Android (3) Apache Spark (3) Become a Better You (3) Concurrency (3) Eclipse RCP (3) English (3) Happy Hacking (3) IBM (3) J2SE Knowledge Series (3) JAX-RS (3) Jetty (3) Restful Web Service (3) Script (3) regex (3) seo (3) .Net (2) Android Studio (2) Apache (2) Apache Procrun (2) Architecture (2) Batch (2) Bit Operation (2) Build (2) Building Scalable Web Sites (2) C# (2) C/C++ (2) CSV (2) Career (2) Cassandra (2) Distributed (2) Fiddler (2) Firefox (2) Google Drive (2) Gson (2) How to Interview (2) Html Parser (2) Http (2) Image Tools (2) JQuery (2) Jersey (2) LDAP (2) Life (2) Logging (2) Python (2) Software Issues (2) Storage (2) Text Search (2) xml parser (2) AOP (1) Application Design (1) AspectJ (1) Chrome DevTools (1) Cloud (1) Codility (1) Data Mining (1) Data Structure (1) ExceptionUtils (1) Exif (1) Feature Request (1) FindBugs (1) Greasemonkey (1) HTML5 (1) Httpd (1) I18N (1) IBM Java Thread Dump Analyzer (1) JDK Source Code (1) JDK8 (1) JMX (1) Lazy Developer (1) Mac (1) Machine Learning (1) Mobile (1) My Plan for 2010 (1) Netbeans (1) Notes (1) Operating System (1) Perl (1) Problems (1) Product Architecture (1) Programming Life (1) Quality (1) Redhat (1) Redis (1) Review (1) RxJava (1) Solutions logs (1) Team Management (1) Thread Dump Analyzer (1) Visualization (1) boilerpipe (1) htm (1) ongoing (1) procrun (1) rss (1)

Popular Posts