blog

Uno de los principales objetivos de un proceso para realizar respuesta de incidentes, es remover o eliminar de manera efectiva la amenaza dentro del entorno de cómputo correspondiente a la organización afectada, mientras al unísono se minimizan los daños, además de restaurar las todas las operaciones normales tan rápido como sea posible. Esta meta es realizada a través de dos actividades principales, investigar y remediar. A continuación se detalla lo incluido en estas dos actividades principales.

• Investigar
  • Determinar el vector de ataque inicial
  • Determinar el malware y herramientas utilizadas
  • Determinar cuales sistemas fueron afectados, y como
  • Determinar lo realizado por el atacante (evaluación de daños)
  • Determinar si el incidente continua
  • Establecer el lapso de tiempo del incidente
• Remediar
  • Utilizar la información obtenida desde la investigación, desarrollar e implementar un plan de remediación

Un incidente de seguridad en computadoras ocurrirá en algún momento de manera inesperada, y se debe estar preparado para afrontarlo.

Fuentes:

https://www.infosec.gov.hk/english/business/sihc_1.html

Al definir un incidente de seguridad en computadoras, se establece el alcance de lo hecho por el equipo y el enfoque proporcionado. Es importante establecer esta definición, de tal manera todos entiendan las responsabilidades del equipo. Si aún no se tiene uno, se debe crear un definición del significado de “incidente de seguridad en computadoras”, para la organización. No existe una única definición aceptada, pero se puede considerar un incidente de seguridad en computadoras implica cualquier evento con las siguientes características:

• Intención de causar daño
• Fue realizado por una persona
• Involucra un recurso de computo

Al analizar estas características. Las primeras dos son consistentes con muchos tipos de incidentes comunes no tecnológicos, como incendios provocados, robos y asaltos. Si no existe la intención de causar daño, es difícil denominar a un evento un incidente. Se debe tener en consideración puede no haber daños inmediatos. Por ejemplo, realizar un escaneo de vulnerabilidades con la intención de utilizar los resultados maliciosamente, esto no causa un daño detectado de inmediato. La tercera característica, requiriendo una persona involucrada, excluye eventos como fallas aleatorias en el sistema, o factores más allá de nuestro control, como el clima. El hecho de un firewall esté inactivo debido a un corte de energía eléctrica, no es necesariamente un incidente, a menos una persona lo cause, o se aproveche de hacer algo para lo cual no estaba autorizado.

La característica final es lo que hace al incidente un incidente de seguridad en computadoras: el evento involucra un recurso de cómputo. Se utiliza el termino “recurso de cómputo” porque existe una amplia gama de tecnologías de cómputo encajando en esta categoría. Algunas veces los recursos de cómputo tienden a pasar desapercibidos, elementos como medios de respaldo, teléfonos, impresoras, tarjetas de acceso a edificios, tokens de doble factor, cámaras, dispositivos de automatización, dispositivos GPS, tabletas, televisores, y muchos otros. Los dispositivos de cómputo están en todos lados, y algunas veces se olvida cuanta información se almacena en estos, que controlan, y hacia donde están conectados.

Puede no estar claro cual evento es un incidente hasta alguna respuesta inicial sea realizada. Eventos sospechosos deben ser vistos como potenciales incidentes, hasta probarse lo contrario. Por el contrario, una investigación puede descubrir evidencia la cual muestre un incidente no fue realmente un verdadero invidente de seguridad.

Algunos ejemplos de incidentes de seguridad por computadora son:

• Robo de datos, incluido información personal confidencial, correos electrónicos y documentos
• Robo de fondos, incluyendo acceso bancario, tarjetas de crédito, y fraude electrónicos
• Extorsión
• Acceso no autorizado hacia recursos de cómputo
• Presencia de malware, incluyendo herramientas para acceso remoto y spyware
• Posesión de materiales ilegales, o no autorizados

El impacto de estos incidentes podría abarcar desde deber reconstruir algunas computadoras, invertir una gran cantidad de dinero en la remediación, hasta la disolución completa de la organización. Las decisiones tomadas, antes, durante y después de la ocurrencia del incidente, afectará directamente el impacto.

Fuentes:

https://www.itu.int/en/ITU-D/Cybersecurity/Documents/Computer%20Inciden…
https://www.giac.org/paper/gsec/3907/introduction-computer-security-inc…

