Ask Your Question
0

Firewall Management - getting locked out of EC2 instances

asked 2014-04-29 16:14:28 -0600

Merch gravatar image

updated 2014-05-06 11:16:19 -0600

When I purge iptables on the first Puppet run I'm getting locked out of EC2 instances. If I set purge to false for the first Puppet run then change it to true for subsequent runs I don't have a problem.

I'm running puppet 3.4.3

This is my firewall module:

init.pp

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

Firewall {
  before  => Class['mush_firewall::post'],
  require => Class['mush_firewall::pre'],
}

class { ['mush_firewall::pre', 'mush_firewall::post']: }

class { 'firewall': }

}

post.pp:

class mush_firewall::post {
  firewall { '999 drop all':
    proto   => 'all',
    action  => 'drop',
    before  => undef,
  }
}

pre.pp

class mush_firewall::pre {
  Firewall {
    require => undef,
  }

  # Default firewall rules
  firewall { "001 accept all icmp requests":
    proto => 'icmp',
    action  => 'accept',
  }
  ->
  firewall { '002 INPUT allow loopback':
    proto => 'all',
    iniface => 'lo',
    chain   => 'INPUT',
    action    => 'accept',
  }
  ->
  firewall { '000 INPUT allow related and established':
    proto => 'all',
    state => ['RELATED', 'ESTABLISHED'],
    action  => 'accept',
  }
  ->
  firewall { '100 allow ssh':
    proto => 'tcp',
    state => ['NEW', 'ESTABLISHED'],
    dport => 22,
    action  => 'accept',
  }
}
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
3

answered 2014-05-16 17:37:00 -0600

reidmv gravatar image

In the code posted above, there are no relationships defined between the mush_firewall, mush_firewall::pre, and mush_firewall::post classes. Due to PUP-1963, I don't know whether or not setting metaparameters like "require" or "before" on the resources { "firewall": } stanza would be effective.

What I've seen success with in the past, and an approach which seems much more flexible than relying on global resource defaults, is using run stages to ensure that the first thing Puppet does is establish the permissive rules, and the very last thing it does is establish any default deny type rules. The purge will be left in the middle. Here's how it works:

Create your firewall class as follows.

init.pp:

class mush_firewall {
  include stdlib::stages

  class { 'firewall':            stage => 'setup'  }
  class { 'mush_firewall::pre':  stage => 'setup'  }
  class { 'mush_firewall::post': stage => 'deploy' }

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

Your pre.pp and post.pp classes can remain the same. Using this model it's not necessary to modify site.pp either - wherever you want the firewall rules enforced, just include mush_firewall and that's it.

The working idea is taken from an example module published here.

edit flag offensive delete link more

Comments

Thanks Reid this is extremely helpful.

Merch gravatar imageMerch ( 2014-05-19 21:59:29 -0600 )edit
0

answered 2014-04-30 03:09:36 -0600

doc75 gravatar image
edit flag offensive delete link more

Comments

Thank you Doc75. Should there also be a snippet in post.pp to revert temporary policies? exec { 'override default policy firewall to drop': command => 'iptables -t filter -P INPUT DROP; iptables -t filter -P FORWARD DROP; iptables -t filter -P OUTPUT DROP', path => '/sbin', }

Dan M gravatar imageDan M ( 2014-04-30 17:01:49 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2014-04-29 16:14:28 -0600

Seen: 999 times

Last updated: May 16 '14