doc: Secure use of iptables and connection tracking helpers

doc: Secure use of iptables and connection tracking helpers

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

Hello,

Pablo Neira Ayuso, Patrick McHardy and I have worked on a document we've
called "Secure use of iptables and connection tracking helpers".

This is a guide describing how to use securely the connection tracking
helpers. This is a recommended reading for all Netfilter/Iptables users.

HTML version: http://home.regit.org/netfilter-en/secure-use-of-helpers/
PDF version:
http://home.regit.org/wp-content/uploads/2011/11/helper-recommandation.pdf

BR,
-- 
Eric Leblond 
Blog: http://home.regit.org/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: doc: Secure use of iptables and connection tracking helpers

[Jan Engelhardt]

On Monday 2011-11-28 18:32, Eric Leblond wrote:

>Hello,
>
>Pablo Neira Ayuso, Patrick McHardy and I have worked on a document we've
>called "Secure use of iptables and connection tracking helpers".
>
>This is a guide describing how to use securely the connection tracking
>helpers. This is a recommended reading for all Netfilter/Iptables users.
>
>HTML version: http://home.regit.org/netfilter-en/secure-use-of-helpers/
>PDF version:
>http://home.regit.org/wp-content/uploads/2011/11/helper-recommandation.pdf

Is this available in a text/{latex,plain,etc.} source available, so one 
can submit changes against?

Re: doc: Secure use of iptables and connection tracking helpers

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

Hello,

On Mon, 2011-11-28 at 21:19 +0100, Jan Engelhardt wrote:
> On Monday 2011-11-28 18:32, Eric Leblond wrote:
> 
> >Hello,
> >
> >Pablo Neira Ayuso, Patrick McHardy and I have worked on a document we've
> >called "Secure use of iptables and connection tracking helpers".
> >
> >This is a guide describing how to use securely the connection tracking
> >helpers. This is a recommended reading for all Netfilter/Iptables users.
> >
> >HTML version: http://home.regit.org/netfilter-en/secure-use-of-helpers/
> >PDF version:
> >http://home.regit.org/wp-content/uploads/2011/11/helper-recommandation.pdf
> 
> Is this available in a text/{latex,plain,etc.} source available, so one 
> can submit changes against?

I've just setup a github repository to host the file. It is available
here:
	https://github.com/regit/secure-conntrack-helpers

BR,
-- 
Eric Leblond 
Blog: http://home.regit.org/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: doc: Secure use of iptables and connection tracking helpers

[Jan Engelhardt]

On Monday 2011-11-28 23:58, Eric Leblond wrote:
>> >HTML version: http://home.regit.org/netfilter-en/secure-use-of-helpers/
>> >PDF version:
>> >http://home.regit.org/wp-content/uploads/2011/11/helper-recommandation.pdf
>
>I've just setup a github repository to host the file. It is available
>here:
>	https://github.com/regit/secure-conntrack-helpers


>"This system lays on parsing of data coming or from the user or from
>the server."
>
>"we put protocol features which lead to have the user to choose some
>parameters."

lay/put is inaccurate here; what was the origin French words
you thought of here?

>"Linux provides a routing based implementation of reverse path
>filtering." ... "There is at the time of the writing no
>routing-based implementation of `rp_filter` in the Linux kernel."

These statements seem to contradict themselves.


Here's a patch so far.

parent 290cb9996fb87876dd73d9b066320c42ea395810 ()
commit e169ba81c02d42e9d1987b18ad89c7c023aff229
Author: Jan Engelhardt <jengelh@medozas.de>
Date:   Tue Nov 29 01:52:05 2011 +0100

Grammar and spelling fixes
---
 secure-conntrack-helpers.rst |  123 ++++++++++++++++++----------------
 1 files changed, 64 insertions(+), 59 deletions(-)

diff --git a/secure-conntrack-helpers.rst b/secure-conntrack-helpers.rst
index bfc6228..9bb9cd3 100644
--- a/secure-conntrack-helpers.rst
+++ b/secure-conntrack-helpers.rst
@@ -10,10 +10,11 @@ Principle of helpers
 --------------------
 
 Some protocols use different flows for signalling and data tranfers.  This is
-the case of FTP, SIP and H.323 among many others. In the setup stage, it is
-common that the the signalling flow is used to negociate the configuration
-parameters for the establishment of the data flow, ie. the IP and port that
-are used to establish the data flow. This sort of protocols are particularly
+the case for FTP, SIP and H.323 among many others. In the setup stage, it is
+common that the the signalling flow is used to negotiate the configuration
+parameters for the establishment of the data flow,
+i.e. the IP address and port that
+are used to establish the data flow. These sort of protocols are particularly
 harder to filter by firewalls since they violate layering by introducing OSI
 layer 3/4 parameters in the OSI layer 7.
 
@@ -21,13 +22,14 @@ In order to overcome this situation in the iptables firewall, Netfilter
 provides the Connection Tracking helpers, which are modules that are able
 to assist the firewall in tracking these protocols.  These helpers create
 the so-called expectations, as defined by the Netfilter project jargon.
-An expectation is similar to a connection tracking entry but it is stored in
-a separate table and as generally a limited duration. Expectation are used to
+An expectation is similar to a connection tracking entry, but it is stored in
+a separate table and generally with a limited duration.
+Expectations are used to
 signal the kernel that in the coming seconds, if a packet with corresponding
-parameters reach the firewall, then this packet is RELATED to the previous
+parameters reaches the firewall, then this packet is RELATED to the previous
 connection.
 
-These kind of packets can then be authorized thanks to module like state or
+These kind of packets can then be authorized thanks to modules like state or
 conntrack which can match RELATED packets.
 
 This system lays on parsing of data coming or from the user or from the server.
@@ -37,25 +39,26 @@ when using connection tracking helpers.
 Connection Tracking helpers default configuration
 -------------------------------------------------
 
-Due to protocol constraints, all helper are not equals. For example, the FTP
-helper will create an expectation where IP parameters are the two peers. The
-IRC helper create expectation where destination address is the client address
+Due to protocol constraints, not all helpers are equal. For example, the FTP
+helper will create an expectation whose IP parameters are the two peers. The
+IRC helper creates expectations whose destination address is the client address
 and source address is any address. This is due to the protocol: we do not know
-the IP adress of the person who is target of the DCC.
+the IP address of the person who is the target of the DCC.
 
-The degree of freedom due to connection tracking helpers are thus dependant of
-the natur of the protocol. Some protocols have dangerous extensions and this
-ones are disabled by defaut by Netfilter. Under the dangerous term, we put
-protocols features which lead to have the user to choose some parameters.
-For example, FTP protocol can let the user choose to have the target server
-connect to an other arbitrary server. This could lead to hole in DMZ and it
-is thus desactivated by default.
+The degree of freedom due to connection tracking helpers are thus dependent on
+the nature of the protocol. Some protocols have dangerous extensions, and these
+are disabled by defaut by Netfilter. Under these dangerous conditions, we put
+protocol features which lead to have the user to choose some parameters.
+For example, the FTP protocol can let the user choose to have the target server
+connect to another arbitrary server. This could lead to a hole in the
+DMZ and it
+is thus deactivated by default.
 
-The following list describes the differents connection tracking helpers
+The following list describes the different connection tracking helper
 modules and their associated degree of freedom.
 
 ==============  ==============  ===========  ===================  ================  ========  ===================================
-Module          Source address  Port Source  Destination address  Destination port  Protocol  Option
+Module          Source address  Source Port  Destination address  Destination port  Protocol  Option
 --------------  --------------  -----------  -------------------  ----------------  --------  -----------------------------------
 amanda          Fixed           0-65535      Fixed                In CMD            TCP 
 ftp             Fixed           0-65535      In CMD               In CMD            TCP       loose = 1 (default)
