--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:

> 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:

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


> 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:

The DNS didn't send you an unsolicited packet, it just answered you DNS
query and that is a new packet (udp ist stateless).

> -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

Logging every packet could lead to a DOS.

cheers

>> 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:

>The DNS didn't send you an unsolicited packet, it just answered you DNS
>query and that is a new packet (udp ist stateless).

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:

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

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

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

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:

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

Sure, e.g.: cat /proc/net/ip_conntrack

> 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.

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 :
> Am Fri, 02 May 2008 02:00:17 -0500 schrieb Hal Murray:
>
>>If UDP was really stateless, NAT boxes wouldn't know where to send
>>that type of responses.
>
> NAT is a totally different thing.

Not so much. Stateful NAT relies on connection tracking.

> UDP is stateless (http://www.faqs.org/rfcs/rfc768.html)

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:

> UDP is stateless (http://www.faqs.org/rfcs/rfc768.html)

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:

> On Fri, 02 May 2008 07:10:34 +0000, Burkhard Ott wrote:
>
>> UDP is stateless (http://www.faqs.org/rfcs/rfc768.html)
>
> This doesn't mean that a stateful protocol cannot be built over UDP. DNS
> has "responses". Therefore, it has state.

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:

>>> 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:

>>The DNS didn't send you an unsolicited packet, it just answered you DNS
>>query and that is a new packet (udp ist stateless).

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

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