tool to search within cidr blocks

tool to search within cidr blocks

[Joey]

Hello,

I have several ranges of IP’s being put into iptables.
The IP ranges look like this:
62.29.0.0/17
62.68.192.0/19
62.108.64.0/19
62.244.192.0/18
62.248.0.0/17
77.67.128.0/17
77.72.184.0/21
77.73.216.0/21
77.75.32.0/21
77.75.216.0/21
77.79.64.0/18
77.92.0.0/19
77.92.96.0/19
77.92.128.0/19
77.223.128.0/19
77.245.144.0/20
78.40.224.0/21
78.111.96.0/20
78.135.0.0/17


I am blocking a specific IP from the firewall as logged in messages
71.74.56.125.
In looking at each block of ip’s and using a CIDR calculator I can’t figure
out what range it’s really coming from.  The list I have is pretty huge.
Is there a tool or a way to ask iptables what rule it matches?  Based on all
my calculations I don’t have anything declared that would block that IP.

Thanks!

Re: tool to search within cidr blocks

[Matt Zagrabelny]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Wed, 2008-10-22 at 15:28 -0400, Joey wrote:

> Is there a tool or a way to ask iptables what rule it matches?

LOG before you DROP.

-- 
Matt Zagrabelny - mzagrabe@d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems & Services
PGP key 1024D/84E22DA2 2005-11-07
Fingerprint: 78F9 18B3 EF58 56F5 FC85  C5CA 53E7 887F 84E2 2DA2

He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

RE: tool to search within cidr blocks

[Joey]

> -----Original Message-----
> From: netfilter-owner@vger.kernel.org
[mailto:netfilter-owner@vger.kernel.org]
> On Behalf Of Matt Zagrabelny
> Sent: Wednesday, October 22, 2008 3:29 PM
> To: Joey
> Cc: IPTables
> Subject: Re: tool to search within cidr blocks
> 
> On Wed, 2008-10-22 at 15:28 -0400, Joey wrote:
> 
> > Is there a tool or a way to ask iptables what rule it matches?
> 
> LOG before you DROP.
> 

We are definatley logging, but the rejected address is not matching any of
the blocks defined to block.
It's very strange.

Joey

Re: tool to search within cidr blocks

[Grant Taylor]

On 10/22/2008 2:28 PM, Joey wrote:
> I have several ranges of IP’s being put into iptables.
> The IP ranges look like this:
> 62.29.0.0/17
> 62.68.192.0/19
> 62.108.64.0/19
> 62.244.192.0/18
> 62.248.0.0/17
> 77.67.128.0/17
> 77.72.184.0/21
> 77.73.216.0/21
> 77.75.32.0/21
> 77.75.216.0/21
> 77.79.64.0/18
> 77.92.0.0/19
> 77.92.96.0/19
> 77.92.128.0/19
> 77.223.128.0/19
> 77.245.144.0/20
> 78.40.224.0/21
> 78.111.96.0/20
> 78.135.0.0/17
> 
> I am blocking a specific IP from the firewall as logged in messages 
> 71.74.56.125. 
> In looking at each block of ip’s and using a CIDR calculator I can’t figure 
> out what range it’s really coming from.  The list I have is pretty huge. 
> Is there a tool or a way to ask iptables what rule it matches?  Based on all 
> my calculations I don’t have anything declared that would block that IP.
> 
> Thanks!

Um, 71.74.56.125 is not part of any of the Class A ranges that you are 
blocking (62., 77., 78.).  So... that sort of implies that something 
else is blocking it.

Do you care to provide the (sanitized) output of an 'iptables-save' for 
us to look at?



Grant. . . .

RE: tool to search within cidr blocks

[Joey]

> -----Original Message-----
> From: netfilter-owner@vger.kernel.org
[mailto:netfilter-owner@vger.kernel.org]
> On Behalf Of Grant Taylor
> Sent: Wednesday, October 22, 2008 7:08 PM
> To: Mail List - Netfilter
> Subject: Re: tool to search within cidr blocks
> 
> On 10/22/2008 2:28 PM, Joey wrote:
> > I have several ranges of IP's being put into iptables.
> > The IP ranges look like this:
> > 62.29.0.0/17
> > 62.68.192.0/19
> > 78.40.224.0/21
> > 78.111.96.0/20
> > 78.135.0.0/17
> >
> > I am blocking a specific IP from the firewall as logged in messages
> > 71.74.56.125.
> > In looking at each block of ip's and using a CIDR calculator I can't
figure
> > out what range it's really coming from.  The list I have is pretty huge.
> > Is there a tool or a way to ask iptables what rule it matches?  Based on
all
> > my calculations I don't have anything declared that would block that IP.
> >
> > Thanks!
> 
> Um, 71.74.56.125 is not part of any of the Class A ranges that you are
> blocking (62., 77., 78.).  So... that sort of implies that something
> else is blocking it.
> 
> Do you care to provide the (sanitized) output of an 'iptables-save' for
> us to look at?
> 
> 
OK, I have unloaded, flushed, reloaded, regenerated my ip lists and I can't
find why we are blocking the IP number.

Here are the block messages:
Oct 22 01:27:16 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.122
DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=46 ID=45805 PROTO=TCP
SPT=40388 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0 
Oct 22 01:27:30 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.122
DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=46 ID=45806 PROTO=TCP
SPT=40388 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0 
Oct 22 01:27:57 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.123
DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=47 ID=45807 PROTO=TCP
SPT=40388 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0 
Oct 22 01:34:09 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.125
DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=35071 PROTO=TCP
SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0 
Oct 22 01:34:12 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.125
DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=35072 PROTO=TCP
SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0 
Oct 22 01:34:19 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.125
DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=35073 PROTO=TCP
SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0 
Oct 22 01:34:32 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.124
DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=42 ID=35074 PROTO=TCP
SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0 
Oct 22 01:34:59 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.125
DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=35075 PROTO=TCP
SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0

Here is the list of IP numbers in an iptables-save format, we build this
from our ip numbers lists merging into this which then gets loaded at each
respective server.

http://web56.net/iptables-save.cfg


Any ideas?  This is crazy.

Thanks!

Joey

Re: tool to search within cidr blocks

[Eljas Alakulppi]

As a first note, all of your -A LOG_* rules are for ASIA only. For example:

:LOG_IISG - [0:0]
:CIDR-IISG - [0:0]
-A SMTP_TRAFFIC -j CIDR-IISG
-A LOG_ASIAN -j LOG --log-prefix "SPAM-BLOCK-CIDR-IISG"
-A LOG_ASIAN -j DROP
-A CIDR-IISG -s 137.39.110.153 -j LOG_IISG

They should change depending on the rule, in this case it should be  
LOG_IISG

Now, this does not explain why anything would ever generate  
SPAM-BLOCK-CIDR-TURKEY message as your LOG_TURKEY should be empty. Could  
you run
iptables -L LOG_ASIAN -v -n
iptables -L LOG_TURKEY -v -n
before fixing the logging issue and also after applying the fix?

Could you paste iptables-save output just in case?

-Eljas Alakulppi

On Thu, 23 Oct 2008 23:51:26 +0300, Joey <Joey@web56.net> wrote:

>> -----Original Message-----
>> From: netfilter-owner@vger.kernel.org
> [mailto:netfilter-owner@vger.kernel.org]
>> On Behalf Of Grant Taylor
>> Sent: Wednesday, October 22, 2008 7:08 PM
>> To: Mail List - Netfilter
>> Subject: Re: tool to search within cidr blocks
>>
>> On 10/22/2008 2:28 PM, Joey wrote:
>> > I have several ranges of IP's being put into iptables.
>> > The IP ranges look like this:
>> > 62.29.0.0/17
>> > 62.68.192.0/19
>> > 78.40.224.0/21
>> > 78.111.96.0/20
>> > 78.135.0.0/17
>> >
>> > I am blocking a specific IP from the firewall as logged in messages
>> > 71.74.56.125.
>> > In looking at each block of ip's and using a CIDR calculator I can't
> figure
>> > out what range it's really coming from.  The list I have is pretty  
>> huge.
>> > Is there a tool or a way to ask iptables what rule it matches?  Based  
>> on
> all
>> > my calculations I don't have anything declared that would block that  
>> IP.
>> >
>> > Thanks!
>>
>> Um, 71.74.56.125 is not part of any of the Class A ranges that you are
>> blocking (62., 77., 78.).  So... that sort of implies that something
>> else is blocking it.
>>
>> Do you care to provide the (sanitized) output of an 'iptables-save' for
>> us to look at?
>>
>>
> OK, I have unloaded, flushed, reloaded, regenerated my ip lists and I  
> can't
> find why we are blocking the IP number.
>
> Here are the block messages:
> Oct 22 01:27:16 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.122
> DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=46 ID=45805 PROTO=TCP
> SPT=40388 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> Oct 22 01:27:30 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.122
> DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=46 ID=45806 PROTO=TCP
> SPT=40388 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> Oct 22 01:27:57 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.123
> DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=47 ID=45807 PROTO=TCP
> SPT=40388 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> Oct 22 01:34:09 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.125
> DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=35071 PROTO=TCP
> SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> Oct 22 01:34:12 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.125
> DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=35072 PROTO=TCP
> SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> Oct 22 01:34:19 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.125
> DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=35073 PROTO=TCP
> SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> Oct 22 01:34:32 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.124
> DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=42 ID=35074 PROTO=TCP
> SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> Oct 22 01:34:59 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.125
> DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=35075 PROTO=TCP
> SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
>
> Here is the list of IP numbers in an iptables-save format, we build this
> from our ip numbers lists merging into this which then gets loaded at  
> each
> respective server.
>
> http://web56.net/iptables-save.cfg
>
>
> Any ideas?  This is crazy.
>
> Thanks!
>
> Joey
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

RE: tool to search within cidr blocks

[Joey]

Eljas, 
Great catch I totally missed that in my code that builds the save file.
That has been corrected.
http://web56.net/iptables-save.cfg

this is the result of iptables-save http://web56.net/iptables-save-output
Thanks!



> -----Original Message-----
> From: Eljas Alakulppi [mailto:Buzer@buzer.net]
> Sent: Thursday, October 23, 2008 4:59 PM
> To: Joey; IPTables
> Subject: Re: tool to search within cidr blocks
> 
> As a first note, all of your -A LOG_* rules are for ASIA only. For
example:
> 
> :LOG_IISG - [0:0]
> :CIDR-IISG - [0:0]
> -A SMTP_TRAFFIC -j CIDR-IISG
> -A LOG_ASIAN -j LOG --log-prefix "SPAM-BLOCK-CIDR-IISG"
> -A LOG_ASIAN -j DROP
> -A CIDR-IISG -s 137.39.110.153 -j LOG_IISG
> 
> They should change depending on the rule, in this case it should be
> LOG_IISG
> 
> Now, this does not explain why anything would ever generate
> SPAM-BLOCK-CIDR-TURKEY message as your LOG_TURKEY should be empty. Could
> you run
> iptables -L LOG_ASIAN -v -n
> iptables -L LOG_TURKEY -v -n
> before fixing the logging issue and also after applying the fix?
> 
> Could you paste iptables-save output just in case?
> 
> -Eljas Alakulppi
> 
> On Thu, 23 Oct 2008 23:51:26 +0300, Joey <Joey@web56.net> wrote:
> 
> >> -----Original Message-----
> >> From: netfilter-owner@vger.kernel.org
> > [mailto:netfilter-owner@vger.kernel.org]
> >> On Behalf Of Grant Taylor
> >> Sent: Wednesday, October 22, 2008 7:08 PM
> >> To: Mail List - Netfilter
> >> Subject: Re: tool to search within cidr blocks
> >>
> >> On 10/22/2008 2:28 PM, Joey wrote:
> >> > I have several ranges of IP's being put into iptables.
> >> > The IP ranges look like this:
> >> > 62.29.0.0/17
> >> > 62.68.192.0/19
> >> > 78.40.224.0/21
> >> > 78.111.96.0/20
> >> > 78.135.0.0/17
> >> >
> >> > I am blocking a specific IP from the firewall as logged in messages
> >> > 71.74.56.125.
> >> > In looking at each block of ip's and using a CIDR calculator I can't
> > figure
> >> > out what range it's really coming from.  The list I have is pretty
> >> huge.
> >> > Is there a tool or a way to ask iptables what rule it matches?  Based
> >> on
> > all
> >> > my calculations I don't have anything declared that would block that
> >> IP.
> >> >
> >> > Thanks!
> >>
> >> Um, 71.74.56.125 is not part of any of the Class A ranges that you are
> >> blocking (62., 77., 78.).  So... that sort of implies that something
> >> else is blocking it.
> >>
> >> Do you care to provide the (sanitized) output of an 'iptables-save' for
> >> us to look at?
> >>
> >>
> > OK, I have unloaded, flushed, reloaded, regenerated my ip lists and I
> > can't
> > find why we are blocking the IP number.
> >
> > Here are the block messages:
> > Oct 22 01:27:16 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> > MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.122
> > DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=46 ID=45805 PROTO=TCP
> > SPT=40388 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> > Oct 22 01:27:30 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> > MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.122
> > DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=46 ID=45806 PROTO=TCP
> > SPT=40388 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> > Oct 22 01:27:57 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> > MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.123
> > DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=47 ID=45807 PROTO=TCP
> > SPT=40388 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> > Oct 22 01:34:09 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> > MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.125
> > DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=35071 PROTO=TCP
> > SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> > Oct 22 01:34:12 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> > MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.125
> > DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=35072 PROTO=TCP
> > SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> > Oct 22 01:34:19 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> > MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.125
> > DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=35073 PROTO=TCP
> > SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> > Oct 22 01:34:32 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> > MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.124
> > DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=42 ID=35074 PROTO=TCP
> > SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> > Oct 22 01:34:59 pluto kernel: SPAM-BLOCK-CIDR-TURKEYIN=eth0 OUT=
> > MAC=00:0e:0c:67:16:a2:00:e0:1e:cd:e1:23:08:00 SRC=71.74.56.125
> > DST=218.144.124.7 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=35075 PROTO=TCP
> > SPT=46522 DPT=25 WINDOW=32850 RES=0x00 SYN URGP=0
> >
> > Here is the list of IP numbers in an iptables-save format, we build this
> > from our ip numbers lists merging into this which then gets loaded at
> > each
> > respective server.
> >
> > http://web56.net/iptables-save.cfg
> >
> >
> > Any ideas?  This is crazy.
> >
> > Thanks!
> >
> > Joey
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netfilter" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: tool to search within cidr blocks

