You are not logged in.

Pages: 1

#1 2014-02-22 04:00:59

synthead
Member
Registered: 2006-05-09
Posts: 1,337

Some questions about iptables

With the following config I created using the Wiki, I have a few questions:

  • I only have one WAN and one LAN interface.  What can I do to simplify the rules (to preferably get rid of TCP, fw_interfaces, and fw_open while retaining the same effect)?

  • Incoming HTTPS connections (port 443) get mangled somehow, with Chrome returning ERR_SSL_PROTOCOL_ERROR.  Why?

  • Is there a package available that allows for testing of iptables configuration before "applying" it, like in Debian?

  • What things (big or small) should I consider in hardening the firewall?

# Generated by iptables-save v1.4.21 on Tue Feb 18 23:58:56 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [72:6517]
:TCP - [0:0]
:UDP - [0:0]
:fw_interfaces - [0:0]
:fw_open - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth_lan -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p udp -m conntrack --ctstate NEW -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j fw_interfaces
-A FORWARD -j fw_open
-A FORWARD -j REJECT --reject-with icmp-host-unreachable
-A fw_interfaces -i eth_lan -j ACCEPT
-A fw_open -d 10.0.0.3/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A fw_open -d 10.0.0.3/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A fw_open -d 10.0.0.3/32 -p tcp -m tcp --dport 443 -j ACCEPT
COMMIT
# Completed on Tue Feb 18 23:58:56 2014
# Generated by iptables-save v1.4.21 on Tue Feb 18 23:58:56 2014
*nat
:PREROUTING ACCEPT [15:1967]
:INPUT ACCEPT [1:233]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i eth_wan -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.3
-A PREROUTING -i eth_wan -p tcp -m tcp --dport 22 -j DNAT --to-destination 10.0.0.3
-A PREROUTING -i eth_wan -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.3
-A POSTROUTING -s 10.0.0.0/8 -o eth_wan -j MASQUERADE
COMMIT
# Completed on Tue Feb 18 23:58:56 2014

Offline

#2 2014-02-22 11:23:19

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: Some questions about iptables

You've got "-j TCP", but not *defined* a chain called "TCP". And probably just adding confusion by trying to be clever with FIN etc. flags.

Offline

#3 2014-02-22 21:22:25

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

Re: Some questions about iptables

synthead wrote:

With the following config I created using the Wiki, I have a few questions:

  • I only have one WAN and one LAN interface.  What can I do to simplify the rules (to preferably get rid of TCP, fw_interfaces, and fw_open while retaining the same effect)?

  • Incoming HTTPS connections (port 443) get mangled somehow, with Chrome returning ERR_SSL_PROTOCOL_ERROR.  Why?

  • Is there a package available that allows for testing of iptables configuration before "applying" it, like in Debian?

  • What things (big or small) should I consider in hardening the firewall?

# Generated by iptables-save v1.4.21 on Tue Feb 18 23:58:56 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [72:6517]
:TCP - [0:0]
:UDP - [0:0]
:fw_interfaces - [0:0]
:fw_open - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth_lan -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p udp -m conntrack --ctstate NEW -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j fw_interfaces
-A FORWARD -j fw_open
-A FORWARD -j REJECT --reject-with icmp-host-unreachable
-A fw_interfaces -i eth_lan -j ACCEPT
-A fw_open -d 10.0.0.3/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A fw_open -d 10.0.0.3/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A fw_open -d 10.0.0.3/32 -p tcp -m tcp --dport 443 -j ACCEPT
COMMIT
# Completed on Tue Feb 18 23:58:56 2014
# Generated by iptables-save v1.4.21 on Tue Feb 18 23:58:56 2014
*nat
:PREROUTING ACCEPT [15:1967]
:INPUT ACCEPT [1:233]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i eth_wan -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.3
-A PREROUTING -i eth_wan -p tcp -m tcp --dport 22 -j DNAT --to-destination 10.0.0.3
-A PREROUTING -i eth_wan -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.3
-A POSTROUTING -s 10.0.0.0/8 -o eth_wan -j MASQUERADE
COMMIT
# Completed on Tue Feb 18 23:58:56 2014

What is your setup? I assume you have a simple client (e.g. laptop) whose IP is 10.0.0.3 -- is that right?

If so, then you don't need a firewall _at_all_ bacause no service is supposed to listen for incoming connections. Check your ports -- there should be nothing binding to anything but localhost (if it does, there is a misconfig somewhere). For example,

