Linux Netfilter discussions
 help / color / mirror / Atom feed
From: "Joey" <Joey@Web56.net>
To: IPTables <netfilter@vger.kernel.org>
Subject: RE: tool to search within cidr blocks
Date: Fri, 24 Oct 2008 18:24:03 -0400	[thread overview]
Message-ID: <007401c93627$38b8f640$aa2ae2c0$@net> (raw)
In-Reply-To: <490156B0.2050905@riverviewtech.net>

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


  reply	other threads:[~2008-10-24 22:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
2008-10-26 19:08                   ` Grant Taylor
2008-10-26 21:13   ` Elvir Kuric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='007401c93627$38b8f640$aa2ae2c0$@net' \
    --to=joey@web56.net \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox