Teardown tcp connection что означает

ASA FAQ: How do you interpret the syslogs generated by the ASA when it builds or tears down connections?

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

This document describes how to interpret the generation for the Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) syslog on the Adaptive Security Appliance (ASA) device when it builds and tears down connections.

How do you interpret the syslogs generated by the ASA when it builds or tears down connections?

All the syslogs discussed in this document are based on the network topologies shown here.

Network Topology

Scenario 1: Management traffic to the ASA inside interface (identity) is sourced from the inside host

Scenario 2: Traffic through the ASA is sourced from the inside host and is destined to the outside host

Scenario 3: Management traffic to the ASA outside interface (identity) is sourced from the outside host

Scenario 4: Traffic through the ASA is sourced from the outside host and is destined to the inside host

Network Topology (Same-Security Interfaces)

Scenario 1: Traffic through the ASA is sourced from the inside host and is destined to the outside host

Scenario 2: Traffic through the ASA is sourced from the outside host to the inside host

Teardown tcp connection что означает

Показываю:

PIX Version 6.3(1)
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto
interface ethernet3 auto shutdown
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security15
nameif ethernet3 pix/intf3 security15
enable password uBsOjijurAEZFM7c encrypted
passwd h4vMmAV6UI3wICj/ encrypted
hostname host
domain-name host.ru
clock timezone MSK/MSD 3
clock summer-time MSK/MDD recurring last Sun Mar 2:00 last Sun Oct 3:00
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
names
access-list ICMP permit icmp any any
access-list inside_access_in permit ip any any log 7 interval 10
access-list dmz_access_in permit ip any any log 7 interval 10
pager lines 24
logging on
logging timestamp
logging trap debugging
logging facility 23
logging host inside 10.60.33.60
icmp permit any outside
icmp permit any inside
icmp permit any dmz
mtu outside 1500
mtu inside 1500
mtu dmz 1500
mtu pix/intf3 1500
ip address outside 10.1.0.2 255.255.255.252
ip address inside 10.60.33.26 255.255.255.0
ip address dmz 10.50.0.1 255.255.255.0
ip address pix/intf3 10.30.30.30 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
no failover
failover timeout 0:00:00
failover poll 15
no failover ip address outside
no failover ip address inside
no failover ip address dmz
no failover ip address pix/intf3
pdm location 10.60.1.0 255.255.255.0 pix/intf3
pdm location 10.100.0.108 255.255.255.255 pix/intf3
pdm location 10.60.33.0 255.255.255.0 inside
pdm location 10.60.33.60 255.255.255.255 inside
no pdm history enable
arp timeout 14400
static (inside,dmz) 10.50.0.42 10.60.33.60 netmask 255.255.255.255 0 0
access-group inside_access_in in interface inside
access-group dmz_access_in in interface dmz
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
aaa authentication secure-http-client
http server enable
http 10.60.33.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection tcpmss 0
telnet 10.60.33.0 255.255.255.0 inside
telnet timeout 15
ssh timeout 5
console timeout 0
username marat password 45W6njenyVAPlJYd encrypted privilege 15
terminal width 80
Cryptochecksum:8813f393d6c053d25270dce391c69931

teardown connection

ASA TCP Connection Flags (Connection Build-Up and Teardown)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

This document provides information about Adaptive Security Appliance (ASA) TCP connection flags.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

Basic knowledge of the TCP Communications Protocol

Basic knowledge of the ASA CLI

Components Used

The information in this document is based on ASA version 8.4.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

ASA TCP Connection Flags

When you troubleshoot TCP connections through the Adaptive Security Appliance (ASA), the connection flags shown for each TCP connection provide a wealth of information about the state of TCP connections to the ASA. This information can be used to troubleshoot problems with the ASA, as well as problems elsewhere in the network.

Here is the output of the show conn protocol tcp command, which shows the state of all TCP connections through the ASA. These connections can also be seen with the show conn command.

The next picture shows the ASA TCP Connection flags at different stages of the TCP state machine. The connection flags can be seen with the show conn command on the ASA.

TCP Connection Flag Values

Additionally, in order to view all of the possible connection flags issue the show connection detail command on the command-line:

Basic understanding of ARP, DHCP, TCP connection and Teardown through Wireshark

Here are we are going learn about basic of Address Resolution Protocol (ARP), Dynamic Host Configuration Protocol (DHCP), Transmission Control Protocol (TCP) connection and TCP teardown. Wireshark protocol analyzer will be used to show the packet exchanges for these protocols.

