puppetlabs / puppetlabs-firewall Goto Github PK

From my iptables-save output:
-A INPUT -m state --state RELATED,ESTABLISHED -m comment --comment "000b allow established or related sessions" -j ACCEPT

Then from "puppet resource firewall"

Error: Could not run: Parameter name failed on Firewall[RELATED,ESTABLISHED]: Invalid value "RELATED,ESTABLISHED". Valid values match /^\d+[[:alpha:][:digit:][:punct:][:space:]]+$/.

Tried reversing the order for my input, but iptables-save puts it in that order.

puppetlabs-firewall (v0.2.1)
puppet 3.1.1
RHEL 5, 64 bit

Are you planning to work around this? Seems like it the functionality should just be removed from the module. Idk.

Improvements on #133

Persistence may fail on fresh Debian/Ubuntu nodes if Package['iptables-persistent'] isn't installed before the first Firewall[] resource is created.

Possible solutions:

1. Have the type auto-require the package if it exists in the catalog. Is this bad form?
2. Write a flag file to indicate that persistence should be attempted on the next run even if no rules have changed.

I have an iptables configuration that contains a few rules in the nat table similar to the following:

-A POSTROUTING -s 192.168.1.0/24 ! -d 192.168.1.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535

The parsing code appears to be choking on the exclamation point in the rule:

$ puppet agent --test --debug
[snip]
debug: Prefetching iptables resources for firewall
debug: Puppet::Type::Firewall::ProviderIptables: [prefetch(resources)]
debug: Puppet::Type::Firewall::ProviderIptables: [instances]
debug: Puppet::Type::Firewall::ProviderIptables: Executing '/sbin/iptables-save'
err: Could not prefetch firewall provider 'iptables': Invalid address from IPAddr.new: !
[snip]
info: Applying configuration version '1363803270'
debug: Puppet::Type::Firewall::ProviderIptables: [instances]
debug: Puppet::Type::Firewall::ProviderIptables: Executing '/sbin/iptables-save'
err: /Firewall[500 accept munin connections from munin master]: Could not evaluate: Invalid address from IPAddr.new: !

I would maybe like it not to do that or at least fail in a way that still allows it to apply the rules I've specified in my manifests.

Could it be possible to make opensuse/SLES support available for puppetlabs-firewall.
both have iptables in there default repo's.

Currently it is only available in the type apache::vhost

If you just use the base class you install apache but you can't open the http port.

You could add an independent firewall resource, but if you include apache more than once (ex : apache required by many other modules), then :

• you get errors because of multiple declaration if you use the same resource name
  or
• you have many rules in the live firewall, just to open port 80, and this is not clean

Currently I use a separate module 'apachefw' that just opens the http port and I

include apache
include apachefw

I can't use apache::vhost for the same reason : I include it in other modules and then I would have multiple declarations of the vhost

That's why it would be nice to have it handled with the apache module

Based on work here: 000a586

We should probably add the installation of iptables itself.

Hi guys, we're experiencing a problem whereby when we set a UID as a username, the run applies cleanly, but a subsequent run will attempt to amend the change by substituting the UID for the username.

For example:

class test_firewall {

        $uid = 'root'

        firewall { '00001 test uid':
            chain       => 'OUTPUT',
            proto       => 'tcp',
            dport       => '3189',
            source      => undef,
            destination => undef,
            action      => 'accept',
            uid         => $uid,
        }
}

class { 'test_firewall': }

results in (and repeated in subsequent runs):

vagrant@server:~$ sudo puppet apply --verbose --logdest console --detailed-exitcodes --show_diff --color=true firewall_test.pp
info: Applying configuration version '1366800808'
notice: /Firewall[00001 test uid]/uid: uid changed '0' to 'root'
notice: Firewall[00001 test uid](provider=iptables): Properties changed - updating rule
notice: Finished catalog run in 0.69 seconds

Is this expected behavior? If so, is there any way to set the UID as a username without experiencing the change on a subsequent run?

