Also use iptables-save #36

Merged
merged 1 commit into from Jan 16, 2014

Conversation

Projects
None yet
2 participants
@mizzy
Owner

mizzy commented Jan 16, 2014

Because RedHat 5 iptables does not have -S option.

mizzy added a commit that referenced this pull request Jan 16, 2014

@mizzy mizzy merged commit 81eda47 into master Jan 16, 2014

1 check passed

default The Travis CI build passed
Details

@mizzy mizzy deleted the change-iptables branch Jan 16, 2014

@jhx

This comment has been minimized.

Show comment
Hide comment
@jhx

jhx Jan 24, 2014

This code does not work for me on CentOS 5.10, serverspec v0.14.3. Below is an excerpt of the output from kitchen verify:

...

network::firewall       
  iptables       
iptables v1.3.5: Unknown arg `-S'       
       Try `iptables -h' or 'iptables --help' for more information.
    drops INPUT packets (FAILED - 1)       
iptables v1.3.5: Unknown arg `-S'       
       Try `iptables -h' or 'iptables --help' for more information.
    drops FORWARD packets (FAILED - 2)       
iptables v1.3.5: Unknown arg `-S'       
       Try `iptables -h' or 'iptables --help' for more information.
    accepts OUTPUT packets (FAILED - 3)       
iptables v1.3.5: Unknown arg `-S'       

...

Failures:       

  1) network::firewall iptables drops INPUT packets       
     Failure/Error: expect(subject).to have_rule('-P INPUT DROP')       
       env PATH=/sbin:/usr/sbin:$PATH iptables -S | grep -- -P\ INPUT\ DROP || env PATH=/sbin:/usr/sbin:$PATH iptables-save | grep -- -P\ INPUT\ DROP       
       expected Iptables "" to have rule "-P INPUT DROP"       
     # /tmp/busser/suites/serverspec/firewall_spec.rb:7:in `block (3 levels) in <top (required)>'       

  2) network::firewall iptables drops FORWARD packets       
     Failure/Error: expect(subject).to have_rule('-P FORWARD DROP')       
       env PATH=/sbin:/usr/sbin:$PATH iptables -S | grep -- -P\ FORWARD\ DROP || env PATH=/sbin:/usr/sbin:$PATH iptables-save | grep -- -P\ FORWARD\ DROP       
       expected Iptables "" to have rule "-P FORWARD DROP"       
     # /tmp/busser/suites/serverspec/firewall_spec.rb:11:in `block (3 levels) in <top (required)>'       

  3) network::firewall iptables accepts OUTPUT packets       
     Failure/Error: expect(subject).to have_rule('-P OUTPUT ACCEPT')       
       env PATH=/sbin:/usr/sbin:$PATH iptables -S | grep -- -P\ OUTPUT\ ACCEPT || env PATH=/sbin:/usr/sbin:$PATH iptables-save | grep -- -P\ OUTPUT\ ACCEPT       
       expected Iptables "" to have rule "-P OUTPUT ACCEPT"       
     # /tmp/busser/suites/serverspec/firewall_spec.rb:15:in `block (3 levels) in <top (required)>'       

I'm not sure why it errors because the OR statement (||) should cause the second part of the bash command to run. When I execute sudo /sbin/iptables -S || sudo /sbin/iptables-save, it runs successfully with an exit code of 0.

Any ideas why this doesn't work?

jhx commented on 4232af6 Jan 24, 2014

This code does not work for me on CentOS 5.10, serverspec v0.14.3. Below is an excerpt of the output from kitchen verify:

...

network::firewall       
  iptables       
iptables v1.3.5: Unknown arg `-S'       
       Try `iptables -h' or 'iptables --help' for more information.
    drops INPUT packets (FAILED - 1)       
iptables v1.3.5: Unknown arg `-S'       
       Try `iptables -h' or 'iptables --help' for more information.
    drops FORWARD packets (FAILED - 2)       
iptables v1.3.5: Unknown arg `-S'       
       Try `iptables -h' or 'iptables --help' for more information.
    accepts OUTPUT packets (FAILED - 3)       
iptables v1.3.5: Unknown arg `-S'       

...

Failures:       

  1) network::firewall iptables drops INPUT packets       
     Failure/Error: expect(subject).to have_rule('-P INPUT DROP')       
       env PATH=/sbin:/usr/sbin:$PATH iptables -S | grep -- -P\ INPUT\ DROP || env PATH=/sbin:/usr/sbin:$PATH iptables-save | grep -- -P\ INPUT\ DROP       
       expected Iptables "" to have rule "-P INPUT DROP"       
     # /tmp/busser/suites/serverspec/firewall_spec.rb:7:in `block (3 levels) in <top (required)>'       

  2) network::firewall iptables drops FORWARD packets       
     Failure/Error: expect(subject).to have_rule('-P FORWARD DROP')       
       env PATH=/sbin:/usr/sbin:$PATH iptables -S | grep -- -P\ FORWARD\ DROP || env PATH=/sbin:/usr/sbin:$PATH iptables-save | grep -- -P\ FORWARD\ DROP       
       expected Iptables "" to have rule "-P FORWARD DROP"       
     # /tmp/busser/suites/serverspec/firewall_spec.rb:11:in `block (3 levels) in <top (required)>'       

  3) network::firewall iptables accepts OUTPUT packets       
     Failure/Error: expect(subject).to have_rule('-P OUTPUT ACCEPT')       
       env PATH=/sbin:/usr/sbin:$PATH iptables -S | grep -- -P\ OUTPUT\ ACCEPT || env PATH=/sbin:/usr/sbin:$PATH iptables-save | grep -- -P\ OUTPUT\ ACCEPT       
       expected Iptables "" to have rule "-P OUTPUT ACCEPT"       
     # /tmp/busser/suites/serverspec/firewall_spec.rb:15:in `block (3 levels) in <top (required)>'       

I'm not sure why it errors because the OR statement (||) should cause the second part of the bash command to run. When I execute sudo /sbin/iptables -S || sudo /sbin/iptables-save, it runs successfully with an exit code of 0.

Any ideas why this doesn't work?

This comment has been minimized.

Show comment
Hide comment
@mizzy

mizzy Jan 25, 2014

Owner

Please tell me the output of sudo /sbin/iptables-save.

Owner

mizzy replied Jan 25, 2014

Please tell me the output of sudo /sbin/iptables-save.

@jhx

This comment has been minimized.

Show comment
Hide comment
@jhx

jhx Jan 25, 2014

Below is the output requested:

$ sudo /sbin/iptables-save
# Generated by iptables-save v1.3.5 on Sat Jan 25 01:36:18 2014
*nat
:PREROUTING ACCEPT [2:620]
:POSTROUTING ACCEPT [3:244]
:OUTPUT ACCEPT [3:244]
COMMIT
# Completed on Sat Jan 25 01:36:18 2014
# Generated by iptables-save v1.3.5 on Sat Jan 25 01:36:18 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [75:68048]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT 
-A RH-Firewall-1-INPUT -i lo -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 
COMMIT
# Completed on Sat Jan 25 01:36:18 2014

jhx commented Jan 25, 2014

Below is the output requested:

$ sudo /sbin/iptables-save
# Generated by iptables-save v1.3.5 on Sat Jan 25 01:36:18 2014
*nat
:PREROUTING ACCEPT [2:620]
:POSTROUTING ACCEPT [3:244]
:OUTPUT ACCEPT [3:244]
COMMIT
# Completed on Sat Jan 25 01:36:18 2014
# Generated by iptables-save v1.3.5 on Sat Jan 25 01:36:18 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [75:68048]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT 
-A RH-Firewall-1-INPUT -i lo -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 
COMMIT
# Completed on Sat Jan 25 01:36:18 2014
@mizzy

This comment has been minimized.

Show comment
Hide comment
@mizzy

mizzy Jan 25, 2014

Owner

This output does not contain -P INPUT DROP, -P FORWARD DROP and -P OUTPUT ACCEPT.
So it should fail obviously.

Owner

mizzy commented Jan 25, 2014

This output does not contain -P INPUT DROP, -P FORWARD DROP and -P OUTPUT ACCEPT.
So it should fail obviously.

@jhx

This comment has been minimized.

Show comment
Hide comment
@jhx

jhx Jan 25, 2014

Fair enough. I would expect the spec to provide a more-reasonable failure message. Is there any way to output the real failure instead of this warning to keep the next person from chasing a rabbit? This is why I looked into the iptables command switches:

network::firewall       
  iptables       