♣ Load Capture in Wireshark:

Wireshark is open source free networking tool. It can be downloaded for any operating system. After it’s installed, here is the first screen of Wireshark.

Wireshark Home screen

To load any capture, go to Edit->Open and select the required capture to be displayed into Wireshark.

Once any capture is loaded it will look like this.

Now let’s understand some protocols and see packets into Wireshark.

♣ ARP:

ARP protocol is used to get the MAC address of another device when you know the IP address of the another device. Let’s see below diagram to understand in simple way.

Suppose device A knows the IP address of device B but does not know MAC address of device B. What should device A do? Here are the steps.

So there should be two packets exchanges if someone has the requested IP in ARP request.

Here is the screenshot in Wireshark after using filter “arp”.

Packet number 1 is Arp Request and packet number 2 is Arp Reply. Now if we take information from capture and put it in diagram, it will look like this.

♦ ARP Request:

ARP Request is the first packet which is sent from the device which is looking for MAC address.

Here is the screenshot of ARP request packet with inside fields.

ARP request

♦ ARP Reply:

ARP Reply is the packet which is sent from the device which has received the query in ARP request.

Here is the screenshot of ARP reply packet with inside fields.

ARP reply

Security concern related to ARP protocol is ARP spoofing.

Protocol standard for ARP is https://tools.ietf.org/html/rfc6747

♣ DHCP:

In simple sentence, DHCP is a process to get IP address from Server. There are mainly 4 packets exchanges in DHCP.

1. DHCP Discover

2. DHCP Offer

3. DHCP Request

4. DHCP Accept

Let’s see these 4 packets in simple diagram

DHCP Discover [Broadcast]

DHCP Offer [Broadcast]

DHCP Request [Broadcast]

DHCP Accept [Broadcast]

Note: These are mainly broadcast but these packets can be sent as unicast in some scenarios.

Let’s see these packets in Wireshark. We can use filter name as “bootp” to get DHCP packets

1. DHCP Discover:

Here is the screenshot to explain about important fields of DHCP discover packet.

DHCP Discover

From above packet we can understand that DHCP discover is a broadcast packet asking for IP address for client.

2. DHCP Offer:
Here is the screenshot to explain about important fields of DHCP offer packet.

DHCP offer

As we can see DHCP offer packet has offered IP address, subnet mask, lease time and server informations like server IP, server domain name etc. Remember that client may receive multiple DHCP offer packets from multiple servers. But it’s client choice to send DHCP request packet to one server.

3. DHCP Request:

Here is the screenshot to explain about important fields of DHCP request packet.

DHCP Request

Client can choose the server and send DHCP offer mentioning one DHCP server IP address. Also client asks for some parameter list from Server.

4. DHCP ACK:

Here is the screenshot to explain about important fields of DHCP ACK packet.

DHCP ACK

DHCP ACK packet is basically the Acknowledge packet from server with almost same information sent in packet DHCP offer.

Now the question comes what happens after 1 day. Client does DHCP renewal. For DHCP renewal there are 2 frame exchanges

1. DHCP Request: DHCP request packet fields are same as previous point 3 but here Client IP address field should be filled with client’s current IP [Example: 192.168.1.101 ] or we can say requested IP.

2. DHCP ACK: DHCP ACK us same as previous point 4.

But the difference is here DHCP Request is unicast packet because client knows its server. DHCP ACK is broadcast as usual.

See screenshot

Protocol standard for DHCP is https://tools.ietf.org/html/rfc2131

♣ TCP:

Transmission Control Protocol is a major protocol in Transport layer. Client and server have to exchange 3 packets to establish TCP connection. We can call it’s a TCP 3-way handshake.

TCP Connection:

Let’s see all three packets from Wireshark. We can use filter “tcp” to list out all tcp packets and the first 3 packets should be the 3-way hand shake packet. Have a look on below screenshot.

♦ SYN:

Here is the screenshot for SYN packet sent by client to server

TCP SYN

Basically SYN packet is sent to share client’s capabilities to server.

SYN+ACK:

Now server share it’s capabilities to client through SYN+ACK packet. So this packet is acknowledgement of SYN packet and also sharing server’s capabilities.

Here is the screenshot

SYN+ACK

If we compare SYN and SYN+ACK packet we can see differences between client’s and server’s capabilities. These informations are useful when client and server shares TCP data packets.

♦ ACK:

Here is the screenshot of ACK packet

This packet is just the acknowledgement from client.

Now TCP connection is completed.