$ ss -lrptn && ss -lrpun
State       Recv-Q Send-Q                    Local Address:Port                      Peer Address:Port 
LISTEN      0      128               localhost.localdomain:22                                   *:*     
LISTEN      0      20                localhost.localdomain:25                                   *:*     
State       Recv-Q Send-Q                    Local Address:Port                      Peer Address:Port 
UNCONN      0      0                              bluemoon:123                                  *:*     
UNCONN      0      0                              bluemoon:123                                  *:*     
UNCONN      0      0                 localhost.localdomain:123                                  *:*     
UNCONN      0      0                                     *:123                                  *:*

See, in the TCP section I have ssh and exim listening on localhost only. The rest is UDP and ntpd.

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

Offline

#4 2014-02-22 22:21:53

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 4,092
Website

Re: Some questions about iptables

Wait, I thought iptables was deprecated in favor of nftables... sad

Offline

#5 2014-02-22 22:48:51

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Some questions about iptables

drcouzelis wrote:

Wait, I thought iptables was deprecated in favor of nftables... sad

It isn't quite yet.  I think that is the goal, but nftables is new and still has a bit of work to be done before it can be considered a safe and viable new solution.  It was just introduced as of 3.13, so I think it needs to enjoy some real world testing first.

Offline

#6 2014-02-23 01:33:37

synthead
Member
Registered: 2006-05-09
Posts: 1,337

Re: Some questions about iptables

brebs wrote:

You've got "-j TCP", but not *defined* a chain called "TCP". And probably just adding confusion by trying to be clever with FIN etc. flags.

In this section of the Wiki, it states:

Now we attach the TCP and UDP chains to the INPUT chain to handle all new incoming connections. Once a connection is accepted by either TCP or UDP chain, it is handled by the RELATED/ESTABLISHED traffic rule. The TCP and UDP chains will either accept new incoming connections, or politely reject them. New TCP connections must be started with SYN packets.

Note: NEW but not SYN is the only invalid TCP flag not covered by the INVALID state. The reason is because they are rarely malicious packets, and they should not just be dropped. Instead, we simply do not accept them, so they are rejected with a TCP RST by the next rule.

# iptables -A INPUT -p udp -m conntrack --ctstate NEW -j UDP
# iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP

When it mentions "all new incoming connections," does it also mean traffic forwarded via NAT, or would these rules only apply to open ports for services running on the firewall?  I followed everything word-for-word on the Wiki excluding the line for ICMP echo requests (to block pings) and used underscores in fw_interfaces and fw_open instead.

Last edited by synthead (2014-02-23 01:34:32)

Offline

#7 2014-02-23 01:35:36

synthead
Member
Registered: 2006-05-09
Posts: 1,337

Re: Some questions about iptables

WonderWoofy wrote:
drcouzelis wrote:

Wait, I thought iptables was deprecated in favor of nftables... sad

It isn't quite yet.  I think that is the goal, but nftables is new and still has a bit of work to be done before it can be considered a safe and viable new solution.  It was just introduced as of 3.13, so I think it needs to enjoy some real world testing first.

Oh wow, interesting!  I will keep an eye on this for sure.

Offline

#8 2014-02-23 10:20:38

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: Some questions about iptables

synthead wrote:
brebs wrote:

You've got "-j TCP", but not *defined* a chain called "TCP". And probably just adding confusion by trying to be clever with FIN etc. flags.

In this section of the Wiki, it states

You missed this bit:

Note: This is where you need to add rules to accept incoming connections, such as SSH, HTTP or other services that you want to access remotely.

That wiki article really needs a "debugging" section, mentioning e.g. -j LOG, and TRACE. And e.g.:

watch -n 2 "iptables -t mangle -L -x -v | tail -n +13"

Offline

#9 2014-02-23 13:00:30

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,489

Re: Some questions about iptables

synthead wrote:

...
When it mentions "all new incoming connections," does it also mean traffic forwarded via NAT, or would these rules only apply to open ports for services running on the firewall?  I followed everything word-for-word on the Wiki excluding the line for ICMP echo requests (to block pings) and used underscores in fw_interfaces and fw_open instead.

What Brebs told you already, you did not follow the very first step of that article:
https://wiki.archlinux.org/index.php/Si … ary_chains
For your other question, have a look at
https://wiki.archlinux.org/index.php/Iptables#Chains
where the basic concepts are described. Maybe that answers?

Offline

Pages: 1

Board footer

Powered by FluxBB