Una respuesta de incidentes es un enfoque coordinado y estructurado para ir desde la detección del incidente hasta la resolución. La respuesta de incidentes puede incluir actividades para:

• Confirmar si el incidente ocurrió o no
• Proporcionar una rápida detección y contención
• Determinar y documentar el alcance del incidente
• Prevenir una respuesta desunida o no cohesiva
• Determinar y promover hechos e información real
• Minimizar la interrupción de las operaciones de la empresa y de la red
• Minimizar el daño hacia la organización comprometida
• Restaurar las operaciones normales
• Gestionar la percepción pública del incidentes
• Permitir acciones civiles o penales contra los perpetradores
• Educar a la alta gerencia
• Mejorar la postura de seguridad de una entidad comprometida contra futuros incidentes

Las actividades y los miembros del equipo quienes son parte de la respuesta de incidentes, podría variar según las metas de la respuesta de incidentes. Las metas de una respuesta de incidentes puede variar dependiendo de factores tales como la severidad del incidente, las necesidades de las victimas, la metodología para la respuesta de incidentes de la victima, el momento del incidente, la intención del grupo de ataque involucrado en el compromiso (si se conoce), la industria o clientes impactados, y el soporte ejecutivo para la respuesta de incidentes.

En general, la respuesta de incidentes consiste en un equipo de investigación el cual determina lo ocurrido y realizar una evaluación de daños, un equipo de remediación quien elimina al atacante del entorno y mejora la postura de seguridad de la victima, además de alguna forma de relaciones públicas (con la gerencia de nivel superior, empleados interior, socios comerciales o el público).

Fuentes:

https://csrc.nist.gov/glossary/term/security-incident

El CSRC (Computer Security Resource Center) o traducido al idioma español Centro de Recursos en Seguridad de Computadoras, de la NIST (National Institute of Standards and Techonology), define tanto eventos e incidentes en una publicación especial SP-800-61 (Computer Security Incident Handling Guide), o traducido al idioma español “Guía para el Manejo de Incidente en Seguridad de Computadoras”. Mientras un evento se describe simplemente como “cualquier ocurrencia observable en un sistema o red”, un incidente es definido como “violación o amenaza de las políticas de seguridad en computadoras, políticas aceptables de uso, o prácticas estándar de seguridad”.

Un gran número de agencias del gobierno, organizaciones asociadas, contratistas, y empresas de soporte, tienen departamentos de TI, los cuales se basan en las directrices NIST para políticas internas. Aunque es importante notar la existencia de estas definiciones, ya sea se apliquen o no a la organización, para nuestros propósitos no describen lo suficiente las variadas facetas técnicas de los potenciales incidentes.

Desde la perspectiva de la respuesta de incidentes, se define un incidente de seguridad en computadoras como; “cualquier acción ilegal no autorizada o acción inaceptable, la cual involucra un sistema de computadora o red de computadoras”. Algunos ejemplos de esto son; el robo de secretos comerciales, el correo electrónico no deseado, intrusiones no autorizadas o ilegales en los sistemas informáticos, y malversación de fondos.

Esta es una buena definición. Sin embargo la industria ha cambiado y la definición de un “incidente” necesita cambiar también. Una definición ampliada es; “cualquier acción ilegal no autorizada o inaceptable, la cual implique un sistema de cómputo, teléfono celular, tableta, o cualquier dispositivos electrónico, con un sistema operativo o el cual opere sobre una red de computadoras”. Esta definición expandida es necesaria debido a la naturaleza interconectada del mundo actual. Automóviles, televisiones, xboxes, e incluso refrigeradoras y tostadoras, ahora tienen la capacidad de conectarse hacia Internet. Esto significa todos estos dispositivos son ahora objetivos potenciales para los cibercriminales.

Fuentes:

https://csrc.nist.gov/
https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
https://www.law.cornell.edu/uscode/text/18/1030
https://www.justice.gov/criminal-ccips/ccips-documents-and-reports

OWASP Juice Shop es probablemente la aplicación web insegura más moderna y sofisticada. Puede ser utilizada en entrenamientos de seguridad, demostraciones para concientización, CTF (Capture The Flag), y para probar herramientas de seguridad. Juice Shop se alinea completamente con los riesgos de seguridad o vulnerabilidades presentadas en el OWASP Top 10, además de otras fallas de seguridad encontradas en las aplicaciones web del mundo real.

