Iptables Reject with TCP Reset

Iptables Reject with TCP Reset

[Matt Killock]

Hi

We are using linux iptables on a firewall device to block all traffic from internal hosts except for a few exceptions with a default FORWARD policy of DROP. So there is no general HTTP/HTTPS access. This all works fine except that various applications like Microsoft Word and Adobe Reader all attempt to connect to various internet hosts and introduce delays that are not there if there is general access. Adobe refuses to display PDF content for 30 seconds whilst it attempts to connect to various cloud services. I can reduce this delay to 5 seconds if I add all the hostnames it attempts to connect to in the hosts file to point to 127.0.0.1.

What I'd like to do is make the firewall respond with a TCP Reset packet instead of doing nothing or only sending an ICMP unreachable packet, which I presume is what happens when Adobe attempts to connect to 127.0.0.1 on port 80

The following line does not do this - does this no longer work?

iptables -A FORWARD -s 192.168.40.0/24 -d 0/0 -p tcp --dport 80 -j REJECT --reject-with tcp-reset

Thanks

Matt

________________________________

Plum Software is a fully owned subsidiary of Praemium Limited.

This e-mail is confidential. It may also be legally privileged. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return email. Internet communications cannot be guaranteed to be timely, secure, or error or virus free. The sender does not accept liability for any errors or omissions.

In the UK the Praemium Group is: Praemium Portfolio Services Ltd (Company Number: 05362168), Praemium (UK) Ltd (Company Number: 05362153), Praemium Administration Ltd (Company Number: 06016828) and Smartfund Nominees Ltd (Company Number: 07153417) each having its registered office at 4th Floor, Suite 643-659, Salisbury House, London Wall, London, EC2M 5QQ, United Kingdom. Praemium Administration Ltd is authorised and regulated by the Financial Conduct Authority under reference 463566. See http://www.fca.org.uk/register for more details.

In Jersey the Praemium Group is: Praemium International Ltd (Company Number: 107624) which has its registered office at 3rd Floor East, Salisbury House, 1-9 Union Street, St Helier, JE2 3RF and is regulated under the Financial Service (Jersey) Law 1998 by the Jersey Financial Services Commission for the conduct of investment business in Jersey. See http://www.jerseyfsc.org for more details.

Thank you for your cooperation. Please contact us on +44 (0)207 5622 450 if you require assistance.

Re: Iptables Reject with TCP Reset

[Noel Kuntze]

[-- Attachment #1.1: Type: text/plain, Size: 442 bytes --]

On 06.01.2017 16:19, Matt Killock wrote:
> The following line does not do this - does this no longer work?
> 
> iptables -A FORWARD -s 192.168.40.0/24 -d 0/0 -p tcp --dport 80 -j REJECT --reject-with tcp-reset
Depends on your rule set. Check and fix it. The target usually works.

-- 

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 866 bytes --]

RE: Iptables Reject with TCP Reset

[Matt Killock]

> Depends on your rule set. Check and fix it. The target usually works.

As a test, I made the very first FORWARD rule this:

iptables -A FORWARD -i eth1 -p tcp -s 192.168.20.0/24 -d 212.58.244.71 --dport 80 -j REJECT --reject-with tcp-reset

'iptables -n -L' output:

Chain FORWARD (policy DROP)
target     prot opt source               destination
REJECT     tcp  --  192.168.20.0/24      212.58.244.71        tcp dpt:80 reject-with tcp-reset


However, no Reset packets can be observed:

# tcpdump -ni eth1 host 192.168.20.164
16:23:00.706667 IP 192.168.20.164.50105 > 212.58.244.71.80: Flags [SEW], seq 2763730948, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
16:23:02.717733 IP 192.168.20.164.50106 > 212.58.244.71.80: Flags [SEW], seq 2464499683, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

If this does usually work then could you give me a clue on what ruleset it does work with?

Thanks

Matt

________________________________

Plum Software is a fully owned subsidiary of Praemium Limited.

This e-mail is confidential. It may also be legally privileged. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return email. Internet communications cannot be guaranteed to be timely, secure, or error or virus free. The sender does not accept liability for any errors or omissions.

