Consejos de Fyodor para comenzar en seguridad de redes, ya sea por diversion o por lucro

Esta es una traducción de la cuarta pregunta hecha en la entrevista a Fyodor (el creador de nmap) por el portal slashdot el 30 de mayo del 2003

4) Comenzando una carrera en seguridad de redes
por: Cobarde Anónimo

Me graduare este mes con un brillante pregrado en ciencias de la computación. He hecho abundante trabajo como administrador de sistemas unix en la universidad e incluso instale algunas honyenets de alta interacción. Estoy muy interesado en seguridad de redes y programación de sistema. Tienes algún consejo para gente en mi situación que quiere entrar en una carrera en seguridad de redes?

Fyodor

! Felicitaciones por tu graduación ¡ Desafortundamente (para los novatos), el campo de la seguridad es uno que a menudo espera sustancial experiencia y referencias. Esto es en parte por que estos trabajos requieres de extraordinaria confianza, y también por una aversión a los errores. Todos cometemos errores, pero estos puede ser extraordinariamente costosos en seguridad y los neófitos tienden a hacer la mayoría de ellos. Pero ¡ no pierdas la esperanza ! Mentes talentosas en seguridad aun están en muy alta demanda, solo se consiente que tendrás que trabajar aun mas fuerte  para probar que vales.

Estas son mis sugerencias para cualquiera comenzando en seguridad de redes, ya sea por diversión o por beneficios económicos:

Paso 1: Aprende todo lo que puedas

1. Puedes empezar  leyendo una descripción general de seguridad, como Practical Unix and Internet Security 3° Edicion

2. Solo leer no te enseñara mucho. La experiencia practica es critica, así que yo instalaría al menos una red básica de prueba. Como mínimo debes tener una o dos maquinas Unix y una maquina Windows (por que estas son las mas comunes en el mundo real). Puedes usar maquinas muy baratas, o incluso emular una gran red con software de virtualizacion como VMWare.

3. A continuación debes aprender mas sobre como se hacen los ataques. Échale una mirada al excelente y gratuito Open Source Security Testing Methodology Manual (OSSTMM) (Nota del traductor: El OSSTMM 2.1 esta disponible en español). El objetivo de este documento es proveer un marco global para pruebas de seguridad. Pero en su mayoría lista tareas para hacer, sin especificar como hacerlas. Ganaras mucho de este manual sí investigas las tareas que no sabes como hacer y sí intentas realizarlas en tu red de prueba. Sí este manual es demasiado conciso o difícil de seguir, puedes intentar un libro mas detallado en evaluación de vulnerabilidades, como Hacking Exposed 4° Edicion.(Nota del traductor: Hacking Exposed va en su sexta edicion y hace poco los creadores del OSSTMM publicaron Hacking Exposed Linux 3° edicion) 