Juice Shop ha sido escrio en Node.js, Express y Angular. Es la primera aplicación escrita completamente en JavaScript, siendo listado en el OWASP VWA Directory.

La aplicación contiene un vasto número de retos para hacking de dificultad variable, donde el usuario debe explotar las vulnerabilidades subyacentes. El proceso de hacking es rastreado en un tabla de puntuación. Encontrar este tablero de puntuación es de hecho uno de los retos (fáciles).

Aparte de los casos de uso para entrenamiento de concientización y hacking, los proxies para pruebas de penetración o escáneres de seguridad, pueden utilizar Juice Shop para verificar cuan bien las herramientas se comportan frente a aplicación frontales JavaScript y REST API.

Características

Entre sus principales características se enumeran:

• Libre y de fuente abierta: Licenciado bajo la licencia MIT sin costos ocultos ni advertencias
• Fácil de instalar: Seleccionar entre node.js, Docket, y Vagrant para ejecutarse en Windows/Mac/Linux
• Autónomo: Dependencias adicionales están previamente empaquetas o se resolverán y descargarán automáticamente
• Auto-reparación: Bases de datos simples SQLite y MarsBD se borran y repoblan desde cero en cada inicio del servidor
• Gamificación: La aplicación notifica sobre los retos resueltos, y realiza un seguimiento de las vulnerabilidades explotadas exitosamente en un tablero de puntuación
• Cambio de marca: Totalmente personalizable en el contexto comercial y apariencia según requerimientos corporativos o de cliente
• Soporte CTF: Las notificaciones de los retos opcionalmente contienen un código bandera para eventos CTFs propios

Arquitectura de la Aplicación

Traducir “dump” o “useless outfit” en alemán es “Softladen”, lo cual se puede traducir de forma inversa palabra por palabra en “tienda de jugos”. De allí el nombre del proyecto. Es una coincidencia las iniciales “JS” coincidan con “JavaScript”.

Fuente:

https://owasp.org/www-project-juice-shop/
https://en.wikipedia.org/wiki/Capture_the_flag
https://owasp.org/www-project-vulnerable-web-applications-directory

Obtener la huella del Framework web es una tarea importante correspondiente al proceso de captura de información. El conocer el tipo de framework puede automáticamente proporcionar una gran ventaja si tal framework ha sido ya probado por un profesional en pruebas de penetración. No son únicamente las vulnerabilidades en versiones no parchadas, sino malas configuraciones específicas en el framewok, y una estructura de archivos conocida, lo cual hace importante un proceso para reconocer la huella.

Diferentes proveedores y versiones de frameworks son ampliamente utilizados. La información sobre estos ayuda significativamente en el proceso de pruebas, y también puede ayudar en cambiar el curso de la prueba. Tal información puede ser derivada por un cuidadoso análisis de ciertas ubicaciones comunes. Muchos de los frameworks web tienen diversos marcadores en estas locaciones, lo cual ayuda al atacante a detectarlos. Esto es básicamente lo hecho por las herramientas automáticas, buscan por un marcador desde una locación específica, y luego la comparan con una base de datos de firmas conocidas. Para una mejor precisión se utilizan generalmente varios marcadores.

Anotación: En el presente texto no se diferencia entre una Framework de Aplicación Web, y Sistema Gestor de Contenido. Esto se ha hecho así para sea conveniente obtener ambas huellas. Además ambas categorías están referidos como frameworks web.

Objetivos de la Prueba

Definir el tipo de framework web utilizado, de tal manera se tenga un mejor conocimiento de la metodologías para pruebas de seguridad.

Como Evaluar

Prueba de Caja Negra

Existen muchas locaciones comunes a mirar para poder definir el framework utilizado.

• Cabeceras HTTP
• Cookies
• Código fuente HTML
• Archivos y carpetas específicas
• Extensiones de archivos
• Mensajes de error

Cabeceras HTTP

La forma más básica para identificar un framework web es buscar en el campo “X-Powered-By” de la cabecera de respuesta HTTP. Muchas herramientas pueden ser utilizadas para obtener la huella. La más simple es la utilidad netcat.

Considerar la siguiente cabecera de respuesta HTTP.