♣ TCP Teardown:

To discontinue existing TCP connection some packet exchanges occur between client and server. If client wants to terminate connection then client can send FIN packet and server sends ACK. Now if server also wants to terminate connection from its end then server sends FIN and gets ACK packet as reply. So, total 4 packets exchanges are happening for complete TCP connection close between client and server.

Note: FIN packet is sent as FIN+ACK to indicate that this FIN packet also the ACK of any previous packet. Do not get confused.

There is no important information inside FIN and ACK packet as this indicates TCP connection termination.

Here is the screenshot for FIN packet

FIN

In reply to FIN, only ACK packet is sent as an acknowledgement. Here is the screenshot of ACK packet.

FIN+ACK

Protocol standard for TCP is https://tools.ietf.org/html/rfc793

Some security threats related to TCP is TCP half open, TCP full scan, TCP Null scan etc.

♣ Conclusions:

From the above article we got basic idea about ARP, DHCP, TCP protocol and their important fields in Wireshark. For deep dive we can go through the shared RFC link.

TCP (Transmission Control Protocol) – The transmission protocol explained

When you connect to the Internet, you establish a connection between a router and a computer or mobile device in a few simple steps, whether you’re using wired or wireless technology. Nothing else is required because the system automatically logs in to the network and obtains the unique Internet address that you need to receive and send data. This is made possible by a set of protocols known as the Internet protocol suite. One of the oldest and most important protocols in the suite is the Transmission Control Protocol (TCP). It determines how network devices exchange data.

What is TCP (Transmission Control Protocol)?

The Transmission Control Protocol, or TCP protocol for short, is a standard for exchanging data between different devices in a computer network. This protocol dates back to 1973, when computer scientists Robert E. Kahn and Vinton G. Cerf published the first version of the standard as part of a research paper. However, it took another eight years before TCP was standardized in RFC 793. Since then, there have been a number of improvements and extensions, although the core of the protocol has remained unchanged. The current version, which is defined in RFC 7323 is from 2014.

The current version of the TCP protocol allows two endpoints in a shared computer network to establish a connection that enables a two-way transmission of data. Any data loss is detected and automatically corrected, which is why TCP is also called a reliable protocol. Together with UDP and SCTP, TCP forms the group of transmission protocols belonging to the Internet protocol suite that are located at the transport layer in the network architecture according to the OSI model. The term TCIP/IP protocol stack is also commonly used to refer to the Internet protocol suite since the TCP protocol is almost always based on the Internet protocol (IP) and this connection is the foundation for the majority of public and local networks and network services.

How exactly do TCP connections work?

TCP allows for transmission of information in both directions. This means that computer systems that communicate over TCP can send and receive data at the same time, similar to a telephone conversation. The protocol uses segments (packets) as the basic units of data transmission. In addition to the payload, segments can also contain control information and are limited to 1,500 bytes. The TCP software in the network protocol stack of the operating system is responsible for establishing and terminating the end-to-end connections as well as transferring data.

The TCP software is controlled by the various network applications, such as web browsers or servers, via specific interfaces. Each connection must always be identified by two clearly defined endpoints (client and server). It doesn’t matter which side assumes the client role and which assumes the server role. All that matters is that the TCP software is provided with a unique, ordered pair consisting of IP address and port (also referred to as «2-tuple» or «socket») for each endpoint.

The three-way handshake: How a TCP connection is established in detail

Prerequisites for establishing a valid TCP connection: Both endpoints must already have a unique IP address (IPv4 or IPv6) and have assigned and enabled the desiredport for data transfer. The IP address serves as an identifier, whereas the port allows the operating system to assign connections to the specific client and server applications.

For a detailed explanation of how TCP and IP interact, see our in-depth article on TCP/IP.

The actual process for establishing a connection with the TCP protocol is as follows:

1. First, the requesting client sends the server a SYN packet or segment (SYN stands for synchronize) with a unique, random number. This number ensures full transmission in the correct order (without duplicates).
2. If the server has received the segment, it agrees to the connection by returning a SYN-ACK packet (ACK stands for acknowledgment) including the client’s sequence number plus 1. It also transmits its own sequence number to the client.
3. Finally, the client acknowledges the receipt of the SYN-ACK segment by sending its own ACK packet, which in this case contains the server’s sequence number plus 1. At the same time, the client can already begin transferring data to the server.

Process of establishing a TCP connection (three-way handshake)

Since the TCP connection is established in three steps, the connection process is called a three-way handshake.

