What gets a Destination IP into the iptables INPUT chain?

[Whit Blauvelt]

Hi,

Clearly a Destination of Any gets represented both in iptable's INPUT and
FORWARD. But when a destination is a specified IP, it only goes into
FORWARD. At least that's what I'm seeing. That's appropriate for example if
DNAT'ing to a box inside the firewall, but what's the setting to enable one
specific IP on the firewall to connect with a service on the firewall
itself? That is, how do I get it into the INPUT chain when it's not Any, but
only a single destination IP (of several on a public interface) which needs
to allow INPUT for a Service hosted on the firewall itself?

Thanks. (Maybe the question's been answered here before. I looked back a ways
through the subject lines without finding it. Is there an efficient way to
search the list archive? Can't find that either.)

Whit

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Whit Blauvelt]

Okay, my problem is more specific. I see that "If address used in DST
matches one of the addresses of the firewall, then code goes into INPUT
chain." But what I need to do is force the compiler to put code into the
INPUT chain even when the address is as-yet unspecified - because the public
interface has multiple addresses, not just the one which can be set to
match the interface in fwbuilder, and also because I'm using a custom
external Address Table at run time to add these addresses into the fwbuilder
rules.

So how do I tell fwbuilder that specific addresses - whose status fwbuilder
is ignorant of at compile time, because they are not the single address it
knows for the interface, and/or will be assigned at run time rather than
compile time - require representation in INPUT and OUTPUT rules because they
are for services hosted on the firewall?

Or do I need to do something bizarre with NAT'ing the firewall to itself as
a workaround?

Whit

On Fri, Jul 17, 2009 at 04:55:14PM -0400, Whit Blauvelt wrote:

> Hi,
>
> Clearly a Destination of Any gets represented both in iptable's INPUT and
> FORWARD. But when a destination is a specified IP, it only goes into
> FORWARD. At least that's what I'm seeing. That's appropriate for example if
> DNAT'ing to a box inside the firewall, but what's the setting to enable one
> specific IP on the firewall to connect with a service on the firewall
> itself? That is, how do I get it into the INPUT chain when it's not Any, but
> only a single destination IP (of several on a public interface) which needs
> to allow INPUT for a Service hosted on the firewall itself?
>
> Thanks. (Maybe the question's been answered here before. I looked back a ways
> through the subject lines without finding it. Is there an efficient way to
> search the list archive? Can't find that either.)
>
> Whit

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Vadim Kurland ✎]

On Jul 17, 2009, at 2:15 PM, Whit Blauvelt wrote:

> Okay, my problem is more specific. I see that "If address used in DST
> matches one of the addresses of the firewall, then code goes into  
> INPUT
> chain." But what I need to do is force the compiler to put code into  
> the
> INPUT chain even when the address is as-yet unspecified - because  
> the public
> interface has multiple addresses, not just the one which can be set to
> match the interface in fwbuilder, and also because I'm using a custom
> external Address Table at run time to add these addresses into the  
> fwbuilder
> rules.
>

you can put firewall object in the destination element of the rule,  
this will generate rule in the INPUT chain and it won't match  
destination address at all. You can restrict it to a specific  
interface by placing interface object in the "Interface" rule elemnt  
and setting direction to "inbound".

If you want to both have it in INPUT chain and match destination  
address, then you can put interface object in the destination element  
of the rule. If interface is marked as "dynamic", there will be a  
shell code added to get its address at run time. Unfortunately this  
code can deal only with single address per interface, so this may not  
quite work for you.

Are these addresses completely random and unknown, as when they are  
assigned via DHCP, or do you need this for the failover configuration  
and addresses are known, but belong to the cluster ?

--vk

> So how do I tell fwbuilder that specific addresses - whose status  
> fwbuilder
> is ignorant of at compile time, because they are not the single  
> address it
> knows for the interface, and/or will be assigned at run time rather  
> than
> compile time - require representation in INPUT and OUTPUT rules  
> because they
> are for services hosted on the firewall?
>
> Or do I need to do something bizarre with NAT'ing the firewall to  
> itself as
> a workaround?
>
> Whit
>
> On Fri, Jul 17, 2009 at 04:55:14PM -0400, Whit Blauvelt wrote:
>> Hi,
>>
>> Clearly a Destination of Any gets represented both in iptable's  
>> INPUT and
>> FORWARD. But when a destination is a specified IP, it only goes into
>> FORWARD. At least that's what I'm seeing. That's appropriate for  
>> example if
>> DNAT'ing to a box inside the firewall, but what's the setting to  
>> enable one
>> specific IP on the firewall to connect with a service on the firewall
>> itself? That is, how do I get it into the INPUT chain when it's not  
>> Any, but
>> only a single destination IP (of several on a public interface)  
>> which needs
>> to allow INPUT for a Service hosted on the firewall itself?
>>
>> Thanks. (Maybe the question's been answered here before. I looked  
>> back a ways
>> through the subject lines without finding it. Is there an efficient  
>> way to
>> search the list archive? Can't find that either.)
>>
>> Whit

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Whit Blauvelt]

On Fri, Jul 17, 2009 at 02:47:00PM -0700, Vadim Kurland ✎ wrote:

> Are these addresses completely random and unknown, as when they are  
> assigned via DHCP, or do you need this for the failover configuration  
> and addresses are known, but belong to the cluster ?

Addresses belong to the cluster (not DHCP). So it looks like the only way to
be address-specific and use the INPUT chain is to assign all addresses to
each interface on each firewall, and just go ahead and generate unused rules
for the addresses which aren't currently on the interfaces. (While being
careful to keep fwbuilder from trying to assign any addresses to the
interfaces themselves.)

These extra rules and steps probably don't cost enough to worry about. It
would be convenient if there were checkboxs somewhere to insist that a
particular rule went to INPUT/OUTPUT, or FORWARD, or both. But the tradeoff
there is whether to keep the GUI simpler, or the generated rules simpler.

Another way to get most of the way there would be to have a single checkbox
for each Address Table, to say whether addresses there should be treated as
known local interface addresses, and thus trigger INPUT/OUTPUT chain
generation.

- Whit

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Vadim Kurland ✎]

On Jul 17, 2009, at 4:19 PM, Whit Blauvelt wrote:

> On Fri, Jul 17, 2009 at 02:47:00PM -0700, Vadim Kurland ✎ wrote:
>
>> Are these addresses completely random and unknown, as when they are
>> assigned via DHCP, or do you need this for the failover configuration
>> and addresses are known, but belong to the cluster ?
>
> Addresses belong to the cluster (not DHCP). So it looks like the  
> only way to
> be address-specific and use the INPUT chain is to assign all  
> addresses to
> each interface on each firewall, and just go ahead and generate  
> unused rules
> for the addresses which aren't currently on the interfaces.

this is the simplest approach with v3.0.x


> (While being
> careful to keep fwbuilder from trying to assign any addresses to the
> interfaces themselves.)
>

just turn checkbox off in the "Script" tab of the firewall settings  
dialog


> These extra rules and steps probably don't cost enough to worry  
> about. It
> would be convenient if there were checkboxs somewhere to insist that a
> particular rule went to INPUT/OUTPUT, or FORWARD, or both. But the  
> tradeoff
> there is whether to keep the GUI simpler, or the generated rules  
> simpler.
>

also, INPUT/OUTPUT/FORWARD business is purely iptables artifact, there  
is nothing like that in any other supported platform.


> Another way to get most of the way there would be to have a single  
> checkbox
> for each Address Table, to say whether addresses there should be  
> treated as
> known local interface addresses, and thus trigger INPUT/OUTPUT chain
> generation.



"known local" is a good term, it is generic and does not give  
impression of being specific to only iptables. However the feature is  
specific to iptables and not useful for other platforms. I'd like to  
avoid doing this if I can.

Just give me a couple of days, I'll post new 3.1 build that should do  
what you want without all these hacks.



Vadim Kurland ✍
vadim@...







------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Whit Blauvelt]

On Fri, Jul 17, 2009 at 04:28:01PM -0700, Vadim Kurland ✎ wrote:

> also, INPUT/OUTPUT/FORWARD business is purely iptables artifact, there  
> is nothing like that in any other supported platform.

A couple of questions then:

1. Does the iptables way contribute something to security? On first glance
   it seems it does, since it can lock things down more precisely. But on
   second thought maybe it doesn't buy much.

2. If it _doesn't_ really contribute anything to security, why shouldn't
   fwbuilder just write _everything_ to all three. As it is it's partially
   respecting the security model of iptables. (To fully respect it you'd have
   to allow INPUT/OUTPUT rules that are _not_ also applied to FORWARD, I
   think.) But if that model is more an artifact than something with
   real-world security implications....

Anyway, happy to wait for the next fwbuilder version and see what that
allows.

Thanks,
Whit

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Vadim Kurland ✎]

On Jul 17, 2009, at 4:41 PM, Whit Blauvelt wrote:

> On Fri, Jul 17, 2009 at 04:28:01PM -0700, Vadim Kurland ✎ wrote:
>
>> also, INPUT/OUTPUT/FORWARD business is purely iptables artifact,  
>> there
>> is nothing like that in any other supported platform.
>
> A couple of questions then:
>
> 1. Does the iptables way contribute something to security? On first  
> glance
>   it seems it does, since it can lock things down more precisely.  
> But on
>   second thought maybe it doesn't buy much.
>

I do not think the way iptables does it makes it better or worse than  
other platforms in terms of security. You can achieve the same  
precision doing filtering in PF where there are no chains and  
administrator does not have to remember which chain certain rule  
should go to. Separation of chains is just an implementation detail.

> 2. If it _doesn't_ really contribute anything to security, why  
> shouldn't
>   fwbuilder just write _everything_ to all three. As it is it's  
> partially
>   respecting the security model of iptables. (To fully respect it  
> you'd have
>   to allow INPUT/OUTPUT rules that are _not_ also applied to  
> FORWARD, I
>   think.) But if that model is more an artifact than something with
>   real-world security implications....
>

It could put all rules in all chains, but there are more standard  
chains than just INPUT/OUTPUT/FORWARD so if it put all rules in all  
chains, it would be rather sub-optimal.

Most of the time high level rules defined in fwbuilder can be properly  
translated into iptables commands using minimal set of chains as  
necessary. Things get difficult when one wants to write rules for  
unknown addresses, but there are ways around that too.


> Anyway, happy to wait for the next fwbuilder version and see what that
> allows.


Should be soon. However it is not ready for production use so we  
should be careful. I do not want to give you impression that it will  
be  a production ready release. This is still code we are testing and  
some of the design ideas are being ironed out. I would like you to try  
it out to see if it solves your problem, but there could be bugs and  
some things are still in flux.


Vadim Kurland ✍
vadim@...







------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Henrique de Moraes Holschuh-3]

On Fri, 17 Jul 2009, Whit Blauvelt wrote:
> > also, INPUT/OUTPUT/FORWARD business is purely iptables artifact, there  
> > is nothing like that in any other supported platform.
>
> A couple of questions then:
>
> 1. Does the iptables way contribute something to security? On first glance
>    it seems it does, since it can lock things down more precisely. But on
>    second thought maybe it doesn't buy much.

It contributes a lot to performance.  The kernel doesn't look at rules that
make no sense for a particular flow direction (inbound, outbound, passing
through).

> 2. If it _doesn't_ really contribute anything to security, why shouldn't
>    fwbuilder just write _everything_ to all three. As it is it's partially

Because that will cause a severe performance degradation in any non-joke
firewall handling multi-gigabit traffic.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Whit Blauvelt]

On Sat, Jul 18, 2009 at 12:45:57PM -0300, Henrique de Moraes Holschuh wrote:

> It contributes a lot to performance.  The kernel doesn't look at rules that
> make no sense for a particular flow direction (inbound, outbound, passing
> through).
>
> > 2. If it _doesn't_ really contribute anything to security, why shouldn't
> >    fwbuilder just write _everything_ to all three. As it is it's partially
>
> Because that will cause a severe performance degradation in any non-joke
> firewall handling multi-gigabit traffic.

Good answer. Thanks. If we're trying for optimal performance then, should
fwbuilder incorporate an option to build INPUT/OUTPUT rules that are not
uselessly duplicated in FORWARD rules? The general assumption might be that
most firewalls are dedicated, so have minimal INPUT/OUTPUT and a whole lot
of FORWARD. In this setup economizing on what goes into INPUT/OUTPUT buys us
the most.

But going forward will the assumption hold? Since fwbuilder makes it far
easier to distribute the same ruleset across multiple machines, and maintain
it that way, there are going to be system architects who decide not to
bottleneck everything through one dedicated firewall, but instead distribute
the firewall across a collection of public-facing servers with other primary
roles. These would be boxes needing a whole lot of INPUT/OUTPUT rules, but
little or nothing by way of FORWARD rules.

So on an alternative architecture that fwbuilder makes more practicable, it
also at present echoes every useful INPUT/OUTPUT rule with a
performance-degrading vestigial FORWARD rule. On the other hand, with a
distributed firewalling the firewall isn't so often a critical bottleneck,
so maybe we can afford the inefficiency in this setup?

A different question: Have you been able to push multi-gigabit traffic
through a Linux/iptables box? My understanding from discussion elsewhere is
to expect it to top out at about 1 gigabit, assuming a fast CPU and solid
NICs. The common claim is it takes Cisco or equivalent hardware with ASICs
to go beyond that. Is that false? Has Netfilter/iptables gotten that good?

