Re: acme-firewall

[Poison Bit <poisonbit@gmail.com>]

On Fri, Jan 20, 2012 at 12:13 AM, Arturo Borrero Gonzalez
<cer.inet@linuxmail.org> wrote:
> Hi all,
>
> It's my first mail to a Debian list.

Welcome !


> [...]
>
> I read some info regarding debian and firewalling here:
>
> 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.


> [...]
>
> 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.


> [...]
>
> 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.


> [...]
>
> So, I ask you two things:
>
> · 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".


> · 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")

> [...]
>
> 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).


> [...]
> 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