Anda di halaman 1dari 20

Problemas de Seguridad en servidores de FTP

Los servidores de FTP annimo estn sometidos a abusos de entre los que destacan principalmente 2: Distribucin de software o material con copyright a travs del servidor.

Fallo de seguridad en el servidor debida a una mala configuracin del servidor de FTP.

Los archivos annimos se pueden conseguir de muchas formas. La mayora de las veces es a travs de servidores FTP annima, pero no hay que olvidar otros medios como FSP o NFS. Algunos servidores permiten la existencia de zonas con permisos de escritura (directorios incoming) para que los usuarios puedan dejar archivos. Pero si los usuarios annimos tienen permiso para leer de ese directorio la probabilidad de abuso por parte de dichos usuarios aumenta. Ciertos usuarios consiguen y distribuyen listas (listas warez) que enumeran sitios con vulnerabilidad y la informacin que contienen. stas listas suelen incluir los nombres de directorios con permisos de escritura y la localizacin de software pirata, as como archivos de password u otra importante informacin. Estos usuarios se aprovechan de la poca importancia que dan los administradores a que este tipo de abuso exista, o bien de la confianza que tienen dichos administradores en la configuracin de su servidor. A parte del problema del pirateo informtico, existe el riesgo de que un mal configurado servidor puede proporcionar alguien la capacidad de ejecutar procesos con UID (identificador de usuario) del demonio de FTP. Permisos y contenido de los directorios. La norma ms importante a seguir a la hora de configurar los permisos de los directorios del servidor de ftp es que el directorio raz (~ftp) y sus subdirectorios no deben ser posedos por el usuario FTP. ste es el problema de configuracin ms corriente. Si no quiere perder mucho tiempo en este captulo de los permisos le recomendamos que haga que el directorio raz y los subdirectorios del servidor

sean propiedad de root y del grupo system, y que slo root tenga permiso de escritura. Un ejemplo de posible directorio del servidor de FTP annimo sera: drwxr-xr-x 7 root drwxr-xr-x 25 root drwxr-xr-x 2 root drwxr-xr-x 2 root drwxr-xr-x 10 root system 512 Jan 10 system 512 Jan 10 system 512 Jan 10 system 512 Jan 10 system 512 Jan 10 11:30 ./ 11:30 ../ 11:30 bin/ 11:30 etc/ 11:30 pub/

Si hubiera dado la propiedad de los directorios al usuario ftp, dejndole adems permiso de escritura, un intruso podra ser capaz de aadir archivos como .rhosts o modificar otros archivos. Los archivos y libreras, especialmente los usados por el demonio de FTP y los que se encuentran en los directorios~ftp/bin y ~ftp/etc deben tener las mismas protecciones que estos directorios. Hasta ahora se ha hecho una descripcin somera de los permisos. Si desea afinar ms los permisos reducindolos al mximo siga los consejos que se van a exponer a continuacin. El directorio ~ftp debe poseerlo root (No FTP. Esto es un agujero de seguridad) y el mismo grupo al que pertenece ftp. El permiso debe ser 555 (read, nowrite, execute). El directorio ~ftp/bin y cualquier archivo incluido en l deben tener los permisos 111(noread, nowrite, execute), pertencer a root y a un grupo de root, por ejemplo whell. Adems debe contener el programa ls para que de esta forma un usuario de FTP pueda listar los archivos. El directorio ~ftp/etc debe tener los mismos permisos que ~ftp/bin. Hay que incluir en ~ftp/etc una copia de los archivos/etc/passwd y /etc/group no sin antes eliminar de ellos todo lo necesario para que slo incluyan las lineas correspondientes a los usuarios root, daemon, uucp, y ftp en passwd y al grupo de ftp en group. No olvidar eliminar todos los passwords de estos archivos sustituyendolos por un * (de

esta forma evitamos que un usuario tenga acceso a password encriptados susceptibles de ser atacados por un programa craqueador) y el resto de informacion como se ve en el ejemplo: root:*:0:0:Ftp maintainer:: ftp:*:400:400: Anonymous ftp:: De todas formas estos archivos no son necesarios y su ausencia slo se notar en que al hacer un listado de archivos a traves de ftp ste no mostrar los nombres de usuario ni de grupo de los archivos y en su lugar mostrar su nmero equivalente. El directorio ~ftp/pub debe ser propiedad del administrador y del grupo de ftp con permisos 555. Se puede poner adems la opcion set-group-id (2555) para que los nuevos archivos que se creen tengan al mismo grupo como propietario. Los archivos que se incluyan tambien con permiso 555. Debido a que las nuevas versiones de los servidores de ftp permiten ejecutar comandos como chmod, es necesario configurarlos para evitar que se puedan cambiar los permisos. Detalles de seguridad. Para conseguir una mayor seguridad, otras cosas a hacer son: touch ~ftp/.rhosts touch ~ftp/.forward chmod 400 ~ftp/.rhosts chmod 400 ~ftp/.forward de esta forma nos aseguramos que estos archivos tienen longitud cero (si es que antes no existan, si ste es el caso, borrarlos previamente) y son posedos por root.