[Grant Taylor]

On 10/23/2008 7:38 PM, Joey wrote:
> Great catch I totally missed that in my code that builds the save file.
> That has been corrected.
> http://web56.net/iptables-save.cfg
> 
> this is the result of iptables-save http://web56.net/iptables-save-output
> Thanks!

Forgive me if I think something /REALLY/ weird is going on.

I have looked through both your iptables-save.cfg and your 
iptables-save-output (which don't match each other) and I'm stumped. 
I've noticed that both your iptables-save.cfg and your 
iptables-save-output files have lines that appear to be in a different 
(alphabetical(?)) order than the packets passed through your kernel.

Please flush all your tables / chains to kernel defaults and then apply 
your config file and then provide an iptables-save output again.  Also, 
please provide the output of this command "iptables -t filter -L -n -v -x".

I /REALLY/ fell like there is something unknown to you that is outside 
of what you have presented to us.  I have no idea what it is.

Do you realize that you are jumping to your "fail2ban-postifx" chain to 
immediately RETURN to the chain that you jumped from?

Also, you are not using your "fail2ban-postfix-log" chain at all.




Grant. . . .

RE: tool to search within cidr blocks

[Joey]

Hey Grant,
Here is what I can tell you.
I run iptables -F which is supposed to clear everything.
I then load my config and what you see as a result of that load is what you
see in the iptables-save result.

I have a script that builds the iptables-save.cfg file from a file
containing IP numbers only.
When I build the script you can see that certain things happen based on the
fact that I am reading in values and building each "chain" in order, so you
won't see all the defining of the chains at the top like the iptables-save
version.

Now I could be missing something somewhere in my declarations, but the code
is working in general.  I see IP's being blocked, as you can see I do a lot
of logging to insure I know what's going on.

The chains for fail2ban are built and managed by that app so I don't mess
with them.

I completely rebooted the box prior to doing the below.  Normally I never
rebooted the box, but new kernel came out so I figured we will start from a
clean slate.

I did a reduced list test:
----------------------------------------------------
My quick file which is created by my app:
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:SMTP_TRAFFIC - [0:0]
-A INPUT -p tcp --dport 25 -m state --state NEW -j SMTP_TRAFFIC
:LOG_ASIAN - [0:0]
:CIDR-ASIAN - [0:0]
-A SMTP_TRAFFIC -j CIDR-ASIAN
-A LOG_ASIAN -j LOG --log-prefix "SPAM-BLOCK-CIDR-ASIAN"
-A LOG_ASIAN -j DROP
-A CIDR-ASIAN -s 58.14.0.0/15 -j LOG_ASIAN
-A CIDR-ASIAN -s 58.16.0.0/13 -j LOG_ASIAN
-A CIDR-ASIAN -s 58.24.0.0/15 -j LOG_ASIAN
-A CIDR-ASIAN -s 58.29.0.0/16 -j LOG_ASIAN
-A CIDR-ASIAN -s 58.30.0.0/15 -j LOG_ASIAN
-A CIDR-ASIAN -s 58.32.0.0/11 -j LOG_ASIAN
COMMIT
----------------------------------------------------
I executed iptables-restore < above-file
----------------------------------------------------
Executing iptables --list results in:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
SMTP_TRAFFIC  tcp  --  anywhere             anywhere            tcp dpt:smtp
state NEW 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain CIDR-ASIAN (1 references)
target     prot opt source               destination         
LOG_ASIAN  all  --  58.14.0.0/15         anywhere            
LOG_ASIAN  all  --  58.16.0.0/13         anywhere            
LOG_ASIAN  all  --  58.24.0.0/15         anywhere            
LOG_ASIAN  all  --  58.29.0.0/16         anywhere            
LOG_ASIAN  all  --  58.30.0.0/15         anywhere            
LOG_ASIAN  all  --  58.32.0.0/11         anywhere            

Chain LOG_ASIAN (6 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere            LOG level
warning prefix `SPAM-BLOCK-CIDR-ASIAN' 
DROP       all  --  anywhere             anywhere            

Chain SMTP_TRAFFIC (1 references)
target     prot opt source               destination         
CIDR-ASIAN  all  --  anywhere             anywhere      
----------------------------------------------------
Executing iptables-save resulted in:
# Generated by iptables-save v1.2.11 on Fri Oct 24 00:08:34 2008
*filter
:INPUT ACCEPT [1091:155172]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1287:150175]
:CIDR-ASIAN - [0:0]
:LOG_ASIAN - [0:0]
:SMTP_TRAFFIC - [0:0]
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -j SMTP_TRAFFIC 
-A CIDR-ASIAN -s 58.14.0.0/255.254.0.0 -j LOG_ASIAN 
-A CIDR-ASIAN -s 58.16.0.0/255.248.0.0 -j LOG_ASIAN 
-A CIDR-ASIAN -s 58.24.0.0/255.254.0.0 -j LOG_ASIAN 
-A CIDR-ASIAN -s 58.29.0.0/255.255.0.0 -j LOG_ASIAN 
-A CIDR-ASIAN -s 58.30.0.0/255.254.0.0 -j LOG_ASIAN 
-A CIDR-ASIAN -s 58.32.0.0/255.224.0.0 -j LOG_ASIAN 
-A LOG_ASIAN -j LOG --log-prefix "SPAM-BLOCK-CIDR-ASIAN" 
-A LOG_ASIAN -j DROP 
-A SMTP_TRAFFIC -j CIDR-ASIAN 
COMMIT
# Completed on Fri Oct 24 00:08:34 2008
----------------------------------------------------

Let me know what you see or think...

Thanks!!!!!

Joey





> -----Original Message-----
> From: netfilter-owner@vger.kernel.org
[mailto:netfilter-owner@vger.kernel.org]
> On Behalf Of Grant Taylor
> Sent: Thursday, October 23, 2008 11:01 PM
> To: Mail List - Netfilter
> Subject: Re: tool to search within cidr blocks
> 
> On 10/23/2008 7:38 PM, Joey wrote:
> > Great catch I totally missed that in my code that builds the save file.
> > That has been corrected.
> > http://web56.net/iptables-save.cfg
> >
> > this is the result of iptables-save
http://web56.net/iptables-save-output
> > Thanks!
> 
> Forgive me if I think something /REALLY/ weird is going on.
> 
> I have looked through both your iptables-save.cfg and your
> iptables-save-output (which don't match each other) and I'm stumped.
> I've noticed that both your iptables-save.cfg and your
> iptables-save-output files have lines that appear to be in a different
> (alphabetical(?)) order than the packets passed through your kernel.
> 
> Please flush all your tables / chains to kernel defaults and then apply
> your config file and then provide an iptables-save output again.  Also,
> please provide the output of this command "iptables -t filter -L -n -v
-x".
> 
> I /REALLY/ fell like there is something unknown to you that is outside
> of what you have presented to us.  I have no idea what it is.
> 
> Do you realize that you are jumping to your "fail2ban-postifx" chain to
> immediately RETURN to the chain that you jumped from?
> 
> Also, you are not using your "fail2ban-postfix-log" chain at all.
> 
> 
> 
> 
> Grant. . . .
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tool to search within cidr blocks

[Grant Taylor]

On 10/23/2008 11:14 PM, Joey wrote:
> Hey Grant,

*wave*

> Here is what I can tell you.
> I run iptables -F which is supposed to clear everything.

*nod*

> I then load my config and what you see as a result of that load is what you 
> see in the iptables-save result.

Ok...  Do the pages you linked to before reflect what is below, or is 
what you have below a small subset of the over all config?

> I have a script that builds the iptables-save.cfg file from a file 
> containing IP numbers only.

I gathered that is what you were doing.  I don't see any thing wrong 
with doing that either.

> When I build the script you can see that certain things happen based on the 
> fact that I am reading in values and building each "chain" in order, so you 
> won't see all the defining of the chains at the top like the iptables-save 
> version.

*nod*

> Now I could be missing something somewhere in my declarations, but the code 
> is working in general.  I see IP's being blocked, as you can see I do a lot 
> of logging to insure I know what's going on.

Yep.

> The chains for fail2ban are built and managed by that app so I don't mess 
> with them.

Ah.

> I completely rebooted the box prior to doing the below.  Normally I never 
> rebooted the box, but new kernel came out so I figured we will start from a 
> clean slate.

I tend to do the same.

> I did a reduced list test:
> ----------------------------------------------------
> My quick file which is created by my app:
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> :SMTP_TRAFFIC - [0:0]
> -A INPUT -p tcp --dport 25 -m state --state NEW -j SMTP_TRAFFIC
> :LOG_ASIAN - [0:0]
> :CIDR-ASIAN - [0:0]
> -A SMTP_TRAFFIC -j CIDR-ASIAN
> -A LOG_ASIAN -j LOG --log-prefix "SPAM-BLOCK-CIDR-ASIAN"
> -A LOG_ASIAN -j DROP
> -A CIDR-ASIAN -s 58.14.0.0/15 -j LOG_ASIAN
> -A CIDR-ASIAN -s 58.16.0.0/13 -j LOG_ASIAN
> -A CIDR-ASIAN -s 58.24.0.0/15 -j LOG_ASIAN
> -A CIDR-ASIAN -s 58.29.0.0/16 -j LOG_ASIAN
> -A CIDR-ASIAN -s 58.30.0.0/15 -j LOG_ASIAN
> -A CIDR-ASIAN -s 58.32.0.0/11 -j LOG_ASIAN
> COMMIT
> ----------------------------------------------------
> I executed iptables-restore < above-file

Is the above file your current config, or just a small portion of your 
config that you created for this test?  I don't see hardly any thing 
compared to your previous iptables-save file.

> ----------------------------------------------------
> Executing iptables --list results in:
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination         
> SMTP_TRAFFIC  tcp  --  anywhere             anywhere            tcp dpt:smtp
> state NEW 
> 
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination         
> 
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination         
> 
> Chain CIDR-ASIAN (1 references)
> target     prot opt source               destination         
> LOG_ASIAN  all  --  58.14.0.0/15         anywhere            
> LOG_ASIAN  all  --  58.16.0.0/13         anywhere            
> LOG_ASIAN  all  --  58.24.0.0/15         anywhere            
> LOG_ASIAN  all  --  58.29.0.0/16         anywhere            
> LOG_ASIAN  all  --  58.30.0.0/15         anywhere            
> LOG_ASIAN  all  --  58.32.0.0/11         anywhere            
> 
> Chain LOG_ASIAN (6 references)
> target     prot opt source               destination         
> LOG        all  --  anywhere             anywhere            LOG level
> warning prefix `SPAM-BLOCK-CIDR-ASIAN' 
> DROP       all  --  anywhere             anywhere            
> 
> Chain SMTP_TRAFFIC (1 references)
> target     prot opt source               destination         
> CIDR-ASIAN  all  --  anywhere             anywhere      
> ----------------------------------------------------

This is what I would expect to see based on your iptables-save file above.

> Executing iptables-save resulted in:
> # Generated by iptables-save v1.2.11 on Fri Oct 24 00:08:34 2008
> *filter
> :INPUT ACCEPT [1091:155172]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [1287:150175]
> :CIDR-ASIAN - [0:0]
> :LOG_ASIAN - [0:0]
> :SMTP_TRAFFIC - [0:0]
> -A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -j SMTP_TRAFFIC 
> -A CIDR-ASIAN -s 58.14.0.0/255.254.0.0 -j LOG_ASIAN 
> -A CIDR-ASIAN -s 58.16.0.0/255.248.0.0 -j LOG_ASIAN 
> -A CIDR-ASIAN -s 58.24.0.0/255.254.0.0 -j LOG_ASIAN 
> -A CIDR-ASIAN -s 58.29.0.0/255.255.0.0 -j LOG_ASIAN 
> -A CIDR-ASIAN -s 58.30.0.0/255.254.0.0 -j LOG_ASIAN 
> -A CIDR-ASIAN -s 58.32.0.0/255.224.0.0 -j LOG_ASIAN 
> -A LOG_ASIAN -j LOG --log-prefix "SPAM-BLOCK-CIDR-ASIAN" 
> -A LOG_ASIAN -j DROP 
> -A SMTP_TRAFFIC -j CIDR-ASIAN 
> COMMIT
> # Completed on Fri Oct 24 00:08:34 2008
> ----------------------------------------------------

Again, this is what I would expect to see based on your iptables-save 
file above.

> Let me know what you see or think...

Please try re-applying your iptables-save.cfg file from your previous 
post and let us know if your firewall is still blocking the 71.74.56.125 IP.

> Thanks!!!!!

You are welcome.



Grant. . . .

RE: tool to search within cidr blocks

[Joey]

I think with all the times we loaded and unloaded our iptables configs and
using the type executed by command line, then through iptables-save etc that
we trashed iptables hence it was blocking IP's we weren't expecting.
For right now I think the reboot did it....

Thanks for all your help!

Joey

> -----Original Message-----
> From: netfilter-owner@vger.kernel.org
[mailto:netfilter-owner@vger.kernel.org]
> On Behalf Of Grant Taylor
> Sent: Friday, October 24, 2008 1:02 AM
> To: Mail List - Netfilter
> Subject: Re: tool to search within cidr blocks
> 
> On 10/23/2008 11:14 PM, Joey wrote:
> > Hey Grant,
> 
> *wave*
> 
> > Here is what I can tell you.
> > I run iptables -F which is supposed to clear everything.
> 
> *nod*
> 
> > I then load my config and what you see as a result of that load is what
you
> > see in the iptables-save result.
> 
> Ok...  Do the pages you linked to before reflect what is below, or is
> what you have below a small subset of the over all config?
> 
> > I have a script that builds the iptables-save.cfg file from a file
> > containing IP numbers only.
> 
> I gathered that is what you were doing.  I don't see any thing wrong
> with doing that either.
> 
> > When I build the script you can see that certain things happen based on
the
> > fact that I am reading in values and building each "chain" in order, so
you
> > won't see all the defining of the chains at the top like the
iptables-save
> > version.
> 
> *nod*
> 
> > Now I could be missing something somewhere in my declarations, but the
code
> > is working in general.  I see IP's being blocked, as you can see I do a
lot
> > of logging to insure I know what's going on.
> 
> Yep.
> 
> > The chains for fail2ban are built and managed by that app so I don't
mess
> > with them.
> 
> Ah.
> 
> > I completely rebooted the box prior to doing the below.  Normally I
never
> > rebooted the box, but new kernel came out so I figured we will start
from a
> > clean slate.
> 
> I tend to do the same.
> 
> > I did a reduced list test:
> > ----------------------------------------------------
> > My quick file which is created by my app:
> > *filter
> > :INPUT ACCEPT [0:0]
> > :FORWARD ACCEPT [0:0]
> > :OUTPUT ACCEPT [0:0]
> > :SMTP_TRAFFIC - [0:0]
> > -A INPUT -p tcp --dport 25 -m state --state NEW -j SMTP_TRAFFIC
> > :LOG_ASIAN - [0:0]
> > :CIDR-ASIAN - [0:0]
> > -A SMTP_TRAFFIC -j CIDR-ASIAN
> > -A LOG_ASIAN -j LOG --log-prefix "SPAM-BLOCK-CIDR-ASIAN"
> > -A LOG_ASIAN -j DROP
> > -A CIDR-ASIAN -s 58.14.0.0/15 -j LOG_ASIAN
> > -A CIDR-ASIAN -s 58.16.0.0/13 -j LOG_ASIAN
> > -A CIDR-ASIAN -s 58.24.0.0/15 -j LOG_ASIAN
> > -A CIDR-ASIAN -s 58.29.0.0/16 -j LOG_ASIAN
> > -A CIDR-ASIAN -s 58.30.0.0/15 -j LOG_ASIAN
> > -A CIDR-ASIAN -s 58.32.0.0/11 -j LOG_ASIAN
> > COMMIT
> > ----------------------------------------------------
> > I executed iptables-restore < above-file
> 
> Is the above file your current config, or just a small portion of your
> config that you created for this test?  I don't see hardly any thing
> compared to your previous iptables-save file.
> 
> > ----------------------------------------------------
> > Executing iptables --list results in:
> > Chain INPUT (policy ACCEPT)
> > target     prot opt source               destination
> > SMTP_TRAFFIC  tcp  --  anywhere             anywhere            tcp
dpt:smtp
> > state NEW
> >
> > Chain FORWARD (policy ACCEPT)
> > target     prot opt source               destination
> >
> > Chain OUTPUT (policy ACCEPT)
> > target     prot opt source               destination
> >
> > Chain CIDR-ASIAN (1 references)
> > target     prot opt source               destination
> > LOG_ASIAN  all  --  58.14.0.0/15         anywhere
> > LOG_ASIAN  all  --  58.16.0.0/13         anywhere
> > LOG_ASIAN  all  --  58.24.0.0/15         anywhere
> > LOG_ASIAN  all  --  58.29.0.0/16         anywhere
> > LOG_ASIAN  all  --  58.30.0.0/15         anywhere
> > LOG_ASIAN  all  --  58.32.0.0/11         anywhere
> >
> > Chain LOG_ASIAN (6 references)
> > target     prot opt source               destination
> > LOG        all  --  anywhere             anywhere            LOG level
> > warning prefix `SPAM-BLOCK-CIDR-ASIAN'
> > DROP       all  --  anywhere             anywhere
> >
> > Chain SMTP_TRAFFIC (1 references)
> > target     prot opt source               destination
> > CIDR-ASIAN  all  --  anywhere             anywhere
> > ----------------------------------------------------
> 
> This is what I would expect to see based on your iptables-save file above.
> 
> > Executing iptables-save resulted in:
> > # Generated by iptables-save v1.2.11 on Fri Oct 24 00:08:34 2008
> > *filter
> > :INPUT ACCEPT [1091:155172]
> > :FORWARD ACCEPT [0:0]
> > :OUTPUT ACCEPT [1287:150175]
> > :CIDR-ASIAN - [0:0]
> > :LOG_ASIAN - [0:0]
> > :SMTP_TRAFFIC - [0:0]
> > -A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -j SMTP_TRAFFIC
> > -A CIDR-ASIAN -s 58.14.0.0/255.254.0.0 -j LOG_ASIAN
> > -A CIDR-ASIAN -s 58.16.0.0/255.248.0.0 -j LOG_ASIAN
> > -A CIDR-ASIAN -s 58.24.0.0/255.254.0.0 -j LOG_ASIAN
> > -A CIDR-ASIAN -s 58.29.0.0/255.255.0.0 -j LOG_ASIAN
> > -A CIDR-ASIAN -s 58.30.0.0/255.254.0.0 -j LOG_ASIAN
> > -A CIDR-ASIAN -s 58.32.0.0/255.224.0.0 -j LOG_ASIAN
> > -A LOG_ASIAN -j LOG --log-prefix "SPAM-BLOCK-CIDR-ASIAN"
> > -A LOG_ASIAN -j DROP
> > -A SMTP_TRAFFIC -j CIDR-ASIAN
> > COMMIT
> > # Completed on Fri Oct 24 00:08:34 2008
> > ----------------------------------------------------
> 
> Again, this is what I would expect to see based on your iptables-save
> file above.
> 
> > Let me know what you see or think...
> 
> Please try re-applying your iptables-save.cfg file from your previous
> post and let us know if your firewall is still blocking the 71.74.56.125
IP.
> 
> > Thanks!!!!!
> 
> You are welcome.
> 
> 
> 
> Grant. . . .
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tool to search within cidr blocks

[Grant Taylor]

On 10/24/2008 5:24 PM, Joey wrote:
> I think with all the times we loaded and unloaded our iptables 
> configs and using the type executed by command line, then through 
> iptables-save etc that we trashed iptables hence it was blocking IP's 
> we weren't expecting.  For right now I think the reboot did it....

Ok...  If you are comfortable with that, I guess that is ok.  I would 
suggest keeping an eye on things.  To me that type of failure is a 
symptom of an underlying bug.  However seeing as how we can't duplicate 
the problem we can't troubleshoot it, so it may have been the difference 
between a "-s" and a "-d" in a script that was accidentally created and 
subsequently corrected.  So it is hard to say.

Either way seeing that things are working as expected I'd say you are 
good to go.

> Thanks for all your help!

You are welcome.



Grant. . . .

Re: tool to search within cidr blocks

[Elvir Kuric]

Hi,

I took a look into mails related to this, and maybe you can use geoip
iptables patch ....

here is how it is implemented on debian :
http://www.debian-administration.org/articles/518

I try and tested this solution it works fine and very fast.

Kind regards,

Elvir Kuric

On Wed, Oct 22, 2008 at 8:28 PM, Joey <Joey@web56.net> wrote:
> Hello,
>
> I have several ranges of IP's being put into iptables.
> The IP ranges look like this:
> 62.29.0.0/17
> 62.68.192.0/19
> 62.108.64.0/19
> 62.244.192.0/18
> 62.248.0.0/17
> 77.67.128.0/17
> 77.72.184.0/21
> 77.73.216.0/21
> 77.75.32.0/21
> 77.75.216.0/21
> 77.79.64.0/18
> 77.92.0.0/19
> 77.92.96.0/19
> 77.92.128.0/19
> 77.223.128.0/19
> 77.245.144.0/20
> 78.40.224.0/21
> 78.111.96.0/20
> 78.135.0.0/17
>
>
> I am blocking a specific IP from the firewall as logged in messages
> 71.74.56.125.
> In looking at each block of ip's and using a CIDR calculator I can't figure
> out what range it's really coming from.  The list I have is pretty huge.
> Is there a tool or a way to ask iptables what rule it matches?  Based on all
> my calculations I don't have anything declared that would block that IP.
>
> Thanks!
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>