iptables v1.3.5: Unknown arg `-S'       
       Try `iptables -h' or 'iptables --help' for more information.
    drops INPUT packets (FAILED - 1)       
iptables v1.3.5: Unknown arg `-S'       
       Try `iptables -h' or 'iptables --help' for more information.
    drops FORWARD packets (FAILED - 2)       
iptables v1.3.5: Unknown arg `-S'       
       Try `iptables -h' or 'iptables --help' for more information.
    accepts OUTPUT packets (FAILED - 3)       
iptables v1.3.5: Unknown arg `-S'

Nowhere in this does it actually tell me that the grep failed to find my text.

jhx commented Jan 25, 2014

Fair enough. I would expect the spec to provide a more-reasonable failure message. Is there any way to output the real failure instead of this warning to keep the next person from chasing a rabbit? This is why I looked into the iptables command switches:

network::firewall       
  iptables       
iptables v1.3.5: Unknown arg `-S'       
       Try `iptables -h' or 'iptables --help' for more information.
    drops INPUT packets (FAILED - 1)       
iptables v1.3.5: Unknown arg `-S'       
       Try `iptables -h' or 'iptables --help' for more information.
    drops FORWARD packets (FAILED - 2)       
iptables v1.3.5: Unknown arg `-S'       
       Try `iptables -h' or 'iptables --help' for more information.
    accepts OUTPUT packets (FAILED - 3)       
iptables v1.3.5: Unknown arg `-S'

Nowhere in this does it actually tell me that the grep failed to find my text.

@jhx

This comment has been minimized.

Show comment
Hide comment
@jhx

jhx Jan 25, 2014

One other aspect to consider is the output from iptables -S does not match that of iptables-save. In CentOS 6.5, I get the following output:

$ sudo iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N RH-Firewall-1-INPUT
-A INPUT -j RH-Firewall-1-INPUT 
-A RH-Firewall-1-INPUT -i lo -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 
$ sudo iptables-save
# Generated by iptables-save v1.4.7 on Sat Jan 25 01:53:37 2014
*nat
:PREROUTING ACCEPT [5:752]
:POSTROUTING ACCEPT [17:1070]
:OUTPUT ACCEPT [17:1070]
COMMIT
# Completed on Sat Jan 25 01:53:37 2014
# Generated by iptables-save v1.4.7 on Sat Jan 25 01:53:37 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [2916:213497]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT 
-A RH-Firewall-1-INPUT -i lo -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 
COMMIT
# Completed on Sat Jan 25 01:53:37 2014

My spec passes on CentOS 6.5 in the first example because iptables -S succeeds; however, it will not succeed as-written on CentOS 5.10 because the spec sees the second example output.

For the short-term, I will adjust my spec to match either output. Thanks for your help identifying this.

jhx commented Jan 25, 2014

One other aspect to consider is the output from iptables -S does not match that of iptables-save. In CentOS 6.5, I get the following output:

$ sudo iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N RH-Firewall-1-INPUT
-A INPUT -j RH-Firewall-1-INPUT 
-A RH-Firewall-1-INPUT -i lo -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 
$ sudo iptables-save
# Generated by iptables-save v1.4.7 on Sat Jan 25 01:53:37 2014
*nat
:PREROUTING ACCEPT [5:752]
:POSTROUTING ACCEPT [17:1070]
:OUTPUT ACCEPT [17:1070]
COMMIT
# Completed on Sat Jan 25 01:53:37 2014
# Generated by iptables-save v1.4.7 on Sat Jan 25 01:53:37 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [2916:213497]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT 
-A RH-Firewall-1-INPUT -i lo -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 
COMMIT
# Completed on Sat Jan 25 01:53:37 2014

My spec passes on CentOS 6.5 in the first example because iptables -S succeeds; however, it will not succeed as-written on CentOS 5.10 because the spec sees the second example output.

For the short-term, I will adjust my spec to match either output. Thanks for your help identifying this.

jhx added a commit to jhx/cookbook-network that referenced this pull request Jan 25, 2014

@jhx jhx referenced this pull request in jhx/cookbook-network Jan 25, 2014

Merged

Fix #36 rewrite firewall_spec to pass on 5.10 #37

@mizzy

This comment has been minimized.

Show comment
Hide comment
@mizzy

mizzy Jan 25, 2014

Owner

Thanks for your feedback.

Owner

mizzy commented Jan 25, 2014

Thanks for your feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment