lunes, 28 de noviembre de 2011

Nessus en Linux

1.- Nessus

1.1.- Instalación Nessus

Dado que nessus ha dejado de ser un proyecto totalmente libre, ya no está disponible en los repositorios de Ubuntu, por lo que debemos ir a la página de descargas del proyecto - http://www.nessus.org/download/ - descargamos el fichero deb. Y lo instalamos: 

image
  • añadimos el usuario para emplear nessus, para ello tenemos que ejecutar el comando:
/opt/nessus/sbin/nessus-adduser

Auditoría de seguridad de sistemas de información



Es el estudio que comprende el análisis y gestión de sistemas para identificar  posterioremente corregir las diversas vulnerabilidades que pudieran presentarse en una revisión de los equipos informáticos, redes y servidores de una empresa.

Se basan en un patrón o conjunto de directrices y buenas prácticas. Existen diversos estándares:


  1. COBIT (Objetivos de Control de las Tecnologías de la información.
  2. ISO 2700
  3. ISO 27002 
  4. ISO/IEC 17799


lunes, 7 de noviembre de 2011

Ejercicios de iptables 4.- Marcado de paquetes, bits, logs,...

4- Otras pruebas con más detalle:
a.- Rechazar el tráfico hacia el puerto 25, en la interfaz eth1, siempre que los paquetes vengan marcados con las opciones SYN y ACK del protocolo tcp, a la vez.

Para comprobar las diferencias, en primer lugar pongo a escuchar netcat en el puerto 25:
netcat -l -p 25


Para comprobar cuál sería la respuesta normal a un paquete normal con el syn y el ack activos genero uno con hping:
hping -c 1 -S -A -p 25 192.168.56.101

viernes, 28 de octubre de 2011

Teclado logitech wireless caput

Hoy estaba "tranquilamente" (lo entrecomillo por las horas) buscando información sobre un tema que estoy preparando cuando el teclado inalámbrico logitech con el que trabajo dejó de funcionar; bueno en realidad la tecla s funcionaba y si pulsaba la v me escribía por pantalla re15.2.

Googleando encontré cómo solucionarlo gracias a : http://forums.techguy.org/hardware/590375-wireless-keyboard-doing-random-things.html


Básicamente lo que hay que hacer es (traduzco una de las entradas en el foro que es la que a mi me funcionó):
http://forums.logitech.com/logitech/...essage.id=2935



Has probado a cambiar las pilas y el problema persiste, sigue estos pasos:
1.- Quita las pilas del teclado y pulsa las teclas del teclado repetidamente (como si escribieras,... pero sin las pilas) durante dos minutos aproximadamente. Esto vaciará los condensadores.
2.- Pulsa el botón conectar en el receptor.
3.- Pulsa el botón conectar en el ratón. NOTA: podrías necesitar un objeto afilado para presionar el botón conectar.
4.- Pulsa el botón conectar en el receptor.
5.- Inserta las pilas de nuevo en el teclado.
6.- Pulsa el botón conectar en el teclado.


la prueba de que funciona es este post :)





Enlace:

esta info la he sacado de una de las contestaciones del foro de este enlace http://forums.techguy.org/hardware/590375-wireless-keyboard-doing-random-things.html

sábado, 22 de octubre de 2011

Seguridad en telefonía móvil. 4.3 La generación 2.5 GPRS

 
4.3.- 2.5G: GPRS
El General Packet Radio Services (GPRS) es un servicio que proporciona la transmisión de paquetes vía radio a los usuarios de GSM. Proporciona multitud de servicios que hacen posible el concepto de Internet móvil. Se considera en su diseño la seguridad como algo vital, para ello emplea una arquitectura específica para proteger la red de accesos no autorizados mientras se protege la seguridad de los usuarios. La arquitectura está basada en las medidas de seguridad implementadas en GSM ya que emplea la infraestructura GSM. Sin embargo GPRS está más expuesta a los ataques ya que usa la tecnología IP que presenta una serie de conocidas vulnerabilidades.
image
Ilustración 6: Arquitectura de la red GPRS

jueves, 20 de octubre de 2011

Ejercicios iptables 3.- Guardar las reglas y contadores de iptables

3- Probar los comandos de almacenamiento de reglas iptables-save y de restauración de reglas iptables-restore (el procedimiento será algo diferente dependiendo de la distribución de LINUX que se esté usando).

La manera básica, una vez que hemos insertado y probado las reglas de iptables en nuestro equipo, consiste en ejecutar el comando “iptables-save” seguido del nombre del fichero dónde guardaremos nuestras reglas, por ejemplo:

iptables-save > /etc/reglas.iptables

si además queremos guardar también los contadores (número de paquetes que se han ajustado a cada regla) podemos emplearlo junto con la opción -c.
una vez que hemos guardado el fichero podremos restaurarlo con el comando iptables-restore del siguiente modo:

iptables-restore < /etc/reglas.iptables

el contenido del fichero /etc/reglas.iptables podría ser algo similar a la siguiente imagen:image

martes, 11 de octubre de 2011

Seguridad en telefonía móvil. 4.2 La segunda generación -2G- GSM

4.2.- La segunda generación (2G): GSM
La segunda generación de telefonía móvil adoptó la tecnología digital. La mayor parte de los terminales usan el Sistema Global para Comunicaciones Móviles, o GSM, que se diseñó desde el inicio para facilitar el roaming internacional y se lanzó en 1992.

Los diseñadores de GSM intentaron asegurar el sistema contra la clonación y otros ataques conocidos; el objetivo era que fuera al menos tan seguro como los sistemas cableados.

Para conseguirlo la industria intentó mantener en secreto la criptografía y otros mecanismos de protección que forman parte del corazón de los protocolos GSM. En cualquier caso este sistema, obviamente no funcionó, ya que pronto se conocieron algunas vulnerabilidades y el resto del sistema fue conocido mediante el empleo de ingeniería inversa.

Las funciones o servicios de seguridad básicos desarrollados para GSM se podrían agrupar en tres grupos: autenticación de la identidad del suscriptor, confidencialidad de la identidad del suscriptor y confidencialidad de los datos, incluyendo elementos de información de señalización, datos de usuario y datos de conexiones físicas.

sábado, 8 de octubre de 2011

Ejercicios iptables 2.- Iptables como NAT

2- Explorar las posibilidades del tipo nat de IPTables. En concreto, probar a hacer NAT con comandos del tipo: # iptables -t nat -A POSTROUTING... y comprobar que se ha realizado el NAT con éxito, analizando los mensajes salientes.

A pesar de que ya he empleado NAT en el apartado 1.e emplearé un esquema nuevo que simula una red “real” para este ejercicio. En la misma tenemos nuestro cortafuegos con tres tarjetas de red separando las distintas zonas: Internet, la LAN y un DMZ en el que hemos puesto un servidor de DNS y un servidor FTP (simulado con netcat) de acuerdo con el siguiente esquema:

image
Las condiciones en cuanto a tráfico que ha de cumplir son las siguientes:

jueves, 6 de octubre de 2011

Fuse para Windows.






Los usuarios de linux disfrutan desde hace bastante de una librería llamada fuse que permite crearnos nuestro sistema de archivos sin necesidad de permisos de administración. A partir del mismo se han desarrollado utilidades como sshfs que haciendo uso de esas librerías nos permiten montar una unidad en nuestro "árbol de directorios" accediendo por ssh a un servidor remoto.

La muerte de un visionario, fallece Steve Jobs

http://www.elpais.com/articulo/tecnologia/Muere/Steve/Jobs/fundador/Apple/elpeputec/20111006elpeputec_1/Tes

martes, 4 de octubre de 2011

Ejercicios de iptables 1.f


f.- Idem, pero denegando el trafico desde la eth0 a la eth1 de mensajes de protocolo tcp

La regla sería similar a la anterior pero especificando ahora que el único tráfico involucrado ahora será el tcp:
#Borro primero las reglas ya existentes anteriores en la cadena FORWARD
iptables -F FORWARD
iptables -A FORWARD -i eth0 -o eth1 -p tcp -j DROP

Para no ser demasiado reiterativos realizamos un intento de conexión a una pagina web tras insertar la regla, y veremos cómo pasan sin problemas tanto las peticiones al servidor DNS (protocolo udp) por esta interfaz como un ping (protocolo icmp), aunque sea reiterativo y con el fin de que registre las estadítiscas (recuerdo que la política por defecto la he establecido para este punto a ACCEPT) añado dos nuevas reglas para tráfico dns e icmp:
# previamente haciendo DNAT he redirigido todas las peticiones dns a través del interfaz eth0
iptables -A FORWARD -i eth0 -o eth1 -p udp -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -p icmp -j ACCEPT
#pongo los contadores a 0
iptables –Z

image

lunes, 3 de octubre de 2011

Seguridad en telefonía móvil. 4.- Mecanismos de seguridad y ataques en las distintas generaciones de telefonía.


4.- Mecanismos de seguridad y ataques en las distintas generaciones de telefonía.

Uno de los factores que han motivado los sucesivos cambios entre generaciones de telefonía ha sido, sin duda, solventar las brechas de seguridad detectadas en cada una de las generaciones anteriores. De este modo mientras se extendían nuevas tecnologías que provocaban el incremento y aprovechamiento del ancho de banda disponible se aplicaban nuevas técnicas que intentaban asegurar distintos elementos presentes en las comunicaciones móviles.

En los siguientes puntos trataré de ofrecer una visión de las distintas generaciones y su evolución en lo que a seguridad se refiere, haciendo especial hincapié en las debilidades y ataques específicos desarrollados contra cada una de ellas.

4.1- Primera generación (1G): el clonado de los teléfonos móviles.

sábado, 1 de octubre de 2011

Ejercicios de Iptables 1.e


e.- Si dispone de dos interfases en el equipo, pruebe a denegar todo el trafico desde la eth0 a la eth1. Si no, al menos plantee cómo sería el comando.

Para comprobar el funcionamiento, en primer lugar debemos habilitar el enrutamiento en iptables, ya que en caso contrario no lo haría:
echo 1 > /proc/sys/net/ipv4/ip_forward
a continuación, lo único que tendríamos que hacer es:
iptables -A FORWARD -i eth0 -o eth1 -j DROP

Para comprobar su funcionamiento emplearé este equipo como enrutador para otra máquina virtual. 

A continuación abriré simplemente el navegador e intentaré conectarme a internet, veremos como las 
peticiones salen hacia fuera pero las respuestas procedentes de los servidores se rechazan.

miércoles, 28 de septiembre de 2011

Ejercicios de iptables 1.d.

d.- Rechazar la conexion al puerto 65000, protocolo udp, de la interfaz eth2, desde los ordenadores de la LAN (red local).

Dado que mi interfaz conectada a la LAN es eth2 voy a rechazar el tráfico destinado a esta conexión en lugar de a eth0

En primer lugar ponemos a escuchar nuevamente netcat, en este caso el protocolo udp de la interfaz eth2 y a través del puerto 65000 con el objeto de realizar las pruebas:
# con la opción “u” le indicamos que el tráfico será udp, con “n” que no resuelva los nombres de los # equipos, con “v” que nos detalle las conexiones
netcat -lunv -p 65000

image

martes, 27 de septiembre de 2011

Cambio de look

Como podéis ver y casi con un año de retraso, finalmente me he decidido a pegarle un pequeño cambio de imagen al blog, a ver que os parece, se admiten sugerencias.

Para los que ya no os acordáis de cómo era os deja una muestra del anterior aspecto:

Ejercicios de iptables. 1c

c.- Denegar la conexion al puerto 25, protocolo tcp, de la interfaz eth1

Para el resto de ejercicios emplearé una máquina virtual con tres interfaces:
  • eth0: 10.0.2.15 – NAT con la tarjeta física para salida a Internet
  • eth1: 192.168.56.10 – red sólo anfitrión para comunicarse con otras máquinas virtuales
  • eth2: 192.168.0.195 – modo puente para comunicarme vía inalámbrica con equipos de la red.
image



Para la realización de este ejercicio debemos poner la política por defecto a ACCEPT, ya que sino lo rechazaría sin que insertáramos ninguna nueva regla:

lunes, 26 de septiembre de 2011

Ejercicios iptables 1.b

b.- Permitir que la interfaz eth0 pueda enviar paquetes ICMP a cualquier red.

Por defecto con las reglas que hemos insertado no podríamos enviar ninguna solicitud de eco, tan sólo recibirlas ya que sólo estamos aceptando tráfico icmp entrante y su saliente relacionado:image
Para habilitarlo (podemos especificar explícitamente a cualquier red poniendo -d 0/0 o no especificando la dirección de destino que equivaldría a cualquiera):

viernes, 23 de septiembre de 2011

Seguridad en telefonía móvil. 3 Conceptos de seguridad en telefonía móvil

3. Seguridad en telefonía móvil

3.1 Características de los dispositivos actuales
Los teléfonos móviles ( o celulares como se les conoce en el mundo sajón) se han convertido en una herramienta indispensable hoy en día. Su reducido tamaño y relativo bajo coste hacen de ellos la herramienta ideal, no sólo para llamadas de voz, envío de mensajes de texto o manejo de información personal (PIM) (p.e. Agenda telefónica, calendarios y anotaciones) sino que pueden incluir numerosas funciones hasta hace poco propias de ordenadores personales: envío de e-mail, navegación Web, almacenamiento y modificación de documentos, realización de presentaciones, acceso remoto a datos,....

Los teléfonos móviles son, por tanto, similares a otros sistemas electrónicos como pueden ser PDA o incluso ordenadores personales, pero presentan algunas características específicas que los hacen diferentes al resto de dispositivos y que además repercute de modo directo en cuanto a los requerimientos de seguridad. Probablemente la mayor diferencia con respecto al resto de dispositivos reside en que son capaces de soportar comunicaciones a través de más de un interfaz de radio a sistemas de comunicaciones inalámbricas.

Seguridad en telefonía móvil. 2 Telefonía móvil

2.- Telefonía móvil

Los sistemas celulares empleados en telefonía móvil representan una importante diferencia de diseño frente a los sistemas tradicionales de emisión de radio y televisión. Estos últimos basan su diseño en la emisión a la máxima potencia y mediante el uso de las antenas más altas permitidas por los órganos reguladores de cada país. En el caso de los sistemas celulares, en cambio, los transmisores se diseñan para emitir en una única célula, buscando la eficiencia a través del uso de distintos canales en cada célula y la transmisión a menor potencia para que las frecuencias puedan ser reutilizada en una zona geográfica relativamente cercana.

Por otra parte, el uso de Internet ha supuesto una explosión en la necesidad y uso de transmisión de datos en medios inalámbricos, creciendo al mismo tiempo y en similar proporción el número de usuarios de dichos servicios.

Todo ello, ha hecho que se sucedan rápidamente distintas generaciones de telefonía que han tratado de adaptarse a dichos cambios pasando de los primeros sistemas de escasa eficiencia espectral, a los actuales sistemas en desarrollo.
image
Ilustración 1: Evolución de los sistemas en las distintas generaciones de telefonía

jueves, 22 de septiembre de 2011

Seguridad en telefonía móvil. 1 Introducción

1.- Introducción: Evolución histórica de las comunicaciones inalámbricas.

En realidad, las comunicaciones inalámbricas tienen más de 150 años, a continuación haré un repaso por algunos de los hitos históricos en dichos sistemas.

Ya en 1835 Samuel Morse desarrolla el código Morse, que representaba letras y números mediante puntos y rayas. A los pocos años también desarrollaría el telégrafo electromagnético que permitía que los mensajes de codificaran y transmitieran como una serie de puntos y rayas.

Seguridad en telefonía móvil

A lo largo de los próximos días iré colgando las entradas relativas a seguridad en la telefonía móvil, os dejo a continuación el índice junto con las referencias bibliográficas que he empleado para hacer el trabajo:

Índice de contenido
2.1- Evolución de la telefonía móvil del 1G al 4G
3.1 Características de los dispositivos actuales
3.2.- Aspectos generales de seguridad.
4.1- Primera generación (1G): el clonado de los teléfonos móviles.
4.2.- La segunda generación (2G): GSM
a.- Autenticación de la identidad del suscriptor: Identificación
Ataques y vulnerabilidades del sistema de identificación
b.- Confidencialidad de la identidad del suscriptor
Ataques y vulnerabilidades de la confidencialidad GSM
c.- Confidencialidad de los datos
Ataques a la confidencialidad de datos GSM
d.- Conclusiones sobre seguridad en GSM
4.3.- 2.5G: GPRS
a.- Arquitectura GPRS
b.-Arquitectura de seguridad GPRS
Seguridad de la red troncal GPRS
c.- Ataques a la seguridad de GPRS
c.1.- Ataques a la estación móvil y al SIM. (iguales a GSM)
c.2 .- Ataques a la interfaz entre MS y SGSN (similares a los desarrollados para GSM).
c.3.- Red troncal GPRS
c.4.- Ataques a la interfaz entre operadores. (interfaz Gp)
c.5.- Ataques al interfaz público de Internet (Interfaz Gi)
d.- Conclusiones
4.4.- Las redes de tercera generación (3G): UMTS
a.- Características de seguridad en la arquitectura de seguridad 3G
b.- Seguridad de acceso a la red
c.- Seguridad del dominio del proveedor
d.- Seguridad del dominio del usuario.
e.- Seguridad del nivel de aplicación:
f.- Visibilidad y Configurabilidad.
g.- Ataques de seguridad a UMTS
h.- Conclusiones UMTS
5.- Seguridad de plataforma.
6.- Conclusiones
7.- Referencias
7.1 Bibliografía
7.2 Artículos, revistas y publicaciones similares
7.3 Enlaces web


 << Anterior                                                                                                                Siguiente >>


miércoles, 21 de septiembre de 2011

clonado a todo trapo

simplemente escribo esta nota para avisar a los alumnos de smr de que los
equipos parece ser estarán mañana en perfecto estado, probablemente mejor que el que firma.
nos vemos mañana

martes, 20 de septiembre de 2011

Ejercicios Iptables 1.a

Introducción

Antes de comenzar con la actividad he instalado algunos programas para poder comprobar el funcionamiento de los comandos y el resultado de los mismos (el demonio contrackd es necesario instalarlo en algunas versiones de ubuntu):
apt-get install conntrack contrackdimage
apt-get install wireshark

sábado, 17 de septiembre de 2011

Ejercicios Iptables. Enunciados

A continuación se proponen una serie de ejercicios a realizar mediante iptables. Las soluciones en próximas entregas...


1- Escribir, probar (y comprobar) los siguientes ejemplos:
  • a Permitir el trafico ICMP de entrada al sistema desde cualquier red. 
  • b Permitir que la interfaz eth0 pueda enviar paquetes ICMP a cualquier red. 
  • c Denegar la conexión al puerto 25, protocolo tcp, de la interfaz eth1 
  • d Rechazar la conexión al puerto 65000, protocolo udp, de la interfaz eth0, desde los ordenadores de la LAN (red local). 
  • e Si dispone de dos interfases en el equipo, pruebe a denegar todo el tráfico desde la eth0 a la eth1. Si no, al menos plantee cómo sería el comando. 
  • f Idem, pero denegando el tráfico desde la eth0 a la eth1 de mensajes de protocolo tcp

