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" <pizzapoweredyahoo.com>
To: <incidentssecurityfocus.com>
Sent: 13 July, 2002 14:57 PM
Subject: Re: Ideas? Port 21 SYNs, slow

> In-Reply-To: <20020712230533.GA4862alcove.wittsend.com>
>
> 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 <pizzapoweredyahoo.com> 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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]