El ataque, básicamente, consiste en que cambia el aspecto completo de la web al cambiar de lengüeta, asemejándose a una web de tipo bancario, o incluso de gmail (como en el caso del ejemplo), el engaño no sería bueno, sino fuese porque cambia la barra del título e incluso el favicon, por lo que, a la mayoría de los internautas, que se fijan en estos datos (que son los visibles en la lengüeta), les puede llevar a confusión y realizar el inicio de sesión en la web del pescador, con lo que, habríamos dado nuestros datos de acceso sin saberlo.

Como consejo, siempre revisar la barra de direcciones para cercionarse de en qué sitio estamos realmente.

En principio, para los más neófitos del tema, y que no tengan ni la más remota idea de cómo lo hacen los hackers (y en peor caso los crackers), para entrar en un sistema remoto sin que nadie se percate de ello, vamos a dar alguna que otra luz sobre el asunto.

Ataques, ¿cómo entran?

A pesar de lo que muchas películas extrañas (o desinformadas) nos hacen creer, los ataques, no consisten en que el atacante vea, como si fuese una televisión, lo que está haciendo el atacado. No consiste en que de repente, tome el control de tu teclado y se vea moviendo el ratón para eliminar ficheros o escribir cosas en un documento del procesador de textos.

Los ataques se producen mediante mecanismos concretos que suelen articular los hackers, y que suelen ser:

• Troyanos: son programas que están escritos específicamente para ejecutarse en un ordenador sin que se note, atendiendo a peticiones a través de la red. Los hay que pueden ser:
  • virus: que se repliquen a otras máquinas a través de la infectación del programa de correo para anexar código macro que se ejecute en otros clientes de correo, o enviarse a través de programas tipo messenger a los contactos cuando estés conectado. La única misión de los virus es infectar a cuantos puedan.
  • gusano: estos se encargan de tomar datos del equipo y enviarlos. Datos confidenciales como claves, cuentas bancarias, certificados digitales, …. todo lo que le pueda interesar, en este caso, a un cracker.

  Cuando un troyano se activa, se conecta con el atacante, el atacante en remoto le puede dar órdenes. Según el programa, lo que permita hacer y para lo que esté hecho, este podrá hacer algo malicioso como usar el equipo para descargas ilegales, ataques en masa contra servidores o punto FTP para descargas en algunos casos, o incluso para jugar, apagando el equipo cada X minutos, haciendo aparecer dibujos en la pantalla, o textos flotantes… ya de estos últimos hay pocos… o ninguno.

• Ingeniería social: de esto da buena muestra la película Asalto final. Esta técnica consiste en que el hacker o cracker se hace con la información haciéndose pasar por alguien a quien, seguramente, se la dirían.
• Fuerza bruta: también los hay… aunque esto es más obra de los lammers, quienes intentan acceder a un equipo a través de probar, de forma reiterada, el acceso a los servidores con usuarios probables y un diccionario de palabras y combinaciones simples para poder acceder a un servidor.
• Vulnerabilidades: esta es la más curiosa y más artesana, ya que consiste en que, aprovechando una vulnerabilidad del sistema, el hacker o cracker, puede acceder a un sistema para depositar código, o ejecutar arbitrariamente alguna línea de código que le permita el acceso, principalmente, a servidores. En la película La red social, por ejemplo, el protagonista va relatando las vulnerabilidades de los sitios a los que accede para robar las fotografías de las chicas sobre las que monta su primera experiencia social.

En caso de los virus, gusanos y troyanos, este malware, como se suele llamar, suele entrar por la ejecución de algún código dentro del equipo atacado. Si se abre algún archivo ejecutable (ya sea juego, presentación o vídeo) que misteriosamente está en formato exe (de executable, ejecutable), es posible que haya detrás uno de estos programas.

Además, mucho software que se descarga desde internet a través de P2P, es sensible de estar infectado por código malware, por lo que hay que tener mucho cuidado con lo que se descarga desde la red de redes.

¿Qué es una vulnerabilidad?

