Replying to SYN with RST,ACK when port is closed. Solutions? [SOLVED]

conn-fused · 2013-01-26 01:08:12

Hi everyone,

Today I ran wireshark and saw that a machine in Russia was sending me TCP packets with the SYN flag set to a closed port (the application that uses it was not running). My machine was happily replying with RST,ACK. I don't think this is standard, and I suspect it's more secure to drop in this case.

So, first the network topology. There's a little SOHO router which forwards the port in question to a desktop. That desktop has an iptables firewall (basically the simple stateful firewall from the wiki, with a rule to accept traffic to this particular port.

When I relocated the closed port (by modifying the router config and the iptables rule), the SYN then RST,ACK pattern stopped. That's not a solution though; I presume SYNs on the new port would be replied to by RST,ACKs too.

So, the thrust of it is: why RST,ACKs and how can I use iptables to stop this behaviour when the application is closed?

Thanks!

Last edited by conn-fused (2013-01-26 10:57:12)

Stebalien · 2013-01-26 03:23:52

That is standard. As a matter of fact, if you don't run a firewall, all ports respond that way and it isn't really a security problem. I don't know of a clean way to drop packets on closed but unfirewalled ports but it may be possible to filter out outgoing reset packets.

Rational for dropping packets:
If you run no internet facing services, dropping packets instead of rejecting them (RST,ACK) allows you to make your machine to appear to be offline to attackers (as long as you block pings etc). If you run services on uncommon (high range) ports, dropping packets on closed ports can make an attacker overlook you as they may not scan the higher ranges. However, if you run services on common ports and most ports drop packets while these ports reject them, you are actually giving information about what services your system runs. So drop on all ports or don't bother.

A long time ago in a city far, far away, I wrote a python script that acted as a on-demand firewall. I make no guarantees.

--edit: fixed link.

Last edited by Stebalien (2013-01-26 05:04:32)

Leonid.I · 2013-01-26 04:36:40

conn-fused wrote:

Hi everyone,
Today I ran wireshark and saw that a machine in Russia was sending me TCP packets with the SYN flag set to a closed port (the application that uses it was not running). My machine was happily replying with RST,ACK. I don't think this is standard, and I suspect it's more secure to drop in this case.
So, first the network topology. There's a little SOHO router which forwards the port in question to a desktop. That desktop has an iptables firewall (basically the simple stateful firewall from the wiki, with a rule to accept traffic to this particular port.
When I relocated the closed port (by modifying the router config and the iptables rule), the SYN then RST,ACK pattern stopped. That's not a solution though; I presume SYNs on the new port would be replied to by RST,ACKs too.
So, the thrust of it is: why RST,ACKs and how can I use iptables to stop this behaviour when the application is closed?
Thanks!

As it was already said, this behavior is standard. I think it is equivalend to using REJECT --reject-with tcp-reset.in an iptables ruleset.

OTOH, plain DROPping packets is not cool because you break lots of legitimate services which will have to timeout instead of moving on. So, it is always better to REJECT packets and DROP only fragmented packets (those which match iptables -f).

There are several solutions under linux which implement a per-application firewall (tc ?) but their common problem is that a packet has to be handed off from the kernel to a userspace daemon. I think the most serious attempt at this is Fedora's firewalld (https://fedoraproject.org/wiki/Firewall … _FirewallD).

EDIT-1: @Stebalien: your link return 404...
EDIT-2: If generality is not important, one can probably implement a dynamic opening/closing of a port in the daemon service file (for each daemon individually). For example, imagine that you have a ruleset in iptables.rules with all ports filtered and use netcfg as a network manager. You order iptables.service before netcfg.service and your daemon after network.target (which is wanted by netcfg.service). Then, in the daemon service file you add ExecStartPre=iptables -I <rulenum> <open a port> and in ExecStopPost=iptables -D <rulenum>... Just a wild idea

Last edited by Leonid.I (2013-01-26 04:44:09)

Stebalien · 2013-01-26 05:14:23

Leonid.I wrote:

OTOH, plain DROPping packets is not cool because you break lots of legitimate services which will have to timeout instead of moving on. So, it is always better to REJECT packets and DROP only fragmented packets (those which match iptables -f).

Legitimate services generally won't attempt to establish an unsolicited (inbound) connection with a PC. When they do, they must assume that the connection will time out because the PC in question may not even be online.

conn-fused · 2013-01-26 10:56:39

Thanks to both of you. This has been both informative and reasuring.

I'll mark the thread solved and have a look at Stebalian's code tomorrow. Cheers.

Arch Linux

#1 2013-01-26 01:08:12

Replying to SYN with RST,ACK when port is closed. Solutions? [SOLVED]

#2 2013-01-26 03:23:52

Re: Replying to SYN with RST,ACK when port is closed. Solutions? [SOLVED]

#3 2013-01-26 04:36:40

Re: Replying to SYN with RST,ACK when port is closed. Solutions? [SOLVED]

#4 2013-01-26 05:14:23

Re: Replying to SYN with RST,ACK when port is closed. Solutions? [SOLVED]

#5 2013-01-26 10:56:39

Re: Replying to SYN with RST,ACK when port is closed. Solutions? [SOLVED]

Board footer