@@ -75,21 +78,21 @@ tftp            Fixed           0-65535      Fixed                In Packet
 
 The following keywords are used:
 
- - Fixed: Value of a connection tracking attribute is used. This is not a candidate to forgery.
- - In CMD: Value is fetch from the payload. This is a candidate to forgery.
+ - Fixed: Value of a connection tracking attribute is used. This is not a candidate for forgery.
+ - In CMD: Value is fetched from the payload. This is a candidate for forgery.
 
-The option are module loading option. They permit to activate the
+The options are module loading options. They permit to activate the
 extended but dangerous features of some protocols.
 
 Secure use of Connection Tracking Helpers
 =========================================
 
-Following the preceedings remarks, it appears that it is necessary to not
+Following the preceeding remarks, it appears that it is necessary to not
 blindly use helpers. You must take into account the topology of your network
-when setting parameters linked with helper.
+when setting parameters linked to a helper.
 
-For each helper, you must open carefully the RELATED flow. All iptables line
-using " -m state --state RELATED" should be used in conjonction with the
+For each helper, you must carefully open the RELATED flow. All iptables lines
+using "-m state --state RELATED" should be used in conjunction with the
 choice of a helper.  Doing that, you will be able to describe how the helper
 must be used with respect to your network and information system architecture.
 
@@ -102,7 +105,7 @@ For example, if you run an FTP server, you can setup ::
  	--helper ftp -d $MY_FTP_SERVER -p tcp \
 	--dport 1024: -j ACCEPT
 
-If your clients are authorized to access to FTP outside of your network you
+If your clients are authorized to access FTP outside of your network, you
 can add ::
 
  iptables -A FORWARD -m state --state RELATED -m helper \
@@ -124,8 +127,8 @@ The same syntax applies to IPV6 ::
 Example: SIP helper
 -------------------
 
-You should limit the connection RELATED due to the SIP helper by restricting
-the destination address to the RTP servers farm of your provider ::
+You should limit the RELATED connection due to the SIP helper by restricting
+the destination address to the RTP server farm of your provider ::
 
  iptables -A FORWARD -m state --state RELATED -m helper \
  	--helper sip -d $ISP_RTP_SERVER -p udp -j ACCEPT
@@ -134,39 +137,39 @@ Example: h323 helper
 --------------------
 
 The issue is the same as the one described for SIP, you should limit the
-opening of the RELATED connection to the RTP servers address of your VOIP
+opening of the RELATED connection to the RTP server addresses of your VOIP
 provider.
 
 Securing the signalling flow
 ----------------------------
 
 You will also need to build carefully crafted rules for the authorization
-of flow involving connection tracking helpers. And in particular, you have
+of flows involving connection tracking helpers. In particular, you have
 to do a strict antispoofing (has described below) to avoid traffic injection
 from other interfaces.
 
 
-Use CT target to refine security
-================================
+Using the CT target to refine security
+======================================
 
 Introduction
 ------------
 
-One classical problem with helpers is the fact that helpers listen on
+One classic problem with helpers is the fact that helpers listen on
 predefined ports.  If a service does not run on standard port, it is
 necessary to declare it. Before 2.6.34, the only method to do so was
 to use a module option. This was resulting in having a systematic
 parsing of the added port by the choosen helper. This was clearly
 suboptimal and the CT target has been introduced in 2.6.34. It allows
 to specify what helper to use for a specific flow.  For exemple, let's
-say we have a FTP server at IP 1.2.3.4 running on port 2121.
+say we have a FTP server at IP address 1.2.3.4 running on port 2121.
 
-To declare it we can simply do ::
+To declare it, we can simply do ::
  
  iptables -A PREROUTING -t raw -p tcp --dport 2121 \
  	-d 1.2.3.4 -j CT --helper ftp
 
-We thus recommand NOT to use module option anymore and use the CT target
+We thus recommand NOT to use module options anymore, and use the CT target
 instead.
 
 Disable helper by default
@@ -174,20 +177,21 @@ Disable helper by default
 Principle
 ~~~~~~~~~
 
