[HACK] Sobreviviendo a un ataque cracker

[Martin H Hoz-Salvador]

Sigo revisando cosas viejas (y depurando basura) de mi atascado correo.
Me encontré el texto que hasta abajo aparece. Se me hizo interesante, e
hice la traducción rápida, no-oficial y sin garantías... (Ni siquiera
he verificado el URL porque escribo esto offline :-p) - Anexo
tanto la traducción como el original.

Está un poco largo, pero creo que vale la pena. Espero les sirva.

-- M. Hoz 

--------------------------------------------------------------------------
Como Sobrevivir a un ataque de crackers
Noviembre 23, 1998
http://www.zdnet.com/windows/stories/prtfriendly/0,4758,2168256,00.html


Es tarde, usted duerme, y de pronto una llamada lo despierta... "Pedro,
estamos siendo atacados, alguien está intentando hacer una negación de
servicio en contra de nuestro web server". Usted rápidamente se da cuenta
de que demasiada gente no estará muy feliz con eso, así que salta a la
acción... después de todo, usted es el GURU de seguridad, ¿Cierto?

Así que, ¿Qué hacer sobre esta "alerta"?

Bien, para muchos, esto ya ha ocurrido y, para la mayor parte, ellos
han experimentado lo que estoy a punto de describir. Sin embargo, muchos
de ustedes que leen NTBugtraq y siguen las alertas de seguridad en la red
no hay experimentado esto aún... y es a ustedes a quienes quiero
dirigirme.

*N. del T.= Parece que el autor original colaboraba en NTBugtraq, no lo
            sé. Lo cierto es que www.securityfocus.com mantiene una buena
            base de listas que hablan sobre ataques y alertas, así
            como en español existen Una-al-día de Hispasec.com , la misma
            lista hacking at argo.es y mx-seguridad at seguridad.unam.mx

Usted ve que el número de veces que la alerta se suena, contra el número
de veces que un ataque actual tiene lugar, y se da cuenta de que es 
extremadamente desproporcionado. Usualmente, hay muchas posibilidades
de que usted no esté bajo ataque.

No me mal entienda, no estoy diciendo que los ataques no pasan- Sí
ocurren, especialmente a ISP's. La clave para responder a este tipo 
de alerta - la clave para determinar si usted realmente está bajo
ataque - es la mandera en cómo se manejen los hechos.

1. Usted conoce qué es lo que se supone que corre en la caja?

Asegurándose de que alguien le diga precisamente lo que se supone 
que está siendo ejecutado en la caja (servidor, workstation, ...)
es crucial para manejar la alerta. Sin este conocimiento, está en
la desventaja de no conocer si lo que se supone debería estar ahí
está ahí, o no. ¿Ha sido colocado "algo" ahí por atancantes? Conociendo
los números de versión correctos y nombres de los diferentes programas
ejecutables que están siendo ejecutados (o que podrían estar corriendo),
cuando ellos se supone que están corriendo, y qué hace cada uno de ellos,
es crucial para mantener el control de su servidor.

N. del T. = El término "caja" (box) es usado comúnmente para referirse
            a un equipo (servidor, cliente, dispositivo embebebido, etc...)

Y por supuesto, conociendo todo esto hará más fácil la tarea de buscar
a través de bases de datos de conocimiento, artículos y/o sitios de 
soporte del fabricante... pero no vaya ahí todavía.

2. ¿Tiene un respaldo?

Antes de que usted vaya a intentar detener un ataque, usted necesita
estar seguro de que puede recuperarse una vez que usted lo haga. Dado
que usted no conoce lo que el ataque haya hecho o no a su sustema,
suponiendo (lo más cerca posible) cuándo fué realizado el último respaldo,
y mas importante: qué tan útil puede ser, es crucial para determinar
cómo enfrentará usted a la alerta. Si usted sabe que usted tiene un
respaldo de justo antes de que la alerta aparecera usted podría, si
es necesario, remplazar completamente la caja. Eso hace que el ataque
del problema sea mas simple: Si usted tiene que eliminar o altear algo
sensible en el proceso, usted puede saber que puede acudir al respaldo
si todo lo demás falla. Si usted no tiene un respaldo razonablemente
actual, entonces usted tendrá que ser mucho mas cuidadoso en la forma
en cómo enfrenta el problema. Y usted tendrá que trabajar mas duro
para determinar exactamente lo que pudo haber sido cambiado debido a
la alerta - Mandar a la basura el sistema y hacer una recuperación
del respaldo (Restore) completo no será entonces una opción.