martes, 6 de septiembre de 2011

Honeyd IX. Final

4.- Conclusiones
Tras haber leído bastante documentación sobre honeypots – a los que sólo conocía de oídas- y pasarme bastante tiempo viendo logs y averiguando el funcionamiento de los mismos, creo que es un software interesante por varios motivos: en primer lugar porque recoge bastantes de las cuestiones relativas a seguridad (IDS, iptables, programas de detección de vulnerabilidades,...) y en segundo lugar porque creo que constituyen la demostración práctica ideal de que en cuanto conectamos un ordenador a la red quedaremos expuestos a múltiples riesgos.

Me llamó la atención -por mucho que lo hayamos leído a lo largo de este año- que cada vez que enchufamos nuestros equipos y abrimos puertos, comenzamos a recibir intentos de conexión desde múltiples redes en Internet: Francia, Suiza, Corea,.... y otras desde la red de nuestra propia operadora.

Mejor demostración de la existencia de gusanos, auto-rooters, mass-rooters es difícil encontrarla.
imageimage

lunes, 29 de agosto de 2011

Honeyd (VIII). Tráfico capturado

3.- Tráfico capturado.

Las primeras muestras de que hay alguien escaneando nuestros sistemas nos las ofrece honeyd desde la propia consola:image
en la imagen podemos ver cómo desde la 83.61.252.186 han solicitado conexión a los puertos 21, 80,110 y 8080, tras comprobar que están abiertos comienzan a ejecutarse los scripts asociados a esos puertos de manera reiterada. Normalmente esto indicará que estamos sufriendo un escaneo de puertos seguido de una comprobación automatizada de vulnerabilidades de esos puertos (como el que suele realizar, por ejemplo Nmap o Nessus.

jueves, 25 de agosto de 2011

Manual de Honeyd (VII). Honeyd registro

e.- Ficheros de registro de la actividad.

En resumen, con la configuración previa habremos recogido información en los siguientes lugares:
  • logs “genéricos”
    • /var/log/syslog: honeypot vuelca su información en este lugar además del fichero que le marquemos
    • /var/log/iptables: conexiones que se ajustan a las reglas que he configurado en iptables
  • logs de honeyd
    • /var/log/honeyd/honeyd.log: fichero dónde se registran todas las conexiones a nuestro “tarro de miel”.
    • Logs de scripts:
      • /var/log/honeyd.txt para los servicios vnc, finger, proftpd, exchange-pop3, exchange-imap
      • /var/log/honeypot/iis.log para el servicio web iis.sh
      • para cada uno de los servicios un fichero en el directorio /var/log/honeypot
      • /var/log/ftp-dirección_ip_del_atacante: log servicio ftp
  • Logs de snort: /var/log/alert
  • logs de iptables: he creado dentro de /var/log/honeypot/ un fichero para cada uno de los servicios del honeypot además del genérico en /var/log/iptables.
  • Contenido de los paquetes grabados con wireshark: almacenado en ficheros también dentro de /var/log/honeypot.




     << Anterior                                                                                                                Siguiente >>

Para ver el resto de manuales de seguridad y enlaces a las siguientes entregas, puede acudir al índice de temas de seguridad en el enlace

miércoles, 24 de agosto de 2011

Manual de Honeyd (VI). Honeyd

d.- Honeyd

image

La instalación en Ubuntu de honeyd es muy sencilla, simplemente ejecutaremos:
apt-get install honeyd
y el sistema instalará la lista de paquetes necesarios incluyendo algunos ficheros de configuración básicos. 

Una vez hecho podemos echarle un vistazo al directorio /etc/honeypot dónde nos encontraremos un fichero de configuración de ejemplo junto con los ficheros de firmas de nmap, p0f y xprobe. Los ficheros de firmas los empleará honeyd para engañar a escaneos activos y pasivos cuando otros sistemas traten de averiguar el sistema operativo que está simulando. El fichero de configuración “honeyd.conf” puede servirnos de guía para crear nuestro propio fichero dónde simularemos nuestra red. 
En mi caso he decidido simular tres máquinas en el mismo rango de red que la de producción, los equipos y servicios, tal y cómo se puede ver en la primera imagen del guión son: windows2003 server, windows XP y Suse 8.0 (no todos los puertos están redirigidos desde fuera). El fichero de configuración será el siguiente:

martes, 23 de agosto de 2011

Manual de Honeyd (V). Farpd

d.- farpd

Farpd es un programa que sirve para realizar arp-spoofing de las ips que le digamos y que no estén siendo usadas en nuestra red local (diferencia con respecto a otros programas empleados para capturar paquetes destinados a otros equipos como puede ser Caín). 

Básicamente lo ejecutamos introduciendo como opción de configuración las ips que queremos que simule el equipo. Una vez en funcionamiento permanecerá a la escucha y cuando algún equipo de la red realice una petición arp para alguna de las ips que hemos introducido, sino contesta ningún otro equipo de la red, lo hará él simulando que nuestro equipo tiene varias ip asignadas. Con ello podemos hacer que un único equipo escuche varias ips de manera sencilla.

En mi caso lo ejecuto de la siguiente manera (lo he incluido en un fichero ejecutable llamado arrancar_farpd):
farpd -d -i eth2 192.168.0.21-192.168.0.30
  • la opción “-d” es para que no demonice la aplicación y para habilitar mostrar por pantalla la información relativa a las peticiones que escucha y acepta.
  • “-i” asignamos la interfaz que debe escuchar nuestro equipo.
  • “192.168.0.21-192.168.0.30” es el rango de ips para el que debe hacer arp-spoofing y que por tanto será el que empleemos en honeyd.
Para probarlo lanzo un ping al equipo 192.168.0.25 y me aseguro de que todo funciona correctamente:

image

como vemos recibe la solicitud, permanece a la escucha y envía la respuesta con la mac del propio equipo (cuya ip real es, en realidad, 192.168.0.16).


 << Anterior                                                                                                                Siguiente >>

Para ver el resto de manuales de seguridad y enlaces a las siguientes entregas, puede acudir al índice de temas de seguridad en el enlace

viernes, 19 de agosto de 2011

Manual de Honeyd (IV). Wireshark

c.- Instalación y ejecución de Wireshark.

Aunque con snort ya capturamos las cabeceras de los paquetes, si queremos capturar el tráfico completo dirigido a nuestro equipo podemos emplear cualquier capturador de paquetes (tcpdump, tshark,....) yo prefiero wireshark porque me parece mucho más sencillo e intuitivo que las otras aplicaciones.

image
Tras instalarlo con

apt-get install wireshark

configuro la captura de datos; he decidido generar un fichero por hora y almacenar los logs de 7 días -con rotación-. Para evitar que capture tráfico que no me interesa -en este caso- he eliminado todo el tráfico broadcast, arp y el del equipo anfitrión dónde he instalado la máquina virtual, para ello simplemente introduzco un filtro de captura de datos:

not broadcast and not multicast and not arp and not host 192.168.0.193
en resumen quedaría tal y cómo se ven en la imagen superior.


 << Anterior                                                                                                                Siguiente >>

Para ver el resto de manuales de seguridad y enlaces a las siguientes entregas, puede acudir al índice de temas de seguridad en el enlace

jueves, 18 de agosto de 2011

Manual de Honeyd (III)

b.- Instalación de Snort.

Snort ya ha sido objeto de estudio de un trabajo previo por lo que simplemente diré que lo he instalado junto con el honeypot para obtener más información sobre el tráfico que llega al equipo, tras instalarlo* con “apt-get install snort” y configuar correctamente el fichero snort.conf con la ip correcta de la red local (en mi caso 192.168.0.0/24) lo ejecuto:
snort -A full -i eth2 -c /etc/snort/snort.conf

como vemos empleo para la escucha la interfaz eth2 que previamente he configurado en la máquina virtual para acceder directamente a mi red de área local -modo puente-.
Para ver si funciona podemos realizar un escaneo con nmap desde otro equipo de la red y ver por pantalla los logs con:
tail -f /var/log/snort/alert

si todo va bien ya tendremos nuestro IDS en funcionamiento.

image

*En posteriores entregas explicaré con más detalle la instalación y funcionamiento de este IDS y su combinación con alguna interfaz gráfica disponible.


 << Anterior                                                                                                                Siguiente >>

Para ver el resto de manuales de seguridad y enlaces a las siguientes entregas, puede acudir al índice de temas de seguridad en el enlace

miércoles, 17 de agosto de 2011

Manual de Honeyd II


a.- Configuración de Iptables y rsyslog.

Por defecto los equipos con ubuntu -distribución que he empleado para la realización de esta práctica- tienen permitido todo tráfico entrante, saliente y en la cadena forward. En mi caso he creado un pequeño fichero para deshabilitar el tráfico forward. En el mismo fichero he creado unas reglas para registrar todo el tráfico dirigido a los puertos que estoy observando en mi honeypot: 21, 25, 80,....

image

martes, 16 de agosto de 2011

Manual de Honeyd

La mejor manera de entender el funcionamiento de un honeypot es la puesta en funcionamiento de uno, en el siguiente documento se explica paso a paso cómo instalar y configurar honeyd así como el software complementario necesario para la realización de la práctica.

Igualmente se verán los resultados de exponer nuestro ordenador con el equipo instalado al exterior (es decir abrir puertos a Internet).
Índice de contenido

1.- Introducción.
2.-Preparación de la práctica y configuración del software.
a.- Configuración de Iptables y rsyslog.
b.- Instalación de Snort.
c.- Wireshark.
d.- farpd
d.- Honeyd
e.- Ficheros de registro de la actividad.
3.- Tráfico capturado.

1.- Introducción.

Para la realización de esta práctica consistente en la detección de tráfico malicioso hacia un honeypot he empleado honeyd sirviéndome de la propia red en producción. Para ello he empleado algunas de las ips libres de mi red en lugar de crear otra red con otro rango totalmente distinto.

viernes, 12 de agosto de 2011

Honeypot VII

7.- Honeynet.

Generalmente se emplean en sistemas de investigación y no en producción ya que requieren una gran cantidad de tiempo y recursos para su implementación y mantenimiento. Su utilización excede el uso como prevención, detección o reacción a ataques pero son excelentes como honeypots de investigación dando respuesta, entre otras a cuestiones como ¿ Quiénes son los atacantes?¿Qué herramientas usan?¿Qué tácticas emplean?¿Cuáles son sus motivaciones? Ninguna otra solución honeypot nos puede dar tanta información.
a.- Métodos, motivos y herramientas involucradas.
La primera norma de investigación es aprender tanto como sea posible sobre los atacantes. Las honeynets nos permiten capturar sus pulsaciones de teclas, las herramientas que emplean para probar y explotar sistemas o incluso sus sesiones de chat.
b.- Análisis de tendencias.
La información recogida puede servir para predecir ataques actuando como sistemas de alerta temprana. Generalmente es difícil determinar cuando se va a atacar a un sistema o con que herramientas.

jueves, 11 de agosto de 2011

Honeypot 6

6.- Honeyd

Al igual que el honeypot BackOfficer, explicado previamente, es un honeypot de baja interacción, aunque mucho más versátil y que ofrece mucha más información. Para funcionar no asume la ip del sistema en el que se instala -como hace BackOfficer-, sino que emplea ips no empleadas por otro equipo.

Una de las ventajas que ofrece es que es capaz de simular una gran cantidad de sistemas operativos al mismo tiempo. 

Es un sistema de baja-interacción empleado principalmente en sistemas de producción a modo de alerta para detectar tanto ataques como sistemas comprometidos. De todos modos permite la incorporación de scripts para simular determinados servicios, algunos de ellos, por ejemplo en el caso del virus Kuang2 permiten incluso más interactividad para el atacante, guardando incluso los ficheros subidos por los atacantes.

martes, 28 de junio de 2011

Honeypot 5

5.- Ejemplos de honeypots.

Algunos ejemplos de honeypots atendiendo a las anteriores clasificaciones y diferenciando sistemas comerciales de libres serían:
a.- Comerciales:
  1. Patriotbox: honeypot de baja interacción diseñado para sistemas windows, en la versión 2 -la actual- incluye soporte para loguin de bases de datos, proxy de puertos e incluso para scripts honeyd.
  2. KFSensor: sistema de baja interacción para Windows. Destinado para detección, incluye simulación NetBIOS y es capaz de interactuar con scripts Honeyd.
  3. NetBait: Permite ejecutarla como producto o como servicio.
  4. ManTrap: Llamado ahora Symantec Decoy Server. Es un honeypot de alta interacción. Permite la ejecución de hasta cuatro sistemas operativos completos distintos que corren encerrados – en “jaulas”- en subsistemas separados del sistema anfitrión.
  5. Specter: es un honeypot de baja interacción diseñado para ser ejecutado en windows. Puede emular hasta 14 sistemas diferentes y diferentes servicios tal y cómo se puede apreciar en la siguiente imagen:image
b.- Sistemas libres

lunes, 27 de junio de 2011

Honeypot 4

4.- Clasificación de los honeypots.

En realidad se pueden realizar clasificaciones de los honeypots atendiendo a dos características: por un lado dependiendo del nivel de interacción que ofrezcan al atacante y por otro dependiendo de la función para la que esté pensado.
a.- Clasificación en función del nivel de interacción.
Según esta clasificación dividiremos los honeypots en baja, media y alta interacción dependiendo de las posibilidades que ofrezcan al posible atacante.
  • Baja interacción: tanto la información que ofrecen como la actividad que puede desarrollar el atacante es muy reducida, en ocasiones se limitan a registrar la ip del sistema que nos está rastreando.
  • Alto nivel de interacción: son sistemas actuales con sistemas operativos y aplicaciones completas. Esto implica que conllevan un mayor riesgo ya que el atacante tiene a su disposición un sistema operativo en el que entrar y desde el que podría atacar a otros equipos. Por otra parte permiten que podamos incluso recoger las herramientas empleadas por los atacantes. Por todo ello y por la mayor necesidad de recursos humanos y materiales suelen emplearse con propósitos de investigación.

jueves, 23 de junio de 2011

Honeypot 3

3.- Rol de los honeypots en nuestro plan de seguridad.

Los honeypots son sistemas que ayudan a reforzar la seguridad de nuestra organización. Atendiendo a la clasificación de las tareas en las que se puede categorizar cualquier proceso de seguridad propuesta por Bruce Shenier en “Secrets and Lies” : Prevención ( que incluiría estimación y protección), Detección y Respuesta veremos como un honeypot puede ayudarnos, o no, en cada una de estas fases.

a.-Prevención

En términos de seguridad quiere decir mantener todo el tráfico malicioso y a los atacantes fuera de nuestra red. Algunos métodos de prevención serían, por tanto, el uso de cortafuegos, claves y dispositivos de acceso, encriptación,.... Desde este punto de vista los honeypots no parecen ofrecer mucha protección ya que más bien hacen lo contrario, atraer atacantes a nuestro sistema.

martes, 21 de junio de 2011

Honeypot 2

2.- Ventajas e inconvenientes de los honeypots

En primer lugar deberíamos decir que los honeypots no son más que otra herramienta de seguridad que podría y debería ser usada en cualquier entorno de red junto con otros como NIDS, cortafuegos,...y que como cualquier otra aplicación tiene una serie de ventajas e inconvenientes.
a.- Ventajas
La primera ventaja que ofrecen es el valor de los datos, frente a otros sistemas como los IDS con un gran número de falsos positivos que tendremos que discriminar “a mano”, estos sistemas tienen pocos logs -son sistemas que no deberían tener ningún tráfico- y por lo tanto son muy valiosos y muy fáciles de analizar.

viernes, 17 de junio de 2011

Honeypot

En esta serie de entregas explicaré en qué consiste y cómo montar un honeypot...

1.- Introducción. ¿Qué es un honeypot?

En realidad y pese a ser una tecnología bastante reciente en el mundo informático - los primeros trabajos que tratan los conceptos de los honeypots datan de 1990/1991, en concreto “The Cuckoo´s Egg” de Clifford Stolls´s y “An Evening With Berferd” de Bill Cheswick´s - constituyen un recurso muy valioso para la seguridad de cualquier empresa o incluso de una pequeña red personal.
Los “honeypots”, literalmente “tarros de miel”, también conocidos como sistemas de decepción o engaño, constituyen una trampa -la otra acepción del término- para posibles atacantes. Un honeypot no es más que un sistema cuya única finalidad es la de ser probado, atacado o incluso comprometido.
El funcionamiento de estos sistemas es bastante sencillo y consiste en poner en marcha un sistema con una serie de servicios expuestos a la red, cuya única finalidad es la de registrar la actividad de cualquier individuo que interactúe con ellos. La diferencia con respecto a un sistema real en producción, es que la única intención del sistema es ser probado por un atacante, no ofrecer un servicio real.

Herramientas automatizadas V

6.5 .- HP WebInspect

Un claro ejemplo de la difusa línea existente entre las herramientas que deben utilizar los administradores de seguridad y los atacantes de dichos sistemas. image
Esta aplicación de HP es en realidad un escáner de vulnerabilidades web. Lo que lo diferencia frente a otras aplicaciones es que no sólo detecta dichas vulnerabilidades en páginas web, sino que incorpora opciones para explotar dichas vulnerabilidades, realizar ataques de fuerza bruta o incluso un “editor” para ataques de SQL injection. Debido a las limitaciones de la versión de prueba tan sólo es posible realizar el test de una página de ejemplo diseñada por la propia HP para ello. En cualquier caso en la imagen se puede ver una captura de pantalla en la que muestro los resultados del escaneo de dicha página.


 << Anterior                                                                                                

Para ver el resto de manuales puede acudir al índice de temas de seguridad en el enlace

inside jobs, una explicación de la crisis

sábado, 4 de junio de 2011

Sobre las privatizaciones

Os copio el enlace a una carta que me han publicado en el diario "El País" sobre el tema de las externalizaciones de servicio y las privatizaciones http://www.elpais.com/articulo/opinion/ERE/vienen/elpepiopi/20110603elpepiopi_8/Tes

viernes, 6 de mayo de 2011

VI Herramientas automatizadas (4)

6.4.- GFI Languard

GFI Languard es un escáner de vulnerabilidades comercial pensado para ser instalado en sistemas Windows que dispone de versiones de evaluación (30 días) e incluso de una versión freeware con ciertas limitaciones (por ejemplo sólo permite escanear cinco ips). image
Desde mi punto de vista es el mejor escáner de vulnerabilidades para sistemas windows, ya que en estos sistemas si se ejecuta como administrador permite incluso, de modo centralizado, ver los servicios o programas que se ejecutan en cualquier equipo de nuestra red, matar los servicios, aplicar parches de manera remota,....Incluso incluye una opción (Remediate vulnerabilities) que lanza un proceso que, de modo totalmente desatendido es capaz de desinstalar cualquier software no autorizado que se haya instalado en cualquier equipo de la red y reparar las vulnerabilidades detectadas.