[Firehol-support] Splitting config file

[Phil Whineray]

Hi

On Sun, May 08, 2016 at 06:55:50PM +0000, Simon Szustkowski wrote:
> Hi,
> 
> currently i have to write a server setup in ansible, which puts me into the
> need of splitting configuration files for services like firehol. That means
> in detail:
> 
> - Create a firehol playbook which installs firehol and deploys a basic
> ruleset which defines one management interface which allows the SSH
> service, and nothing more.
> - Each other playbook which installs a server software adds a bit of
> information, which is usually the service port which has to be opened in
> the firehol configuration so that the server is accessible from $zone.
> 
> Is there a possibility to implement this in firehol? Like, create a folder
> /etc/firehol/rules.d and a keyword in the /etc/firehol like "source all the
> files in rules.d", and then every server playbook adds a file like
> /etc/firehol/rules.d/apache.rule which contains like "server http accept"
> and/or service definitions for unknown services?
> 
> Currently, the monolithic configuration file approach could result in lots
> of regex insert-and-replace, and you have to re-run every server playbook
> after the basic firehol playbook because this one would replace all the
> neat regexp'd configuration with just the basic one instead.
> 
> I know, the firehol configuration is just some kind of bash script, but, to
> be honest, i have no idea how the "source all files in rules.d" command
> could look like, and if it could be possible to merge a server's service
> definition and access rules in just one file - so i'm hoping for answers
> here.

To implement something like this in the top-level firehol.conf you
can just write e.g.

for f in /etc/firehol/rules.d/*.rule
do
        if [ -r "$f" ]
        then
                source "$f"
        fi
done

wherever you want to include your rules files.

Please bear in mind that a assuming a set of rules can be linearly loaded
with out a wider context will probably only work in the simplest host
protection scenarios.

Hope that helps
Phil