3. ¿Quién o quiénes descubrió(eron) la alerta? ¿Qué fué exactamente lo 
   que ellos descubrieron?

Es importante saber quién descubrió la alerta en el proceso de 
diagnóstico del problema, porque su conocimiento y experiencia podrían
afectar grandemente la validez de sus observaciones. No es por ser
duros, pero: ¿Saben ellos de lo que están hablando? ¿Deberían ellos
de tener la capacidad para ver la alerta? Si no, ¿Qué estaban ellos 
haciendo en la caja que les permitió descubrirla? La respuesta a esa
pregunta ha resuelto mas de una alerta con la que yo he lidiado (um,
ellos estaban urgando un poco en el registro y entonces de pronto 
ellos notaron que el CPU se fué al 100%... ;-])

Adicionalmente, lo que es alerta en sí puede ser altamente subjetivo. Es
decir que puede haber una diferencia entre lo que una persona piensa
que es el problema, y el problema en sí.  Todos nosotros hemos esuchado
algo similar a "está corriendo mucho mas lento de lo que usualmente
lo hace..." Solo para encontrar que lo que pasa es que estamos a la mitad
de un respaldo completo del sistema... ;-] Los medidores de performance
son complejos, y pueden ser fácilmente mal interpretados. Decir a alguien
que el número de "Intentos de conexión HTTP" está mas arriba de lo normal
no necesariamente significa que usted está bajo ataque. Especialmente si ellos
toman aquel valor de Perfmon y lo comparan con el valor "Hits" de un 
programa de estadísticas de web (cuando usted considera que un intento de
conexión no necesariamente es escrito en las bitácoras como un "hit" si 
la transferencia no fué exitosa).

Demasiada gente invierte poco tiempo analizando la alerta y verificándola 
por múltiples mecanismos - triste pero cierto. Hágalo: Analice y verifique.
Si usted piensa que está bajo un ataque de DOS, usted debiera:
  
   * Ejecutar Netmon y verificar si la utilización de la red está
constantemente
     a un nivel mas alto del normal. Y recuerde comparar su ancho de banda de
     la red local (LAN) con el ancho de banda de su conexión al ISP. Su
     utilización no debería ser capaz de soportar tasas mayores que las que
     permite su conexión a Intenet. Si lo está, entonces el ataque viene de 
     otra máquina en su LAN, o usted tiene algun otro problema causando la
     saturación.
*N. del T. = En el mundo UNIX, un equivalente de netmon "genérico" puede 
	ser netstat -in + ifconfig - Ellos muestran estadísticas de paquetes
        en el cable, errores, etc. Otro aliado es MRTG.

   * Verifique en "netstat -n l" y vea si tiene o no muchos intentos de 
     conexiones de la misma IP, o de IP's similares. Hay posibilidad de que
     un ataque DOS en curso venga de una sola dirección IP, o de un rango de
     IP's de una sola subred. Cuando sucedió el ataque TearDrop2 este año,
     la dirección fuente fué siempre la misma. A pesar de que estaba siendo
     suplantada ("spoofed") (Es decir, no venía de la dirección que aparecía),
     aún así era la misma dirección que aparecía repetidamente.

   * De una revisión a sus bitácoras del web. ¿Reflejan ellas el tráfico que
     usted ve? La red es un lugar divertido. Lo sé - Yo tuve una experiencia
     con mi Web site que me hizo considerar seriamente que tenía una alerta.
     Sucede que algo que escribí fué ligado (linked) desde el sitio Web
     de Microsoft, y el número de visitantes creció exponencialmente en
     cuestión de minutos.

