Re: Ideas? Port 21 SYNs, slow

["Buddy Nahay" <res0xhvr () verizon net>]

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" <pizzapowered () yahoo com>
To: <incidents () securityfocus com>
Sent: 13 July, 2002 14:57 PM
Subject: Re: Ideas? Port 21 SYNs, slow


> In-Reply-To: <20020712230533.GA4862 () alcove 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 <pizzapowered () yahoo 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