efficient source address filtering and logging?

efficient source address filtering and logging?

[Robert P. J. Day]

  i'd like to find a short, efficient way to filter incoming packets with
bogus source addresses, but i don't see an elegant way of doing it.

  as we all know, there are a number of clearly bogus source addresses on
incoming packets:

  - broadcast
  - your own IP address
  - any of the private class A, B or C addresses
  - class D addresses

and on and on.  so it's natural to want to discard them and, just for fun,
log them as well.

  for elegance, i can create a user-defined chain called, say,
"reject_bad_source_addresses" to which i jump with every incoming packet.  
this user-defined chain will test for all of the bad source addresses, one
at a time, and DROP/REJECT each one.  however, if i want to log all of 
these rejections, i'd have to double the number of rules in this chain,
so that each test would first LOG that packet, then be followed by a 
second rule to DROP it.  kind of a pain.

  if i could rewrite the rules all backwards, i could have the 
user-defined chain full of ACCEPT rules, and only terminate the chain with 
a rule for LOG, followed by one for DROP.  but i don't see how that's 
possible.

  so, is there a solution i'm missing that's clean, elegant and short?

rday

Re: efficient source address filtering and logging?

[James Pattie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert P. J. Day wrote:
|   i'd like to find a short, efficient way to filter incoming packets with
| bogus source addresses, but i don't see an elegant way of doing it.
|
|   as we all know, there are a number of clearly bogus source addresses on
| incoming packets:
|
|   - broadcast
|   - your own IP address
|   - any of the private class A, B or C addresses
|   - class D addresses
|
| and on and on.  so it's natural to want to discard them and, just for fun,
| log them as well.
|
|   for elegance, i can create a user-defined chain called, say,
| "reject_bad_source_addresses" to which i jump with every incoming packet.
| this user-defined chain will test for all of the bad source addresses, one
| at a time, and DROP/REJECT each one.  however, if i want to log all of
| these rejections, i'd have to double the number of rules in this chain,
| so that each test would first LOG that packet, then be followed by a
| second rule to DROP it.  kind of a pain.
|
|   if i could rewrite the rules all backwards, i could have the
| user-defined chain full of ACCEPT rules, and only terminate the chain with
| a rule for LOG, followed by one for DROP.  but i don't see how that's
| possible.

you probably want to use RETURN instead of ACCEPT so that the packet can
continue to be processed instead of just accepting all packets that don't come
from a Bogus address. :)

|
|   so, is there a solution i'm missing that's clean, elegant and short?
|
| rday
|
|
|


- --
James A. Pattie
james@pcxperience.com

Linux  --  SysAdmin / Programmer
Xperience, Inc.
http://www.pcxperience.com/
http://www.xperienceinc.com/

GPG Key Available at http://www.pcxperience.com/gpgkeys/james.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/noqdtUXjwPIRLVERAgfEAKCeEBtW7EZ9GYsptVaGr80CBPFc1wCfSsd4
bTz9ZAeArjVNuiVFPk20FVs=
=7aXk
-----END PGP SIGNATURE-----


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

Re: efficient source address filtering and logging?

[Alistair Tonner]

On October 28, 2003 09:59 am, Robert P. J. Day wrote:
>   i'd like to find a short, efficient way to filter incoming packets with
> bogus source addresses, but i don't see an elegant way of doing it.
>
>   as we all know, there are a number of clearly bogus source addresses on
> incoming packets:
>
>   - broadcast
>   - your own IP address
>   - any of the private class A, B or C addresses
>   - class D addresses
>
> and on and on.  so it's natural to want to discard them and, just for fun,
> log them as well.
>
>   for elegance, i can create a user-defined chain called, say,
> "reject_bad_source_addresses" to which i jump with every incoming packet.
> this user-defined chain will test for all of the bad source addresses, one
> at a time, and DROP/REJECT each one.  however, if i want to log all of
> these rejections, i'd have to double the number of rules in this chain,
> so that each test would first LOG that packet, then be followed by a
> second rule to DROP it.  kind of a pain.

	Why don't you have the first user chain test for bad addresses, send them to 
a second chain, which the logs all traffic going through it, and then drops 
all traffic going through it?

>
>   if i could rewrite the rules all backwards, i could have the
> user-defined chain full of ACCEPT rules, and only terminate the chain with
> a rule for LOG, followed by one for DROP.  but i don't see how that's
> possible.
>
>   so, is there a solution i'm missing that's clean, elegant and short?
>
> rday

-- 

	Alistair Tonner
	nerdnet.ca
	Senior Systems Analyst - RSS
	
     Any sufficiently advanced technology will have the appearance of magic.
	Lets get magical!

Re: efficient source address filtering and logging?

[Robert P. J. Day]

On Tue, 28 Oct 2003, James Pattie wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert P. J. Day wrote:
> |   i'd like to find a short, efficient way to filter incoming packets with
> | bogus source addresses, but i don't see an elegant way of doing it.
> |
> |   as we all know, there are a number of clearly bogus source addresses on
> | incoming packets:
> |
> |   - broadcast
> |   - your own IP address
> |   - any of the private class A, B or C addresses
> |   - class D addresses
> |
> | and on and on.  so it's natural to want to discard them and, just for fun,
> | log them as well.
> |
> |   for elegance, i can create a user-defined chain called, say,
> | "reject_bad_source_addresses" to which i jump with every incoming packet.
> | this user-defined chain will test for all of the bad source addresses, one
> | at a time, and DROP/REJECT each one.  however, if i want to log all of
> | these rejections, i'd have to double the number of rules in this chain,
> | so that each test would first LOG that packet, then be followed by a
> | second rule to DROP it.  kind of a pain.
> |
> |   if i could rewrite the rules all backwards, i could have the
> | user-defined chain full of ACCEPT rules, and only terminate the chain with
> | a rule for LOG, followed by one for DROP.  but i don't see how that's
> | possible.
> 
> you probably want to use RETURN instead of ACCEPT so that the packet can
> continue to be processed instead of just accepting all packets that don't come
> from a Bogus address. :)

whoops, you're right, brain glitch there.  it's been a long day already.

rday

Re: efficient source address filtering and logging?

[Robert P. J. Day]

On Tue, 28 Oct 2003, Alistair Tonner wrote:

> On October 28, 2003 09:59 am, Robert P. J. Day wrote:
> >   i'd like to find a short, efficient way to filter incoming packets with
> > bogus source addresses, but i don't see an elegant way of doing it.
> >
> >   as we all know, there are a number of clearly bogus source addresses on
> > incoming packets:
> >
> >   - broadcast
> >   - your own IP address
> >   - any of the private class A, B or C addresses
> >   - class D addresses
> >
> > and on and on.  so it's natural to want to discard them and, just for fun,
> > log them as well.
> >
> >   for elegance, i can create a user-defined chain called, say,
> > "reject_bad_source_addresses" to which i jump with every incoming packet.
> > this user-defined chain will test for all of the bad source addresses, one
> > at a time, and DROP/REJECT each one.  however, if i want to log all of
> > these rejections, i'd have to double the number of rules in this chain,
> > so that each test would first LOG that packet, then be followed by a
> > second rule to DROP it.  kind of a pain.
> 
> 	Why don't you have the first user chain test for bad addresses, send them to 
> a second chain, which the logs all traffic going through it, and then drops 
> all traffic going through it?

oooh, yeah, that'll work.  thanks.

rday

Re: efficient source address filtering and logging?

[Chris Brenton]

On Tue, 2003-10-28 at 09:59, Robert P. J. Day wrote:
>   i'd like to find a short, efficient way to filter incoming packets with
> bogus source addresses, but i don't see an elegant way of doing it.

Here is what I do in my script to specify my rules:

while read SPOOFED ; do
iptables -A FORWARD -s $SPOOFED -j LOG --log-prefix " SPOOFING "
iptables -A FORWARD -s $SPOOFED -j DROP
done < spoofed_ips.txt

Now you just create a text file called 'spoofed_ips.txt' and add all the
IPs you want to filter, one per line. Use CIDR format to specify
subnets. So your file may look like this:

10.0.0.0/8
192.168.0.0/16
127.0.0.0/8

The only thing you can't specify this way is your internal address space
because the above rules does not tie things to a specific interface
(like external). The reason I do that is so I can catch internal
spoofing as well. Just do a separate spoofing rule for your internal
address space and life will be cool.

This also works well for blocking spammers, known hostile IPs,
countries, etc.

HTH,
C

Re[2]: efficient source address filtering and logging?

[Peteris Krumins]

Hello Chris,

Tuesday, October 28, 2003, 6:26:10 PM, you wrote:

CB> On Tue, 2003-10-28 at 09:59, Robert P. J. Day wrote:
>>   i'd like to find a short, efficient way to filter incoming packets with
>> bogus source addresses, but i don't see an elegant way of doing it.

CB> Here is what I do in my script to specify my rules:

CB> while read SPOOFED ; do
CB> iptables -A FORWARD -s $SPOOFED -j LOG --log-prefix " SPOOFING "
CB> iptables -A FORWARD -s $SPOOFED -j DROP
CB> done < spoofed_ips.txt

This is wrong, to log/drop a single ip 2 lookups on the src addr have to be
performed.
Instead a single chain should be created which all the spoofed packets
would jump. The single chain logs and drops.

i=iptables
$i -N LOG_DROP
$i -A LOG_DROP -j LOG --log-prefix " SPOOFING "
$i -A LOG_DROP -j DROP

while read SPOOFED;
  do
    $i -A FORWARD --src $SPOOFED -j LOG_DROP
done < spoofed_ips.txt


P.Krumins

Re: Re[2]: efficient source address filtering and logging?

[Chris Brenton]

On Sun, 2003-11-02 at 05:29, Peteris Krumins wrote:
>
> CB> Here is what I do in my script to specify my rules:
> 
> CB> while read SPOOFED ; do
> CB> iptables -A FORWARD -s $SPOOFED -j LOG --log-prefix " SPOOFING "
> CB> iptables -A FORWARD -s $SPOOFED -j DROP
> CB> done < spoofed_ips.txt
> 
> This is wrong,

I'm not sure what you mean by "wrong" as this works just fine.

>  to log/drop a single ip 2 lookups on the src addr have to be
> performed.

LOL! If you are worried about performing one extra file read when
loading your rules, I think its time to upgrade your hard drive. ;-)

> Instead a single chain should be created which all the spoofed packets
> would jump. The single chain logs and drops.
> 
> i=iptables
> $i -N LOG_DROP
> $i -A LOG_DROP -j LOG --log-prefix " SPOOFING "
> $i -A LOG_DROP -j DROP
> 
> while read SPOOFED;
>   do
>     $i -A FORWARD --src $SPOOFED -j LOG_DROP
> done < spoofed_ips.txt

Yup, this would work as well. I _personally_ like my way a little better
because this way requires the traversal of of an additional rule for
every IP packet that matches the ban list. This is going to have a
greater performance impact than the additional file read mention above.
Probably not a big deal if you are talking a home firewall, but it can
make a difference if you have big pipes and/or large ban lists.

HTH,
C

Re: Re[2]: efficient source address filtering and logging?

[Alistair Tonner]

On November 2, 2003 06:45 am, Chris Brenton wrote:
> On Sun, 2003-11-02 at 05:29, Peteris Krumins wrote:
> > CB> Here is what I do in my script to specify my rules:
> >
> > CB> while read SPOOFED ; do
> > CB> iptables -A FORWARD -s $SPOOFED -j LOG --log-prefix " SPOOFING "
> > CB> iptables -A FORWARD -s $SPOOFED -j DROP
> > CB> done < spoofed_ips.txt
> >
> > This is wrong,
>
> I'm not sure what you mean by "wrong" as this works just fine.
>
> >  to log/drop a single ip 2 lookups on the src addr have to be
> > performed.
>
> LOL! If you are worried about performing one extra file read when
> loading your rules, I think its time to upgrade your hard drive. ;-)
>
> > Instead a single chain should be created which all the spoofed packets
> > would jump. The single chain logs and drops.
> >
> > i=iptables
> > $i -N LOG_DROP
> > $i -A LOG_DROP -j LOG --log-prefix " SPOOFING "
> > $i -A LOG_DROP -j DROP
> >
> > while read SPOOFED;
> >   do
> >     $i -A FORWARD --src $SPOOFED -j LOG_DROP
> > done < spoofed_ips.txt
>
> Yup, this would work as well. I _personally_ like my way a little better
> because this way requires the traversal of of an additional rule for
> every IP packet that matches the ban list. This is going to have a
> greater performance impact than the additional file read mention above.
> Probably not a big deal if you are talking a home firewall, but it can
> make a difference if you have big pipes and/or large ban lists.
>
> HTH,
> C


	Actually the point is in the first form (linear in FORWARD) you have to check 
the IP TWICE ... (not FILE read during the load but checking the ?? skb ?? )
	in the second form, once the lookup is done the packet is passed out to the 
second chain and no other lookups of src_addr are required as the chain is 
purpose built.

	in small load/pipes this is negligible, however in very large load/pipes 
there might be an issue ... 

	As to what load this might engender on the system .. I've no clue... 

-- 

	Alistair Tonner
	nerdnet.ca
	Senior Systems Analyst - RSS
	
     Any sufficiently advanced technology will have the appearance of magic.
	Lets get magical!

Re: Re[2]: efficient source address filtering and logging?

[Alistair Tonner]

On November 2, 2003 06:45 am, Chris Brenton wrote:
> On Sun, 2003-11-02 at 05:29, Peteris Krumins wrote:
> > CB> Here is what I do in my script to specify my rules:
> >
> > CB> while read SPOOFED ; do
> > CB> iptables -A FORWARD -s $SPOOFED -j LOG --log-prefix " SPOOFING "
> > CB> iptables -A FORWARD -s $SPOOFED -j DROP
> > CB> done < spoofed_ips.txt
> >
> > This is wrong,
>
> I'm not sure what you mean by "wrong" as this works just fine.
>
> >  to log/drop a single ip 2 lookups on the src addr have to be
> > performed.
>
> LOL! If you are worried about performing one extra file read when
> loading your rules, I think its time to upgrade your hard drive. ;-)
>
> > Instead a single chain should be created which all the spoofed packets
> > would jump. The single chain logs and drops.
> >
> > i=iptables
> > $i -N LOG_DROP
> > $i -A LOG_DROP -j LOG --log-prefix " SPOOFING "
> > $i -A LOG_DROP -j DROP
> >
> > while read SPOOFED;
> >   do
> >     $i -A FORWARD --src $SPOOFED -j LOG_DROP
> > done < spoofed_ips.txt
>
> Yup, this would work as well. I _personally_ like my way a little better
> because this way requires the traversal of of an additional rule for
> every IP packet that matches the ban list. This is going to have a
> greater performance impact than the additional file read mention above.
> Probably not a big deal if you are talking a home firewall, but it can
> make a difference if you have big pipes and/or large ban lists.
>

	I disagree with this logic.  You have more work in matching ip's twice
	in the FORWARD chain than matching them once and dumping them 
	to a straight log and drop.

	Even further, method 1 adds {spoofed ip count}*2 rules to the base
	                      method 2 adds {spoofed ip count}+2 rules to the base.

	memory saving if I don't misunderstand.

	
	

> HTH,
> C

-- 

	Alistair Tonner
	nerdnet.ca
	Senior Systems Analyst - RSS
	
     Any sufficiently advanced technology will have the appearance of magic.
	Lets get magical!

Re: Re[2]: efficient source address filtering and logging?

[Tarek W.]

don't forget that throughput is affected by how many rules a packet is
inspected against... and in FORWARD all packets part of a stream r
seen... a flat structure is wrong by any standards, performance and
maintenance also... dunno if nf-hipac at netfilter.org has the relevant
lit, but on the original nf-hipac site, u have extensive data on how the
number of rules affects throughput.