Iptables standards and configuration management

[Stephen John Smoogen]

One of the items that I have to deal with at UNM is a long list of
different firewalls and servers. I have Solaris(9,10), AIX(various),
MacOSX(various), and SuSE(various), RHEL(2,3,4,5), and Fedora(7,8,9)
to worry about with lots of different firewall needs for each one. As
I am trying to standardize the firewalls... I run into that same
headache everyone runs into at some point or another... How does one
organize the various different firewalls in both the VCS and the
upcoming configuration management system... while perfect is the enemy
of the good.. what is a good way of doing it as I see way to many ways
of laying it out in file structure.

firewalls/project/OS/system
project/firewall/OS/system
OS/firewall/project/system
OS/system/project/firewall

etc etc etc.  with some other // items added. Any ideas?

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Mike McGrath]

On Sat, 2 Aug 2008, Stephen John Smoogen wrote:

>  One of the items that I have to deal with at UNM is a long list of
>  different firewalls and servers. I have Solaris(9,10), AIX(various),
>  MacOSX(various), and SuSE(various), RHEL(2,3,4,5), and Fedora(7,8,9)
>  to worry about with lots of different firewall needs for each one. As
>  I am trying to standardize the firewalls... I run into that same
>  headache everyone runs into at some point or another... How does one
>  organize the various different firewalls in both the VCS and the
>  upcoming configuration management system... while perfect is the enemy
>  of the good.. what is a good way of doing it as I see way to many ways
>  of laying it out in file structure.
>
>  firewalls/project/OS/system
>  project/firewall/OS/system
>  OS/firewall/project/system
>  OS/system/project/firewall
>
>  etc etc etc.  with some other // items added. Any ideas?
>  
Hmmm, well.  My initial thought for the standard was to focus explicitly
on Red Hat family type stuff which could mean the rest of that is not
compliant.  Even in the RH family type stuff I'm not quite sure the best
way to manage firewalls.  We're doing them with puppet templates right now
but our firewall rules are fairly simple.

Perhaps the firewall standard could explicitly focus on iptables to at
least not be RH specific but trying to write up something for a lot of
different types of firewalls seems a bit out of scope for CSI.

	-Mike

[Stephen John Smoogen]

On Sat, Aug 2, 2008 at 4:03 PM, Mike McGrath <mmcgrath(a)redhat.com&gt; wrote:
>  On Sat, 2 Aug 2008, Stephen John Smoogen wrote:
>
> > One of the items that I have to deal with at UNM is a long list of
> > different firewalls and servers. I have Solaris(9,10), AIX(various),
> > MacOSX(various), and SuSE(various), RHEL(2,3,4,5), and Fedora(7,8,9)
> > to worry about with lots of different firewall needs for each one. As
> > I am trying to standardize the firewalls... I run into that same
> > headache everyone runs into at some point or another... How does one
> > organize the various different firewalls in both the VCS and the
> > upcoming configuration management system... while perfect is the enemy
> > of the good.. what is a good way of doing it as I see way to many ways
> > of laying it out in file structure.
> >
> > firewalls/project/OS/system
> > project/firewall/OS/system
> > OS/firewall/project/system
> > OS/system/project/firewall
> >
> > etc etc etc.  with some other // items added. Any ideas?
> >
>
>  Hmmm, well.  My initial thought for the standard was to focus explicitly
>  on Red Hat family type stuff which could mean the rest of that is not
>  compliant.  Even in the RH family type stuff I'm not quite sure the best
>  way to manage firewalls.  We're doing them with puppet templates right now
>  but our firewall rules are fairly simple.
>
>  Perhaps the firewall standard could explicitly focus on iptables to at
>  least not be RH specific but trying to write up something for a lot of
>  different types of firewalls seems a bit out of scope for CSI.
>  
Actually what I was thinking was a bit bigger than firewalls. In a
corporate/university/etc environment there are going to be lots of
different systems to deal with... how do you best manage that
complexity? [Say program set A requires one set of LDAP servers, and
set B requires another set.. and C is some beast in between.] Managing
the complexity of proliferation of files can be the hardest challenge
in taking over an existing setup and bringing it to order.

./rhel3
./rhel3/authorization/
./rhel3/authorization/projectA/
./rhel3/authorization/projectB/
./rhel3/email/
./rhel3/email/list-cluster/
./rhel3/email/groupwise/
./rhel3/email/zimbra/
./rhel3/email/mail-relays/
./rhel3/firewall/
./rhel3/firewall/projectA/
./rhel3/firewall/projectC/
....
./rhel3/logwatch/
./rhel3/monitoring/
./rhel3/openssh/
./rhel3/printing/
./rhel3/resolver/
./rhel3/superusers/
./rhel3/syslog/
./rhel3/tcp_wrapper/
./rhel3/timeservices/
./rhel3/backups/
./rhel3/usersec/
....

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[David Lutterkort]

On Sat, 2008-08-02 at 17:03 -0500, Mike McGrath wrote:
>  Even in the RH family type stuff I'm not quite sure the best
>  way to manage firewalls.  We're doing them with puppet templates right now
>  but our firewall rules are fairly simple.
>  
>  Perhaps the firewall standard could explicitly focus on iptables to at
>  least not be RH specific but trying to write up something for a lot of
>  different types of firewalls seems a bit out of scope for CSI. 
It's quite likely out-of-scope for CSI, though a vexing problem
nonetheless. One of the problems with iptables in particular is that
there is now user-level model of what iptables does, you configure it
directly by essentially putting kernel-internal data structures into the
'config' file. 

My favorite example is that you use iptables (and often the same file)
to open port 80 _and_ to forward packets across a bridged network
interface - from a user's point of view the two have no connection
whatsoever, one being an application-level configuration, the other
being a fairly low-level network plumbing issue.

Anyway, won't help CSI much ;)

David

[Jeroen van Meeuwen]

Stephen John Smoogen wrote:
>  One of the items that I have to deal with at UNM is a long list of
>  different firewalls and servers. I have Solaris(9,10), AIX(various),
>  MacOSX(various), and SuSE(various), RHEL(2,3,4,5), and Fedora(7,8,9)
>  to worry about with lots of different firewall needs for each one. As
>  I am trying to standardize the firewalls... I run into that same
>  headache everyone runs into at some point or another... How does one
>  organize the various different firewalls in both the VCS and the
>  upcoming configuration management system... while perfect is the enemy
>  of the good.. what is a good way of doing it as I see way to many ways
>  of laying it out in file structure.
>  
>  firewalls/project/OS/system
>  project/firewall/OS/system
>  OS/firewall/project/system
>  OS/system/project/firewall
>  
>  etc etc etc.  with some other // items added. Any ideas?
>   
Sounds like a very sweet apple to sink my teeth in. Are you asking how 
to standardize this best both CSI-style and puppet-style?

Kind regards,

Jeroen van Meeuwen
-kanarip

[Stephen John Smoogen]

On Sun, Aug 3, 2008 at 3:50 AM, Jeroen van Meeuwen <kanarip(a)kanarip.com&gt; wrote:
>  Stephen John Smoogen wrote:
> > One of the items that I have to deal with at UNM is a long list of
> > different firewalls and servers. I have Solaris(9,10), AIX(various),
> > MacOSX(various), and SuSE(various), RHEL(2,3,4,5), and Fedora(7,8,9)
> > to worry about with lots of different firewall needs for each one. As
> > I am trying to standardize the firewalls... I run into that same
> > headache everyone runs into at some point or another... How does one
> > organize the various different firewalls in both the VCS and the
> > upcoming configuration management system... while perfect is the enemy
> > of the good.. what is a good way of doing it as I see way to many ways
> > of laying it out in file structure.
> >
> > firewalls/project/OS/system
> > project/firewall/OS/system
> > OS/firewall/project/system
> > OS/system/project/firewall
> >
> > etc etc etc.  with some other // items added. Any ideas?
> >
>
>  Sounds like a very sweet apple to sink my teeth in. Are you asking how
>  to standardize this best both CSI-style and puppet-style?
>  
Yes. Since CSI (wow I have 3 acronyms to deal with CIS, CSI, and SCI..
I wonder if I can get a ISC, and ICS somewhere) needs to have a
regularized layout of how to deal with puppet, VCS and other things
that meet togther.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Jeroen van Meeuwen]

Stephen John Smoogen wrote:
>  On Sun, Aug 3, 2008 at 3:50 AM, Jeroen van Meeuwen
> <kanarip(a)kanarip.com&gt; wrote:
> > Stephen John Smoogen wrote:
> >> One of the items that I have to deal with at UNM is a long list of
> >> different firewalls and servers. I have Solaris(9,10), AIX(various),
> >> MacOSX(various), and SuSE(various), RHEL(2,3,4,5), and Fedora(7,8,9)
> >> to worry about with lots of different firewall needs for each one. As
> >> I am trying to standardize the firewalls... I run into that same
> >> headache everyone runs into at some point or another... How does one
> >> organize the various different firewalls in both the VCS and the
> >> upcoming configuration management system... while perfect is the enemy
> >> of the good.. what is a good way of doing it as I see way to many ways
> >> of laying it out in file structure.
> >>
> >> firewalls/project/OS/system
> >> project/firewall/OS/system
> >> OS/firewall/project/system
> >> OS/system/project/firewall
> >>
> >> etc etc etc.  with some other // items added. Any ideas?
> >>
> > Sounds like a very sweet apple to sink my teeth in. Are you asking how
> > to standardize this best both CSI-style and puppet-style?
> >
>  
>  Yes. Since CSI (wow I have 3 acronyms to deal with CIS, CSI, and SCI..
>  I wonder if I can get a ISC, and ICS somewhere) needs to have a
>  regularized layout of how to deal with puppet, VCS and other things
>  that meet togther.
>   
Awesome, here we go:

Judging from the list you give here in OSs and versions of those OSs, I 
doubt they all use "iptables"-compatible firewalls, and that every 
iptables or iptables-"alternative" command for each version of a given 
OS is compatible with all the versions of that OS.

I suggest the following naming schema / tree layout:

firewall (name of the module)
  `- files/ (to put the files in, doh)
      `- $os (from the $operatingsystem fact[1])
          `- $osver (from the $operatingsystemversion or
                     $lsbdistrelease fact[1])

Where the default firewall goes into firewall/files/, an old obsolete 
firewall for RHEL2 (whereas RHEL3-5 supposedly are common) goes into 
firewall/files/RedHat/2/, and the later major OS versions go into 
firewall/files/RedHat.

This might however need a fact to be created so that you know the 
firewall type as well (ipchains/iptables/foo/bar), so that you can:

class firewall {
     case $firewall_type { # Comes from the new fact
         iptables: { include firewall::iptables }
         ipchains: { include firewall::ipchains }
         foo:      { include firewall::foo }
         bar:      { include firewall::bar }
     }
}

Let me know what you think (as I'm starting to write the facts and 
module itself and stuff).

Kind regards,

Jeroen van Meeuwen
-kanarip

[1] The assignment of facts to variables is useful in this particular 
instance as there is now a common variable to use throughtout the rest 
of the manifests,  although facter in Fedora now knows about 
$operatingsystemrelease for many OSs.