Tuesday, March 12, 2019

Half Open/Close TCP Connections (Stale/Drop/Embryonic connections)


Half Open and Half Close TCP Connections(Embryonic Connections)


There is a three-way handshake to open a TCP/IP connection, and a four-way handshake to close it. However, once the connection has been established, if neither side sends any data, then no packets are sent over the connection. TCP is an “idle” protocol, happy to assume that the connection is active until proven otherwise.

Half Open


At any given point in most protocols, one side is expected to send a message and the other side is expecting to receive it. Consider what happens if an intermediate router is suddenly rebooted at that point: the receiving side will continue waiting for the message to arrive; the sending side will send its data, and receive an error indicating the connection was lost. Since broken connections can only be detected by sending data, the receiving side will wait forever. This scenario is called a “half-open connection” because one side realizes the connection was lost but the other side believes it is still active.

Half Close


Half-closed connections are when one side performs a Shutdown operation on its socket, shutting down only the sending (outgoing) stream. Either the receiving stream or sending stream may be clamped shut. For receives, this is only a local operation; the other end of the connection is not notified. For sends, the outgoing stream is shut down (the same way Disconnect does it), and this is acknowledged by the other side; however, there is no notification of this operation completing.




Causes of Half-Open/Half-Close Connections

Half-open connections are commonly happening in the real world. This is because if the socket is shut down with the normal four-way handshake (or even if it is abruptly closed), the half-open problem will not occur. Some of the common causes of a half-open connection are described below:

  • Process crash:  If a process shuts down normally, it usually sends out a “FIN” packet, which informs the other side that the connection has been lost. However, if a process crashes or is terminated (e.g., from Task Manager), this is not guaranteed. It is possible that the OS will send out a “FIN” packet on behalf of a crashed process; however, this is up to the OS.
  • Computer crash: If the entire computer (including the OS) crashes or loses power, then there is certainly no notification to the other side that the connection has been lost.
  • Router crash/reboot:  Any of the routers along the route from one side to the other may also crash or be rebooted; this causes a loss of connection if data is being sent at that time. If no data is being sent at that exact time, then the connection is not lost.
  • Network cable unplugged:  Any network cables unplugged along the route from one side to the other will cause a loss of connection without any notification. This is similar to the router case; if there is no data being transferred, then the connection is not actually lost. However, computers usually will detect if their specific network cable is unplugged and may notify their local sockets that the network was lost (the remote side will not be notified).
  • Wireless devices (including laptops) moving out of range:  A wireless device that moves out of its access point range will lose its connection. This is an often-overlooked but increasingly common situation.

In all of the situations above, it is possible that one side may be aware of the loss of connection, while the other side is not.

Wrong Methods to Detect Dropped Connections

  • A Second socket connection:  A new socket connection cannot determine the validity of an existing connection in all cases. In particular, if the remote side has crashed and rebooted, then a second connection attempt will succeed even though the original connection is in a half-open state.
  • Ping: Sending a ping (ICMP) to the remote side has the same problem: it may succeed even when the connection is unusable. Furthermore, ICMP traffic is often treated differently than TCP traffic by routers.

Correct Methods to Detect Dropped Connections


Add a keepalive message to the application protocol framing (an empty message).
  • Length-prefixed and delimited systems may send empty messages (e.g., a length prefix of “0 bytes” or a single “end delimiter”).
Add a keepalive message to the actual application protocol (a “null” message).
  • This adds a new message to the application protocol: a “null” message that should just be ignored.
Explicit timer assuming the worst.
  • Have a timer and assume that the connection has been dropped when the timer expires (of course, the timer is reset each time data is transferred). This is the way HTTP servers work, if they support persistent connections.
Manipulate the TCP/IP keepalive packet settings.
  • This is a highly controversial solution that has complex arguments for both pros and cons. Essentially, this instructs the TCP/IP stack to send keepalive packets periodically on the application’s behalf.
Keep-Alive (also known as HTTP Keep-Alive or persistent connection) :
  • With higher traffic this value can go extremely higher to make sure there is no frequent TCP connection re-initiated.
  • If this value goes down too much, Keep-Alive loses its purpose!
  • It prevents unused connections from hanging around for too long.

