TCP Split Handshake

Que mejor forma de retomar el blog que mandando un afectuoso salud a mis apreciados lectores, si los tuviera delante haríamos algo tal que así:

GigA --------->Hola:Lector

GigA:Hola + Mano<----------Lector

GigA:Mano<---------------->Mano:Lector

Etc.

Esto por si no lo habéis entendido es un saludo normal y corriente, que da paso a una conversación. Los humanos, fieles copiadores de lo que vemos en el mundo real decidimos trasladar esta forma de saludo a la informática, para que dos ordenadores pudieran iniciar su conversación lo harán de la misma forma. Es lo que conocemos como ThreeWay-Handsake , que originales somos:

Lo gracioso es que en el mundo virtual, al igual que en el real, pasamos del saludo a 3 bandas y pillamos a alguien desprevenido y le damos una colleja diciéndole: ¡ay maestro agujas!, ¡como vá capataz! (resto de saludos José Mota©), sin dejarle hablar ni nada. Esto entre colegas e incluso desconocidos puede ser gracioso, pero entre frías máquinas sin corazón es desastroso, tanto como que pueden reaccionar de formas raras, reiniciándose, parándose, ignorándote o accediendo a un nivel superior de funcionalidad (muchas veces esto también puede ocurrir con las mujeres), así una máquina se queda algo confusa cuando se le intenta abrir una conexión por ejemplo un SYN SEQ 1000, te responde con un SYN ACK 1000+1 SEQ 1500, y tu ignoras completamente su respuesta y vuelves a hacer otro SYN, y otro, y otro, y vas cambiando puerto, o le saturas un servicio a intentos de conexión, etc. Son muchas de las variedades de handshake que se pueden hacer en un escaner de puertos (para lo que vendría bien recordar esta entrada).

Sin embargo parecía que estaba todo inventado en lo que a saludos se refiere, cual es mi sorpresa cuando ayer me encontré esta interesante investigación de la gente de Macrothink, el TCP Split Handshake. Trasladado al lenguaje humano sería como realizar el saludo de forma normal, pero definir y recalcar cada una de las fases sin hacer nunca 2 cosas a la vez (¿?¿?), vale. Os pongo la imagen y me explico:

¿Qué es lo que se ha hecho?, separar el SYN, ACK que hace el servidor en dos pasos bien diferenciados, en dos paquetes distintos, algo que recoge perfectamente la RFC 793 en su página 27. Algo tan inocente como esto se ha probado con IDS/ IPS, routers, servidores, etc. con resultados más que soprendentes, y es que un servidor que tenga el protocolo de establecimiento de conexiones TCP alterado puede comprometer a sus clientes en una infinidad de casos. Veamos como reacciona el cliente cuando el servidor hace el split:

Lo que era un ThreeWay Handshake acaba convirtiéndose un FiveWay,,, de esto no decía nada la RFC 793. Otras curiosidades de esta particular forma de saludarse son que algunos IPS (lo probaron con un Juniper) no detectaron el ataque, sirviendo el splits tcp como técnica de evasión ya que, al no detectar la conexión como establecida no detectaba ataque alguno. En caso de NAT se encuentra de todo, desde un PIX-515 que era incapaz de hacer NAT y salir hacia otras redes con el splits TCP a un Cisco 2631 que se metía hasta Internet, luego parece que dependiendo del caso el NAT a priori no nos protegerá de este tipo de intentos de conexión. Finalmente, si estás ofreciendo un servicio en un puerto cualquiera, digamos el 22, y tu máquina es sometida a un escáner de red con un NMAP o similares no reaccionará tampoco de la forma habitual, pudiendo quedar oculto ese servicio o mal identificado:

Efectivamente esto para un atacante persistente no es un problema pero por ejemplo, para un barrido de un virus puede ser una “medida de seguridad”.

En resumen, este comportamiento anómalo en el establecimiento de conexiones por Split Handshake va a obligar a todo tipo de proveedores de equipos de comunicaciones, servidores, appliances de seguridad, etc. a añadir una excepción más o a contemplar que el ThreeWay Handshake no es la única forma de establecer una conexión TCP. Parece mentira que algo que lleva tantos años usándose no haya sido evaluado por muchos fabricantes en el 2010.

Ah, si queréis jugar tenéis scripts de ejemplo y capturas de Wireshark aquí, está hecho en Ruby y necesitareis las librerías libpcap para poder ejecutarlo.