Del campo “X-Powered-By”, se conoce el framework de aplicación web es probable sea PHP. Sin embargo, aunque esta perspectiva es simple y rápida, esta metodología no funciona en el 100% de los casos. Es posible fácilmente deshabilitar la cabecera “X-Powered-By” mediante una configuración adecuada. Existen muchas técnicas las cuales permiten a un sitio web ofuscar las cabeceras HTTP.

Algunas veces puede existir más de una cabecera HTTP, la cual apunte hacia un cierto framework web. Se podría ver por ejemplo una cabecera como la anterior, y una cabecera “X-Generator”, la cual apunte a otro framework utilizado como “Swiftlet”, lo cual podría ayudar al profesional en pruebas de penetración a expandir los vectores de ataque. Cuando se realice un reconocimiento de la huella, siempre se debe cuidadosamente inspeccionar cada cabecera HTTP por exposición de información.

Cookies

Otra manera similar y algo más fiable para determinar el framework web utilizado son las Cookies específicas a un framework.

Considerar la siguiente cabecera de respuesta:

La cookie de nombre “PHPSESSID” es automáticamente definida, lo cual proporciona información sobre el framework en uso. Las limitaciones son las mismas, es posible cambiar el nombre de la cookie.

Sin embargo estos cambios son menos probables comparados con los cambios hecho a la cabecera “X-Powered-By”, de tal manera esta perspectiva se considera más fiable.

Código fuente HTML

Esta técnica se basa en encontrar ciertos patrones en el código fuente de la página HTML. Frecuentemente se puede encontrar mucha información la cual ayuda al profesional en pruebas de penetración y hacking ético a reconocer rápidamente un framework web específico. Uno de los marcadores más comunes son los comentarios HTML, los cuales exponen directamente información del framework. Pueden ser encontrados rutas específicas a ciertos framework, enlaces hacia carpetas css o js específicas a un framework. Finalmente variables script específicas podrían también apuntar hacia un cierto framework.

Más frecuentemente tal información es puesta entre las etiquetas head > y / head>, en etiquetas meta > o al final de la página. Sin embargo, se recomienda verificar todo el documento, pues esto puede ser útil para otros propósitos, tales como inspección de otros comentarios útiles o campos ocultos. Algunas veces los desarrolladores web no tienen cuidado sobre ocultar información del framework utilizado. Siendo posible toparse con información muy específica.

Archivos y carpetas específicos

Los archivos y carpetas específicos son diferentes para cada framework. Se recomienda instalar el correspondiente framework durante una prueba de penetración, para poder tener un mejor conocimiento de cual es la infraestructura presentada, y cuales archivos podrían ser dejados en el servidor. Sin embargo, ya existen varias buenas listas de archivos, y un buen ejemplo son las listas de palabras de “FuzzDB”, conteniendo nombres de archivos o carpetas predecibles.

Extensiones de archivos

Una URL puede incluir extensiones de archivos. Las extensiones de los archivos pueden también ayudar a identificar la plataforma web o tecnología. Por ejemplo si se utiliza PHP.

Algunas extensiones web comunes y tecnologías:

• php - PHP
• aspx - Microsoft ASP.NET
• jsp - Java Server pages

Frameworks Comunes

Cookies:

Framework y nombre de la cookie

Zope - zope3
CakePHP - cakephp
Kohana - kohanasession
Laravel - laravel_session

Código fuente HTML:

Marcadores generales

powered by
built upon
running

Marcadores específicos

Framework y palbraclave

Adobe ColdFusion - <! -- START headerTags.cfm>
Microsoft ASP.NET - __VIEWSTATE
ZK - < !-- ZK
Business Catalyst - <! – bC_OBNW -- >
Indexhibit – ndxz-studio

Herramientas

A continuación se presentan algunas herramientas conocidas. Existen también otras utilidades, como también herramientas para obtener la huella del framework.

WhatWeb

Es actualmente una de las mejores herramientas para obtener la huella. Está incluida por defecto en Kali Linux. Las correspondencias para las huellas se realizan con:

• Cadenas de texto (sensible a mayúsculas)
• Expresiones regulares
• Consultas a bases de datos de Google Hacking (Conjunto limitado de palabras clave)
• Hashes MD5
• Reconocimiento de URL
• Patrones de etiquetas HTML
• Código Ruby personalizado para operaciones pasivas y agresivas

A continuación se presenta una imagen de la herramienta.

Wappalyzer

