IPSet Log and drop.

IPSet Log and drop.

[Rob Carlson]

Sorry if this is a dupe, the first one didn't seem 
to go through...

I'm currently using ipset to block some large
blocks of addresses.  It seems to be working well,
but a couple of rogue emails have gotten through.
  This is not my concern right now, rather I would
like to see what _is_ being caught and try to
establish a pattern/ratio.

I've found that with vanilla IPTables, to log and
block one sets up two rules, first the LOG
statement, then immediately following, the DROP
statement.  However since I am using a nethash in
IPSet, I wonder if this approach would work, or
whether scanning the hash twice to invoke each
operation would be counter to the reason for using
the IPset nethash.

I have created a nethash with my "undesirable"
address blocks, and then ran:
iptables -A testhash -m set --set testhash src -j DROP

Would it be counter-productive to have:
iptables -A testhash -m set --set testhash src -j LOG
iptables -A testhash -m set --set testhash src -j
DROP?


Thanks,

Rob

Re: IPSet Log and drop.

[Jozsef Kadlecsik]

On Thu, 21 Apr 2005, Rob Carlson wrote:

> I'm currently using ipset to block some large
> blocks of addresses.  It seems to be working well,
> but a couple of rogue emails have gotten through.

E-mails? You are fully aware that E-mail headers are trivial to forge,
aren't you. Have you checked the sender machines in the Received lines?

> I've found that with vanilla IPTables, to log and
> block one sets up two rules, first the LOG
> statement, then immediately following, the DROP
> statement.  However since I am using a nethash in
> IPSet, I wonder if this approach would work, or
> whether scanning the hash twice to invoke each
> operation would be counter to the reason for using
> the IPset nethash.

ipset set types are really fast. It's hard to say, which is faster:
the rules

> iptables -A testhash -m set --set testhash src -j LOG
> iptables -A testhash -m set --set testhash src -j DROP

or

iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP
iptables -A testhash -m set --set testhash src -j logdrop

In the first case there is an additional set lookup, in the second case
there are four [six]) additional "wildcard" builtin matches (src, dst,
inface, outface, [proto, frag]) and one jump.

Probably the latter one is a teeny bit faster with a few cycles: hash key
computations are just more expensive operations than simple matches.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: IPSet Log and drop.

[Taylor, Grant]

> ipset set types are really fast. It's hard to say, which is faster:
> the rules
> 
> 
>>iptables -A testhash -m set --set testhash src -j LOG
>>iptables -A testhash -m set --set testhash src -j DROP
> 
> or
> 
> iptables -N logdrop
> iptables -A logdrop -j LOG
> iptables -A logdrop -j DROP
> iptables -A testhash -m set --set testhash src -j logdrop
> 
> In the first case there is an additional set lookup, in the second case
> there are four [six]) additional "wildcard" builtin matches (src, dst,
> inface, outface, [proto, frag]) and one jump.
> 
> Probably the latter one is a teeny bit faster with a few cycles: hash key
> computations are just more expensive operations than simple matches.

One additional advantage of using the latter method is that if you ever decide that you want to do limit matching on the LOG target (to prevent filling the logs for duplicate connect attempts) you could easily add additional entries to the logdrop chain and not have to introduce any additional hash processing as you would if you used the first method.  Think of jumping to a new chain as sort of like a subroutine in your favorite programming language.



Grant. . . .