Si se montan discos de otras mquinas sobre la jerarqua de ftp, montarlo como de slo lectura. Por ejemplo una entrada del archivo /etc/fstab podra ser: other:/u1/linux /home/ftp/pub/linux nfs ro,noquota,nosuid,intr,bg 1 0 Cmo saber si un servidor es seguro? Pasos a seguir por un administrador para asegurarse que la seguridad del sistema no est siendo comprometida: 1.- Asegurarse que el servidor de ftp no tiene el comando SITE EXEC haciendo telnet al puerto 21 y tecleando SITE EXEC. Si lo tuviera asegurarse que es la version ms moderna (es decir Wu-FTP 2.4). En antiguas versiones esto permita ganar a cualquiera una shell a travs de ese puerto. 2.- Comprobar que nadie puede conectarse ni crear archivos ni directorios en el directorio principal. Si cualquiera puede conectarse como anonymous FTP y crear archivos como .rhosts y .forward, se garantiza acceso instantaneo a cualquier intruso. 3.- Asegurarse que el directorio principal no esta poseido por ftp. Si lo estuviera un intruso podria ejecutar SITE CHMOD 777 en el directorio principal y luego en los archivos para darle acceso. El comando SITE CHMOD debera ser eliminado porque usuarios annimos no necesitan ningun privilegio extra. 4.- Mirar que ningn archivo ni directorio est poseido por ftp. Si lo est un intruso podr reemplazarlos con su propia versin troyana. 5.- Hay varios errores en antiguos demonios por lo que es importante asegurarse que se tiene la versin ms moderna. Polticas de seguridad. 1.- Comprobar la no existencia de archivos o directorios inusuales en el directorio incoming especialmente busca por archivos ocultos que normalmente no son mostrados mediante "ls". 2.- Revisar peridicamente los archivos log de ftp buscando actividades inusuales del servidor, como gran cantidad de conexiones, identificadas como "puts" y

"gets", por ejemplo, en un breve intervalo de tiempo. Esto puede mostrar un uso del servidor como intercambiador de software pirateado, que a la larga puede provocar: que legtimos usuarios no puedan acceder al sistema por haber demasiadas conexiones, la cada del sistema o el consumo de espacio de disco en el sistema. Conviene por tanto desarrollar herramientas de anlisis de los archivos logs, buscando "STOR" y "RETR" sesiones, adaptadas a la actividad del servidor. 3.- FSP es un servidor de archivos annimo que es similar a FTP. Est basado en UDP y a menudo utiliza el puerto privilegiado 21. Sin embargo, existen casos en que usuarios o intrusos han establecido su propio servicio de FSP sobre un puerto UDP no privilegiado. Aunque FSP no es en s un problema, es susceptible de sufrir los mismos abusos que FTP. Por tanto, si no va a ofrecer un servicio FSP, examine el sistema mirando los servicios que se ofrecen a travs del puerto 21. El problema aparece cuando un usuario ofrece un servicio FTP o FSP no autorizado en un puerto no privilegiado, debido a la dificultad de deteccin, hacindose necesario un anlisis de trfico de los puertos. 4.- Asegrese de que no se ha producido ninguna modificacin de algn fichero existente. Muestre especial inters en el propio demonio de ftp y en archivos con directo impacto en la seguridad del sistema como ~ftp/.rhosts. Se conocen casos de servidores en los que se reemplaz el demonio de ftp por una versin del caballo de Troya. 5.- Utilice herramientas como Tripwire que permiten la comprobacin de la integridad de sus archivos. Qu hacer si nuestro servidor est siendo usado ilegalmente? 1.- Si se detecta el uso del servidor como distribuidor de software pirateado, debe revisar los directorios y archivos creados como resultado de dicho abuso, y tome las medidas oportunas de acuerdo a las normas de su organizacin. 2.- Si descubre entre el material descubierto cualquier referencia a otros sitios, como por ejemplo listas warez, haga lo siguiente:

Determine desde dnde se produjo el acceso no autorizado, pues lo ms probable es que la seguridad de estos sitios est siendo igualmente comprometida. Revise los contenidos de los archivos o directorios en busca de posibles referencias a cuentas o passwords de otros servidores. Notifique cualquier descubrimiento a la organizacin correspondiente. SFTP Una de las funcionalidades deseables de wordpress a nivel de seguridad que muchos echamos de menos, es la posibilidad de realizar transferencias seguras en wordpress bajo conexiones SSH, SFTP (Secure FTP). A fecha de hoy WordPress en su ltima versin solo permiteconexiones a travs del protocolo FTP, que por definicin del mismo es inseguro al no encriptar los datos de autentificacin, lo que hace que se transmitan los datos de acceso en plano. Si bien es cierto, que WordPress permite tambin utilizar certificados SSL en las conexiones FTP para proporcionar seguridad a la conexin (FTPS), no lo es menos que la mayora de servidores FTP no disponen de certificados SSL, y esta cifra aumenta cuando hablamos de hosting compartido. Es por ello por lo que en la mayora de ocasiones se utilizan conexiones FTP inseguras. Si deseamos poder realizar transferencias seguras en wordpress necesitamos recurrir a un plugin de terceros: SSH SFTP updater. Este plugin trabaja sobre la librera php phpseclib para establecer conexiones SFTP, y por lo tanto transferir archivos de forma segura en wordpress. Su instalacin es sencilla tanto por medio del gestor de plugins de wordpress, como manualmente (descargar y descomprimir en la carpeta plugins dentro de wp-content). Una vez instalado solo queda activarlo para poder hacer uso de l.

Como

podemos

comprobar SSH

SFTP

updater nos

permite

establecer

conexiones SSH validndonos tanto con nombre de usuario y contrasea como con sistemas de clave pblica y privada.

De una forma sencilla y fcil podemos aadir soporte SFTP y realizar transferencias seguras en wordpress por medio de este plugin. TFTP TFTP son las siglas de Trivial file transfer Protocol (Protocolo de transferencia de archivos trivial). Es un protocolo de transferencia muy simple semejante a una versin bsica de FTP. TFTP a menudo se utiliza para transferir pequeos archivos entre ordenadores en una red, como cuando un terminal X Window o cualquier otro cliente ligero arrancan desde un servidor de red. Algunos detalles del TFTP:

Utiliza UDP (en el puerto 69) como protocolo de transporte (a diferencia de FTP que utiliza los puertos 20 y 21 TCP). No puede listar el contenido de los directorios.

No existen mecanismos de autenticacin o cifrado. Se utiliza para leer o escribir archivos de un servidor remoto.

Soporta tres modos diferentes de transferencia, "netascii", "octet" y "mail", de los que los dos primeros corresponden a los modos "ascii" e "imagen" (binario) del protocolo FTP.

Detalles de una sesin TFTP Ya que TFTP utiliza UDP, no hay una definicin formal de sesin, cliente y servidor, aunque se considera servidor a aquel que abre el puerto 69 en modo UDP, y cliente a quien se conecta. Sin embargo, cada archivo transferido va TFTP constituye un intercambio independiente de paquetes, y existe una relacin cliente-servidor informal entre la mquina que inicia la comunicacin y la que responde.

La mquina A, que inicia la comunicacin, enva un paquete RRQ (read

request/peticin de lectura) o WRQ (write request/peticin de escritura) a la mquina B, conteniendo el nombre del archivo y el modo de transferencia.

B responde con un paquete ACK (acknowledgement/confirmacin), que

tambin sirve para informar a A del puerto de la mquina B al que tendr que enviar los paquetes restantes.

La mquina origen enva paquetes de datos numerados a la mquina

destino, todos excepto el ltimo conteniendo 512 bytes de datos. La mquina destino responde con paquetes ACK numerados para todos los paquetes de datos.