Wapplyzer es un plugin para Chrome y Firefox. Funciona únicamente encontrando coincidencias con expresiones regulares, y no se necesita hacer nada más a cargar una página web en el navegador. Funciona completamente a nivel del navegador, y proporciona resultados en la forma de iconos. Aunque algunas veces tiene falsos positivos, es muy útil para tener una noción de cuales tecnologías son utilizadas para construir un sitio web, inmediatamente después de cargar una página.

Una imagen de ejemplo se presenta a continuación.

Fuentes:

https://www.owasp.org/index.php/Fingerprint_Web_Application_Framework_(…
https://www.php.net/manual/en/function.session-id.php
https://github.com/fuzzdb-project/fuzzdb
http://www.morningstarsecurity.com/research/whatweb
https://www.wappalyzer.com/

No existe una respuesta a la pregunta sobre como asegurar Kali Linux. Todo esto depende de como se lo utilizará, y aquello lo cual se está intentando proteger.

En el Servidor

Si se ejecuta Kali Linux en una servidor públicamente accedible, es más probable se requiera asegurar los servicios de red, cambiar las contraseñas por defecto configurada, y posiblemente también restringir el acceso con un firewall. Si se gestionan cuentas ya sea directamente en el servidor o en uno de los servicios, se debe asegurar definir contraseñas fuertes (para resistir ataques por fuerza bruta). Al mismo tiempo, es posible se requiera configurar “fail2ban”, lo cual hará mucho más difícil la fuerza bruta de contraseñas sobre la red (filtrando las direcciones IP excediendo el limite de intentos fallidos de login). Se puede instalar “fail2ban” con el comando “apt-update”, seguido por “apt install fail2ban”. Si se ejecuta servicios web, probablemente se requerirá alojarlos sobre HTTPS, para prevenir intermediarios en la red puedan husmear el tráfico (lo cual podría incluir cookies de autenticación).

En una Laptop

La laptop del profesional en pruebas de penetración está sujeta al mismo riesgo de un servidor público: por ejemplo, es menos probable esté sujeto a escaneos aleatorios de script kiddies, e inclusive cuando se esté, probablemente no se tendrá ningún servicio de red habilitado. El riesgo real frecuentemente surge de viajar de un cliente a otro. Por ejemplo, la laptop podría ser robada mientras se viaja o confiscada por una aduana. Esta es la razón por la cual se requiere utilizar el cifrado completo del disco, y posiblemente también se requiera definir la funcionalidad “nuke”: los datos recopilados durante las evaluaciones son confidenciales y requieren la máxima protección. También se puede necesitar reglas del firewall, pero no para el mismo propósito del servidor. Es posibles se requiera prohibir todo el tráfico saliente excepto el tráfico generado por el acceso VPN. Esto se entiende como una red segura, de modo cuando la VPN no funcione, inmediatamente se notará (en lugar de recurrir al acceso de red local). De esta manera no se divulgará las direcciones IP de los clientes cuando se navega la web o se realizan otras actividades en línea. Además, si se está realizando una evaluación local interna, es mejor permanecer en control de todas las actividades para reducir el ruido creado sobre la red, lo cual puede alertar al cliente y sus sistemas de defensa.

Fuentes:

https://www.kali.org
https://www.kali.org/download-kali-linux-revealed-book/
https://www.fail2ban.org/wiki/index.php/Main_Page
https://gitlab.com/kalilinux/packages/cryptsetup-nuke-password

No es práctico discutir sobre seguridad a grandes rasgos, pues la idea representa un amplio rango de conceptos, herramientas, y procedimientos; ninguno de los cuales se aplica universalmente. Seleccionar entre estos requiere una idea precisa de cuales son las metas. El asegurar un sistema inicia respondiendo algunas preguntas. El correr precipitadamente para implementar un conjunto arbitrario de herramientas tiene el riesgo de enfocarse en los aspectos incorrectos de la seguridad. Usualmente es mejor determinar una meta específica. Una buena perspectiva para ayudar con esta determinación, es iniciar con las siguientes preguntas:

• ¿Qué se está tratando de proteger?. La política de seguridad será diferente dependiendo de aquello lo cual se requiere proteger, ya sea computadoras o datos. En el último caso también se necesita conocer cuales datos.
• ¿Contra que se está tratando de proteger. ¿Es una fuga de datos confidenciales? ¿Perdida accidental de datos? ¿Pérdida de ingresos causado por una interrupción del servicio?.
• También. ¿Contra quien se está intentando proteger?. Las medidas de seguridad podrían ser bastante diferentes para protegerse contra un error tipográfico de un usuario regular del sistema, versus protegerse de un determino grupo de atacantes externos.