Una vulnerabilidad es un error de código explotable. Cualquier servicio que se ejecuta y mantiene comunicación abierta de red, a modo pasivo (o servidor) es potencialmente un sistema vulnerable y explotable. No obstante, de forma local, también hay sistemas vulnerables y explotables, pero para poder realizar una explotación de ellos, se requiere acceso físico a esas máquinas.

En Internet existen base de datos de vulnerabilidades descubiertas de muchos tipos de software, entre los que hay sistemas operativos como Windows, servidores como Apache, base de datos como MySQL y otros elementos con los que se crean páginas web, o sistemas de mensajería intantánea, servidores de correo, etc.

¿Cómo explotan estas vulnerabilidades?

Cuando una vulnerabilidad es descubierta, puede pasar que el descubrimiento lo realice un cracker, y cree una aplicación que lo explote. Las aplicaciones que sirven para explotar vulnerabilidades tienen el nombre de exploit (aunque también se puede escribir como xploit o sploit). Cuando está recién hecho, se dice que estos exploits son de 0day (día cero), y por tanto, hay muchos sistemas en producción sensibles de su acción.

No obstante, los exploits también son buenas herramientas de seguridad, porque ayudan a comprobar si un sistema es fiable o no. Por lo que también existen muchas base de datos de exploits en Internet. La más conocida es la que usa el programa metasploit.

Conclusiones

Una conexión a internet en sí, estando detrás de un router y manejando solo páginas web, suele ser segura, y sobretodo, si mantenemos nuestro equipo al día con actualizaciones de seguridad. No obstante, el uso de cada vez más software pirata, hace que no sea del todo confiable lo que hay en un PC.

Por otro lado, si mantenemos un servidor, desarrollamos un aplicación web, o simplemente tenemos un blog. Hay que tener el mismo cuidado de tener el servidor actualizado a nivel de software, las configuraciones revisadas a nivel de accesibilidad de los ficheros instalados, de las rutas a las que se tenga acceso y de no instalar plugins o librerías que no tengan un mínimo de fiabilidad.

El caso es que la empresa y la comunidad que soportan ambas distribuciones (incluso distros comos OpenSuSE o SuSE, Mandriva y otras similares) les pasa que desarrollan versiones de forma bastante rápida (una o dos al año), con lo que, pasando 5 años, pueden haber salido unas 10 versiones posteriores del producto.

Esto genera problemas, sobre todo para la comunidad y la empresa que las mantiene, que deben de ir cerrando soporte de las antiguas, porque sino sería un caos el mantenimiento de 10 distros con versiones distintas de los códigos que se incluyen. A día de hoy, RedHat no suele mantener nada más que dos versiones, al última y su anterior, y Fedora Core, como mucho, da soporte a las 3 ó 4 últimas, con lo que, yendo actualmente por la versión 12, es lógico que el soporte a la versión 2 y 3 ha expirado hace bastante tiempo.

¿Qué pasa si hemos instalado un servidor web con estas distribuciones y queremos mantenerlo para nuestro correo, página web y otros menesteres?, pues que sino actualizamos, llegará el momento en el que haya vulnerabilidades en el código de nuestro servidor de correo, nuestro servidor web, o que queramos simplemente actualizar la versión del CMS que estamos usando y necesite una versión superior de Python, PHP o Ruby, o no tengamos forma de instalarla, a menos que vayamos tirando de compilación.

En Debian también pasa algo parecido. El ritmo de liberación de las distribuciones es más lento, con lo que da un tiempo mayor de permanencia de una distribución a su siguiente liberación. Pero el cambio es mucho mayor en este sentido, puesto que las versiones, cuando se cambian, son saltos bastante grandes y requiere de un mayor esfuerzo de adaptación.

¿Qué hacer?, básicamente, ir actualizando y mantenerse al tanto de cuando sale la siguiente liberación de la distribución que estamos usando y, sobretodo, planificar tiempos cada 5 ó 6 meses, para actualizar las distribuciones a sus versiones superiores, ya que así estaremos más protegidos de posibles vulnerabilidades.