4. Ahora que entiendes muchas de las ideas generales de seguridad, es hora de actualizarte. Esta es una área que se ha vuelto mas fácil en la ultima década. Se solía pensar que la información sobre vulnerabilidades solo debía distribuirse a bien conocidos y confiados administradores e investigadores en seguridad atreves de compendios privados como Zardoz. Esto fue un desastre por muchas razones, y nació el movimiento de divulgación total. En los últimos años las cosas han empezado a moverse hacia divulgación mas limitada ("responsable") y también hay un inquietante tendencia paga-dinero-por-divulgación-temprana. Pero la información todavia esta mucho mas disponible de lo que solía estarlo. La mayoría de las noticias son llevadas en listas de correo, y yo archivo las que considero son las mejores en lists.insecure.org. Debes suscribirte a Bugtraq, y yo también recomiendo altamente pen-test, vuln-dev, y security-basics.Lee al menos 6-12 meses de archivos. escoge otras listas que correspondan con tus intereses. SecurityFocus también ofrece una lista de trabajo de seguridad que es un excelente recurso para encontrar trabajos o solo entender lo que los empleadores desean. Hay 2 razones principales por las cual leer Bugtraq. Una es que debes reaccionar rápido a nuevas vulnerabilidades parchando tus servidores, notificando a tus clientes, etc. Puedes tener eso con simplemente revisar los asuntos o resúmenes de advisories por bugs que se apliquen directamente a ti. Pero entonces te perderías otro propósito crucial de Bugtraq. En realidad entender una vulnerabilidad te ayuda a defenderte de ella, explotarla, e identificar/prevenir bugs similares en el futuro. Cuando eres afortunado, el advisory por si mismo te dara detalles completos sobre el bug. Revisa este excelente advisory reciente de Core Security Technologies. Nota como ellos describen exactamente como funciona la vulnerabilidad Snort TCP Stream Reassembly con detalles he incluso incluyen una prueba de concepto como demostración. Desafortunadamente, no todos los advisories son tan agradables. Para bugs en Software de Fuentes Abiertas, puedes entender el problema leyendo el diff. El siguiente paso es escribir, probar y explotar. Te recomiendo escribir al menos uno de cada clase general de bug (buffer overflow, format string, SQL injection, etc) o siempre que un bug sea particularmente interesante.

Asegúrate de leer el ultimo numero de Phrack y los papers de investigación enviados a las listas de correo. Envia tus comentarios y preguntas a los autores y puedes empezar interesantes conversaciones. Lee los reconocidos libros en temas de seguridad que mas te interesen.

No puedo enfatizar lo suficiente que debes intercalar trabajo practico con toda esta lectura. Instala Redhat 8 sin parches(o lo que sea) y ejecuta Nmap y Nessus (Nota del traductor: si desea usar una alternativa libre mire openvas que se basa en la ultima version libre de Nesus) contra el. Luego comprometalo remotamente, talvez con el ultimo hueco de samba. Empieza con un explot pre-escrito de Bugtraq, lo cual no es tan facil como suena. Puede que tengas que modificar el 'sploit para que compile, aplicar fuerza bruta sobre el offset adecuado, etc. Entonces rompelo de nuevo usando una tecnica diferente, y tu propio exploit. Instala Ethereal (Nota del traductor: debido a problemas de marca registrada este proyecto cambio su nombre a Wireshark) y/o tcpdump y asegúrate de entender el trafico en tu red tanto en la explotación como en actividad normal. Instala Snort en una maquina conectada a internet y mira los ataques y prueba tu experiencia. Recorreo tu vecindario con Kismet, Netstumbler, o Wellenreiter en tu portátil o PDA buscando WAP abiertas. Instala DSniff y ejecuta un ataque MITM activo en una conexión SSH o SSL entre dos computadores. Mira mi top de las 75 herramientas y asegúrate de entender que hace cada una y cuando seria útil. Prueba tantas como puedas.

5. ! Tomate unas vacaciones, o al menos un fin de semana de campamento ¡ ! Te lo mereces ¡ Los pasos anteriores probablemente te tomen como mínimo de 3 a 12 meses tiempo completo, dependiendo de tu nivel de motivación y la profundidad y amplitud de tu investigación.


Ahora estoy cansado así que en otra entrada del blog hago el Paso 2: Ahora aplica tu conocimiento recién adquirido

Asfixia una novela de Chuck Palahniuk

 

SI VAS A LEER ESTO, NO TE MOLESTES.

Después de un par de paginas, no querrás estar acá. Así que olvídalo. Vete. Vete mientras todavia estas de una pieza. Sálvate. Tiene que haber algo mejor en la televisión. o dado que tienes tanto tiempo en tus manos, tal vez puedas tomar un curso nocturno. Convertirte en medico. Puedes hacer algo de ti. Llévate a cenar afuera. Píntate el cabello.No te estas haciendo mas joven.

Lo que pasa acá al comienzo va a encabronarte. Despues de eso solo se volverá peor y peor

Colombianos arriesgando sus vidas en la guerra de Afganistán

