All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ted Kaczmarek <tedkaz@optonline.net>
To: Antony Stone <Antony@Soft-Solutions.co.uk>
Cc: netfilter@lists.netfilter.org
Subject: Re: Testing iptables setup
Date: Mon, 08 Mar 2004 21:51:26 -0500	[thread overview]
Message-ID: <1078800686.20494.23.camel@tarkus> (raw)
In-Reply-To: <200403081518.17402.Antony@Soft-Solutions.co.uk>

hping and nmap do wonders for me :-)

Ted
On Mon, 2004-03-08 at 15:18 +0000, Antony Stone wrote:

> On Monday 08 March 2004 3:00 pm, Richard L. Dery wrote:
> 
> > I have the following setup in my /etc/ppp/ip-up.d directory:
> >
> > ## Create chain which blocks new connections, except if coming from inside.
> > # iptables -N block
> > # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
> > # iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
> > # iptables -A block -j DROP
> >
> > ## Jump to that chain from INPUT and FORWARD chains.
> > # iptables -A INPUT -j block
> > # iptables -A FORWARD -j block
> >
> > When I run iptables -L after connecting these rules are displayed.
> >
> > Is there a way to test to show that these rules work?
> 
> I can think of two meanings of the word "work" here:
> 
> 1. Do they allow the traffic you want?
> 2. Do they block the traffic you don't want?
> 
> I suggest you test them by setting the packet counters to zero ("iptables 
> -Z"), then sending some traffic through your firewall which is expected to 
> work (eg: browse an Internet website from a LAN client), and make sure you 
> see a small increase in the packet counters for the NEW rule in the 
> user-defined chain (using "iptables -L -nvx"), and a larger increase in the 
> counters for the ESTABLISHED rule (since this is where the reply packets, and 
> further request packets, will go after the initial connection is made).
> 
> Then try something which should be blocked by the above rules (eg: try to 
> connect to your public IP address from somewhere else on the Internet - it 
> doesn't matter what protocol you try to use - HTTP, telnet, SSH, POP3 etc 
> should all be blocked), and make sure (a) you can't connect, and (b) you see 
> some packets build up in the counters for the DROP rule.
> 
> If in doubt, put a LOG rule just before the DROP rule, and you'll sson see 
> packets from all over the Internet trying to connect to your address, and 
> failing :)
> 
> Regards,
> 
> Antony.
> 
> -- 
> The words "e pluribus unum" on the Great Seal of the United States are from a 
> poem by Virgil entitled "Moretum", which is about cheese and garlic salad 
> dressing.
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 



      reply	other threads:[~2004-03-09  2:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-08 15:00 Testing iptables setup Richard L. Dery
2004-03-08 15:18 ` Antony Stone
2004-03-09  2:51   ` Ted Kaczmarek [this message]

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=1078800686.20494.23.camel@tarkus \
    --to=tedkaz@optonline.net \
    --cc=Antony@Soft-Solutions.co.uk \
    --cc=netfilter@lists.netfilter.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.