-Once an helper is loaded, it will treat the packet for a given port and all IP.
-As explained before this is not optimal and is even a security risk. A better
-solution is to load the module helper and desactivate their parsing by default.
+Once a helper is loaded, it will treat packets for a given port and all IP
+addresses.
+As explained before, this is not optimal and is even a security risk. A better
+solution is to load the module helper and deactivate their parsing by default.
 Each wanted helper use is then set by using a call to the CT target.
 
 Method
 ~~~~~~
 
 It is possible to obtain this behaviour for most connection tracking helper
-module by setting to 0 the port number for the module. For example ::
+modules by setting the port number to 0 for the module. For example ::
 
  modprobe nf_conntrack_$PROTO ports=0
 
-The following modules will be desactivated on all flows by default by doing
+The following modules will be deactivated on all flows by default by doing
 this:
 
  - ftp
@@ -196,7 +200,7 @@ this:
  - sip
  - tftp
 
-Some modules will no work dut to the abscence of ports parameter:
+Some modules will not work due to the abscence of ports parameter:
 
  - amanda
  - h323
@@ -211,8 +215,8 @@ Helpers and antispoofing
 ------------------------
 
 Helper lays on the parsing of data that come from client or from server. It
-is thus important to limit spoofing attack that could be used to feed the
-helpers with forged datas. Helpers are IP only and are not doing, as the
+is thus important to limit spoofing attacks that could be used to feed the
+helpers with forged data. Helpers are IP only and are not doing, as the
 rest of the connection tracking, any coherence check on the network
 architecture.
 
@@ -220,8 +224,8 @@ Using rp_filter
 ---------------
 
 Linux provides a routing based implementation of reverse path filtering.
-This is available for IPv4.  To activate it you need to ensure that the
-`/proc/sys/net/ipv4/conf/*/rp_filter` files contains 1.  The complete
+This is available for IPv4.  To activate it, you need to ensure that the
+`/proc/sys/net/ipv4/conf/*/rp_filter` files contain 1.  The complete
 documentation about `rp_filter` is available in the file `ip-sysctl.txt`
 in the `Documentation/networking/` directory of the Linux tree.
 
@@ -233,13 +237,13 @@ The documentation at the time of the writing is reproduced here ::
         Reverse Path. Each incoming packet is
         tested against the FIB and if the interface
         is not the best reverse path the packet
-        check will fail. By default failed packets
+        check will fail. By default, failed packets
         are discarded.
     2 - Loose mode as defined in RFC3704 Loose
         Reverse Path. Each incoming packet's source
         address is also tested against the FIB
         and if the source address is not reachable
-        via any interface the packet check will fail.
+        via any interface, the packet check will fail.
 
     Current recommended practice in RFC3704 is to
     enable strict mode to prevent IP spoofing from
@@ -261,17 +265,18 @@ is thus needed.
 Manual anti-spoofing
 --------------------
 
-The best way to do anit-spoofing is to use filtering rules in the RAW table.
+The best way to do anti-spoofing is to use filtering rules in the RAW table.
 This has the great advantage of shortcutting the connection tracking. This
-help to reduce the load that could be created by some flooding.
+helps to reduce the load that could be created by some flooding.
 
-The antispoofing must be done a a per-interface way. For each interface,
-we must list the authorized network on the interface. There is an exception
+The antispoofing must be done on a per-interface basis. For each interface,
+we must list the authorized network on the interface. There is an exception,
 which is the interface with the default route where an inverted logic must
-be used. In our example, let's take eth1 which is a LAN interface and have
-eth0 the interface with the default route. Let's also have $NET_ETH1 being
+be used. In our example, let's take eth1, which is a LAN interface, and have
+eth0 being the interface with the default route.
+Let's also have $NET_ETH1 being
 the network connected to $ETH1 and $ROUTED_VIA_ETH1 a network routed by this
