('binary' encoding is not supported, stored as-is) In-Reply-To: <20020712230533.GA4862at_private> I believe the sender was receiving my responses, I'll explain why I believe that. Just before I was going to route the first one, I pinged and portscanned that IP, there were many services, a webserver, PCAnywhere and some other things. When I stopped returning packets to that IP, services started falling off, and "attacks" started from other IPs in the same net. For the record, I also tracerouted to see how much of their BW they were using, to see if this might have been directed towards many IPs at once, which might have been shown by a drastic change in return trip time from the offending machine to their backbone connection, I had 29 MS to their backbone router, and 30 MS to the offending IP, consistently. Given that and that they seemed to notice quickly when I stopped returning packets, A assume that they weren't doing a widespread "attack", probably some admin sitting around with too much time on his hands. After I noticed the first IP doing this for 2 full days, I captured a few packets and routed the offending IP to localhost, so I could still watch what they were trying to do. Within a few minutes of my not sending packets back to the supposed source, another IP appeared which was doing the same type of thing, my log was included in my original message to show the pattern. Shortly after that, more IPs popped up, doing the same type of thing, and after I routed those IPs off to local, within a short time, all "attacks" stopped. I have seen this same type of thing for a while, but they don't usually continue for very long, today's "attacker" is 66.192.45.84, who I routed to local to see how long it takes for them to notice. If my assumptions are close to being correct, the source IP saw my responses, which makes me think they have a use for the response itself, or are watching for a change in the response. I created a change by stopping the responses, which made them wonder if I firewalled them, which I did :) so they continued from another net. When I blocked them, one by one, they tried sending from many IPs at once, and eventually stopped, which makes me wonder: This originally went on for days before I stopped it. What use could my acks be to someone? Is this a DOS meant towards an FTP server? Or is it an exploit that I'm not aware of? I assume this is either a person with even less of a life that I have :) or a new exploit that I'm not aware of yet. Given that I see one or two similar to these on the short term per day, apparently coming from different unique places, I'm more inclined to think that this is a new exploit, and I'm still curious to see what you guys and gals think. TNX >On Thu, Jul 11, 2002 at 06:15:17PM -0400, Jason Giglio wrote: >> You are probably seeing backscatter from a DDoS attack. Someone is > probably spoofing your address as the source of the attack, > among a lot of others. That also explains why the server went > down eventually. Also the controversial political nature of the > site would make it a target of attack. > >> Just my guess. > > Bad guess. Wrong answer. Unless the data he's supplying is bogus. > > He is reporting port 21 SYNs. Now, unless they are SYN-ACKs, >there is no way on God's green earth for them to be backscatter. Why? >Because there is no TCP request packet that RESULTS in a SYN packet. >A SYN-ACK, yes. A SYN, no. Backscatter, by definition, are response >packets. SYN packets can not be response packets. Therefore SYN >packets can not be backscatter. > > For the record... The "darkside" / "blackhole" network I monitor >has received sporatic bursts of both FTP SYN (not SYN ACK) and FTP FIN >(which is probably stealth scanning) from several sites over the last >few days. Several are in Korea (over half). Some are not. I do >monitor for backscatter and, IMNSHO, have some pretty good filters >for discriminating between what is backscatter and what is direct >scanning (it's not that difficult). Backscatter is running pretty >low (from my view port) at the moment compared to flat out port scanning. > > BTW... As several of us have noted in the past, some "slow" >scans are, if you were at the source, "balls to the wall", "scan >the planet", scans with the address ordering arranged to minimize >the hits per day a (small) end network experiences. We've seen several >scans in which the scanner is running as fast as possible but is >incrementing through the address space in "octel reversed order" so >someone on a /24 only sees an occasional hit while someone like me >and others I colaborate with see faster hits on our /16 but the next >higher byte increments faster. Correlating with some of my "numerical >neighbors", it's rapidly obvious that the octet next up (the second >octet) is incrementing even faster. I'm sure Dug Song and a few of >the others with the high honor of access to the data from a fossile >/8 can attest to even more interesting patterns of activity. Correlating >that data with distributed sensor data where I work is consistent with >scans where the bytes are increments in reverse order and what appears >to be a slow scan is really an uncapped scan that is blazing away with >all barrels a blazing. So, slow or fast is a rather relative term. :-) > >> On 11 Jul 2002 02:41:08 -0000 >> Bubsy <pizzapoweredat_private> wrote: >> >> > >> > >> > I would like to pick your collective brains >> > regarding what I believe is an attack of some form, >> > even if it is very slow. I noticed a day and a half >> > worth of continuous port 21 SYNs. Because there were >> > never any completed connections, this would not show up >> > in the FTP logs, but I watch all traffic, maybe I need >> > a life :) . I noticed an unusual amount of FTP port >> > SYNs that I was acknowledging, which were being >> > ignored. One or more SYNs would come in at about the >> > same time, to which I would respond with three >> > acknowledgements per SYN and then quit. Many of these >> > incoming SYNs had the same checksum. Strange, maybe >> > forgery? ---------------------------------------------------------------------------- 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 : Sat Jul 13 2002 - 19:54:37 PDT