Yes, there are empty pings that accompany the proximity checks and ACKs that don't pass muster for state. I have not seen any 53>53 traffic associated with these, though. My traffic was all associated with visits from my network to the load balanced site. Thanks for the specifics about the Linkproof device. - Jim Kevin Bowman wrote Monday, December 16, 2002 1:54 PM > 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 archive was generated by hypermail 2b30 : Wed Dec 18 2002 - 19:38:10 PST