Re: [Fwbuilder-discussion] single-entry add/delete of IPSET lists? external IPSET files?

[Ben DJ <bendj095124367913213465@gm...>]

On Mon, Aug 2, 2010 at 8:52 PM, Ben DJ
<bendj095124367913213465@...> wrote:
> On Mon, Aug 2, 2010 at 8:44 PM, Vadim Kurland <vadim@...> wrote:
>> looks like GEO_IP is set to be compile time ?
>
> nope.  both RunTime.
>
> did notice that svn rev says 3189, but "About box" says 3188.  is that
> normal/expected?
>
> just in case, i'm gonna clean house, reDL & rebuild ...

Still saye 3188 in the abt box, but the problem's gone.   Gremlins :-/

Seems that my FWB-gen'd firewall is correctly using -- well,
referencing atm.  i'll watch logs for a bit -- the IPSETs I 'restored'
@ boot.local, immediately prior to fwbuilder.fw exec.

and, of course, @ fw upload/install -- not having to (re)generate the
IPSET -- goes very quickly.

Ben

Re: [Fwbuilder-discussion] single-entry add/delete of IPSET lists? external IPSET files?

[Ben DJ <bendj095124367913213465@gm...>]

On Mon, Aug 2, 2010 at 8:44 PM, Vadim Kurland <vadim@...> wrote:
> looks like GEO_IP is set to be compile time ?

nope.  both RunTime.

did notice that svn rev says 3189, but "About box" says 3188.  is that
normal/expected?

just in case, i'm gonna clean house, reDL & rebuild ...

Re: [Fwbuilder-discussion] single-entry add/delete of IPSET lists? external IPSET files?

[Vadim Kurland <vadim@vk...>]

looks like GEO_IP is set to be compile time ?

--vk


On Mon, Aug 2, 2010 at 8:07 PM, Ben DJ <bendj095124367913213465@...>wrote:

> On Mon, Aug 2, 2010 at 7:19 PM, Vadim Kurland <vadim@...>
> wrote:
> > Hi Ben,
> > I have this in the latest build of 4.1. Here is what I've done:
> >  - if you leave file name blank in the run-time Address Table object,
> > generated script will use the ipset but will not try to load addresses
> from
> > the data file. Management of the set is left for the administrator to do
> > outside of the fwbuilder script.
>
> I created two RunTime AddressTables, with NO filename, named "GEO_IP"
> & "GEO_CIDR".
>
> i created a Rule (#7) in FWB (how do we cut-n-paste a single Rule from
> the GUI for 'sharing' in lists?),
>
>  Source: GEO_IP, GEO_CIDR
>  Destination: Any
>  Service: Any
>  Interface: All
>  Direction: Inbound
>  Action: DENY
>
> When I try to compile the rule, I get:
>
> fw_linode / Policy / rule 7
>  $IPTABLES -N In_RULE_7
>  $IPTABLES -A INPUT -m set  --set GEO_CIDR src  -j In_RULE_7
>  # fw_linode:Policy:7: error: File not found for Address Table: GEO_IP
> () Using dummy address in test mode
>  $IPTABLES -A INPUT  -s 192.0.2.0/24   -j In_RULE_7
>  $IPTABLES -A FORWARD  -i +  -m set  --set GEO_CIDR src  -j In_RULE_7
>  # fw_linode:Policy:7: error: File not found for Address Table: GEO_IP
> () Using dummy address in test mode
>  $IPTABLES -A FORWARD  -i +   -s 192.0.2.0/24   -j In_RULE_7
>  $IPTABLES -A In_RULE_7   -j LOG  --log-level error --log-prefix "RULE
> 7 -- DENY "
>  $IPTABLES -A In_RULE_7  -j DROP
>
>
> Of course, @compile fw, I get a 'fail' with Fatal Error.
>
> Ben
>

Re: [Fwbuilder-discussion] single-entry add/delete of IPSET lists? external IPSET files?

[Ben DJ <bendj095124367913213465@gm...>]

On Mon, Aug 2, 2010 at 7:19 PM, Vadim Kurland <vadim@...> wrote:
> Hi Ben,
> I have this in the latest build of 4.1. Here is what I've done:
>  - if you leave file name blank in the run-time Address Table object,
> generated script will use the ipset but will not try to load addresses from
> the data file. Management of the set is left for the administrator to do
> outside of the fwbuilder script.

I created two RunTime AddressTables, with NO filename, named "GEO_IP"
& "GEO_CIDR".

