best approach for RDBMS based rules
Thu, 02 Aug 2001 18:06:59 -0400
I have another idea: why not write an RDBMS plugin (if possible) which
translates symbolic database entries into commands for use by libiptc
is the low-level netlink socket interface API used by iptables). Then
have to reinvent the wheel, and you can also support IPv6 later on.
Is that a good idea?
Mr. Shannon Aldinger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On Wed, 1 Aug 2001, Harald Welte wrote:
>> On Thu, Aug 02, 2001 at 10:33:17AM -0400, Mr. Shannon Aldinger wrote:
>>> What would be the best approach for setting up RDBMS based iptables rules?
>>> Using the queue target and a middle-man program. Writing and extension to
>>> iptables. Using triggers to call a program to add remove rules from the
>>> existing input, output targets.
>> ? that is some automatic feedback system you are talking about.
> I meant the best approach for integrating iptables and a database. But you
> did however answer my question.
>> Representation of iptables rules in a relational database model should
>> be discussed independently.
> It looks from your previous mail that the best approach to this, would be
> to use the database as storage for the IP tables. It might also be able to
> shortcut having to walk through all of the entries in a given IP table. I
> can see one big down-side to using an RDBMS for this task, which is the
> database server crashes and your rules go away.
> Take my open relay example, you could use the first quad of the incoming
> packets ip address and look for matches by regular expression on that. A
> packet comes in from 24.104.x.y, the database would be feed a query to
> look for all 24.z.x.y, if there are any results walk through them and
> apply them accordingly. Also a query would be needed to look for a
> netmask/ip that applies to all connections.
>> Well, I think you would have to design a _very_ flexible database structure
>> for dealing with all the flexibility of iptables (all matches/targets, and
>> even considering that new ones are added all the time).
> Maybe we can start off with the basics: input, output. Once that's worked
> out a bit move on to some of the more complex targets.
> With just the input target I can see complications. I don't think that an
> IP table can be represented in a way that will allow for one query and
> walking through the returned rules. Mainly because you can have rules that
> apply to all protocols, just a specific protocol, specific protocol/port,
> So for one packet coming into the input target, I see needing at least
> three queries. Which in itself adds more complication, which rules get
> applied first. So any design will need lots of peer review.
> Shannon Aldinger
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Made with pgp4pine 1.75
> -----END PGP SIGNATURE-----