Breaking a TCP connection

[Skaperen]

is there a tool that i could use (via sudo) that can force drop a TCP connection (or SCTP session) based on knowing the 2 addresses and ports it is working on (that can be seen in netstat or tcpdump)?

[Doug S]

You could use iptables to force a DROP:

sudo iptables -I INPUT 1 -s 100.101.102.103 -i enp4s0 -j DROP

And actually, I do this on my system often. If you have an existing iptables rules set, or an UFW generated iptables rule set, you will have to determine the correct place to put the rule. On my system, I usually do it as INPUT rule 26:

sudo iptables -I INPUT 26 -s 100.101.102.103 -i enp4s0 -j DROP

And note also, for attacks, in recent years they (China mainly) just switch to another IP address on the same sub-net, so I look up the sub-net mask and block the entire subnet:

sudo iptables -I INPUT 26 -s 45.114.8.0/22 -i enp4s0 -j DROP

Of course, I also edit my master file so that the rules will be there after re-boots.

[Skaperen]

isn't that just a rule to drop packets and prevent traffic? i have an existing connection that is already established that the peer is no longer sending anything on. i do not want to signal or kill the local process as that will be ungraceful and lose data. instead i wand to process to act as if the connect was closed. also, the Linux box is just the router. the process on the local end is on another box. so i would need to send a TCP RST with the right sequence number. but i recall reading, a couple years ago, about a program that could do this.

[1fallen]

Would something like this be satisfactory?
Closing a socket in a running process is not impossible but it is difficult: https://superuser.com/questions/1278.../668155#668155

[The Cog]

Yes, that rule just drops the packets. Better might be to use -j REJECT which actively closes the connection in response to a packet. I'm not sure now if it sends ICMP unreachable or whether it sends a RST though. And TCP connections that are idle with no keepalive would never discover that the path was no longer working, so wouldn't close.

Anyway, it probably won't work on an existing connections because most firewall rule sets have an early rule that allows existing connections through (permit ESTABLISHED). This saves every packet having to pass through all the filter tests. Only the initial connection setup goes through all the filter rules. So after adding the new rule you would also have to use the conntrack command to remove that connection from the connection tracking table.

There almost certainly are programs that can send a RST to a specified addr+port pair, but I don't know what they are. I suspect that you don't have to give a good sequence number in a RST packet, but haven't checked. ddg found this for me: http://www.ubuntugeek.com/sendip-too...p-packets.html

[Doug S]

Anyway, it probably won't work on an existing connections because most firewall rule sets have an early rule that allows existing connections through (permit ESTABLISHED). This saves every packet having to pass through all the filter tests. Only the initial connection setup goes through all the filter rules. So after adding the new rule you would also have to use the conntrack command to remove that connection from the connection tracking table.

If you put the rule before the typical REALATED,ESTABLISHED rule, it'll drop any packets from the IP, regardless. Chains that are only traversed once for NEW connections are, for example the nat PREROUTING chain, but the INPUT chain is traversed for every packet that gets to the INPUT chain.

The connection tracking table only exists if you already have some itpbales rules that require it. Then yes, it is trivial to drop that existing connection.

EDIT: Oh, I see the OPs box is a router. Then it is likely that the nat PREROUTEING chain is being used.

[kpatz]

...i do not want to signal or kill the local process as that will be ungraceful and lose data....

What is the local process? Many will close gracefully on a SIGTERM signal, and disconnect the connection cleanly. SIGHUP may also close cleanly depending on the application. Of course using SIGKILL (-9) will force an unclean shutdown.

[The Cog]

Good point. Just make sure the rule is above the RELATED rule. And on looking back, you used -I not -A. My bad.

[Skaperen]

right, this is the router i am doing this from. and there are no packets being sent in either direction.

[Doug S]

i have an existing connection that is already established that the peer is no longer sending anything on. i do not want to signal or kill the local process as that will be ungraceful and lose data. instead i wand to process to act as if the connect was closed. also, the Linux box is just the router. the process on the local end is on another box. so i would need to send a TCP RST with the right sequence number. but i recall reading, a couple years ago, about a program that could do this.

Already installed on one of my computers is "hping3", which can send almost what you want, but I don't know the proper sequence number to provide:

$ sudo hping3 --count 1 --spoof 192.168.111.1 --baseport 51086 --destport 22 --rst 192.168.111.120

But it has no effect:

doug@s17:~$ sudo tcpdump -n -tttt -i ens5 not host 192.168.111.101
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens5, link-type EN10MB (Ethernet), capture size 262144 bytes
2019-06-28 11:59:18.775302 IP 192.168.111.1.51086 > 192.168.111.120.22: Flags [P.], seq 2280786151:2280786187, ack 1881387854, win 296, options [nop,nop,TS val 550886439 ecr 2632743252], length 36
2019-06-28 11:59:18.776225 IP 192.168.111.120.22 > 192.168.111.1.51086: Flags [P.], seq 1:69, ack 36, win 312, options [nop,nop,TS val 2632833224 ecr 550886439], length 68
2019-06-28 11:59:18.776462 IP 192.168.111.1.51086 > 192.168.111.120.22: Flags [.], ack 69, win 296, options [nop,nop,TS val 550886439 ecr 2632833224], length 0
2019-06-28 11:59:19.232814 IP 192.168.111.1.51086 > 192.168.111.120.22: Flags [P.], seq 36:72, ack 69, win 296, options [nop,nop,TS val 550886554 ecr 2632833224], length 36
2019-06-28 11:59:19.233147 IP 192.168.111.120.22 > 192.168.111.1.51086: Flags [P.], seq 69:105, ack 72, win 312, options [nop,nop,TS val 2632833681 ecr 550886554], length 36
2019-06-28 11:59:19.233377 IP 192.168.111.1.51086 > 192.168.111.120.22: Flags [.], ack 105, win 296, options [nop,nop,TS val 550886554 ecr 2632833681], length 0
2019-06-28 11:59:19.233392 IP 192.168.111.120.22 > 192.168.111.1.51086: Flags [P.], seq 105:173, ack 72, win 312, options [nop,nop,TS val 2632833681 ecr 550886554], length 68
2019-06-28 11:59:19.233604 IP 192.168.111.1.51086 > 192.168.111.120.22: Flags [.], ack 173, win 296, options [nop,nop,TS val 550886554 ecr 2632833681], length 0
2019-06-28 11:59:33.652957 IP 192.168.111.1.51086 > 192.168.111.120.22: Flags [R], seq 1992732150, win 512, length 0
2019-06-28 12:08:00.901149 IP 192.168.111.1.51086 > 192.168.111.120.22: Flags [P.], seq 2280786223:2280786259, ack 1881388026, win 296, options [nop,nop,TS val 551016971 ecr 2632833681], length 36
2019-06-28 12:08:00.902129 IP 192.168.111.120.22 > 192.168.111.1.51086: Flags [P.], seq 1:69, ack 36, win 312, options [nop,nop,TS val 2633355350 ecr 551016971], length 68
2019-06-28 12:08:00.902353 IP 192.168.111.1.51086 > 192.168.111.120.22: Flags [.], ack 69, win 296, options [nop,nop,TS val 551016971 ecr 2633355350], length 0

doug@DOUG-64:~$ sudo conntrack -L | grep "192\.168\.111\.120"
tcp      6 35853 ESTABLISHED src=192.168.111.1 dst=192.168.111.120 sport=51086 dport=22 src=192.168.111.120 dst=192.168.111.1 sport=22 dport=51086 [ASSURED] mark=0 use=1
conntrack v1.4.3 (conntrack-tools): 49 flow entries have been shown.