i created a Rule (#7) in FWB (how do we cut-n-paste a single Rule from
the GUI for 'sharing' in lists?),

  Source: GEO_IP, GEO_CIDR
  Destination: Any
  Service: Any
  Interface: All
  Direction: Inbound
  Action: DENY

When I try to compile the rule, I get:

fw_linode / Policy / rule 7
 $IPTABLES -N In_RULE_7
 $IPTABLES -A INPUT -m set  --set GEO_CIDR src  -j In_RULE_7
 # fw_linode:Policy:7: error: File not found for Address Table: GEO_IP
() Using dummy address in test mode
 $IPTABLES -A INPUT  -s 192.0.2.0/24   -j In_RULE_7
 $IPTABLES -A FORWARD  -i +  -m set  --set GEO_CIDR src  -j In_RULE_7
 # fw_linode:Policy:7: error: File not found for Address Table: GEO_IP
() Using dummy address in test mode
 $IPTABLES -A FORWARD  -i +   -s 192.0.2.0/24   -j In_RULE_7
 $IPTABLES -A In_RULE_7   -j LOG  --log-level error --log-prefix "RULE
7 -- DENY "
 $IPTABLES -A In_RULE_7  -j DROP


Of course, @compile fw, I get a 'fail' with Fatal Error.

Ben

Re: [Fwbuilder-discussion] single-entry add/delete of IPSET lists? external IPSET files?

[Ben DJ <bendj095124367913213465@gm...>]

Vadim,

On Mon, Aug 2, 2010 at 7:19 PM, Vadim Kurland <vadim@...> wrote:
> I have this in the latest build of 4.1. Here is what I've done:

Great, thx!  I'll start testing various scenarios here.  Just cleaning
up my local management scripts to do double-duty -- for both IPSET and
'just text' generation ...

Ben

Re: [Fwbuilder-discussion] single-entry add/delete of IPSET lists? external IPSET files?

[Vadim Kurland <vadim@vk...>]

Hi Ben,

I have this in the latest build of 4.1. Here is what I've done:

 - if you leave file name blank in the run-time Address Table object,
generated script will use the ipset but will not try to load addresses from
the data file. Management of the set is left for the administrator to do
outside of the fwbuilder script.

 - I added functions to add and remove address from given set to the
generated script, as well as to test an address. These functions have the
following usage :


# /etc/fw/script.fw reload_address_table
Usage: reload_address_table address_table_object_name file_name

# /etc/fw/script.fw add_to_address_table
Usage: add_to_address_table address_table_object_name file_name address

# /etc/fw/script.fw remove_from_address_table
Usage: remove_from_address_table address_table_object_name file_name address

# /etc/fw/script.fw test_address_table
Usage: test_address_table address_table_object_name address


 - functions that add and delete addresses do this with both sets in memory
and data files to keep them synchronized.

 - note that I have changed the name of the function that reloads ipsets to
reload_address_table. This is because the name it takes is actually the name
of the address table object rather than a name of ipset. The script manages
two ip sets per address table object and all addition or removal is done
from the right set depending on whether address being added is a single
address or a subnet. It was confusing to call the function "reload_ipset"
while the name it took as an argument was not exactly the name of the ipset.

 - we plan to add similar functions to the generated script for PF for
consistency at some point in the future.

To test you need build 3189 or later.

--vk


On Mon, Aug 2, 2010 at 10:02 AM, Ben DJ
<bendj095124367913213465@...>wrote:

> hi,
>
> On Mon, Aug 2, 2010 at 9:17 AM, Vadim Kurland <vadim@...>
> wrote:
> >> what's the FWB mechanism, if any atm, for adding, or deleting, a
> >> SINGLE address (simply with IPSET -A ...)?
> >
> > there is none right now. You could do this yourself using ipset -A but do
>
> sure.
>
> > not forget to add this address to the file so that when the firewall
> > reboots, the script can add it to the set as well.
>
> under FWB script control will, imo, be most user-friendly ...
>
> > I can add another action to the script to add or delete single address,
> this
> > is easy. It would basically wrap "ipset -A" and adding address to the
> file.
> > Does this sound useful ?
>
> Yes.  The ability to ADD &/or DELETE a single IP from cmd line would
> be useful.  Might as well add a TEST cmd as well.
>
>
> -A, --add setname IP
>    Add an IP to a set.
> -D, --del setname IP
>    Delete an IP from a set.
> -T, --test setname IP
>    Test wether an IP is in a set or not. Exit status number is zero if
> the tested IP is in the set and nonzero if it is missing from the set.
>
> Eventually might be nice to have a GUI-driven "add a single IP" cmd
> ... without the need for a complete firewall reload.  Of course, all
> can be done via script from cmd line.  But for that FWB iPhone app ...
> ;-)
>
> > the file format is stable. Address Table object also depends on this
> format
> > when firewall does not have ipset module so I do not see us changing the
> > format in the future.
>
> thx
>
> > the (b) makes Address Table object aware of specifics of particular
> > implementation, that is, format of the file created with "ipset --save"
> > command. This goes against general architecture of fwbuilder because the
> > object should be generic. All platform-specific details should be in the
> > generated script.
>
> fair enough.
>
> > On the technical side, reload_ipset() function uses a trick where it
> loads
> > new addresses into a temporary set and then swaps sets. This is done this
> > way, as opposed to just flushing the set and then reloading it, to avoid
> > running for a period of time with no addresses in the set. Standard file
> > created with "ipset --save" does not do this, it simply creates set and
> > loads addresses. If script generated by fwbuilder were to use a file like
> > that, it would have to flush the set and then call "ipset --restore". If
> the
> > set is big and takes some time to load, the firewall would run with
> > incomplete set for all that time.
>
> Interesting.  In effect, "hiding" the reload time of a long IPSET ...
>
> > Another reason is that ipset does not allow you to store individual ip
> > addresses and CIDR blocks in the same set.
> > You can either do addresses if
> > the set type is iphash or subnets with type nethash, but not both. You
> can't
> > even store addresses as /32 subnets in the nethash because it only allows
> > netmasks between /1 and /31.
>
> not completely correct, that depends on the set type ... e.g.
> "iptreemap" allows "As input entry, you can add IP addresses, CIDR
> blocks or network ranges to the set"
>
> but for *hash, you're right.
>
> > Function reload_ipset() in the script generated
> > by fwbuilder works around this limitation by creating two sets and
> managing
> > them together. It decides which set an entry from the data file should
> > placed by checking if it has "/".
>
> > If it supported standard files created
> > with "ipset --save", this would not be possible and you would have to
> manage
> > separate sets for addresses and subnets yourself.
>
> personally, I'd suggest adherence to the standard, and manage the
> separate sets.  especially if/when the FWB dialog allows to specify
> the IPSET type to be used for a given data set -- whether internal or
> external.
>
> > Judging by how relatively difficult it was to install ipset module and
> tools
> > on most of my test machines,
>
> ipset is available as part of xtables-addons
> (http://xtables-addons.sourceforge.net/) package,  e.g., on opensuse,
> it was simply
>
>  zypper in xtables-addons
>
> and, iiuc, widely available for most distros,
>
>  http://xtables-addons.sourceforge.net/distro-support.php
>
> even in the (older) cases where not currently packages, the build --
> either of xtables or ipset directly -- should be relatively trivial.
>
> > I guess ipset module is not that widely used right now and number of
> users who already have "ipset --save" files
>
> depends where you look.  every one of our clients' linux firewalls --
> desktop & server -- use it.  for us, that's ~ 1600 installs
>
> > and use fwbuilder should be small.
>
> of course, as there hasn't been IPSET support until now.  for us,
> e.g., every one of our (eventual) migrations to FWB-controlled
> firewalls will use it. atm, they're all diy-iptables, or shorewall.
>
> > It is easy to convert these files to the simple format used by fwbuilder.
>
> I need to think about how to maintain these files under script
> control, then.  Iiuc, it should be as simple as removing text/list ->
> IPSET conversion logic
>
> ben
>

[Fwbuilder-discussion] Branch Logging Label inheritance?

[Ben DJ <bendj095124367913213465@gm...>]

What are the inheritance 'rules' for Branch logging labels?

If I want to log, say,

   [BRANCHNAME] RULE %N -- %A

does that _all_ have to go in each Logging field for each Rule in the
Branch policy?  Or, can "[BRANCHNAME]" go in the Main Policy Branch
rule's logging prefix field, and the default "RULE %N -- %A" would
automatically be inherited and appended?

also, there seems to be no macro for Branch (or Policy) name,

there's,

Log prefix
Log records will be prefixed with a string you enter in this option.
Firewall Builder supports the following macros in the log prefix that
are expanded at the compile time:
%N rule number in the GUI.
%A rule action
%I interface the rule is associated with
%C (iptables only) iptables chain that this rule generated code for.

are there others?

Ben