Best,
Whit

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Vadim Kurland ✎]

On Jul 18, 2009, at 9:52 AM, Whit Blauvelt wrote:

> On Sat, Jul 18, 2009 at 12:45:57PM -0300, Henrique de Moraes  
> Holschuh wrote:
>
>> It contributes a lot to performance.  The kernel doesn't look at  
>> rules that
>> make no sense for a particular flow direction (inbound, outbound,  
>> passing
>> through).
>>
>>> 2. If it _doesn't_ really contribute anything to security, why  
>>> shouldn't
>>>   fwbuilder just write _everything_ to all three. As it is it's  
>>> partially
>>
>> Because that will cause a severe performance degradation in any non-
>> joke
>> firewall handling multi-gigabit traffic.
>
> Good answer. Thanks. If we're trying for optimal performance then,  
> should
> fwbuilder incorporate an option to build INPUT/OUTPUT rules that are  
> not
> uselessly duplicated in FORWARD rules?

could you give an example of when it uselessly duplicates rules into  
the FORWARD chain ?


> The general assumption might be that
> most firewalls are dedicated, so have minimal INPUT/OUTPUT and a  
> whole lot
> of FORWARD. In this setup economizing on what goes into INPUT/OUTPUT  
> buys us
> the most.
>

this assumption is not correct. Users have wide variety of firewall  
configurations and configuration generation tool can not operate under  
the assumption that some configurations are more prevailing than others.

> But going forward will the assumption hold? Since fwbuilder makes it  
> far
> easier to distribute the same ruleset across multiple machines, and  
> maintain
> it that way, there are going to be system architects who decide not to
> bottleneck everything through one dedicated firewall, but instead  
> distribute
> the firewall across a collection of public-facing servers with other  
> primary
> roles. These would be boxes needing a whole lot of INPUT/OUTPUT  
> rules, but
> little or nothing by way of FORWARD rules.
>
> So on an alternative architecture that fwbuilder makes more  
> practicable, it
> also at present echoes every useful INPUT/OUTPUT rule with a
> performance-degrading vestigial FORWARD rule.

no it doesnt mirror them. You just have a lot of rules with "any" in  
destination/source and have option "assume firewall is part of any"  
turned on. This means rule with "any" in destination generates  
iptables commands in INPUT and FORWARD chains. If you turn this option  
off, then the rule will only go into the FORWARD chain. If address in  
destination matches one of the addresses that belong to the firewall,  
the rule will always go into INPUT chain. If address in destination is  
not "any" and does not match any address of the firewall, the rule  
goes only into FORWARD chain.

Your case is very specific, you want the program to put rules that  
have unknown addresses into the INPUT chain. This is impossible  
without either special hacks or different firewall model. I believe  
that support for clustering configurations we are currently working on  
should solve this problem nicely.

> On the other hand, with a
> distributed firewalling the firewall isn't so often a critical  
> bottleneck,
> so maybe we can afford the inefficiency in this setup?
>
> A different question: Have you been able to push multi-gigabit traffic
> through a Linux/iptables box? My understanding from discussion  
> elsewhere is
> to expect it to top out at about 1 gigabit, assuming a fast CPU and  
> solid
> NICs. The common claim is it takes Cisco or equivalent hardware with  
> ASICs
> to go beyond that. Is that false? Has Netfilter/iptables gotten that  
> good?

may be someone on the list can answer this ? I have never seen Linux  
box push that much traffic with any kind of complicated packet  
inspection.


Vadim Kurland ✍
vadim@...







------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Whit Blauvelt]

On Sat, Jul 18, 2009 at 10:11:38AM -0700, Vadim Kurland ✎ wrote:

> could you give an example of when it uselessly duplicates rules into the
> FORWARD chain ?

Sure. I have a box that's not primarily a firewall, but has a public IP, so
runs iptables. It has httpd running on it that's available on the public
interface. The rules I've been running on it have dtp:80 rules in both INPUT
and OUTPUT, but not in FORWARD. The ruleset fwbuilder generates puts the
dtp:80 rules in FORWARD too. It always puts rules in FORWARD, right?

When boxes behind the firewall are providing for instance dtp:80 service
they also typically don't require FORWARD rules, but get handled by DNAT in
PREROUTING. So in firewalls I'm running with some services on them, some
services NATed behind them (DNAT in for some, SNAT out for others), very
little ends up in FORWARD at all - basically just rules for stuff routed
between LAN and DMZ. Rebuilding the rulesets with fwbuilder, I see lots of
FORWARD rules that essentially duplicate INPUT/OUTPUT rules, but aren't
doing anything useful in my setup.

For example:

echo "Rule 3 (eth1)"
#
#
#
$IPTABLES -A INPUT  -i eth1 -p tcp -m tcp  -d 123.456.789.11  --dport 80  -m state --state NEW  -j ACCEPT
$IPTABLES -A OUTPUT  -o eth1 -p tcp -m tcp  -d 123.456.789.11  --dport 80  -m state --state NEW  -j ACCEPT
$IPTABLES -A FORWARD  -o eth1 -p tcp -m tcp  -d 123.456.789.11  --dport 80  -m state --state NEW  -j ACCEPT

This is where 123.456.789.11 is recognized by fwbuilder as the IP of eth1.
The first two rules are necessary if 123.456.789.11 is to have
publicly-available web server running locally. The last rule does nothing
useful at all, right? What's admitted in on INPUT and out on OUTPUT never
crosses FORWARD. It works fine without it, and may even be a security flaw
if someone devises a way to take advantage of an ACCEPT rule in FORWARD
leaving a door open where there's no need for it - although the door doesn't
seem to much go to anywhere.

> no it doesnt mirror them. You just have a lot of rules with "any" in  
> destination/source and have option "assume firewall is part of any"  
> turned on. This means rule with "any" in destination generates iptables
> commands in INPUT and FORWARD chains. If you turn this option off, then
> the rule will only go into the FORWARD chain.

I understand that. What would be ideal is a way to put rules _only_ in
INPUT/OUTPUT, with no corresponding rule in FORWARD. INPUT/OUTPUT and
FORWARD are entirely separate. In distributed firewall structures where the
firewalls are on each of the servers, you ideally want a bunch of
INPUT/OUTPUT rules with no duplication of them as FORWARD rules. In
structures where the firewall is separate hardware, and the services all on
boxes behind it, the opposite is ideal - lots of FORWARD rules, but very
minimal use of INPUT/OUTPUT, maybe just ssh, ping, ntp, to the firewall box
itself.

> Your case is very specific, you want the program to put rules that have
> unknown addresses into the INPUT chain. This is impossible without either
> special hacks or different firewall model. I believe that support for
> clustering configurations we are currently working on should solve this
> problem nicely.

I appreciate your attention to my other concern. But I think that's entirely
separate. My concern here is that because some of us sometimes like to run a
set of firewall rules across multiple public-facing servers, rather than put
all the servers behind a separate firewall, for this use we'll have the most
efficient rulesets if they don't include unnecessary FORWARD chain
duplications of rules which we only need on the INPUT/OUTPUT chains.

That said, fwbuilder generates pretty efficient rulesets, even where
unnecessary FORWARD rules are included as a byproduct of getting the
necessary INPUT/OUTPUT rules to be compiled. You've got a beautiful project
here.

Best,
Whit

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Vadim Kurland ✎]

On Jul 18, 2009, at 12:12 PM, Whit Blauvelt wrote:

> On Sat, Jul 18, 2009 at 10:11:38AM -0700, Vadim Kurland ✎ wrote:
>
>> could you give an example of when it uselessly duplicates rules  
>> into the
>> FORWARD chain ?
>
> Sure. I have a box that's not primarily a firewall, but has a public  
> IP, so
> runs iptables. It has httpd running on it that's available on the  
> public
> interface. The rules I've been running on it have dtp:80 rules in  
> both INPUT
> and OUTPUT, but not in FORWARD. The ruleset fwbuilder generates puts  
> the
> dtp:80 rules in FORWARD too. It always puts rules in FORWARD, right?

no. As I explained in my previous email:

You probably have a lot of rules with "any" in  destination/source and  
have option "assume firewall is part of any"  turned on. This means  
rule with "any" in destination generates  iptables commands in INPUT  
and FORWARD chains. If you turn this option  off, then the rule will  
only go into the FORWARD chain. If address in  destination matches one  
of the addresses that belong to the firewall,  the rule will always go  
into INPUT chain. If address in destination is  not "any" and does not  
match any address of the firewall, the rule  goes only into FORWARD  
chain.



>
> When boxes behind the firewall are providing for instance dtp:80  
> service
> they also typically don't require FORWARD rules, but get handled by  
> DNAT in
> PREROUTING.


DNAT rules only translate, they do not filter. You always need to have  
filtering rule to go with translation rule, unless your filtering  
policy is ACCEPT by default. So in case of a server behind the  
firewall you do need a rule in the FORWARD chain.

> So in firewalls I'm running with some services on them, some
> services NATed behind them (DNAT in for some, SNAT out for others),  
> very
> little ends up in FORWARD at all - basically just rules for stuff  
> routed
> between LAN and DMZ. Rebuilding the rulesets with fwbuilder, I see  
> lots of
> FORWARD rules that essentially duplicate INPUT/OUTPUT rules, but  
> aren't
> doing anything useful in my setup.
>
> For example:
>
> echo "Rule 3 (eth1)"
> #
> #
> #
> $IPTABLES -A INPUT  -i eth1 -p tcp -m tcp  -d 123.456.789.11  --
> dport 80  -m state --state NEW  -j ACCEPT
> $IPTABLES -A OUTPUT  -o eth1 -p tcp -m tcp  -d 123.456.789.11  --
> dport 80  -m state --state NEW  -j ACCEPT
> $IPTABLES -A FORWARD  -o eth1 -p tcp -m tcp  -d 123.456.789.11  --
> dport 80  -m state --state NEW  -j ACCEPT
>
> This is where 123.456.789.11 is recognized by fwbuilder as the IP of  
> eth1.
> The first two rules are necessary if 123.456.789.11 is to have
> publicly-available web server running locally. The last rule does  
> nothing
> useful at all, right? What's admitted in on INPUT and out on OUTPUT  
> never
> crosses FORWARD. It works fine without it, and may even be a  
> security flaw
> if someone devises a way to take advantage of an ACCEPT rule in  
> FORWARD
> leaving a door open where there's no need for it - although the door  
> doesn't
> seem to much go to anywhere.
>

how does the original rule in the GUI look like ?

> I understand that. What would be ideal is a way to put rules _only_ in
> INPUT/OUTPUT, with no corresponding rule in FORWARD. INPUT/OUTPUT and
> FORWARD are entirely separate. In distributed firewall structures  
> where the
> firewalls are on each of the servers, you ideally want a bunch of
> INPUT/OUTPUT rules with no duplication of them as FORWARD rules. In
> structures where the firewall is separate hardware, and the services  
> all on
> boxes behind it, the opposite is ideal - lots of FORWARD rules, but  
> very
> minimal use of INPUT/OUTPUT, maybe just ssh, ping, ntp, to the  
> firewall box
> itself.
>
>> Your case is very specific, you want the program to put rules that  
>> have
>> unknown addresses into the INPUT chain. This is impossible without  
>> either
>> special hacks or different firewall model. I believe that support for
>> clustering configurations we are currently working on should solve  
>> this
>> problem nicely.
>
> I appreciate your attention to my other concern. But I think that's  
> entirely
> separate. My concern here is that because some of us sometimes like  
> to run a
> set of firewall rules across multiple public-facing servers, rather  
> than put
> all the servers behind a separate firewall, for this use we'll have  
> the most
> efficient rulesets if they don't include unnecessary FORWARD chain
> duplications of rules which we only need on the INPUT/OUTPUT chains.
>
> That said, fwbuilder generates pretty efficient rulesets, even where
> unnecessary FORWARD rules are included as a byproduct of getting the
> necessary INPUT/OUTPUT rules to be compiled. You've got a beautiful  
> project
> here.

I have not seen the proof that the rule you generated was "unncessary"  
from the configuration generation standpoint. It may be unnecessary  
because in your topology it will never see packets, but it was  
generated for the rule you created in the GUI. Please understand, the  
program can not read your mind and does not know about peculiarities  
of your network setup. It just takes rules you created in the GUI and  
translates them into iptables commands. If you believe the rule in  
FORWARD chain in this example is a bug and should not have been  
created, please file bug report. Please provide detailed information  
describing original rule in the GUI and we'll see if this is really a  
bug or not. If it is a bug, I promise I will fix it. However note that  
some configurations, such as your other case with unknown addresses,  
can not be translated in an ideal way and therefore are not a bug.



Vadim Kurland ✍
vadim@...







------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Whit Blauvelt]

On Sat, Jul 18, 2009 at 12:24:58PM -0700, Vadim Kurland ✎ wrote:

> You probably have a lot of rules with "any" in  destination/source and  
> have option "assume firewall is part of any"  turned on. This means rule
> with "any" in destination generates  iptables commands in INPUT and
> FORWARD chains. If you turn this option  off, then the rule will only go
> into the FORWARD chain. If address in  destination matches one of the
> addresses that belong to the firewall,  the rule will always go into
> INPUT chain. If address in destination is  not "any" and does not match
> any address of the firewall, the rule  goes only into FORWARD chain.

