You are not logged in.

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

conn-fused
Member
Registered: 2011-06-19
Posts: 27

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

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)

Offline

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

Stebalien
Member
Registered: 2010-04-27
Posts: 1,227
Website

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

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)


Steven [ web : git ]
GPG:  327B 20CE 21EA 68CF A7748675 7C92 3221 5899 410C
Do not email: honeypot@stebalien.com

Offline

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

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 948

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

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 smile

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


Arch Linux is more than just GNU/Linux -- it's an adventure

Offline

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

Stebalien
Member
Registered: 2010-04-27
Posts: 1,227
Website

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

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.


Steven [ web : git ]
GPG:  327B 20CE 21EA 68CF A7748675 7C92 3221 5899 410C
Do not email: honeypot@stebalien.com

Offline

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

conn-fused
Member
Registered: 2011-06-19
Posts: 27

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

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.

Offline

Board footer

Powered by FluxBB