Si los resultados de las verificaciones anteriores muestran algunas
inconsistencias, entonces usted puede asumir (como usualmente yo lo hago)
que alguien ha cambiado algo en la caja, y es lo que está causando el problema
¿Cuándo comenzó la alerta? ¿Alguien añadió o eliminó algo de la caja 
mas o menos a esa hora? ¿Qué hay de nuevo en la caja? ¿Es posible regresar
a lo que se tenía antes, y si es posible, aún así sigue ocurriendo el
problema? No puedo presionar aquí lo suficiente: Hay posibilidad de que
algo que usted (o su equipo) hicieron, sea la causa de su alerta. Muy
frecuentemente, un cambio en la caja es lo que causa que las cosas vayan
mal.

Por otro lado, todas las verificaciones se hicieroN y usted está convecido
de que está siendo atacado, ¿Ahora qué?


4. Contacte a su ISP
Si usted puede identificar una IP en paricular (o un rango de direcciones
de IP) como la raíz del problema que causó la alerta, entonces usted 
debiera contactar a su ISP y pedirle que filtre esa dirección en sus
routers. Por supuesto que usted puede filtrar la dirección maligna en sus
propios ruteadores, pero aquello hará amontonar un cerro de frijoles lo
más probablemente (¿?). Recuerde, el ancho de banda de su ISP a usted
es su ancho de banda - Aún así estará siendo consumido por el tráfico
del ataque mientras llega a su router para ser rechazado! Haciendo que
su ISP se involucre ayudará a evitar esta pérdida de ancho de banda, así
como mantener la seguridad de sus amigos andando. (¿?). ¡Un ataque contra
usted es también un ataque contra su ISP! Una vez que usted y su ISP
han cortado el ataque, usted buscará arreglar lo que pudiera haber
sido dañado (diga hola a sus respaldos) y parchando su caja.

Por supuesto que sobra decir que usted y su ISP deberían tener un plan 
antes de que un ataque ocurra. Hable con su ISP ahora y sepa por anticipado
qué es lo que harán en una situación así... Si ellos no tienen una 
respuesta: ¡Cambie su ISP!.

5. Registre todo lo que pueda.

Mientras que actualmente ir a la corte contra un atacante es extremadamente
raro, usted no estará en capacidad de hacer nada sin registros de el ataque.
Más allá, compañías como Network Flight Recorder (www.nfr.net) e ISS
Real Secure (www.iss.net), quienes hacen productos que pueden detectar 
firmas de ataques en la red, apreciarían mucho registros de eventos de
ataque actuales. La mas detallada información que pueda proveer a tales
fabricantes, mejor podrán ellos construir sus productos para combatir
dichos ataques.
*N. de T. = Hay que ver que iniciativas de software libre como SNORT
            (www.snort.org) hacen uso también de firmas de ataques para 
            determinar en tiempo real un ataque en curso.

6. ¡Hágamelo saber!

NTBugtraq está aquí para mantener al amigo de NT informado acerca de estos
ataques. El daño causado por Teardrop2, mientras que fué devastado para 
algunas gentes por un periodo de tiempo, fué limitado al menos en parte 
debido a nuestra habilidad para coordinar a mucha gente sobre el mismo 
problema... Virtualmente en tiempo real.
* N. de T. = Hoy en día el foro de INCIDENTS de SecurityFocus.com y el
             GIAC de SANS, parecen ser los puntos mas adecuados para
             compartir información sobre incidentes. En España, hacking
             y la lista de CERT-ES pueden ser buenos sitios para reportar.
             En México, GASU y MX-Seguridad son buenas alternativas.

Hay posibilidades de que si usted sigue estos pasos, su problema
sea resuelto. Recuerde:

  1. Conozca lo que está corriendo su caja (inventario)
  2. Mantenga respaldos frescos
  3. Verifique que el ataque es real
  4. Córtelo a nivel ISP
  5. Regístrelo
  6. Repórtelo