You misunderstand me. This isn't in an "any" circumstance. It's with a
defined IP. The service is on the same box as the firewall. There is no use
for a FORWARD rule. Yet fwbuilder has no option to generate just
INPUT/OUTPUT rules without a corresponding FORWARD rule.

>> When boxes behind the firewall are providing for instance dtp:80 service
>> they also typically don't require FORWARD rules, but get handled by DNAT
>> in PREROUTING.

> DNAT rules only translate, they do not filter. You always need to have  
> filtering rule to go with translation rule, unless your filtering policy
> is ACCEPT by default. So in case of a server behind the firewall you do
> need a rule in the FORWARD chain.

When DNAT'ing traffic to say, port 80, from one of the public interfaces's
IPs to a box on the DMZ, and the intent is just to pass all port 80 traffic
to that internal server, there is no FORWARD rule needed. The DNAT rule can
restrict the source IPs if desired. There are many real world cases where
that's all the firewalling you want on a server - that traffic to the
desired port at the desired address from the desired range goes to it, and
nothing else. DNAT does this by itself. No FORWARD rules are required. I'm
far from a Netfilter expert, but I've been doing this for many years, and it
works well.

>> echo "Rule 3 (eth1)"
>> #
>> #
>> #
>> $IPTABLES -A INPUT  -i eth1 -p tcp -m tcp  -d 123.456.789.11  --dport 80  -m state --state NEW  -j ACCEPT
>> $IPTABLES -A OUTPUT  -o eth1 -p tcp -m tcp  -d 123.456.789.11  --dport 80  -m state --state NEW  -j ACCEPT
>> $IPTABLES -A FORWARD  -o eth1 -p tcp -m tcp  -d 123.456.789.11  --dport 80  -m state --state NEW  -j ACCEPT
>>
>> This is where 123.456.789.11 is recognized by fwbuilder as the IP of
>> eth1. The first two rules are necessary if 123.456.789.11 is to have
>> publicly-available web server running locally. The last rule does nothing
>> useful at all, right? What's admitted in on INPUT and out on OUTPUT never
>> crosses FORWARD. It works fine without it, and may even be a security
>> flaw if someone devises a way to take advantage of an ACCEPT rule in
>> FORWARD leaving a door open where there's no need for it - although the
>> door doesn't seem to much go to anywhere.
>>
>
> how does the original rule in the GUI look like ?

Source: Any ; Destination: eth1:ip67 ; Service: http ; Interface: WAN ;
Direction: both ; Action: accept; Time: any

> I have not seen the proof that the rule you generated was "unncessary"  
> from the configuration generation standpoint. It may be unnecessary  
> because in your topology it will never see packets, but it was generated
> for the rule you created in the GUI. Please understand, the program can
> not read your mind and does not know about peculiarities of your network
> setup. It just takes rules you created in the GUI and translates them
> into iptables commands. If you believe the rule in FORWARD chain in this
> example is a bug and should not have been created, please file bug
> report. Please provide detailed information describing original rule in
> the GUI and we'll see if this is really a bug or not. If it is a bug, I
> promise I will fix it. However note that some configurations, such as
> your other case with unknown addresses, can not be translated in an ideal
> way and therefore are not a bug.

I wouldn't call it a bug, but a useful potential feature currently
unimplemented. If there is already a way to use the GUI go generate
INPUT/OUTPUT rules without generating unnecessary (in some common
topologies) FORWARD rules I'd like to learn it. If not, I'll just put up
with slightly inefficient rulesets. It's no big thing.

Whit

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Vadim Kurland ✎]

On Jul 18, 2009, at 1:14 PM, Whit Blauvelt wrote:

> On Sat, Jul 18, 2009 at 12:24:58PM -0700, Vadim Kurland ✎ wrote:
>
>> You probably have a lot of rules with "any" in  destination/source  
>> and
>> have option "assume firewall is part of any"  turned on. This means  
>> rule
>> with "any" in destination generates  iptables commands in INPUT and
>> FORWARD chains. If you turn this option  off, then the rule will  
>> only go
>> into the FORWARD chain. If address in  destination matches one of the
>> addresses that belong to the firewall,  the rule will always go into
>> INPUT chain. If address in destination is  not "any" and does not  
>> match
>> any address of the firewall, the rule  goes only into FORWARD chain.
>
> You misunderstand me. This isn't in an "any" circumstance. It's with a
> defined IP. The service is on the same box as the firewall. There is  
> no use
> for a FORWARD rule. Yet fwbuilder has no option to generate just
> INPUT/OUTPUT rules without a corresponding FORWARD rule.
>

I need to see the original rule as it looks like in the GUI. The  
program certainly can generate rules just in the INPUT chain to  
control access to the firewall itself. What object did you put in the  
"destination" of the policy rule ?

>>> When boxes behind the firewall are providing for instance dtp:80  
>>> service
>>> they also typically don't require FORWARD rules, but get handled  
>>> by DNAT
>>> in PREROUTING.
>
>> DNAT rules only translate, they do not filter. You always need to  
>> have
>> filtering rule to go with translation rule, unless your filtering  
>> policy
>> is ACCEPT by default. So in case of a server behind the firewall  
>> you do
>> need a rule in the FORWARD chain.
>
> When DNAT'ing traffic to say, port 80, from one of the public  
> interfaces's
> IPs to a box on the DMZ, and the intent is just to pass all port 80  
> traffic
> to that internal server, there is no FORWARD rule needed.

the FORWARD rule is not needed if default policy in FORWARD chain is  
ACCEPT. Try to make default policy DROP in the FORWARD chain and then  
see if you need explicit rule in FORWARD in this configuration.

> The DNAT rule can
> restrict the source IPs if desired. There are many real world cases  
> where
> that's all the firewalling you want on a server - that traffic to the
> desired port at the desired address from the desired range goes to  
> it, and
> nothing else. DNAT does this by itself. No FORWARD rules are  
> required. I'm
> far from a Netfilter expert, but I've been doing this for many  
> years, and it
> works well.

>
>>> echo "Rule 3 (eth1)"
>>> #
>>> #
>>> #
>>> $IPTABLES -A INPUT  -i eth1 -p tcp -m tcp  -d 123.456.789.11  --
>>> dport 80  -m state --state NEW  -j ACCEPT
>>> $IPTABLES -A OUTPUT  -o eth1 -p tcp -m tcp  -d 123.456.789.11  --
>>> dport 80  -m state --state NEW  -j ACCEPT
>>> $IPTABLES -A FORWARD  -o eth1 -p tcp -m tcp  -d 123.456.789.11  --
>>> dport 80  -m state --state NEW  -j ACCEPT
>>>
>>> This is where 123.456.789.11 is recognized by fwbuilder as the IP of
>>> eth1. The first two rules are necessary if 123.456.789.11 is to have
>>> publicly-available web server running locally. The last rule does  
>>> nothing
>>> useful at all, right? What's admitted in on INPUT and out on  
>>> OUTPUT never
>>> crosses FORWARD. It works fine without it, and may even be a  
>>> security
>>> flaw if someone devises a way to take advantage of an ACCEPT rule in
>>> FORWARD leaving a door open where there's no need for it -  
>>> although the
>>> door doesn't seem to much go to anywhere.
>>>
>>
>> how does the original rule in the GUI look like ?
>
> Source: Any ; Destination: eth1:ip67 ; Service: http ; Interface:  
> WAN ;
> Direction: both ; Action: accept; Time: any
>

