Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #11761 > unrolled thread

Comment on iptables for a home computer?

Started bynomdeplume82008@googlemail.com
First post2014-08-19 10:20 -0700
Last post2014-08-22 12:00 +0200
Articles 9 — 6 participants

Back to article view | Back to comp.os.linux.misc

Contents

  Comment on iptables for a home computer? nomdeplume82008@googlemail.com - 2014-08-19 10:20 -0700
    Re: Comment on iptables for a home computer? Andreas Kohlbach <aug14.8.ankman@spamgourmet.com> - 2014-08-19 16:41 -0400
    Re: Comment on iptables for a home computer? Rich <rich@example.invalid> - 2014-08-19 21:16 +0000
    Re: Comment on iptables for a home computer? nomdeplume82008@googlemail.com - 2014-08-20 08:53 -0700
      Re: Comment on iptables for a home computer? Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2014-08-21 22:47 +0200
        Re: Comment on iptables for a home computer? The Natural Philosopher <tnp@invalid.invalid> - 2014-08-21 23:37 +0100
          Re: Comment on iptables for a home computer? Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2014-08-22 10:45 +0200
            Re: Comment on iptables for a home computer? The Natural Philosopher <tnp@invalid.invalid> - 2014-08-22 10:41 +0100
              Re: Comment on iptables for a home computer? Marc Haber <mh+usenetspam1118@zugschl.us> - 2014-08-22 12:00 +0200

#11761 — Comment on iptables for a home computer?

Fromnomdeplume82008@googlemail.com
Date2014-08-19 10:20 -0700
SubjectComment on iptables for a home computer?
Message-ID<f71a0f23-7e9c-45bd-98a6-cf0daeccf9ec@googlegroups.com>
What do you think of this iptables ruleset?

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             state NEW,RELATED,ESTABLISHED

[toc] | [next] | [standalone]

#11763

FromAndreas Kohlbach <aug14.8.ankman@spamgourmet.com>
Date2014-08-19 16:41 -0400
Message-ID<87wqa4qkjn.fsf@usenet.ankman.de>
In reply to#11761
nomdeplume82008@googlemail.com wrote on 19. August 2014:
>
> What do you think of this iptables ruleset?
>
> Chain INPUT (policy DROP)
> target     prot opt source               destination         
> ACCEPT     all  --  anywhere             anywhere            
> ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
>
> Chain FORWARD (policy DROP)
> target     prot opt source               destination         
>
> Chain OUTPUT (policy DROP)
> target     prot opt source               destination         
> ACCEPT     all  --  anywhere             anywhere            
> ACCEPT     all  --  anywhere             anywhere             state NEW,RELATED,ESTABLISHED

I'd say you don't need any rules if you are not offering any services you
don't want to offer.
-- 
Andreas

I wish my grass was emo. Then it would cut itself.

[toc] | [prev] | [next] | [standalone]

#11764

FromRich <rich@example.invalid>
Date2014-08-19 21:16 +0000
Message-ID<lt0es0$3m4$2@dont-email.me>
In reply to#11761
nomdeplume82008@googlemail.com wrote:
> What do you think of this iptables ruleset?

>   Chain INPUT (policy DROP)
>   target     prot opt source               destination         
> 1 ACCEPT     all  --  anywhere             anywhere            
> 2 ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED

>   Chain FORWARD (policy DROP)
>   target     prot opt source               destination         

>   Chain OUTPUT (policy DROP)
>   target     prot opt source               destination         
> 3 ACCEPT     all  --  anywhere             anywhere            
> 4 ACCEPT     all  --  anywhere             anywhere             state NEW,RELATED,ESTABLISHED

Line numbers added above for clarity.  You should have dumped with the
"--line-numbers" switch to begin with.

Line 1 undoes everything a default DROP on INPUT performs.  Because
line 1 accepts anything, from anywhere.

Line 2 is never executed, because anything, from anywhere, for any
reason, is already accepted by line 1.

Line 3 & 4 are identical to lines 1 & 2 as far as what they do, and
what they allow.

This ruleset is identical to having no firewall at all.  Anything, from
anywhere, in any state, is accepted.

If your plan is to expose all ports to the network interface, it is
perfect.

If your plan is to actually "firewall" the machine, it won't work.


You could achieve the identical "ruleset" by doing this:

iptables --flush
iptables --policy INPUT ACCEPT
iptables --policy OUTPUT ACCEPT

[toc] | [prev] | [next] | [standalone]

#11767

Fromnomdeplume82008@googlemail.com
Date2014-08-20 08:53 -0700
Message-ID<c383c655-9bd2-4dd3-91f6-c4eaf4679c71@googlegroups.com>
In reply to#11761
On Tuesday, August 19, 2014 5:20:52 PM UTC, nomdepl...@googlemail.com wrote:
> What do you think of this iptables ruleset?
> 
> 
> 
> Chain INPUT (policy DROP)
> 
> target     prot opt source               destination         
> 
> ACCEPT     all  --  anywhere             anywhere            
> 
> ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
> 
> 
> 
> Chain FORWARD (policy DROP)
> 
> target     prot opt source               destination         
> 
> 
> 
> Chain OUTPUT (policy DROP)
> 
> target     prot opt source               destination         
> 
> ACCEPT     all  --  anywhere             anywhere            
> 
> ACCEPT     all  --  anywhere             anywhere             state NEW,RELATED,ESTABLISHED

Oops, it seems my loopback line was messed up!

#!/bin/bash
iptables --flush
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP
iptables --append INPUT -i lo -j ACCEPT
iptables --append OUTPUT -o lo -j ACCEPT
iptables --append INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables --append OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

[toc] | [prev] | [next] | [standalone]

#11783

FromPascal Hambourg <boite-a-spam@plouf.fr.eu.org>
Date2014-08-21 22:47 +0200
Message-ID<lt5lt3$j9a$1@saria.nerim.net>
In reply to#11767
nomdeplume82008@googlemail.com a écrit :
> 
> Oops, it seems my loopback line was messed up!

No, the output of "iptables -L" is incomplete by design. Consider using
iptables-save instead.

> iptables --flush
> iptables --policy INPUT DROP
> iptables --policy OUTPUT DROP
> iptables --policy FORWARD DROP
> iptables --append INPUT -i lo -j ACCEPT
> iptables --append OUTPUT -o lo -j ACCEPT
> iptables --append INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables --append OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

In short this ruleset allows only outgoing connections.

[toc] | [prev] | [next] | [standalone]

#11787

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2014-08-21 23:37 +0100
Message-ID<lt5sb2$ok7$1@news.albasani.net>
In reply to#11783
On 21/08/14 21:47, Pascal Hambourg wrote:
> nomdeplume82008@googlemail.com a écrit :
>>
>> Oops, it seems my loopback line was messed up!
>
> No, the output of "iptables -L" is incomplete by design. Consider using
> iptables-save instead.
>
>> iptables --flush
>> iptables --policy INPUT DROP
>> iptables --policy OUTPUT DROP
>> iptables --policy FORWARD DROP
>> iptables --append INPUT -i lo -j ACCEPT
>> iptables --append OUTPUT -o lo -j ACCEPT
>> iptables --append INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>> iptables --append OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>
> In short this ruleset allows only outgoing connections.
>
Strictly it allows incoming connections that are RELATED to previous 
outgoing ones as well: Typically a DNS request over UDP from port X to 
remote port 53 will 'allow' a connection from remote port 53 back to the 
originating port X, though it can't be considered established because 
UDP never gets 'established'.


-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[toc] | [prev] | [next] | [standalone]

#11788

FromPascal Hambourg <boite-a-spam@plouf.fr.eu.org>
Date2014-08-22 10:45 +0200
Message-ID<lt6vve$10qn$1@saria.nerim.net>
In reply to#11787
The Natural Philosopher a écrit :
> On 21/08/14 21:47, Pascal Hambourg wrote:
>> nomdeplume82008@googlemail.com a écrit :
>>
>>> iptables --flush
>>> iptables --policy INPUT DROP
>>> iptables --policy OUTPUT DROP
>>> iptables --policy FORWARD DROP
>>> iptables --append INPUT -i lo -j ACCEPT
>>> iptables --append OUTPUT -o lo -j ACCEPT
>>> iptables --append INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>>> iptables --append OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>> In short this ruleset allows only outgoing connections.
>>
> Strictly it allows incoming connections that are RELATED to previous 
> outgoing ones as well:

Yes. For instance it includes ICMP error messages and FTP data
connections, related to outgoing existing connections.

> Typically a DNS request over UDP from port X to 
> remote port 53 will 'allow' a connection from remote port 53 back to the 
> originating port X, though it can't be considered established because 
> UDP never gets 'established'.

A DNS reply packet is ESTABLISHED. Netfilter connection tracking keeps
some state for UDP flows, and UDP packets can be ESTABLISHED.

[toc] | [prev] | [next] | [standalone]

#11789

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2014-08-22 10:41 +0100
Message-ID<lt7382$jo4$1@news.albasani.net>
In reply to#11788
On 22/08/14 09:45, Pascal Hambourg wrote:
> The Natural Philosopher a écrit :
>> On 21/08/14 21:47, Pascal Hambourg wrote:
>>> nomdeplume82008@googlemail.com a écrit :
>>>
>>>> iptables --flush
>>>> iptables --policy INPUT DROP
>>>> iptables --policy OUTPUT DROP
>>>> iptables --policy FORWARD DROP
>>>> iptables --append INPUT -i lo -j ACCEPT
>>>> iptables --append OUTPUT -o lo -j ACCEPT
>>>> iptables --append INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>>>> iptables --append OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>>> In short this ruleset allows only outgoing connections.
>>>
>> Strictly it allows incoming connections that are RELATED to previous
>> outgoing ones as well:
>
> Yes. For instance it includes ICMP error messages and FTP data
> connections, related to outgoing existing connections.
>
>> Typically a DNS request over UDP from port X to
>> remote port 53 will 'allow' a connection from remote port 53 back to the
>> originating port X, though it can't be considered established because
>> UDP never gets 'established'.
>
> A DNS reply packet is ESTABLISHED. Netfilter connection tracking keeps
> some state for UDP flows, and UDP packets can be ESTABLISHED.
>
I don't think the UDP protocol has the concept of ESTABLISHED in it.

A UDP header is source and destination ports and addresses and the 
packet length and a checksum ONLY.

Any concept of a stateful connection has to be implied from thehistory 
of UDP packet flow.

If that statefulness is called 'established' in iptables well all well 
and good, but in my book its 'related'

'established' refers to TCP connections with SYN/ACK responses and a 
valid sequence numbers..in my book..

-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[toc] | [prev] | [next] | [standalone]

#11790

FromMarc Haber <mh+usenetspam1118@zugschl.us>
Date2014-08-22 12:00 +0200
Message-ID<lt74c6$vnu$1@news1.tnib.de>
In reply to#11789
The Natural Philosopher <tnp@invalid.invalid> wrote:
>I don't think the UDP protocol has the concept of ESTABLISHED in it.

A stateful packet filter has. If it hadn't, you would have to manually
allow the reverse direction. Typically, a stateful filter allows
reverse packets for a configurable amount of time. Better stateful
filters can distinguish between query-answer-finished and streaming
type protocols, bad filters can't.

Typically, the latter shows itself if DNS works but SIP/RTP doesn't.

Greetings
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web