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
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 :
No comments:
Post a Comment