El término “riesgo” es utilizado habitualmente para referirse de manera colectiva a estos tres factores: que proteger, que debe ser prevenido, y quien podría hacer esto ocurra. Modelar el riesgo requiere responder a estas tres preguntas. Desde este modelo de riesgo, una política de seguridad puede ser construida, y la política puede ser implementada con acciones concretas.

También vale considerar restricciones adicionales, pues pueden restringir el rango de políticas disponibles. ¿Hasta donde se está dispuesto llegar para asegurar un sistema?. Esta pregunta tiene un impacto importante sobre cual política implementar. Con demasiada frecuencia, la respuesta solo se define en terminos de costo monetarios, pero también se deben considerar otros elementos, como la cantidad de inconvenientes impuestos a los usuarios del sistema o degradación del desempeño.

Una vez el riesgo ha sido modelado, se puede comenzar a pensar sobre diseñar una política real de seguridad. Existen extremos los cuales pueden entrar en consideración al decidir el nivel de protecciones de seguridad a adoptar. De otro lado, puede ser extremadamente simple proporcionar seguridad básica del sistema.

Por ejemplo, si el sistema a ser protegido únicamente comprende una computadora de segunda mano, cuyo único uso es añadir unos pocos número al final del día, decidir no hacer nada especial para protegerlo podría ser bastante razonable. El valor intrínseco del sistema es bajo, y el valor de los datos son cero, pues no están almacenados en la computadora. Un potencial atacante infiltrándose en este sistema podría únicamente ganar una calculadora. El costo de asegurar tal sistema podría probablemente ser mayor comparado al costo de una brecha.

En el otro lado del espectro, se podría requerir proteger la confidencialidad de datos secretos de la manera más completa posible, superando cualquier otra consideración. En este caso, una respuesta apropiada sería la destrucción total de los datos (borrar de manera segura los archivos, triturar los discos duros, para luego disolver sus restos en ácido, etc.). Si existe un requisito adicional de los datos deban mantenerse almacenados para uso futuro (aunque no necesariamente disponibles),y si el coso no es un factor, entonces un punto de partida podría ser almacenar los datos en una aleación de placas de iridio y platino, almacenadas en bunkeres a prueba de bombas debajo de varias montañas en el mundo, cada una de las cuales (por supuesto) es completamente secreta, y vigilada por ejércitos completos.
Aunque estos ejemplos podrían parecer extremos, serían una respuesta adecuada para definir ciertos riesgos, en la medida son el resultado de un proceso de pensamiento el cual tiene en consideración, las metas a alcanzar y las limitaciones a cumplir. Cuando se trata de una decisión razonada, ninguna política de seguridad es más o menos respetable comparada a otra.

De vuelta al caso más típico, un sistema de información puede ser segmentado dentro de subsistemas consistentes y en su mayoría independientes. Cada subsistema tendrá sus propios requerimientos y limitaciones, además la evaluación del riesgo y el diseño de la política de seguridad debe realizarse por separado. Un buen principio a tener en consideración es una pequeña superficie de ataque es más fácil de defender a una grande. La red de la organización también debe diseñarse en consecuencia: los servicios sensibles deben estar concentrados en un número pequeño de máquinas, y estas máquinas deben únicamente ser accedibles mediante un número mínimo de caminos o puntos de verificación. La lógica es sencilla: es más fácil proteger estos puntos de control comparado con proteger todas las máquinas sensibles contra todo el mundo exterior. Es en este punto la utilidad del filtrado de red (incluyendo firewalls) se vuelve evidente. Este filtrado puede ser implementado con hardware dedicado, pero una solución simple y más compleja es utilizar un firewall software, como el integrado en el kernel de Linux.

Fuentes:

https://www.kali.org
https://www.kali.org/download-kali-linux-revealed-book/

Aunque Kali Linux se esfuerza en seguir la política de Debian siempre sea posible, existen algunas áreas donde se hicieron decisiones de diseño significativamente diferentes, debido a necesidades particulares de los profesionales en seguridad.

Único Usuario Root por Defecto

