Re: Logs: Many hits with source port of 80

From: Byrne Ghavalas (security@nscs.uk.com)
Date: 12/16/02

  • Next message: Joe Stewart: "Re: Logs: Many hits with source port of 80"
    From: "Byrne Ghavalas" <security@nscs.uk.com>
    To: "James C Slora Jr" <Jim.Slora@phra.com>, <incidents@securityfocus.com>
    Date: Mon, 16 Dec 2002 14:21:14 -0000
    
    

    Hi,

    Thanks for the suggestion. Russell F. also mentioned that he'd had seen
    this traffic as a result of load balancing switches...

    I had checked my logs to see if there were any matching web sessions as
    usually these packets are a result of late packets arriving out of
    sequence, which are then dropped by the firewall as they don't match any
    current sessions.

    However, I couldn't find any outgoing sessions (web or other) to any of
    the IP addresses in my logs. The other strange thing was the timing of
    the packets - the packets arrived at the same interval, with the last 5
    packets being one minute apart (give or take a few ms for latency).

    Reverse lookups are generally not configured on the IP addresses in the
    logs, and for those that do have PTR records, the host is usually a
    cable / DSL user at an ISP.

    There does seem to be something listening on the sample IP from my logs,
    at port 80, but it returns a 404 - 'The requested URL,
    "http://194.78.225.36:8808/", is not available.'

    I have captured some of the packets for analysis - they seem to be
    standard tcp packets with no data - just FIN and ACK flags set.

    I'm guessing it must be some kind of scan attempting to go through badly
    configured ACLs / non-stateful firewalls... Maybe NMAP? Not sure about
    that though...

    I'll be unable to get my mail for the next 2 week - so if anyone wishes
    to investigate this further (which I doubt - coz the packets seem rather
    dull <grin>) just drop me a message off-list and I'll pick up the
    conversation when I next access my mail.

    Kind regards,

    Byrne Ghavalas

    ----- Original Message -----
    From: "James C Slora Jr" <Jim.Slora@phra.com>
    To: "'Byrne Ghavalas'" <security@nscs.uk.com>;
    <incidents@securityfocus.com>
    Sent: Monday, December 16, 2002 1:37 PM
    Subject: RE: Logs: Many hits with source port of 80

    > I have seen similar hits for the past three months.
    >
    > Mine are UDP. Are you sure yours are TCP? All mine had destination
    port
    > 37852. All hits have been from the same two hosts, and are fairly
    > infrequent.
    >
    > 2002-12-11 14:56:03 63.211.17.228 myhost Udp 80 37852
    > 2002-12-11 14:56:06 64.152.70.68 myhost Udp 80 37852
    > 2002-12-11 14:56:08 63.211.17.228 myhost Udp 80 37852
    > 2002-12-11 14:56:11 64.152.70.68 myhost Udp 80 37852
    > 2002-12-11 15:04:20 64.152.70.68 myhost Udp 80 37852
    > 2002-12-11 15:04:25 64.152.70.68 myhost Udp 80 37852
    >
    > The reverse DNS for 64.152.70.68 is proximitycheck2.allmusic.com, but
    > proximitycheck2.allmusic.com doesn't resolve to anything.
    > The reverse DNS for 63.211.17.228 is proximitycheck1.allmusic.com, but
    > proximitycheck1.allmusic.com doesn't resolve to anything.
    >
    > These always appear after a user visits www.allmusic.com and I believe
    the
    > packets are benign but annoying load balancing probes. Your probes may
    > possibly have similar origins - try correlating the probes with web
    logs if
    > you have them.
    >
    > -----Original Message-----
    > From: Byrne Ghavalas [mailto:security@nscs.uk.com]
    > Sent: Friday, December 13, 2002 5:06 AM
    > To: incidents@securityfocus.com
    > Subject: Logs: Many hits with source port of 80
    >
    >
    > Hi All,
    >
    > Has anyone else noticed a high number of hits in their security logs,
    > where the source port is set to tcp 80 and the destination port is
    some
    > high tcp port? I have noticed that these events seem to be getting
    more
    > numerous than the NetBios scans ;-)
    >
    > For example:
    > 2002-12-13 09:08:04 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:07:04 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:06:05 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:05:04 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:04:04 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:03:05 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:02:04 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:01:28 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:01:10 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:01:01 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:00:57 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:00:55 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:00:54 194.78.225.36:80 XX.XX.XX.XX:29439
    > 2002-12-13 09:00:54 194.78.225.36:80 XX.XX.XX.XX:29439
    >
    > It appears to be some kind of automated scan as the time of each entry
    > appears to follow a pattern.
    >
    > Byrne Ghavalas
    >
    >
    >
    > ----------------------------------------------------------------------
    ------
    > This list is provided by the SecurityFocus ARIS analyzer service.
    > For more information on this free incident handling, management
    > and tracking system please see: http://aris.securityfocus.com
    >
    >
    >

    ----------------------------------------------------------------------------
    This list is provided by the SecurityFocus ARIS analyzer service.
    For more information on this free incident handling, management
    and tracking system please see: http://aris.securityfocus.com



    Relevant Pages

    • Re: DOD Inside
      ... Do you have logs of the actual packet contents or just these logs of the communication endpoints? ... What kind of a network is that router on? ... One remarkable fact about those packets is that the source port number is equal to 0x3434 in all cases and the destination port numbers were always quite near the 1024 boundary; except for one case, when it was port 139. ...
      (Incidents)
    • Re: Harvested TCPs of hackers
      ... It alerts you when unsolicited packets arrive at your computer. ... TCP is a protocol, not an address. ... Crackers (those hackers who have turned ... D-Shield or MyNetWatchman accept router and firewall logs, ...
      (microsoft.public.security)
    • RE: Logs: Many hits with source port of 80
      ... > The hits from source port 80 to dest port 37852 are IMHO almost ... which sends a few packets to the other end of the ... > their load balancer pays you a visit - you might look for inbound ... >> the IP addresses in my logs. ...
      (Incidents)
    • Re: Odd Firewall logs
      ... >>I just found some interesting hits in my firewall log. ... no response would be able to reach those IPs. ... > and so the packets could be routed to you. ... I'll check the logs more, I think I saw some other IP scanning the same ...
      (comp.os.linux.security)
    • Re: computer misuse
      ... firewall logs, showing all incoming connections, all outgoing connections, ... There is no legal problem in keeping these logs. ... we need the logs of the outgoing packets so that if someone ... What we -cannot- do is blithely record packet streams *with the intent ...
      (comp.security.misc)

  • Quantcast