El fondo a todo esto es asegurirse de que se tiene un plan. Asegúrese que
usted sabe qué es lo que hará cuando reciba esa llamada a media noche.
En serio, cuando pasa, su corazón comienza a latir fuertemente y usted 
puede llegar a confundirse. Teniendo un plan, una lista de preguntas 
a realizar, una lista de cosas por hacer, y una lista de gente a la cual
llamar (¡con números!) ayudará a calmarlo un poco y permitirle tomar
el curso correcto de acciones para resolver el problema rápidamente.

----------------- Forwarded Message ----------------- 
Desde: 	mea culpa[SMTP:jericho at dimensional.com]
Enviado el: 	Sábado 28 de Noviembre de 1998 3:46 AM
Para: 	InfoSec News
Asunto: 	[ISN] How to Survive a Hack Attack  


http://www.zdnet.com/windows/stories/prtfriendly/0,4758,2168256,00.html

How to Survive a Hack Attack
November 23, 1998

Its late, you're sleeping, you get a call waking you . . .  "Fred, we're
being attacked, someone is trying to do a denial of service attack against
our web server". You quickly realize that lots of people aren't going to
be very happy, so you leap into action . . . after all, you're the
security GURU, right? 

So what do you do about this "alert"? 

Well, for many, this has already happened and, for the most part, they've
experienced what I'm going to describe. However, many of you who read
NTBugtraq and follow security alerts on the 'net haven't had it happen to
you yet . . . and it is you I'd like to talk to. 

You see the number of times the alert is sounded, versus the number of
times an actual attack occurs, is extremely disproportionate. Usually,
chances are you are not under attack. 

Don't get me wrong, I'm not saying attacks don't happen—they do,
especially to ISPs. The key to responding to this type of alert--the key
to determining if you're really under attack--is how you handle the facts. 

1. Do you know what's supposed to be running on the box?  

Making sure that someone can tell you precisely what's supposed to be
running on the box is crucial to handling an alert. Without this
knowledge, you're at a loss to know whether what's supposed to be there is
there. Has something been placed there by an attacker? Knowing the right
version numbers and names of the various executable programs that are
running (or could be running), when they're supposed to be running, and
what each of them actually does, is crucial to keeping control of your
server.

And of course, knowing all of this will make it easier to search through
Knowledgebase articles and/or vendor's support sites . . . but don't go
there yet. 

2. Do you have a backup? 

Before you go trying to stop an attack, you need to be sure you can
recover from it once you do. Since you don't know what the attack may or
may not have done to your system, figuring out when your last backup was
made, and more importantly how useful it might be, is crucial to
determining how to handle the alert. If you know you have a backup from
just prior to any indications of an alert you could, if necessary,
completely replace the box.  That makes attacking the problem easier:
Should you have to delete or alter something sensitive in the process, you
know you can go to the backup if all else fails. If you don't have a
reasonably up-to-date backup, then you'll have to be a whole lot more
cautious in your approach. And you'll have to work harder to determine
exactly what might have changed due to the alert—trashing the system and
doing a full "restore" won't be an option. 

3. Who discovered the alert? What exactly did they discover? 

Who discovered the alert is important in diagnosing the problem because
their knowledge and expertise could greatly affect the validity of their
observations. Not to be harsh, but: Do they know what they're talking
about?  Should they have been able to even see the alert? If not, what
were they doing on the box that allowed them to discover it? The answer to
that question has solved more than a few alerts I've dealt with (um, they
were just poking around the registry on that box and then all of a sudden
they noticed the CPU went to 100% . . . ;-]) 

Additionally, what the alert actually is can be highly subjective. That is
to say that there may be a difference between what the person thinks the
problem is and the problem itself. We've all likely heard the claim "its
running much slower than it usually does . . ." only to find out it
happens to be in the middle of a full system backup . . . ;-] Performance
counters are complex, and can easily be mis-read. Telling someone that the
number of "HTTP Connection Attempts" is way above normal doesn't
necessarily mean you're under attack. Especially if they take that Perfmon
value and compare it with a web statistics program's "Hits" value (when
you consider that a connection attempt doesn't necessarily get logged as a
hit if the transfer was unsuccessful). 