Tener presente que si el cambio no se realiza, puntualmente, antes de que el soporte oficial a la distro que tenemos instalada expire, nos veremos en la situación de tener un sistema con agujeros de seguridad, que es propenso a fallos y sobre el que, cada día que pase, será más complicado instalar software nuevo.

Normalmente, estos scripts se realizan buscando las peticiones más lentas de los sistemas web. Una vez detectadas, se procede a lanzar muchas de estas peticiones en muy poco tiempo. Los servidores web, ante una avalancha de peticiones, normalmente, comienzan a crear forks o workers (según el servidor y modo de funcionamiento) hasta llegar al límite máximo configurado… o a que se sature el sistema y termine no respondiendo.

Los sistemas GNU/Linux, al igual que la mayoría, tienen un uso de memoria limitada por el tamaño de la misma que haya instalada. Estos sistemas manejan una caché bastante grande y por ello, aunque se tenga 1GB o más instalado en el sistema, siempre se anda con una ocupación bastante alta de la memoria del sistema. Cuando esta se agota, se recurre a la memoria de intercambio (swap), que es mucho más lenta que la memoria convencional, por lo que el sistema comienza a ralentizarse.

Para evitar estos problemas, lo ideal es configurar de forma adecuada el servidor web, acorde a la memoria disponible, el número máximo de hilos que se puedan crear y el número máximo de forks o workers que se puedan lanzar para atender peticiones. Con esto evitamos que la memoria se use en exceso y, aunque las peticiones se atiendan más lentas, se asegure que el sistema permanecerá estable.

También habría que revisar la pila de entrada TCP para el puerto 80 (se puede ver a través de netstat en cualquier sistema GNU/Linux), por si acaso se saturase mucho, comenzar a cortar, vía cortafuegos (iptables), las direcciones IP que estén haciendo flood.

• han entrado en tu servidor y han comenzado a enviar un montón de emails desde tu cuenta de usuario, o
• alguien ha comenzado a enviar un montón de emails a servidores mal configurados, con tu dirección de email como remitente, para hacerte llegar todos esos mensajes.

Visto por cualquiera de las formas pinta mal, pero a la que nos referimos cuando hablamos de spam por relay es la segunda. Tu sistema está bien configurado, nadie ha entrado y no has enviado ningún email, pero sin embargo comienzan a llegar emails de MAILER-DAEMON o similares, diciendo que no han podido entregar tu email (y te lo ponen completo) porque no se encuentra el usuario, porque está mal formado, o por cualquier otro error intencionado que ha introducido el spammer.

El problema se da, y lo sé porque lo he vivido, cuando abres la bandeja de entrada y ves nada más y nada menos que de 30 a 60 mensajes diarios con el mismo asunto. Después, leyendo las cabeceras del email (esas que no se ven a simple vista, ni desde MUAs como Outlook), se puede ver, en la lista de los Received, el último que aparece (que es el primero que se escribió):

Received: (from nj.ua@localhost)
	by nj.ua (8.13.8/8.13.8/Submit) id a862dvhn858019;
	Thu, 21 Jan 2010 09:36:45 +0800

Ha sido enviado por alguien que no se conoce, la siguiente línea es la del que recibe el email, directamente, por lo que no ha pasado, siquiera, por nuestro servidor. Estamos seguros… pero eso no nos quita el problema… y realmente, y lamentablemente, no hay una solución real a este problema, ya que al intentar comunicar a cada uno de los sitios la configuración que deben de poner para que esto no pase (validación de SPF, uso de EHLO o HELO,…) o no saben cómo hacerlo y pasan, o pasan directamente.

Por lo que, el spam ha conseguido otra vía de acceso a través de los sistemas de email más pobremente configurados (y hay muchos así) de Internet. ¿Habrá forma de pararlos?

El sistema se basa en tener una copia exacta y nueva de un sistema operativo basado en Debian GNU/Linux, que se instala en un directorio específico de nuestro árbol de directorios. El comando que genera la jaula, que tiene el nombre de debootstrap, se encarga de realizar la instalación del sistema a partir del directorio solicitado y con las fuentes solicitadas, es decir, si queremos instalar un woody, sarge, etch, lenny… o un gutsy, hardy, ibex… pues solo tenemos que indicarlo, con la URL de donde conseguir los paquetes y listo.

