Re: [Fwbuilder-discussion] single-entry add/delete of IPSET lists? external IPSET files?
Brought to you by:
mikehorn
From: Vadim K. <va...@vk...> - 2010-08-02 16:17:59
|
On Mon, Aug 2, 2010 at 8:45 AM, Ben DJ <ben...@gm...>wrote: > re: IPSET usage in FWB 4.1 > > reading, > > > If you install a firewall that is using Address Tables with ipset enabled > you can update the list of addresses > > that are stored in memory for that "set" by updating the file associated > with the Address Table object and > > then running the firewallscript.fw reload_ipset command. For the examples > shown above you would > > enter: > > guardian.fw reload_ipset bad_hosts /etc/fw/bad_hosts > > looking at the script's 'reload_ipset()', > > ... > grep -Ev '^#|^;|^\s*$' $data_file | while read L ; do > set $L > addr=$1 > echo $addr | grep -q "/" && { > $IPSET -A tmp_fwb_set:net $1 > } || { > $IPSET -A tmp_fwb_set:ip $1 > } > done > ... > > reads & reloads the entire set. for a long/large set, that's > unnecessary & wasteful ... > > 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 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. 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 ? > also, is the IPSET naming convention stable/invariant? so that we can > access/address the IPSET directly, e.g. via script? > 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. > > might be useful/helpful in an FWB AddressTable dialog to allow > specification in of either > (a) a text list that's converted @runtime by FWB compile (current > situation), or > (b) an already created, external IPSET file that can simply be referenced > > 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. 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. 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. 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. Judging by how relatively difficult it was to install ipset module and tools on most of my test machines, I guess ipset module is not that widely used right now and number of users who already have "ipset --save" files and use fwbuilder should be small. It is easy to convert these files to the simple format used by fwbuilder. --vk |