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