secure-conntrack-helpers: updates

secure-conntrack-helpers: updates

[Jan Engelhardt]

The following changes since commit 68d21fbfc9c8cc646f8408cf37761bc2d5584222:

  More english fix. (2011-12-04 11:48:54 +0100)
[sic!!1]

are available in the git repository at:
  git://dev.medozas.de/secure-conntrack-helpers master

Jan Engelhardt (5):
      Use modern -m conntrack match
      Sentence ordering
      Selected corrections from Mr. Dash Four
      Selected corrections from Mr. Dash Four
      Plural forms

 secure-conntrack-helpers.rst |   42 +++++++++++++++++++++---------------------
 1 files changed, 21 insertions(+), 21 deletions(-)

[PATCH 1/5] Use modern -m conntrack match

[Jan Engelhardt]

---
 secure-conntrack-helpers.rst |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/secure-conntrack-helpers.rst b/secure-conntrack-helpers.rst
index acf6670..cbd5fd5 100644
--- a/secure-conntrack-helpers.rst
+++ b/secure-conntrack-helpers.rst
@@ -90,7 +90,7 @@ blindly use helpers. You must take into account the topology of your network
 when setting parameters linked to a helper.
 
 For each helper, you must carefully open the RELATED flow. All iptables statement 
-using "-m state --state RELATED" should be used in conjunction with the
+using "-m conntrack --ctstate RELATED" should be used in conjunction with the
 choice of a helper and of IP parameters.  Doing that, you will be able to describe
 how the helper must be used with respect to your network and information system
 architecture.
@@ -100,26 +100,26 @@ Example: FTP helper
 
 For example, if you run an FTP server, you can setup ::
 
- iptables -A FORWARD -m state --state RELATED -m helper \
+ iptables -A FORWARD -m conntrack --ctstate RELATED -m helper \
  	--helper ftp -d $MY_FTP_SERVER -p tcp \
 	--dport 1024: -j ACCEPT
 
 If your clients are authorized to access FTP outside of your network, you
 can add ::
 
- iptables -A FORWARD -m state --state RELATED -m helper \
+ iptables -A FORWARD -m conntrack --ctstate RELATED -m helper \
  	--helper ftp -o $OUT_IFACE -p tcp \
 	--dport 1024: -j ACCEPT
- iptables -A FORWARD -m state --state RELATED -m helper \
+ iptables -A FORWARD -m conntrack --ctstate RELATED -m helper \
  	--helper ftp -i $OUT_IFACE -p tcp \
 	--dport 1024: -j ACCEPT
 
 The same syntax applies to IPV6 ::
 
- ip6tables -A FORWARD -m state --state RELATED -m helper \
+ ip6tables -A FORWARD -m conntrack --ctstate RELATED -m helper \
  	--helper ftp -o $OUT_IFACE -p tcp \
 	--dport 1024: -j ACCEPT
- ip6tables -A FORWARD -m state --state RELATED -m helper \
+ ip6tables -A FORWARD -m conntrack --ctstate RELATED -m helper \
  	--helper ftp -i $OUT_IFACE -p tcp \
 	--dport 1024: -j ACCEPT
 
@@ -129,7 +129,7 @@ Example: SIP helper
 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 \
+ iptables -A FORWARD -m conntrack --ctstate RELATED -m helper \
  	--helper sip -d $ISP_RTP_SERVER -p udp -j ACCEPT
 
 Example: h323 helper
-- 
1.7.3.4

[PATCH 2/5] Sentence ordering

[Jan Engelhardt]

"this" refers to a near object (cf. "that" for far), so s/by doing
this/by doing that/, or just move the subclause to the front.
---
 secure-conntrack-helpers.rst |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/secure-conntrack-helpers.rst b/secure-conntrack-helpers.rst
index cbd5fd5..1acaf2e 100644
--- a/secure-conntrack-helpers.rst
+++ b/secure-conntrack-helpers.rst
@@ -190,8 +190,8 @@ modules by setting the port number for the module to 0. For example ::
 
  modprobe nf_conntrack_$PROTO ports=0
 
-The following modules will be deactivated on all flows by default by doing
-this:
+By doing this, the following modules will be deactivated on all flows
+by default:
 
  - ftp
  - irc
@@ -199,7 +199,7 @@ this:
  - sip
  - tftp
 
-Some modules will not work due to the absence of ports parameter:
+Due to the absence of a "ports" parameter, some modules will not work:
 
  - amanda
  - h323
-- 
1.7.3.4

[PATCH 3/5] Selected corrections from Mr. Dash Four

[Jan Engelhardt]

References: <4EDA2715.7030006@googlemail.com>
Date: 2011-12-03 13:41:41 +0000
---
 secure-conntrack-helpers.rst |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/secure-conntrack-helpers.rst b/secure-conntrack-helpers.rst
index 1acaf2e..13fc263 100644
--- a/secure-conntrack-helpers.rst
+++ b/secure-conntrack-helpers.rst
@@ -216,8 +216,8 @@ For example, if the option has been used for the ftp helper, one should use ::
 
 
 
-Antispoofing
-============
+Anti-spoofing
+=============
 Helpers and anti-spoofing
 -------------------------
 
@@ -232,7 +232,7 @@ 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
-`/proc/sys/net/ipv4/conf/*/rp_filter` files contain 1.  The complete
+`/proc/sys/net/ipv4/conf/*/rp_filter` files contain 1.  Complete
 documentation about `rp_filter` is available in the file `ip-sysctl.txt`
 in the `Documentation/networking/` directory of the Linux tree.
 
@@ -265,7 +265,7 @@ The documentation at the time of the writing is reproduced here ::
     Default value is 0. Note that some distributions
     enable it in startup scripts.
 
-At the time of the writing there is no routing-based implementation of
+At the time of the writing, there is no routing-based implementation of
 `rp_filter` in the Linux kernel for IPv6. Manual anti-spoofing via Netfilter
 rules is thus needed.
 
@@ -276,7 +276,7 @@ The best way to do anti-spoofing is to use filtering rules in the RAW table.
 This has the great advantage of bypassing the connection tracking. This
 helps to reduce the load that could be created by some flooding.
 
-The anti-spoofing must be done on a per-interface basis. For each interface,
+Anti-spoofing must be done on a per-interface basis. For each interface,
 we must list the authorized network on the interface. There is 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
-- 
1.7.3.4

[PATCH 4/5] Selected corrections from Mr. Dash Four

[Jan Engelhardt]

References: <4EDA332F.2010409@googlemail.com>
References: http://marc.info/?l=netfilter&m=132292290523592&w=2
Date: 2011-12-03 14:33:19 +0000
---
 secure-conntrack-helpers.rst |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/secure-conntrack-helpers.rst b/secure-conntrack-helpers.rst
index 13fc263..18a7a81 100644
--- a/secure-conntrack-helpers.rst
+++ b/secure-conntrack-helpers.rst
@@ -43,12 +43,12 @@ 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 address of the person who is the target of the DCC.
 
-The degree of freedom due to connection tracking helpers are thus dependent on
+The degree of freedom due to connection tracking helpers are therefore dependent on
 the nature of the protocol. Some protocols have dangerous extensions, and these
 are disabled by default by Netfilter. The user has to pass an option during
 loading of the module to enable this dangerous protocol features. 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
+another arbitrary server. This could lead to a hole in the DMZ and it is therefore
 deactivated by default. To enable it, you've got to pass the `loose` option
 with the `1` value.
 
@@ -91,7 +91,7 @@ when setting parameters linked to a helper.
 
 For each helper, you must carefully open the RELATED flow. All iptables statement 
 using "-m conntrack --ctstate RELATED" should be used in conjunction with the
-choice of a helper and of IP parameters.  Doing that, you will be able to describe
+choice of a helper and of IP parameters. By doing that, you will be able to describe
 how the helper must be used with respect to your network and information system
 architecture.
 
@@ -144,7 +144,7 @@ Securing the signaling flow
 
 You will also need to build carefully crafted rules for the authorization
 of flows involving connection tracking helpers. In particular, you have
-to do a strict anti-spoofing (as described below) to avoid traffic injection
+to do strict anti-spoofing (as described below) to avoid traffic injection
 from other interfaces.
 
 
-- 
1.7.3.4

[PATCH 5/5] Plural forms

[Jan Engelhardt]

About the second hunk: it does need an article if one does not talk
about an unspecified plural form.
---
 secure-conntrack-helpers.rst |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/secure-conntrack-helpers.rst b/secure-conntrack-helpers.rst
index 18a7a81..4c56a8d 100644
--- a/secure-conntrack-helpers.rst
+++ b/secure-conntrack-helpers.rst
@@ -89,7 +89,7 @@ Following the preceding 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 to a helper.
 
-For each helper, you must carefully open the RELATED flow. All iptables statement 
+For each helper, you must carefully open the RELATED flow. All iptables statements 
 using "-m conntrack --ctstate RELATED" should be used in conjunction with the
 choice of a helper and of IP parameters. By doing that, you will be able to describe
 how the helper must be used with respect to your network and information system
@@ -277,7 +277,7 @@ This has the great advantage of bypassing the connection tracking. This
 helps to reduce the load that could be created by some flooding.
 
 Anti-spoofing must be done on a per-interface basis. For each interface,
-we must list the authorized network on the interface. There is exception,
+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 being the interface with the default route.
-- 
1.7.3.4

Re: [PATCH 3/5] Selected corrections from Mr. Dash Four

[Mr Dash Four]

> -At the time of the writing there is no routing-based implementation of
> +At the time of the writing, there is no routing-based implementation of
>  `rp_filter` in the Linux kernel for IPv6. Manual anti-spoofing via Netfilter
>  rules is thus needed.
>   
I don't mean to be picky (again) but the above should be "At the time of 
writing, there is no routing-based implementation of `rp_filter` in the 
Linux kernel for IPv6 - manual anti-spoofing via Netfilter rules is 
needed." or "At the time of writing, there is no routing-based 
implementation of `rp_filter` in the Linux kernel for IPv6, therefore 
manual anti-spoofing via Netfilter rules is needed."

> -The anti-spoofing must be done on a per-interface basis. For each interface,
> +Anti-spoofing must be done on a per-interface basis. For each interface,
>  we must list the authorized network on the interface. There is exception,
>   
"For each interface, we must list the authorized network on that interface."

Re: [PATCH 5/5] Plural forms

[Mr Dash Four]

> @@ -277,7 +277,7 @@ This has the great advantage of bypassing the connection tracking. This
>  helps to reduce the load that could be created by some flooding.
>   
"This has the great advantage of bypassing the connection tracking and 
helps reducing the load that could be created by some flooding."

Re: [PATCH 5/5] Plural forms

[Eric Leblond]

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

Hello,

Jan, all patches have been applied.

Proposal by Mr Dash Four have been added to the document.

Thanks a lot!

On Sun, 2011-12-18 at 15:14 +0000, Mr Dash Four wrote:
> > @@ -277,7 +277,7 @@ This has the great advantage of bypassing the connection tracking. This
> >  helps to reduce the load that could be created by some flooding.
> >   
> "This has the great advantage of bypassing the connection tracking and 
> helps reducing the load that could be created by some flooding."
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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