Re: Port 0 packets

From: Dave Paris (dparis_at_w3works.com)
Date: 07/24/03

  • Next message: Jason Falciola: "Re: www.google.com reference in directory-traversal attack" 
    Date: Thu, 24 Jul 2003 16:04:49 -0400
To: Russell Fulton <r.fulton@auckland.ac.nz>

    Our IDS spotted another TCP port 0 packet at 19:59pm UTC today
    (Thursday). Headers follow:

    [**] (snort_decoder): T/TCP Detected [**]
    07/24-19:59:51.308749 216.136.173.246:0 -> xxx.xxx.xxx.xxx:0
    TCP TTL:55 TOS:0x0 ID:41202 IpLen:20 DgmLen:68 DF
    ******S* Seq: 0x73C13DA0 Ack: 0x0 Win: 0xFFFF TcpLen: 48
    TCP Options (9) => MSS: 1460 NOP WS: 1 NOP NOP TS: 15026415 0
    TCP Options => NOP NOP CCNEW: 248555

    Kind Regards,
    -dsp

    On Wednesday, Jul 23, 2003, at 16:38 US/Eastern, Russell Fulton wrote:

    > On Wed, 2003-07-23 at 12:28, Stuart wrote:
    >> Hi,
    >>
    >> After currently reviewing firewall logs from ISA server I have come
    >> across a period of where the box was hit with an aprox. average of 3
    >> - 4
    >> packets per 5 minute period for 8 hours.
    >
    > Over the last few day sort has been complaining about packets on TCP 0
    > to an address in our network. I finally got to investigate it
    > yesterday.
    >
    > The packets were coming from two IP addresses in China and were tcp
    > with
    > RST+ACK flags set. I then used our argus <www.qosient.com> logs to
    > examine all the traffic between the addresses. It turned out that that
    > there was a flood of incoming packets with random source and
    > destination
    > ports. So snort was triggering on a tiny proportion of the total
    > packets.
    >
    > I concluded that this was fallout from a DOS attack on the two Chinese
    > machines in which our address had been spoofed.
    >
    > Give the frequency of your packets and the likelihood that you would
    > have noticed if there was other traffic from the source this probably
    > is
    > not the same scenario. One thing that would help us work out possible
    > causes is some more details about the packets -- TCP or UDP, flags etc.
    >
    > --
    > Russell Fulton, Network Security Officer, The University of Auckland,
    > New Zealand.
    >
    >
    > -----------------------------------------------------------------------
    > ----
    > -----------------------------------------------------------------------
    > -----
    >
    >
    >

    ---------------------------------------------------------------------------
    ----------------------------------------------------------------------------

  • Next message: Jason Falciola: "Re: www.google.com reference in directory-traversal attack"

    Relevant Pages

    • Re: UPD better than TCP in streaming video/audio ?
      ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
      (microsoft.public.win32.programmer.networks)
    • Re: Simulating smaller MTU? ie sending small packets.
      ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
      (comp.lang.perl.misc)
    • Re: NTP and Firewall help needed.
      ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
      (comp.os.linux.setup)
    • Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
      ... I'll be able to run some more basic tests tomorrow to see some results, but want to wrap my head around what's actually logically meant to be happening based on adjustments, etc. [I suspect this'll do nothing for the UDP issue, but at least I might be able to pipe some TCP traffic] ... Little packets with ip lengths of 28-29 bytes seem to do the most damage. ... UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). ...
      (freebsd-performance)
    • tcp hostcache and ip fastforward for review
      ... this patch contains three things (to be separated for committing): ... - removes ip route cache in ip_input.c (locking much easier) ... - removes most (tcp specific) metrics from rtentry metrics ... - fixes wrong goto in tcp_input.c which sends two RST packets ...
      (freebsd-current)