acme-firewall

[Arturo Borrero Gonzalez]

Hi all,

It's my first mail to a Debian list.

I've been working on a debian package with a basic iptables-based
firewall system.


I read some info regarding debian and firewalling here:

http://wiki.debian.org/DebianFirewall
http://wiki.debian.org/Firewalls
http://wiki.debian.org/iptables

After deploy a bunch of local firewalls on linux servers and also as a
perimeter firewall based on linux & iptables, I discovered myself
always writing the same hierarchy of script files.

So, I decided to put all in a .deb package as a standar basic service
to the system, so the admin can easily write new rules and have a good
structure to start building a strong firewall from.

In RHEL & derivates distros, you can see some kind of "firewall"
service, all based on iptables, and here i've done the same, but in
the debian way.

By now, the package includes (adds) this to the system:

· An init.d script that manages iptables (including basic nat and
routing) as a service.
· The init.d script has his own /etc/defauld/firewall file with a few
directives for the admin to adapt the firewall. (such as change easily
the default policy in testing environments, the option to flush or not
nat rules when stopping the firewall and the option to stop routing or
not when stopping the firewall).
· Valid rsyslog conf to get firewall logs on /var/log/firewall.d/
· Reasonable logrotate conf to all files under /var/log/firewall.d
· Separates iptables files under /etc/firewall.d with this hierarchy:
local rules (input, output), external rules (forward), nat rules and
other rules (such as mangle ones). All files with no default
configuration other than permit traffic from and to the local machine.
· Full IPv6 support.

I see this basic approach a nice way to include a firewall as a
service in the system. No one of the packages listed in the debian
wiki seems to only deploy a structure where the system admin can build
his own firewall. This package just try to do that.

By contacting here I want to show you the package, seeking your
knowledge in sys admin and debian packaging.

If you see the package, you will notice that there are a lot of weird
things in some places, like the maintainer scripts. I know it. I'm new
writing .deb packages and i'm learning now the debian way. I know i
lack in knoledge of some d/files, like "rules", and there isn't any
references to copyright (absolutely GPL or something, of course)


All about the package itself could be subject of strong evolution, and
i would like to see it as fine-tuned as all others debian packages.

So, I ask you two things:

· What about the schema i'm talking on?
· What about the format of the package?


The package itself:
https://sites.google.com/site/ralarturo/acme-firewall_0.07-1_all.deb

In addition, I've been working by now for a while with debian-based HA
firewall clusters. I have some interesting documentation developed by
me regarding this issues.
The doc covers some aspect like comparisons between technologies
(keepalived, VRRP, pacemaker, conntrakd, netfilter, corosync,
heartbeat, and so on..) and explains a basic deployment in several
ways.
The problem is that document is in my native language (spanish) and
the translation is pending.

Here I reference it if you like to take a look:

https://sites.google.com/site/ralarturo/proyecto_integrado_arturo_borrero_pdf.pdf

That's all.
Best regards.

[Kenyon Ralph]

Post by Arturo Borrero Gonzalez
I've been working on a debian package with a basic iptables-based
firewall system.
http://wiki.debian.org/DebianFirewall
http://wiki.debian.org/Firewalls
http://wiki.debian.org/iptables

[...]

Post by Arturo Borrero Gonzalez
I see this basic approach a nice way to include a firewall as a
service in the system. No one of the packages listed in the debian
wiki seems to only deploy a structure where the system admin can build
his own firewall. This package just try to do that.

The iptables-persistent package is missing from those wiki pages. I
haven't tried it, but it may be worth looking at.

Maybe you could just install iptables-persistent and distribute the
iptables rules that you want, using puppet for example (of course, if
you're using puppet you would automate the installation of the package
too). Or, you could build your own local version of the package with
the default configuration you want.

[Michael]

I think he should go for his own package

[Arturo Borrero Gonzalez]

Post by Kenyon Ralph

Post by Arturo Borrero Gonzalez
I've been working on a debian package with a basic iptables-based
firewall system.
http://wiki.debian.org/DebianFirewall
http://wiki.debian.org/Firewalls
http://wiki.debian.org/iptables

[...]

Post by Arturo Borrero Gonzalez
I see this basic approach a nice way to include a firewall as a
service in the system. No one of the packages listed in the debian
wiki seems to only deploy a structure where the system admin can build
his own firewall. This package just try to do that.

The iptables-persistent package is missing from those wiki pages. I
haven't tried it, but it may be worth looking at.
Maybe you could just install iptables-persistent and distribute the
iptables rules that you want, using puppet for example (of course, if
you're using puppet you would automate the installation of the package
too). Or, you could build your own local version of the package with
the default configuration you want.
--
Kenyon Ralph

Hi there.

You are rigth. The package "iptables-persistent" has the same
objetives than mine. But there are still some differences between that
package and mine, such as:

· Low functionality init.d script. The script can't even stop the
firewall. In fact, the package just does what they told:

Descripción: Simple package to set up iptables on boot
This package contains just a system startup script that restores
iptables rules from a configuration file.

· My init.d script could stop the firewall, restart it, change quickly
the default policy, flush iptables rules without flushing nat ones
(very useful in some environments), change the ip_forwarding kernel
keys if the machine

I think acme-firewall is a better service aproach.

Best regards.

[Michael]

Arturo,

I think you should ask your question about packaging in a more general way (since it's not strictly restricted to your specific one) and maybe on the debian-users list. At least, under another subject. And try specify your questions in detail because else the answer would just be read the HowTo.

About your work, i can't say much but just, go ahead.

It appears you are trying to share something that would be useful for server / network administrators and maybe there is another list for those people. They don't ship any traffic summary figure with the overview of http://lists.debian.org/completeindex.html but i believe Debian-firewall has very low traffic these days.

Anyway, it seems to be the standard behavior nowadays that once someone answered to a mailing list question, but did not hit the nail, anyone else still thinks it's ok now and they skip it. You may try ask the netfilter list https://lists.netfilter.org/pipermail/netfilter-announce and cc to debian-firewall again.

[Michael]

Sorry, wrong link

netfilter user list: http://marc.info/?l=netfilter

[Poison Bit]

On Fri, Jan 20, 2012 at 12:13 AM, Arturo Borrero Gonzalez

Post by Arturo Borrero Gonzalez
Hi all,
It's my first mail to a Debian list.

Welcome !

Post by Arturo Borrero Gonzalez
[...]
http://wiki.debian.org/DebianFirewall

I worked in such article a boring afternoon.

Re-reading it... there are many places for improvement in the article.

Post by Arturo Borrero Gonzalez
[...]
In RHEL & derivates distros, you can see some kind of "firewall"
service, all based on iptables, and here i've done the same, but in
the debian way.

One good publicity for your package, could be to make a detailed
comparison with currently available tools
(iptables-save+iptables-restore, iptables-persistent, apt-firewall,
arno-iptables-firewall, dtc-xen-firewall, ferm, fiaif, filtergen,
firehol, firestarter, fwbuilder, ipkungfu, pyroman, shorewall, uif,
ufw, uruk...)

First of all, studing currently available packages, you may find ideas
for improvement in your.

Second, you may give sense to other package more, with some feature
loosed in other solutions, and a good (detailed) presentation on
current solutions Vs your, may attract more potential users.

Post by Arturo Borrero Gonzalez
[...]
I see this basic approach a nice way to include a firewall as a
service in the system. No one of the packages listed in the debian
wiki seems to only deploy a structure where the system admin can build
his own firewall. This package just try to do that.

Are you 100% sure ?

Some tools I've try by curiosity (some of the graphical ones) start
with an empty rule-set and helpers to expand it.

Post by Arturo Borrero Gonzalez
[...]
· What about the schema i'm talking on?

It's a nice idea. From my personal experience I could request for the
next version:

+ Take variables in one (or more) files, separate from the rules.
The rules uses the sourced variables. For example I don't want to
search "rules" to find IFACE="eth0"
+ Most firewall may have routing tables, vlans, bridges, vpns,
etc... so I think that the skeleton for logging and rules should take
that in mind
+ It could be nice to integrate /etc/sysctl.d/local.conf (or at
least more sysctl keys recommended for firewalls) with your management
scripts.
+ You're configuring firewall logging, thats nice for a start point,
but it's a need that may change from one firewall to others (from
avoid logs, to complex setups with multiple WAN addresses, bridges,
vpns and vlans, to people that wants ulogd)... maybe take all usage
cases in mind and make logging configurable (and ship a basic default
as you already do).
+ Nowdays, I would like that any firewall code I manage provides:
version control and sanity checks (is the interface here? is the
address here? shell syntax check pass? etc) for example your init.d
has some syntax errors like in [ ... "] (lack a space at " ])
+ Debian if-up-down maybe extended to match firewall policies (or
your init.d script should be installed in a way that does not exposes
"up" interfaces until rules are loaded).

They are all just suggestions... from my personal view point, nothing more.

I like iptables-save+iptables-restore for _very_ large rulesets,
because they are much better than loading hand-crafted nested for
loops of tons of rules (from the network disruption on reloading view
point)

Some people like logging with -m limit

I could love if the "schema" or "skeleton" of your system, could
include some doc outside comments and could include "helpers"
(scripts/commands) to manage rules (add/remove ip, interface, service,
rule, group, bandwitch, etc etc)

And now, at a side of "firewalls"....

You use in /etc/default: var = value # with spaces

And then you parse that as:

cat /etc/default/firewall | grep -i
^[[:space:]]*"routing"[[:space:]]*"="[[:space:]]*"yes"[[:space:]]*$ >
/dev/null
if [ $? -eq 0 ]
then

That is "useless use of cat" :), and gnu grep does has a -q switch:

grep -iq ^[[:space:]]*"routing"[[:space:]]*"="[[:space:]]*"yes"
/etc/default/firewall

And also you can do the if [ $? and the grep in one step: (if grep -iq
....; then...)

Could be better to just use standard shell syntax in /etc/default
(var=val #without spaces) and then source such file ( . "$file" ), so
no complex greps are needed.

As a side note, I really like your fully documented /etc/default. Just
remove "non-config-related" comment lines. And maybe put each info
above each variable.

mensaje should be message :)

your init.d checks (lot of [ -e and [ -r and [ $? -eq 0 ) maybe
re-factored to functions and take less lines... like file_exists
"$file" "error message", file_has_exec "$file" "error message"....

Also your (un)quoting style (as in rm -f $LOCK_FILE etc) may run into
junior sysadmins or windows people creating a weird file names and
breaking all code... as a safer alternative, not just add the quotes,
but also -- in case someone uses "-r ~" as filename. There are lot of
unquoted variable usage... rm -f -- "$LOCK_FILE".

Post by Arturo Borrero Gonzalez
· What about the format of the package?

As far as I know Debian init.d scripts use to have spaces (no tabs)
and use to avoid colors in stdout.

For the packaging, there are packaging and policy guides, irc channels
in irc.debian.org (in special look for "mentors")

Post by Arturo Borrero Gonzalez
[...]
In addition, I've been working by now for a while with debian-based HA
firewall clusters. I have some interesting documentation developed by
me regarding this issues.
The doc covers some aspect like comparisons between technologies
(keepalived, VRRP, pacemaker, conntrakd, netfilter, corosync,
heartbeat, and so on..) and explains a basic deployment in several
ways.
The problem is that document is in my native language (spanish) and
the translation is pending.

You can start by pasting the docs at debian wiki, under the "es"
(spanish) namespace, and requesting translators using such link (you
will need people that is able to edit a wiki and know Spanish+other
language).

Post by Arturo Borrero Gonzalez
[...]
That's all.
Best regards.

Thanks for your time, sharing and efforts. Have fun working on it.

It's always great when people wants to share acquired knowledge and
help to others. Congrats.

My suggestions are not telling you "make a
dino-full-featured-firewall", but more "think that a debian user, may
not have only one connection, only one subnet, only one routing table,
only one..."

Maybe I'm wrong and there should be a clear statement on the "target
public" of the package.


Greetings


--
Iñigo

[Poison Bit]

On Fri, Jan 20, 2012 at 3:16 PM, Poison Bit <***@gmail.com> wrote:

[...]

Post by Poison Bit
Greetings

One tip more... when your package ships the license, changelog, etc in
/usr/share/doc, you may ship a "examples" dir
(/usr/share/doc/acme-firewall/examples) to extend your skeleton.

Have fun!

[Michael]

Iñigo, thanks for stepping in !

Arturo,

Please don't feel discouraged. As Iñigo already said, it is totally ok to create a system for a specific purpose, restricted to some usage scenario. It is 100 time better than giving up upon the too big task !

Iñigos' suggestions are already hitting the point. When you make it highly configurable, and keep different scenarios in mind, it still can be restricted and 'narrow' in the beginning, but be expanded in future.

Commenting Iñigos good suggestions a little,

Post by Poison Bit
One good publicity for your package, could be to make a detailed
comparison with currently available tools

While this is for sure a good idea, generally, but i would not throw the burden upon you, to analyze all of them ...! Maybe investigate only those who seem to have a similar target or those that you simply are interested in.

One should be aware that the real value of your work is not in the code, but in the choices and decisions what specific situations to tackle and how to solve it, i.e. your security / networking knowledge. Ideally, you would have an UML flowchart that does not even depend on a specific platform or network backend. That would be the real value, and no other available package would include exactly your experiences.

For example, personally i installed shorewall but that's more just a more complex backend (still using iptables of course), it does not ship any specific scenario. It still leaves what you already have done to the admin.

I strongly support to just source the /etc/default files (it is a shell inbuilt command) to keep it simple. Some config sanity / bug checking could be done catching the shell return code (man trap).

Try to stay compatible to the Linux Standard Base as much as possible, it makes your package easier to port to another distribution. http://www.linuxfoundation.org/collaborate/workgroups/lsb/about
In this respect, it is another good idea to make anything configurable which uses specific Debian infrastructure (like backends.)

Post by Poison Bit
+ Debian if-up-down maybe extended to match firewall policies

But, isn't if-up-down somehow spinning towards becoming obsolete somehow ? It already does not bring up all available interfaces, today. I think this shifts to udev (and desktop daemons using dbus), but anyway, IMHO the firewall should not bring interfaces up or down, you could easily run into a bad mess with other managers. It should not bother about who manages that as long as it can poll the actual network state, and as long as there are triggering hooks. (Maybe add udev monitoring rules ?) But YMMV.

Post by Poison Bit

Post by Arturo Borrero Gonzalez
The problem is that document is in my native language (spanish) and
the translation is pending.

Arturo, I think that you are the only one who really will be able to translate your doc w/o mistakes... and your English is quite good.

Post by Poison Bit
You can start by pasting the docs at debian wiki, under the "es"
(spanish) namespace, and requesting translators using such link (you
will need people that is able to edit a wiki and know Spanish+other
language).

I wonder if anyone would dare to pick up the job :) it is not like there are many people with your knowledge, who are also working as translators.

But Arturo, you may ask for 50:50 teamwork, maybe someone picks it up as a matter of exercise then.

Post by Poison Bit
It's always great when people wants to share acquired knowledge and
help to others. Congrats.

ACK

Also Iñigo for good suggestions.

[Arturo Borrero Gonzalez]

Post by Michael
Iñigo, thanks for stepping in !
Arturo,
Please don't feel discouraged. As Iñigo already said, it is totally ok to create a system for a specific purpose, restricted to some usage scenario. It is 100 time better than giving up upon the too big task !
Iñigos' suggestions are already hitting the point. When you make it highly configurable, and keep different scenarios in mind, it still can be restricted and 'narrow' in the beginning, but be expanded in future.
Commenting Iñigos good suggestions a little,

Post by Poison Bit
One good publicity for your package, could be to make a detailed
comparison with currently available tools

While this is for sure a good idea, generally, but i would not throw the burden upon you, to analyze all of them ...! Maybe investigate only those who seem to have a similar target or those that you simply are interested in.
One should be aware that the real value of your work is not in the code, but in the choices and decisions what specific situations to tackle and how to solve it, i.e. your security / networking knowledge. Ideally, you would have an UML flowchart that does not even depend on a specific platform or network backend. That would be the real value, and no other available package would include exactly your experiences.
For example, personally i installed shorewall but that's more just a more complex backend (still using iptables of course), it does not ship any specific scenario. It still leaves what you already have done to the admin.
I strongly support to just source the /etc/default files (it is a shell inbuilt command) to keep it simple. Some config sanity / bug checking could be done catching the shell return code (man trap).
Try to stay compatible to the Linux Standard Base as much as possible, it makes your package easier to port to another distribution. http://www.linuxfoundation.org/collaborate/workgroups/lsb/about
In this respect, it is another good idea to make anything configurable which uses specific Debian infrastructure (like backends.)

Post by Poison Bit
  + Debian if-up-down maybe extended to match firewall policies

But, isn't if-up-down somehow spinning towards becoming obsolete somehow ? It already does not bring up all available interfaces, today. I think this shifts to udev (and desktop daemons using dbus), but anyway, IMHO the firewall should not bring interfaces up or down, you could easily run into a bad mess with other managers. It should not bother about who manages that as long as it can poll the actual network state, and as long as there are triggering hooks. (Maybe add udev monitoring rules ?) But YMMV.

Post by Poison Bit

Post by Arturo Borrero Gonzalez
The problem is that document is in my native language (spanish) and
the translation is pending.

Arturo, I think that you are the only one who really will be able to translate your doc w/o mistakes... and your English is quite good.

Post by Poison Bit
You can start by pasting the docs at debian wiki, under the "es"
(spanish) namespace, and requesting translators using such link (you
will need people that is able to edit a wiki and know Spanish+other
language).

I wonder if anyone would dare to pick up the job :) it is not like there are many people with your knowledge, who are also working as translators.
But Arturo, you may ask for 50:50 teamwork, maybe someone picks it up as a matter of exercise then.

Post by Poison Bit
It's always great when people wants to share acquired knowledge and
help to others. Congrats.

ACK
Also Iñigo for good suggestions.
--

Hi there!

First, thanks Iñigo and Michael for your detailed post, and thanks for
your interest. I thank you for your time and hassle.

Reading all emails, you give me a lot of TODO. Just give me time to
think about some issues both you said and i will come back with a
better package. I promisse it :) I can't say when, because my
extremely-full-time job.

About Iñigo and Michael ideas, i have to say:

I approached my package as a standar service in the system. Mostly
(maybe) inspired by RHEL iptables-save+iptables-restore method. I miss
(in debian) a standar way to deploy iptables rules. I know that the
system lacks of methods that a real firewall must have (with vpn,
checking interfaces, checking conectivity, a system to avoid dns
queries in each rule, and a long etc..) But that's not the scope of
the package.
In real deployment of a firewall, it's not rare to find a custom
script to manage the specific system. Thats my case: in my job (5k+
iptables rules, both IPv6 and IPv4) I have a totally different system.
I want you to understand the scope difference.

Said that, i will continue working on it.

About the HA-cluster-firewall documentation, I absolutely have no time
to translate it. So I will go to debian-wiki.

And again, thanks for all. I had doubt about how could a newbie
packager join a discussions like this.