Muchas distribuciones Linux fomentan, con bastante sensibilidad, el uso de una cuenta no privilegiada cuando se ejecuta el sistema, y el uso de una utilidad como “sudo” cuando se necesiten privilegios administrativos. Este es un buen consejo de seguridad, proporcionando una capa extra de protección entre el usuario y cualquier comando potencialmente perjudicial o destructivo para el sistema operativo. Esto es especialmente cierto para usuarios con múltiples usuarios, donde se requiere la separación de los privilegios del usuario; el inadecuado comportamiento de un usuario puede interrumpir o destruir el trabajo de muchos usuarios.

Dado el hecho muchas herramientas incluidas en Kali Linux pueden únicamente ser ejecutadas con privilegios de “root”, esta es la cuenta por defecto de Kali Linux. A diferencia de otras distribuciones Linux, no se solicitará crear una cuenta de usuario no privilegiada cuando se instale Kali Linux. Esta política particular es una desviación importante de la mayoría de sistemas Linux,y tiende a ser muy confusa para usuarios menos experimentados. Los principiantes deben tener especial cuidado cuando utilicen Kali Linux, pues la mayoría de los errores destructivos ocurren al operar con privilegios de “root”.

Servicios de Red Deshabilitadas por Defecto

En contraste con Debian, Kali Linux deshabilita por defecto cualquier servicio instalado el cual podría atender en una interfaz de red pública, como HTTP o SSH.

La razón detrás de esta decisión es para minimizar la exposición durante una prueba de penetración, cuando es perjudicial anunciar la presencia, y el riesgo de detección debido a interacciones inesperadas de red. Se puede manualmente habilitar cualquier servicio ejecutando el comando “systemctl enable service”.

Una Colección Curada de Aplicaciones

Debian pretende ser un sistema operativo universal, y pone muy pocos limites en aquello lo cual empaqueta, proporcionando un mantenedor a cada paquete. Por contraste, Kali Linux no empaqueta cada herramienta disponible para pruebas de penetración. En lugar de esto, el objetivo es proporcionar solo las mejores herramientas licenciadas disponibles, abarcando la mayoría de tareas requeridas de realizar por un profesional en pruebas de penetración. Los desarrolladores de Kali Linux trabajan como profesionales en pruebas de penetración, impulsan el proceso de selección, y se aprovecha de su experiencia y pericia para tomar decisiones inteligentes. En algunos casos esto es una cuestión de hecho, pero hay otras opciones más difíciles, las cuales simplemente se reducen a preferencias personales.

A continuación algunos de los puntos considerados cuando una nueva aplicación es evaluada:

• La utilidad de la aplicación en el contexto de pruebas de penetración
• La funcionalidad única de las características de la aplicación
• La licencia de la aplicación
• Los requerimientos de recursos de la aplicación

Mantener un repositorio útil de herramientas para pruebas de penetración es una tarea retadora. Son bienvenidas las sugerencias de herramientas dentro de una categoría dedicada (Peticiones de Herramientas Nuevas) en el “Rastreador de Fallas de Kali Linux”. Las peticiones de nuevas herramientas son mejor recibidas cuando el envío está bien presentado, incluyendo una explicación de porque es útil la herramienta, como se compara con otras herramientas similares, etc.

Fuentes:

https://www.kali.org
https://bugs.kali.org/my_view_page.php
https://www.kali.org/download-kali-linux-revealed-book/
https://www.debian.org/

Kali Linux es una distribución la cual contiene su propia colección de cientos de herramientas de software, especialmente hechas a medida para los usuarios; como profesionales en pruebas de penetración y otros profesionales de seguridad. También viene con un programa de instalación para completamente configurar Kali Linux como el sistema operativo principal en cualquier computadora.

Es muy parecido a todas las otras distribuciones Linux existentes, pero existen otras características las cuales diferencian a Kali Linux, muchas de las cuales se adaptan a necesidades específicas de los profesionales en pruebas de penetración. A continuación se exponen algunas de estas.

Un sistema Vivo

Contrario a la mayoría de distribuciones Linux, la imagen ISO principal la cual se descarga no está simplemente dedicada a instalar el sistema operativo; esta puede ser utilizada también como un sistema iniciable en vivo. En otras palabras, se puede utilizar Kali Linux sin instalarlo, únicamente iniciando la imagen ISO (usualmente después de ser copiada la imagen en una unidad USB).

