Subject: [alpine-devel] Alpine Wall for firewall management

From: Kaarle Ritvanen <[email-masked]>
Date: Fri, 30 Dec 2011 16:08:57 +0200 (EET)

Hello,

We have a new firewall management framework under early development. 
Please check out the draft specification here and provide your comments:

http://wiki.alpinelinux.org/wiki/Alpine_Wall

BR,
Kaarle

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Natanael Copa <[email-masked]>
Date: Tue, 3 Jan 2012 16:19:22 +0100

On Fri, 30 Dec 2011 16:08:57 +0200 (EET)

> http://wiki.alpinelinux.org/wiki/Alpine_Wall

Very nice!

Regarding XML vs JSON vs YAML, I don't really like XML in general,
probably because i feel it generates bigger files. json would make it
easy to do things with javascript in browser and has lots of libs for
lua. I would be ok with YAML too.

Framework or template language? I have no strong opinions. I don't feel
competent enough to have opinion about it.

Thanks for working on this!

-nc

---

---

From: Harry Lachanas <[email-masked]>
Date: Wed, 04 Jan 2012 11:45:20 +0200

> http://wiki.alpinelinux.org/wiki/Alpine_Wall
Very nice effort indeed ...
However I would like to see some level of abstraction in the ZONE 
specification.
That is,

Instead of a 1 to 1 relation between zone and interface+subnet

I would like to attach an ipset there as a part of a zone.

In other words

Zone = ( iface ) U ( subnet(s) ) U ( ipset )
This should also consider the aspect if incoming and outgoing 
connections, so expanding this would impose
ZONE = ( iface ) U ( Subnet(s) ) U ( ipset/Incoming ) U ( ipset/outgoing )

where U = union.

Perhaps Superimposing IPSETS on top of ip tables could offer a suitable 
degree  of freedom and abstraction to move things around.
IPSET attributes -> ZONES -> Interfaces

The promising element of ipsets is the elimination of iptables 
reloading. Once values are added to the sets they are seen and executed 
from iptables.

Regards
Harry.

---

From: Kaarle Ritvanen <[email-masked]>
Date: Thu, 5 Jan 2012 09:19:39 +0200 (EET)

On Wed, 4 Jan 2012, Harry Lachanas wrote:

> However I would like to see some level of abstraction in the ZONE specification.
> That is,
> 

I'm not sure what your use case is, but I could interpret this in two
alternative ways:

1. User configures a complex zone consisting of serveral host and/or
subnet addresses. Alpine Wall optimizes the zone lookup by constructing an
ipset based on the definition, which is then used in the actual rules.

2. User defines the zone with a reference to an existing ipset, which is
managed manually or by some other tool.

I think both are valid use cases. The second one is particularly useful 
e.g. in connection with captive portal authentication.

Now that we got into set theory, I was actually thinking an intersection 
between the interface and subnet definitions rather than union. If a 
packet with source address <a> arrives on interface <i>, it is considered 
to originate from zone Z = (I, S) (where I is the set of interfaces and S 
is the set of subnets) if and only if I includes <i>, and <a> belongs to 
any subnet of S. In zone definitions, I would default to the set of all 
interfaces and S to {0.0.0.0/0, ::}. The destination zone would be defined 
in a similar way based on the packet's destination address and interface.

> This should also consider the aspect if incoming and outgoing connections, so
> expanding this would impose

Why would you need separate ipsets for incoming and outgoing packets? 
Couldn't you just define two zones?

BR,
Kaarle

---

---

From: Harry Lachanas <[email-masked]>
Date: Thu, 05 Jan 2012 10:27:34 +0200

> Couldn't you just define two zones?
Haloo Kaarle,

Actually this came into my mind as I was pressing the SEND Button ...
But then again .... My mind flashed ...
What about the pre-routing , outgoing chain,
one aspect that I like in tables is the high-route marks issue  that 
lets me do shaping as well as policy based routing.
i.e.  Route port 25 traffic through ISP provider X .... ( Sorry I never 
mentioned the Multi ISP Setups )  the condition module comes very handy 
in such cases ...

Here is a live example in one of my firewalls

pkts bytes target     prot opt in     out     source               
destination
17516 1426K MARK       tcp  --  vlan20 *       0.0.0.0/0            
0.0.0.0/0           tcp dpt:25 condition !isp1_down MARK xset 
0x100/0xffffffff
     0     0 MARK       tcp  --  vlan20 *       0.0.0.0/0            
0.0.0.0/0           tcp dpt:25 condition isp1_down MARK xset 
0x200/0xffffffff

Line status detector issues an "echo 1 > /proc/net/nf_condition/isp1_down"
and SMTP traffic flows through ISP2 that otherwise would have been 
routed through ISP1 ...
or redirect port 80 traffic to a proxy ... etc ...

Thanks
Harry

---

From: Nathan Angelacos <[email-masked]>
Date: Fri, 30 Dec 2011 13:33:53 -0800

> http://wiki.alpinelinux.org/wiki/Alpine_Wall

Nice write-up!  Thanks!   This looks promising.

<phb>
Interesting name choice too.  Its functional description almost exactly 
matches http://en.wikipedia.org/wiki/Alpine_Wall
</phb>

---

---

From: Timo Teräs <[email-masked]>
Date: Mon, 02 Jan 2012 11:16:18 +0200

> matches http://en.wikipedia.org/wiki/Alpine_Wall

+1 from here too.

The discussion I'd like to have is if the "new template language" or
"Lua framework" would be used internally. I don't have strong opinion
either way. I would probably personally go with the framework approach,
but that's just because I'm more familiar with that kind of things.

I'm trying to list pros and cons, so please feel free to add thoughts.

New DSL (Domain Specific Language):
 + fast to write simple functionality
 + template is probably shorter than corresponding framework code
 - might need additional framework support for complex things
 - requires learning and definition of a new language
 - one needs to do template for each target "language"
   (iptables-save file format would be enough)

Purely Framework:
 + complex policies and transformations doable programmatically
 + familiar programming language
 - new framework API needs learning
 - might need internal representations of firewall rules, adding
   to work (but adding additional target formats easier)

Also, my guess is that new language + compiler for it is slower. Though
the differences would be fraction of second class for the common case.

So to me it sounds like both are viable choices. And ultimately it'll
probably be left as implementator's choice.

Cheers,
 Timo

---

---

From: Jeremy Thomerson <[email-masked]>
Date: Tue, 3 Jan 2012 12:45:19 -0500

On Fri, Dec 30, 2011 at 9:08 AM, Kaarle Ritvanen <
[email-masked]> wrote:

> http://wiki.alpinelinux.org/**wiki/Alpine_Wall<http://wiki.alpinelinux.org/wiki/Alpine_Wall>
>
> BR,
> Kaarle
>

Not having looked through all of it in great detail, I have a question
about the following statement from the wiki:

> The back-end will contain functionality for domain name resolution. In the
> data model, hosts of groups thereof can be identified by their domain
> names. The back-end will resolve these to IP addresses, which will be
> stored in the target files, so there will be no need to resolve anything
> when activating the configuration during boot.
>
At what point does the back-end do the resolution?  It seems like it would
need to periodically update this since a firewall may run weeks, months, or
years with no change and name resolution could change periodically.  Will
it observe TTL?

Overall, the plan looks really good.  I'd be curious: will there be a CLI
for the functionality, or will it only be in ACF webapp?  I typically don't
use ACF on my Alpine boxes.  I assume without ACF I'll just need to modify
the Alpine Wall config files directly?

Thanks!
Jeremy Thomerson

---

From: Timo Teräs <[email-masked]>
Date: Wed, 04 Jan 2012 11:21:00 +0200

On 01/03/2012 07:45 PM, Jeremy Thomerson wrote:
> 
> On Fri, Dec 30, 2011 at 9:08 AM, Kaarle Ritvanen
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     Hello,
> 
>     http://wiki.alpinelinux.org/__wiki/Alpine_Wall
>     <http://wiki.alpinelinux.org/wiki/Alpine_Wall>
> 
>     BR,
>     Kaarle
> 
> 
>     The back-end will contain functionality for domain name resolution.
>     In the data model, hosts of groups thereof can be identified by
>     their domain names. The back-end will resolve these to IP addresses,
>     which will be stored in the target files, so there will be no need
>     to resolve anything when activating the configuration during boot.
> 
> At what point does the back-end do the resolution?  It seems like it
> would need to periodically update this since a firewall may run weeks,
> months, or years with no change and name resolution could change
> periodically.  Will it observe TTL?

I believe updating of the DNS records to IPv4/IPv6 addresses would be
administrative step. The idea is to create permanent cache of the fqdn
domain names, that gets refreshed only as a result of running a command
(or clicking acf button).

This is because otherwise just someone updating a dns entry could break
the whole firewall. Additionally, during bootup we cannot usually do dns
queries (so we really need cached info). However, allowing usage of dns
names will be beneficial, as it avoid duplication of information in
multiple places. This should be sufficient as your server dns records
should not change that often; and when they change you probably want to
double check your firewall rules anyway.

The idea is also that for fqdn's both A and AAAA records are used, so
alpine wall would automatically create both ipv4 and ipv6 firewall rules.

> Overall, the plan looks really good.  I'd be curious: will there be a
> CLI for the functionality, or will it only be in ACF webapp?  I
> typically don't use ACF on my Alpine boxes.  I assume without ACF I'll
> just need to modify the Alpine Wall config files directly?

Yes, plan is to have command line functionality as well. ACF would be
just polished way to display the data.

- Timo

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 5 Jan 2012 11:23:17 +0100

On Wed, 04 Jan 2012 11:21:00 +0200

> > would need to periodically update this since a firewall may run
> > weeks, months, or years with no change and name resolution could
> > change periodically.  Will it observe TTL?
> 
> domain names, that gets refreshed only as a result of running a
> command (or clicking acf button).
> 
> This is because otherwise just someone updating a dns entry could
> break the whole firewall. Additionally, during bootup we cannot
> usually do dns queries (so we really need cached info). However,
> allowing usage of dns names will be beneficial, as it avoid
> duplication of information in multiple places. This should be
> sufficient as your server dns records should not change that often;
> and when they change you probably want to double check your firewall
> rules anyway.
> 

I really like this. It means that if you move a service to new IP you
update DNS and then just refresh dns cache in firewall rather than sync
the ip address info in firewall config. And yes, I would prefer that dns
refresh in firewall is a manual admin step.

Very nice! Thanks!

-nc

---