Salu2

Forensic Analysis of a Network Scan

¡Hola! Volvemos a la carga con una vieja asignatura que teníamos aparcada desde hace tiempo: Análisis Forense. En el día de hoy hemos cogido un sencillo reto “for beginners” de los muchos existentes en los “scan of the month” del honeynet Project. En el mismo nos proporcionan un fichero binario con un tcpdump de varios megas que incluye una serie de tráfico TCP/IP que deberemos analizar para averiguar que ocurrió, el reto incluye la respuesta a varias preguntas de creciente dificultad. En este “mini-reto” utilizaremos herramientas tan comunes como Wireshark (también vale Ethereal o el sniffer que a vosotros os guste) y nmap. Vamos para allá:

1.- What is a binary log file and how is one created?

Una teórica para empezar, un fichero binario no es más que un archivo generado por el NIDS (Network Intrussion Detection System) Snort que, apoyándose en las habituales librerías Libpcap / Winpcap es capaz de depositar el tráfico exactamente igual que circula por la red en un fichero. La presencia de copias exactas de los paquetes nos garantiza que nada es modificado, ¡el requisito más importante en cualquier investigación! Esto nos lleva a la siguiente cuestión.

2.- What is MD5 and what value does it provide?

Bueno, creo que esto lo sabéis todos ya, lo vimos en esta entrada. El MD5 no es más que un algoritmo de un solo camino que calcula un valor hash, ese valor es único para cada entrada, o eso se supone. Existe un verdadero debate (el cual me está dando una idea para una futura entrada) acerca de la validez de un hash como mecanismo que garantiza que una evidencia no ha sido comprometida, debate acrecentado a medida que se descubren colisiones en los principales algoritmos: MD5 y SHA1. Cuando nos descargamos los archivos del reto nos piden que confirmemos el hash, en este caso lo hemos hecho:

3.- What is the attacker’s IP address?

Se acabó la literature, tenemos que averiguar la dirección IP del atacante, para ello (y dado que no es un fichero grande) examinaremos todas las IP origen y destino con Wireshark. Rápidamente podemos observar que aparecen las siguientes IP source:

192.168.0.9, 192.168.09.9, 192.168.0.254, 192.168.0.199, 192.168.0.1

Y las siguientes IP de destino (IP.dst):

192.168.0.9, 192.168.0.99

En la siguiente captura hacemos filtrado para asegurarnos que no hay otras IP.dst:

De forma curiosa, la regla no filtra aquellos destinos inalcanzables (¡pero eso es una pista!), ahora bien, ¿Cómo sabemos la IP del atacante a partir de esta información? Deberemos examinar los paquetes, no obstante algo huele a chamusquina cuando el 99% del tráfico procede de 192.168.0.9 y tiene de destino 192.168.0.99. No obstante nos aseguramos comprobando el tráfico que sale de 192.168.0.99 y eliminando el que tiene de destino 192.168.0.9 (genera demasiado ruido), obteniendo que no hay tráfico de estas características. Lo cual quiere decir que no hay respuesta de 192.168.0.99 hacia otros destinos distintos de 192.168.0.9, en este caso la ausencia de evidencia es la evidencia de que el atacante (¿supuesto atacante?) proviene de 192.168.0.9, probablemente por que el resto de destinos no existían (¿IP spoofing?).

4.- What is the destination IP address?

Como hemos hecho nuestro trabajo bien en la anterior cuestión, sabemos que la IP que estaba respondiendo a todas las peticiones era la 192.168.0.9. Parece que vamos bien ;-)

5.- We scanned de honeypot using five different methods. Can you identify the five different scanning methods, and describe how each of five works?

Comienza a subir la dificultad del análisis, nos piden averiguar las distintas tácticas de escaneo utilizadas. Vayamos por partes, nada más comenzar la captura se observa un ping hacia 192.168.0.99, justo después (Time 10.346091) comienzan a hacerse peticiones de tipo SYN desde el puerto origen 52198 hacia puertos fuera del rango reservado, el host escaneado responde con trazas [RST, ACK], lo que significa que se ha llegado al puerto pero no hay nadie escuchando, este podría ser nuestro primer tipo de escaneo:

Correspondiente a un nmap –sS (TCP SYN Scan) 192.168.0.99, el cliente debería responder con un ACK pero no lo hace, se queda a medio camino (half-open scanning).

En el Time 148007 se vuelve a producir un ping hacia 192.168.0.99, en ese momento se arranca otro tipo de escaneo, el wireshark nos cambia los colores, lo que ayuda ya que es muy llamativo:

Parece que se están tratando de hacer fingerprinting del sistema operativo, es decir, detectar que tipo de máquina hay detrás, en este caso el escaneo se concentra en los puertos habituales de servicios Windows. Por ahora parece que no tiene suerte nuestro atacante :) sin embargo poco tiempo después, línea de tiempo 150563 comienzan a aparecer paquetes ACK duplicados (el Wireshark los pinta de un negro terrorífico), que tienen su cumbre en el 150626, donde se comienza a recibir [SYN-ACK] en servicios habituales de Windows, lo que parece un nmap –sX (Xmas scan) bastante exitoso:

Ahora bien, justo después (se puede apreciar en la imagen anterior) el atacante trata de establecer conexiones al puerto SSH, pero con todos los flags TCP sin determinar, esto significa que estamos delante de un “Null Scan”, también llamado nmap –sN, si pinchamos en cualquier paquete veremos esta información dentro de los flags del protocolo de control de transmisiones:

Terminamos con un último ataque, se llama decoy scanning y sirve para que el host remoto no sepa identificar (a priori) quien es el host destino, decoy significa señuelo en inglés y lo que hace es realizar la misma petición desde varias IP inexistentes como las que vimos en 3), está muy bien para pasar desapercibidos aunque obviamente no tiene sentido en un entorno como el que estamos viendo:

Puede reproducirse con nmap y la opción –D. Y con esto hemos repasado los escaneos que se han realizado, como vemos es importante conocer los tipos de escáneres que permiten las herramientas, para ello podemos acudir por ejemplo a las técnicas que explican en la página del escáner más famoso.

6) Which scanning tool was used to scan our honeypot? How were you able to determine this?

Bien, en el punto anterior vimos que opciones de nmap había que habilitar para cada ataque, pero eso no significa ni mucho menos que haya sido esta herramienta, ¿verdad? Necesitaremos utilizar un NIDS para analiza las trazas y verificar si detecta algún ataque y por parte de qué, para ello no hay nada como Snort, que nos devolverá algo parecido a esto:

[**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] - 22539

[**] [111:9:1] spp_stream4: STEALTH ACTIVITY (NULL scan) detection [**] - 3996

[**] [111:12:1] spp_stream4: NMAP FINGERPRINT (stateful) detection [**] - 9

[**] [1:628:1] SCAN nmap TCP [**] - 9

Luego ahí tenemos a nuestro principal sospechoso.

7) What is the purpose of port scanning?

Bueno, la razón de realizar un escáner de puertos es bastante sencilla. Identificar todos los servicios y puertos abiertos que el host “víctima” está ofreciendo. O dicho de otro modo, identificar los posibles puntos de entrada a su sistema. Es una definición algo tosca pero nos vale :)

8) What ports are open on our honeypot?

Tal y como vimos en 5) los mecanismos para establecer una conexión TCP/IP incluyen el famoso saludo “a 3 bandas” o 3-way handshake, de tal forma que cuando hay un puerto abierto y dependiendo del ataque lo podemos identificar de varias formas. A grandes rasgos para no extender la entrada en demasiado he recolectado todos los paquetes emitidos por 192.168.0.99 con [SYN,ACK], es decir donde hay servicios, con ello he identificado los puertos:

- 22 / SSH

- 53 / DNS

- 80 / HTTP

- 443 /HTTPS

- 111 / SUNRPC

- 32768 / FILENET

9) Bonus Question: What operating system was the attacker using?

Esta cuestión puede parecer a priori la más difícil de responder, obtener el sistema operativo origen a partir de unas trazas TCP/IP podría ser un problema si no fuese por herramientas como p0f, Ettercap o Network Miner, las mismas utilizan técnicas de fingerprinting pasivo a raíz de los valores TTL, el tamaño de la ventana, type of service, (TOS) etc. Se puede profundizar en estas técnicas aquí. Yo he escogido Network Miner, la cual nos podría haber facilitado el trabajo desde el principio (pero entonces no habría sido tan divertido ;-) ) ya que es una herramienta de análisis forense en red. Ella nos muestra que tanto host atacante como host atacado eran Linux:

Y esto es todo por hoy, el análisis forense es magnífico para repasar y profundizar en los habituales conocimientos de redes, sistemas operativos, etc.

Buen fin de semana :)

NdA: Estoy teniendo bastantes problemas para escalar las imágenes sin perder detalle, así que se ven bastante pequeñas, siento el inconveniente.

Adobe getIcon Universal Exploiter

En las visitas habituales a milw0rm hay días aburridos en que apenas surgen exploits nuevos, otros en los que los que aparecen apenas están documentados y no acaban de describir que vulnerabilidad explotan (y como) y finalmente están los días normales es que aparecen programas de uso común para Windows y Linux, que son las plataformas con las que los usuarios trasteamos más. En uno de esos días de este mes de Septiembre surgió el exploit para Adobe 9.0 y 8.1.2 titulado “getIcon Universal Exploiter” el cual tenía una particularidad, estaba perfectamente documentado y era bastante fácil de explotar (así como de encontrar clientes explotables xd).

La vulnerabilidad, conocida por Adobe desde Julio del año pasado aprovecha el típico desbordamiento de buffer en la pila al no controlar los argumentos que se pasan al método “getIcon” (de ahí el original nombre). En los enlaces publicados en milw0rm hay amplia información de la vulnerabilidad, código ensamblador que muestra las llamadas no controladas, etc. Etc. A grandes rasgos el exploit desarrollado en Python aplica la conocida técnica de “Heap Spraying” para inyectar el payload que en este caso será una Shell remota, para ello formaremos un archivo .pdf que incluya una librería desarrollada en C y que luego incluiremos en el pdf mediante el exploit desarrollado en python. Me explico paso a paso:

1) En el archivo evil_payload.c se genera un socket que abrirá la conexión a la IP y puerto que indiquemos (aquí normalmente pondremos nuestra IP publica y un puerto que nos asegure no bloquee el firewall, digamos, el 80), además mostrará un error que mitigue las sospechas al usuario que abre el pdf. A partir de este código en C debemos generar la librería a inyectar en el pdf, si disponéis del Visual C++ 2008 Express Edition (gratuito) se puede compilar en un periquete:

Con la opción /LD especificamos que se genere una librería de enlace dinámico (.DLL, para más info sobre compilaciones acudir aquí:

2) Una vez que tenemos la librería toca darle paso al Script de Python, si le echamos un ojo vemos que lo único que hace es manipular el .pdf que le digamos inyectándole la librería, incluir un payload en javascript que genere la excepción y poco más:

Ejecutamos el script y creamos el .pdf especialmente modificado:

3) Llegado este punto ya tenemos nuestro documento .pdf especialmente manipulado para que las versiones no actualizadas de Adobe hagan “crash”. Probablemente al hacer este último paso os haya saltado el antivirus, y es que ya han pasado 3 semanas desde que se publicó el exploit y son varios los que lo detectan, en concreto 14 según virustotal*:

Pero claro, esto es relativo. Una idea sencilla para utilizarlo es compartir el archivo con el Emule bajo un nombre sugerente (de ahí el que yo he escogido) y esperar que la gente se lo vaya bajando, no es sofisticado pero funciona. De todas formas todavía no tendremos nada, si os fijáis nos falta algo, si queremos que se nos abra una Shell remota (para eso pusimos nuestra IP y puerto), ¿alguien tendrá que estar escuchando, verdad? Por suerte esto es facilísimo con netcat:

Recordar que deberéis tener configurado el NAT en vuestro router para que la conexión pueda abrirse, después solo queda esperar que “piquen” y se nos abrirá una bonita Shell. Fácil a la par que peligroso, ¿verdad?

Espero que os haya gustado, un saludo!

Nota*: He ofuscado el código de la librería, he eliminado los comentarios, renombrado variables, etc. pero solo he conseguido que un par de antivirus más no lo detecten hasta lograra una tasa de 12/41 :-( Se aceptan sugerencias :)

Sys Internals

Hagamos un Kit Kat en esta semana intensa de vuelta a la normalidad para presentaros un pack de herramientas de Windows, si con las Net Tools teníamos casi todo lo que hace falta para trabajar a nivel de red (como vimos aquí ) con Sys Internals tendremos un control mucho mayor sobre lo que pasa en nuestra máquina Windows (preferiblemente XP, algunas de ellas no se llevan bien con WVista y W7, otras sí) a nivel de procesos, registro de Windows, arranque del sistema operativo, conexiones de red e incluso un detector de Rootkits!, Merece la pena:

Process Explorer (): Un básico con unos añitos del que ya se oyó hablar cuando vimos el Svchost Analyzer. Procesos padres, hijos, consumo de CPU, hilos lanzados, consumo de CPU, etc. Una gozada:

PSTools : Pack de herramientas de gestión de procesos, con las que podremos jugar todo lo que queramos en nuestros sistema (o en otros xD) incluye:

- PsExec: Ejecuta procesos de forma remota.

- PsFile: Muestra archivos abiertos de forma remota.

- PsGetSid: Muestra el SID de un equipo o un usuario.

- PsInfo: Muestra información acerca de un sistema.

- PsKill: Elimina los procesos por el nombre o Id. de proceso.

- PsList: Muestra información acerca de procesos.

- PsLoggedOn: Averigua quién ha iniciado sesión de forma local y a través de recursos compartidos (origen completo incluido).

- PsLogList: Vuelca los registros de eventos.

- PsPasswd: Cambia las contraseñas de cuenta.

- PsService: Muestra y controla los servicios.

- PsShutDown: Apaga y reinicia opcionalmente un equipo.

- PsSuspend: Suspende los procesos.

- PsUptime: Muestra el tiempo durante el que se ha ejecutado un sistema desde el último reinicio (la funcionalidad de PsUptime se ha incluido en PsInfo).

AutoRuns: El comando msconfig nos permite editar el boot.ini, ver que servicios se arrancan con nuestro Sistema Operativo y que programas se ejecutarán sin necesidad de que estén en la carpeta de “Inicio”, todo eso está muy bien y es básico, pero con AutoRuns alcanzaremos una granularidad mucho mayor, librerias, drivers, tareas del scheduled, ¡codecs!, de todo lo que os podáis imaginar. Muy útil para entender como funciona nuestro sistema operativo:

RootkitRevealer: ¿Crees que tu antivirus no lo detecta todo? Entonces crees bien, si quieres echar un vistazo rápido a tu registro de Windows y detectar inconsistencias, buscar el gato encerrado que hay en tu sistema operativo y alimentar tu paranoia, esta es tu herramienta:

TCPView: Yo creo que si los millones de Script Kiddies del mundo que buscan en los foros el Puerto del messenger conocieran esta herramienta saldrían hackers como setas. No, en serio, con TCPView tendremos un conocimiento casi total sobre todos los flujos TCP y UDP que llegan y salen de nuestra máquina, su estado, el proceso que los inició (algo parecido al netstat –ban pero más profundo) así como la posibilidad de matar los procesos o cerrar las conexiones que no tengan buena pinta, muy util:

Poco a poco vamos ampliando nuestro kit de herramientas, ¿verdad?

Espero que tengáis una vuelta “amable”, ¡salu2!

Super Tool Box

Pásame la llave allen, la crimpadora y la llave inglesa, que te voy a hacer la 3/14.

Respuesta: ¿Pero tu no eras informático?

Hacía tiempo que no veía un pack de esos “imprescindibles” pero gracias a un compi he podido descubrir las Net Tools , que no son más que un conjunto de herramientas completísimo que funciona bajo plataformas Windows y va como la seda. 175 herramientas en apenas 25 MB que incluyen desde GeoLocator, codificador en base 64, obtención de hash, Nmap, e-mail spoofing, analizador de cookies, programas de esteganografía, etc. etc. Todo de forma gratuita y en entorno “ventanita” para la mayor de las facilidades:

Además incluye dos screensavers bastante graciosos, mejor que los veáis vosotros mismos :-)

Lista completa de herramientas (vereis que chorrazo):

1) IP Address Scanner

2) IP Calculator

3) IP Converter

4) Port Listener

5) Port Scanner

6) Ping

7) NetStat (2 ways)

8) Trace Route (2 ways)

9) TCP/IP Configuration

10) Online - Offline Checker

11) Resolve Host & IP

12) Time Sync

13) Whois & MX Lookup

14) Connect0r

15) Connection Analysator and protector

16) Net Sender

17) E-mail seeker

18) Net Pager

19) Active and Passive port scanner

20) Spoofer

21) Hack Trapper

22) HTTP flooder (DoS)

23) Mass Website Visiter

24) Advanced Port Scanner

25) Trojan Hunter (Multi IP)

26) Port Connecter Tool

27) Advanced Spoofer

28) Advanced Anonymous E-mailer

29) Simple Anonymous E-mailer

30) Anonymous E-mailer with Attachment Support

31) Mass E-mailer

32) E-mail Bomber

33) E-mail Spoofer

34) Simple Port Scanner (fast)

35) Advanced Netstat Monitoring

36) X Pinger

37) Web Page Scanner

38) Fast Port Scanner

39) Deep Port Scanner

40) Fastest Host Scanner (UDP)

41) Get Header

42) Open Port Scanner

43) Multi Port Scanner

44) HTTP scanner (Open port 80 subnet scanner)

45) Multi Ping for Cisco Routers

46) TCP Packet Sniffer

47) UDP flooder

48) Resolve and Ping

49) Multi IP ping

50) File Dependency Sniffer

51) EXE-joiner (bind 2 files)

52) Encrypter

53) Advanced Encryption

54) File Difference Engine

55) File Comparasion

56) Mass File Renamer

57) Add Bytes to EXE

58) Variable Encryption

59) Simple File Encryption

60) ASCII to Binary (and Binary to ASCII)

61) Enigma

62) Password Unmasker

63) Credit Card Number Validate and Generate

64) Create Local HTTP Server

65) eXtreme UDP Flooder

66) Web Server Scanner

67) Force Reboot

68) Webpage Info Seeker

69) Bouncer

70) Advanced Packet Sniffer

71) IRC server creater

72) Connection Tester

73) Fake Mail Sender

74) Bandwidth Monitor

75) Remote Desktop Protocol Scanner

76) MX Query

77) Messenger Packet Sniffer

78) API Spy

79) DHCP Restart

80) File Merger

81) E-mail Extractor (crawler / harvester bot)

82) Open FTP Scanner

83) Advanced System Locker

84) Advanced System Information

85) CPU Monitor

86) Windows Startup Manager

87) Process Checker

88) IP String Collecter

89) Mass Auto-Emailer (Database mailer; Spammer)

90) Central Server (Base Server; Echo Server; Time Server; Telnet Server; HTTP Server; FTP Server)

91) Fishing Port Scanner (with named ports)

92) Mouse Record / Play Automation (Macro Tool)

93) Internet / LAN Messenger Chat (Server + Client)

94) Timer Shutdown/Restart/Log Off/Hibernate/Suspend/ Control

95) Hash MD5 Checker

96) Port Connect - Listen tool

97) Internet MAC Address Scanner (Multiple IP)

98) Connection Manager / Monitor

99) Direct Peer Connecter (Send/Receive files + chat)

100) Force Application Termination (against Viruses and Spyware)

101) Easy and Fast Screenshot Maker (also Web Hex Color Picker)

102) COM Detect and Test

103) Create Virtual Drives

104) URL Encoder

105) WEP/WPA Key Generator

106) Sniffer.NET

107) File Shredder

108) Local Access Enumerater

109) Steganographer (Art of hiding secret data in pictures)

110) Subnet Calculater

111) Domain to IP (DNS)

112) Get SNMP Variables

113) Internet Explorer Password Revealer

114) Advanced Multi Port Scanner

115) Port Identification List (+port scanner)

116) Get Quick Net Info

117) Get Remote MAC Address

118) Share Add

119) Net Wanderer

120) WhoIs Console

121) Cookies Analyser

122) Hide Secret Data In Files

123) Packet Generator

124) Secure File Splitting

125) My File Protection (Password Protect Files, File Injections)

126) Dynamic Switch Port Mapper

127) Internet Logger (Log URL)

128) Get Whois Servers

129) File Split&Merge

130) Hide Drive

131) Extract E-mails from Documents

132) Net Tools Mini (Client/Server, Scan, ICMP, Net Statistics, Interactive, Raw Packets, DNS, Whois, ARP, Computer's IP, Wake On LAN)

133) Hook Spy

134) Software Uninstaller

135) Tweak & Clean XP

136) Steganographic Random Byte Encryption

137) NetTools Notepad (encrypt your sensitive data)

138) File Encrypter/Decrypter

139) Quick Proxy Server

140) Connection Redirector (HTTP, IRC, ... All protocols supported)

141) Local E-mail Extractor

142) Recursive E-mail Extractor

143) Outlook Express E-mail Extractor

144) Telnet Client

145) Fast Ip Catcher

146) Monitor Host IP

147) FreeMAC (MAC Address Editor)

148) QuickFTP Server (+user accounts support)

149) NetTools Macro Recorder/Player (Keybord and Mouse Hook)

150) Network Protocol Analyzer

151) Steganographic Tools (Picture, Sounds, ZIP Compression and Misc Methods)

152) WebMirror (Website Ripper)

153) GeoLocate IP

154) Google PageRank Calculator

155) Google Link Crawler (Web Result Grabber)

156) Network Adapter Binder

157) Remote LAN PC Lister

158) Fast Sinusoidal Encryption

159) Software Scanner

160) Fast FTP Client

161) Network Traffic Analysis

162) Network Traffic Visualiser

163) Internet Protocol Scanner

164) Net Meter (Bandwidth Traffic Meter)

165) Net Configuration Switcher

166) Advanced System Hardware Info

167) Live System Information

168) Network Profiler

169) Network Browser

170) Quick Website Maker and Web Gallery Creator

171) Remote PC Shutdown

172) Serial Port Terminal

173) Standard Encryptor

174) Tray Minimizer

175) Extra Tools (nmap console & win32 version)

Casi nada,,, ¡a jugar!

Un saludo

Firewall Suizo

Jamon de York, mantequilla, un firewall y pan de molde, eso sí es un buen sándwich.

Respuesta: Sólo si el firewall es Suizo.

Hoy vamos a hablar de una tecnología nueva en el mundo de la Seguridad de la Información, concretamente en el capítulo de “Seguridad de las comunicaciones”.  Exacto, vamos a hablar de los Firewall (y no, no me refiero a la película de Harrison Ford). ¿Por qué digo nueva? Bueno, principalmente por que considero que estos dispositivos tienen que estar al día siempre. Un firewall tiene que ser tan nuevo como los servicios de nuestra empresas, o mejor dicho, sus políticas de seguridad.

Repasemos, un cortafuegos sirve (a muy grosso modo) para separar redes distintas dejando tan solo los flujos de comunicación que consideremos legítimos o válidos. Por ejemplo, el firewall que nos separe del mundo Internet tendrá prohibido todo el tráfico de entrada, excepto algún servicio que publiquemos al mundo, llámese mi página Web. Lo mismo ocurrirá con los flujos de salida. Estos filtrados pueden hacerse de muchas formas dependiendo del nivel al que trabaje el cortafuegos:

1.- Filtrado de paquetes (1ª generación): Analiza los paquetes de entrada y ver si hay alguna regla definida que los deje pasar (suponemos que todo se rechaza por defecto). Vulnerables a IP Spoofing. Nivel 3 OSI.

2.- Filtrado por estado (2ª generación): Estos cortafuegos mantienen “en memoria” el rastro de cada conexión que se permite, detectando comportamientos anómalos o sospechosos como un ataque DOS. Pueden llegar al Nivel 7 OSI.

3.-  Proxy – Firewall (3ª generación): Trabajando en la capa de aplicación estos dispositivos son capaces de inspeccionar el tráfico de protocolos y servicios que trabajan a este nivel, detectando posibles exploits, comandos no permitidos, etc.

4.- Kernel Proxy – Firewall (4ª generación): Incluyen inspección profunda de paquetes, tecnología de detección / prevención de intrusiones, etc.

 Independientemente de que generación sea nuestro firewall, tendrá una base de reglas que a buen seguro habrá que revisar periódicamente. Estas reglas deben basarse en unos pocos principios básicos:

-          Todo se rechaza por defecto.

-          Solo se autoriza tráfico para servicios reconocidos en la organización.

-          La regla debe ser tan restrictiva como sea posible, a nivel de puertos (conociendo los puertos que manejan los servicios) y a nivel de IP (conociendo quienes van a demandar estos servicios).

-          Si un servicio se da de baja o cambia, deben cambiar o darse de baja las reglas asociadas al servicio (llamémosle gestión de cambios controlada).

Si no trabajamos con estos principios, nos encontraremos con cositas como esta:

Tiene pinta de ser un FWSM suizo. 

En mi experiencia el principal problema que he encontrado ha sido el de reglas obsoletas, que cubren servicios inexistentes o para máquinas que han migrado o simplemente desaparecido. Una solución es establecer un periodo de caducidad para las reglas, de tal forma que una alerta te avise el día que estas caduquen, no obstante esto se puede volver inmanejable en organizaciones que tengan decenas de firewall y por tanto cientos de reglas. No es un problema de fácil solución, la caducidad es una buena idea ya que obliga a revisar lo implantado, ahora bien, ¿Cuáles revisar de todas las decenas que pueden caducar en un día sin que el  administrador se vuelva loco? Se me ocurre comenzar por aquellas reglas por las que no pasa tráfico, estableciendo mecanismos como la baja automática en aquellas que no se produce un “match” durante 3 meses, siendo ese periodo configurable según la criticidad de las redes que se separan, no es lo mismo una red de ofimática que una de gestión, ni cuanto menos una red de datos (y todo ello sin provocarte DOS).

