[libvirt] [PATCH v3] nwfilter: probe for inverted ctdir
Linux netfilter at some point inverted the meaning of the '--ctdir reply' and newer netfilter implementations now expect '--ctdir original' instead and vice-versa. We probe for this netfilter change via a UDP message over loopback and 3 filtering rules applied to INPUT two times, one time with '--ctdir original' which should then work on 'fixed' netfilter and one other time with '--ctdir reply' which should only work on the 'old' netfilter. If neither one of the tests gets the data through, then the loopback device is probably not configured correctly. If both tests get the data through something must be seriously wrong. In both of these two latter cases no '--ctdir' will then be applied to the rules. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> --- v2->v3: - probing with --ctdir original and --ctdir reply v1->v2: - using virSocketAddrParseIPv4 --- src/nwfilter/nwfilter_ebiptables_driver.c | 169 ++++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) Index: libvirt-acl/src/nwfilter/nwfilter_ebiptables_driver.c =================================================================== --- libvirt-acl.orig/src/nwfilter/nwfilter_ebiptables_driver.c +++ libvirt-acl/src/nwfilter/nwfilter_ebiptables_driver.c @@ -27,6 +27,10 @@ #include <string.h> #include <sys/stat.h> #include <fcntl.h> +#include <arpa/inet.h> +#include <sys/select.h> +#include <sys/time.h> +#include <unistd.h> #include "internal.h" @@ -85,6 +89,17 @@ static char *iptables_cmd_path; static char *ip6tables_cmd_path; static char *grep_cmd_path; +/* + * --ctdir original vs. --ctdir reply's meaning was inverted in netfilter + * at some point. We probe for it. + */ +enum ctdirStatus { + CTDIR_STATUS_UNKNOWN = 0, + CTDIR_STATUS_CORRECTED = (1 << 0), + CTDIR_STATUS_OLD = (1 << 1), +}; +static enum ctdirStatus iptables_ctdir_corrected; + #define PRINT_ROOT_CHAIN(buf, prefix, ifname) \ snprintf(buf, sizeof(buf), "libvirt-%c-%s", prefix, ifname) #define PRINT_CHAIN(buf, prefix, ifname, suffix) \ @@ -1262,6 +1277,17 @@ iptablesEnforceDirection(int directionIn virNWFilterRuleDefPtr rule, virBufferPtr buf) { + switch (iptables_ctdir_corrected) { + case CTDIR_STATUS_UNKNOWN: + /* could not be determined or s.th. is seriously wrong */ + return; + case CTDIR_STATUS_CORRECTED: + directionIn = !directionIn; + break; + case CTDIR_STATUS_OLD: + break; + } + if (rule->tt != VIR_NWFILTER_RULE_DIRECTION_INOUT) virBufferAsprintf(buf, " -m conntrack --ctdir %s", (directionIn) ? "Original" @@ -4304,6 +4330,146 @@ ebiptablesDriverTestCLITools(void) return ret; } +static void +ebiptablesDriverProbeCtdir(void) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + static const char cmdline[] = + "$IPT -%c INPUT %c -i lo -p udp --dport %hu " + "-m state --state ESTABLISHED -j ACCEPT " CMD_SEPARATOR + "$IPT -%c INPUT %c -i lo -p udp --dport %hu " + "-m conntrack --ctdir %s -j ACCEPT " CMD_SEPARATOR + "$IPT -%c INPUT %c -i lo -p udp --dport %hu -j DROP"; + /* + * Above '--ctdir original' gets this test to receive a message on + * 'fixed' netfilter. + */ + unsigned short port; + int ssockfd = -1, csockfd = -1; + virSocketAddr saddr; + struct sockaddr_in *serveraddr = &saddr.data.inet4; + fd_set readfds; + struct timeval timeout = { + .tv_sec = 0, + .tv_usec = 1000 * 200, + }; + int n, i, results = 0; + const char *ctdiropts[2] = { "original", "reply" }; + unsigned char data[10]; + + if (virSocketAddrParseIPv4(&saddr, "127.0.0.1") < 0) { + VIR_ERROR(_("Could not parse IP address")); + goto cleanup; + } + + if ((ssockfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0 || + (csockfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { + VIR_ERROR(_("Could not open UDP socket")); + goto cleanup; + } + + for (port = 0xffff; port > 1024; port--) { + serveraddr->sin_port = htons(port); + if (bind(ssockfd, (struct sockaddr *)serveraddr, + sizeof(*serveraddr)) == 0) + break; + } + if (port == 1024) { + VIR_ERROR(_("Could not bind to any UDP socket")); + goto cleanup; + } + + i = 0; + while (true) { + NWFILTER_SET_IPTABLES_SHELLVAR(&buf); + virBufferAsprintf(&buf, cmdline, + 'I', '1', port, + 'I', '2', port, ctdiropts[i], + 'I', '3', port); + + if (virBufferError(&buf)) { + virReportOOMError(); + goto cleanup; + } + + if (ebiptablesExecCLI(&buf, NULL, NULL) < 0) { + VIR_ERROR(_("Could not apply iptables rules")); + goto cleanup_iptables; + } + + virBufferFreeAndReset(&buf); + + if (sendto(csockfd, cmdline, 1, 0, (struct sockaddr *)serveraddr, + sizeof(*serveraddr)) < 0) { + VIR_ERROR(_("Could not send to UDP socket")); + goto cleanup_iptables; + } + + FD_ZERO(&readfds); + FD_SET(ssockfd, &readfds); + + while (true) { + n = select(ssockfd + 1, &readfds, NULL, NULL, &timeout); + if (n < 0) { + if (errno == EINTR) + continue; + VIR_ERROR(_("Select failed")); + goto cleanup_iptables; + } + if (n == 0) { + VIR_INFO("Ctdir probing received no data"); + break; + } + VIR_INFO("Ctdir probing received data"); + results |= (1 << i); + read(ssockfd, data, sizeof(data)); + break; + } + + if (i + 1 == ARRAY_CARDINALITY(ctdiropts)) + break; + + NWFILTER_SET_IPTABLES_SHELLVAR(&buf); + virBufferAsprintf(&buf, cmdline, + 'D', ' ', port, + 'D', ' ', port, ctdiropts[i], + 'D', ' ', port); + ebiptablesExecCLI(&buf, NULL, NULL); + + i++; + } + + switch (results) { + case 0x0: + /* no test passed -- loopback device not setup? */ + case 0x3: + /* both test passed -- s.th. is wrong */ + iptables_ctdir_corrected = CTDIR_STATUS_UNKNOWN; + break; + case 0x1: + iptables_ctdir_corrected = CTDIR_STATUS_CORRECTED; + break; + case 0x2: + iptables_ctdir_corrected = CTDIR_STATUS_OLD; + break; + } + +cleanup_iptables: + virBufferFreeAndReset(&buf); + + NWFILTER_SET_IPTABLES_SHELLVAR(&buf); + virBufferAsprintf(&buf, cmdline, + 'D', ' ', port, + 'D', ' ', port, ctdiropts[i], + 'D', ' ', port); + ebiptablesExecCLI(&buf, NULL, NULL); + +cleanup: + virBufferFreeAndReset(&buf); + VIR_FORCE_CLOSE(ssockfd); + VIR_FORCE_CLOSE(csockfd); +} + static int ebiptablesDriverInit(bool privileged) { @@ -4341,6 +4507,9 @@ ebiptablesDriverInit(bool privileged) return -ENOTSUP; } + if (iptables_cmd_path) + ebiptablesDriverProbeCtdir(); + ebiptables_driver.flags = TECHDRV_FLAG_INITIALIZED; return 0;
On 03/22/2013 04:37 PM, Stefan Berger wrote:
Linux netfilter at some point inverted the meaning of the '--ctdir reply' and newer netfilter implementations now expect '--ctdir original' instead and vice-versa. We probe for this netfilter change via a UDP message over loopback and 3 filtering rules applied to INPUT two times, one time with '--ctdir original' which should then work on 'fixed' netfilter and one other time with '--ctdir reply' which should only work on the 'old' netfilter. If neither one of the tests gets the data through, then the loopback device is probably not configured correctly. If both tests get the data through something must be seriously wrong. In both of these two latter cases no '--ctdir' will then be applied to the rules.
Are you going to let 1.0.4 sail without 'something like this'?
On 03/26/2013 07:59 AM, Stefan Berger wrote:
On 03/22/2013 04:37 PM, Stefan Berger wrote:
Linux netfilter at some point inverted the meaning of the '--ctdir reply' and newer netfilter implementations now expect '--ctdir original' instead and vice-versa. We probe for this netfilter change via a UDP message over loopback and 3 filtering rules applied to INPUT two times, one time with '--ctdir original' which should then work on 'fixed' netfilter and one other time with '--ctdir reply' which should only work on the 'old' netfilter. If neither one of the tests gets the data through, then the loopback device is probably not configured correctly. If both tests get the data through something must be seriously wrong. In both of these two latter cases no '--ctdir' will then be applied to the rules.
Are you going to let 1.0.4 sail without 'something like this'?
My opinion is that the patch we should apply should be a simple patch that just removes use of --ctdir. According to the netfilter developer who responded to the thread on libvirt-users, it doesn't add any extra security not already provided by conntrack: https://www.redhat.com/archives/libvirt-users/2013-March/msg00121.html https://www.redhat.com/archives/libvirt-users/2013-March/msg00128.html Not being an expert on netfilter internals, I can't dispute his claim. Does anyone else have an opinion?
On 03/27/2013 10:30 AM, Laine Stump wrote:
My opinion is that the patch we should apply should be a simple patch that just removes use of --ctdir. According to the netfilter developer who responded to the thread on libvirt-users, it doesn't add any extra security not already provided by conntrack:
https://www.redhat.com/archives/libvirt-users/2013-March/msg00121.html https://www.redhat.com/archives/libvirt-users/2013-March/msg00128.html
Not being an expert on netfilter internals, I can't dispute his claim.
Does anyone else have an opinion?
What filters specifically caused the use of --ctdir, and are they broken if we omit the use of --ctdir? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 03/27/2013 02:01 PM, Eric Blake wrote:
On 03/27/2013 10:30 AM, Laine Stump wrote:
My opinion is that the patch we should apply should be a simple patch that just removes use of --ctdir. According to the netfilter developer who responded to the thread on libvirt-users, it doesn't add any extra security not already provided by conntrack:
https://www.redhat.com/archives/libvirt-users/2013-March/msg00121.html https://www.redhat.com/archives/libvirt-users/2013-March/msg00128.html
Not being an expert on netfilter internals, I can't dispute his claim.
Does anyone else have an opinion? What filters specifically caused the use of --ctdir, and are they broken if we omit the use of --ctdir?
It depends on how you write the filters that the --ctdir is being used. iirc: The effect of the --ctdir usage is that if one has an incoming rule and and outgoing rule with the same IP address on the 'other' side the check for an ESTABLISHED state is not enough to ACCEPT the traffic, if one was to remove one of the rules while communication in both directions was occurring and an immediate cut of the traffic in one way was expected. The effect so far was that if the rule for the incoming rule was removed it would cut the incoming traffic immediately while the traffic in outgoing direction was uninterrupted. I think that if we remove this now the traffic in both directions will continue. I will verify tomorrow. I don't quite understand the skepticism towards this patch (v3) that tries to keep what is there right now. Stefan
On 03/27/2013 09:09 PM, Stefan Berger wrote:
On 03/27/2013 02:01 PM, Eric Blake wrote:
On 03/27/2013 10:30 AM, Laine Stump wrote:
My opinion is that the patch we should apply should be a simple patch that just removes use of --ctdir. According to the netfilter developer who responded to the thread on libvirt-users, it doesn't add any extra security not already provided by conntrack:
https://www.redhat.com/archives/libvirt-users/2013-March/msg00121.html https://www.redhat.com/archives/libvirt-users/2013-March/msg00128.html
Not being an expert on netfilter internals, I can't dispute his claim.
Does anyone else have an opinion? What filters specifically caused the use of --ctdir, and are they broken if we omit the use of --ctdir?
It depends on how you write the filters that the --ctdir is being used.
iirc: The effect of the --ctdir usage is that if one has an incoming rule and and outgoing rule with the same IP address on the 'other' side the check for an ESTABLISHED state is not enough to ACCEPT the traffic, if one was to remove one of the rules while communication in both directions was occurring and an immediate cut of the traffic in one way was expected. The effect so far was that if the rule for the incoming rule was removed it would cut the incoming traffic immediately while the traffic in outgoing direction was uninterrupted. I think that if we remove this now the traffic in both directions will continue. I will verify tomorrow.
Verified. I have a ping running from the VM to destination 'A' and from 'A' to the VM. The --ctdir enforces the direction of the traffic and if one of the following rules is removed, the ping is immediately cut. <rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule> The ping is not cut anymore upon removal of one of the above rules if --ctdir was to be removed entirely.
For reference of people new to this thread, here is the start of the thread: https://www.redhat.com/archives/libvir-list/2013-March/msg01403.html This concerns changes to libvirt to cope with the newly discovered (by us :-) difference in interpretation of ctdir by different versions of netfilter. On 03/28/2013 07:11 AM, Stefan Berger wrote:
On 03/27/2013 09:09 PM, Stefan Berger wrote:
On 03/27/2013 02:01 PM, Eric Blake wrote:
On 03/27/2013 10:30 AM, Laine Stump wrote:
My opinion is that the patch we should apply should be a simple patch that just removes use of --ctdir. According to the netfilter developer who responded to the thread on libvirt-users, it doesn't add any extra security not already provided by conntrack:
https://www.redhat.com/archives/libvirt-users/2013-March/msg00121.html https://www.redhat.com/archives/libvirt-users/2013-March/msg00128.html
Not being an expert on netfilter internals, I can't dispute his claim.
Does anyone else have an opinion? What filters specifically caused the use of --ctdir, and are they broken if we omit the use of --ctdir?
It depends on how you write the filters that the --ctdir is being used.
iirc: The effect of the --ctdir usage is that if one has an incoming rule and and outgoing rule with the same IP address on the 'other' side the check for an ESTABLISHED state is not enough to ACCEPT the traffic, if one was to remove one of the rules while communication in both directions was occurring and an immediate cut of the traffic in one way was expected. The effect so far was that if the rule for the incoming rule was removed it would cut the incoming traffic immediately while the traffic in outgoing direction was uninterrupted. I think that if we remove this now the traffic in both directions will continue. I will verify tomorrow.
Verified. I have a ping running from the VM to destination 'A' and from 'A' to the VM. The --ctdir enforces the direction of the traffic and if one of the following rules is removed, the ping is immediately cut.
<rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule>
The ping is not cut anymore upon removal of one of the above rules if --ctdir was to be removed entirely.
Okay, as I understand from your description, the difference is that when a ping in one direction is already in action, and you remove the rule allowing that ping, that existing ping "session" will continue to be allowed *if* there is still a rule allowing pings in the other direction. Is that correct? I'm guessing that *new* attempts to ping in that direction will no longer be allowed though, is that also correct? For the benefit of Pablo and the other netfilter developers, can you paste the iptables commands that are generated for the two rules above? Possibly they can suggest alternative rules that have the desired effect. If they have no alternatives, then I do now agree that we shouldn't just scrap --ctdir. Then we have two choices: 1) take your patch, which hopefully will successfully guess the polarity of --ctdir correctly in all cases. 2) switch unconditionally to the new "correct" polarity of --ctdir, release-note the heck out of it, and require that any distro with a kernel old enough to have the old style --ctdir backport at least the one patch to netfilter to change that. My comments about (1): while I'll again say that the patch truly is poetic in its ability to overcome obstacles, it's really a workaround for a bug, and as time goes on will become less and less relevant (and more and more difficult to explain/rationalize). I really think I would prefer to be broken on very old distros rather than have that patch in the tree (although others may have a different opinion, and I would gracefully withdraw my objection in that case). About (2): Fedora at least as far back as F16 has a new enough kernel/iptables (iptables-1.4.12) that it uses the new polarity for --ctdir, and no older Fedora is supported. RHEL6 and CentOS6 still have iptables-1.4.7, so they have the old polarity. I'd be willing to bet that RHEL6 would take the netfilter patch to change --ctdir; of course that would leave us with temporary brokenness for anybody who upgraded their kernel without upgrading libvirt, or vice-versa. (That temporary breakage has me a bit concerned, actually, and may mandate a patch like yours, at least applied downstream-only for RHEL/CentOS builds of libvirt.) Can maintainers for other distros comment on the version of iptables their distros have in all releases still being supported? It would be good to know just who would be broken by changing this (and who would be fixed, of course)
On 03/28/2013 10:36 AM, Laine Stump wrote:
For reference of people new to this thread, here is the start of the thread:
https://www.redhat.com/archives/libvir-list/2013-March/msg01403.html
This concerns changes to libvirt to cope with the newly discovered (by us :-) difference in interpretation of ctdir by different versions of netfilter.
On 03/27/2013 09:09 PM, Stefan Berger wrote:
On 03/27/2013 02:01 PM, Eric Blake wrote:
On 03/27/2013 10:30 AM, Laine Stump wrote:
My opinion is that the patch we should apply should be a simple patch that just removes use of --ctdir. According to the netfilter developer who responded to the thread on libvirt-users, it doesn't add any extra security not already provided by conntrack:
https://www.redhat.com/archives/libvirt-users/2013-March/msg00121.html https://www.redhat.com/archives/libvirt-users/2013-March/msg00128.html
Not being an expert on netfilter internals, I can't dispute his claim.
Does anyone else have an opinion? What filters specifically caused the use of --ctdir, and are they broken if we omit the use of --ctdir? It depends on how you write the filters that the --ctdir is being used.
iirc: The effect of the --ctdir usage is that if one has an incoming rule and and outgoing rule with the same IP address on the 'other' side the check for an ESTABLISHED state is not enough to ACCEPT the traffic, if one was to remove one of the rules while communication in both directions was occurring and an immediate cut of the traffic in one way was expected. The effect so far was that if the rule for the incoming rule was removed it would cut the incoming traffic immediately while the traffic in outgoing direction was uninterrupted. I think that if we remove this now the traffic in both directions will continue. I will verify tomorrow. Verified. I have a ping running from the VM to destination 'A' and from 'A' to the VM. The --ctdir enforces the direction of the traffic and if one of the following rules is removed, the ping is immediately cut.
<rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule>
The ping is not cut anymore upon removal of one of the above rules if --ctdir was to be removed entirely. Okay, as I understand from your description, the difference is that when a ping in one direction is already in action, and you remove the rule allowing that ping, that existing ping "session" will continue to be allowed *if* there is still a rule allowing pings in the other
On 03/28/2013 07:11 AM, Stefan Berger wrote: direction. Is that correct? I'm guessing that *new* attempts to ping in that direction will no longer be allowed though, is that also correct?
For the benefit of Pablo and the other netfilter developers, can you paste the iptables commands that are generated for the two rules above? Possibly they can suggest alternative rules that have the desired effect.
First off, there are multiple ways one can write the filtering rules in nwfilter, either stateless or stateful: http://libvirt.org/formatnwfilter.html#nwfwrite Thus the filter here is only one example how one can write a stateful filter for traffic from/to a VM: <filter name='ctdirtest' chain='ipv4' priority='-700'> <uuid>582c2fe6-569a-f366-58fb-f995f1a559ce</uuid> <rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule> <rule action='drop' direction='inout' priority='500'> <all/> </rule> </filter> The filter above creates the following types of rules -- some rules are omitted that goto into these user-defined rules. Chain FI-vnet0 (1 references) pkts bytes target prot opt in out source destination 6 504 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED ctdir ORIGINAL 0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED ctdir REPLY 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FO-vnet0 (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED ctdir REPLY 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED ctdir ORIGINAL 53 3235 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain HI-vnet0 (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED ctdir ORIGINAL 0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED ctdir REPLY 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Those may not be the most efficient rules, yet they provide the possibility to remove a rule from the XML and cut the connection immediately due to the ctdir usage.
If they have no alternatives, then I do now agree that we shouldn't just scrap --ctdir. Then we have two choices:
1) take your patch, which hopefully will successfully guess the polarity of --ctdir correctly in all cases.
Why 'guess' -- it 'probes' for it and does actual testing.
2) switch unconditionally to the new "correct" polarity of --ctdir, release-note the heck out of it, and require that any distro with a kernel old enough to have the old style --ctdir backport at least the one patch to netfilter to change that.
Not a good idea IMHO because it would break on older kernels.
My comments about (1): while I'll again say that the patch truly is poetic in its ability to overcome obstacles, it's really a workaround for a bug, and as time goes on will become less and less relevant (and more and more difficult to explain/rationalize). I really think I would prefer to be broken on very old distros rather than have that patch in the tree (although others may have a different opinion, and I would gracefully withdraw my objection in that case).
About (2): Fedora at least as far back as F16 has a new enough kernel/iptables (iptables-1.4.12) that it uses the new polarity for --ctdir, and no older Fedora is supported. RHEL6 and CentOS6 still have iptables-1.4.7, so they have the old polarity. I'd be willing to bet that RHEL6 would take the netfilter patch to change --ctdir; of course that would leave us with temporary brokenness for anybody who upgraded their kernel without upgrading libvirt, or vice-versa.
You not only need to convert the filtering rules (and only do it once) but also re-program the users minds that may be used to that odd mixup of directions.
On Thu, Mar 28, 2013 at 10:54:01AM -0400, Stefan Berger wrote:
On 03/28/2013 10:36 AM, Laine Stump wrote:
For reference of people new to this thread, here is the start of the thread:
https://www.redhat.com/archives/libvir-list/2013-March/msg01403.html
This concerns changes to libvirt to cope with the newly discovered (by us :-) difference in interpretation of ctdir by different versions of netfilter.
On 03/27/2013 09:09 PM, Stefan Berger wrote:
On 03/27/2013 02:01 PM, Eric Blake wrote:
On 03/27/2013 10:30 AM, Laine Stump wrote:
My opinion is that the patch we should apply should be a simple patch that just removes use of --ctdir. According to the netfilter developer who responded to the thread on libvirt-users, it doesn't add any extra security not already provided by conntrack:
https://www.redhat.com/archives/libvirt-users/2013-March/msg00121.html https://www.redhat.com/archives/libvirt-users/2013-March/msg00128.html
Not being an expert on netfilter internals, I can't dispute his claim.
Does anyone else have an opinion? What filters specifically caused the use of --ctdir, and are they broken if we omit the use of --ctdir? It depends on how you write the filters that the --ctdir is being used.
iirc: The effect of the --ctdir usage is that if one has an incoming rule and and outgoing rule with the same IP address on the 'other' side the check for an ESTABLISHED state is not enough to ACCEPT the traffic, if one was to remove one of the rules while communication in both directions was occurring and an immediate cut of the traffic in one way was expected. The effect so far was that if the rule for the incoming rule was removed it would cut the incoming traffic immediately while the traffic in outgoing direction was uninterrupted. I think that if we remove this now the traffic in both directions will continue. I will verify tomorrow. Verified. I have a ping running from the VM to destination 'A' and from 'A' to the VM. The --ctdir enforces the direction of the traffic and if one of the following rules is removed, the ping is immediately cut.
<rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule>
The ping is not cut anymore upon removal of one of the above rules if --ctdir was to be removed entirely. Okay, as I understand from your description, the difference is that when a ping in one direction is already in action, and you remove the rule allowing that ping, that existing ping "session" will continue to be allowed *if* there is still a rule allowing pings in the other
On 03/28/2013 07:11 AM, Stefan Berger wrote: direction. Is that correct? I'm guessing that *new* attempts to ping in that direction will no longer be allowed though, is that also correct?
For the benefit of Pablo and the other netfilter developers, can you paste the iptables commands that are generated for the two rules above? Possibly they can suggest alternative rules that have the desired effect.
First off, there are multiple ways one can write the filtering rules in nwfilter, either stateless or stateful:
http://libvirt.org/formatnwfilter.html#nwfwrite
Thus the filter here is only one example how one can write a stateful filter for traffic from/to a VM:
<filter name='ctdirtest' chain='ipv4' priority='-700'> <uuid>582c2fe6-569a-f366-58fb-f995f1a559ce</uuid> <rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule> <rule action='drop' direction='inout' priority='500'> <all/> </rule> </filter>
The filter above creates the following types of rules -- some rules are omitted that goto into these user-defined rules.
Chain FI-vnet0 (1 references) pkts bytes target prot opt in out source destination 6 504 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED ctdir ORIGINAL 0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED ctdir REPLY 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Conntrack is already internally validating that directions are correct for you, so no need for those --ctdir. Let me explain why: If conntrack gets an ICMP echo reply entering through the NEW state, it will consider it invalid since it is not coming as reply to an ICMP echo request. [ In case you want to have a look at the internal implementation. See linux/net/ipv4/netfilter/nf_conntrack_proto_icmp.c, function icmp_new(), the valid ICMP message that can enter through the NEW state are: static const u_int8_t valid_new[] = { [ICMP_ECHO] = 1, [ICMP_TIMESTAMP] = 1, [ICMP_INFO_REQUEST] = 1, [ICMP_ADDRESS] = 1 }; ] So using: 0.0.0.0/0 state NEW,ESTABLISHED is just fine if you drop INVALID traffic in your rule-set: iptables -A F0-vnet0 -m state INVALID -j LOG --log-prefix "invalid: " iptables -A F0-vnet0 -m state INVALID -j DROP Which are the common rules that you add in a sane stateful rule-set (the log line could be removed if you want to discard traffic silently). Same thing for TCP traffic. The connection tracking table already validates in its internal state machine that the correct state transitions are actually happening. That validation includes that packets are coming in the good direction. In sum: The --ctdir is not providing more security. We did not have it originally in the `state' match, it was a late extension to the conntrack match. My advice here: Just rely on conntrack states and drop invalid traffic, it will do the direction validation that you're trying to achieve with that rule-set. Hope that it helps. Regards.
On 03/28/2013 01:17 PM, Pablo Neira Ayuso wrote:
On Thu, Mar 28, 2013 at 10:54:01AM -0400, Stefan Berger wrote:
On 03/28/2013 10:36 AM, Laine Stump wrote:
For reference of people new to this thread, here is the start of the thread:
https://www.redhat.com/archives/libvir-list/2013-March/msg01403.html
This concerns changes to libvirt to cope with the newly discovered (by us :-) difference in interpretation of ctdir by different versions of netfilter.
On 03/27/2013 09:09 PM, Stefan Berger wrote:
On 03/27/2013 02:01 PM, Eric Blake wrote:
On 03/27/2013 10:30 AM, Laine Stump wrote: > My opinion is that the patch we should apply should be a simple patch > that just removes use of --ctdir. According to the netfilter developer > who responded to the thread on libvirt-users, it doesn't add any extra > security not already provided by conntrack: > > https://www.redhat.com/archives/libvirt-users/2013-March/msg00121.html > https://www.redhat.com/archives/libvirt-users/2013-March/msg00128.html > > Not being an expert on netfilter internals, I can't dispute his claim. > > Does anyone else have an opinion? What filters specifically caused the use of --ctdir, and are they broken if we omit the use of --ctdir? It depends on how you write the filters that the --ctdir is being used.
iirc: The effect of the --ctdir usage is that if one has an incoming rule and and outgoing rule with the same IP address on the 'other' side the check for an ESTABLISHED state is not enough to ACCEPT the traffic, if one was to remove one of the rules while communication in both directions was occurring and an immediate cut of the traffic in one way was expected. The effect so far was that if the rule for the incoming rule was removed it would cut the incoming traffic immediately while the traffic in outgoing direction was uninterrupted. I think that if we remove this now the traffic in both directions will continue. I will verify tomorrow. Verified. I have a ping running from the VM to destination 'A' and from 'A' to the VM. The --ctdir enforces the direction of the traffic and if one of the following rules is removed, the ping is immediately cut.
<rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule>
The ping is not cut anymore upon removal of one of the above rules if --ctdir was to be removed entirely. Okay, as I understand from your description, the difference is that when a ping in one direction is already in action, and you remove the rule allowing that ping, that existing ping "session" will continue to be allowed *if* there is still a rule allowing pings in the other
On 03/28/2013 07:11 AM, Stefan Berger wrote: direction. Is that correct? I'm guessing that *new* attempts to ping in that direction will no longer be allowed though, is that also correct?
For the benefit of Pablo and the other netfilter developers, can you paste the iptables commands that are generated for the two rules above? Possibly they can suggest alternative rules that have the desired effect.
First off, there are multiple ways one can write the filtering rules in nwfilter, either stateless or stateful:
http://libvirt.org/formatnwfilter.html#nwfwrite
Thus the filter here is only one example how one can write a stateful filter for traffic from/to a VM:
<filter name='ctdirtest' chain='ipv4' priority='-700'> <uuid>582c2fe6-569a-f366-58fb-f995f1a559ce</uuid> <rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule> <rule action='drop' direction='inout' priority='500'> <all/> </rule> </filter>
The filter above creates the following types of rules -- some rules are omitted that goto into these user-defined rules.
Chain FI-vnet0 (1 references) pkts bytes target prot opt in out source destination 6 504 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED ctdir ORIGINAL 0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED ctdir REPLY 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Conntrack is already internally validating that directions are correct for you, so no need for those --ctdir. Let me explain why:
If conntrack gets an ICMP echo reply entering through the NEW state, it will consider it invalid since it is not coming as reply to an ICMP echo request. [...]
In sum: The --ctdir is not providing more security. We did not have it originally in the `state' match, it was a late extension to the conntrack match.
My advice here: Just rely on conntrack states and drop invalid traffic, it will do the direction validation that you're trying to achieve with that rule-set.
I don't see that removing a filtering rule, as can be done by an nwfilter user, invalidates the connection tracking state so that a rule dropping upon INVALID state would then kick in. IMO the connection is still in ESTABLISHED state and thus will act on a rule checking on ESTABLISHED state. A simple test here: iptables -I INPUT 1 -m state --state INVALID -j DROP iptables -I INPUT 2 -p icmp -m state --state ESTABLISHED -j ACCEPT iptables -I INPUT 3 -p icmp -j ACCEPT Now ping that machine. Pings should work now Following what you said iptables -D INPUT -p icmp -j ACCEPT should now cause the first rule to kick in for that ICMP stream now that the rule is gone. This is not the case with my machine and the ping simply continues -- in this case I have used a RHEL 6 installation with 2.6.32 kernel. IMO we still need --ctdir. Stefan
On Thu, Mar 28, 2013 at 01:55:09PM -0400, Stefan Berger wrote:
On 03/28/2013 01:17 PM, Pablo Neira Ayuso wrote:
On Thu, Mar 28, 2013 at 10:54:01AM -0400, Stefan Berger wrote:
On 03/28/2013 10:36 AM, Laine Stump wrote:
For reference of people new to this thread, here is the start of the thread:
https://www.redhat.com/archives/libvir-list/2013-March/msg01403.html
This concerns changes to libvirt to cope with the newly discovered (by us :-) difference in interpretation of ctdir by different versions of netfilter.
On 03/27/2013 09:09 PM, Stefan Berger wrote:
On 03/27/2013 02:01 PM, Eric Blake wrote: >On 03/27/2013 10:30 AM, Laine Stump wrote: >>My opinion is that the patch we should apply should be a simple patch >>that just removes use of --ctdir. According to the netfilter developer >>who responded to the thread on libvirt-users, it doesn't add any extra >>security not already provided by conntrack: >> >>https://www.redhat.com/archives/libvirt-users/2013-March/msg00121.html >>https://www.redhat.com/archives/libvirt-users/2013-March/msg00128.html >> >>Not being an expert on netfilter internals, I can't dispute his claim. >> >>Does anyone else have an opinion? >What filters specifically caused the use of --ctdir, and are they >broken >if we omit the use of --ctdir? It depends on how you write the filters that the --ctdir is being used.
iirc: The effect of the --ctdir usage is that if one has an incoming rule and and outgoing rule with the same IP address on the 'other' side the check for an ESTABLISHED state is not enough to ACCEPT the traffic, if one was to remove one of the rules while communication in both directions was occurring and an immediate cut of the traffic in one way was expected. The effect so far was that if the rule for the incoming rule was removed it would cut the incoming traffic immediately while the traffic in outgoing direction was uninterrupted. I think that if we remove this now the traffic in both directions will continue. I will verify tomorrow. Verified. I have a ping running from the VM to destination 'A' and from 'A' to the VM. The --ctdir enforces the direction of the traffic and if one of the following rules is removed, the ping is immediately cut.
<rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule>
The ping is not cut anymore upon removal of one of the above rules if --ctdir was to be removed entirely. Okay, as I understand from your description, the difference is that when a ping in one direction is already in action, and you remove the rule allowing that ping, that existing ping "session" will continue to be allowed *if* there is still a rule allowing pings in the other
On 03/28/2013 07:11 AM, Stefan Berger wrote: direction. Is that correct? I'm guessing that *new* attempts to ping in that direction will no longer be allowed though, is that also correct?
For the benefit of Pablo and the other netfilter developers, can you paste the iptables commands that are generated for the two rules above? Possibly they can suggest alternative rules that have the desired effect.
First off, there are multiple ways one can write the filtering rules in nwfilter, either stateless or stateful:
http://libvirt.org/formatnwfilter.html#nwfwrite
Thus the filter here is only one example how one can write a stateful filter for traffic from/to a VM:
<filter name='ctdirtest' chain='ipv4' priority='-700'> <uuid>582c2fe6-569a-f366-58fb-f995f1a559ce</uuid> <rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule> <rule action='drop' direction='inout' priority='500'> <all/> </rule> </filter>
The filter above creates the following types of rules -- some rules are omitted that goto into these user-defined rules.
Chain FI-vnet0 (1 references) pkts bytes target prot opt in out source destination 6 504 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED ctdir ORIGINAL 0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED ctdir REPLY 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Conntrack is already internally validating that directions are correct for you, so no need for those --ctdir. Let me explain why:
If conntrack gets an ICMP echo reply entering through the NEW state, it will consider it invalid since it is not coming as reply to an ICMP echo request. [...]
In sum: The --ctdir is not providing more security. We did not have it originally in the `state' match, it was a late extension to the conntrack match.
My advice here: Just rely on conntrack states and drop invalid traffic, it will do the direction validation that you're trying to achieve with that rule-set.
I don't see that removing a filtering rule, as can be done by an nwfilter user, invalidates the connection tracking state so that a rule dropping upon INVALID state would then kick in. IMO the connection is still in ESTABLISHED state and thus will act on a rule checking on ESTABLISHED state. A simple test here:
iptables -I INPUT 1 -m state --state INVALID -j DROP iptables -I INPUT 2 -p icmp -m state --state ESTABLISHED -j ACCEPT iptables -I INPUT 3 -p icmp -j ACCEPT
Now ping that machine. Pings should work now
Following what you said
iptables -D INPUT -p icmp -j ACCEPT
should now cause the first rule to kick in for that ICMP stream now that the rule is gone. This is not the case with my machine and the ping simply continues -- in this case I have used a RHEL 6 installation with 2.6.32 kernel.
If default policy is DROP, then no rules will match, so the ping will be dropped. The rule with the INVALID state only matches if, for example, conntrack sees an ICMP echo reply without having seen an echo request before.
On 03/28/2013 03:09 PM, Pablo Neira Ayuso wrote:
On Thu, Mar 28, 2013 at 01:55:09PM -0400, Stefan Berger wrote:
On 03/28/2013 01:17 PM, Pablo Neira Ayuso wrote:
On Thu, Mar 28, 2013 at 10:54:01AM -0400, Stefan Berger wrote:
On 03/28/2013 10:36 AM, Laine Stump wrote:
For reference of people new to this thread, here is the start of the thread:
https://www.redhat.com/archives/libvir-list/2013-March/msg01403.html
This concerns changes to libvirt to cope with the newly discovered (by us :-) difference in interpretation of ctdir by different versions of netfilter.
On 03/27/2013 09:09 PM, Stefan Berger wrote: > On 03/27/2013 02:01 PM, Eric Blake wrote: >> On 03/27/2013 10:30 AM, Laine Stump wrote: >>> My opinion is that the patch we should apply should be a simple patch >>> that just removes use of --ctdir. According to the netfilter developer >>> who responded to the thread on libvirt-users, it doesn't add any extra >>> security not already provided by conntrack: >>> >>> https://www.redhat.com/archives/libvirt-users/2013-March/msg00121.html >>> https://www.redhat.com/archives/libvirt-users/2013-March/msg00128.html >>> >>> Not being an expert on netfilter internals, I can't dispute his claim. >>> >>> Does anyone else have an opinion? >> What filters specifically caused the use of --ctdir, and are they >> broken >> if we omit the use of --ctdir? > It depends on how you write the filters that the --ctdir is being used. > > iirc: The effect of the --ctdir usage is that if one has an incoming > rule and and outgoing rule with the same IP address on the 'other' > side the check for an ESTABLISHED state is not enough to ACCEPT the > traffic, if one was to remove one of the rules while communication in > both directions was occurring and an immediate cut of the traffic in > one way was expected. The effect so far was that if the rule for the > incoming rule was removed it would cut the incoming traffic > immediately while the traffic in outgoing direction was > uninterrupted. I think that if we remove this now the traffic in both > directions will continue. I will verify tomorrow. Verified. I have a ping running from the VM to destination 'A' and from 'A' to the VM. The --ctdir enforces the direction of the traffic and if one of the following rules is removed, the ping is immediately cut.
<rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule>
The ping is not cut anymore upon removal of one of the above rules if --ctdir was to be removed entirely. Okay, as I understand from your description, the difference is that when a ping in one direction is already in action, and you remove the rule allowing that ping, that existing ping "session" will continue to be allowed *if* there is still a rule allowing pings in the other
On 03/28/2013 07:11 AM, Stefan Berger wrote: direction. Is that correct? I'm guessing that *new* attempts to ping in that direction will no longer be allowed though, is that also correct?
For the benefit of Pablo and the other netfilter developers, can you paste the iptables commands that are generated for the two rules above? Possibly they can suggest alternative rules that have the desired effect. First off, there are multiple ways one can write the filtering rules in nwfilter, either stateless or stateful:
http://libvirt.org/formatnwfilter.html#nwfwrite
Thus the filter here is only one example how one can write a stateful filter for traffic from/to a VM:
<filter name='ctdirtest' chain='ipv4' priority='-700'> <uuid>582c2fe6-569a-f366-58fb-f995f1a559ce</uuid> <rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule> <rule action='drop' direction='inout' priority='500'> <all/> </rule> </filter>
The filter above creates the following types of rules -- some rules are omitted that goto into these user-defined rules.
Chain FI-vnet0 (1 references) pkts bytes target prot opt in out source destination 6 504 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED ctdir ORIGINAL 0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED ctdir REPLY 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Conntrack is already internally validating that directions are correct for you, so no need for those --ctdir. Let me explain why:
If conntrack gets an ICMP echo reply entering through the NEW state, it will consider it invalid since it is not coming as reply to an ICMP echo request. [...] In sum: The --ctdir is not providing more security. We did not have it originally in the `state' match, it was a late extension to the conntrack match.
My advice here: Just rely on conntrack states and drop invalid traffic, it will do the direction validation that you're trying to achieve with that rule-set. I don't see that removing a filtering rule, as can be done by an nwfilter user, invalidates the connection tracking state so that a rule dropping upon INVALID state would then kick in. IMO the connection is still in ESTABLISHED state and thus will act on a rule checking on ESTABLISHED state. A simple test here:
iptables -I INPUT 1 -m state --state INVALID -j DROP iptables -I INPUT 2 -p icmp -m state --state ESTABLISHED -j ACCEPT iptables -I INPUT 3 -p icmp -j ACCEPT
Now ping that machine. Pings should work now
Following what you said
iptables -D INPUT -p icmp -j ACCEPT
should now cause the first rule to kick in for that ICMP stream now that the rule is gone. This is not the case with my machine and the ping simply continues -- in this case I have used a RHEL 6 installation with 2.6.32 kernel. If default policy is DROP, then no rules will match, so the ping will be dropped.
Unless it runs into a rule '-m state --state ESTABLISHED -j ACCEPT', which I would say is typical for stateful filtering. The point is '--ctdir' helped us before to cut off traffic and we still need it.
The rule with the INVALID state only matches if, for example, conntrack sees an ICMP echo reply without having seen an echo request before.
Well, yeah, but this is not the case we're after. Stefan
On Thu, Mar 28, 2013 at 03:24:37PM -0400, Stefan Berger wrote:
On 03/28/2013 03:09 PM, Pablo Neira Ayuso wrote:
On Thu, Mar 28, 2013 at 01:55:09PM -0400, Stefan Berger wrote:
On 03/28/2013 01:17 PM, Pablo Neira Ayuso wrote:
On Thu, Mar 28, 2013 at 10:54:01AM -0400, Stefan Berger wrote:
On 03/28/2013 10:36 AM, Laine Stump wrote:
For reference of people new to this thread, here is the start of the thread:
https://www.redhat.com/archives/libvir-list/2013-March/msg01403.html
This concerns changes to libvirt to cope with the newly discovered (by us :-) difference in interpretation of ctdir by different versions of netfilter.
On 03/28/2013 07:11 AM, Stefan Berger wrote: >On 03/27/2013 09:09 PM, Stefan Berger wrote: >>On 03/27/2013 02:01 PM, Eric Blake wrote: >>>On 03/27/2013 10:30 AM, Laine Stump wrote: >>>>My opinion is that the patch we should apply should be a simple patch >>>>that just removes use of --ctdir. According to the netfilter developer >>>>who responded to the thread on libvirt-users, it doesn't add any extra >>>>security not already provided by conntrack: >>>> >>>>https://www.redhat.com/archives/libvirt-users/2013-March/msg00121.html >>>>https://www.redhat.com/archives/libvirt-users/2013-March/msg00128.html >>>> >>>>Not being an expert on netfilter internals, I can't dispute his claim. >>>> >>>>Does anyone else have an opinion? >>>What filters specifically caused the use of --ctdir, and are they >>>broken >>>if we omit the use of --ctdir? >>It depends on how you write the filters that the --ctdir is being used. >> >>iirc: The effect of the --ctdir usage is that if one has an incoming >>rule and and outgoing rule with the same IP address on the 'other' >>side the check for an ESTABLISHED state is not enough to ACCEPT the >>traffic, if one was to remove one of the rules while communication in >>both directions was occurring and an immediate cut of the traffic in >>one way was expected. The effect so far was that if the rule for the >>incoming rule was removed it would cut the incoming traffic >>immediately while the traffic in outgoing direction was >>uninterrupted. I think that if we remove this now the traffic in both >>directions will continue. I will verify tomorrow. >Verified. I have a ping running from the VM to destination 'A' and >from 'A' to the VM. The --ctdir enforces the direction of the traffic >and if one of the following rules is removed, the ping is immediately >cut. > > <rule action='accept' direction='out' priority='500'> > <icmp/> > </rule> > <rule action='accept' direction='in' priority='500'> > <icmp/> > </rule> > >The ping is not cut anymore upon removal of one of the above rules if >--ctdir was to be removed entirely. Okay, as I understand from your description, the difference is that when a ping in one direction is already in action, and you remove the rule allowing that ping, that existing ping "session" will continue to be allowed *if* there is still a rule allowing pings in the other direction. Is that correct? I'm guessing that *new* attempts to ping in that direction will no longer be allowed though, is that also correct?
For the benefit of Pablo and the other netfilter developers, can you paste the iptables commands that are generated for the two rules above? Possibly they can suggest alternative rules that have the desired effect. First off, there are multiple ways one can write the filtering rules in nwfilter, either stateless or stateful:
http://libvirt.org/formatnwfilter.html#nwfwrite
Thus the filter here is only one example how one can write a stateful filter for traffic from/to a VM:
<filter name='ctdirtest' chain='ipv4' priority='-700'> <uuid>582c2fe6-569a-f366-58fb-f995f1a559ce</uuid> <rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='in' priority='500'> <icmp/> </rule> <rule action='drop' direction='inout' priority='500'> <all/> </rule> </filter>
The filter above creates the following types of rules -- some rules are omitted that goto into these user-defined rules.
Chain FI-vnet0 (1 references) pkts bytes target prot opt in out source destination 6 504 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED ctdir ORIGINAL 0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED ctdir REPLY 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Conntrack is already internally validating that directions are correct for you, so no need for those --ctdir. Let me explain why:
If conntrack gets an ICMP echo reply entering through the NEW state, it will consider it invalid since it is not coming as reply to an ICMP echo request. [...] In sum: The --ctdir is not providing more security. We did not have it originally in the `state' match, it was a late extension to the conntrack match.
My advice here: Just rely on conntrack states and drop invalid traffic, it will do the direction validation that you're trying to achieve with that rule-set. I don't see that removing a filtering rule, as can be done by an nwfilter user, invalidates the connection tracking state so that a rule dropping upon INVALID state would then kick in. IMO the connection is still in ESTABLISHED state and thus will act on a rule checking on ESTABLISHED state. A simple test here:
iptables -I INPUT 1 -m state --state INVALID -j DROP iptables -I INPUT 2 -p icmp -m state --state ESTABLISHED -j ACCEPT iptables -I INPUT 3 -p icmp -j ACCEPT
Now ping that machine. Pings should work now
Following what you said
iptables -D INPUT -p icmp -j ACCEPT
should now cause the first rule to kick in for that ICMP stream now that the rule is gone. This is not the case with my machine and the ping simply continues -- in this case I have used a RHEL 6 installation with 2.6.32 kernel. If default policy is DROP, then no rules will match, so the ping will be dropped.
Unless it runs into a rule '-m state --state ESTABLISHED -j ACCEPT', which I would say is typical for stateful filtering.
Not sure what you mean. The first packet of an ICMP echo request will not ever match -m state --state ESTABLISHED.
The point is '--ctdir' helped us before to cut off traffic and we still need it.
The rule with the INVALID state only matches if, for example, conntrack sees an ICMP echo reply without having seen an echo request before.
Well, yeah, but this is not the case we're after.
participants (4)
-
Eric Blake -
Laine Stump -
Pablo Neira Ayuso -
Stefan Berger