Too many people spend far too little time analyzing the alert and
verifying it by multiple mechanisms—sad but true. Do it: analyze & verify.
If you think you're under a DOS attack, you should: 

   * run Netmon and see whether network utilization is being sustained at a
     higher than normal level. And remember to compare your LAN bandwidth
     with that of your ISP connection. Your utilization shouldn't be able to
     sustain rates higher than your Internet connection allows. If it is,
     then the attack is either coming from another machine on your LAN, or
     you've got some other problem causing the saturation.
   * look at "netstat -n 1" and see whether or not you have a lot of
     connection attempts from the same, or similar, IP addresses. Chances
     are a DOS attack is going to come from a single IP address, or a range
     of addresses from a single subnet. When the Teardrop2 attack happened
     earlier this year, the source address was always the same. Despite it
     being spoofed (i.e. not from the address you actually saw), it was
     still the same address repeatedly.
   * Have a look at your web logs. Do they reflect the traffic you're
     seeing? The Net is a funny place. I know—I had a spike on my web site
     once that seriously made me consider it an alert. Turns out something I
     wrote had just been linked from Microsoft's web site and the viewers
     rose exponentially in a matter of minutes.

If the results of the above verifications show some inconsistencies, then
you can assume (as I usually do) that someone has changed something on the
box, and that it's causing a problem. When did the alert start? Did
someone add or remove something from the box around that time? What's new
on the box? Can you revert back to what you had before, and if you do,
does the problem still occur? I can't stress this enough: chances are
something you (or your team) did is the cause of your alert. More often
than not, it's a change to the box that's caused things to run afoul. 

If, on the other hand, all verifications check out and you're convinced
your being attacked, then what? 

4. Contact your ISP. 

If you can identify a particular IP address (or range of IP addresses) as
the root cause of the alert, you should contact your ISP and ask them to
filter out that address at their routers. Of course you could filter out
the offending address at your routers, but that'll amount to a hill o'
beans most likely. Remember, the bandwidth from your ISP to you is your
bandwidth—it will still be consumed by the attacking traffic as it comes
down to your router to be rejected! Getting your ISP involved should help
avoid this bandwidth loss, as well as set their security folks in motion.
An attack against you is also an attack against your ISP! Once you and
your ISP have cut off the attack, you're looking at fixing what ever was
damage (say hello to your backup) and patching you box. 

Of course it goes without sayting that you and your ISP should have a plan
in place before an attack occurs. Talk to your ISP now and find out what
they will do in such a situation . . . if they don't have an answer:
change your ISP! 

5. Log everything you can. 

While actually going to court against an attacker is extremely rare, you
won't be able to do anything without logs of the attack. Further,
companies like Network Flight Recorder (http://www.nfr.net) and ISS Real
Secure (http://www.iss.net), who make products that can detect attack
signatures on the wire, would greatly appreciate detailed logs of actual
attack events.  The more detailed the information you can provide to such
vendors, the more they'll be able to build products to combat such
attacks. 

6. Let me know about it! 

NTBugtraq is here to keep NT folk informed about such attacks. The damage
done by Teardrop2, while devastating to quite a few people for a short
period of time, was limited at least in part due to our ability to
coordinate lots of different people onto the same problem . . . virtually
in real time. 

Chances are, if you follow these steps, your problem will be resolved. 
Remember: 

  1. know what's running on your box
  2. keep current backups
  3. verify the attack as real
  4. cut it off at the ISP level
  5. log it
  6. report it

Bottom line to all of this is to make sure you have a plan. Make sure you
know what you're going to do when/if you should ever get that call in the
middle of the night. Trust me, when it happens, your heart is going to
start pumping and you're going to be scrambling. Having a plan, a list of
questions to ask, a list of things to do, a list of people to call (with
numbers!) will help calm you down and let you take the right actions to
resolve it quickly.