TCP Keep-Alive


  • TCP connections consist of two sockets, one on each end of the connection. When one side wants to terminate the connection, it sends an RST packet which the other side acknowledges and both close their sockets.
  • Until that happens, however, both sides will keep their socket open indefinitely. This leaves open the possibility that one side may close their socket, either intentionally or due to some error, without informing the other end via RST. In order to detect this scenario and close stale connections the TCP Keep Alive process is used.
  • It means that you will be able to check your connected socket (also known as TCP sockets), and determine whether the connection is still up and running or if it has broken.
  • The keepalive concept is very simple: when you set up a TCP connection, you associate a set of timers. Some of these timers deal with the keepalive procedure. When the keepalive timer reaches zero, you send your peer a keepalive probe packet with no data in it and the ACK flag turned on.
  • If you receive a reply to your keepalive probe, you can assert that the connection is still up and running without worrying about the user-level implementation. In fact, TCP permits you to handle a stream, not packets, and so a zero-length data packet is not dangerous for the user program.
  • This procedure is useful because if the other peers lose their connection (for example by rebooting) you will notice that the connection is broken, even if you don't have traffic on it. If the keepalive probes are not replied to by your peer, you can assert that the connection cannot be considered valid and then take the correct action.


Two target tasks for keepalive


1. Checking for dead peers:

  • Keepalive can be used to advise you when your peer dies before it is able to notify you.
  • When the peer is still alive but the network channel between it and you has gone down. In this scenario, if the network doesn't become operational again, you have the equivalent of peer death.
  • If the problem is in the network between two peers, the keepalive action is to wait some time and then retry, sending the keepalive packet before marking the connection as broken. 
  • Think of a simple TCP connection between Peer A and Peer B: there is the initial three-way handshake, with one SYN segment from A to B, the SYN/ACK back from B to A, and the final ACK from A to B. At this time, we're in a stable status: connection is established, and now we would normally wait for someone to send data over the channel. And here comes the problem: unplug the power supply from B and instantaneously it will go down, without sending anything over the network to notify A that the connection is going to be broken. A, from its side, is ready to receive data, and has no idea that B has crashed. Now restore the power supply to B and wait for the system to restart. A and B are now back again, but while A knows about a connection still active with B, B has no idea. The situation resolves itself when A tries to send data to B over the dead connection, and B replies with an RST packet, causing A to finally to close the connection.

2. Preventing disconnection due to network inactivity



  • The other useful goal of keepalive is to prevent inactivity from disconnecting the channel.
  • It's a very common issue, when you are behind a NAT proxy or a firewall, to be disconnected without a reason.
  • This behavior is caused by the connection tracking procedures implemented in proxies and firewalls, which keep track of all connections that pass through them. Because of the physical limits of these machines, they can only keep a finite number of connections in their memory. The most common and logical policy is to keep newest connections and to discard old and inactive connections first.
  • Returning to Peers A and B, reconnect them. Once the channel is open, wait until an event occurs and then communicate this to the other peer. What if the event verifies after a long period of time? Our connection has its scope, but it's unknown to the proxy. So when we finally send data, the proxy isn't able to correctly handle it, and the connection breaks up. 


Keep-Alive Process


There are three configurable properties that determine how Keep-Alives work. On Linux they are :
tcp_keepalive_time
o    default 7200 seconds
tcp_keepalive_probes
o    default 9
tcp_keepalive_intvl
o    default 75 seconds
The process works like this:
1.       Client opens TCP connection
2.       If the connection is silent for tcp_keepalive_time seconds, send a single empty ACK packet.
3.       Did the server respond with a corresponding ACK of its own?
o    No
1.       Wait tcp_keepalive_intvl seconds, then send another ACK
2.       Repeat until the number of ACK probes that have been sent equals tcp_keepalive_probes.
3.       If no response has been received at this point, send a RST and terminate the connection.
o    Yes: Return to step 2
This process is enabled by default on most operating systems, and thus dead TCP connections are regularly pruned once the other end has been non-responsive for 2 hours 11 minutes (7200 seconds + 75 * 9 seconds).

Java


Unfortunately since TCP connections are managed on the OS level, Java does not support configuring timeouts on a per-socket level such as in java.net.Socket

OS Level


In some cases (especially Java), you may be forced to apply your configuration to the operating system as a whole. Be aware that this configuration will affect all TCP connections running on the entire system.

