--state NEW for UDP?

I am trying to log all instances of --state NEW packets on our interface
to the Internet, and am occasionally getting some UDP packets that match
the logging criteria from DNS nameservers:

Resolved_Address Packets Bytes Protocol(s) Dest.Port
148.78.249.202.starband.com 1 190 UDP 45236
ns1.eburg.com 1 256 UDP 45241
ns1-mar.starband.com 1 124 UDP 45271

Is there any reason why a nameserver in /etc/resolv.conf would be sending
me unsolicited UDP packets? The iptables rule that causes the logging is:

-A INPUT -m state -i eth1 --state NEW -j LOG --log-level 7 \
--log-prefix UNSOLICITED:

and the logged entry for the first instance above is:

May 1 08:31:48 centos51 kernel: UNSOLICITED:IN=eth1 OUT=
MAC=00:03:6d:17:df:1a:00:a0:ad:09:1d:88:08:00 SRC=148.78.249.202
DST=148.78.x.y LEN=105 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=53
DPT=45236 LEN=85

Am Thu, 01 May 2008 22:11:47 +0000 schrieb Greg Russell:
[color=blue]
> I am trying to log all instances of --state NEW packets on our interface
> to the Internet, and am occasionally getting some UDP packets that match
> the logging criteria from DNS nameservers:[/color]

Have fun with that, so it's pretty easy to get your host load up.

[color=blue]
> Is there any reason why a nameserver in /etc/resolv.conf would be sending
> me unsolicited UDP packets? The iptables rule that causes the logging is:[/color]

The DNS didn't send you an unsolicited packet, it just answered you DNS
query and that is a new packet (udp ist stateless).
[color=blue]
> -A INPUT -m state -i eth1 --state NEW -j LOG --log-level 7 \
> --log-prefix UNSOLICITED:
>
> and the logged entry for the first instance above is:
>
> May 1 08:31:48 centos51 kernel: UNSOLICITED:IN=eth1 OUT=
> MAC=00:03:6d:17:df:1a:00:a0:ad:09:1d:88:08:00 SRC=148.78.249.202
> DST=148.78.x.y LEN=105 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=53
> DPT=45236 LEN=85[/color]

Logging every packet could lead to a DOS.

cheers

[color=blue][color=green]
>> Is there any reason why a nameserver in /etc/resolv.conf would be sending
>> me unsolicited UDP packets? The iptables rule that causes the logging is:[/color][/color]
[color=blue]
>The DNS didn't send you an unsolicited packet, it just answered you DNS
>query and that is a new packet (udp ist stateless).[/color]

If UDP was really stateless, NAT boxes wouldn't know where to send
that type of responses.

I don't know much about iptables. I assume it either isn't setup
right for this problem or can't be setup correctly because it's missing
a critical feature.

--
These are my opinions, not necessarily my employer's. I hate spam.

Am Fri, 02 May 2008 02:00:17 -0500 schrieb Hal Murray:
[color=blue]
> If UDP was really stateless, NAT boxes wouldn't know where to send
> that type of responses.[/color]

NAT is a totally different thing.
UDP is stateless ([url]http://www.faqs.org/rfcs/rfc768.html[/url])

[color=blue]
>NAT is a totally different thing.
>UDP is stateless ([url]http://www.faqs.org/rfcs/rfc768.html[/url])[/color]

Even through the RFC says it is stateless, there is enough
information so that NAT boxes can do their thing.

If the goal is to make iptables not get confused by
answers to UDP packets, it might be a good idea to
copy whatever tricks NAT is using.

--
These are my opinions, not necessarily my employer's. I hate spam.

Am Fri, 02 May 2008 02:50:31 -0500 schrieb Hal Murray:
[color=blue]
> Even through the RFC says it is stateless, there is enough
> information so that NAT boxes can do their thing.[/color]

Sure, e.g.: cat /proc/net/ip_conntrack
[color=blue]
> If the goal is to make iptables not get confused by
> answers to UDP packets, it might be a good idea to
> copy whatever tricks NAT is using.[/color]

No, I don't agree if you log every new packet it fills just the logfile.
That means more I/O to system (logfile) and if there is no seperate
partition for /var/log, huge logfiles will stop the systems
(e.g. root-partition full)
In my opinion it doesen't make sense to log so paranoid, hut anyway
everybody can do what he want.

cheers

Hello,

Burkhard Ott a écrit :[color=blue]
> Am Fri, 02 May 2008 02:00:17 -0500 schrieb Hal Murray:
>[color=green]
>>If UDP was really stateless, NAT boxes wouldn't know where to send
>>that type of responses.[/color]
>
> NAT is a totally different thing.[/color]

Not so much. Stateful NAT relies on connection tracking.
[color=blue]
> UDP is stateless ([url]http://www.faqs.org/rfcs/rfc768.html[/url])[/color]

Even though UDP is stateless by design, the Netfilter connection
tracking maintains some state information about UDP flows, so a
bidirectionnal UDP flow with packets in each direction having
source/destination addresses and ports swapped is considered a connection.

To answer the initial question, there could be some reasons for DNS
replies being tagged NEW :
- the reply arrived after the connection entry expired (default
unreplied UDP timeout is 30 seconds) ;
- the source address of the query was spoofed ;
- you have a dynamic connection (DHCP, PPP...) and use MASQUERADE, which
deletes masqueraded connections whenever the interface goes down or has
its address deleted or changed ;
- the DNS server has some DNAT-based load-balancing which sometimes
fails to put the correct source address back in the reply.

On Fri, 02 May 2008 07:10:34 +0000, Burkhard Ott wrote:
[color=blue]
> UDP is stateless ([url]http://www.faqs.org/rfcs/rfc768.html[/url])[/color]

This doesn't mean that a stateful protocol cannot be built over UDP. DNS
has "responses". Therefore, it has state.

In playing around, I've noticed the same thing as the OP; I've been
curious about it too. I've thought perhaps that it's an artifact of the
timeout, but that seems a little unlikely. I'd notice delays like that!

Perhaps the issue is that responses are coming from different IPs than
that to which the requests are sent? I think I've seen this (resulting
in responses blocked by a stateful firewall?). Would these match
iptable's RELATED, perhaps?

- Andrew

Am Fri, 02 May 2008 12:37:18 +0000 schrieb Andrew Gideon:
[color=blue]
> On Fri, 02 May 2008 07:10:34 +0000, Burkhard Ott wrote:
>[color=green]
>> UDP is stateless ([url]http://www.faqs.org/rfcs/rfc768.html[/url])[/color]
>
> This doesn't mean that a stateful protocol cannot be built over UDP. DNS
> has "responses". Therefore, it has state.[/color]

No, it doesn't you surely mean a session in the firewall/filter.
You can't mix a stateless protocoll with a stateful.
(but you could encapsulate it)

Many stateful firewalls are able to track the state of flows in
connectionless protocols, like UDP.
Such sessions usually get the ESTABLISHED state immediately after the
first packet is seen by the firewall.
Sessions in connectionless protocols can only end by time-out, because
there is no flag where you could see that ist the last packet.
It ist not part of an protocoll.

By keeping track of the connection state, stateful firewalls provide added
efficiency in terms of packet inspection.
This is because for existing connections the firewall need only check the
state table, instead of checking the packet against the firewall's rule
set, which can be extensive.

cheers

On Fri, 02 May 2008 02:00:17 -0500, Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
[color=blue][color=green][color=darkred]
>>> Is there any reason why a nameserver in /etc/resolv.conf would be sending
>>> me unsolicited UDP packets? The iptables rule that causes the logging is:[/color][/color][/color]
[color=blue][color=green]
>>The DNS didn't send you an unsolicited packet, it just answered you DNS
>>query and that is a new packet (udp ist stateless).[/color][/color]
[color=blue]
>If UDP was really stateless, NAT boxes wouldn't know where to send
>that type of responses.[/color]

UDP is stateless. NAT boxes using UDP broadcast their UDP packets to
everybody on the physical network.

AZ Nomad a écrit :[color=blue]
>
> NAT boxes using UDP broadcast their UDP packets to
> everybody on the physical network.[/color]

Nonsense. UDP NAT does not work this way, it just cannot work this way.
UDP NAT is stateful.

On Fri, 02 May 2008 16:03:01 +0200, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:[color=blue]
>AZ Nomad a écrit :[color=green]
>>
>> NAT boxes using UDP broadcast their UDP packets to
>> everybody on the physical network.[/color][/color]
[color=blue]
>Nonsense. UDP NAT does not work this way, it just cannot work this way.
>UDP NAT is stateful.[/color]

It does and it has to. UDP packets are not point to point. They
are broadcast.

Perhaps you are confusing the NFS layer atop UDP with UDP itself?

Am Fri, 02 May 2008 11:09:10 -0500 schrieb AZ Nomad:
[color=blue]
> Perhaps you are confusing the NFS layer atop UDP with UDP itself?[/color]

Nope, a DNS query is defently unicast.

[color=blue]
>UDP is stateless. NAT boxes using UDP broadcast their UDP packets to
>everybody on the physical network.[/color]

Not mine. If an incoming UDP packet doesn't match a connection
or an entry in the "server" table that tells it the IP Address
to send it to, the packet gets dropped.

Maybe an ICMP error is sent back.

--
These are my opinions, not necessarily my employer's. I hate spam.

AZ Nomad a écrit :[color=blue]
>
> UDP packets are not point to point. They are broadcast.[/color]

Unicast UDP packets are point to point. DNS queries and replies over UDP
are unicast.
[color=blue]
> Perhaps you are confusing the NFS layer atop UDP with UDP itself?[/color]

No. What does NFS have to do with this ?

On Fri, 02 May 2008 12:37:18 +0000, Andrew Gideon wrote:
[color=blue]
> Perhaps the issue is that responses are coming from different IPs than
> that to which the requests are sent?[/color]

Thank you, I think that is the most likely scenario, as /etc/resolv.conf
on all NAT'd machines lists 148.78.249.20[01] and the occasional
"unsolicited" UDP packets emanate from SPT=53 on 148.78.249.20[0-3].

I'll use wireshark to examine the traffic and verify that hypothesis if
possible.

[color=blue][color=green]
>> This doesn't mean that a stateful protocol cannot be built over UDP.
>> DNS has "responses". Therefore, it has state.[/color]
>
> No, it doesn't you surely mean a session in the firewall/filter. You
> can't mix a stateless protocoll with a stateful. (but you could
> encapsulate it)[/color]

I wrote what I meant (or at least that part of it {8^), and I stand by it
(though in fact we're also speaking of firewall session states in this
conversation). An arbitrary protocol could be built over UDP which
provided it's own three-way handshake for session initiation, packet
sequence numbers, etc. These wouldn't be a part of UDP, of course, but
would be a part of the arbitrary protocol that we'd built that happens to
use UDP as the underlying transport.

So a stateful protocol can be built on top of a stateless protocol.

[But perhaps this is what you mean by "encapsulate"?]

In fact, if memory serves Ethernet is stateless. TCP packets are
transported over Ethernet.

Though, in fact, there is something I wrote incorrectly in my previous
note. DNS isn't stateful because it has requests and responses. That's
not how the term is used.
[color=blue]
> Many stateful firewalls are able to track the state of flows in
> connectionless protocols, like UDP.[/color]

That is also true. These can also track "related" flows, like the DATA
circuit used by FTP.

[...][color=blue]
> Sessions in connectionless protocols
> can only end by time-out, because there is no flag where you could
> see that ist the last packet.[/color]

This isn't necessarily true. For example, a firewall could choose to
take down the "session" for a DNS request when the response was seen.
But this is protocol specific and requires an inspecting firewall.

[...]
[color=blue]
>
> By keeping track of the connection state, stateful firewalls provide
> added efficiency in terms of packet inspection. This is because for
> existing connections the firewall need only check the state table,
> instead of checking the packet against the firewall's rule set, which
> can be extensive.[/color]

So can the state table be extensive. From what I've read, stateless
tends to win in efficiency for this reason (though there's the added
complexity that a stateless firewall is likely to have a larger rule set).

- Andrew

On Fri, 02 May 2008 11:09:10 -0500, AZ Nomad wrote:
[color=blue]
> It does and it has to. UDP packets are not point to point. They are
> broadcast.[/color]

I'm afraid not (though they *can* be broadcast; they don't have to be).
Do you imagine that any/every DNS request is broadcast? Or that NFS
packets are sent to every machine on a network? What happens when NFS
packets are routed?

A UDP packet has an IP address destination (though this could be a
broadcast address for a given network).

- Andrew