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.Sloraat_private> > To: "'Byrne Ghavalas'" <securityat_private>; > <incidentsat_private> > 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:securityat_private] >>Sent: Friday, December 13, 2002 5:06 AM >>To: incidentsat_private >>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
This archive was generated by hypermail 2b30 : Wed Dec 18 2002 - 17:52:44 PST