Linux :


The currently configured TCP Keep-Alive settings can be found in
·         /proc/sys/net/ipv4/tcp_keepalive_time
·         /proc/sys/net/ipv4/tcp_keepalive_probes
·         /proc/sys/net/ipv4/tcp_keepalive_intvl
You can update any of these like so:
# Send first Keep-Alive packet when a TCP socket has been idle for 3 minutes
$ echo 180 > /proc/sys/net/ipv4/tcp_keepalive_time
# Send three Keep-Alive probes...
$ echo 3 > /proc/sys/net/ipv4/tcp_keepalive_probes
# ... spaced 10 seconds apart.
$ echo 10 > /proc/sys/net/ipv4/tcp_keepalive_intvl

These changes will not persist through a restart. To make persistent changes, use sysctl:

sysctl -w net.ipv4.tcp_keepalive_time=180 net.ipv4.tcp_keepalive_probes=3 net.ipv4.tcp_keepalive_intvl=10 

OS Dead Connection Management

Linux OS Default : (tcp_keepalive_time +  tcp_keepalive_probes * tcp_keepalive_intvl) = (7200 seconds + 75 * 9 seconds) = 2 hours 11 minutes


Database Stale Connection (This situation can occur for many reasons):


  • The application tries to get a connection and fails, as when the database is not started.
  • A connection is no longer usable because of a database failure. When an application tries to use a previously obtained connection, the connection is no longer valid. In this case, all connections currently in use by the application can get this error when they try to use the connection.
  • The connection is orphaned (because the application had not used it in at most two times the value of the unused timeout setting) and the application tries to use the orphaned connection. This case applies only to V4.0 data sources.
  • The application tries to use a JDBC resource, such as a statement, obtained on a stale connection.
  • A connection is closed by the V4.0 data source auto connection cleanup feature and is no longer usable. Auto connection cleanup is the standard mode in which connection management operates. This mode indicates that at the end of a transaction, the transaction manager closes all connections enlisted in that transaction. This enables the transaction manager to ensure that connections are not held for excessive periods of time and that the pool does not reach its maximum number of connections prematurely.

Scenarios to generate database stale connections at application end:
  • DROP/REJECT the tcp/ip connections using iptables from source application server or destination database server.
  • Applied stress into destination database server CPU/memory using stress linux utility and checked the delay in getting connection time.
  • Kill the tcp/ip connection from source application server using tcpkill linux utility
  • Shutdown the destination database server
CLOSE_WAIT
  • If you are seeing a large number of connections persisting in CLOSE_WAIT state, it’s probably a problem with the application itself. Restarting it will clear the connections temporarily, but obviously, further investigation will be required to find the cause of the problem. If restarting of application is undesirable, you can manually kill all connections that are in CLOSE_WAIT state.

You cannot kill a TCP connection using netstat utility. netstat is use for

  • Display network connections
  • Routing tables
  • Interface statistics
  • Masquerade connections
  • Multicast memberships
  • And much more

However Linux support two other commands or utility that can be used to kill a TCP connection. To "kill" a socket, you must send a TCP reset packet(R). To send it (and be accepted by the other side), you must know the actual TCP sequence number.
  • tcpkill : The already mentioned tcpkill method learns the SEQ number by passively sniffing on the network and waiting for valid packets of this connection to arrive. Then it uses the learned SEQ number to send RSET packets to both sides. However if the connection is idle/hanged and no data flows, it won't do anything and will wait forever.
  • killcx : Another method uses perl script called killcx .This actively sends spoofed SYN packets and learns the SEQ number from the answer. It then sends RSET packets the same way as tcpkill.
For more about IP and Packets Spoofing , Click on https://www.java2depth.com/2019/03/tcp-syn-flood-attack-ip-and-packets.html


To kill an already established TCP session / stale connections but without killing the process that opened it.

Solution #1: passive mechanism 

  • This is passive mechanism to learn about the TCP ACK and SEQ numbers. Once it knows the numbers it spoofs a TCP segments and try to reset the TCP session on both sides.
  • If the TCP session is idle or in generic there is no data being exchanged than this passive mechanism unfortunately is not going to work.
  • tcpkill -i eth0 { expression }
  • For tcpkill to work (i.e., craft a reset packet that has the correct sequence number and source port), there must be traffic. If nothing more is printed then there is no traffic.
  • To verify you could run tcpdump -i eth1 port 443.