If the server port is closed or access is blocked, the client receives a TCP RST packet (reset) instead of an acknowledgment packet.

TCP teardown: How a controlled TCP connection termination works

Both sides of a connection can terminate a TCP connection, and even one-sided termination is also possible. This is also known as a half-open connection, whereby the other side is still allowed to transfer data even if one side has already disconnected.

The individual steps of two-way termination (initiated by the client for the sake of simplicity in this example) can be summarized as follows:

1. The client sends a FIN segment to notify the server that it no longer wants to send data. It sends its own sequence number, just as it does when the connection is established.
2. The server acknowledges receipt of the package with an ACK segment that contains the sequence number plus 1.
3. When the server has finished the data transfer, it also sends a FIN packet, to which it adds its sequence number.
4. Now it is the client’s turn to send an ACK packet including the sequence number plus 1, which officially terminates the TCP connection for the server.

Process of TCP connection termination (TCP teardown)

However, the connection is not immediately terminated for the side that sent the last ACK segment (in our case, the client). Since there’s no guarantee that the last packet sent has actually arrived, the client or server will initially remain in time-wait state until the maximum lifetimes of the ACK segment and any new FIN segments (according to RFC 793, two minutes for each segment) have expired.

What is the structure of the TCP header?

Typically, the header of a TCP packet contains the data required for connection and data transmission with the Transmission Control Protocol. This header data (which contains control information) precedes the payload to be transferred and is typically 20 bytes (160 bits) in size. It is followed by up to 40 bytes (320 bits) of additional information, which is optional and not used in all packets.

TCP segments without payload data, essentially pure headers, are also allowed if only acknowledgments, error messages, etc. need to be transmitted, as in the case of SYN and FIN messages (connection establishment/termination).

The detailed structure of the TCP header is as follows:

Structure of a TCP header

The individual components or fields of the header of the TCP protocol have the following meaning:

Source port (16 bits): Identifies the port number of the sender.

Destination port (16 bits): Identifies the port number of receiver.

Sequence number (32 bits): The sequence number specifies the first byte of attached payload data or is sent when the connection is established or terminated. It is also used for validating and sorting the segments after transmission.

Acknowledgment number (32 bits): This field contains the next sequence number that the sender is expecting. An ACK flag (in the “Flags” field) is a precondition for validity.

Offset (4 bits): The “Offset” field specifies the length of the TCP header in 32-bit words to highlight the starting point of the payload data. This starting point varies from segment to segment due to the variable “Options” field.

Reserved (6 bits): Reserved for future use according to RFC 793 and not yet in use. This field must always be set to 0.

Flags (6 bits): The six possible single bits in the “Flags” field enable various TCP actions for organizing communication and data processing. The following flags are either set or not set for these actions:

• URG: The «Urgent» flag signals to the TCP application that the payload data must be processed immediately up to the set Urgent pointer (see above).
• ACK: In combination with the acknowledgment number, the ACK flag acknowledges the receipt of TCP packets. If the flag is not set, the confirmation number is also invalid.
• PSH: The «Push» flag ensures that a TCP segment is immediately pushed through without first being sent to the buffer of the sender and receiver.
• RST: If there is an error during transmission, a TCP packet with the RST flag set can be used to reset the connection.
• SYN: Messages that have SYN flag set represent the first step of the three-way handshake, meaning they initiate the connection.
• FIN: The «Finish» flag signals to the other party that a sender is ending the transmission.

Window size (16 bits): This field specifies the number of bytes that the sender is willing to receive.

Checksum (16 bits): The Transmission Control Protocol can reliably detect transmission errors. The checksum calculated from the header, the payload data and the pseudo-header is used for this purpose.

Urgent pointer (16 bits): The urgent pointer indicates the position of the first byte after the payload data that is to be processed urgently. As a result, this field is only valid and relevant if the URG flag is set.

Options (0 — 320 bits): Use the Options field if you want to include TCP functions that don’t belong in the general header, for example if you want to define the maximum segment size. The length of the options must always be a multiple of 32, otherwise zero-bit padding is required.

How data transmission via TCP protocol works in detail

Even before the first data is transmitted, the sender and receiver typically agree on the maximum size of the TCP segments to be sent (MSS). By default, up to 1,500 bytes per segment are possible, with at least 20 bytes for the TCP header and a further 20 bytes for the IP header, leaving 1,460 bytes for payload data. If you need a custom size, you have to specify it in the Options field as described above, but you’ll have to reduce the payload data accordingly.