Print-friendly Version

A Tool to Drop TCP Sessions for the Solaris OS: tcpdrop

Ceri Davies, February 2007

Abstract

I ported tcpdrop from the BSD projects, which allows an administrator to easily drop any TCP connection without harmful effects elsewhere. This Tech Tip outlines the use of tcpdrop for the Solaris Operating System. This was tested on Solaris releases 8, 9, and 10.

Introduction

Imagine that, for whatever reason, you wish to kick a remote client off your Solaris OS host. Perhaps you believe that the connection is causing a resource issue, or you might be debugging an application's reaction to sudden disconnects.

If a user is logged in over Secure Shell (SSH), then it's relatively simple to identify and kill the user's shell and the associated sshd(1M) process. However, if you're dealing with a shared server process, such as a database dispatcher or a threaded web server, it can be more difficult or even impossible to ensure that killing a process does not affect other clients. If your application does not provide a means to disconnect client sessions, then you need to perform some action at the network level in order to drop that client's connection.

Identifying the Victim

An established TCP socket can be uniquely identified by the following quadruple:

  {local IP address, local port, remote IP address, remote port}

You can, therefore, use a tool such as netstat(1M) to uniquely identify the connection that you wish to drop. For example, if you want to drop a TCP connection from 192.168.4.25, which is connected to a web server on 172.20.3.75, you can identify the port numbers like this:

# netstat -n -Ptcp | egrep 172.20.3.75.\*192.168.4.25
  172.20.3.75.80  192.168.4.25.33062  49640  0  49640  0 ESTABLISHED

The output shows an established TCP connection to port 80 on IP address 172.20.3.75 from port 33062 on IP address 192.168.4.25, giving a quadruple of {172.20.3.75, 80, 192.168.4.25, 33062}, which uniquely identifies this TCP connection.

Null Routes

One popular method of dropping IP traffic is to null route, or black hole, the remote machine. With the remote machine from the previous example, 192.168.4.25, the following command would cause all IP traffic to be dropped:

# route add -host 192.168.4.25 127.0.0.1 -blackhole

Now, replies generated by the host cannot reach the client, and the TCP session eventually times out. Note, however, that some packets from the client might still be processed by the application.

One downside to this approach is that it has black holed all traffic from the remote IP address. The black hole has very likely caused some collateral damage if the remote machine is one of these:

• A multiuser host
• The other end of a connection pool using Java DataBase Connectivity (JDBC) technology
• The provider of any service to the local machine

Firewalling

The IP Filter packet filter distributed with the Solaris 10 OS allows a finer grain of selectivity when discarding traffic. You can build a rule that drops a particular connection using the following template. (This should all be on one line.)

   block return-rst in quick proto tcp from /remote_addr/ port = \
 /remote_port/ to /local_addr/ port = /local_port/

Assuming you have the same previously established connection, plugging in the values yields the following:

  block return-rst in quick proto tcp from 192.168.4.25 port = 33062 to 172.20.3.75 port = 80

This method has the advantage of blocking only the connection that you wish to block. However, this rule must now be prepended to the head of /etc/ipf/ipf.conf and the IP Filter service must be restarted using the following command:

svcadm restart ipfilter

If there is enough traffic between the hosts, then the quadruple eventually gets recycled. So when the connection times out, you need to remove the line from /etc/ipf/ipf.conf and restart the service again. What's more, if there is a lot of legitimate traffic between these two hosts, then the quadruple could be recycled rather quickly, and failing to remove the entry soon enough could cause a connection to stall or fail.

The tcpdrop Utility

While working on a security fix for a TCP packet ordering problem, Markus Friedl of the OpenBSD project found that he was having to go to some lengths in order to drop TCP connections. Although there are, of course, methods other than the ones covered previously, Markus decided that his life would be easier if he wrote a tool that would take a quadruple and have the OpenBSD kernel drop the connection. That tool, tcpdrop, was quickly ported to FreeBSD and has been available to administrators of these systems for over two years.

An example of using tcpdrop to drop the previous example connection is simple:

  # tcpdrop 172.20.3.75 80 192.168.4.25 33062
  172.20.3.75 80 192.168.4.25 33062: dropped

The connection is instantly dropped, and there is no ill effect on new connections or on already established connections from the same host.

Solaris administrators have had to make do without this tool. In a recent discussion on the Usenet group comp.unix.solaris, however, it was pointed out that the Solaris OS contains an undocumented kernel interface that could be used to perform the same function. A port of tcpdrop was swiftly performed and is now available from typo.submonkey.net.

Note: Since the kernel interface is undocumented, this tool is liable to stop working or to break in future versions of the Solaris OS.

About the Author

Ceri Davies (ceri [at] submonkey.net) is a UNIX systems administrator for a Welsh university and a FreeBSD developer.

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.