[nsp-sec] UDP 7100 Increase?

Matt.Carothers at cox.com Matt.Carothers at cox.com
Tue Mar 4 15:20:31 EST 2008


NAT would account for some boxes showing incrementing source ports with
others showing fixed.  Especially if the source ports look linuxy and
not windowsy.

I'm looking at my own network, and this doesn't seem like scanning
behavior.  My customers are repeatedly contacting the same hosts, and
they're receiving packets back from them.  Also, the one I examined made
a DNS query for list.pplive.com.  PPLive is alledgedly "a P2P televiion
network software that famous all othe world. It has the largest number
of users, the most extensive coverage in internet."  It appears to be
Chinese.

-- 
Matt Carothers
Cox Communications
(404) 269-7220 (office)
(404) 933-1125 (mobile)


> -----Original Message-----
> From: nsp-security-bounces at puck.nether.net [mailto:nsp-security-
> bounces at puck.nether.net] On Behalf Of Neil Long
> Sent: Tuesday, March 04, 2008 1:16 PM
> To: NSP nsp-security
> Subject: Re: [nsp-sec] UDP 7100 Increase?
> 
> ----------- nsp-security Confidential --------
> 
> Hi
> 
> Very odd and slightly ominous increases. Darknets can grab udp data
> segments of course via tcpdump.
> 
> The darknet collectors saw a lot of this starting yetserday -  all
> 76byte data segments (but with a 32byte "string" e.g.
> "FE893F2BD50B21AE6CE96F9AD1669564".
> 
> Some have srcport=dstport but by no means all and some srcIP packets
> have a fixed srcport while other sequences are incrementing srcport.
> 
> There is almost a unique string per srcIP but looking more closely I
> see the data change even though it is targeting the same /24.
> 
> The change seems to be more closely related to the timestamp i.e. the
> packets are going out in bursts which don't always cover the full /24
> 
> Fairly weird but 32bytes seems way too small to be a payload?? P2p?
> 
> regards
> Neil
> 
> 
> 
> 
> On 4 Mar 2008, at 17:45, <claude.labbe at bell.ca>
> <claude.labbe at bell.ca> wrote:
> 
> > ----------- nsp-security Confidential --------
> >
> >
> >
> >
> >   Hi,
> >
> > We are seeing 5 to 6 times the usual traffic since Feb 24th
> > will try to get more details on this in the next couple of hours
> >
> > Regards
> >
> > -----Original Message-----
> > From: nsp-security-bounces at puck.nether.net
> > [mailto:nsp-security-bounces at puck.nether.net] On Behalf Of
> > Matthew.Swaar at us-cert.gov
> > Sent: March 3, 2008 10:12 PM
> > To: nsp-security at puck.nether.net
> > Subject: [nsp-sec] UDP 7100 Increase?
> >
> > ----------- nsp-security Confidential --------
> >
> >
> > Anyone seeing a UDP-7100 traffic increase?  If so, does anyone know
> > what's causing it?
> >
> > My historical flowdata shows that traffic increased from ~4 flows
per
> > day to 1,072,861 on 3 March.  What's troubling, is that I logged
> > over 6k
> > unique sources.  I first thought that it might be a DDoS against
> > one or
> > more customers, but SANS port charts are showing some recent
volatile
> > activity, too.  (http://www.incidents.org/port.html?port=7100
> > <http://www.incidents.org/port.html?port=7100> )
> >
> > Here's the breakout for the (inbound) flows I show for March 3rd -
> 4th
> > GMT:
> >
> >                Date|          Records|                Bytes|
> > Packets|
> > 2008/03/03T00:00:00|            20.00|              3419.00|
> > 20.00|
> > 2008/03/03T01:00:00|            20.00|              3460.00|
> > 21.00|
> > 2008/03/03T02:00:00|            16.00|              2376.00|
> > 16.00|
> > 2008/03/03T03:00:00|            19.00|              3151.00|
> > 19.00|
> > 2008/03/03T04:00:00|         46794.00|           6641566.00|
> > 63803.00|
> > 2008/03/03T05:00:00|         43807.00|           6295043.00|
> > 60467.00|
> > 2008/03/03T06:00:00|            32.00|              4947.00|
> > 37.00|
> > 2008/03/03T07:00:00|         51664.00|           7380310.00|
> > 70930.00|
> > 2008/03/03T08:00:00|         96702.00|          13909022.00|
> > 133478.00|
> > 2008/03/03T09:00:00|           245.00|             36531.00|
> > 342.00|
> > 2008/03/03T10:00:00|            24.00|              3518.00|
> > 24.00|
> > 2008/03/03T11:00:00|        127143.00|          18289175.00|
> > 175324.00|
> > 2008/03/03T12:00:00|         28062.00|           4024740.00|
> > 38661.00|
> > 2008/03/03T13:00:00|        248105.00|          36357095.00|
> > 347733.00|
> > 2008/03/03T14:00:00|        341644.00|          50365557.00|
> > 483065.00|
> > 2008/03/03T15:00:00|           989.00|            147064.00|
> > 1396.00|
> > 2008/03/03T16:00:00|            41.00|              7851.00|
> > 42.00|
> > 2008/03/03T17:00:00|        112995.00|          16194471.00|
> > 155000.00|
> > 2008/03/03T18:00:00|           177.00|             24751.00|
> > 221.00|
> > 2008/03/03T19:00:00|            37.00|              7942.00|
> > 39.00|
> > 2008/03/03T20:00:00|            34.00|              5587.00|
> > 34.00|
> > 2008/03/03T21:00:00|            35.00|              6553.00|
> > 37.00|
> > 2008/03/03T22:00:00|            23.00|              3402.00|
> > 23.00|
> > 2008/03/03T23:00:00|         70267.00|          10319436.00|
> > 99170.00|
> > 2008/03/04T00:00:00|            22.00|              3212.00|
> > 26.00|
> > 2008/03/04T01:00:00|            25.00|              4340.00|
> > 25.00|
> > 2008/03/04T02:00:00|            15.00|              2272.00|
> > 15.00|
> > 2008/03/04T03:00:00|             1.00|               121.00|
> > 1.00|
> >
> > The above certainly doesn't resemble the traffic patterns I've
> > observed
> > in the past during worm outbreaks.  Looked at with a different
> > bias, the
> > above numbers originated from over 6k+ unique sources (possibly
> > spoofed)
> > and targeted over 500k unique destination IPs, so it doesn't look
> > like a
> > DDoS either.
> >
> > This port went from being invisible to being #14 on my top 20, and
> I'm
> > wondering 'why'.
> >
> > More details:  The traffic seems to be UDP sport 7100 to dport
> > 7100, 104
> > bytes per packet.  (My flowdata includes the header size, which I
> > think
> > is 28 bytes, so you may see this as 76 bytes per packet.)
> >
> >
> > Matt Swaar
> > US-CERT Analyst
> >
> >
> > _______________________________________________
> > nsp-security mailing list
> > nsp-security at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/nsp-security
> >
> > Please do not Forward, CC, or BCC this E-mail outside of the
> > nsp-security
> > community. Confidentiality is essential for effective Internet
> > security
> > counter-measures.
> > _______________________________________________
> >
> >
> > _______________________________________________
> > nsp-security mailing list
> > nsp-security at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/nsp-security
> >
> > Please do not Forward, CC, or BCC this E-mail outside of the nsp-
> > security
> > community. Confidentiality is essential for effective Internet
> > security counter-measures.
> > _______________________________________________
> >
> 
> --
> Neil Long, Team Cymru
> http://www.cymru.com | +1 312 924 4022 | neil at cymru.com
> 
> 
> 
> 
> 
> _______________________________________________
> nsp-security mailing list
> nsp-security at puck.nether.net
> https://puck.nether.net/mailman/listinfo/nsp-security
> 
> Please do not Forward, CC, or BCC this E-mail outside of the nsp-
> security
> community. Confidentiality is essential for effective Internet
security
> counter-measures.
> _______________________________________________



More information about the nsp-security mailing list