Example:

[root@SERVER ~]#  nc -v -l 7777
Connection from 172.30.40.108 port 7777 [tcp/cbt] accepted
This is java2depth
Please kill my tcp connection

[root@CLIENT ~]# nc -D 172.30.40.115 7777
This is java2depth
Please kill my tcp connection

[root@SERVER ~]# tcpdump -i eth1 -nn port 7777
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
07:45:41.537168 IP 172.30.40.108.48236 > 172.30.40.115.7777: Flags [S], seq 926008289, win 14600, options [mss 1460,sackOK,TS val 789656686 ecr 0,nop,wscale  7], length 0
07:45:41.537232 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [S.], seq 3884442905, ack 926008290, win 14480, options [mss 1460,sackOK,TS val 355193510  ecr 789656686,nop,wscale 7], length 0
07:45:41.537632 IP 172.30.40.108.48236 > 172.30.40.115.7777: Flags [.], ack 1, win 115, options [nop,nop,TS val 789656687 ecr 355193510], length 0
07:46:04.251436 IP 172.30.40.108.48236 > 172.30.40.115.7777: Flags [P.], seq 1:20, ack 1, win 115, options [nop,nop,TS val 789679401 ecr 355193510], length  19
07:46:04.251490 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [.], ack 20, win 114, options [nop,nop,TS val 355216225 ecr 789679401], length 0
07:57:32.149418 IP 172.30.40.108.48236 > 172.30.40.115.7777: Flags [P.], seq 20:50, ack 1, win 115, options [nop,nop,TS val 790367299 ecr 355216225], length  30
07:57:32.149510 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [.], ack 50, win 114, options [nop,nop,TS val 355904123 ecr 790367299], length 0
07:57:32.149991 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884442906, win 0, length 0
07:57:32.150108 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884443021, win 0, length 0
07:57:32.150164 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884443251, win 0, length 0
07:57:32.150215 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884443596, win 0, length 0
07:57:32.150266 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884444056, win 0, length 0
07:57:32.150316 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884444631, win 0, length 0
07:57:32.150366 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884445321, win 0, length 0
07:57:32.150428 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884446126, win 0, length 0
07:57:32.150479 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884447046, win 0, length 0

[root@CLIENT ~]# tcpdump -i eth2 -nn port 7777
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
07:46:15.211274 IP 172.30.40.108.48236 > 172.30.40.115.7777: Flags [S], seq 926008289, win 14600, options [mss 1460,sackOK,TS val 789656686 ecr 0,nop,wscale  7], length 0
07:46:15.211707 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [S.], seq 3884442905, ack 926008290, win 14480, options [mss 1460,sackOK,TS val 355193510  ecr 789656686,nop,wscale 7], length 0
07:46:15.211735 IP 172.30.40.108.48236 > 172.30.40.115.7777: Flags [.], ack 1, win 115, options [nop,nop,TS val 789656687 ecr 355193510], length 0
07:46:37.925523 IP 172.30.40.108.48236 > 172.30.40.115.7777: Flags [P.], seq 1:20, ack 1, win 115, options [nop,nop,TS val 789679401 ecr 355193510], length  19
07:46:37.925931 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [.], ack 20, win 114, options [nop,nop,TS val 355216225 ecr 789679401], length 0
07:58:05.823603 IP 172.30.40.108.48236 > 172.30.40.115.7777: Flags [P.], seq 20:50, ack 1, win 115, options [nop,nop,TS val 790367299 ecr 355216225], length  30
07:58:05.824004 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [.], ack 50, win 114, options [nop,nop,TS val 355904123 ecr 790367299], length 0
07:58:05.824449 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884442906, win 0, length 0
07:58:05.824556 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884443021, win 0, length 0
07:58:05.824692 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884443251, win 0, length 0
07:58:05.824704 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884443596, win 0, length 0
07:58:05.824712 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884444056, win 0, length 0
07:58:05.824760 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884444631, win 0, length 0
07:58:05.824811 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884445321, win 0, length 0
07:58:05.824875 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884446126, win 0, length 0
07:58:05.824931 IP 172.30.40.115.7777 > 172.30.40.108.48236: Flags [R], seq 3884447046, win 0, length 0

[root@SERVER ~]# netstat -natp | grep 7777
tcp        0      0 0.0.0.0:7777                0.0.0.0:*                   LISTEN      19931/nc
tcp        0      0 172.30.40.115:7777          172.30.40.108:48236         ESTABLISHED 19931/nc
[root@SERVER ~]# tcpkill -i eth1 -9  port 48236
tcpkill: listening on eth1 [port 48236]
172.30.40.108:48236 > 172.30.40.115:7777: R 3884442906:3884442906(0) win 0
172.30.40.108:48236 > 172.30.40.115:7777: R 3884443021:3884443021(0) win 0
172.30.40.108:48236 > 172.30.40.115:7777: R 3884443251:3884443251(0) win 0
172.30.40.108:48236 > 172.30.40.115:7777: R 3884443596:3884443596(0) win 0
172.30.40.108:48236 > 172.30.40.115:7777: R 3884444056:3884444056(0) win 0
172.30.40.108:48236 > 172.30.40.115:7777: R 3884444631:3884444631(0) win 0
172.30.40.108:48236 > 172.30.40.115:7777: R 3884445321:3884445321(0) win 0
172.30.40.108:48236 > 172.30.40.115:7777: R 3884446126:3884446126(0) win 0
172.30.40.108:48236 > 172.30.40.115:7777: R 3884447046:3884447046(0) win 0
172.30.40.115:7777 > 172.30.40.108:48236: R 926008339:926008339(0) win 0
172.30.40.115:7777 > 172.30.40.108:48236: R 926008453:926008453(0) win 0
172.30.40.115:7777 > 172.30.40.108:48236: R 926008681:926008681(0) win 0
172.30.40.115:7777 > 172.30.40.108:48236: R 926009023:926009023(0) win 0
172.30.40.115:7777 > 172.30.40.108:48236: R 926009479:926009479(0) win 0
172.30.40.115:7777 > 172.30.40.108:48236: R 926010049:926010049(0) win 0
172.30.40.115:7777 > 172.30.40.108:48236: R 926010733:926010733(0) win 0
172.30.40.115:7777 > 172.30.40.108:48236: R 926011531:926011531(0) win 0
172.30.40.115:7777 > 172.30.40.108:48236: R 926012443:926012443(0) win 0
 

Solution #2: active mechanism 

  • It tries to generate traffic on the wire to discover what the ACK and SEQ numbers are. Once it forces the peer to replay to its spoofed traffic it kills the TCP session immediately after.
  • killcx dest_ip:dest_port
Example:

[root@SERVER ~]# nc -v -l 7777
Connection from 172.30.40.108 port 7777 [tcp/cbt] accepted
This is java2depth
Please kill my tcp connection

[root@CLIENT ~]# nc -D 172.30.40.115 7777
This is java2depth
Please kill my tcp connection

[root@SERVER ~]# tcpdump -i eth1 -nn port 7777
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
05:11:09.690045 IP 172.30.40.108.36952 > 172.30.40.115.7777: Flags [S], seq 2232791160, win 14600, options [mss 1460,sackOK,TS val 1035956014 ecr 0,nop,wscale 7], length 0
05:11:09.691821 IP 172.30.40.115.7777 > 172.30.40.108.36952: Flags [S.], seq 2419664464, ack 2232791161, win 14480, options [mss 1460,sackOK,TS val 601492804 ecr 1035956014,nop,wscale 7], length 0
05:11:09.693889 IP 172.30.40.108.36952 > 172.30.40.115.7777: Flags [.], ack 1, win 115, options [nop,nop,TS val 1035956018 ecr 601492804], length 0
05:11:19.356920 IP 172.30.40.108.36952 > 172.30.40.115.7777: Flags [P.], seq 1:20, ack 1, win 115, options [nop,nop,TS val 1035965681 ecr 601492804], length 19
05:11:19.356999 IP 172.30.40.115.7777 > 172.30.40.108.36952: Flags [.], ack 20, win 114, options [nop,nop,TS val 601502471 ecr 1035965681], length 0
05:11:27.380878 IP 172.30.40.108.36952 > 172.30.40.115.7777: Flags [P.], seq 20:50, ack 1, win 115, options [nop,nop,TS val 1035973705 ecr 601502471], length 30
05:11:27.380970 IP 172.30.40.115.7777 > 172.30.40.108.36952: Flags [.], ack 50, win 114, options [nop,nop,TS val 601510495 ecr 1035973705], length 0
05:11:59.431146 IP 172.30.40.115.7777 > 172.30.40.108.36952: Flags [.], ack 50, win 114, options [nop,nop,TS val 601542545 ecr 1035973705], length 0
05:11:59.436185 IP 172.30.40.115.7777 > 172.30.40.108.36952: Flags [R], seq 2419664465, win 65535, length 0