-interface. With that setup, we can do antispoofing with the following rules ::
+interface. With this setup, we can do antispoofing with the following rules ::
 
  iptables -A PREROUTING -t raw -i eth0 -s $NET_ETH1 -j DROP
  iptables -A PREROUTING -t raw -i eth0 -s $ROUTED_VIA_ETH1 -j DROP
@@ -283,6 +288,6 @@ The IPv6 case is similar if we omit the case of the local link network ::
 
  ip6tables -A PREROUTING -t raw -i eth0 -s $NET_ETH1 -j DROP
  ip6tables -A PREROUTING -t raw -i eth0 -s $ROUTED_VIA_ETH1 -j DROP
- ip6tables -A PREROUTING -t raw fe80::/64 -j ACCEPT
+ ip6tables -A PREROUTING -t raw -s fe80::/64 -j ACCEPT
  ip6tables -A PREROUTING -t raw -i eth1 -s $NET_ETH1 -j ACCEPT
  ip6tables -A PREROUTING -t raw -i eth1 -s $ROUTED_VIA_ETH1 -j ACCEPT
-- 
# Created with git-export-patch

Re: doc: Secure use of iptables and connection tracking helpers

[Pablo Neira Ayuso]

On Tue, Nov 29, 2011 at 01:55:56AM +0100, Jan Engelhardt wrote:
> Here's a patch so far.

I think that this patch is enough to include you as author, for the
time spent in reviewing it (unless you don't want that your name
appear close to us, of course ;-).

Re: doc: Secure use of iptables and connection tracking helpers

[Eric Leblond]

Hello,

Already pushed with Jan as author on github :-) 

Pablo Neira Ayuso <pablo@netfilter.org> a écrit :

>On Tue, Nov 29, 2011 at 01:55:56AM +0100, Jan Engelhardt wrote:
>> Here's a patch so far.
>
>I think that this patch is enough to include you as author, for the
>time spent in reviewing it (unless you don't want that your name
>appear close to us, of course ;-).

Re: doc: Secure use of iptables and connection tracking helpers

[Nikolay S.]

В Пн., 28/11/2011 в 18:32 +0100, Eric Leblond пишет:
> Hello,
> 
> Pablo Neira Ayuso, Patrick McHardy and I have worked on a document we've
> called "Secure use of iptables and connection tracking helpers".
> 
> This is a guide describing how to use securely the connection tracking
> helpers. This is a recommended reading for all Netfilter/Iptables users.
> 
> HTML version: http://home.regit.org/netfilter-en/secure-use-of-helpers/
> PDF version:
> http://home.regit.org/wp-content/uploads/2011/11/helper-recommandation.pdf
> 
> BR,

There is one thing in "Using the CT target to refine security" section.
If we use the CT target and pass '0' as ports to nf_conntrack_ftp as
advised in the next section, the helper name would be "ftp-0", not
"ftp". I know, that helper module naming is described somwhere, but what
if we could mention it here also?

Re: doc: Secure use of iptables and connection tracking helpers

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

Hello,

Le samedi 03 décembre 2011 à 14:06 +0400, Nikolay S. a écrit :
> В Пн., 28/11/2011 в 18:32 +0100, Eric Leblond пишет:
> > Hello,
> > 
> > Pablo Neira Ayuso, Patrick McHardy and I have worked on a document we've
> > called "Secure use of iptables and connection tracking helpers".
> > 
> > This is a guide describing how to use securely the connection tracking
> > helpers. This is a recommended reading for all Netfilter/Iptables users.
> > 
> > HTML version: http://home.regit.org/netfilter-en/secure-use-of-helpers/
> > PDF version:
> > http://home.regit.org/wp-content/uploads/2011/11/helper-recommandation.pdf
> > 
> > BR,
> 
> There is one thing in "Using the CT target to refine security" section.
> If we use the CT target and pass '0' as ports to nf_conntrack_ftp as
> advised in the next section, the helper name would be "ftp-0", not
> "ftp". I know, that helper module naming is described somwhere, but what
> if we could mention it here also?

Really good catch, I've published an update.

Thanks a lot.

BR,
--
Eric


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: doc: Secure use of iptables and connection tracking helpers

[Mr Dash Four]

> Really good catch, I've published an update.
>   
I don't want to be seen as "picky", but there is a spelling mistake at 
the 3rd line on the very first page of this document - "negociate" 
should be "negotiate". It is worth running a spell-checker on this 
entire document though - just in case I've missed something. ;-)

Re: doc: Secure use of iptables and connection tracking helpers

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

Hello,

Le samedi 03 décembre 2011 à 12:54 +0000, Mr Dash Four a écrit :
> > Really good catch, I've published an update.
> >   
> I don't want to be seen as "picky", but there is a spelling mistake at 

no problem with that.

> the 3rd line on the very first page of this document - "negociate" 
> should be "negotiate". It is worth running a spell-checker on this 
> entire document though - just in case I've missed something. ;-)

It seems your document is outdated. If not please tell me where you've
got it. And all my apologies for the spelling mistake in first version.

BR,
--
Eric



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: doc: Secure use of iptables and connection tracking helpers

[Mr Dash Four]

>>> Really good catch, I've published an update.
>>>   
>>>       
>> I don't want to be seen as "picky", but there is a spelling mistake at 
>>     
>
> no problem with that.
>   
OK then (you asked for it :-P ):

p.1 "but it is stored in a separate table and as generally a limited 
duration" ("as" should be "has")
p.2 "conjonction" should be "conjunction"
p.2 "If your clients are authorized to access to FTP outside of your 
network you can add" should be "If your clients are authorized to access 
FTP outside of your network you can add"
p.4 "has described below" ("has" should be "as")
p.4 "Once an helper is loaded" should be "Once helper is loaded"
p.4 "it will treat the packet for a given port and all IP" should be "it 
will treat the packet for a given port and all IP addresses"
p.4 "desactivate" should be "deactivate"
p.4 "It is possible to obtain this behaviour for most connection 
tracking helper module by setting to 0 the port number for the module." 
should be "It is possible to obtain this behaviour for most connection 
tracking helper modules by setting the port number for the module to 0."
p.4 "The following modules will be desactivated on all flows by default 
by doing this: ftp irc sane sip tftp" - 1) "desactivated" should be 
"deactivated"; 2) The whole sentence does not make sense: - what does 
"desactivated on all flows by default" mean? Having "deactivated on all 
flows" (with the right spelling and without the "by default" bit) makes 
more sense if you mean that by setting the "port 0" all of the listed 
modules will be deactivated.
p.4 "Some modules will no work dut to the abscence of ports parameter" 
("no" to "not" and "abscence" to "absence")
p.5 "Antispoofing" should be "Anti-spoofing"
p.5 "Helper lays on the parsing of data that come from client or from 
server" should be either "Helpers rely on parsing of data that comes 
from a client or a server" or "A helper relies on parsing of data that 
comes from a client or a server"
p.5 "It is thus important" should be "Therefore, it is important"
p.5 "Linux provides a routing based implementation" should be "Linux 
provides a routing-based implementation"
p.5 "To activate it you need to ensure that the 
/proc/sys/net/ipv4/conf/*/rp_filter" should be "To activate it you need 
to ensure that /proc/sys/net/ipv4/conf/*/rp_filter"
p.5 "The complete documentation about rp_filter is available in the file 
ip-sysctl.txt" should be "Complete documentation about rp_filter is 
available in ip-sysctl.txt"
p.6 "There is at the time of the writing no routing-based implementation 
of rp_filter in the Linux kernel." should be "At the time of writing, 
there is no routing-based implementation of rp_filter in the Linux kernel."
p.6 "anit-spoofing" should be "anti-spoofing"
p.6 "shortcutting" should be "short-cutting" or "bypassing"
p.6 "This help to reduce the load" should be "This helps reducing the load"
p.6 "The antispoofing must be done a a per-interface way" should be 
"Anti-spoofing must be done on a per-interface basis"
p.6 "There is an exception which is the interface with the default 
route" should be "There is exception, which is the interface with the 
default route"
p.6 "and have eth0 the interface with the default route" should be "and 
have the eth0 interface with a default route"
p.6 "antispoofing with the following rules" should be "anti-spoofing 
with the following rules:"


