~alpine/devel

9 6

[alpine-devel] Alpine Wall for firewall management

Details
Message ID
<alpine.LFD.2.02.1112301354560.21584@kunkku.net>
Sender timestamp
1325254137
DKIM signature
missing
Download raw message
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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Nathan Angelacos <nangel@alpinelinux.org>
Details
Message ID
<4EFE2E41.30809@alpinelinux.org>
In-Reply-To
<alpine.LFD.2.02.1112301354560.21584@kunkku.net> (view parent)
Sender timestamp
1325280833
DKIM signature
missing
Download raw message
On 12/30/2011 06:08 AM, Kaarle Ritvanen wrote:
> 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
>

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>





---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teräs <timo.teras@iki.fi>
Details
Message ID
<4F0175E2.7020603@iki.fi>
In-Reply-To
<4EFE2E41.30809@alpinelinux.org> (view parent)
Sender timestamp
1325495778
DKIM signature
missing
Download raw message
On 12/30/2011 11:33 PM, Nathan Angelacos wrote:
> On 12/30/2011 06:08 AM, Kaarle Ritvanen wrote:
>> 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
> 
> 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>

+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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jeremy Thomerson <jeremy@thomersonfamily.com>
Details
Message ID
<CADVmKVAZcc8QWmz_HLgOY_njSnaXyUt5NZp6oTpabf6Bwngexg@mail.gmail.com>
In-Reply-To
<alpine.LFD.2.02.1112301354560.21584@kunkku.net> (view parent)
Sender timestamp
1325612719
DKIM signature
missing
Download raw message
On Fri, Dec 30, 2011 at 9:08 AM, Kaarle Ritvanen <
kaarle.ritvanen@datakunkku.fi> wrote:

> 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<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
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20120103161922.24b68f37@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<alpine.LFD.2.02.1112301354560.21584@kunkku.net> (view parent)
Sender timestamp
1325603962
DKIM signature
missing
Download raw message
On Fri, 30 Dec 2011 16:08:57 +0200 (EET)
Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi> wrote:

> 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

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teräs <timo.teras@iki.fi>
Details
Message ID
<4F0419FC.3080801@iki.fi>
In-Reply-To
<CADVmKVAZcc8QWmz_HLgOY_njSnaXyUt5NZp6oTpabf6Bwngexg@mail.gmail.com> (view parent)
Sender timestamp
1325668860
DKIM signature
missing
Download raw message
On 01/03/2012 07:45 PM, Jeremy Thomerson wrote:
> 
> On Fri, Dec 30, 2011 at 9:08 AM, Kaarle Ritvanen
> <kaarle.ritvanen@datakunkku.fi <kaarle.ritvanen@datakunkku.fi>>
> wrote:
> 
>     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
>     <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?

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Harry Lachanas <grharry@freemail.gr>
Details
Message ID
<4F041FB0.10109@freemail.gr>
In-Reply-To
<alpine.LFD.2.02.1112301354560.21584@kunkku.net> (view parent)
Sender timestamp
1325670320
DKIM signature
missing
Download raw message
On 12/30/2011 04:08 PM, Kaarle Ritvanen wrote:
> 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
>
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.
Details
Message ID
<alpine.LFD.2.02.1201050906000.14693@kunkku.net>
In-Reply-To
<4F041FB0.10109@freemail.gr> (view parent)
Sender timestamp
1325747979
DKIM signature
missing
Download raw message
On Wed, 4 Jan 2012, Harry Lachanas wrote:

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

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
> ZONE = ( iface ) U ( Subnet(s) ) U ( ipset/Incoming ) U ( ipset/outgoing )

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

BR,
Kaarle


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Harry Lachanas <grharry@freemail.gr>
Details
Message ID
<4F055EF6.7020004@freemail.gr>
In-Reply-To
<alpine.LFD.2.02.1201050906000.14693@kunkku.net> (view parent)
Sender timestamp
1325752054
DKIM signature
missing
Download raw message
>> 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 )
>
> Why would you need separate ipsets for incoming and outgoing packets? 
> Couldn't you just define two zones?
>
> BR,
> Kaarle
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
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20120105112317.32270488@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<4F0419FC.3080801@iki.fi> (view parent)
Sender timestamp
1325758997
DKIM signature
missing
Download raw message
On Wed, 04 Jan 2012 11:21:00 +0200
Timo Teräs <timo.teras@iki.fi> wrote:

> On 01/03/2012 07:45 PM, Jeremy Thomerson wrote:

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

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)