Re: iptables and INVALID packet filtering.
Matthew Babcock a écrit :
> On Thu, 2013-05-02 at 00:17 +0200, Pascal Hambourg wrote:
>> Hello,
>>
>> Matthew Babcock a écrit :
>>> Please excuse the delayed response.
>> No problem.
>>
>>> To answer your question, no I cannot, yet.
>>>
>>> However, I can demonstrate iptables following what the "state" be on UDP
>>> packets using DNS.
>> [...]
>>> You should see as I do, that the UDP DNS request are logged under the
>>> state NEW, and that the response was logged under the state ESTABLISHED.
>> Nothing new here. UDP possible states are :
>> - NEW for a datagram creating a new connection or belonging to a
>> "connection" which has seen traffic only in one direction ;
>> - ESTABLISHED for a datagram belonging to a "connection" which has seen
>> traffic in both directions ;
>> - RELATED when a conntrack helper expects a UDP datagram related to an
>> existing connection (e.g. TFTP or SIP).
>
> Much of that is my point. I am not sure why you make the statement
> specific to UDP while omitting the "INVALID" state.
Because I am describing how the general UDP connection tracking behaves.
AFAIK, it does not use the INVALID state because, as you mention, this
state does not make sense until the connection tracking looks beyond the
IP and UDP headers.
> iptables can determine, based on some criteria, what "state" a
> connectionless protocol is in.
Actually the state is not determined by iptables but by the connection
tracking (aka conntrack), an other part of netfilter. iptables is just
the filtering and mangling part of netfilter.
> As I conceptualized previously and am now elaborating on, there are
> several application layer protocols that have their own "state", yet are
> transported over unreliable transport protocols.
>
> Example #1, DNS requests.
> DNS packets have Transaction IDs. See the RFC rfc1035
> "This identifier is copied the corresponding reply and can be used by
> the requester to match up replies to outstanding queries."
>
> So, an "established" DNS connection over UDP is *determined most
> accurately through the layer 7 protocol*, matching the transaction IDs
> in the absence of TCP Flags.
I guess that a protocol-specific conntrack helper could do this. Not
sure it is desirable.
> Example #2, ICMP Pings.
> I believe the standard for ICMP ping messages states that a ICMP ECHO
> Response, is only created in response to an incoming ICMP Echo Request.
>
> It seems to me that if iptables looked a bit beyond the headers (my
> suggested premise) it could easily flag a unsolicited ICMP Echo response
> as an INVALID state packet.
Conntrack already does this. But ICMP has a special status : although is
is carried over IP, it is part of the IP protocol at the network layer,
it is not an application or transport layer protocol.
Reply to: