Re: newb: netfilter/iptables ?? extension?

From: prg (
Date: 01/01/05

Date: 31 Dec 2004 18:54:23 -0800

protocol wrote:
> thanks for the reply!
> > Why? Explain further what you expect to gain by filtering on IP
> > source address -- there may be a better way. This approach is
> > usually pointless except in the easiest cases.
> I have about 100,000+ ips to block in about 30,000+ ranges

So you would have to describe and compare to _at_least_ 30,000 ranges
by _inspecting_every_ packet.

> > Why not? Can't understand/write the proper rules? Just ask for
> > -- no one groks iptables when they first encounter it.
> Not the issue, just too many rules for my 200mhz MIPS/4MB free

I think it would take a rack of Cisco high speed packet filtering
routers to even come close, he opines dramatically.

> > > Can I maybe do this with an iptables extension? Examine each new
> > > connection's source IP, and decide accept or drop? Or is there a
> > > better way?
> Since I probably have too many rules for iptables, I was thinking a
> custom lookup based on the source IP. Wouldn't have to block on the
> first visit, but maybe for any further visits that day (its a weird
> problem I'm trying to solve)

But you would still have to inspect every packet that arrives and
perform a lookup -- just like iptables.

There is no magic involved inspecting packets and making decisions
based on the source IP. The sheer # of comparisons you would have to
perform rules out this approach -- even connection tracking will not
save the day.

> Should have mentioned in the first post that I'm looking for
> info about iptables and extensions, if I need to write this myself.

You still haven't provided us with any idea of the nature of your
problem (just the nature of your proposed solution), so can't really
provide a clue to solve it -- except that _no_ packet filtering router
is going to work.

If these IPs are meant to be 86ed from web server access eg., you
should use an application proxy (like Squid) with acls -- that way you
inspect the traffic that needs inspecting, not every d***d packet that
arrives on the public interface. In fact, you could use iptables _on_
the web server.

The key to tackling any problem this size is to isolate and shrink the
problem down to manageable size. At the IP level that means filter
_where_ it will be most efficient considering your network topology.
You may need _several_ FW routers. If the problem involves an
application, use a proxy for _that_ traffic and let the rest alone.
Don't inspect/filter what you don't have to.

Curious -- just how do you know already how many IPs and ranges you
want to block? Log analysis? Why do you want to keep these IPs out?
Presumably you are offering a _public_ service of _some_ kind (what?)
so where's the value inviting the public _except_ these 100,000? What
will you do if/when it doubles? Triples?

If you do want some iptable coding guidance, check:
Some examples:
Some hacking:

Scrounge the site for other goodies and the mailing lists.
Happy New Year ^@*$%^ (party favors;)
email above disabled