Hi Garrett,

There are two DOS attacks that I know of that use ACKS called stream.c and
raped.c, the stream.c sends ACK packets to the target with random sequence
numbers and source IP's.  The raped.c sends ACKs with spoofed source IP's
but I believe the sequence numbers are the same.

C
----- Original Message -----
From: "Garrett Allen" 
To: 
Sent: Sunday, October 27, 2002 3:14 AM
Subject: Re: ack attack or config prob? [7:56341]


> the filter doesn't like special characters.  sorry.  here is another try
> without the less than symbol:
>
> priscilla,
>
> the bursts were less than 2mins each in duration as i recall.  they
occurred
> sporatically through the day.  i have traces and i'll look for more
precise
> timeframes later tonite.  within each burst the packets were from the same
> ip address.  there were at least 2 unique non-contiguous ip addresses
> involved and 1 repeated a burst at least once that we tracked (i.e. at
least
> 2 bursts of 100k packets).
>
> the trace reveals acks and fin acks; no syn or syn ack's noted (my
reference
> to syn acks in the prior email was the only reference i could find on the
ms
> site that discussed their retry implementation, which could cause this if
it
> was unlimited).  firewalls are in place which is why i was going down the
> path of a misconfiguration on our servers.  in theory the firewall vendor
> states that the firewall is doing a stateful inspection and we did see
some
> evidence of packets being dropped at the firewall - but not all.  if the
> session was not previously opened the firewall should drop the ack and fin
> ack's as they are not a valid start of session transmission.  each burst
> contained the same sequence and ack numbers.
>
> i wondered at first if it was our servers that was initiating this
behavior
> pattern.  we did reboot the servers.  urban legend has it (i.e. my
neighbor
> has a friend whose wife's cousin said ...) that unexpected terminations of
> outlook web access can cause this kind of behavior to occur, but it is
just
> legend.  an examination of the trace doesn't point in that direction but i
> need to spend more time reviewing them.  and the problem reoccurred after
> the reboots.
>
> like i said i think it is an interesting issue because there are so many
> possibilities and it forces one to think about all the many things that
can
> go wrong.
>
> thanks for your insights and thoughtful questions.
>
> ----- Original Message -----
> From: "Garrett Allen"
> To:
> Sent: Saturday, October 26, 2002 9:59 PM
> Subject: Re: ack attack or config prob? [7:56341]
>
>
> > priscilla,
> >
> > the bursts were
> > To:
> > Sent: Saturday, October 26, 2002 7:40 PM
> > Subject: RE: ack attack or config prob? [7:56341]
> >
> >
> > > It sounds like you were under attack, though it's hard to say for
sure.
> I
> > > doubt that it's a misconfig on your end, though. It could be a
misconfig
> > at
> > > the other server, but probably not. I don't think you can set the
> > parameters
> > > that badly!? :-)
> > >
> > > It sounds like a DoS attack because of the volume of 100,000 packets.
> > What's
> > > the timeframe, though? You said "burst" so I assume pretty quick.
> > >
> > > Did the problem happen just once or has it reoccured?
> > >
> > > What do any relevant logs show? Do you have a firewall or Intrusion
> > > Detection System that logs info? How about the server itself? Does it
> show
> > > anything in its log?
> > >
> > > Were all the packets to the server?
> > >
> > > Were they ACKs or SYN ACKs? You mentioned both.
> > >
> > > Were they in response to something your server sent?
> > >
> > > Were they always the same ACK number?
> > >
> > > What were the port numbers? You mentioned e-mail, so were the packets
to
> > > port 25 for SMTP? SMTP implementations used to have many security
flaws.
> > > Hopefully those would be fixed in a modern OS, but you never know.
> > >
> > > Usually, DoS attacks are SYNs, but there are probably ones that use
ACKs
> > or
> > > SYN ACKs too. A search on Google might reveal more info.
> > >
> > > Anyway, I think you did the right thing by getting the ISP security
> folks
> > > involved. Keep us posted, unless they recommend that you keep it
quiet.
> > >
> > > _______________________________
> > >
> > > Priscilla Oppenheimer
> > > www.troubleshootingnetworks.com
> > > www.priscilla.com
> > >
> > > Garrett Allen wrote:
> > > >
> > > > heys,
> > > >
> > > > ran into something interesting today.  not sure if it is a dos
> > > > attack or if it
> > > > indicates an ip stack misconfig. here is the symptom:
> > > >
> > > > periodically through the day today we received 100,000 packet
> > > > bursts on a t-1
> > > > circuit.  this is a name-brand provider.  when the burst occurs
> > > > it is from the
> > > > same ip address.  on some bursts the packets are all acks.  on
> > > > others they are
> > > > all fin acks.  they are directed at our email servers.  when
> > > > they occur the
> > > > packets in a burst are all sourced from the same ip address.
> > > > in the one case
> > > > where we resolved the ip address back it was another orgs email
> > > > server.  based
> > > > on the router interface stats the traffic is coming from the
> > > > outside and is
> > > > not an internal broadcast storm.
> > > >
> > > > per the ms site, "A default-configured Windows NT 3.5x or 4.0
> > > > computer will
> > > > retransmit the SYN-ACK 5 times, doubling the time-out value
> > > > after each
> > > > retransmission."   if the same logic holds for other parts of
> > > > the handshake
> > > > then i'm at a loss to explain tens of thousands of packets
> > > > unless it is an
> > > > exploit of a weakness in the stack that allows for virtually
> > > > unlimited
> > > > retries.
> > > >
> > > > anyone run into this kind of situation before and was the
> > > > resolution a service
> > > > pack or other such server upgrade?  it caused considerable
> > > > slowness on
> > > > external accesses as you might imagine.  i grabbed a number of
> > > > traces
> > > > documenting it and we did contact our provider (they opened a
> > > > ticket with
> > > > their security folk).
> > > >
> > > > thanks.




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=56382&t=56341
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to