>> the 3rd line on the very first page of this document - "negociate" 
>> should be "negotiate". It is worth running a spell-checker on this 
>> entire document though - just in case I've missed something. ;-)
>>     
>
> It seems your document is outdated. If not please tell me where you've
> got it. And all my apologies for the spelling mistake in first version.
>   
I've just downloaded it from the link in your previous post/reply: 
http://home.regit.org/wp-content/uploads/2011/11/helper-recommandation.pdf

Re: doc: Secure use of iptables and connection tracking helpers

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

Hello,

Le samedi 03 décembre 2011 à 13:41 +0000, Mr Dash Four a écrit :
> >>> Really good catch, I've published an update.
> >>>   
> >>>       
> >> I don't want to be seen as "picky", but there is a spelling mistake at 
> >>     
> >
> > no problem with that.
> >   
> OK then (you asked for it :-P ):
> 
> p.1 "but it is stored in a separate table and as generally a limited 
> duration" ("as" should be "has")
> p.2 "conjonction" should be "conjunction"
> p.2 "If your clients are authorized to access to FTP outside of your 
> network you can add" should be "If your clients are authorized to access 
> FTP outside of your network you can add"
...
> p.6 "and have eth0 the interface with the default route" should be "and 
> have the eth0 interface with a default route"
> p.6 "antispoofing with the following rules" should be "anti-spoofing 
> with the following rules:"

Most of them have been fixed by Jan, I will have a cautious look.

> >> the 3rd line on the very first page of this document - "negociate" 
> >> should be "negotiate". It is worth running a spell-checker on this 
> >> entire document though - just in case I've missed something. ;-)
> >>     
> >
> > It seems your document is outdated. If not please tell me where you've
> > got it. And all my apologies for the spelling mistake in first version.
> >   
> I've just downloaded it from the link in your previous post/reply: 
> http://home.regit.org/wp-content/uploads/2011/11/helper-recommandation.pdf

Arghh, the only one link I did not update after the renaming of the
file:
http://home.regit.org/wp-content/uploads/2011/11/secure-conntrack-helpers.pdf

I'm hidding...

BR,
--
Eric

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: doc: Secure use of iptables and connection tracking helpers

[Mr Dash Four]

> Most of them have been fixed by Jan, I will have a cautious look.
>   
Much better (in addition to what I posted previously) :-D :

p.1 "tranfers" should be "transfers"
p.1 "This system lays on parsing of data coming or from the user or from 
the server. It is thus subject to attack and this is necessary to take 
some protections when using connection tracking helpers" should be "The 
system relies on parsing of data coming either from the user or the 
server. It is, therefore, vulnerable and ("all the necessary 
precautions"/"great care") must be taken when using connection tracking 
helpers."
p.1 "tracking helpers are thus dependent on" should be "tracking helpers 
are therefore dependent on"
p.2 "and it is thus deactivated by default." should be "and it is 
therefore deactivated by default."
p.2. "They permit to activate the extended but dangerous features of 
some protocols." should be "They permit activation of the extended, but 
dangerous, features of some protocols."
p.3 "All iptables lines using “-m state --state RELATED” should be used 
in conjunction with the choice of a helper. Doing that, you " should be 
"The following iptables statement should be used in conjunction with the 
choice of a helper:- “-m state --state RELATED”. By doing that, you"
p.4 "In particular, you have to do a strict anti-spoofing (has described 
below)" should be "In particular, you have to do strict anti-spoofing 
(as described below)"
p.4 "For example, let’s say we have a FTP server at IP address 1.2.3.4 
running on port 2121" should be "For example, let’s say we have FTP 
server running on IP address 1.2.3.4 and port 2121"
p.4 "We thus recommand NOT to use module options any more, and use the 
CT target instead" should be "Therefore, the use of module options is 
NOT recommended any more - please use the CT target instead."
p.4 "Each wanted helper use is then set by using a call to the CT 
target." should be "Each helper we need to use is then set by a call to 
the CT target."