[root@CLIENT ~]# tcpdump -i eth2 -nn port 7777
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
05:11:09.690406 IP 172.30.40.108.36952 > 172.30.40.115.7777: Flags [S], seq 2232791160, win 14600, options [mss 1460,sackOK,TS val 1035956014 ecr 0,nop,wscale 7], length 0
05:11:09.694213 IP 172.30.40.115.7777 > 172.30.40.108.36952: Flags [S.], seq 2419664464, ack 2232791161, win 14480, options [mss 1460,sackOK,TS val 601492804 ecr 1035956014,nop,wscale 7], length 0
05:11:09.694282 IP 172.30.40.108.36952 > 172.30.40.115.7777: Flags [.], ack 1, win 115, options [nop,nop,TS val 1035956018 ecr 601492804], length 0
05:11:19.357313 IP 172.30.40.108.36952 > 172.30.40.115.7777: Flags [P.], seq 1:20, ack 1, win 115, options [nop,nop,TS val 1035965681 ecr 601492804], length 19
05:11:19.357665 IP 172.30.40.115.7777 > 172.30.40.108.36952: Flags [.], ack 20, win 114, options [nop,nop,TS val 601502471 ecr 1035965681], length 0
05:11:27.381221 IP 172.30.40.108.36952 > 172.30.40.115.7777: Flags [P.], seq 20:50, ack 1, win 115, options [nop,nop,TS val 1035973705 ecr 601502471], length 30
05:11:27.381684 IP 172.30.40.115.7777 > 172.30.40.108.36952: Flags [.], ack 50, win 114, options [nop,nop,TS val 601510495 ecr 1035973705], length 0
05:11:59.431884 IP 172.30.40.115.7777 > 172.30.40.108.36952: Flags [.], ack 50, win 114, options [nop,nop,TS val 601542545 ecr 1035973705], length 0
05:11:59.436855 IP 172.30.40.115.7777 > 172.30.40.108.36952: Flags [R], seq 2419664465, win 65535, length 0


[root@SERVER killcx-1.0.3]# netstat -ntap | grep 7777
tcp        0      0 0.0.0.0:7777                0.0.0.0:*                   LISTEN      26861/nc
tcp        0      0 172.30.40.115:7777          172.30.40.108:36952         ESTABLISHED 26861/nc

[root@SERVER killcx-1.0.3]# ./killcx 172.30.40.108:36952
killcx v1.0.3 - (c)2009-2011 Jerome Bruandet - http://killcx.sourceforge.net/

[PARENT] checking connection with [172.30.40.108:36952]
[PARENT] found connection with [172.30.40.115:7777] (ESTABLISHED)
[PARENT] forking child
[CHILD]  interface not defined, will use [eth1]
[CHILD]  setting up filter to sniff ACK on [eth1] for 5 seconds
[PARENT] sending spoofed SYN to [172.30.40.115:7777] with bogus SeqNum
[CHILD]  hooked ACK from [172.30.40.115:7777]
[CHILD]  found AckNum [2232791210] and SeqNum [2419664465]
[CHILD]  sending spoofed RST to [172.30.40.115:7777] with SeqNum [2232791210]
[CHILD]  sending RST to remote host as well with SeqNum [2419664465]
[CHILD]  all done, sending USR1 signal to parent [26968] and exiting
[PARENT] received child signal, checking results...
         => success : connection has been closed !

Info :

1 comment:

  1. Wow :)
    This is an incredible collection of ideas!
    Waiting for more helpful pieces.
    You would amazing to read a similar one here-
    besttoolsbrand

    ReplyDelete