Adoptable Cookbooks List

Supermarket Belongs to the Community

Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.

iptables-patterns Cookbook

How to use this cookbook

Allowing all traffic to ports

The frontend_permissive_ports recipe determines which ports are open and closed to external traffic on the server.
By default, it will set up a STANDARD-FIREWALL chain that allows communication from all IP addresses to ports:

22 (ssh)

80 (http)

443 (https)

The local interface, lo, will be allowed to talk to itself, so 127.0.0.1 on all ports will function.

Any other traffic will be rejected with an icmp-port-unreachable or icmp6-port-unreachable response.

You can override the opened ports by defining more ports in attributes:
node['iptables-standard']['allowed_incoming_ports'] = {
'rsync' => 'rsync',
'non-standard-software' => '12345'
}

The ports for each item in the array are internally mapped by iptables to those defined in /etc/services if not port numbers.

If you want to remap the port numbers of existing ports, you can again do so via attributes:
node['iptables-standard']['allowed_incoming_ports'] = {
'http' => '8080',
'https' => false
}
This will create a firewall with http port 8080, along with the default ssh port as inherited from the cookbook attributes, leaving the https port blocked.

Whitelisting IPs to ports

The whitelist_ip_ports recipe can write out rules for many different custom firewall chains.
This builds upon the frontend_permissive_ports recipe which determines which ports are open, to then determine
which IPs the ports are actually open to.

Any non-whitelisted traffic will be dropped.

For every firewall chain that you wish to create, add the name to this firewalls array:
node['iptables-patterns']['firewalls'] = ['readme']

This will cause the recipe to pick up on node['iptables-readme'].

For every firewall chain in the firewalls array, the following is expected:

node['iptables-readme']['name'] = 'readme' - the name of the firewall chain

node['iptables-readme']['type'] = 'whitelist_ips' - use the whitelist_ips LWRP instead of the permissive_ports LWRP.

node['iptables-readme']['firewalled_chains'] = ['INPUT', 'FORWARD'] - which standard firewall chains should be used to
hook into the new one.

node['iptables-readme']['tcp_ports'] = [80, 443, 1080]- which TCP ports should be filtered through the new firewall
chain. This should contain at least the ports that are innode['iptables-standard']['allowed_incoming_ports']` for any
traffic from the whitelisted IPs to not be rejected.

node['iptables-readme']['udp_ports'] = [] - which UDP ports should be filtered through the new firewall chain

node['iptables-readme']['whitelist_action'] = 'RETURN' - what to do when a whitelisted IP is matched. 'RETURN' is
recommended, rather than 'ACCEPT' as there may be further firewall chains that filter traffic more.

The IPv4 addresses that are allowed to communicate with the server, to the TCP and UDP ports defined earlier:
ruby
node['iptables-readme']['whitelist_ipv4_addresses'] = [
'127.0.0.1', # Allow localhost to access services
'1.2.3.4',
'5.6.7.8/32'
]

The IPv6 addresses that are allowed to communicate with the server, to the TCP and UDP ports defined earlier:
ruby
node['iptables-readme']['whitelist_ipv6_addresses'] = [
'::1' # Allow localhost to access services
]

Hooking up fail2ban and iptables-ng

If using the fail2ban cookbook, it is agnostic as to the cookbook that configures iptables.
So, use the iptables-patterns::fail2ban recipe to hook up a restart of fail2ban every time the iptables rules change
via iptables-ng.

LWRPs

iptables_patterns_permissive_ports

Use the LWRP iptables_patterns_permissive_ports to define which ports are open for the server.
This is used by the frontend_permissive_ports recipe and as it stands, you cannot use both the recipe and the LWRP
together or indeed two usages of the LWRP, due to the action of a non-whitelisted port number being to drop the traffic.

As it is used by the frontend_permissive_ports recipe, see it's description above in Allowing all traffic to ports
for what it will do!

iptables_patterns_whitelist_ips

Use the LWRP iptables_patterns_whitelist_ips to lock down the specified ports to be able to be accessed by whitelisted
IPs only.

This is used by the whitelist_ip_ports recipe and as it stands. Usages of the LWRP and recipe are allowed but you
should not use this to define more than one whitelist for the same port, as the first filter of the port would drop
the traffic for non-whitelisted IPs.

As it is used by the whitelist_ip_ports recipe, see it's description above in Whitelisting IPs to ports
for what it will do!

Testing

We use the following testing tools on this project, which can be installed by running bundle install.
These will all run when you perform bundle exec rake test, however if you wish to know how to run them individually,
they are listed below.