Thanks,
Andrew

Yesterday I tried to use puppetlabs-firewall on a very minimal CentOS 5 and it bailed because the iptables package was not installed. After installing that there was also an error about iptables_save exiting with code 1 which I could work around with by calling service iptables save manually. I'd expect puppetlabs-firewall to do this for me.

        firewall { '520 dns':
                chain => 'OUTPUT',
                dport => '53',
                proto => [ 'tcp','udp' ],
                action => 'accept',
        }

Currently generates only tcp

Chain OUTPUT (policy ACCEPT 133 packets, 14604 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport dports 53 /* 520 dns */ 

Everyone seems to think this is safer, and it might make parsing etc. easier.

Hey, Iv tried using puppet firewall on centos with the following rules:

firewall { "JMS port":
dport => "5672",
jump => "ACCEPT",
state => "NEW",
proto => "tcp",
}

firewall { "Allowing rabbit managment port":
  dport => "55672",
  jump => "ACCEPT",
  state => "NEW",
  proto => "tcp",
}

firewall { "Allow jmx":
dport => "9999",
jump => "ACCEPT",
state => "NEW",
proto => "tcp",
}

firewall { "Allow rmi":
dport => "1099",
jump => "ACCEPT",
state => "NEW",
proto => "tcp",
}

firewall { "Allow clarity":
dport => "80",
jump => "ACCEPT",
state => "NEW",
proto => "tcp",
}

Instead of skipping existing rules on consecutive runs same rules are duplicated again:

-A INPUT -p tcp -m multiport --dports 80 -m comment --comment "Allow clarity" -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m multiport --dports 9999 -m comment --comment "Allow jmx" -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m multiport --dports 5672 -m comment --comment "JMS port" -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m multiport --dports 1099 -m comment --comment "Allow rmi" -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m multiport --dports 55672 -m comment --comment "Allowing rabbit managment port" -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m multiport --dports 9999 -m comment --comment "Allow jmx" -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m multiport --dports 55672 -m comment --comment "Allowing rabbit managment port" -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m multiport --dports 1099 -m comment --comment "Allow rmi" -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m multiport --dports 80 -m comment --comment "Allow clarity" -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m multiport --dports 5672 -m comment --comment "JMS port" -m state --state NEW -j ACCEPT

Iv also had to change the following method so that it will work on ruby 1.8.5 (I know old but its centos default):

def self.instances
debug "Converting existing rules to resources"
rules = []
# lines method isn't defined in ruby 1.8.5
ipsave.split("\n") do |line|
unless line =~ /^#\s+|^:\S+|^COMMIT/
if line =~ /^/
table = line.sub(//, "")
else
if hash = rule_to_hash(line, table)
rules << new(hash)
end
end
end
end
rules
end

Let me know if I can provide more info

Thanks
Ronen

Hello!

How i can combine fail2ban and this module?
I tryed:

exec { 'fail2ban':
command => $operatingsystem ? {
/(debian|Ubuntu)/ => '/usr/bin/fail2ban-client reload',
/(RedHat|CentOS)/ => '/usr/bin/fail2ban-client reload',
},
schedule => 'daily',
refreshonly => true,
subscribe => Resources["firewall"],
}

But it is not help for me. I want to f2b was not related to the firewall-module. And if Firewall was changed - f2b make reload. Thanks.
I don't know where i can asking is yet.

I just tried to create a log all rule - but it failed, due to comment and log_prefix NOT being enclosed in ". (see issue before this)

I removed that - but puppet run still fails EVERY time - because it for some reason - still tries to apply it:
err: /Firewall[998 Log all]/ensure: change from present to absent failed: Execution of '/sbin/iptables -t filter -D INPUT -m comment --comment 998 Log all -j LOG --log-prefix default drop' returned 1: iptables: Bad rule (does a matching rule exist in that chain?).

It must be caching somewhere?

If you have a rule like the following:

firewall { "090 preroute 192.168.1.1:80":
    chain       => 'PREROUTING',
    proto       => 'tcp',
    destination => "192.168.1.1",
    dport       => '80',
    toports     => '80',
    jump        => 'REDIRECT',
    table       => 'nat',
}

If you later delete the firewall rule, on the next puppet run it is unable to
delete the rule with output something along the lines of:

err: /Firewall[090 preroute 192.168.1.1:80]/ensure: change from present to absent failed: Execution of '/sbin/iptables -D PREROUTING -d 192.168.1.1/32 -p tcp -m multiport --dports 80 -m comment --comment 090 preroute 192.168.1.1:80 -j REDIRECT --to-ports 80' returned 1: iptables: Bad rule (does a matching rule exist in that chain?).

When I have this:

firewall { '998 log all':
   proto   => 'all',
   jump => LOG,
   log_level => 'debug',
   before  => undef,
}

It fails on run:

err: /Firewall[998 Log all]/ensure: change from present to absent failed: Execution of '/sbin/iptables -t filter -D INPUT -m comment --comment 998 Log all -j LOG --log-prefix default drop' returned 1: iptables: Bad rule (does a matching rule exist in that chain?).

But the rule is inserted into /etc/sysconfig/iptables (there the comment and log_prefix is enclosed in ") - and if I alter the above iptables command, so that I enclose the comment and log_prefix - it works.

This is on RHEL 6.4

I have rules named things like '000 Allow everything from localhost' and '999 deny everything else'. According to the documentation, they should be run in string order, but they appear to be running randomly.

Am I missing anything?

Run 1:

info: Applying configuration version '1310608761'
notice: /Firewall[001 allow ssh]/ensure: created
notice: /Firewall[002 allow snmp]/ensure: created
notice: /Firewall[101 allow puppet internally]/ensure: created
notice: /Firewall[000 allow localhost]/ensure: created
notice: /Firewall[100 allow puppet internally]/ensure: created
notice: /Firewall[998 allow everything from office]/ensure: created
notice: /Firewall[999 deny all other requests]/ensure: created
notice: Finished catalog run in 1.33 seconds

Run 2:

info: Applying configuration version '1310608813'
notice: /Firewall[999 deny all other requests]/ensure: created
[timeout]

Submit some initial IPFW work - supporting at least filtering on source, dest, sport, dport and protocol.

Currently we don't get adequate purging for example. And users don't really want to have to switch providers. Better that we treat the two rulesets as one thing in Puppet.

Hi
When running module for the first time on a system with already-defined rules, it fails:

err: Could not prefetch firewall provider 'iptables': private method gsub' called for nil:NilClass info: Applying configuration version '1311006570' err: //iptables/Firewall[998 OUTPUT drop invalid]: Failed to retrieve current state of resource: private methodgsub' called for nil:NilClass
err: //iptables/Firewall[999 OUTPUT drop invalid]: Failed to retrieve current state of resource: private method `gsub' called for nil:NilClass

But iptables -L still shows the old defined rules (the ones of system-config-securitylevel-tui), of course, new rules are not appended either...

Regards
Pablo

Use case, when the below has been applied, and state is removed, its not removed from the rule, and type/provider doesn't detect any changes.

firewall{'0010 allow ssh':
ensure=>present,
action=>accept,
proto=>tcp,
dport=>22,
state=>['NEW'],
}

As of Linux Kernel 3.7, the "state" module is an obsolete version of "conntrack".

Firewall rules specifying state are re-added everytime Puppet is run (because they're converted to conntrack in /etc/sysconfig/iptables and no longer match the original firewall rule). This problem was discovered on Fedora 18.

There are (at least) two possible solutions for this issue.

1. Add ctstate, which will specify state requirements using conntrack syntax.
2. Modify state to specify state requirements using conntrack syntax rather than state syntax.

My preferences is solution 2, because then all state requirements are specified using the same syntax for all rules.

I will be working on a patch for this issue and would appreciate feedback regarding which solution is preferred by the project maintainers.

This is actually just this bug - http://projects.reductivelabs.com/issues/18104 I can't seem to see it here anywhere. I am having the same problem.

We had a firewall rule defining a "destination", after some time we want to change the destination from the already set ip-range to everything (0.0.0.0/0). We did this by removing the destination entry.

This change didn't cause the firewall rules to be updated, as it now doesn't check the destination anymore.

If we have the following

class rcac_firewall::post_accept_all {

firewall { '975 log test':
    state      => 'NEW',
    log_level  => 'debug',
    log_prefix => 'iptables A: ',
    jump       => 'LOG'
}

...
}

On the first puppet run the rule is inserted ok... however, on the second
run we get some errors like this:

info: Applying configuration version '1365457738'
err: /Firewall[975 log test]/log_level: change from iptables A: to 7 failed: The iptables provider can not handle attribute log_level at /etc/puppet/modules/rcac_firewall/manifests/post_accept_all.pp:8
err: /Firewall[975 log test]/log_prefix: change from 7 to iptables A: failed: The iptables provider can not handle attribute log_prefix at /etc/puppet/modules/rcac_firewall/manifests/post_accept_all.pp:8
notice: Finished catalog run in 18.76 seconds

If it is of interest, this is puppet version 2.7.21 running under RHEL 6.3.

It would be nice to support other firewall engines such as Windows Firewall. I have an almost working type/provider, but the terminology is quite different from iptables. Windows uses remote/local instead of source/destination, there are also some other major differences. I can generate a provider for puppetlabs-firewall, just not sure the best route.

I configured the firewall for persistence as described at http://forge.puppetlabs.com/puppetlabs/firewall:

exec { "persist-firewall":
  command => "/sbin/iptables-save >/etc/iptables.rules",
  refreshonly => true,
}
Firewall {
  notify => Exec["persist-firewall"]
}

No notification occurs and no /etc/iptables.rules is created when purging is setup:

resources { "firewall":
  purge => true,
}

And a rule is removed due to purge ...

I'm using Ubuntu 12.10 and the firewall module keeps throwing these:

Info: Loading facts in /var/lib/puppet/lib/facter/iptables_version.rb
dpkg-query: no packages found matching iptables-persistent
dpkg-query: no packages found matching iptables-persistent
dpkg-query: no packages found matching iptables-persistent

Note: I've installed the package as a git submodule using the master branch, not though the puppet forge.

Hi
RH-based distros use a chain created by system-config-firewall named "RH-Firewall-1-INPUT" which is the first target for INPUT and FORWARD chains.

"RH-Firewall-1-INPUT" ends 'rejecting anything not aproved previously' thus returning to INPUT or FORWARD chains.

This allows to use RH-Firewall-1-INPUT for system default firewalls, and use INPUT to put temorary changes to firewall rules.

puppetlabs-firewall 'firewall', doesn't accept RH-Firewall-1-INPUT as a valid chain ( INPUT, FORWARD, OUTPUT, PREROUTING, POSTROUTING).

Allowing the definition of custom chains could help in writing diferent rules.

Regards
Pablo

Like --source ! 1.1.1.1

Improvements on #133

The flush method, and thus the shell out in persist_iptables, is called on every modified resource. It would be more cost effective to call it once after all Firewall/Firewallchain resources have been synced.

@kbarber, any idea if this is technically possible?

None of the documentation or examples show how to "purge" with the ip6tables provider.

The puppetlabs-firewall module is unable to purge existing IPtables rules that don’t have a comment matching the regex:

newvalues(/^\d+[a-zA-Z0-9\s\-_]+$/)

This can be reproduced with a simple example:

[root@papp0 ~]# iptables -F
[root@papp0 ~]# iptables -t filter -A INPUT -j ACCEPT -p tcp --dport 80 -m comment --comment "http"
[root@papp0 ~]# puppet apply --modulepath /vagrant/puppet/modules
resources { "firewall":
    purge => true,
}
^D
err: /Stage[main]//Resources[firewall]: Failed to generate additional resources using 'generate': Parameter name failed: Invalid value "http". Valid values match /^\d+[a-zA-Z0-9\s\-_]+$/.
notice: Finished catalog run in 0.07 seconds

Although I can't replicate this in 3.1.0, Puppet 3.0.1 used to have a problem with method_missing. Has this just disappeared or is something up with that version of Puppet?

The firewall class, as it currently stands, doesn't take any parameters and ensures that the appropriate service is running and enabled for the operating system returned by factor. It would be nice for the class to take an ensure parameter that would be passed along to support stopping the iptables service. By default, the service should obviously be running.

So I wrote this:

https://rubygems.org/gems/iptables

The concept being that I wanted to externalise the concept of decoding and encoding iptables rules to another library that didn't have the same modelling constraints as Puppet imposes. I would have preferred to use something off the shelf, but nothing existed that suited my needs.

The 'iptables' gem itself is built from the ground up to reliably parse 'iptables-save' output into a complex data structure that mirrors the internal model of iptables itself. It has achieved full feature capability it would seem, as it doesn't try to do the transformation at the same time, this was much simpler.

By doing it this way, we no longer limit features by what the parser can do - as the parser does everything. Previously parser modifications were always buggy and very easy to regress on, this way the parser layer is kept isolated. As the parser doesn't have to do the transformation itself - it should be more reliable.

More or less this isolates the transformation and parsing into two separate pieces that can be maintained individually.

The ticket tracks the development of an experimental provider that utilises this new parser and architecture.

Hi
Using those rules:

  firewall { '999 OUTPUT drop invalid':
            jump => "ACCEPT",
            sport => "666",
            proto => "tcp",
            destination => "10.31.66.9/24",
            chain => 'RH-Firewall-1-INPUT',
    }
    firewall { '998 OUTPUT drop invalid':
            jump => "ACCEPT",
            sport => "667",
            proto => "tcp",
            destination => "10.31.66.9/24",
            chain => 'RH-Firewall-1-INPUT',
    }

I get the system applying once and over again the same rules:

notice: //iptables/Firewall[998 OUTPUT drop invalid]/destination: destination changed '10.31.66.0/255.255.255.0' to '10.31.66.9/24'
notice: Firewall998 OUTPUT drop invalid: Properties changed - updating rule
notice: //iptables/Firewall[999 OUTPUT drop invalid]/destination: destination changed '10.31.66.0/255.255.255.0' to '10.31.66.9/24'
notice: Firewall999 OUTPUT drop invalid: Properties changed - updating rule
notice: Finished catalog run in 53.68 seconds

¿Shouldn't this just apply once?

Thanks
Pablo

Currently, the firewall module doesn’t work on Archlinux because Arch has (ip|ip6|eb)tables in /usr/sbin instead of /sbin. See also #94.

After discussion with Jonathan it was proposed we create a generic non-iptables property for basic filtering actions (well only filtering for now).

So the proposal is to create a new property action which accepts: accept, deny or reject.

firewall { "000 accept icmp":
  action => "accept",
  proto => "icmp",
}

Now ... we believe that 'jump' for iptables is still important but provider specific. So this will become a feature only available to iptables. So a new feature 'iptables' should probably be created to handle this.

The behaviour when these items are mixed should be thus:

• If action is provided and jump is not - action is used
• If action is provied and jump is provided - jump overrides action. However we throw an error when the jump is: ACCEPT, DENY, REJECT ... this way we ensure there is only 1 way to set these states.

Action should also default to 'accept' to save typing - most people would expect if they define a rule it means acceptance by default. Also the ratio of accept rules to deny rules are higher.

Sample code to obtain catalogue info from another resource:

def delete
  catalog = self.resource.catalog
  chain_resource = catalog.resource("Firewallchain[mychain]")
  chain_properties = chain_resource.properties
  chain_properties.each do |p|
    notice("  #{p.name} #{p.value}")
  end

  ... and the rest ...
end