Mailing List Archive

Well, in the three-way handshake the flags in the packets are:

1) syn packet sent by the client
2) syn,ack sent by the server
3) ack sent by the client

The packets in the NEW state for a statefull firewall (as iptables) are
packets that belongs to a new "data stream", marked with the syn flag.

The packets in the INVALID state are packets, in your case specifically,
that implies a new "data stream" (or more properly, packets that does not
belongs to a connection previously ESTABLISHED or to a connection RELATED to
a connection previously ESTABLISHED) but this new "data stream" is not
negotiating for open a new socket, is just sending "data".

To extend the analogy of the three-way handshake, someone is trying to shake
your hand but you see the persone until you have the sense of the other hand
in your hand, then you are surprised, retire your hand and face the other
person trying to recognize who is, does not shake his hand and does not
speak to him.

In fact, there are 0 packets with the state NEW with the flags
FIN,SYN,RST,ACK/SYN,ACK because the packets that you sent does not have the
right flags to be considered a valid packets to open a new connection.

Jorge.

On Sat, 4 Aug 2007 21:21:09 +0200
Franck Joncourt <franck.joncourt@wanadoo.fr> wrote:
> Hi,
>
> Looking at this :
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html#SYNACKANDNEW
>
> I understand that in order to prevent my ip address from being spoofed,
> I should reject NEW packets with the SYN/ACK flags set and the others
> cleared.
>
> However, with the following nmap command I have tried to check it out :
>
> nmap --scanflags SYNACK 192.168.0.1
>
> all packets are known to be in the INVALID state rather than in the NEW
> state.
>
> state NEW tcp flags:FIN,SYN,RST,ACK/SYN,ACK -> 0 packet
> state INVALID tcp flags:FIN,SYN,RST,ACK/SYN,ACK -> 170 packets
>
> They talk about sequence number, as well, in the document, but I can't
> figure out what difference it makes.
>
> Did I miss anything ?
>
> --
>Franck Joncourt
> http://www.debian.org - http://smhteam.info/wiki/
> GPG server : pgpkeys.mit.edu
>Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
davila@nicaraguaopensource.com

> On Sat, 4 Aug 2007 21:21:09 +0200
> Franck Joncourt <franck.joncourt@wanadoo.fr> wrote:
>> Hi,
>> Looking at this :
>> http://iptables-tutorial.frozentux.net/iptables-tutorial.html#SYNACKANDNEW
>> I understand that in order to prevent my ip address from being spoofed,
>> I should reject NEW packets with the SYN/ACK flags set and the others
>> cleared.
>> However, with the following nmap command I have tried to check it out :
>> nmap --scanflags SYNACK 192.168.0.1
>> all packets are known to be in the INVALID state rather than in the NEW
>> state.
>> state NEW tcp flags:FIN,SYN,RST,ACK/SYN,ACK -> 0 packet
>> state INVALID tcp flags:FIN,SYN,RST,ACK/SYN,ACK -> 170 packets
>> They talk about sequence number, as well, in the document, but I can't
>> figure out what difference it makes.
>> Did I miss anything ?

On Sat, Aug 04, 2007 at 02:26:12PM -0600, Jorge Davila wrote:
> Well, in the three-way handshake the flags in the packets are:
>
> 1) syn packet sent by the client
> 2) syn,ack sent by the server
> 3) ack sent by the client

So far, I agree :p!

> The packets in the NEW state for a statefull firewall (as iptables) are
> packets that belongs to a new "data stream", marked with the syn flag.

What about sending packets with only the ACK flag set.

Those packets matched the following rule every time on random ports :

iptables -A INPUT -m state --state NEW \
-p tcp SYN,FIN,RST,ACK ACK -j RETURN

using nmap --scanflags ACK 192.168.0.1

So, there is something wrong since I did not send any SYN packets. 530
packets send and 530 packets matched. And none of them are part of a
connection.

> The packets in the INVALID state are packets, in your case specifically,
> that implies a new "data stream" (or more properly, packets that does not
> belongs to a connection previously ESTABLISHED or to a connection RELATED
> to a connection previously ESTABLISHED) but this new "data stream" is not
> negotiating for open a new socket, is just sending "data".

I understand what you mean, I hope so. The flags SYN/ACK are not
sufficent to be matched as a NEW state since there is nothing in the
data stream "to negotiate for a new socket".

