* tool to search within cidr blocks @ 2008-10-22 19:28 ` Joey 2008-10-22 19:28 ` Matt Zagrabelny ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Joey @ 2008-10-22 19:28 UTC (permalink / raw) To: IPTables 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! ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: tool to search within cidr blocks 2008-10-22 19:28 ` tool to search within cidr blocks Joey @ 2008-10-22 19:28 ` Matt Zagrabelny 2008-10-22 22:40 ` Joey 2008-10-22 23:07 ` Grant Taylor 2008-10-26 21:13 ` Elvir Kuric 2 siblings, 1 reply; 13+ messages in thread From: Matt Zagrabelny @ 2008-10-22 19:28 UTC (permalink / raw) To: Joey; +Cc: IPTables [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: tool to search within cidr blocks 2008-10-22 19:28 ` Matt Zagrabelny @ 2008-10-22 22:40 ` Joey 0 siblings, 0 replies; 13+ messages in thread From: Joey @ 2008-10-22 22:40 UTC (permalink / raw) To: IPTables > -----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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: tool to search within cidr blocks 2008-10-22 19:28 ` tool to search within cidr blocks Joey 2008-10-22 19:28 ` Matt Zagrabelny @ 2008-10-22 23:07 ` Grant Taylor 2008-10-23 20:51 ` Joey 2008-10-26 21:13 ` Elvir Kuric 2 siblings, 1 reply; 13+ messages in thread From: Grant Taylor @ 2008-10-22 23:07 UTC (permalink / raw) To: Mail List - Netfilter 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. . . . ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: tool to search within cidr blocks 2008-10-22 23:07 ` Grant Taylor @ 2008-10-23 20:51 ` Joey 2008-10-23 20:58 ` Eljas Alakulppi 0 siblings, 1 reply; 13+ messages in thread From: Joey @ 2008-10-23 20:51 UTC (permalink / raw) To: IPTables > -----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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: tool to search within cidr blocks 2008-10-23 20:51 ` Joey @ 2008-10-23 20:58 ` Eljas Alakulppi 2008-10-24 0:38 ` Joey 0 siblings, 1 reply; 13+ messages in thread From: Eljas Alakulppi @ 2008-10-23 20:58 UTC (permalink / raw) To: Joey, IPTables 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: tool to search within cidr blocks 2008-10-23 20:58 ` Eljas Alakulppi @ 2008-10-24 0:38 ` Joey 2008-10-24 3:01 ` Grant Taylor 0 siblings, 1 reply; 13+ messages in thread From: Joey @ 2008-10-24 0:38 UTC (permalink / raw) To: IPTables 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: tool to search within cidr blocks 2008-10-24 0:38 ` Joey @ 2008-10-24 3:01 ` Grant Taylor 2008-10-24 4:14 ` Joey 0 siblings, 1 reply; 13+ messages in thread From: Grant Taylor @ 2008-10-24 3:01 UTC (permalink / raw) To: Mail List - Netfilter 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. . . . ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: tool to search within cidr blocks 2008-10-24 3:01 ` Grant Taylor @ 2008-10-24 4:14 ` Joey 2008-10-24 5:01 ` Grant Taylor 0 siblings, 1 reply; 13+ messages in thread From: Joey @ 2008-10-24 4:14 UTC (permalink / raw) To: IPTables 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: tool to search within cidr blocks 2008-10-24 4:14 ` Joey @ 2008-10-24 5:01 ` Grant Taylor 2008-10-24 22:24 ` Joey 0 siblings, 1 reply; 13+ messages in thread From: Grant Taylor @ 2008-10-24 5:01 UTC (permalink / raw) To: Mail List - Netfilter 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. . . . ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: tool to search within cidr blocks 2008-10-24 5:01 ` Grant Taylor @ 2008-10-24 22:24 ` Joey 2008-10-26 19:08 ` Grant Taylor 0 siblings, 1 reply; 13+ messages in thread From: Joey @ 2008-10-24 22:24 UTC (permalink / raw) To: IPTables 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: tool to search within cidr blocks 2008-10-24 22:24 ` Joey @ 2008-10-26 19:08 ` Grant Taylor 0 siblings, 0 replies; 13+ messages in thread From: Grant Taylor @ 2008-10-26 19:08 UTC (permalink / raw) To: Mail List - Netfilter 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. . . . ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: tool to search within cidr blocks 2008-10-22 19:28 ` tool to search within cidr blocks Joey 2008-10-22 19:28 ` Matt Zagrabelny 2008-10-22 23:07 ` Grant Taylor @ 2008-10-26 21:13 ` Elvir Kuric 2 siblings, 0 replies; 13+ messages in thread From: Elvir Kuric @ 2008-10-26 21:13 UTC (permalink / raw) To: Joey; +Cc: IPTables 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-10-26 21:13 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <Ack0fGqkMfM1syJxRQCXdIAkNZSCIQ==>
2008-10-22 19:28 ` tool to search within cidr blocks Joey
2008-10-22 19:28 ` Matt Zagrabelny
2008-10-22 22:40 ` Joey
2008-10-22 23:07 ` Grant Taylor
2008-10-23 20:51 ` Joey
2008-10-23 20:58 ` Eljas Alakulppi
2008-10-24 0:38 ` Joey
2008-10-24 3:01 ` Grant Taylor
2008-10-24 4:14 ` Joey
2008-10-24 5:01 ` Grant Taylor
2008-10-24 22:24 ` Joey
2008-10-26 19:08 ` Grant Taylor
2008-10-26 21:13 ` Elvir Kuric
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox