comparison modules/firewall/README.markdown @ 39:d6f2a0ee45c0 puppet-3.6

Add "Firewall" module
author IBBoard <dev@ibboard.co.uk>
date Sat, 14 Mar 2015 20:58:03 +0000
parents
children d9352a684e62
comparison
equal deleted inserted replaced
38:a1960fb961c5 39:d6f2a0ee45c0
1 #firewall
2
3 [![Build Status](https://travis-ci.org/puppetlabs/puppetlabs-firewall.png?branch=master)](https://travis-ci.org/puppetlabs/puppetlabs-firewall)
4
5 ####Table of Contents
6
7 1. [Overview - What is the firewall module?](#overview)
8 2. [Module Description - What does the module do?](#module-description)
9 3. [Setup - The basics of getting started with firewall](#setup)
10 * [What firewall Affects](#what-firewall-affects)
11 * [Setup Requirements](#setup-requirements)
12 * [Beginning with firewall](#beginning-with-firewall)
13 * [Upgrading](#upgrading)
14 4. [Usage - Configuration and customization options](#usage)
15 * [Default rules - Setting up general configurations for all firewalls](#default-rules)
16 * [Application-Specific Rules - Options for configuring and managing firewalls across applications](#application-specific-rules)
17 * [Additional Uses for the Firewall Module](#other-rules)
18 5. [Reference - An under-the-hood peek at what the module is doing](#reference)
19 6. [Limitations - OS compatibility, etc.](#limitations)
20 7. [Development - Guide for contributing to the module](#development)
21 * [Tests - Testing your configuration](#tests)
22
23 ##Overview
24
25 The firewall module lets you manage firewall rules with Puppet.
26
27 ##Module Description
28
29 PuppetLabs' firewall module introduces the `firewall` resource, which is used to manage and configure firewall rules from within the Puppet DSL. This module offers support for iptables and ip6tables. The module also introduces the `firewallchain` resource, which allows you to manage chains or firewall lists and ebtables for bridging support. At the moment, only iptables and ip6tables chains are supported.
30
31 The firewall module acts on your running firewall, making immediate changes as the catalog executes. Defining default pre and post rules allows you to provide global defaults for your hosts before and after any custom rules. Defining `pre` and `post` rules is also necessary to help you avoid locking yourself out of your own boxes when Puppet runs.
32
33 ##Setup
34
35 ###What firewall Affects
36
37 * Every node running a firewall
38 * Firewall settings in your system
39 * Connection settings for managed nodes
40 * Unmanaged resources (get purged)
41
42
43 ###Setup Requirements
44
45 Firewall uses Ruby-based providers, so you must enable [pluginsync](http://docs.puppetlabs.com/guides/plugins_in_modules.html#enabling-pluginsync).
46
47 ###Beginning with firewall
48
49 In the following two sections, you create new classes and then create firewall rules related to those classes. These steps are optional but provide a framework for firewall rules, which is helpful if you’re just starting to create them.
50
51 If you already have rules in place, then you don’t need to do these two sections. However, be aware of the ordering of your firewall rules. The module will dynamically apply rules in the order they appear in the catalog, meaning a deny rule could be applied before the allow rules. This might mean the module hasn’t established some of the important connections, such as the connection to the Puppet master.
52
53 The following steps are designed to ensure that you keep your SSH and other connections, primarily your connection to your Puppet master. If you create the `pre` and `post` classes described in the first section, then you also need to create the rules described in the second section.
54
55 ####Create the `my_fw::pre` and `my_fw::post` Classes
56
57 This approach employs a whitelist setup, so you can define what rules you want and everything else is ignored rather than removed.
58
59 The code in this section does the following:
60
61 * The 'require' parameter in `firewall {}` ensures `my_fw::pre` is run before any other rules.
62 * In the `my_fw::post` class declaration, the 'before' parameter ensures `my_fw::post` is run after any other rules.
63
64 Therefore, the run order is:
65
66 * The rules in `my_fw::pre`
67 * Your rules (defined in code)
68 * The rules in `my_fw::post`
69
70 The rules in the `pre` and `post` classes are fairly general. These two classes ensure that you retain connectivity and that you drop unmatched packets appropriately. The rules you define in your manifests are likely specific to the applications you run.
71
72 1.) Add the `pre` class to my_fw/manifests/pre.pp. Your pre.pp file should contain any default rules to be applied first. The rules in this class should be added in the order you want them to run.2.
73 ~~~puppet
74 class my_fw::pre {
75 Firewall {
76 require => undef,
77 }
78
79 # Default firewall rules
80 firewall { '000 accept all icmp':
81 proto => 'icmp',
82 action => 'accept',
83 }->
84 firewall { '001 accept all to lo interface':
85 proto => 'all',
86 iniface => 'lo',
87 action => 'accept',
88 }->
89 firewall { "002 reject local traffic not on loopback interface":
90 iniface => '! lo',
91 proto => 'all',
92 destination => '127.0.0.1/8',
93 action => 'reject',
94 }->
95 firewall { '003 accept related established rules':
96 proto => 'all',
97 state => ['RELATED', 'ESTABLISHED'],
98 action => 'accept',
99 }
100 }
101 ~~~
102
103 The rules in `pre` should allow basic networking (such as ICMP and TCP) and ensure that existing connections are not closed.
104
105 2.) Add the `post` class to my_fw/manifests/post.pp and include any default rules to be applied last.
106
107 ~~~puppet
108 class my_fw::post {
109 firewall { '999 drop all':
110 proto => 'all',
111 action => 'drop',
112 before => undef,
113 }
114 }
115 ~~~
116
117 Alternatively, the [firewallchain](#type-firewallchain) type can be used to set the default policy:
118
119 ~~~puppet
120 firewallchain { 'INPUT:filter:IPv4':
121 ensure => present,
122 policy => drop,
123 before => undef,
124 }
125 ~~~
126
127 ####Create Firewall Rules
128
129 The rules you create here are helpful if you don’t have any existing rules; they help you order your firewall configurations so you don’t lock yourself out of your box.
130
131 Rules are persisted automatically between reboots, although there are known issues with ip6tables on older Debian/Ubuntu distributions. There are also known issues with ebtables.
132
133 1.) In site.pp or another top-scope file, add the following code to set up a metatype to purge unmanaged firewall resources. This will clear any existing rules and make sure that only rules defined in Puppet exist on the machine.
134
135 **Note** - This only purges IPv4 rules.
136
137 ~~~puppet
138 resources { 'firewall':
139 purge => true
140 }
141 ~~~
142
143 To purge unmanaged firewall chains, also add:
144
145 ~~~puppet
146 resources { 'firewallchain':
147 purge => true
148 }
149 ~~~
150
151 **Note** - If there are unmanaged rules in unmanaged chains, it will take two Puppet runs before the firewall chain is purged. This is different than the `purge` parameter available in `firewallchain`.
152
153 2.) Use the following code to set up the default parameters for all of the firewall rules you will establish later. These defaults will ensure that the `pre` and `post` classes are run in the correct order to avoid locking you out of your box during the first Puppet run.
154
155 ~~~puppet
156 Firewall {
157 before => Class['my_fw::post'],
158 require => Class['my_fw::pre'],
159 }
160 ~~~
161
162 3.) Then, declare the `my_fw::pre` and `my_fw::post` classes to satisfy dependencies. You can declare these classes using an External Node Classifier or the following code:
163
164 ~~~puppet
165 class { ['my_fw::pre', 'my_fw::post']: }
166 ~~~
167
168 4.) Include the `firewall` class to ensure the correct packages are installed.
169
170 ~~~puppet
171 class { 'firewall': }
172 ~~~
173
174 ###Upgrading
175
176 Use these steps if you already have a version of the firewall module installed.
177
178 ####From version 0.2.0 and more recent
179
180 Upgrade the module with the puppet module tool as normal:
181
182 puppet module upgrade puppetlabs/firewall
183
184 ##Usage
185
186 There are two kinds of firewall rules you can use with firewall: default rules and application-specific rules. Default rules apply to general firewall settings, whereas application-specific rules manage firewall settings for a specific application, node, etc.
187
188 All rules employ a numbering system in the resource's title that is used for ordering. When titling your rules, make sure you prefix the rule with a number, for example, '000 accept all icmp requests'. _000_ runs first, _999_ runs last.
189
190 ###Default Rules
191
192 You can place default rules in either `my_fw::pre` or `my_fw::post`, depending on when you would like them to run. Rules placed in the `pre` class will run first, and rules in the `post` class, last.
193
194 In iptables, the title of the rule is stored using the comment feature of the underlying firewall subsystem. Values must match '/^\d+[[:alpha:][:digit:][:punct:][:space:]]+$/'.
195
196 ####Examples of Default Rules
197
198 Basic accept ICMP request example:
199
200 ~~~puppet
201 firewall { "000 accept all icmp requests":
202 proto => "icmp",
203 action => "accept",
204 }
205 ~~~
206
207 Drop all:
208
209 ~~~puppet
210 firewall { "999 drop all other requests":
211 action => "drop",
212 }
213 ~~~
214
215 #### Example of an IPv6 rule
216
217 IPv6 rules can be specified using the _ip6tables_ provider:
218
219 ~~~puppet
220 firewall { "006 Allow inbound SSH (v6)":
221 port => 22,
222 proto => tcp,
223 action => accept,
224 provider => 'ip6tables',
225 }
226 ~~~
227
228 ###Application-Specific Rules
229
230 Puppet doesn't care where you define rules, and this means that you can place
231 your firewall resources as close to the applications and services that you
232 manage as you wish. If you use the [roles and profiles
233 pattern](https://puppetlabs.com/learn/roles-profiles-introduction) then it
234 makes sense to create your firewall rules in the profiles, so they
235 remain close to the services managed by the profile.
236
237 This is an example of firewall rules in a profile:
238
239 ~~~puppet
240 class profile::apache {
241 include apache
242 apache::vhost { 'mysite': ensure => present }
243
244 firewall { '100 allow http and https access':
245 port => [80, 443],
246 proto => tcp,
247 action => accept,
248 }
249 }
250 ~~~
251
252 ###Rule inversion
253 Firewall rules may be inverted by prefixing the value of a parameter by "! ". If the value is an array, then every item in the array must be prefixed as iptables does not understand inverting a single value.
254
255 Parameters that understand inversion are: connmark, ctstate, destination, dport, dst\_range, dst\_type, iniface, outiface, port, proto, source, sport, src\_range, src\_type, and state.
256
257 Examples:
258
259 ~~~puppet
260 firewall { '001 disallow esp protocol':
261 action => 'accept',
262 proto => '! esp',
263 }
264 firewall { '002 drop NEW external website packets with FIN/RST/ACK set and SYN unset':
265 chain => 'INPUT',
266 state => 'NEW',
267 action => 'drop',
268 proto => 'tcp',
269 sport => ['! http', '! 443'],
270 source => '! 10.0.0.0/8',
271 tcp_flags => '! FIN,SYN,RST,ACK SYN',
272 }
273 ~~~
274
275 ###Additional Uses for the Firewall Module
276
277 You can apply firewall rules to specific nodes. Usually, you will want to put the firewall rule in another class and apply that class to a node. Apply a rule to a node as follows:
278
279 ~~~puppet
280 node 'some.node.com' {
281 firewall { '111 open port 111':
282 dport => 111
283 }
284 }
285 ~~~
286
287 You can also do more complex things with the `firewall` resource. This example sets up static NAT for the source network 10.1.2.0/24:
288
289 ~~~puppet
290 firewall { '100 snat for network foo2':
291 chain => 'POSTROUTING',
292 jump => 'MASQUERADE',
293 proto => 'all',
294 outiface => "eth0",
295 source => '10.1.2.0/24',
296 table => 'nat',
297 }
298 ~~~
299
300
301 You can also change the TCP MSS value for VPN client traffic:
302
303 ~~~puppet
304 firewall { '110 TCPMSS for VPN clients':
305 chain => 'FORWARD',
306 table => 'mangle',
307 source => '10.0.2.0/24',
308 proto => tcp,
309 tcp_flags => 'SYN,RST SYN',
310 mss => '1361:1541',
311 set_mss => '1360',
312 jump => 'TCPMSS',
313 }
314 ~~~
315
316 The following will mirror all traffic sent to the server to a secondary host on the LAN with the TEE target:
317
318 ~~~puppet
319 firewall { '503 Mirror traffic to IDS':
320 proto => all,
321 jump => 'TEE',
322 gateway => '10.0.0.2',
323 chain => 'PREROUTING',
324 table => 'mangle',
325 }
326 ~~~
327
328 The following example creates a new chain and forwards any port 5000 access to it.
329 ~~~puppet
330 firewall { '100 forward to MY_CHAIN':
331 chain => 'INPUT',
332 jump => 'MY_CHAIN',
333 }
334 # The namevar here is in the format chain_name:table:protocol
335 firewallchain { 'MY_CHAIN:filter:IPv4':
336 ensure => present,
337 }
338 firewall { '100 my rule':
339 chain => 'MY_CHAIN',
340 action => 'accept',
341 proto => 'tcp',
342 dport => 5000,
343 }
344 ~~~
345
346 ###Additional Information
347
348 Access the inline documentation:
349
350 puppet describe firewall
351
352 Or
353
354 puppet doc -r type
355 (and search for firewall)
356
357 ##Reference
358
359 Classes:
360
361 * [firewall](#class-firewall)
362
363 Types:
364
365 * [firewall](#type-firewall)
366 * [firewallchain](#type-firewallchain)
367
368 Facts:
369
370 * [ip6tables_version](#fact-ip6tablesversion)
371 * [iptables_version](#fact-iptablesversion)
372 * [iptables_persistent_version](#fact-iptablespersistentversion)
373
374 ###Class: firewall
375
376 Performs the basic setup tasks required for using the firewall resources.
377
378 At the moment this takes care of:
379
380 * iptables-persistent package installation
381
382 Include the `firewall` class for nodes that need to use the resources in this module:
383
384 class { 'firewall': }
385
386 ####ensure
387
388 Parameter that controls the state of the iptables service on your system, allowing you to disable iptables if you want.
389
390 `ensure` can either be 'running' or 'stopped'. Default to 'running'.
391
392 ####package
393
394 Specify the platform-specific package(s) to install. Defaults defined in `firewall::params`.
395
396 ####service
397
398 Specify the platform-specific service(s) to start or stop. Defaults defined in `firewall::params`.
399
400 ###Type: firewall
401
402 This type enables you to manage firewall rules within Puppet.
403
404 ####Providers
405 **Note:** Not all features are available with all providers.
406
407 * `ip6tables`: Ip6tables type provider
408 * Required binaries: `ip6tables-save`, `ip6tables`.
409 * Supported features: `address_type`, `connection_limiting`, `dnat`, `hop_limiting`, `icmp_match`, `interface_match`, `iprange`, `ipsec_dir`, `ipsec_policy`, `ipset`, `iptables`, `isfirstfrag`, `ishasmorefrags`, `islastfrag`, `log_level`, `log_prefix`, `mark`, `mask`, `mss`, `owner`, `pkttype`, `rate_limiting`, `recent_limiting`, `reject_type`, `snat`, `socket`, `state_match`, `tcp_flags`.
410
411 * `iptables`: Iptables type provider
412 * Required binaries: `iptables-save`, `iptables`.
413 * Default for `kernel` == `linux`.
414 * Supported features: `address_type`, `connection_limiting`, `dnat`, `icmp_match`, `interface_match`, `iprange`, `ipsec_dir`, `ipsec_policy`, `ipset`, `iptables`, `isfragment`, `log_level`, `log_prefix`, `mark`, `mask`, `mss`, `netmap`, `owner`, `pkttype`, `rate_limiting`, `recent_limiting`, `reject_type`, `snat`, `socket`, `state_match`, `tcp_flags`.
415
416 **Autorequires:**
417
418 If Puppet is managing the iptables or ip6tables chains specified in the `chain` or `jump` parameters, the firewall resource will autorequire those firewallchain resources.
419
420 If Puppet is managing the iptables or iptables-persistent packages, and the provider is iptables or ip6tables, the firewall resource will autorequire those packages to ensure that any required binaries are installed.
421
422 #### Features
423
424 * `address_type`: The ability to match on source or destination address type.
425
426 * `connection_limiting`: Connection limiting features.
427
428 * `dnat`: Destination NATing.
429
430 * `hop_limiting`: Hop limiting features.
431
432 * `icmp_match`: The ability to match ICMP types.
433
434 * `interface_match`: Interface matching.
435
436 * `iprange`: The ability to match on source or destination IP range.
437
438 * `ipsec_dir`: The ability to match IPsec policy direction.
439
440 * `ipsec_policy`: The ability to match IPsec policy.
441
442 * `iptables`: The provider provides iptables features.
443
444 * `isfirstfrag`: The ability to match the first fragment of a fragmented ipv6 packet.
445
446 * `isfragment`: The ability to match fragments.
447
448 * `ishasmorefrags`: The ability to match a non-last fragment of a fragmented ipv6 packet.
449
450 * `islastfrag`: The ability to match the last fragment of an ipv6 packet.
451
452 * `log_level`: The ability to control the log level.
453
454 * `log_prefix`: The ability to add prefixes to log messages.
455
456 * `mark`: The ability to match or set the netfilter mark value associated with the packet.
457
458 * `mask`: The ability to match recent rules based on the ipv4 mask.
459
460 * `owner`: The ability to match owners.
461
462 * `pkttype`: The ability to match a packet type.
463
464 * `rate_limiting`: Rate limiting features.
465
466 * `recent_limiting`: The netfilter recent module.
467
468 * `reject_type`: The ability to control reject messages.
469
470 * `set_mss`: Set the TCP MSS of a packet.
471
472 * `snat`: Source NATing.
473
474 * `socket`: The ability to match open sockets.
475
476 * `state_match`: The ability to match stateful firewall states.
477
478 * `tcp_flags`: The ability to match on particular TCP flag settings.
479
480 * `netmap`: The ability to map entire subnets via source or destination nat rules.
481
482 #### Parameters
483
484 * `action`: This is the action to perform on a match. Valid values for this action are:
485 * 'accept': The packet is accepted.
486 * 'reject': The packet is rejected with a suitable ICMP response.
487 * 'drop': The packet is dropped.
488
489 If you specify no value it will simply match the rule but perform no action unless you provide a provider-specific parameter (such as `jump`).
490
491 * `burst`: Rate limiting burst value (per second) before limit checks apply. Values must match '/^\d+$/'. Requires the `rate_limiting` feature.
492
493 * `chain`: Name of the chain to use. You can provide a user-based chain or use one of the following built-in chains:'INPUT','FORWARD','OUTPUT','PREROUTING', or 'POSTROUTING'. The default value is 'INPUT'. Values must match '/^[a-zA-Z0-9\-_]+$/'. Requires the `iptables` feature.
494
495 * `checksum_fill`: When using a `jump` value of 'CHECKSUM', this boolean makes sure that a checksum is calculated and filled in a packet that lacks a checksum. Valid values are 'true' or 'false'. Requires the `iptables` feature.
496
497 * `clamp_mss_to_pmtu`: Enables PMTU Clamping support when using a jump target of 'TCPMSS'. Valid values are 'true' or 'false'.
498
499 * `connlimit_above`: Connection limiting value for matched connections above n. Values must match '/^\d+$/'. Requires the `connection_limiting` feature.
500
501 * `connlimit_mask`: Connection limiting by subnet mask for matched connections. Apply a subnet mask of /0 to /32 for IPv4, and a subnet mask of /0 to /128 for IPv6. Values must match '/^\d+$/'. Requires the `connection_limiting` feature.
502
503 * `connmark`: Match the Netfilter mark value associated with the packet. Accepts values `mark/mask` or `mark`. These will be converted to hex if they are not hex already. Requires the `mark` feature.
504
505 * `ctstate`: Matches a packet based on its state in the firewall stateful inspection table, using the conntrack module. Valid values are: 'INVALID', 'ESTABLISHED', 'NEW', 'RELATED'. Requires the `state_match` feature.
506
507 * `date_start`: Start Date/Time for the rule to match, which must be in ISO 8601 "T" notation. The possible time range is '1970-01-01T00:00:00' to '2038-01-19T04:17:07'
508
509 * `date_stop`: End Date/Time for the rule to match, which must be in ISO 8601 "T" notation. The possible time range is '1970-01-01T00:00:00' to '2038-01-19T04:17:07'
510
511 * `destination`: The destination address to match. For example: `destination => '192.168.1.0/24'`. You can also negate a mask by putting ! in front. For example: `destination => '! 192.168.2.0/24'`. The destination can also be an IPv6 address if your provider supports it.
512
513 For some firewall providers you can pass a range of ports in the format: 'start number-end number'. For example, '1-1024' would cover ports 1 to 1024.
514
515 * `dport`: The destination port to match for this filter (if the protocol supports ports). Will accept a single element or an array. For some firewall providers you can pass a range of ports in the format: 'start number-end number'. For example, '1-1024' would cover ports 1 to 1024.
516
517 * `dst_range`: The destination IP range. For example: `dst_range => '192.168.1.1-192.168.1.10'`.
518
519 The destination IP range is must in 'IP1-IP2' format. Values in the range must be valid IPv4 or IPv6 addresses. Requires the `iprange` feature.
520
521 * `dst_type`: The destination address type. For example: `dst_type => 'LOCAL'`.
522
523 Valid values are:
524
525 * 'UNSPEC': an unspecified address
526 * 'UNICAST': a unicast address
527 * 'LOCAL': a local address
528 * 'BROADCAST': a broadcast address
529 * 'ANYCAST': an anycast packet
530 * 'MULTICAST': a multicast address
531 * 'BLACKHOLE': a blackhole address
532 * 'UNREACHABLE': an unreachable address
533 * 'PROHIBIT': a prohibited address
534 * 'THROW': an unroutable address
535 * 'XRESOLVE: an unresolvable address
536
537 Requires the `address_type` feature.
538
539 * `ensure`: Ensures that the resource is present. Valid values are 'present', 'absent'. The default is 'present'.
540
541 * `gateway`: Used with TEE target to mirror traffic of a machine to a secondary host on the LAN.
542
543 * `gid`: GID or Group owner matching rule. Accepts a string argument only, as iptables does not accept multiple gid in a single statement. Requires the `owner` feature.
544
545 * `hop_limit`: Hop limiting value for matched packets. Values must match '/^\d+$/'. Requires the `hop_limiting` feature.
546
547 * `icmp`: When matching ICMP packets, this indicates the type of ICMP packet to match. A value of 'any' is not supported. To match any type of ICMP packet, the parameter should be omitted or undefined. Requires the `icmp_match` feature.
548
549 * `iniface`: Input interface to filter on. Values must match '/^!?\s?[a-zA-Z0-9\-\._\+\:]+$/'. Requires the `interface_match` feature. Supports interface alias (eth0:0) and negation.
550
551 * `ipsec_dir`: Sets the ipsec policy direction. Valid values are 'in', 'out'. Requires the `ipsec_dir` feature.
552
553 * `ipsec_policy`: Sets the ipsec policy type. Valid values are 'none', 'ipsec'. Requires the `ipsec_policy` feature.
554
555 * `ipset`: Matches IP sets. Value must be 'ipset_name (src|dst|src,dst)' and can be negated by putting ! in front. Requires ipset kernel module.
556
557 * `isfirstfrag`: If true, matches when the packet is the first fragment of a fragmented ipv6 packet. Cannot be negated. Supported by ipv6 only. Valid values are 'true', 'false'. Requires the `isfirstfrag` feature.
558
559 * `isfragment`: If 'true', matches when the packet is a tcp fragment of a fragmented packet. Supported by iptables only. Valid values are 'true', 'false'. Requires features `isfragment`.
560
561 * `ishasmorefrags`: If 'true', matches when the packet has the 'more fragments' bit set. Supported by ipv6 only. Valid values are 'true', 'false'. Requires the `ishasmorefrags` feature.
562
563 * `islastfrag`: If true, matches when the packet is the last fragment of a fragmented ipv6 packet. Supported by ipv6 only. Valid values are 'true', 'false'. Requires the `islastfrag`.
564
565 * `jump`: The value for the iptables `--jump` parameter. Any valid chain name is allowed, but normal values are: 'QUEUE', 'RETURN', 'DNAT', 'SNAT', 'LOG', 'MASQUERADE', 'REDIRECT', 'MARK', 'TCPMSS'.
566
567 For the values 'ACCEPT', 'DROP', and 'REJECT', you must use the generic `action` parameter. This is to enforce the use of generic parameters where possible for maximum cross-platform modeling.
568
569 If you set both `accept` and `jump` parameters, you will get an error, because only one of the options should be set. Requires the `iptables` feature.
570
571 * `kernel_timezone`: Use the kernel timezone instead of UTC to determine whether a packet meets the time regulations.
572
573 * `limit`: Rate limiting value for matched packets. The format is: 'rate/[/second/|/minute|/hour|/day]'. Example values are: '50/sec', '40/min', '30/hour', '10/day'. Requires the `rate_limiting` feature.
574
575 * `line`: Read-only property for caching the rule line.
576
577 * `log_level`: When combined with `jump => 'LOG'` specifies the system log level to log to. Requires the `log_level` feature.
578
579 * `log_prefix`: When combined with `jump => 'LOG'` specifies the log prefix to use when logging. Requires the `log_prefix` feature.
580
581 * `mask`: Sets the mask to use when `recent` is enabled. Requires the `mask` feature.
582
583 * `month_days`: Only match on the given days of the month. Possible values are '1' to '31'. Note that specifying '31' will not match on months that do not have a 31st day; the same goes for 28- or 29-day February.
584
585 * `match_mark`: Match the Netfilter mark value associated with the packet. Accepts either of mark/mask or mark. These will be converted to hex if they are not already. Requires the `mark` feature.
586
587 * `mss`: Sets a given TCP MSS value or range to match.
588
589 * `name`: The canonical name of the rule. This name is also used for ordering, so make sure you prefix the rule with a number. For example:
590
591 ~~~puppet
592 firewall { '000 this runs first':
593 # this rule will run first
594 }
595 firewall { '999 this runs last':
596 # this rule will run last
597 }
598 ~~~
599
600 Depending on the provider, the name of the rule can be stored using the comment feature of the underlying firewall subsystem. Values must match '/^\d+[[:alpha:][:digit:][:punct:][:space:]]+$/'.
601
602 * `outiface`: Output interface to filter on. Values must match '/^!?\s?[a-zA-Z0-9\-\._\+\:]+$/'. Requires the `interface_match` feature. Supports interface alias (eth0:0) and negation.
603
604 * `physdev_in`: Match if the packet is entering a bridge from the given interface. Values must match '/^[a-zA-Z0-9\-\._\+]+$/'.
605
606 * `physdev_out`: Match if the packet is leaving a bridge via the given interface. Values must match '/^[a-zA-Z0-9\-\._\+]+$/'.
607
608 * `physdev_is_bridged`: Match if the packet is transversing a bridge. Valid values are true or false.
609
610 * `pkttype`: Sets the packet type to match. Valid values are: 'unicast', 'broadcast', and'multicast'. Requires the `pkttype` feature.
611
612 * `port`: The destination or source port to match for this filter (if the protocol supports ports). Will accept a single element or an array. For some firewall providers you can pass a range of ports in the format: 'start number-end number'. For example, '1-1024' would cover ports 1 to 1024.
613
614 * `proto`: The specific protocol to match for this rule. This is 'tcp' by default. Valid values are:
615 * 'tcp'
616 * 'udp'
617 * 'icmp'
618 * 'ipv4'
619 * 'ipv6'
620 * 'ipv6-icmp'
621 * 'esp'
622 * 'ah'
623 * 'vrrp'
624 * 'igmp'
625 * 'ipencap'
626 * 'ospf'
627 * 'gre'
628 * 'all'
629
630 * `provider`: The specific backend to use for this firewall resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform. Available providers are ip6tables and iptables. See the [Providers](#providers) section above for details about these providers.
631
632 * `random`: When using a `jump` value of 'MASQUERADE', 'DNAT', 'REDIRECT', or 'SNAT', this boolean will enable randomized port mapping. Valid values are true or false. Requires the `dnat` feature.
633
634 * `rdest`: If boolean 'true', adds the destination IP address to the list. Valid values are true or false. Requires the `recent_limiting` feature and the `recent` parameter.
635
636 * `reap`: Can only be used in conjunction with the `rseconds` parameter. If boolean 'true', this will purge entries older than 'seconds' as specified in `rseconds`. Valid values are true or false. Requires the `recent_limiting` feature and the `recent` parameter.
637
638 * `recent`: Enable the recent module. Valid values are: 'set', 'update', 'rcheck', or 'remove'. For example:
639
640 ~~~puppet
641 # If anyone's appeared on the 'badguy' blacklist within
642 # the last 60 seconds, drop their traffic, and update the timestamp.
643 firewall { '100 Drop badguy traffic':
644 recent => 'update',
645 rseconds => 60,
646 rsource => true,
647 rname => 'badguy',
648 action => 'DROP',
649 chain => 'FORWARD',
650 }
651 # No-one should be sending us traffic on eth0 from localhost
652 # Blacklist them
653 firewall { '101 blacklist strange traffic':
654 recent => 'set',
655 rsource => true,
656 rname => 'badguy',
657 destination => '127.0.0.0/8',
658 iniface => 'eth0',
659 action => 'DROP',
660 chain => 'FORWARD',
661 }
662 ~~~
663
664 Requires the `recent_limiting` feature.
665
666 * `reject`: When combined with `jump => 'REJECT'`, you can specify a different ICMP response to be sent back to the packet sender. Requires the `reject_type` feature.
667
668 * `rhitcount`: Used in conjunction with `recent => 'update'` or `recent => 'rcheck'`. When used, this will narrow the match to happen only when the address is in the list and packets greater than or equal to the given value have been received. Requires the `recent_limiting` feature and the `recent` parameter.
669
670 * `rname`: Specify the name of the list. Takes a string argument. Requires the `recent_limiting` feature and the `recent` parameter.
671
672 * `rseconds`: Used in conjunction with `recent => 'rcheck'` or `recent => 'update'`. When used, this will narrow the match to only happen when the address is in the list and was seen within the last given number of seconds. Requires the `recent_limiting` feature and the `recent` parameter.
673
674 * `rsource`: If boolean 'true', adds the source IP address to the list. Valid values are 'true', 'false'. Requires the `recent_limiting` feature and the `recent` parameter.
675
676 * `rttl`: May only be used in conjunction with `recent => 'rcheck'` or `recent => 'update'`. If boolean 'true', this will narrow the match to happen only when the address is in the list and the TTL of the current packet matches that of the packet that hit the `recent => 'set'` rule. If you have problems with DoS attacks via bogus packets from fake source addresses, this parameter may help. Valid values are 'true', 'false'. Requires the `recent_limiting` feature and the `recent` parameter.
677
678 * `set_mark`: Set the Netfilter mark value associated with the packet. Accepts either 'mark/mask' or 'mark'. These will be converted to hex if they are not already. Requires the `mark` feature.
679
680 * `set_mss`: When combined with `jump => 'TCPMSS'` specifies the value of the MSS field.
681
682 * `socket`: If 'true', matches if an open socket can be found by doing a socket lookup on the packet. Valid values are 'true', 'false'. Requires the `socket` feature.
683
684 * `source`: The source address. For example: `source => '192.168.2.0/24'`. You can also negate a mask by putting ! in front. For example: `source => '! 192.168.2.0/24'`. The source can also be an IPv6 address if your provider supports it.
685
686 * `sport`: The source port to match for this filter (if the protocol supports ports). Will accept a single element or an array. For some firewall providers you can pass a range of ports in the format:'start number-end number'. For example, '1-1024' would cover ports 1 to 1024.
687
688 * `src_range`: The source IP range. For example: `src_range => '192.168.1.1-192.168.1.10'`. The source IP range must be in 'IP1-IP2' format. Values in the range must be valid IPv4 or IPv6 addresses. Requires the `iprange` feature.
689
690 * `src_type`: Specify the source address type. For example: `src_type => 'LOCAL'`.
691
692 Valid values are:
693
694 * 'UNSPEC': an unspecified address.
695 * 'UNICAST': a unicast address.
696 * 'LOCAL': a local address.
697 * 'BROADCAST': a broadcast address.
698 * 'ANYCAST': an anycast packet.
699 * 'MULTICAST': a multicast address.
700 * 'BLACKHOLE': a blackhole address.
701 * 'UNREACHABLE': an unreachable address.
702 * 'PROHIBIT': a prohibited address.
703 * 'THROW': an unroutable address.
704 * 'XRESOLVE': an unresolvable address.
705
706 Requires the `address_type` feature.
707
708 * `stat_every`: Match one packet every nth packet. Requires `stat_mode => 'nth'`
709
710 * `stat_mode`: Set the matching mode for statistic matching. Supported modes are `random` and `nth`.
711
712 * `stat_packet`: Set the initial counter value for the nth mode. Must be between 0 and the value of `stat_every`. Defaults to 0. Requires `stat_mode => 'nth'`
713
714 * `stat_probability`: Set the probability from 0 to 1 for a packet to be randomly matched. It works only with `stat_mode => 'random'`.
715
716 * `state`: Matches a packet based on its state in the firewall stateful inspection table. Valid values are: 'INVALID', 'ESTABLISHED', 'NEW', 'RELATED'. Requires the `state_match` feature.
717
718 * `table`: Table to use. Valid values are: 'nat', 'mangle', 'filter', 'raw', 'rawpost'. By default the setting is 'filter'. Requires the `iptables` feature.
719
720 * `tcp_flags`: Match when the TCP flags are as specified. Set as a string with a list of comma-separated flag names for the mask, then a space, then a comma-separated list of flags that should be set. The flags are: 'SYN', 'ACK', 'FIN', 'RST', 'URG', 'PSH', 'ALL', 'NONE'.
721
722 Note that you specify flags in the order that iptables `--list` rules would list them to avoid having Puppet think you changed the flags. For example, 'FIN,SYN,RST,ACK SYN' matches packets with the SYN bit set and the ACK, RST and FIN bits cleared. Such packets are used to request TCP connection initiation. Requires the `tcp_flags` feature.
723
724 * `time_contiguous`: When the `time_stop` value is smaller than the `time_start` value, match this as a single time period instead of distinct intervals.
725
726 * `time_start`: Start time for the rule to match. The possible time range is '00:00:00' to '23:59:59'. Leading zeroes are allowed (e.g. '06:03') and correctly interpreted as base-10.
727
728 * `time_stop`: End time for the rule to match. The possible time range is '00:00:00' to '23:59:59'. Leading zeroes are allowed (e.g. '06:03') and correctly interpreted as base-10.
729
730 * `todest`: When using `jump => 'DNAT'`, you can specify the new destination address using this parameter. Requires the `dnat` feature.
731
732 * `toports`: For DNAT this is the port that will replace the destination port. Requires the `dnat` feature.
733
734 * `tosource`: When using `jump => 'SNAT'`, you can specify the new source address using this parameter. Requires the `snat` feature.
735
736 * `to`: When using `jump => 'NETMAP'`, you can specify a source or destination subnet to nat to. Requires the `netmap` feature`.
737
738 * `uid`: UID or Username owner matching rule. Accepts a string argument only, as iptables does not accept multiple uid in a single statement. Requires the `owner` feature.
739
740 * `week_days`: Only match on the given weekdays. Possible values are 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun'.
741
742 ###Type: firewallchain
743
744 Enables you to manage rule chains for firewalls.
745
746 Currently this type supports only iptables, ip6tables, and ebtables on Linux. It also provides support for setting the default policy on chains and tables that allow it.
747
748 **Autorequires**: If Puppet is managing the iptables or iptables-persistent packages, and the provider is iptables_chain, the firewall resource will autorequire those packages to ensure that any required binaries are installed.
749
750 ####Providers
751
752 `iptables_chain` is the only provider that supports firewallchain.
753
754 ####Features
755
756 * `iptables_chain`: The provider provides iptables chain features.
757 * `policy`: Default policy (inbuilt chains only).
758
759 ####Parameters
760
761 * `ensure`: Ensures that the resource is present. Valid values are 'present', 'absent'.
762
763 * `ignore`: Regex to perform on firewall rules to exempt unmanaged rules from purging (when enabled). This is matched against the output of iptables-save. This can be a single regex or an array of them. To support flags, use the ruby inline flag mechanism: a regex such as '/foo/i' can be written as '(?i)foo' or '(?i:foo)'. Only when purge is 'true'.
764
765 Full example:
766 ~~~puppet
767 firewallchain { 'INPUT:filter:IPv4':
768 purge => true,
769 ignore => [
770 # ignore the fail2ban jump rule
771 '-j fail2ban-ssh',
772 # ignore any rules with "ignore" (case insensitive) in the comment in the rule
773 '--comment "[^"](?i:ignore)[^"]"',
774 ],
775 }
776 ~~~
777
778 * `name`: Specify the canonical name of the chain. For iptables the format must be {chain}:{table}:{protocol}.
779
780 * `policy`: Set the action the packet will perform when the end of the chain is reached. It can only be set on inbuilt chains ('INPUT', 'FORWARD', 'OUTPUT', 'PREROUTING', 'POSTROUTING'). Valid values are:
781
782 * 'accept': The packet is accepted.
783 * 'drop': The packet is dropped.
784 * 'queue': The packet is passed userspace.
785 * 'return': The packet is returned to calling (jump) queue or to the default of inbuilt chains.
786
787 * `provider`: The specific backend to use for this firewallchain resource. You will seldom need to specify this --- Puppet will usually discover the appropriate provider for your platform. The only available provider is:
788
789 `iptables_chain`: iptables chain provider
790
791 * Required binaries: `ebtables-save`, `ebtables`, `ip6tables-save`, `ip6tables`, `iptables-save`, `iptables`.
792 * Default for `kernel` == `linux`.
793 * Supported features: `iptables_chain`, `policy`.
794
795 * `purge`: Purge unmanaged firewall rules in this chain. Valid values are 'false', 'true'.
796
797 **Note** This `purge` is purging unmanaged rules in a firewall chain, not unmanaged firewall chains. To purge unmanaged firewall chains, use the following instead.
798
799 ~~~puppet
800 resources { 'firewallchain':
801 purge => true
802 }
803 ~~~
804
805 ###Fact: ip6tables_version
806
807 A Facter fact that can be used to determine what the default version of ip6tables is for your operating system/distribution.
808
809 ###Fact: iptables_version
810
811 A Facter fact that can be used to determine what the default version of iptables is for your operating system/distribution.
812
813 ###Fact: iptables_persistent_version
814
815 Retrieves the version of iptables-persistent from your OS. This is a Debian/Ubuntu specific fact.
816
817 ##Limitations
818
819 ###SLES
820
821 The `socket` parameter is not supported on SLES. In this release it will cause
822 the catalog to fail with iptables failures, rather than correctly warn you that
823 the features are unusable.
824
825 ###Oracle Enterprise Linux
826
827 The `socket` and `owner` parameters are unsupported on Oracle Enterprise Linux
828 when the "Unbreakable" kernel is used. These may function correctly when using
829 the stock RedHat kernel instead. Declaring either of these parameters on an
830 unsupported system will result in iptable rules failing to apply.
831
832 ### Debian 8 Support
833
834 As Puppet Enterprise itself does not yet support Debian 8, use of this module with Puppet Enterprise under a Debian 8
835 system should be regarded as experimental.
836
837 ###Other
838
839 Bugs can be reported in JIRA:
840
841 <http://tickets.puppetlabs.com>
842
843 ##Development
844
845 Puppet Labs modules on the Puppet Forge are open projects, and community contributions are essential for keeping them great. We can’t access the huge number of platforms and myriad of hardware, software, and deployment configurations that Puppet is intended to serve.
846
847 We want to keep it as easy as possible to contribute changes so that our modules work in your environment. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.
848
849 You can read the complete module contribution guide [on the Puppet Labs wiki.](http://projects.puppetlabs.com/projects/module-site/wiki/Module_contributing)
850
851 For this particular module, please also read CONTRIBUTING.md before contributing.
852
853 Currently we support:
854
855 * iptables
856 * ip6tables
857 * ebtables (chains only)
858
859 ###Testing
860
861 Make sure you have:
862
863 * rake
864 * bundler
865
866 Install the necessary gems:
867
868 bundle install
869
870 And run the tests from the root of the source code:
871
872 rake test
873
874 If you have a copy of Vagrant 1.1.0 you can also run the system tests:
875
876 RS_SET=ubuntu-1404-x64 rspec spec/acceptance
877 RS_SET=centos-64-x64 rspec spec/acceptance