From: Rob Carlson <rcarlson@kitchenandassociates.com>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: Netfilter User Mailing List <netfilter@lists.netfilter.org>
Subject: Re: IPset ports question.
Date: Tue, 19 Jul 2005 15:13:40 -0400 [thread overview]
Message-ID: <42DD50E4.9090800@kitchenandassociates.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0507191037060.22686@blackhole.kfki.hu>
Jozsef,
Somehow I'm still blocking all traffic from the
iphash entries afrer binding the hash to the port
(port 80, for instance). For background purposes,
this is how I am blocking traffic with the iphash:
iptables -A testset -m set --set testset src -j
LTREJECT
iptables -I FORWARD 2 -i eth1 -j testset
iptables -I INPUT 2 -i eth1 -j testset
This works fine for blocking all traffic. However
since I now want specifically to only drop port 22
and port 25 entries (that is most of the nuisance
traffic) and allow port 80 for example, I did the
following:
ipset -N ports portmap --from 1 --to 1024
ipset -A ports 22
ipset -A ports 25
ipset -B testset :default: -b ports
Now, if I run "ipset -n -L testset", I get the
following
Name: testset
Type: iphash
References: 1
Default binding: ports
Header: hashsize: 1024 probes: 8 resize: 50
Members:
<List of Entries>
Bindings:
In order to test what I have, I added to the hash
an address of an external machine (that I can
always reach) to see if I could access the web
page, but _not_ the ssh port. However, when the
address is in the hash, _all_ ports still seem to
be blocked-- i.e. no web access OR ssh. Removing
the address from the hash fixes this.
In order to see if something was cached and
blocking the address I tried removing the iptables
entry for testset and re-added it. The result is
the same. Is there something in the order of what
I am doing that causes the LTREJECT to affect
traffic to all ports, and not just the ports that
I bound to the iphash?
Thanks,
Rob
.
Jozsef Kadlecsik wrote:
> Hi Rob,
>
> On Mon, 18 Jul 2005, Rob Carlson wrote:
>
>
>>Is there a way to bind an IPSet hash to a port,
>>and if so, what is the syntax?
>
>
> The syntax is the same in all cases:
>
> ipset -B <setname> <elem> -b <name of set to bind elem from setname>
>
> Best regards,
> Jozsef
> -
> E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
> PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
> Address : KFKI Research Institute for Particle and Nuclear Physics
> H-1525 Budapest 114, POB. 49, Hungary
>
>
--
Rob Carlson, Systems and Network Administrator
Kitchen & Associates Architectural Services, PA
Architecture - Planning - Interior Design
856.854.1880
next prev parent reply other threads:[~2005-07-19 19:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-18 18:42 IPset ports question Rob Carlson
2005-07-19 8:42 ` Jozsef Kadlecsik
2005-07-19 19:13 ` Rob Carlson [this message]
2005-07-19 20:09 ` Jozsef Kadlecsik
2005-07-19 20:58 ` Rob Carlson
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=42DD50E4.9090800@kitchenandassociates.com \
--to=rcarlson@kitchenandassociates.com \
--cc=kadlec@blackhole.kfki.hu \
--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.