All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christoph A." <casmls@gmail.com>
To: netfilter@vger.kernel.org
Cc: Julien Vehent <julien@linuxwall.info>,
	NICHOLAS KLINE <nkline@kent.edu>,
	"Christoph A." <casmls@gmail.com>
Subject: Re: Firewall Configuration Help
Date: Wed, 05 Aug 2009 20:21:01 +0200	[thread overview]
Message-ID: <4A79CD8D.4030005@gmail.com> (raw)
In-Reply-To: <47ae5fdc6d1c4a93d1035f61774996ec@localhost>

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

On 28.07.2009 11:09, Julien Vehent wrote:
>> # The following will NOT interfere with local inter-process traffic,
> whose
>> # packets have the source IP of the local loopback interface, e.g.
>> 127.0.0.1
>>
>> $IPTABLES -A INPUT -s $IP_LOCAL -j LOG --log-prefix "Spoofed source IP"
>> $IPTABLES -A INPUT -s $IP_LOCAL -j DROP
>>
>> # Tell netfilter that all TCP sessions do indeed begin with SYN
>>
>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG
>> --log-prefix "Stealth scan attempt?"
>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
>>
>>
> 
> My understanding of the conntrack subsystem is that a connection cannot be
> in the state NEW without a syn packet, therefore I don't think this is
> useful.


I also thought that such a packet has the state INVALID, but after
making some tests I saw that such TCP packets (! --syn with state NEW)
are possible, but considering his hole ruleset these packets would be
DROPed anyway by his default policy, because he has no
-A INPUT ... --state NEW -j ACCEPT
rules in his ruleset.
This means that the rule is redundant and should be removed to minimize
the number of rules.

Just for the record, I tested it like this:
I generated a packet with hping that has only the ACK flag set and
to see the state I created some logging rules:

iptables -A INPUT -p tcp --sport 9999 ! --syn -m state --state NEW -j
LOG --log-prefix "NEW_: "
iptables -A INPUT -p tcp --sport 9999 ! --syn -m state --state RELATED
-j LOG --log-prefix "RELATED_: "
iptables -A INPUT -p tcp --sport 9999 ! --syn -m state --state
ESTABLISHED -j LOG --log-prefix "ESTABLISHED_: "
iptables -A INPUT -p tcp --sport 9999 ! --syn -m state --state INVALID
-j LOG --log-prefix "INVALID_: "


test #1: (ACK flag set)
hping3 -c 1 -I wlan0 -A -s 9999 -p 1110 localhost

Logging output:
NEW_: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00
SRC=192.168.1.33 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=4943
PROTO=TCP SPT=9999 DPT=1110 WINDOW=512 RES=0x00 ACK URGP=0

state => NEW
------------------------------------------------------
test #2 (no TCP flags set):
hping command:

hping -c 1 -I wlan0 -s 9999 -p 1111 localhost

Logging output:
INVALID_: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00
SRC=192.168.1.33 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=9687
PROTO=TCP SPT=9999 DPT=1111 WINDOW=512 RES=0x00 URGP=0

(test was made with iptables v1.4.3.1)


On 05.08.2009 15:35, Mart Frauenlob wrote:
> Wrong, from the iptables tutorial 1.2.2 at frozentux:
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html#STATEMACHINE
>
> The NEW state tells us that the packet is the first packet that we see.
> This means that the first packet that the conntrack module sees, within
> a specific connection, will be matched. For example, if we see a SYN
> packet and it is the first packet in a connection that we see, it will
> match. However, the packet may as well not be a SYN packet and still be
> considered NEW.

Given this fact I'm reconsidering my rules like:

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT

to be changed to:
iptables -A INPUT -p tcp --dport 80 --syn -j ACCEPT
(because this is the samller group of packets and works as well)

best regards,
Christoph A.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  parent reply	other threads:[~2009-08-05 18:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-27 17:56 Firewall Configuration Help NICHOLAS KLINE
2009-07-28  9:09 ` Julien Vehent
2009-07-28 13:19   ` Billy Crook
2009-07-28 13:27     ` Julien Vehent
2009-07-28 22:08     ` /dev/rob0
2009-08-05 13:20   ` Mart Frauenlob
2009-08-05 13:51     ` Julien Vehent
2009-08-05 14:05       ` Mart Frauenlob
2009-08-05 13:35   ` Mart Frauenlob
2009-08-05 13:47     ` Julien Vehent
2009-08-05 18:21   ` Christoph A. [this message]
2009-08-05 12:56 ` Mart Frauenlob

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=4A79CD8D.4030005@gmail.com \
    --to=casmls@gmail.com \
    --cc=julien@linuxwall.info \
    --cc=netfilter@vger.kernel.org \
    --cc=nkline@kent.edu \
    /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.