In the UK the Praemium Group is: Praemium Portfolio Services Ltd (Company Number: 05362168), Praemium (UK) Ltd (Company Number: 05362153), Praemium Administration Ltd (Company Number: 06016828) and Smartfund Nominees Ltd (Company Number: 07153417) each having its registered office at 4th Floor, Suite 643-659, Salisbury House, London Wall, London, EC2M 5QQ, United Kingdom. Praemium Administration Ltd is authorised and regulated by the Financial Conduct Authority under reference 463566. See http://www.fca.org.uk/register for more details.

In Jersey the Praemium Group is: Praemium International Ltd (Company Number: 107624) which has its registered office at 3rd Floor East, Salisbury House, 1-9 Union Street, St Helier, JE2 3RF and is regulated under the Financial Service (Jersey) Law 1998 by the Jersey Financial Services Commission for the conduct of investment business in Jersey. See http://www.jerseyfsc.org for more details.

Thank you for your cooperation. Please contact us on +44 (0)207 5622 450 if you require assistance.

Re: Iptables Reject with TCP Reset

[Noel Kuntze]

[-- Attachment #1.1: Type: text/plain, Size: 481 bytes --]

On 06.01.2017 17:28, Matt Killock wrote:
> 'iptables -n -L' output:
Please use and show the output of `iptables-save -c`.


> If this does usually work then could you give me a clue on what ruleset it does work with?
Generally in any. If it doesn't work and your rule set is not to blame, you've got another problem.

-- 

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 866 bytes --]

Re: Iptables Reject with TCP Reset

[Noel Kuntze]

[-- Attachment #1.1: Type: text/plain, Size: 1842 bytes --]

On 06.01.2017 17:44, Matt Killock wrote:
> My server has unusual interface names, so I changed them before.
> 
> root@aspfw2:~# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 0.0.0.0         192.168.0.254   0.0.0.0         UG    0      0        0 enp2s12f0
> 192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp2s12f0
> 192.168.20.0    0.0.0.0         255.255.255.0   U     0      0        0 enp2s12f1
> 192.168.40.0    0.0.0.0         255.255.255.0   U     0      0        0 enp6s7


Use iproute2. Don't use the net-tools. They're unmaintained, less powerful and lie.

> [4:208] -A FORWARD -s 192.168.20.0/24 -d 212.58.244.71/32 -i enp2s12f1 -p tcp -m tcp --dport 80 -j REJECT --reject-with tcp-reset
The rule is hit.

Your rule set is absolutely broken, because you don't permit ctstate RELATED
and at the same time, it's unnecessarily convoluted unstructered.

You need to permit it to allow ICMP errors through and the TCP reset packets.

I advise to rewrite the complete rule set. You should start by taking this example
rule set for edge-routers, understanding the different components and rewriting your current one based of
the example. You are strongly encouraged to filter traffic based on ctstates. Use the conntrack module
instead of the state module. It is more powerful.

Please use the documents at [2] and [3] to improve your rule set.


[1] https://github.com/QueuingKoala/netfilter-samples/tree/master/rules-edge-router
[2] http://sfvlug.editthis.info/wiki/Things_You_Should_Know_About_Netfilter
[3] http://inai.de/images/nf-packet-flow.png

-- 

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 866 bytes --]

RE: Iptables Reject with TCP Reset

[Matt Killock]

Thanks for your response.

> Use iproute2. Don't use the net-tools. They're unmaintained, less powerful and lie.

I do use iproute2 - for our multi-homed edge router, where it's needed. In this case, I wanted a list of interfaces, and I can see that the output was not a 'lie', so as a tool for that job, it's fine.

>Your rule set is absolutely broken, because you don't permit ctstate RELATED and at the same time, it's unnecessarily convoluted unstructered.

I note you dislike our ruleset, and I have no intention of rewriting the whole thing, especially as the examples in links you provide allow all outbound traffic from internal hosts. We want to block all outbound traffic except on a very limited range of host / port combinations. I accept that we may not have gone about that in an entirely modern or simplest manner possible, but it is far from 'absolutely' broken.

However, you did manage to tell me what I need to know, which is that I needed a RELATED rule in there. After a bit of experimentation, I discovered that I need a rule like this:

iptables -A OUTPUT -o eth1 -p tcp -d 192.168.40.0/24 -m state --state RELATED -j ACCEPT

That fixes this problem, thank you.

Matt

________________________________

Plum Software is a fully owned subsidiary of Praemium Limited.

This e-mail is confidential. It may also be legally privileged. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return email. Internet communications cannot be guaranteed to be timely, secure, or error or virus free. The sender does not accept liability for any errors or omissions.

In the UK the Praemium Group is: Praemium Portfolio Services Ltd (Company Number: 05362168), Praemium (UK) Ltd (Company Number: 05362153), Praemium Administration Ltd (Company Number: 06016828) and Smartfund Nominees Ltd (Company Number: 07153417) each having its registered office at 4th Floor, Suite 643-659, Salisbury House, London Wall, London, EC2M 5QQ, United Kingdom. Praemium Administration Ltd is authorised and regulated by the Financial Conduct Authority under reference 463566. See http://www.fca.org.uk/register for more details.

In Jersey the Praemium Group is: Praemium International Ltd (Company Number: 107624) which has its registered office at 3rd Floor East, Salisbury House, 1-9 Union Street, St Helier, JE2 3RF and is regulated under the Financial Service (Jersey) Law 1998 by the Jersey Financial Services Commission for the conduct of investment business in Jersey. See http://www.jerseyfsc.org for more details.

Thank you for your cooperation. Please contact us on +44 (0)207 5622 450 if you require assistance.

RE: Iptables Reject with TCP Reset

[André Paulsberg-Csibi (IBM Consultant)]

The rule you made here makes little sense , It would be preferable to make a more simple rule at "the top" like this ...

iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
or
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

This will allow "all" traffic for rules you have already allowed through other rules in the FW ( no matter the IP or interface ) .


Best regards
André Paulsberg-Csibi
Senior Network Engineer 
Fault Handling
IBM Services AS




-----Original Message-----
From: netfilter-owner@vger.kernel.org [mailto:netfilter-owner@vger.kernel.org] On Behalf Of Matt Killock
Sent: 9. januar 2017 11:46
To: Noel Kuntze <noel@familie-kuntze.de>; netfilter@vger.kernel.org
Subject: RE: Iptables Reject with TCP Reset

Thanks for your response.

> Use iproute2. Don't use the net-tools. They're unmaintained, less powerful and lie.

I do use iproute2 - for our multi-homed edge router, where it's needed. In this case, I wanted a list of interfaces, and I can see that the output was not a 'lie', so as a tool for that job, it's fine.

>Your rule set is absolutely broken, because you don't permit ctstate RELATED and at the same time, it's unnecessarily convoluted unstructered.

I note you dislike our ruleset, and I have no intention of rewriting the whole thing, especially as the examples in links you provide allow all outbound traffic from internal hosts. We want to block all outbound traffic except on a very limited range of host / port combinations. I accept that we may not have gone about that in an entirely modern or simplest manner possible, but it is far from 'absolutely' broken.

However, you did manage to tell me what I need to know, which is that I needed a RELATED rule in there. After a bit of experimentation, I discovered that I need a rule like this:

iptables -A OUTPUT -o eth1 -p tcp -d 192.168.40.0/24 -m state --state RELATED -j ACCEPT

That fixes this problem, thank you.

Matt

________________________________

Plum Software is a fully owned subsidiary of Praemium Limited.

This e-mail is confidential. It may also be legally privileged. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return email. Internet communications cannot be guaranteed to be timely, secure, or error or virus free. The sender does not accept liability for any errors or omissions.

In the UK the Praemium Group is: Praemium Portfolio Services Ltd (Company Number: 05362168), Praemium (UK) Ltd (Company Number: 05362153), Praemium Administration Ltd (Company Number: 06016828) and Smartfund Nominees Ltd (Company Number: 07153417) each having its registered office at 4th Floor, Suite 643-659, Salisbury House, London Wall, London, EC2M 5QQ, United Kingdom. Praemium Administration Ltd is authorised and regulated by the Financial Conduct Authority under reference 463566. See http://www.fca.org.uk/register for more details.

In Jersey the Praemium Group is: Praemium International Ltd (Company Number: 107624) which has its registered office at 3rd Floor East, Salisbury House, 1-9 Union Street, St Helier, JE2 3RF and is regulated under the Financial Service (Jersey) Law 1998 by the Jersey Financial Services Commission for the conduct of investment business in Jersey. See http://www.jerseyfsc.org for more details.

Thank you for your cooperation. Please contact us on +44 (0)207 5622 450 if you require assistance.
\x13��칻\x1c�&�~�&�\x18��+-��ݶ\x17��w��˛���m�޵������^n�r���z�\x1a��h����&��\x1e�G���h�\x03(�階�ݢj"��\x1a�^[m�����z�ޖ���f���h���~�m�

RE: Iptables Reject with TCP Reset

[Matt Killock]

> The rule you made here makes little sense , It would be preferable to make a more simple rule at "the top" like this ...
>
> This will allow "all" traffic for rules you have already allowed through other rules in the FW ( no matter the IP or interface ) .

I note that it would be simpler to have one such rule for RELATED,ESTABLISHED but that's not the way we've done things here, much to Noel's disgust. :)

We've blocked everything, including OUTPUT, by default. There are no general SNAT rules or MASQUERADE. We've tried to allow only the bare minimum required for two-way traffic between a small set of host/port combinations. This has led to some unnecessary duplication of ESTABLISHED rules, and I didn't appreciate that RELATED traffic is what the 'REJECT with TCP-Reset' traffic is classed as but otherwise it makes (some) sense and does work.

Kind regards
Matt

________________________________

Plum Software is a fully owned subsidiary of Praemium Limited.

This e-mail is confidential. It may also be legally privileged. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return email. Internet communications cannot be guaranteed to be timely, secure, or error or virus free. The sender does not accept liability for any errors or omissions.

In the UK the Praemium Group is: Praemium Portfolio Services Ltd (Company Number: 05362168), Praemium (UK) Ltd (Company Number: 05362153), Praemium Administration Ltd (Company Number: 06016828) and Smartfund Nominees Ltd (Company Number: 07153417) each having its registered office at 4th Floor, Suite 643-659, Salisbury House, London Wall, London, EC2M 5QQ, United Kingdom. Praemium Administration Ltd is authorised and regulated by the Financial Conduct Authority under reference 463566. See http://www.fca.org.uk/register for more details.

In Jersey the Praemium Group is: Praemium International Ltd (Company Number: 107624) which has its registered office at 3rd Floor East, Salisbury House, 1-9 Union Street, St Helier, JE2 3RF and is regulated under the Financial Service (Jersey) Law 1998 by the Jersey Financial Services Commission for the conduct of investment business in Jersey. See http://www.jerseyfsc.org for more details.

Thank you for your cooperation. Please contact us on +44 (0)207 5622 450 if you require assistance.

RE: Iptables Reject with TCP Reset

[André Paulsberg-Csibi (IBM Consultant)]

TCP-RESET would typically be "ESTABLISHED" as that would be a normal part of a TCP session ,
In IPTABLES it might be that an EARLY TCP-RESET could be "RELATED" but I do not think so .

"RELATED" is typically ICMP responses from systems in the path that are response to a TCP session that for some reason no longer is "reachable" ,
as this is not part of the TCP session directly it would not be in the conntrack table and
IPTABLES would need to look at the DATA in the ICMP to see if that is RELATED to any active session .

"RELATED" could also be sessions inspected with FTP or other protocols , where a NEW TCP session is created which can be inspected
in the uncrypted FTP session on the primary FTP port of 21 and then RELATED as it is created if proper modules are used .

Using "RELATED" is mostly safer and preferable instead of opening manually for ICMP TYPE 3 , TYPE 4 and TYPE 11 
( and all other types that may be needed to have correct and stable TCP/IP connectivity )


Best regards
André Paulsberg-Csibi
Senior Network Engineer 
Fault Handling
IBM Services AS



-----Original Message-----
From: Matt Killock [mailto:matt.killock@praemium.com] 
Sent: 10. januar 2017 11:10
To: André Paulsberg-Csibi (IBM Consultant) <Andre.Paulsberg-Csibi@evry.com>; Noel Kuntze <noel@familie-kuntze.de>; netfilter@vger.kernel.org
Subject: RE: Iptables Reject with TCP Reset

> The rule you made here makes little sense , It would be preferable to make a more simple rule at "the top" like this ...
>
> This will allow "all" traffic for rules you have already allowed through other rules in the FW ( no matter the IP or interface ) .

I note that it would be simpler to have one such rule for RELATED,ESTABLISHED but that's not the way we've done things here, much to Noel's disgust. :)

We've blocked everything, including OUTPUT, by default. There are no general SNAT rules or MASQUERADE. We've tried to allow only the bare minimum required for two-way traffic between a small set of host/port combinations. This has led to some unnecessary duplication of ESTABLISHED rules, and I didn't appreciate that RELATED traffic is what the 'REJECT with TCP-Reset' traffic is classed as but otherwise it makes (some) sense and does work.

Kind regards
Matt

________________________________

Plum Software is a fully owned subsidiary of Praemium Limited.

This e-mail is confidential. It may also be legally privileged. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return email. Internet communications cannot be guaranteed to be timely, secure, or error or virus free. The sender does not accept liability for any errors or omissions.

In the UK the Praemium Group is: Praemium Portfolio Services Ltd (Company Number: 05362168), Praemium (UK) Ltd (Company Number: 05362153), Praemium Administration Ltd (Company Number: 06016828) and Smartfund Nominees Ltd (Company Number: 07153417) each having its registered office at 4th Floor, Suite 643-659, Salisbury House, London Wall, London, EC2M 5QQ, United Kingdom. Praemium Administration Ltd is authorised and regulated by the Financial Conduct Authority under reference 463566. See http://www.fca.org.uk/register for more details.

In Jersey the Praemium Group is: Praemium International Ltd (Company Number: 107624) which has its registered office at 3rd Floor East, Salisbury House, 1-9 Union Street, St Helier, JE2 3RF and is regulated under the Financial Service (Jersey) Law 1998 by the Jersey Financial Services Commission for the conduct of investment business in Jersey. See http://www.jerseyfsc.org for more details.

Thank you for your cooperation. Please contact us on +44 (0)207 5622 450 if you require assistance.

Re: Iptables Reject with TCP Reset

[Neal P. Murphy]

On Tue, 10 Jan 2017 10:09:55 +0000
Matt Killock <matt.killock@praemium.com> wrote:

> > The rule you made here makes little sense , It would be preferable to make a more simple rule at "the top" like this ...
> >
> > This will allow "all" traffic for rules you have already allowed through other rules in the FW ( no matter the IP or interface ) .
> 
> I note that it would be simpler to have one such rule for RELATED,ESTABLISHED but that's not the way we've done things here, much to Noel's disgust. :)
> 
> We've blocked everything, including OUTPUT, by default. There are no general SNAT rules or MASQUERADE. We've tried to allow only the bare minimum required for two-way traffic between a small set of host/port combinations. This has led to some unnecessary duplication of ESTABLISHED rules, and I didn't appreciate that RELATED traffic is what the 'REJECT with TCP-Reset' traffic is classed as but otherwise it makes (some) sense and does work.

This doesn't make much sense. A RELATED packet is the first packet of a new conn that a helper has determined is related to an existing conn (e.g., the data conn of an FTP control session). Once a RELATED packet is replied to, the resulting conn is an ordinary, vanilla ESTABLISHED conn; specifically, the RELATED 'tag' is discarded. When a packet matches a "REJECT with TCP-Reset" rule, netfilter immediately sends a TCP RESET to the end that sent the packet.

It may be that TCP RESET applies to the first TCP SYN packet of a conn. But RESETting only established TCP conns and using ICMP 'admin prohibited' for all other packets works well and is logical.

It almost sounds like you built a nearly stateless firewall.

A rule near the top that allows packets for ESTABLISHED,RELATED conns to pass is more efficient, and is probably significantly more-so on a busy router because *most* packets will be associated with established conns and should be handled without needlessly passing them through all the 'new conn' checks.

Re: Iptables Reject with TCP Reset

[Matt Killock]

> This doesn't make much sense. A RELATED packet is the first packet of
> a new conn that a helper has determined is related to an existing conn
> (e.g., the data conn of an FTP control session). Once a RELATED packet
> is replied to, the resulting conn is an ordinary, vanilla ESTABLISHED
> conn; specifically, the RELATED 'tag' is discarded. When a packet
> matches a "REJECT with TCP-Reset" rule, netfilter immediately sends a
> TCP RESET to the end that sent the packet.

Sounds nice in theory, but reality bites back. RELATED also applies to 
the TCP Reset packets to SYN packets.

I just tried this at home to confirm my findings.

Please review the below firewall script. It does not send the TCP RST 
packets unless you make one minor change: To add 'RELATED,' to the line 
underneath '#General State Matching'

Please note that it has the single state matching lines as recommended 
by various others on this list.





> It almost sounds like you built a nearly stateless firewall.

It's more or less like the below but duplicates ESTABLISHED everywhere

------------------------------

A='/sbin/iptables'
EXIF='ppp0'
LANIF='eth1'

#Clear
$A -F
$A -F INPUT
$A -F OUTPUT
$A -F FORWARD
$A -F -t mangle
$A -F -t nat
$A -X

#Setup policies
$A -P INPUT DROP
$A -P OUTPUT DROP
$A -P FORWARD DROP

echo "1" > /proc/sys/net/ipv4/ip_forward

# Some basics
# Accept loopback interface
$A -A INPUT -i lo -j ACCEPT
A='/sbin/iptables'
EXIF='ppp0'
LANIF='eth1'

#Clear
$A -F
$A -F INPUT
$A -F OUTPUT
$A -F FORWARD
$A -F -t mangle
$A -F -t nat
$A -X

#Setup policies
$A -P INPUT DROP
$A -P OUTPUT DROP
$A -P FORWARD DROP

echo "1" > /proc/sys/net/ipv4/ip_forward

# Some basics
# Accept loopback interface
$A -A INPUT -i lo -j ACCEPT
$A -A OUTPUT -o lo -j ACCEPT

# SSH from LAN
$A -A INPUT -i $LANIF -p tcp --dport 22 -j ACCEPT

#general NAT
$A -t nat -A POSTROUTING -o $EXIF -j MASQUERADE

#General State Matching
$A -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
$A -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

#Allowed HTTP/HTTPS Sites
#bbc
$A -A FORWARD -i $LANIF -o $EXIF -d 212.58.244.22 -p tcp -m multiport 
--dports '80,443' -j ACCEPT

#Send RST to LAN for all other 80/443 connections
$A -A FORWARD -i $LANIF -p tcp -m multiport --dports '80,443' -j REJECT 
--reject-with tcp-reset


--------------------



Matt

RE: Iptables Reject with TCP Reset

[André Paulsberg-Csibi (IBM Consultant)]

After your mail now I am prudent to test this more thou

I have somewhat verified in a test FW that you do not need RELATED rule for the IPTABLES to be allowed to generate a TCP RST packet internally .

From what you sent me directly , you also allowed this in the OUTPUT chain which makes no sense to me ...
... but it maybe that the rules set has somehow been "broken" and it is now causing un-intended packet handling .

I will try to change my OUTPUT rules to LOG any output that is regarded as RELATED with full options ,
That will not change anything in the FW rules itself just add a LOG entry at the start of the OUTPUT chain to see if
TCP RST generated inside the IPTABLES FORWARD chain has to pass the OUTPUT chain at any time ...


Best regards
André Paulsberg-Csibi
Senior Network Engineer 
Fault Handling
IBM Services AS


-----Original Message-----
From: netfilter-owner@vger.kernel.org [mailto:netfilter-owner@vger.kernel.org] On Behalf Of Matt Killock
Sent: 10. januar 2017 20:30
To: Neal P. Murphy <neal.p.murphy@alum.wpi.edu>
Cc: netfilter@vger.kernel.org; netfilter-owner@vger.kernel.org
Subject: Re: Iptables Reject with TCP Reset

> This doesn't make much sense. A RELATED packet is the first packet of
> a new conn that a helper has determined is related to an existing conn
> (e.g., the data conn of an FTP control session). Once a RELATED packet
> is replied to, the resulting conn is an ordinary, vanilla ESTABLISHED
> conn; specifically, the RELATED 'tag' is discarded. When a packet
> matches a "REJECT with TCP-Reset" rule, netfilter immediately sends a
> TCP RESET to the end that sent the packet.

Sounds nice in theory, but reality bites back. RELATED also applies to 
the TCP Reset packets to SYN packets.

I just tried this at home to confirm my findings.

Please review the below firewall script. It does not send the TCP RST 
packets unless you make one minor change: To add 'RELATED,' to the line 
underneath '#General State Matching'

Please note that it has the single state matching lines as recommended 
by various others on this list.





> It almost sounds like you built a nearly stateless firewall.

It's more or less like the below but duplicates ESTABLISHED everywhere

------------------------------

A='/sbin/iptables'
EXIF='ppp0'
LANIF='eth1'

#Clear
$A -F
$A -F INPUT
$A -F OUTPUT
$A -F FORWARD
$A -F -t mangle
$A -F -t nat
$A -X

#Setup policies
$A -P INPUT DROP
$A -P OUTPUT DROP
$A -P FORWARD DROP

echo "1" > /proc/sys/net/ipv4/ip_forward

# Some basics
# Accept loopback interface
$A -A INPUT -i lo -j ACCEPT
A='/sbin/iptables'
EXIF='ppp0'
LANIF='eth1'

#Clear
$A -F
$A -F INPUT
$A -F OUTPUT
$A -F FORWARD
$A -F -t mangle
$A -F -t nat
$A -X

#Setup policies
$A -P INPUT DROP
$A -P OUTPUT DROP
$A -P FORWARD DROP

echo "1" > /proc/sys/net/ipv4/ip_forward

# Some basics
# Accept loopback interface
$A -A INPUT -i lo -j ACCEPT
$A -A OUTPUT -o lo -j ACCEPT

# SSH from LAN
$A -A INPUT -i $LANIF -p tcp --dport 22 -j ACCEPT

#general NAT
$A -t nat -A POSTROUTING -o $EXIF -j MASQUERADE

#General State Matching
$A -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
$A -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

#Allowed HTTP/HTTPS Sites
#bbc
$A -A FORWARD -i $LANIF -o $EXIF -d 212.58.244.22 -p tcp -m multiport 
--dports '80,443' -j ACCEPT

#Send RST to LAN for all other 80/443 connections
$A -A FORWARD -i $LANIF -p tcp -m multiport --dports '80,443' -j REJECT 
--reject-with tcp-reset


--------------------



Matt



--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Iptables Reject with TCP Reset

[Matt Killock]

On 2017-01-11 10:21, André Paulsberg-Csibi wrote:
> From what you sent me directly , you also allowed this in the OUTPUT
> chain which makes no sense to me ...
> ... but it maybe that the rules set has somehow been "broken" and it
> is now causing un-intended packet handling .

You might need INPUT, OUTPUT & FORWARD policies all to be 'DROP' for 
this behaviour.

I reproduced this at home using the below script (now corrected for 
copy/paste errors)

It's very basic, and should allow you to telnet from an internal host to 
the allowed HTTP site but refuse all other port 80's

I used tcpdump on the firewall to monitor the LAN interface.

--------------------------------------------------

A='/sbin/iptables'
EXIF='ppp0'
LANIF='eth1'

#Clear
$A -F
$A -F INPUT
$A -F OUTPUT
$A -F FORWARD
$A -F -t mangle
$A -F -t nat
$A -X

#Setup policies
$A -P INPUT DROP
$A -P OUTPUT DROP
$A -P FORWARD DROP

echo "1" > /proc/sys/net/ipv4/ip_forward

# Some basics
# Accept loopback interface
$A -A INPUT -i lo -j ACCEPT
$A -A OUTPUT -o lo -j ACCEPT

# SSH from LAN
$A -A INPUT -i $LANIF -p tcp --dport 22 -j ACCEPT

#general NAT
$A -t nat -A POSTROUTING -o $EXIF -j MASQUERADE

#General State Matching
$A -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
$A -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

#Allowed HTTP/HTTPS Sites
#bbc
$A -A FORWARD -i $LANIF -o $EXIF -d 212.58.244.22 -p tcp -m multiport
--dports '80,443' -j ACCEPT

#Send RST to LAN for all other 80/443 connections
$A -A FORWARD -i $LANIF -p tcp -m multiport --dports '80,443' -j REJECT
--reject-with tcp-reset


--------------------------


Matt

Re: Iptables Reject with TCP Reset

[Ethy H. Brito]

On Fri, 6 Jan 2017 16:28:31 +0000
Matt Killock <matt.killock@praemium.com> wrote:

> > Depends on your rule set. Check and fix it. The target usually works.  
> 
> As a test, I made the very first FORWARD rule this:
> 
> iptables -A FORWARD -i eth1 -p tcp -s 192.168.20.0/24 -d 212.58.244.71
> --dport 80 -j REJECT --reject-with tcp-reset
> 
> 'iptables -n -L' output:
> 
> Chain FORWARD (policy DROP)
> target     prot opt source               destination
> REJECT     tcp  --  192.168.20.0/24      212.58.244.71        tcp dpt:80
> reject-with tcp-reset
> 
> 
> However, no Reset packets can be observed:
> 
> # tcpdump -ni eth1 host 192.168.20.164
> 16:23:00.706667 IP 192.168.20.164.50105 > 212.58.244.71.80: Flags [SEW], seq
> 2763730948, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length
> 0 16:23:02.717733 IP 192.168.20.164.50106 > 212.58.244.71.80: Flags [SEW],
> seq 2464499683, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK],
> length 0
> 
> If this does usually work then could you give me a clue on what ruleset it
> does work with?
> 

Is the 192.168.20.0/24 network at the "same side" of eth1 ??

The rule, as it is written, expects an incoming packet thru eth1 and outgoing
thru any interface towards port 80. Therefore 192.168.20.0/24 must be at the "same side" of the eth1.

Ethy

Re: Iptables Reject with TCP Reset

[Neal P. Murphy]

On Fri, 6 Jan 2017 16:28:31 +0000
Matt Killock <matt.killock@praemium.com> wrote:

> > Depends on your rule set. Check and fix it. The target usually works.
> 
> As a test, I made the very first FORWARD rule this:
> 
> iptables -A FORWARD -i eth1 -p tcp -s 192.168.20.0/24 -d 212.58.244.71 --dport 80 -j REJECT --reject-with tcp-reset

Dumb question: can you reset a TCP conn that isn't ESTABLISHED? I don't think a TCP reset applies to the first SYN packet.

Here are the rules I use when a conn passes outside its allowed time frame:
  -A timedaction -p tcp -m state --state ESTABLISHED -j REJECT --reject-with tcp-reset
  -A timedaction -j REJECT --reject-with icmp-admin-prohibited

When a packet is received for an established TCP conn, a reset is returned to the sender. Each direction is handled separately. Once a particular direction has been reset, it is no longer ESTABLISHED, and further packets in that direction are rejected with ICMP 'admin prohibited' packets.

In short, each direction of established TCP conns is reset individually. All other conns, including each reset direction of TCP conns, are rejected via ICMP.

N

Re: Iptables Reject with TCP Reset

[Noel Kuntze]

[-- Attachment #1.1: Type: text/plain, Size: 878 bytes --]

On 07.01.2017 00:26, Neal P. Murphy wrote:
> Dumb question: can you reset a TCP conn that isn't ESTABLISHED? I don't think a TCP reset applies to the first SYN packet.
Yes, you can and have to. It's specified as such. It does.


>   -A timedaction -p tcp -m state --state ESTABLISHED -j REJECT --reject-with tcp-reset
>   -A timedaction -j REJECT --reject-with icmp-admin-prohibited
You should reject all TCP packets, not just the ones that belong to an established connection.

> and further packets in that direction are rejected with ICMP 'admin prohibited' packets.
That's invalid behaviour. See above.

>  All other conns, including each reset direction of TCP conns, are rejected via ICMP.
See above.

-- 

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 866 bytes --]