Re: bind() udp behavior 2.6.8.1

From: Adam Denenberg (adam_at_dberg.org)
Date: 12/14/04

  • Next message: Tom Duffy: "Re: [openib-general] [PATCH][v3][5/21] Add InfiniBand MAD (management datagram) support" 
    To: Jan Engelhardt <jengelh@linux01.gwdg.de>
Date:	Tue, 14 Dec 2004 12:01:56 -0500

    any firewall must keep some sort of state table even if it is udp. How
    else do you manage established connections? It must know that some high
    numbered port is making a udp dns request, and thus be able to allow
    that request back thru to the high numbered port client b/c the
    connection is already established.

    what does any fireawall do if it sees one ip with the same high numbered
    udp port make a request in a _very_ short amount of time (under 60ms for
    this example)? It must make a distintion between an attack and legit
    traffic. So if it sees one ip/port make multiple requests in too short
    of a time frame, it will drop the traffic, as it probably should. This
    is causing erratic behavior when traffic traverses the firewall b/c the
    linux kernel keeps allocating the same source high numbered ephemeral
    port. I would like to know if there is a way to alter this behavior b/c
    it is breaking applications.

    thanks
    adam

    please CC me as I am not on this list.

    On Tue, 2004-12-14 at 11:44, Jan Engelhardt wrote:
    > >sorry "closed" was the wrong term here. We are using a PIX Firewall
    > >Module and it keeps a state table of all connections (tcp and udp).
    > >Thus when a new udp connection comes in with same high numbered source
    >
    > UDP does not know connections. As such, _nobody_ can tell whether an UDP
    > packet belongs to a logically existing "connection" or not.
    >
    > >port and the firewall has not removed that connection from its state
    > >table, the firewall drops the packet. The firewall needs about 60ms in
    > >order to clear that connection from the state table, so if a second udp
    > >request with the same high number port/ip comes thru before the firewall
    > >clears the connection from the state table, it will drop the connection
    > >(which is what we are seeing).
    > >
    > >FreeBSD seems to increment future udp requests which prevents this
    > >problem. It just seems strange that the kernel would not randomize or
    > >increment these source ports for udp requests.
    >
    > The kernel does not have problems with UDP, it's probably your firewall.
    >

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Tom Duffy: "Re: [openib-general] [PATCH][v3][5/21] Add InfiniBand MAD (management datagram) support"

    Relevant Pages

    • Re: bind() udp behavior 2.6.8.1
      ... We are using a PIX Firewall ... Module and it keeps a state table of all connections (tcp and udp). ... Thus when a new udp connection comes in with same high numbered source ... FreeBSD seems to increment future udp requests which prevents this ...
      (Linux-Kernel)
    • UDP connection attempts
      ... Jul 19 03:25:56 ns1 kernel: Connection attempt to UDP ... something that has to do with my firewall settings, ...
      (FreeBSD-Security)
    • Re: bind() udp behavior 2.6.8.1
      ... clearing out a UDP connection in a firewall coming from a high port is ... Allowing a high numbered udp port to remain ... first connection which is what is causing the issue. ...
      (Linux-Kernel)
    • Re: How can I make the server to call back to client without being blocked by firewall.
      ... Since UDP can also be in connection mode even ... >so that server can send some data back without being blocked by firewall? ... Fax/Voice +1258-9858 | read details of WFTPD Pro for XP/2000/NT. ...
      (comp.security.firewalls)
    • Re: weird packets.. anyone?
      ... See below for how I handle this on my cable connection. ... The second appears to be a broadcast NetBIOS-NS request from a DHCP ... I simply drop all tcp and udp>134 <140 and ignore them. ... spoof UDP traffic through your packet filters. ...
      (FreeBSD-Security)