I suppose  eth1:ip67  is an address of interface eth1. What object  
does this address object belong to ? Is this an address of an  
interface of the firewall object ? Or not ?


Vadim Kurland ✍
vadim@...







------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Whit Blauvelt]

On Sat, Jul 18, 2009 at 01:25:25PM -0700, Vadim Kurland ✎ wrote:

> I need to see the original rule as it looks like in the GUI. The program
> certainly can generate rules just in the INPUT chain to control access to
> the firewall itself. What object did you put in the "destination" of the
> policy rule ?

Sorry. Thought I was clear. The Destination is dragged and dropped as a WAN
IP address, and so has the "IP" graphic beside it. That's the sole
destination in this line.

>> When DNAT'ing traffic to say, port 80, from one of the public
>> interfaces's IPs to a box on the DMZ, and the intent is just to pass all
>> port 80 traffic to that internal server, there is no FORWARD rule needed.
>
> the FORWARD rule is not needed if default policy in FORWARD chain is  
> ACCEPT. Try to make default policy DROP in the FORWARD chain and then  
> see if you need explicit rule in FORWARD in this configuration.

You may well be right on this one. Sorry. My standard FORWARD setup is to
DROP anything to the LAN/DMZ net IP ranges, and ACCEPT everything else. I'll
test later whether that's required for DNAT to work; it may well be.

>> Source: Any ; Destination: eth1:ip67 ; Service: http ; Interface: WAN ;
>> Direction: both ; Action: accept; Time: any
>>
> I suppose  eth1:ip67  is an address of interface eth1. What object does
> this address object belong to ? Is this an address of an interface of the
> firewall object ? Or not ?

Yes, it is an address defined on the WAN (ext) interace of the firewall
object. So the compiler knows it's a local IP on the public interface. When
you say "The program certain can generate rules just in the INPUT chain,"
I'd like to know how to use the GUI to achieve that.

The docs suggest it always creates a FORWARD rule, and just when it
recognizes an IP on the interface also INPUT/OUTPUT rules. So there's a way
to get INPUT/OUTPUT without FORWARD? If there's not, it doesn't deserve to
be a priority. I was just trying to get some "blue sky" discussion going on
what the ultimate, ideal feature set might be.

Whit

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Vadim Kurland ✎]

On Jul 18, 2009, at 2:55 PM, Whit Blauvelt wrote:

> On Sat, Jul 18, 2009 at 01:25:25PM -0700, Vadim Kurland ✎ wrote:
>
>> I need to see the original rule as it looks like in the GUI. The  
>> program
>> certainly can generate rules just in the INPUT chain to control  
>> access to
>> the firewall itself. What object did you put in the "destination"  
>> of the
>> policy rule ?
>
> Sorry. Thought I was clear. The Destination is dragged and dropped  
> as a WAN
> IP address, and so has the "IP" graphic beside it. That's the sole
> destination in this line.
>
>>> When DNAT'ing traffic to say, port 80, from one of the public
>>> interfaces's IPs to a box on the DMZ, and the intent is just to  
>>> pass all
>>> port 80 traffic to that internal server, there is no FORWARD rule  
>>> needed.
>>
>> the FORWARD rule is not needed if default policy in FORWARD chain is
>> ACCEPT. Try to make default policy DROP in the FORWARD chain and then
>> see if you need explicit rule in FORWARD in this configuration.
>
> You may well be right on this one. Sorry. My standard FORWARD setup  
> is to
> DROP anything to the LAN/DMZ net IP ranges, and ACCEPT everything  
> else. I'll
> test later whether that's required for DNAT to work; it may well be.
>
>>> Source: Any ; Destination: eth1:ip67 ; Service: http ; Interface:  
>>> WAN ;
>>> Direction: both ; Action: accept; Time: any
>>>
>> I suppose  eth1:ip67  is an address of interface eth1. What object  
>> does
>> this address object belong to ? Is this an address of an interface  
>> of the
>> firewall object ? Or not ?
>
> Yes, it is an address defined on the WAN (ext) interace of the  
> firewall
> object. So the compiler knows it's a local IP on the public  
> interface. When
> you say "The program certain can generate rules just in the INPUT  
> chain,"
> I'd like to know how to use the GUI to achieve that.
>

it should create a rule in INPUT if address in destination belongs to  
the firewall. We are going in circles now, please send your data file  
to me and I'll look why rule gets created in the FORWARD chain.




> The docs suggest it always creates a FORWARD rule, and just when it
> recognizes an IP on the interface also INPUT/OUTPUT rules.

where in the documentation does it say this ? This is not correct, it  
seems I need to fix the documentation.


Vadim Kurland ✍
vadim@...







------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Vadim Kurland ✎]

got the file, thanks.

The original rule in the GUI has "Any" in source, an address of one of  
the interfaces of the firewall in Destination, that interface in  
"Interface" and direction "Both". Option "Assume firewall is part of  
any" is on.

The reason the program generated both INPUT and OUTPUT+FORWARD is  
because of the combination of "assume firewall is part of any" and  
direction Both. The program treats "Both" as "Inbound OR Outbound" and  
tries to generate rules to match either direction. So it splits  
original rule to make two rules, one with direction Inbound and  
another with direction  Outbound. The first rule generates iptables  
command in the INPUT chain and the second rule generates commands in  
the OUTPUT+FORWARD chains. The OUTPUT is because firewall is assumed  
to be part of "any", and command in the FORWARD chain is indeed useless.

So yes, you are right,  certain combination of parameters in the  
original rule can lead to the useless iptables command in the FORWARD  
chain.

Now, how to remedy this. The simplest method is to set direction to  
"Inbound". This yields just one iptables command in the INPUT chain.

I'll see if I can optimize rule generation to drop unnecessary rule in  
the FORWARD chain, too.

--vk



On Jul 18, 2009, at 2:55 PM, Whit Blauvelt wrote:

> On Sat, Jul 18, 2009 at 01:25:25PM -0700, Vadim Kurland ✎ wrote:
>
>> I need to see the original rule as it looks like in the GUI. The  
>> program
>> certainly can generate rules just in the INPUT chain to control  
>> access to
>> the firewall itself. What object did you put in the "destination"  
>> of the
>> policy rule ?
>
> Sorry. Thought I was clear. The Destination is dragged and dropped  
> as a WAN
> IP address, and so has the "IP" graphic beside it. That's the sole
> destination in this line.
>
>>> When DNAT'ing traffic to say, port 80, from one of the public
>>> interfaces's IPs to a box on the DMZ, and the intent is just to  
>>> pass all
>>> port 80 traffic to that internal server, there is no FORWARD rule  
>>> needed.
>>
>> the FORWARD rule is not needed if default policy in FORWARD chain is
>> ACCEPT. Try to make default policy DROP in the FORWARD chain and then
>> see if you need explicit rule in FORWARD in this configuration.
>
> You may well be right on this one. Sorry. My standard FORWARD setup  
> is to
> DROP anything to the LAN/DMZ net IP ranges, and ACCEPT everything  
> else. I'll
> test later whether that's required for DNAT to work; it may well be.
>
>>> Source: Any ; Destination: eth1:ip67 ; Service: http ; Interface:  
>>> WAN ;
>>> Direction: both ; Action: accept; Time: any
>>>
>> I suppose  eth1:ip67  is an address of interface eth1. What object  
>> does
>> this address object belong to ? Is this an address of an interface  
>> of the
>> firewall object ? Or not ?
>
> Yes, it is an address defined on the WAN (ext) interace of the  
> firewall
> object. So the compiler knows it's a local IP on the public  
> interface. When
> you say "The program certain can generate rules just in the INPUT  
> chain,"
> I'd like to know how to use the GUI to achieve that.
>
> The docs suggest it always creates a FORWARD rule, and just when it
> recognizes an IP on the interface also INPUT/OUTPUT rules. So  
> there's a way
> to get INPUT/OUTPUT without FORWARD? If there's not, it doesn't  
> deserve to
> be a priority. I was just trying to get some "blue sky" discussion  
> going on
> what the ultimate, ideal feature set might be.
>
> Whit
>

Vadim Kurland ✍
vadim@...







------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Whit Blauvelt]

Hi Vadim,

That makes much sense. I've unchecked the "Assume firewall is part of any."
What happens subsequently is that excess OUTPUT rules go away. Then being
specific on direction gets rid of the excess FORWARD rules.

Part of this is just getting familiar with the results of the basic GUI
options. For instance understanding that the default rules include

$IPTABLES -A OUTPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT

means that Direction "Outbound" is automaticly allowed, without explicit
action in the GUI, for anything allowed "Inbound" to start. That makes
perfect sense. It's efficient. But it's not the only model for the
situation. So a novice to fwbuilder (me) looking at the GUI might leave the
default Inbound/Outbound setting for Direction not realizing that Outbound
ESTABLISHED,RELATED is implicit in the fwbuilder context.

What this suggests in terms of expanding the documentation might be a HOWTO
or Cookbook section on "Generating Efficient Rulesets with Firewall
Builder." Tips might include advice not to use "Assume firewall is part of
any" for iptables, and not to use the default Direction of Inbound/Outbound
for stuff where Outbound permission is already implicit. Then again, it
would need to be mentioned that it's only implicit if "Accept ESTABLISHED
and RELATED packets before the first rule" is checked.

On a separate matter, I wonder if I'm the only one who would like to have
"Always permit ssh access from the workstation with this address" accept
multiple addresses? At least some systems have redundant administrators in
redundant locations.

Best,
Whit



On Sat, Jul 18, 2009 at 03:37:11PM -0700, Vadim Kurland ✎ wrote:

> got the file, thanks.
>
> The original rule in the GUI has "Any" in source, an address of one of  
> the interfaces of the firewall in Destination, that interface in  
> "Interface" and direction "Both". Option "Assume firewall is part of  
> any" is on.
>
> The reason the program generated both INPUT and OUTPUT+FORWARD is  
> because of the combination of "assume firewall is part of any" and  
> direction Both. The program treats "Both" as "Inbound OR Outbound" and  
> tries to generate rules to match either direction. So it splits original
> rule to make two rules, one with direction Inbound and another with
> direction  Outbound. The first rule generates iptables command in the
> INPUT chain and the second rule generates commands in the OUTPUT+FORWARD
> chains. The OUTPUT is because firewall is assumed to be part of "any",
> and command in the FORWARD chain is indeed useless.
>
> So yes, you are right,  certain combination of parameters in the  
> original rule can lead to the useless iptables command in the FORWARD  
> chain.
>
> Now, how to remedy this. The simplest method is to set direction to  
> "Inbound". This yields just one iptables command in the INPUT chain.
>
> I'll see if I can optimize rule generation to drop unnecessary rule in  
> the FORWARD chain, too.
>
> --vk

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Vadim Kurland ✎]

On Jul 19, 2009, at 6:25 PM, Whit Blauvelt wrote:

> Hi Vadim,
>
> That makes much sense. I've unchecked the "Assume firewall is part  
> of any."
> What happens subsequently is that excess OUTPUT rules go away. Then  
> being
> specific on direction gets rid of the excess FORWARD rules.
>
> Part of this is just getting familiar with the results of the basic  
> GUI
> options. For instance understanding that the default rules include
>
> $IPTABLES -A OUTPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> means that Direction "Outbound" is automaticly allowed, without  
> explicit
> action in the GUI, for anything allowed "Inbound" to start. That makes
> perfect sense. It's efficient. But it's not the only model for the
> situation. So a novice to fwbuilder (me) looking at the GUI might  
> leave the
> default Inbound/Outbound setting for Direction not realizing that  
> Outbound
> ESTABLISHED,RELATED is implicit in the fwbuilder context.
>

the rule that matches ESTABLISHED,RELATED you quoted above permits  
reply packets for sessions opened from inside going out. It does not  
permit just everything outbound.


> What this suggests in terms of expanding the documentation might be  
> a HOWTO
> or Cookbook section on "Generating Efficient Rulesets with Firewall
> Builder." Tips might include advice not to use "Assume firewall is  
> part of
> any" for iptables, and not to use the default Direction of Inbound/
> Outbound
> for stuff where Outbound permission is already implicit.

there is no implicit permission for outbound, your conclusion is  
incorrect.

Rules in fwbuilder apply to sessions rather than individual packets.  
When a rule permits some kind of connection inbound, the implicit rule  
matching ESTABLISHED,RELATED automatically permits reply packets going  
out. It works the same the other way around too because rules matching  
ESTABLISHED,RELATEd are added to all three chains. But only reply  
packets are permitted. Iptables module "state" keeps track of sessions  
and associates reply packets to the sessions.

yes, a User Guide chapter explaining the structure of generated script  
would be useful.

> Then again, it
> would need to be mentioned that it's only implicit if "Accept  
> ESTABLISHED
> and RELATED packets before the first rule" is checked.
>
> On a separate matter, I wonder if I'm the only one who would like to  
> have
> "Always permit ssh access from the workstation with this address"  
> accept
> multiple addresses? At least some systems have redundant  
> administrators in
> redundant locations.
>