Por ejemplo, instalar en nuestro directorio /home/usuario/lenny una distribución lenny de Debian, sería hacer lo siguiente:

# debootstrap lenny /home/usuario/lenny http://ftp.rediris.es/debian

Esto tardará unos minutos hasta realizar la instalación completa, ya que se tiene que descargar los paquetes de internet, pero en el momento de finalizar, tendremos un sistema básico de lenny instalado en la ruta indicada.

Para poder usarlo, solo tendremos que hacer lo siguiente:

# mount -t proc proc /home/usuario/lenny/proc
# chroot /home/usuario/lenny

El hecho de montar el directorio proc es para poder tener acceso, desde la jaula, al kernel y poder lanzar servidores como apache, proftpd, postfix o similares.

Una vez dentro, podremos realizar las instalaciones y configuraciones que queramos realizar sin miedo de estar estropeando nuestra configuración normal.

La sincronización horaria es completamente posible de llevar, simplemente, instalando un servidor de hora NTP dentro de nuestra red, para que nos haga de servidor de sincronización.

En España, generalmente, se suele usar hora.rediris.es como servidor de hora, puesto que es un sistema formado por varios servidores, algunos de ellos con el uso de relojes GPS.

Muchos sistemas ya tienen el servidor ntpd instalado. En otros habrá que hacer la instalación, ya sea del paquete con nombre: ntp, ntp-server, ntpd…

El archivo de configuración, normalmente: /etc/ntp.conf; debería de tener un contenido parecido a este:

driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
 
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
 
server hora.rediris.es
 
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
 
restrict 127.0.0.1
restrict ::1
 
restrict 192.168.123.0  mask  255.255.255.0 notrust
 
broadcast 192.168.123.255
disable auth
broadcastclient

Con esto, el servidor de hora recién instalado, servirá como repetidor para los equipos de la red interna. En caso de tener un solo equipo, en ese caso es mejor tomar el archivo de /etc/ntp.conf y modificarlo levemente para hacer que el sistema fucnione, y nada más.

Espero que os sirva de ayuda.

Estas preguntas surgen siempre por desconocimiento y, realmente es bueno que nos las hagamos, ya que hay también mucha gente que dice saber y, cuando dicen eso de: “en mi equipo es imposible que entren”; es donde están realmente equivocados.

Nuestros equipos informáticos, en la amplia mayoría, están conectados a Internet. Reciben una cantidad de información muy grande a diario, y envian también mucha información a la red de redes.

Cuando se configura un ordenador, normalmente, se hace conectado a un router. Este tipo de conexión, a priori, hace que sea imposible que un atacante pueda acceder directamente al equipo que está detrás del router. Pero en sí, el router también podría contener algún tipo de vulnerabilidad, con la que pudiera ser saltado, por lo que no nos da una seguridad total.

Por otra parte, no es necesario que entren por ahí, desde tiempos inmemoriales, las mejores tácticas para atacar a alguien, sin que este se diese cuenta y usando el factor sorpresa, han sido con engaños. Los programas que parecen inofensivos y se instalan en nuestro sistema, pueden actuar como el famoso caballo de Troya (y a cuyo nombre deben el suyo propio: troyanos).

Este tipo de malware se encarga de tomar información propia y, normalmente, de convertir nuestro sistema en un zombie.

¿Es nuestro equipo realmente seguro? Depende del uso que le demos, depende de que no se reproduzca contenido recibido de fuentes no seguras y, de que nuestros equipos, si usan Windows, tengan el software preciso y necesario para evitar males mayores.

¿Un sistema GNU/Linux es más seguro? Normalmente sí, pero no es totalmente seguro, debe de mantenerse el mismo cuidado, no visualizar contenido del que se desconozca su origen, y deshabilitar los permisos de tipo ejecución en todos los ficheros “sospechosos”, es una buena práctica.