Archive for the ‘ seguridad ’ Category

Directorio Cifrado con EcryptFS

Ultimamente en el trabajo estamos ocupándonos de la parte de seguridad y me he topado con una cosa que puede sernos útil en casa a más de uno, mantener un directorio con información sensible que queremos tener cifrada para evitar que alguien con acceso físico a nuestro disco duro pueda verla. Es especialmente interesante en el caso de los equipos portátiles y unidades externas de almacenamiento, por ser éstos más susceptibles de un robo y de manipulación física desde otro equipo.

Lo que vamos a configurar aquí es un directorio que mantendrá cifrada la información que contiene siempre que el directorio no esté montado, es decir, si el directorio sin montar (o el equipo apagado, ya que al apagar el sistema se desmontan automáticamente todas las unidades), la información estará cifrada, cuando el directorio esté montado, la información estará descifrada y se podrá leer libremente (cosa que también se puede acotar con los permisos del directorio en cuestión).

Sigue leyendo

Crackeando cifrados WEP

pillando paquetes...Si… es un tema viejo y de sobra conocido. Tampoco es que yo esté muy puesto en éstos temas, pero hoy por casualidades de la vida me ha tocado meterme con ello (consecuencias de no enseñar a tu padre a apuntar algo cuando lo cambia en el router de su casa…), así que voy a dejarlo de la forma más sencilla por si me hace falta alguna otra vez…

El caso es que he conseguido que funcione, fué una putadilla buscarlo, porque mira que hay tutoriales diversos, desde los más breves que no te funcionan hasta los que te explican cada byte que tienes que procesar para conseguir pillar los paquetes (que es donde de verdad está el meollo de la cosa porque el crackeo es pura rutina :P)

En fin, aquí se queda, y si de paso le viene a alguien mejor todavía 😉

Sigue leyendo

Olvídate de firmar repositorios

Si habéis añadido algún repositorio de terceros a ubuntu, os habréis dado cuenta de que después de añadirlos es necesario “instalar” también la clave PGP que usa dicho repositorio. Bien, todo eso es un poco coñazo, pero es lo que tiene la seguridad.

Ahora bien, ¿quieres olvidarte de tener que añadir las claves y que, cada vez que añadas un repositorio la clave se añada sola y de forma transparente para ti? Pues entonces sólo tendrás que instalar éste paquete: launchpadupdate-0.unknown.deb y listo. La siguiente vez que que añadas un repositorio no tendrás que andar “firmándolo”.

Un par de cosillas sueltas:

– Cuando añadáis repositorios, no lo hagáis en el fichero /etc/apt/sources.list, mejor cread un fichero nuevo en /etc/apt/sources.list.d/ es decir, si queréis añadir los repositorios para MyApp, cread el fichero /etc/apt/sources.list.d/MyApp.list y meted las direcciones de los repos dentro de ese fichero. Si luego queréis dejar de usarlo, sólo tendrés que borrar ese fichero o quitarle la “extensión” .list. Cómodo y eficaz, a parte de una buena forma de tener los repositorios colocaditos.

– Si no queréis que las firmas se añadan “sólas” pero nunca os acordáis del dichoso comando, podéis meter en un fichero, por ejemplo firmar, ésto:

echo Adding signature: $1 …
echo
sudo apt-key adv –recv-keys –keyserver keyserver.ubuntu.com $1
echo
echo Added.

lo metéis el fichero en /usr/bin, y le dáis permisos de ejecución. La siguiente vez, sólo tendréis que hacer un update, pillar la clave y escribir:

firmar <clave>

y listo. Cómodo y fácil también.

Fuente: TuxApuntes

Conceal, encriptación de carpetas.

OJO! ANTES DE NADA LEED LA ACTUALIZACIÓN AL FINAL DEL POST!

Bueno, el termino de carpetas no me gusta nada pero la verdad es que se está extendiendo mucho. Eso sí, no lo soltéis por el canal #ubuntu del hispano porque os correrán a gorrazos… se llaman “directorios”, no carpetas. xD

Conceal es un proyecto del Google Summer of Code que he descubierto a través del post en Blux 2.0, donde hablan de Cypt Manager, al parecer es otro nombre del proyecto. No sé cual es el definitivo aunque Conceal suena más a nombre en clave que a nombre de aplicación final, la verdad (va a ser por eso que me gusta más xD).

El caso es que no está en los repositorios ni nada, pero la aplicación merece la pena, aunque se encuentre en la versión 0.0.5 funciona bastante bien. Son tres paquetes externos los que hay que instalar para la aplicación, aunque son partes modulares, así que puede que haya alguno que no te interese (a mi los tres me parecen bastante buenos):

  • La aplicación en si (escrita en python) que se puede utilizar desde la línea de comandos. [Link]
  • El interfaz en gtk para la aplicación, el icono aparece en Administración como Encrypted Directories. [Link]
  • El paquete para la integración con Nautilus. [Link]

Una vez tengamos todo instalado veréis como es MUY fácil de manejar: simplemente os váis a Administración, pincháis en Encrypted Directories y tendréis un cómodo interfaz para añadir los directorios que queréis tener encriptados.

Para los que uséis KDE también tenéis la aplicación portada a QT [Link], pero no he encontrado ningún paquete para integrarlo con Konqueror.

 ACTUALIZADO: Después de probar unas cuantas veces ésta aplicación no he conseguido añadir una sóla carpetada encriptada. No sé si es que el encriptado que hace por defecto es demasiado alto, pero da la impresión de que la aplicación se queda pillada. De todas formas, no es para nada usable si tengo que esperar tanto para que la cosa funcione. Importante:

NO PROBÉIS ÉSTA APLICACIÓN CON NINGÚN DIRECTORIO QUE TENGA ALGO QUE NO QUERÁIS PERDER SIN HACER ANTES UNA COPIA DE SEGURIDAD. CORRÉIS EL RIESGO DE PERDER LOS DATOS QUE CONTENGA.

A cambio, os dejo la aplicación que usaba antes y que es la que voy a seguir usando: EncFS con CryptKeeper como interfaz gtk, una auténtica delicia de aplicación. Os dejo el enlace al post donde comenté como se instala y usa 😀

WordPress 2.3 … ponte una beta YA!

Vale, igual el titular es demasiado heavy como para pedir a gritos una actualización de wordpress 2.2 a wordpress 2.3 pero el tema trae tela…os cuento.

Ésta semana hemos visto como la cosa empezaba a moverse en WordPress, la beta de la versión 2.3 está disponible y ya hay incluso una traducción completa al español, aún así la versión final todavía no está disponible. ¿por qué actualizar entonces? ¿trae algo nuevo? ¿trae algo con ese saborcillo a compiz que hace que la gente se instale betas? Pues la verdad es que no.

Más bien es que no trae algo que si traen las demás versiones: un agujero de seguridad que alguien se ha encargado ya de explotar. No con fines buenos, como podría ser encontrar el fallo y comunicarlo a la gente de wordpress, sino creando un gusano que está creando expetación. Al parecer todas las versiones anteriores a la 2.3 son vulnerables.

Me imagino que los desarrolladores de wordpress estarán con el agua al cuello para sacar YA la versión final de WorpPress 2.3 porque la gente lo está pidiendo a gritos.

Os dejo las fuentes de la noticia:

WordPress 2.3 en español
Exploit liberado
Noticia original sobre el exploit

Alemania, hacia la “seguridad” por el mal camino

Alemania ha decidido seguir el camino más “fácil” pero más desastroso para combatir el crimen tecnológico: ilegalizar la posesión de herramientas de “hacking”. Es decir, si tienes una herramienta de “hacking” te pueden arrestar sin más, y OJO, sólo con poseerla, no tienes porque estar usándola ni nada parecido.

Cómo habréis notado por las comillas, me ha llamado la atención lo de “herramienta de hacking” (traducido literalmente de “hacking tool”), ¿qué se considera una herramienta de hacking? Por ejemplo, Nmap, es un escaneador de puertos remotos sumamente conocido. ¿es una herramienta de hacking? Pues depende como lo uses. Lo puedes usar para acechar una máquina, ver que puertos tiene abiertos, mirar a qué servicios corresponden y buscar uno con alguna vulnerabilidad aprovechable. Pero, por ejemplo, yo lo use en su día para ver, por curiosidad, que puertos tenía abiertos mi PS3 y la Wii de mi ex-compañero de piso. Lo mismo ocurre con Kismet, un software también muy conocido para la detección/estudio de redes wifi también puede ser usado de ambas formas: para pillar paquetes de la wifi de tu vecino y a partir de ellos crackear su contraseña wep y poder usar su red o bien para mantener vigilada tu wifi por si alguien más que tu la está usando o, simplemente, hacerte unas estadísticas de cuando usas más tu red y para qué la usas más.

He aquí una foto de unos cuantos que están en contra de ésta ley y han protestado contra ella de ésta guisa, la mayoría forman parte del Chaos Computer Camp y todos ellos podrían ser arrestados sin problemas:

Soy de la opinión de que las cosas no se hacen así y que, aunque a los gobernantes les pueda parecer que así cortan por lo sano con los delitos informáticos no es así para nada. Deberían haberse planteado utilizar la fuerza de la educación. ¿Qué impide que ataquen sus servidores desde fuera de Alemania? Nada. Además, creo que la ley tiene fuertes puntos flojos… si lanzo nmap de ésta guisa:

sudo aptitude install nmapfe && nmapfe && sudo aptitude purge nmapfe

¿qué pasa? Porque eso va a bajarse nmap con su frontend, lo va a lanzar y cuando termine lo va a desisntalar de mi sistema. Vale, durante el tiempo desde que acabe de ejecutarse el primer comando hasta que acabe de ejecutarse el último tendrían potestad para arrestarme, pero… ¿y las pruebas? xD

No sé, me parece un muy mal camino a seguir. A ver quien tiene cojones de pasar con su portatil por la aduana Alemana xD

¿y tú? ¿le ves alguna ventaja a ésta ley?

SSH sin contraseña pero más seguro

Un poco contradictorio el título ¿no? Pues puede verse así. Hablando de temas de seguridad muchas veces (como en todo el mundo de la informática) las cosas cambian mucho según el punto de vista de cada uno.

Lo que voy a explicar de manera breve es algo que vi en 120%Linux, concretamente en éste post, y que me pareció bastante interesante, en gran parte porque me ahorra meter una contraseña bastante veces al día xD

El objetivo es el siguiente: poder logearnos en nuestros servidor a través de ssh sin tener que introducir ninguna contraseña pero manteniendo cierto nivel de seguridad en el servidor. Lo que haremos será eliminar el hecho de introducir la contraseña y añadir la necesidad de indentificarse (de forma automática) mediante una firma RSA que tendremos almacenada. Aquí os va el resumen de lo que tenéis que hacer:

Generar el par de claves RSA (pública y privada):

ssh-keygen -t rsa

nos preguntará la passphrase que queremos usar para éste par de claves y en qué fichero queremos guardar la clave, de forma que guardara con ese nombre la clave privada y con el mismo nombre seguido de .pub la clave pública (por defecto ~/.ssh/id_rsa y ~/.ssh/id_rsa.pub). OJO! si lo que queremos es no tener que meter clave al conectar por ssh debedos dejar el passphrase en blanco.

– Ahora mandaremos la clave pública al servidor:

ssh-copy-id -i ~/.ssh/id_rsa.pub usuario@servidor

– Ya sólo nos queda configurar el servidor. Lo hacemos editando el fichero /etc/ssh/sshd_config y cambiando los siguientes valores:

PasswordAuthentication no
RSAAuthentication yes
PubkeyAuthentication yes

más o menos se entiende, pero quiero aclarar que si dejamos “PasswordAuthentication no” ya no se podrá entrar en el servidor si no disponemos de la clave privada en la máquina desde la que estamos trabajando. Yo lo he dejado como yes porque alguna vez conecto desde casa de algún amigo y otro colegas míos tienen cuentas ssh en el servidor de mi casa. Tenedlo en cuenta porque afecta a todos los usuarios del sistema.

En el tutorial original añaden éste otro paso más, pero no estoy muy seguro de que haga falta, probad antes de hacerlo y si no os funciona ya sabéis 😉 (de paso dejad un comentario para aclararlo :D):

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

– Por último, pero no menos importante, reiniciar el servicio ssh en el servidor así:

sudo /etc/init.d/ssh restart

Y listo. Ahora deberíamos poder logearnos sin problemas como siempre:

ssh usuario@servidor

Podéis hacerlo así para ver todos los mensajes y aseguraros de que está usando el par de claves rsa:

ssh -v usuario@servidor

Si queréis hacer cambios tened en cuenta que no se puede cambiar la passphrase, vamos, si que se puede pero el concepto es distinto: tenéis que generar otro par de claves distintas con otra passphrase y añadirlas. Pero sabed que sino elimináis la clave pública vieja del fichero ~/.ssh/authorized_keys seguirá siendo válida. Podéis hacerlo borrando directamente ese fichero antes de pasarle la clave pública nueva o editándolo se ve bien donde termina una clave y empieza otra.

Que no os engañe el hecho de que no haya que meter contraseña, si controláis bien el acceso a vuestro clave privada es mucho más seguro que la contraseña que usábais hasta ahora.