[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re: Problems reloading ippools
From:       Chet Burgess <cfb () usc ! edu>
Date:       2006-10-20 14:47:03
Message-ID: 20061020144703.GR20295 () usc ! edu
[Download RAW message or body]

On Fri, Oct 20, 2006 at 12:32:30AM -0700, Darren Reed wrote:
> Chet Burgess wrote:
> >This is sort of a repost of my question from 8/9 about ippools that
> >never got solved. I just now got around to looking into this again as
> >I have an immediate need to make it work.
> >  
> 
> I saw your email at the time and it started me thinking about the 
> problem...so it wasnt wasted.
> 
> >The problem I am having is that while I can create ippool.conf, define
> >a simple table, and then load it and use it, I cannot change a pool,
> >or remove it using "ipfboot reload"
> >  
> 
> understood.
> 
> >As an example if I define the following in ipf.conf
> >
> >block return-rst in log quick proto tcp from pool/100 to any port = 25
> >
> >and the following in ippool.conf
> >
> >table role = ipf type = tree number = 100
> >        { 128.125.10.28/32; };
> >
> >and then start ipf, there are no problems and things work.
> >
> >ex.
> >[root@msg-mx4 ipf]# ipfstat -io
> >empty list for ipfilter(out)
> >block return-rst in log quick proto tcp from pool/100 to any port =
> >smtp
> >
> >[root@msg-mx4 ipf]# ippool -l
> >table role = ipf type = tree number = 100
> >        { 128.125.10.28/32 };
> >
> >
> >However if I then try add an IP address to that pool such as
> >128.125.253.108 and then run "reload" the pool will not be
> >updated. The problems seems to come from the ippool -f <FILE> portions
> >of the reload command.
> >  
> 
> My advice is to do the addition in two parts:
> 1) update the file on disk
> 2) run the ippool command update the kerne without loading the file.

	So your saying to use ippool to add and delete the elements I
want after updating the file? I had thought about that, haven't tried
it yet though. The reason being I am attempting to build a somewhat
automated blocking method across several application servers using
ipf. The goal is that a member of our security, network, or system
administration team can run a simple tool that will take something
like source IP and application (ex. SMTP, Kerberos, POP, ALL,
etc). The tool will then make the changes in the proper ippool.conf
file, push the new file out to the application servers the new file
applies to, reload the rules as be done. Running the adds and deletes
individually would be a bit more difficult but still doable. The tool was going to have
a simple local DB for querying so building the file would just have
been a matter of doing a select on every entry for a given service.

	Another idea I have had but not yet tried is to simply make
the name of the pool serialized like the SOA in a DNS zone. Instead of
pushing just ippool.conf, the system could push ipf.conf and
ippool.conf and the pool name/number could just be updated each
time. The name/number could be set to something like UTC time. As part
of the push I could simply run the reload followed by a "ippool -F"
which I think should flush the no longer in use, and no longer in the
file pool, but I have not tested this out yet.

> 
> >...
> >[root@msg-mx4 ipf]# ippool -f ippool.conf
> >load_pool:SIOCLOOKUPADDTABLE: File exists
> >[root@msg-mx4 ipf]#
> >  
> 
> What would you prefer to happen here?
> 
> Or should there be a flag used here to ignore this error?
> e.g.
> ippool -f ippool.conf -u
> - if a pool exists, ignore the "already exists" error
> - if an address already exists in a pool, ignore it
> afterwards, retrieve pools from the kernel and
> - delete addresses from the kernel no longer in the file
> - delete pools no longer in the file
> 
> sound reasonable?

	That sounds about right. As Phil mentioned I would want to
cover the add logic as well. So it would look something like the
following.

- if a pool exists, ignore the "already exists" error
- if an address already exists in a pool, ignore it
afterwards, retrieve pools from the kernal and
 -delete addresses from the kernel no longer in the file
 -add addresses to the kernel that are *new* in the file 

	Not sure about deleting pools no longer in the file. The more
I think about that, the more I realize that might be a bad
thing. Since "ippool -f ippool.conf" gets called before reloading
ipf.conf, if you delete a pool from the kernel that is no longer in
the file, you might be removing a pool that is in use by the
kernel. Perhaps the order for reloading should be changed as follows?

1) ippool -f ippool.conf -u (or whatever the flag will be)
2) ipf -IFa -f ipf.conf
3) ipnat -CF -f ipnat.conf
4) ippool -F

-- 
Chet Burgess

Director, Systems Support
Information Technology Services
University of Southern California
cfb@usc.edu
213-740-5160
[prev in list] [next in list] [prev in thread] [next in thread]