I am also receiving something similar, after reading this thread I noticed the following in my system logs. [**] spp_stream4: STEALTH ACTIVITY (SYN FIN scan) detection [**] 07/14-12:01:12.488358 61.220.166.204:21 -> 4.62.68.160:21 TCP TTL:22 TOS:0x0 ID:39426 IpLen:20 DgmLen:40 ******SF Seq: 0x74CEB8FE Ack: 0x748CEEB Win: 0x404 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ [**] spp_stream4: STEALTH ACTIVITY (SYN FIN scan) detection [**] 07/14-13:22:23.606072 61.220.166.204:21 -> 4.62.68.160:21 TCP TTL:22 TOS:0x0 ID:39426 IpLen:20 DgmLen:40 ******SF Seq: 0xAEA6C78 Ack: 0x138F638F Win: 0x404 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ [**] spp_stream4: STEALTH ACTIVITY (SYN FIN scan) detection [**] 07/14-13:35:33.997851 61.220.166.204:21 -> 4.62.68.160:21 TCP TTL:22 TOS:0x0 ID:39426 IpLen:20 DgmLen:40 ******SF Seq: 0x3E36EFC3 Ack: 0x13EE38CB Win: 0x404 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ [**] spp_stream4: STEALTH ACTIVITY (SYN FIN scan) detection [**] 07/14-14:59:56.920424 61.220.166.204:21 -> 4.62.68.160:21 TCP TTL:22 TOS:0x0 ID:39426 IpLen:20 DgmLen:40 ******SF Seq: 0x572677AB Ack: 0x716D6B6D Win: 0x404 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ bash-2.05# nslookup 61.220.166.204 Server: vnsc-pri.sys.gtei.net Address: 4.2.2.1 Name: 61-220-166-204.HINET-IP.hinet.net Address: 61.220.166.204 the only probes from this IP address were to port 21. Regards, Buddy Nahay n a h a y DOT b g AT v e r i z o n DOT n e t ----- Original Message ----- From: "Bubsy" <pizzapoweredat_private> To: <incidentsat_private> Sent: 13 July, 2002 14:57 PM Subject: Re: Ideas? Port 21 SYNs, slow > 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 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 : Mon Jul 15 2002 - 08:26:41 PDT