>
> In fact, there are 0 packets with the state NEW with the flags
> FIN,SYN,RST,ACK/SYN,ACK because the packets that you sent does not have the
> right flags to be considered a valid packets to open a new connection.

Ok.

Do not worry about the ACK packets, unless you have an explanation and
the time to put it down. There must be something in the RFC 793 about
it.

Thanks

I apologize for the delay, but I saw your message when I was sorting
out my spams.

--
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

Franck,

In the the RFC 793 [1] we can read:

A TCP connection progresses from one state to another in response to
events. The events are the user calls, OPEN, SEND, RECEIVE, CLOSE,
ABORT, and STATUS; the incoming segments, particularly those
containing the SYN, ACK, RST and FIN flags; and timeouts.

Then, the rule

iptables -A INPUT -m state --state NEW \
-p tcp SYN,FIN,RST,ACK ACK -j RETURN

_must_ match the packet sent by nmap because have a valid state (NEW) and a
valid flag (ACK) -a flag that is present in a normal tcp negotiation.

Someone may want dig in this?

Jorge Dávila.

[1] http://www.ietf.org/rfc/rfc793.txt

On Mon, 6 Aug 2007 20:20:27 +0200
Franck Joncourt <franck.joncourt@wanadoo.fr> wrote:
>> On Sat, 4 Aug 2007 21:21:09 +0200
>> Franck Joncourt <franck.joncourt@wanadoo.fr> wrote:
>>> Hi,
>>> Looking at this :
>>> http://iptables-tutorial.frozentux.net/iptables-tutorial.html#SYNACKANDNEW
>>> I understand that in order to prevent my ip address from being spoofed,
>>> I should reject NEW packets with the SYN/ACK flags set and the others
>>> cleared.
>>> However, with the following nmap command I have tried to check it out :
>>> nmap --scanflags SYNACK 192.168.0.1
>>> all packets are known to be in the INVALID state rather than in the NEW
>>> state.
>>> state NEW tcp flags:FIN,SYN,RST,ACK/SYN,ACK -> 0 packet
>>> state INVALID tcp flags:FIN,SYN,RST,ACK/SYN,ACK -> 170 packets
>>> They talk about sequence number, as well, in the document, but I can't
>>> figure out what difference it makes.
>>> Did I miss anything ?
>
> On Sat, Aug 04, 2007 at 02:26:12PM -0600, Jorge Davila wrote:
>> Well, in the three-way handshake the flags in the packets are:
>>
>> 1) syn packet sent by the client
>> 2) syn,ack sent by the server
>> 3) ack sent by the client
>
> So far, I agree :p!
>
>> The packets in the NEW state for a statefull firewall (as iptables) are
>> packets that belongs to a new "data stream", marked with the syn flag.
>
> What about sending packets with only the ACK flag set.
>
> Those packets matched the following rule every time on random ports :
>
> iptables -A INPUT -m state --state NEW \
> -p tcp SYN,FIN,RST,ACK ACK -j RETURN
>
> using nmap --scanflags ACK 192.168.0.1
>
> So, there is something wrong since I did not send any SYN packets. 530
> packets send and 530 packets matched. And none of them are part of a
> connection.
>
>> The packets in the INVALID state are packets, in your case specifically,
>> that implies a new "data stream" (or more properly, packets that does not
>> belongs to a connection previously ESTABLISHED or to a connection RELATED
>> to a connection previously ESTABLISHED) but this new "data stream" is not
>> negotiating for open a new socket, is just sending "data".
>
> I understand what you mean, I hope so. The flags SYN/ACK are not
> sufficent to be matched as a NEW state since there is nothing in the
> data stream "to negotiate for a new socket".
>
>>
>> In fact, there are 0 packets with the state NEW with the flags
>> FIN,SYN,RST,ACK/SYN,ACK because the packets that you sent does not have
>>the
>> right flags to be considered a valid packets to open a new connection.
>
> Ok.
>
> Do not worry about the ACK packets, unless you have an explanation and
> the time to put it down. There must be something in the RFC 793 about
> it.
>
> Thanks
>
> I apologize for the delay, but I saw your message when I was sorting
> out my spams.
>
> --
>Franck Joncourt
> http://www.debian.org - http://smhteam.info/wiki/
> GPG server : pgpkeys.mit.edu
>Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
davila@nicaraguaopensource.com