El paquete de datos final debe contener menos de 512 bytes de datos para

indicar que es el ltimo. Si el tamao del archivo transferido es un mltiplo exacto de 512 bytes, el origen enva un paquete final que contiene 0 bytes de datos NFS Maestro Client utiliza RPCSEC_GSS (RFC2203), que permite que los protocolos RPC tengan acceso a la interfaz de programacin de aplicaciones Generic Security Services Application Programming Interface (GSS-API) para garantizar la integridad y la privacidad de los datos. Se pueden utilizar diversos mecanismos de seguridad para garantizar que los intercambios de datos y mensajes entre los equipos se realizan con un alto nivel de seguridad. Uno de estos mecanismos de seguridad es V5. NFS Maestro Client admite tambin otras medidas de seguridad como la Lista de control de acceso (ACL) de Sun Solaris, el protocolo de autenticacin SASL para el acceso a los dominios de Microsoft Active Directory y la definicin de modos de seguridad predeterminados para cada recurso compartido. Controle y reduzca el costo total de la propiedad.

Los sistemas legados albergan ms del 80% de la informacin corporativa. Una parte importante de nuestro trabajo depende del xito de las negociaciones efectuadas con estos sistemas. El acceso a la informacin nunca ha sido tan crtico. HostExplorer y Hummingbird Deployment Wizard le proporcionan una manera sencilla de proteger su inversin en informacin legada al mismo tiempo que le permiten beneficiarse de las tecnologas de Internet y escritorio ms avanzadas. Permiten a las organizaciones disminuir su costo total de propiedad mediante la expansin de un emulador de terminales de vanguardia a travs de Internet Samba Modos de seguridad Samba Solamente hay dos tipos de modos de seguridad para Samba, share-level y userlevel, que se conocen de forma colectiva como niveles de seguridad. Solamente se puede implementar la seguridad a nivel de recurso compartido de una forma, mientras que la seguridad a nivel de usuario se puede implementar en una de cuatro formas diferentes. Las diferentes formas de implementar un nivel de seguridad se llama modos de seguridad. Seguridad a nivel de usuario La seguridad a nivel de usuario es la configuracin predeterminada para Samba. An si la directriz security = user no est listada en el archivo smb.conf, es utilizada por Samba. Si el servidor acepta la combinacin de nombre de usuario/contrasea del cliente, el cliente puede montar mltiples recursos compartidos sin tener que especificar una contrasea para cada instancia. Samba tambin puede aceptar solicitudes de nombre de usuario/contrasea basadas en la sesin. El cliente mantiene mltiples contextos de autenticacin usando un nico UID por cada inicio de sesin. En smb.conf, la directiva security = user que configura la seguridad a nivel de los usuarios es:

[GLOBAL] ... security = user ... Seguridad a nivel de usuarios Con la seguridad a nivel de recurso compartido o servicio, el servidor acepta solamente una contrasea sin un nombre de usuario explcito desde el cliente. El servidor espera una contrasea para cada recurso compartido, independientemente del nombre de usuario. Han surgido informes recientes de clientes Microsoft Windows con problemas de compatibilidad con servidores de seguridad a nivel de recurso compartido. Los desarrolladores de Samba no recomiendan el uso de la seguridad a este nivel. En smb.conf, la directiva security = share que configura la seguridad a nivel de directorio compartidos es: [GLOBAL] ... security = share ... Modo de seguridad de dominio (seguridad a nivel del usuario) En un modo de seguridad de dominio, el servidor Samba tiene una cuenta de mquina (cuenta confiable de seguridad del dominio) y hace que todas las solicitudes de autenticacin se pasen a travs de los controladores de dominio. El servidor Samba se convierte en un servidor miembro de dominio usando las directrices siguientes en smb.conf: [GLOBAL] ... security = domain

workgroup = MARKETING ... Modo de seguridad de Active Directory (seguridad a nivel de usuario) Si tiene un entorno Active Directory, es posible unirse al dominio como un miembro nativo de Active Directory. An si una poltica de seguridad limita el uso de protocolos de autenticacin compatibles con NT, el servidor Samba se puede unir al ADS utilizando Kerberos. Samba en un modo de miembro de Active Directory puede aceptar tquets Kerberos. En smb.conf, las directivas siguientes hacen a Samba un servidor miembro de Active Directory: [GLOBAL] ... security = ADS realm = EXAMPLE.COM password server = kerberos.example.com ... Modo de seguridad de servidor (seguridad a nivel de usuario) Se utiliz el modo de seguridad de servidor previamente cuando Samba no fue capaz de actuar como un servidor miembro de dominio. En smb.conf, las directrices siguientes permiten que Samba opere en modo de seguridad de servidor: [GLOBAL] ... encrypt passwords = Yes security = server password server = "NetBIOS_of_Domain_Controller" ...

Servidor NIS

Seguridad en el Servidor NIS NIS sola tener un defecto grave de seguridad: dejaba su fichero de contraseas legible por prcticamente cualquier persona en toda Internet, lo que supona un gran nmero de posibles intrusos. Si un intruso saba su (de usted) dominio NIS y la direccin de su servidor, simplemente tena que enviar una consulta al mapa passwd.byname y recibir al instante todas las contraseas encriptadas del sistema. Con un programa rpido paracrackear contraseas como el crack, y un buen diccionario, averiguar unas cuantas contraseas de usuario no es problema. De todo esto trata la opcin securenets. Esta opcin simplemente restringe el acceso a su servidor NIS a ciertos nodos, basndose en su direccin IP o nmeros de red. La ltima versin de ypserv implementa esta caracterstica de dos maneras. La primera consta de un fichero de configuracin especial llamado /etc/ypserv.securenets y la segunda utiliza convenientemente los ficheros /etc/hosts.allow y /etc/hosts.denyque. ypserv: 172.16.2. Esto permitira a todos los nodos de la red 172.16.2.0 acceder al servidor NIS. Para denegar el acceso al resto de nodos, la correspondiente lnea en el hosts.deny sera: ypserv: ALL Las direcciones IP no son la nica manera de especificar nodos y redes en hosts.allow y hosts.deny. Por favor, consulte la pgina del manual hosts_access(5) de su sistema para ms detalles. Sin embargo, advierta que no puede utilizar nombres de nodo o de dominio en la entrada ypserv. Si especifica un nombre de nodo, el servidor tratar de resolver este nombre de nodo pero el resolvedor a su vez llamar a ypserv, y caer en un bucle infinito.

Para

configurar

la

seguridad necesita

securenets crear el

utilizando fichero

el de

mtodo /etc/ypserv.securenets,

configuracin, /etc/ypserv.securenets. Este fichero de configuracin es simple en su estructura. Cada lnea describe un nodo o red de nodos que tendrn permiso de acceso al servidor. Cualquier direccin no descrita con una entrada en este fichero tendr denegado el acceso. Una lnea que comience por # ser tratada como comentario. El ejemplo 13-1 muestra cmo sera un sencillo fichero /etc/ypserv.securenets: Ejemplo 13-1. Fichero ypserv.securenets de Ejemplo # permitir conexiones desde el nodo local -- necesario host 127.0.0.1 # lo mismo para 255.255.255.255 127.0.0.1 # # permitir conexiones desde cualquier nodo de la red de la Cervecera Virtual 255.255.255.0 172.16.1.0 # La primera entrada de cada lnea es la mscara de red a utilizar, siendo host una palabra clave especial que significa mscara de red 255.255.255.255. La segunda entrada de cada lnea es la direccin IP a la que aplicar la mscara de red. Una tercera opcin es utilizar el mapeador de puertos (portmapper) seguro en lugar de la opcin securenets de ypserv. El mapeador de puertos seguro (portmap-5.0) utiliza tambin el esquema de hosts.allow, pero ofrece esto a todos los servidores RPC, no slo a ypserv. Sin embargo, no se debe utilizar la opcin securenets y el mapeador de puertos seguro al mismo tiempo, por la sobrecarga que esto supondra. HTTP

La especificacin del protocolo HTTP tiene ya ms de 8 aos, y es ahora, cuando se empieza a trabajar en la seguridad asociada a este protocolo, con la creacin de un borrador por parte del IETF. Security Requirements for HTTP.

Los problemas que van a tratar son los mecanismos de seguridad asociados al HTTP o la falta de ellos. :) Entre otros podemos ver:

Autenticacin HTTP a travs de claves de sesin en cookies y formularios HTML.

