newb: netfilter/iptables ?? extension?

Hi all, (not sure if this is the right group...)


I want to filter incoming connections based on source IP address. My
wrt54 router currently uses iptables, but I don't want to use its
traditional rules for this.

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?

thanks for the tips!

protocol

protocol wrote:
[snip]
> I want to filter incoming connections based on source IP address.

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.

> My wrt54 router currently uses iptables, but I don't want to use
> its traditional rules for this.

Why not? Can't understand/write the proper rules? Just ask for help
-- no one groks iptables when they first encounter it.

> 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?

Yes, use iptables -- that's what it is there for. These are some of
the easiest rules to write (even if they usually don't help much).

If you need help setting up your rules simply ask. If you think you
_can_ extend/improve on iptables, just do it. The fact that you even
ask/suggest such a thing reveals you are not up to the task.

We all started out clueless. The trick is getting clued in.

I could not see where/how to add custom rules to the firewall/filter in
my quick glance of the user guide. Once we find that, I'm confident
someone can show you some rules to use.
hth,
prg
email above disabled

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

> Why not? Can't understand/write the proper rules? Just ask for help
> -- no one groks iptables when they first encounter it.

Not the issue, just too many rules for my 200mhz MIPS/4MB free router.

>
> > 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)

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

"protocol" <(E-Mail Removed)> wrote in
news:(E-Mail Removed) oups.com:

> 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

About 3 IP#s per range?
How big is a "range"?
What's the downside of over-aggressive blocking (False positives)?


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

What make you think you can write code that's more effiecent than IPTABLES?

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

AFAIK, IPTABLES is open source s/w.

"protocol" <(E-Mail Removed)> writes:

> 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

What are you really trying to do? I don't know what your actual goal
is, but it's hard to imagine that filtering 100,000 IPs in 30,000
ranges is the right way to go about it.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer

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
help
> > -- no one groks iptables when they first encounter it.
>
> Not the issue, just too many rules for my 200mhz MIPS/4MB free
router.

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
developer
> 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:
http://www.netfilter.org/documentati...s-HOWTO-1.html
Some hacking:
http://www.netfilter.org/documentati...ing-HOWTO.html

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