RE: strange logs -- tcp port 16166

From: Jerry Shenk (jshenk_at_decommunications.com)
Date: 06/25/03

  • Next message: James C. Slora Jr.: "Re: strange logs -- tcp port 16166" 
    To: "James C. Slora, Jr." <Jim.Slora@phra.com>, "Jiang Peng" <pengf@hotmail.com>, <incidents@lists.securityfocus.com>
Date: Wed, 25 Jun 2003 15:16:37 -0400

    Well, that looks like what it is. The window size matches.

    15:02:07.620000 yahoobb219046246242.bbtec.net.39770 > destination.com.44197:
    S 3511228839:3511228839(0) win 55808 <mss 1460,nop,wscale 2,nop,nop,sackOK>
    15:02:17.350000 yahoobb219046246242.bbtec.net.39770 > destination.com.44197:
    S 3511228839:3511228839(0) win 55808 <mss 1420,nop,wscale 2,nop,nop,sackOK>

    Here's a snort decode of the same packet:
    06/25-15:02:07.620000 xx:x:xx:xx:xx:xx -> xx:xx:xx:xx:xx:xx type:0x800
    len:0x42
    219.46.246.242:39770 -> destination:44197 TCP TTL:110 TOS:0x0 ID:20208
    IpLen:20 DgmLen:52
    ******S* Seq: 0xD14919A7 Ack: 0x0 Win: 0xDA00 TcpLen: 32
    TCP Options (6) => MSS: 1460 NOP WS: 2 NOP NOP SackOK

    -----Original Message-----
    From: James C. Slora, Jr. [mailto:Jim.Slora@phra.com]
    Sent: Wednesday, June 25, 2003 12:20 PM
    To: Jerry Shenk; Jiang Peng; incidents@lists.securityfocus.com
    Subject: RE: strange logs -- tcp port 16166

    Both sets of logs (Jerry Shenk and Jiang Peng) look very similar to the
    traffic everyone else has been analyzing for the past month+. Try to get
    some full packet captures, and see if the TCP window size is 55808. If so,
    there are multiple threads about this traffic on most security lists. The
    traffic is not fully explained at this point, but some of it may be related
    to "Typot" listed at antivirus vendor sites.

    The target port for the odd TCP win 55808 traffic varies from target to
    target and source addresses are generally spoofed, so your port numbers and
    source addresses might not be the key to solving your puzzle.

    Full packet captures are the only way to tell whether or not your traffic is
    related to the 55808 stuff.

    > -----Original Message-----
    > From: Jerry Shenk [mailto:jshenk@decommunications.com]
    > Sent: Wednesday, June 25, 2003 7:40 AM
    > To: Jiang Peng; incidents@lists.securityfocus.com
    > Subject: RE: strange logs -- tcp port 16166
    >
    >
    > That source is in a reserved block of addresses isn't it? I tried to
    > traceroute to it from here and 3 hops out, it got ICMP
    > unreachables. It
    > seems like this probably isn't related but I've had an
    > address in Japan
    > hitting on of my boxes for about 6 weeks. That too started
    > real slow and is
    > not hitting a couple times an hour. The source and
    > destination ports are
    > always the same. The internal IP address is even an unused
    > one. There is a
    > SHADOW IDS installed that grabs all headers - it doesn't show
    > any traffic to
    > that entire C.
    >
    > Here's a typical (only thing that changes is the time) log
    > entry from the
    > edge router that I've been seeing:
    >
    > Jun 25 00:10:04 list 106 tcp 219.46.246.242(39770) ->
    > xx.xxx.xxx.133(44197),
    > 1 pkt
    >
    > -----Original Message-----
    > From: Jiang Peng [mailto:pengf@hotmail.com]
    > Sent: Tuesday, June 24, 2003 11:00 PM
    > To: incidents@lists.securityfocus.com
    > Subject: strange logs -- tcp port 16166
    >
    >
    > Hi all,
    >
    > For the last month, I received the following log message continuelly =
    > from the PIX firewall:
    >
    > %PIX-4-106023: Deny tcp src outside:87.104.162.116/64604 dst =
    > inside:hostname/16166 by access-group "out
    > side_access_in"
    >
    > At first, there were only a couple of messages every day, but
    > from last =
    > week, there are 30-40 messages every day.
    > All the message has the same source, source port and same
    > destination, =
    > destination port. The destination is our external DNS server.
    > I checked =
    > google, but still no idea what kind of services running on port 16166.
    >
    > Does anyone have any clues for this message?
    >
    > Thanks,
    > Jiang
    >
    >

    ----------------------------------------------------------------------------
    Attend the Black Hat Briefings & Training, July 28 - 31 in Las Vegas, the
    world's premier technical IT security event! 10 tracks, 15 training sessions,
    1,800 delegates from 30 nations including all of the top experts, from CSO's to
    "underground" security specialists. See for yourself what the buzz is about!
    Early-bird registration ends July 3. This event will sell out. www.blackhat.com
    ----------------------------------------------------------------------------

  • Next message: James C. Slora Jr.: "Re: strange logs -- tcp port 16166"

    Relevant Pages

    • Re: Suspecious DNS traffic
      ... Every UDP and TCP packet has two port numbers, ... source port number. ... send a UDP packet with source port 53 and with destination port ... For TCP and stub DNS resolvers, ...
      (comp.protocols.dns.bind)
    • Re: Full Plate of Crow
      ... upsurges in port 80 probes and actually ... > firewall is only telling it dropped a packet, not what was in the packet. ... infections based on the data Caida collected. ... > firewall logs, not IDS logs. ...
      (Incidents)
    • Re: Windows ControlAd experience this morning
      ... TCP non-syn/non-ack packet on invalid connection. ... TCP Destination Port: 3665. ... OrgTechName: Network Operations ...
      (alt.computer.security)
    • Re: Strange WAN Activity
      ... > firewall logs for a possible TCP FIN scan that keeps ... > company's intranet server IP and its port 80 across our ... > My firewall is a Sonicwall Pro 200 and I'm running W2K ... It's difficult to be sure without inspecting the web server for signs of ...
      (microsoft.public.win2000.security)
    • Re: UDP catchall
      ... This is a kind of port knocking. ... Thanks to TCP ... If an RST packet is generated in response to the first TCP SYN packet, ... there might be no retransmission as the sender would think the TCP ...
      (freebsd-net)