--state NEW for UDP? - Security

This is a discussion on --state NEW for UDP? - Security ; 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 ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: --state NEW for UDP?

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

  2. Re: --state NEW for UDP?

    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

  3. Re: --state NEW for UDP?


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


  4. Re: --state NEW for UDP?

    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)

  5. Re: --state NEW for UDP?


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


  6. Re: --state NEW for UDP?

    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

  7. Re: --state NEW for UDP?

    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.

  8. Re: --state NEW for UDP?

    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

  9. Re: --state NEW for UDP?

    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

  10. Re: --state NEW for UDP?

    On Fri, 02 May 2008 02:00:17 -0500, Hal Murray 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.

  11. Re: --state NEW for UDP?

    AZ Nomad a écrit :
    >
    > NAT boxes using UDP broadcast their UDP packets to
    > everybody on the physical network.


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

  12. Re: --state NEW for UDP?

    On Fri, 02 May 2008 16:03:01 +0200, Pascal Hambourg wrote:
    >AZ Nomad a écrit :
    >>
    >> NAT boxes using UDP broadcast their UDP packets to
    >> everybody on the physical network.


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


    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?

  13. Re: --state NEW for UDP?

    Am Fri, 02 May 2008 11:09:10 -0500 schrieb AZ Nomad:

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


    Nope, a DNS query is defently unicast.

  14. Re: --state NEW for UDP?


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


    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.


  15. Re: --state NEW for UDP?

    AZ Nomad a écrit :
    >
    > UDP packets are not point to point. They are broadcast.


    Unicast UDP packets are point to point. DNS queries and replies over UDP
    are unicast.

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


    No. What does NFS have to do with this ?

  16. Re: --state NEW for UDP?

    On Fri, 02 May 2008 12:37:18 +0000, Andrew Gideon wrote:

    > Perhaps the issue is that responses are coming from different IPs than
    > that to which the requests are sent?


    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.

  17. Re: --state NEW for UDP?


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


    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.

    > Many stateful firewalls are able to track the state of flows in
    > connectionless protocols, like UDP.


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

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


    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.

    [...]

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


    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

  18. Re: --state NEW for UDP?

    On Fri, 02 May 2008 11:09:10 -0500, AZ Nomad wrote:

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


    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

+ Reply to Thread