Recordando la histórica estupidez de haber enviado tropas a korea ahora Colombia las enviara a Afganistán que lastima que los militares arriesguen sus vidas por meros pactos políticos, que poco o nada tienen que ver con la seguridad de su nación.

 

Que lastima que personas que nunca en su vida han escuchado de un país tengan que ir allí a acabar con sus vidas y las de otros sin siquiera entender o detenerse a pensar que hacen desperdiciando su única vida a cambio de hacer sonreír a la potencia de turno.

Choke a novel by Chuck Palahniuk

IF YOU'RE GOING TO READ THIS, DON'T BOTHER.
After a couple pages, you won't want to be here. So forget it. Go away. Get out while you're still in one piece. Save yourself.
There has to be something better on television. Or since you have so much time on your hands, maybe you could take a night course. Become a doctor. You could make something out of yourself. Treat yourself to a dinner out. Color your hair.
You're not getting any younger.
What happens here is first going to piss you off. After that it just gets worse and worse.

Edición posterior: Para complacer a Ms. Davis hice una traduccion de esta entrada

La divertida y compleja tarea de publicitar bits invisibles

Si usted alguna vez considero que era complicado el mundo de la informática, que es una cosa extraña y que funciona por casualidad tema que hace dificil el trabajo de quienes estaban involucrados con ella, entonces hace falta que analice la posición de los pobres vendedores que deben ofrecer productos que su cliente no puede tocar y/o saber si resolverán o no sus problemas pero aun así son muy costosos

En el museo de la historia de la computación tienen una muestra bien interesante llamada selling the computer revolution que muestra como esta pobre gente ha intentado hacer publicidad de estas cajas feas y las cosas que se supone que llevan por dentro, entre estos hay 2 que me parecen de especial mencion.

PDP-11 Resource Timesharing System RSTS-11 1970

Las cajas esas del demonio no son atractivas, no te pueden llevar a incontables kilometros por hora y dificilmente te pueden hacer sentir mas masculino/femenino, asi que.... facil pongamos una mujer hermosa y ella hara el trabajo por nosotros, ella vendera el producto con su cuerpo.

¿ Ademas no da la impresion que el informativo morboso la mira de una forma obsena ?

Is Software Development Getting You Down? 1981

Tranquilo no se suicide, simplemente compre nuestro producto y el magicamente resolvera sus problemas

Actualización: 
Un interesante ejemplo de que no siempre hay que usar el cuerpo de mujeres,  el luchador Bret "The Hitman" Hart sosteniendo un diskette. Seguro que la mujer del fondo comprara lo que sea que el este vendiendo.

Las personas pesimistas e inteligentes que suelen ser las mismas

Estaba hablando un rato con manuelj sobre un monton de cosas cuando en algun momento me dio el enlace a la wikipedia sobre el Voluntary Human Extinction Movement y luego salio con una frase mas que perfecta "si y los que llegarian a eso son las personas pesimistas e inteligentes que suelen ser las mismas"

Por cierto, ya vieron Idiocracy?

Cerebro en una cubeta

"Usted no sabe que no es un cerebro, suspendido en una cubeta llena de líquido en un laboratorio, y conectada a un computador que lo alimenta con sus experiencias actuales bajo el control de algún ingenioso científico técnico (benévolo o maligno, de acuerdo a su gusto). Puesto que, si usted fuera un cerebro así, asumiendo que el científico es exitoso, nada dentro de sus experiencias podría revelar que usted lo es; ya que sus experiencias son, según la hipótesis, idénticas con las de algo que no es un cerebro en la cubeta. Como usted sólo tiene sus propias experiencias para saberlo, y esas experiencias son las mismas en cualquier situación, nada podría mostrarle cuál de las dos situaciones es la real.” (Introduction to Contemporary Epistemology, 10).

Realmente se encuentran cosas muy divertidas en la wikipedia: http://es.wikipedia.org/wiki/Cerebro_en_una_cubeta