El sistema vivo contiene las herramientas comúnmente utilizadas por los profesionales en pruebas de penetración, de tal manera incluso si el sistema de uso diario no es Kali Linux, se puede simplemente insertar el disco o unidad USB, para luego reiniciarlo y ejecutar Kali Linux. Sin embargo se debe tener en consideración, la configuración por defecto no preserva los cambios entre reinicios. Si se configura la persistencia con una unidad USB, luego se puede ajustar el sistema a necesidades específicas (por ejemplo; modificar archivos de configuración, guardar reportes, actualizar software, e instalar paquetes adicionales), además de los cambios serán conservados entre reinicios.

Modo Forense

En general, cuando se realiza trabajo forense en un sistema, se necesita evitar cualquier actividad la cual pueda alterar los datos sobre el sistema analizado de cualquier manera. Desafortunadamente, los entornos de escritorio modernos tienden a interferir con este objetivo, intentando montar automáticamente cualquier disco detectado. Para evitar este comportamiento, Kali Linux tiene un modo forense, el cual puede ser habilitado desde el menú de inicio: esto deshabilitará tales características.

El sistema en vivo particularmente útil para propósitos forenses,porque es posible reiniciar cualquier computadora con el sistema Kali Linux, sin acceder o modificar los discos duros.

Un Kernel Linux Personalizado

Kali Linux siempre proporciona un Kernel de Linux reciente personalizado, basado en la versión de Debian “unstable”. Esto asegura soporte sólido de hardware, especialmente para un amplio rango de dispositivos inalámbricos. El kernel está parchado para soporte de inyección inalámbrica, debido a muchas herramientas par evaluaciones de seguridad inalámbrica confían en esta característica.

Debido a muchos dispositivos de hardware requieren archivos de firmwares actualizados (encontrados en /lib/firmware), Kali Linux los instala por defecto; incluyendo el firmware disponible en la sección “non-free” de Debian. Esto no son instalados por defecto en Debian, porque son de fuente cerrada, y por lo tanto no forman parte de Debian propiamente.

Completamente Personalizable

Kali Linux es construido por profesionales en pruebas de penetración, pero se entiende no todos estarán de acuerdo con las decisiones de diseño o selección de las herramientas incluidas por defecto. Con esto en consideración, siempre se asegura Kali Linux sea fácil de personalizar basándose en necesidades y preferencias propias. Al final se publica la configuración de la construcción en vivo utilizada para construir las imágenes oficiales de Kali Linux, de tal manera se pueda configurar a gusto propio. Es muy fácil iniciar desde esta configuración publicada e implementar varios cambios en función a necesidades propias, gracias a una construcción en vivo versátil.

La construcción en vivo incluye muchas características para modificar el sistema instalado, instalar archivos suplementarios, instalar paquetes adicionales, ejecutar comandos arbitrarios, y cambiar valores previamente sembrados a debconf.

Un Sistema Operativo Confiablee

Los usuarios de una distribución de seguridad, con mucha razón requieren conocer a simple vista se puede confiar en esta, y como ha sido desarrollada, lo cual permite a cualquiera inspeccionar el código fuente. Kali Linux es desarrollado por un pequeño equipo de desarrolladores con muchos conocimientos, trabajando de manera transparente y siguiendo las mejores prácticas en seguridad: suben paquetes fuente firmados, los cuales son luego construidos en demonios de construcción dedicados. Los paquetes son luego verificados y distribuidos como parte de un repositorio firmado. El trabajo hecho en los paquetes puede ser completamente revisado a través de los repositorios Git de empaquetamiento (lo cual contiene etiquetas firmadas), los cuales son utilizados para construir los paquetes fuentes de Kali Linux. La evolución de cada paquete también puede ser seguida a través del “Rastreador de Paquetes de Kali”.

Utilizable en una Amplia Rango de Dispositivos ARM

Kali Linux proporciona paquetes binarios para arquitecturas ARM armel,armhf, y arm64. Gracias a las imágenes fácilmente instalables proporcionadas por Offensive Security, Kali Linux puede ser desplegado en muchos dispositivos interesantes, desde teléfonos inteligentes y tables, hasta routers Wi-FI y computadoras de varios tipos y tamaños.

Fuentes:

https://www.kali.org
https://www.offensive-security.com/
https://www.kali.org/download-kali-linux-revealed-book/
https://www.debian.org/
https://developer.arm.com/architectures/learn-the-architecture/introduc…