> Arghh, the only one link I did not update after the renaming of the
> file:
> http://home.regit.org/wp-content/uploads/2011/11/secure-conntrack-helpers.pdf
>
> I'm hidding...
>   
No worries, I enjoyed reading this and it was educational for me too!

Re: doc: Secure use of iptables and connection tracking helpers

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Hello,

Le samedi 03 décembre 2011 à 14:33 +0000, Mr Dash Four a écrit :
> > Most of them have been fixed by Jan, I will have a cautious look.
> >   
> Much better (in addition to what I posted previously) :-D :
> 
> p.1 "tranfers" should be "transfers"
...
> > Arghh, the only one link I did not update after the renaming of the
> > file:
> > http://home.regit.org/wp-content/uploads/2011/11/secure-conntrack-helpers.pdf
> >
> > I'm hidding...
> >   
> No worries, I enjoyed reading this and it was educational for me too!

Thanks a lot for all these improvements, they almost all have been used
for the new version of the document. You've diserve to be on the author
list, but using Mr Dash Four as name is a little strange. Any other
suggestions ;)

BR,
--
Eric


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: doc: Secure use of iptables and connection tracking helpers

[Mr Dash Four]

> Thanks a lot for all these improvements, they almost all have been used
> for the new version of the document. You've diserve to be on the author
> list, but using Mr Dash Four as name is a little strange. Any other
> suggestions ;)
>   
Well, I have to tell my life story if you want to understand what's 
behind 'Mr-4' and somehow I don't think I will be doing that. If you 
really need to place me in the list of authors, just put me simply as 
'Mr-4' (or Mr Dash Four - your choice) - that will suffice, thank you.

Re: doc: Secure use of iptables and connection tracking helpers

[Jan Engelhardt]

On Sunday 2011-12-04 13:08, Mr Dash Four wrote:

>
>> Thanks a lot for all these improvements, they almost all have been used
>> for the new version of the document. You've diserve to be on the author
>> list, but using Mr Dash Four as name is a little strange. Any other
>> suggestions ;)
>>  
> Well, I have to tell my life story if you want to understand what's behind
> 'Mr-4' and somehow I don't think I will be doing that. If you really need to
> place me in the list of authors, just put me simply as 'Mr-4' (or Mr Dash Four
> - your choice) - that will suffice, thank you.

"Suggestion" usually means the striving to use real-world names, as 
are mandated in other places, e.g. kernel's DCO (Developer's 
Certificate of Origin).

Re: doc: Secure use of iptables and connection tracking helpers

[Mr Dash Four]

>> Well, I have to tell my life story if you want to understand what's behind
>> 'Mr-4' and somehow I don't think I will be doing that. If you really need to
>> place me in the list of authors, just put me simply as 'Mr-4' (or Mr Dash Four
>> - your choice) - that will suffice, thank you.
>>     
>
> "Suggestion" usually means the striving to use real-world names, as 
> are mandated in other places, e.g. kernel's DCO (Developer's 
> Certificate of Origin).
>   
The decision whether to use my "real-world name", as you put it, is 
solely mine and nobody else's. If I call myself "Mr John 'Crazy Horse' 
Stockton" instead of "Mr Dash Four" would that make you feel better? 
Besides, if you really, really must know - my alias *is* used in the 
Linux kernel's contributions list and people happily accepted that.

To conclude this, I haven't asked my name to be put in the co-authors 
(or any other) list of Eric's work and I won't be upset/angry/whatever 
if I am omitted from it. As I already indicated to him - I was happy to 
help (it was a good mental exercise on a Saturday morning, not to 
mention that it was educational for me too), so, for me, that's that.