Susceptibilidad de las cookies a todo tipo de ataques por parte de intermediarios y mirones. Autenticacin bsica, digest y otros esquemas basados en la capa de transporte. Esquemas de autenticacin basados en tickets centralizados. Web Services. (protocolos basados en XML)

Posible revisin del protocolo HTTP en un futuro.

Ya hablamos de esto anteriormente, la seguridad en la capa de transporte proporcionada a los protocolos de nivel ms alto, como HTTP, o lo que es lo mismo. Este documento cubrir los mecanismos de seguridad de HTTP como una combinacin del transporte seguro y la autenticacin de acceso. Su objetivo ser concluir con un documento. Hay que ver que en la actualidad se trata nicamente de un borrador inicial y est incompleto. Pero al menos, son buenas noticias, ya que se est trabajando en ello para que tarde o temprano se empiece a implementar. Puede que no sea todo lo que necesitamos, pero al menos es ms de lo que tenemos actualmente.

HTTPS

La idea principal de https es la de crear un canal seguro sobre una red insegura. Proporcionando una proteccin contra ataques eavesdropping y man-in-themiddle, siempre que sea empleen mtodos de cifrado adecuados y que el certificado del servidor sea verificado y resulte de confianza. La confianza inherente de HTTPS est basada en una autoridad de certificacin superior que viene preinstala en el software del navegador.

Una conexin https a un bensite puede ser validad. El usuario confa en la autorizacin de sertificacion. El website proporciona un certificado valido. El certificado identifica correctamente el website. Cada uno de los nodos utilizados en internet son signos de confianza, o que el usuario confi en la capa de cifrado del protocolo SMTP SMTP NO VERIFICA EL ORIGEN DEL MAIL Si bien es cierto que existen mecanismos ms que suficientes para verificar el origen y la integridad de un correo electrnico, tambin es cierto que no estn implementadas en la prctica. Raro es que alguien use criptografa en su correo electrnico, includos directivos de la empresa y personal de seguridad informtica. Raro es tambin que se intente verificar el origen del mail, pese a la existencia de los SPF.es realmente lo hace desde la IP de un servidor de correo de miempresa.es. S, es raro. El SMTP permite por tanto declarar como origen del mail LO QUE NOS DE LA GANA. Y esta es una de sus grandes debilidades. ESTABLECIENDO UNA SESIN DE CORREO VA TELNET

Lo primero ser averiguar cul es el servidor de correo de nuestro objetivo, para ello ejecutamos dig @80.58.0.33 destino.es mx, que pide el servidor MX (mail) del dominio destino.es al dns de telefnica 80.58.0.33. Ahora podemos hacer lo mismo que hace nuestro servidor de correo haciendo telnet al puerto 25 del MX de destino. Enviar un mail a mano es tan sencillo como esto:

Como podis ver, hemos establecido una sesin de telnet al puerto 25 y hemos hecho uso de los comandos del protocolo SMTP para enviar nuestro mail. Del mismo modo, podramos enviar un mail con un documento adjunto o cualquier otra cosa. La ventaja de hacer esto as, es que nos permite verificar que ciertos comandos han sido deshabilitados VULNERABILIDADES COMUNES

Lo primero que miramos es el banner del servidor de correo, que usamos para ver si existe alguna vulnerabilidad publicada Si es as, ya sabes qu tienes que hacer. Lo normal es que el banner haya sido modificado, pero en el caso de que el servidor sea sendmail esto requiere recompilar el cdigo, con lo que es posible que no lo hayan cambiado. En lugar de ver el banner, tambin podemos usar amap (http://freeworld.thc.org/thc-amap/) o nmap, como sigue: amap -sT -d -b -o amap.out 192.168.1.100 25 Ahora miramos es si el servidor de correo es un open relay. Es decir, si permite enviar mails a otros destinos que no sean de su dominio. Para ello, simplemente nos conectamos por telnet y vemos el resultado de meterle en RCPT TO una direccin de gmail o cualquier otra cosa. Despus, vemos si los comandos vrfy y expn estn habilitados. No deberan, ya que el primero puede usarse para verificar si existe un mail dado, lo cual permite sacar todos los usuarios de correo por fuerza bruta, y el segundo expande una direccin de mail, ofreciendo valiosa informacin sobre el destinatario. Debera de darnos un error.

Ahora, intentamos ver si entra un mail con FROM: de la propia empresa. Si es as, es posible que lo que enviemos desde una direccin falsa de la propia empresa no sea escaneado por el filtro antivirus/antispam. Otra prueba que podemos hacer es enviar un virus como documento adjunto en un rar cifrado. Los filtros antivirus tienen un tiempo mximo asignado a escanear los adjuntos. Intentan descifrarlo y si no pueden ponen el archivo en cuarentena. Si este tiempo no est bien puesto, podemos tirar el servidor mail mandando un montn de pequeos .rar. Un DOS simple y efectivo, que es fcil que funcione. Y seguimos con nuestros intentos tienen puesto un tamao mximo para los adjuntos? Comprubalo. Mndales un pedazo de adjunto de 30Mb, a ver qu pasa. Ahora, intentaremos algo que suele ser bastante efectivo: vamos a comprobar si existen direcciones de correo genricas para toda la empresa, a lo mejor est definido como alias algo tipo empleados, todos, empresa, sistemas, comunicaciones, rrhh, Haz una lista e intenta a ver si llegan. Si es as, podemos mandarles SPAM o ficheros adjuntos pesados hasta aburrirnos. Y tambin podemos recopilar direcciones de correo usadas por la empresa Ya sabes, google . Adems, si hemos conseguido enumerar direcciones de correo de la empresa podemos hacerlas pblicas (postendolas en cualquier foro de rusia o ucrania, por poner un ejemplo) para que reciban abundante SPAM.

SNIFFERS Muchos que estn en el tema de la computacin seguramente han odo hablar sobre este tipo de programas, y los que no, ser bueno que sepan que existen. En realidad todos deberan saber que existen ya que su informacin puede ser interceptada por este tipo de aplicaciones. SNIFFERS que hacen trabajar una computadora en modo promiscuo:

Actan en redes del tipo LAN es decir de rea local, y lo que hacen es capturar toda la informacin que pasa por la red, desde una foto hasta una contrasea y cualquier otra cosa tambin, segn como se lo configure. Este programa en modo promiscuo acta solo en un tipo de redes en particular: peer to peer o estrella que utilice un concentrador o hub que es lo mismo. Por si no se sabe, en este tipo de redes se enva la informacin a todas las computadoras porque es procesada y mostrada solo por la computadora destino ya que todas las placas de red tienen un cdigo nico en ellas. Entonces saben cuando algo es para ellas y cuando no. Por si no entiende nada, le cuento tambin que una placa de red es una placa que estando en una computadora se utiliza para conectar a otra computadora que tenga otra placa de red. Lo que hace un sniffer es que captura toda la informacin que pasa por toda la red dejando ver todo su contenido o lo que se desee, cambiando la forma de trabajo de la placa de red, haciendo que esta capte la informacin almacenndola el sniffer para luego mostrarla. Se los puede llamar tambin Packet sniffers o sniffers de paquetes, porque

monitorizan los paquetes que se mueven por la red para ver si alguno de esos paquetes cumple con las condiciones que esta buscado. Qu es un paquete? Resumiendo: son trozos de informacin que se transmiten en la red y que estn formados por una estructura de datos. Cada paquete de datos por ejemplo tiene un principio y un fin y un par de datos ms, adems de los datos que esta transmitiendo. Sniffers que no necesitan hacer trabajar una computadora en modo promiscuo: Los puntos problemticos en la red no solo son las computadoras en estrella como hemos comentado sino tambin cabe la posibilidad de que este programa espa se lo cargue en un router que a diferencia de un concentrador lo que hace es el mismo elegir a que computadora va a enviar la informacin en vez de enviarlas a todas al mismo tiempo (ahorrando as recursos en los sistemas).

Otros datos: El sniffer puede ser tanto un programa con interfaz de lnea de comandos. Un sniffer se lo puede instalar de forma remota. Es decir un pirata informtico de forma ilegal puede entrar en una red y cargar un sniffer para capturar mediante su computadora (que puede estar en otro pas) informacin que se transmite por una red LAN. Un sniffer tambin lo pueden cargar en un gateway. Esto es una nota que hice sacando informacin de distintas fuentes. Es bueno que un usuario comn sepa que existen estas cosas y obviamente alguien que se dedica a la computacin tambin. Es difcil protegerse de estos tipos de programas. Una vez ya instalado si no lo detect el antivirus que se est usando, es difcil detectarlo.