Re: Logs: Many hits with source port of 80

From: Kevin Bowman (kevin.bowman@garmin.com)
Date: 12/16/02

  • Next message: Damian Gerow: "Re: Rooted, .haos on system" 
    Date: Mon, 16 Dec 2002 12:54:03 -0600
From: Kevin Bowman <kevin.bowman@garmin.com>
To: Byrne Ghavalas <security@nscs.uk.com>

    The hits from source port 80 to dest port 37852 are IMHO almost
    certainly from a RadWare Linkproof device. These load balancers play
    DNS games to load balance across multiple WAN connections without the
    need for BGP4. The probes you see are from the LinkProof's "proximity
    balancing" feature, which sends a few packets to the other end of the
    connection to try to determine which WAN link provides lowest cost,
    allowing subsequent traffic to move along that path.

    If I'm correct, you should probably see a couple other packets - perhaps
    an ICMP echo and a port 53 hit with source of port 53. I have also seen
    destinations of 47804 and 60750. The proximity feature will fire these
    packets if either you send the load balancer a packet, or someone behind
    their load balancer pays you a visit - you might look for inbound
    packets from their networks as well as outbound to them.

    http://www.radware.com/content/products/link.asp

    Hope this helps.
    Kevin

    Byrne Ghavalas wrote:
    > 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
    >
    >
    >

    ----------------------------------------------------------------------------
    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: 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 am running Smoothwalll 2.0 Express and I have several hits coming ... no response would be able to reach those IPs. ... and so the packets could be routed to you. ... > what is odd is that their are several 4-5 attempts at each port. ...
      (comp.os.linux.security)
    • [Full-Disclosure] Port 6881 scans - why?
      ... Am getting a Distributed and fair quantity ... (100 packets per min. per IP) ... of port 6881 hits... ...
      (Full-Disclosure)
    • Re: What is going on with my Dialup?
      ... also forward it to an unused port, and have that port provide the ... verses the RST or ICMP 3,3. ... The lack of response causes the remote computer to make ... Others think that by not responding to unwanted packets, ...
      (comp.os.linux.networking)
    • Re: OT .. Road Warrior communications question
      ... The data on the Internet is sent in little packets. ... The packets addressed to port 80 ... Likewise, at the mail server receiving the packets, it knows the return ... Why would e-mail work on the web but not from your e-mail software? ...
      (alt.guitar.bass)