Mantener unas políticas acordes a nuestra arquitectura de red es crítico para la seguridad de nuestras redes, establecer los controles para verificar que se cumplen las políticas, también. Es la única forma de que nuestro queso tenga los agujeros que necesita, ni uno más, ni uno menos.

Más info en:

http://www.conectronica.com/200812052004/Nuevos-enfoques-en-el-an%E1lisis-de-la-tecnolog%EDa-firewall-componente-esencial-para-la-seguridad-red.html

http://en.wikipedia.org/wiki/Firewall

Salu2!! (Y cuidado en la vuelta de vacas xD)

Internet, Puertos, y 6 meses de experiencia.

Mientras uno se dedica a asimilar consultas de seguridad de todo tipo, ganando experiencia poco a poco viendo tecnologías que uno se pregunta como es posible que no las haya visto en la Universidad. Llámese SAP, llámese Solaris, llámese AIX, Citrix, Tarantela, getAccess etc. etc. Y haciendo comentarios de Seguridad mitad Normativa, mitad experiencia, mitad google, te llegan momentos como este, hablando hablando te llega la cuestión:

¿Pero tu sabes como se conecta un cliente a un servidor? A lo que me digo,,, vaya chorrada! No recuerdo los pasos exactos, pero era algo así como que el cliente realizaba la solicitud de conexión al servidor por la IP y puertos del servicio, el servidor aceptaba la petición ó la rechazaba según conveniera e indicaba al cliente que la conexión está establecida tal tal

Vamos, lo que uno recuerda de Redes de hace 6 años, totalmente de 2º de carrera, hasta ahí bien, en ese momento te lanzan otra pregunta ¿y que pasa con la negociación de puertos? Uno frunce el ceño,, y piensa ¿lo cualo? For example, si un servicio usa el puerto 80 (por decir uno raro), el cliente usa el puerto 80, (¡¡Bocina Camionero!!)

No, el cliente no tiene por qué usar ese puerto!! Luego los puertos de Firewall abiertos deben ser los del rango de negociación (Cara de asustado), ¡Pero como no recuerdo eso!, ¿Por que nadie me lo dijo nunca? Entonces uno se va derechico al google, y corrobora con un artículo del año de la polca:

**************************************

Cuando abrimos el "navegador" y tecleamos una pagina, el funcionamiento sería el siguiente:

1) Nuestro PC para abrir el socket necesita conocer la dirección del destino (el puerto ya lo sabe, ya que por defecto en html es el 80). Esta dirección debe estar en formato xxx.xxx.xxx.xxx (4 numeros separados por puntos -dirección IP-)

2) Nuestro PC, investiga si conoce el ordenador destino (es decir investiga un nombre, por ejemplo http://www.microsoft.com/). Si no lo conoce debe investigar.

3) Aunque para esta investigacion intervienen varios pasos (fichero host, mascaras de subred, etc), vamos a simplificarlo. Nuestro PC se lo pregunta al DNS de nuestro servidor (recordad que ponemos DNS al definir una conexion telefonica, o bien nuestro proveedor nos lo da automaticamente al establecerlo.

4) DNS = Domain Name Solver. Es decir nos va a resolver por nombre de dominio su dirección . Por tanto nos devuelve su dirección IP.

5) Con esto el navegador ya puede abrir un socket desde nuestra dirección , y un puerto "cualquiera" !!! libre de nuestro PC y la dirección del destino y el puerto 80.

6) Es decir lo que hace en ese momento es pedirle a nuestro propio PC un puerto libre, imaginemos que le dá el 2122, y entonces establece un canal de comunicacion entre ambas maquinas desde el puerto 2122 en el cual "escuchará" nuestro navegador para esa conexion y el 80 en el destino, que será el que nos pase la informacion (la pagina web).

**************************************





Y se va al CMD asustado, a corroborarlo... hace un netstat -na y observa:

¡Pero como no he descubierto esto antes! Es de cajón de madera de chopo... y no sabes que hacer, si clamar al cielo o decirte, será cosa de la experiencia...