Litigios sobre proyectos de software como evitarlos y que hacer en caso de

Estve leyendo el articulo Litigation Support for Software Intensive Projects de Tom DeMarco y Tim Lister(los de peopleware) y me encanto, basicamente dice:

Para evitar un litigio hay que:

• Hacer contratos que usted firmaria asi fuera el cliente o la empresa desarrolladora
• Conducir exaustivos y reflexivos analisis de requerimientos 
  
• Hacer un cuidadoso trabajo de medicion
• Enfocarse en buenas practicas de gestion
• Hacer una pequeña gestion del riesgo, solo por si acaso

 y si pese a todo su proyecto termina en litigio:

• Investigar y calibrar su proyecto con respecto a normas industriales como The Condensed Guide to Software Acquisition Best Practices pues la mejor defensa contra los ataques es demostrar que el rendimiento de la empresa es mejor que el de las normas industriales.
  

Pdt: En el enlace de The Condensed Guide to Software Acquisition Best Practices se pueden descargar otras guias sobre las mejores practicas en el software hechas por The Software Program Managers Network bajo el patrocinio del Departamento de Defensa de los Estados Unidos, precisamente ahora me encuentro disfrutando de una de estas guias, el Little Brown Book of Program Manager Bad Excuses (introduccion de Tom DeMarco)

Productividad en modificaciones al software

Yo siempre había pensado que era mas fácil y rápido hacer nuevos proyectos de software que modificar los antiguos pero leyendo PSP: A Self-improvement Process for Software Engineers me encontré con un par de citas con las cuales avalar mis impresiones.

"the productivity for software modification is often much slower than for new development"  Flaherty, M. J. "Programming Process Productivity Measurement System for System/370." IBM Systems Journal 24, no. 2 (1985): 168–175.

"an unpublished IBM study found that small code modifications were 39 times as error-prone as new development when measured in defects per modified LOC" - Managing the Software Process by Watts S. Humphrey

¿ Como evalar si un proyecto de software es exitoso o no ?

Si el gremio de los desarrolladores de software no esta de acuedo respecto a cuales son las prioridades, enfoques o que debe hacer un individuo en circunstancias especificas para cumplir con sus labores (Debates within software engineering) entonces ¿ como se puede diferenciar un proyecto con una mala ejecucion del que a tenido una buena ? ¿ Como 2 respetados autores de textos sobre el desarrollo de software como Ed Yourdon y Tom de Marco ofrecen sus servicios como expertos tecnicos en litigios sobre contratos de software y sobre que parámetros ellos definen si un contratista dejo de cumplir o no con sus obligaciones ?



¿ Sera que es tal el estado de la ingeniería de software como área del conocimiento que solo podemos decidir si un proyecto es exitoso o no, por criterios subjetivos ?

O acaso los criterios deben ser exageradamente generales y muy cercanos a la sola revisión sobre si se cumplieron las estimaciones iniciales de:

• Presupuesto


• Tiempo de Desarrollo
  
  


• Funcionalidad (Cantidad de cosas hechas)

Todo esto es lo que se me pasa por la cabeza cuando veo a ZettaByte diciendo en twitter: Necesito documentacion sobre malas practicas de implementacion de proyectos y desarrollo de software por que mirando las cosas desde alguna de las múltiples y contradictorias metodologías de desarrollo de software uno podría decir que falta o sobra determinado elemento para cumplir con ella, pero difícilmente tendría unas bases teóricas fuertes que sean reconocidas a lo largo de todo el gremio como para decir que el incumplimiento de esa practicas o de varias de ellas hace que el proyecto sea un fracaso.

Personalmente me quedo sin ideas pero el motivo detrás de esta entrada es esperar a que los lectores me den las suyas y/o repuestas contundentes a como hacer estas evaluaciones pues pese a llevar varios años en esto me declaro en la misma inquietud que ZettaByte