file feature request.

--vk

> Best,
> Whit
>
>
>
> On Sat, Jul 18, 2009 at 03:37:11PM -0700, Vadim Kurland ✎ wrote:
>
>> got the file, thanks.
>>
>> The original rule in the GUI has "Any" in source, an address of one  
>> of
>> the interfaces of the firewall in Destination, that interface in
>> "Interface" and direction "Both". Option "Assume firewall is part of
>> any" is on.
>>
>> The reason the program generated both INPUT and OUTPUT+FORWARD is
>> because of the combination of "assume firewall is part of any" and
>> direction Both. The program treats "Both" as "Inbound OR Outbound"  
>> and
>> tries to generate rules to match either direction. So it splits  
>> original
>> rule to make two rules, one with direction Inbound and another with
>> direction  Outbound. The first rule generates iptables command in the
>> INPUT chain and the second rule generates commands in the OUTPUT
>> +FORWARD
>> chains. The OUTPUT is because firewall is assumed to be part of  
>> "any",
>> and command in the FORWARD chain is indeed useless.
>>
>> So yes, you are right,  certain combination of parameters in the
>> original rule can lead to the useless iptables command in the FORWARD
>> chain.
>>
>> Now, how to remedy this. The simplest method is to set direction to
>> "Inbound". This yields just one iptables command in the INPUT chain.
>>
>> I'll see if I can optimize rule generation to drop unnecessary rule  
>> in
>> the FORWARD chain, too.
>>
>> --vk
>

Vadim Kurland ✍
vadim@...







------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

[Vadim Kurland ✎]

Here is a followup.

I implemented additional optimization to remove unnecessary rules in  
the FORWARD chain when the following conditions are detected in the  
same rule:

  - direction is Outbound or Both
  - an interface of the firewall is placed in the "Interface" element  
of a rule
  - destination address matches one of the addresses of the firewall

there is no way a packet with destination matching firewall can be  
going through FORWARD chain. If it was generated by the firewall  
itself, it would appear in the OUTPUT chain. If such packet was sent  
by some other machine, it would have gone through the INPUT chain  
rather than FORWARD. Now the program detects this combination of  
conditions and drops rules like this from the FORWARD chain.

The optimization is implemented in v3.0.6 build 1182. Testing  
repositories have been updated and packages are available for download  
on the nightly builds site. Urls:

http://www.fwbuilder.org/docs/firewall_builder_packages.html
http://www.fwbuilder.org/nightly_builds/fwbuilder-3.0/


Please test

--vk



On Jul 18, 2009, at 3:37 PM, Vadim Kurland ✎ wrote:

>
>
> got the file, thanks.
>
> The original rule in the GUI has "Any" in source, an address of one of
> the interfaces of the firewall in Destination, that interface in
> "Interface" and direction "Both". Option "Assume firewall is part of
> any" is on.
>
> The reason the program generated both INPUT and OUTPUT+FORWARD is
> because of the combination of "assume firewall is part of any" and
> direction Both. The program treats "Both" as "Inbound OR Outbound" and
> tries to generate rules to match either direction. So it splits
> original rule to make two rules, one with direction Inbound and
> another with direction  Outbound. The first rule generates iptables
> command in the INPUT chain and the second rule generates commands in
> the OUTPUT+FORWARD chains. The OUTPUT is because firewall is assumed
> to be part of "any", and command in the FORWARD chain is indeed  
> useless.
>
> So yes, you are right,  certain combination of parameters in the
> original rule can lead to the useless iptables command in the FORWARD
> chain.
>
> Now, how to remedy this. The simplest method is to set direction to
> "Inbound". This yields just one iptables command in the INPUT chain.
>
> I'll see if I can optimize rule generation to drop unnecessary rule in
> the FORWARD chain, too.
>
> --vk
>
>
>
> On Jul 18, 2009, at 2:55 PM, Whit Blauvelt wrote:
>
>> On Sat, Jul 18, 2009 at 01:25:25PM -0700, Vadim Kurland ✎ wrote:
>>
>>> I need to see the original rule as it looks like in the GUI. The
>>> program
>>> certainly can generate rules just in the INPUT chain to control
>>> access to
>>> the firewall itself. What object did you put in the "destination"
>>> of the
>>> policy rule ?
>>
>> Sorry. Thought I was clear. The Destination is dragged and dropped
>> as a WAN
>> IP address, and so has the "IP" graphic beside it. That's the sole
>> destination in this line.
>>
>>>> When DNAT'ing traffic to say, port 80, from one of the public
>>>> interfaces's IPs to a box on the DMZ, and the intent is just to
>>>> pass all
>>>> port 80 traffic to that internal server, there is no FORWARD rule
>>>> needed.
>>>
>>> the FORWARD rule is not needed if default policy in FORWARD chain is
>>> ACCEPT. Try to make default policy DROP in the FORWARD chain and  
>>> then
>>> see if you need explicit rule in FORWARD in this configuration.
>>
>> You may well be right on this one. Sorry. My standard FORWARD setup
>> is to
>> DROP anything to the LAN/DMZ net IP ranges, and ACCEPT everything
>> else. I'll
>> test later whether that's required for DNAT to work; it may well be.
>>
>>>> Source: Any ; Destination: eth1:ip67 ; Service: http ; Interface:
>>>> WAN ;
>>>> Direction: both ; Action: accept; Time: any
>>>>
>>> I suppose  eth1:ip67  is an address of interface eth1. What object
>>> does
>>> this address object belong to ? Is this an address of an interface
>>> of the
>>> firewall object ? Or not ?
>>
>> Yes, it is an address defined on the WAN (ext) interace of the
>> firewall
>> object. So the compiler knows it's a local IP on the public
>> interface. When
>> you say "The program certain can generate rules just in the INPUT
>> chain,"
>> I'd like to know how to use the GUI to achieve that.
>>
>> The docs suggest it always creates a FORWARD rule, and just when it
>> recognizes an IP on the interface also INPUT/OUTPUT rules. So
>> there's a way
>> to get INPUT/OUTPUT without FORWARD? If there's not, it doesn't
>> deserve to
>> be a priority. I was just trying to get some "blue sky" discussion
>> going on
>> what the ultimate, ideal feature set might be.
>>
>> Whit
>>
>
> Vadim Kurland ✍
> vadim@...
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited  
> time,
> vendors submitting new applications to BlackBerry App World(TM) will  
> have
> the opportunity to enter the BlackBerry Developer Challenge. See  
> full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Fwbuilder-discussion mailing list
> Fwbuilder-discussion@...
> https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion

Vadim Kurland ✍
vadim@...







------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fwbuilder-discussion mailing list
Fwbuilder-discussion@...
https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion