Mostrando entradas con la etiqueta seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta seguridad. Mostrar todas las entradas

martes, 26 de agosto de 2014

iceweasel, tor y dns leaks

Para los que no conozcáis iceweasel, he de decir que es un fork totalmente libre de firefox, y el navegador predeterminado de Debian. De cualquier forma, es mi navegador habitual.

Todo empezó el pasado domingo, cuando me decidía a bajarme el último capítulo de una de esas series extranjeras que sigo y que aquí ni se estrenaron, ni se estrenan, ni se las espera. La página no estaba disponible. Como no tenía la IP de la página, comprobé su estado a través del servicio: downforeveryoneorjustme.com.

Era solo yo. Entonces me di cuenta de que mi ISP había decidido volver a bloquear ciertas páginas de descargas. Páginas de esas que tan poco les gusta a unos y que tan útiles nos resultan a otros.

Esto me enfadó bastante. Por una parte, por qué están bloqueadas otra vez? Hay una sentencia judicial reciente que les obliga a levantar el bloqueo. Por otra parte, qué anduve haciendo con mis DNS y por qué me dejé puestas las que usa el ISP y no las OpenDNS? (Seguro que ya no eran horas...) En ese momento pensé que tal y como están las cosas (gracias a un buen puñado de ministros inútiles) sería mejor bajar el torrent a través de TOR (siempre cifrando el tráfico del cliente de descargas, claro). Pero... Tampoco resolvía!

WTF? AYFKM??? DNS LEAKS?!?!?!

Cambio las DNS y me dispongo a comprobar si hay fugas con wireshark. Efectivamente, unas fugas de DNS tan grandes que no sabía si tendría que pagarles el IBI. D'OH!!!.

Inmediatamente se me vino a la cabeza una mala configuración de firefox/bug que provocaba estas fugas (allá por el 2012...), y fui directo al about:config a comprobarlo, por si era heredada.

Después de cambiar la variable network.websocket.enabled y ponerla a false, me vuelvo a wireshark, a ver que tal están las cosas ahora y... Sigo con fugas! D'OH!!! (2).

Pero ya que estamos aquí, y por aquello de no dar dos viajes, vamos a rebuscar un poco en las opciones relacionadas con las DNS...

network.proxy.socks_remote_dns = false? Vamos a ponerla a true... A ver qué dice ahora wireshark...

Efectivamente, era eso. Y yo dejando mi rastro de miguitas de DNS por TOR :'(

Gran lección aprendida: Antes de salir de casa hay que hacer siempre los deberes.

Así que ya sabéis, cuidado con esas fugas!

*Nota: Algunas extensiones pueden revelar nuestra IP aún mientras estamos utilizando TOR o i2p. Haced los deberes!

*Nota 2: Los enlaces están apuntando a meneame.net y wikipedia intencionadamente. No pienso enlazar a ningún medio de AEDE.

Enjoy! ;)

domingo, 16 de febrero de 2014

compartiendo archivos en red con NFSv4 en debian

NFS (Network File System) es un protocolo utilizado para compartir archivos en red. Posibilita que sistemas distintos, conectados a la misma red, puedan acceder a ficheros remotos como si fuesen locales. Este protocolo está incluido por defecto en los sistemas operativos UNIX y en la mayoría de distribuciones GNU/Linux.

NFS es un protocolo cliente-servidor. El servidor comparte los recursos y el cliente (o clientes) puede acceder a los recursos. El acceso a los recursos es totalmente transparente para el cliente y todas las operaciones son síncronas. Es decir, una operación sólo retorna cuando el servidor ha completado todo el trabajo asociado.

La versión 4 de NFS (NFSv4) fue publicada en abril de 2003 y *no* es compatible con las versiones anteriores.

El uso de NFS, presenta una serie de ventajas e inconvenientes que tendremos que tener presentes antes de decidirnos a implementar esta tecnología:

Ventajas

  • Fácil de instalar y configurar
    Respecto a la instalación: Todos los archivos necesarios deberían estar disponibles en los repositorios de la distribución, llegando a estar instalado por defecto en muchas de ellas.
    Respecto a la configuración: En el lado del servidor, editando un único fichero se definen los recursos a compartir, las direcciones IP que pueden acceder a dicho recurso y los permisos que los clientes tendrán sobre éste. En la parte del cliente (si queremos que los recursos remotos se monten automáticamente, por ejemplo durante el arranque) sólo tendremos que editar el fichero /etc/fstab.
  • Más rápido que SSH
    NFS llega a ser un 30% más rápido que SSH
    *Aunque en las pruebas que yo he realizado se aproximaba más al 25% (sin optimizaciones).
    *Después de configurar correctamente los usuarios, en mis pruebas, sí que resulta un 30% más rápido. Además consume la mitad de CPU que SSH.
  • Fácil de utlizar
    Si nos encontramos en un escenario donde la persona que utiliza la máquina cliente es un usuario normal, al poder montar el recurso compartido como si fuese un recurso local más, su acceso será trivial y el usuario no tendrá la necesidad de complicarse aprendiendo a utilizar tecnologías como SSH, FTP, rsync o similares.

Desventajas

  • NFSv4 no es compatible con las versiones anteriores
    En la realidad nos encontramos con que, en algunos casos, se siguen utilizando NFSv2 y NFSv3.
  • Transmisión en plano
    NFS no va cifrado. En caso de encontrarnos en una red no fiable, o sobre la que pueda llegar a ser objetivo de ataques, sería más conveniente utilizar SSH, que al ir cifrado añade una capa de seguridad a las transmisiones.
  • Restricciones de acceso en base a la IP El servidor restringe el acceso a los recursos en base a la dirección IP de los clientes, pero estas direcciones pueden ser falsificadas con relativa facilidad. Una buena alternativa a esto sería utilizar SSH con claves RSA y/o un firewall bloqueando las falsificaciones de IP (ip spoofing).
  • El acceso de root
    Si el servidor NFS está mal configurado, un cliente que utilice el usuario root para acceder al recurso podrá acceder a todos los archivos, ya que el servidor confía en el nombre de usuario que le da el cliente.

Configurando NFSv4

El servidor

  1. Instalar nfs-kernel-server
    $ sudo aptitude install nfs-kernel-server *NFS se basa en RPC. Si no disponemos de un gestor de paquetes o éste no instala RPC, deberemos instalarlo manualmente.
  2. Editar los ficheros /etc/default/nfs-kernel-server y /etc/default/nfs-common
    Editar estos ficheros sólo debería ser necesario en caso de disponer (en el servidor) de un firewall basado en puertos (port-based firewall), del protocolo de autenticación Kerberos o de querer securizar NFS. Estos ficheros son auto explicativos, por lo que no voy a detallar su configuración. En https://wiki.debian.org/SecuringNFS podremos consultar más información sobre cómo securizar el servidor NFS.
  3. Configurar el fichero /etc/exports
    En este fichero se configurarán los directorios compartidos (exportados). La sintaxis es simple:
    /foo/bar maquina1(opcion1,opcion2,...) maquina2(...) ... Como podermos ver en los ejemplos de /etc/exports: /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check) Para conocer en detalle las opciones disponibles, y su funcionamiento, podemos consultar el man, donde también podremos encontrar opciones para mejorar el rendimiento. $ man exports
  4. Reiniciar el servidor
    Una vez que los cambios están hehos, deberemos aplicarlos, bien reiniciando el servidor:
    $ sudo /etc/init.d/nfs-kernel-server start O bien, mefiante el comando exportfs:
    $ sudo exportfs -r

El cliente

  1. Instalar el paquete nfs-common $ sudo aptitude install nfs-common
  2. Montar el recurso remoto
    Podemos montar el recurso remoto manualmente, mediante el comando mount: $ sudo mount -t nfs servidor:/ /foo/bar * A mount le podremos pasar todas las opciones que consideremos oportunas.

    O, también, podremos añadir el recurso remoto en el fichero /etc/fstab para montarlo más cómodamente o durante el arranque: servidor:/ /foo/bar/ nfs opciones 0 0 * servidor: El nombre del servidor (si lo tenemos añadido en hosts), la URI o la dirección IP del servidor.
    * /foo/bar: El punto de montaje local.
    * opciones: Opciones de montaje.

Enjoy!

domingo, 15 de septiembre de 2013

ssh sin contraseña, utilizando claves rsa

Supongamos que tenemos dos equipos entre los que nos conectamos habitualmente utilizando ssh.El equipo1 (10.0.0.1) y el equipo2 (10.0.0.2).

Al conectarnos con mucha frecuencia, introducir la contraseña cada vez que nos conectamos se convierte en una labor repetitiva, cansina y en una pérdida de tiempo. Para poder conectarnos entre ellos de forma cómoda y segura, podemos hacerlo utilizando claves rsa, en vez de contraseña.


Esquema de los equipos y sentido de la conexión ssh
Esquema de los equipos y sentido de la conexión ssh

Para poder conectarnos mediante ssh utilizando las claves rsa, en lugar de tener que introducir la contraseña:

En el equipo1 creamos las claves rsa pública y privada:

rubenhortas@equipo1:~/.ssh$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/rubenhortas/.ssh/id_rsa): [ENTER]
Enter passphrase (empty for no passphrase): [ENTER*]
Enter same passphrase again: [ENTER*]
Your identification has been saved in /home/rubenhortas/.ssh/id_rsa.
Your public key has been saved in /home/rubenhortas/.ssh/id_rsa.pub.
The key fingerprint is:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**
The key's randomart image is:


< Que te lo voy a decir ;)>
 ------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
*Dejad la passphrase en blanco, porque si no la va a pedir cada vez que nos conectemos al equipo2 por ssh

Copiamos la clave pública al equipo2:

rubenhortas@equipo1$ ssh-copy-id -i ~/.ssh/id_rsa.pub 10.0.0.2
The authenticity of host '10.0.0.2 (10.0.0.2)' can't be established.
RSA key fingerprint is **:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
rubenhortas@10.0.0.2's password: [CONTRASEÑA EQUIPO2]

Por último nos conectamos al equipo2 por ssh, y comprobamos que no nos pide la contraseña.

Enjoy!

domingo, 10 de marzo de 2013

manejar varias interfaces de red con firestarter e iptables


Por casualidades (o causalidades) de la vida, llevo una temporada usando firestarter como firewall. Firestarter es una GUI para configurar de forma sencilla iptables. Como con todo, después de usarlo un tiempo, surge una lista de pros y contras, en la que yo destacaría:





Pros:

  • Sencillez: Se configura a través de un asistente y diálogos de prefrencias. Definir reglas y políticas se convirte en algo trivial.
  • Buenos defaults: Creo que tiene una buena configuración por defecto, y suficiente para la mayoría de equipos de escritorio. Aunque siempre se pueden añadir y modificar reglas y políticas.
  • Daemon: Se ejecuta como daemon, y se puede configurar para que se inicie/pare al conectarse a internet o al renovar la sesión DHCP.
  • Icono: El icono (opcional) en el área de notificación. Es imposible pasar algún evento por alto (aunque puede llegar a distraer).

Contras:

  • Interfaces: Firestarter permite configurar un dispositivo de red conectado a internet y un dispositivo de red conectado al área local. El problema está en que, dependiendo de la configuración de la red, la interfaz puede ser la misma, o puede no ser suficiente.

Para configurar otra interfaz hay que añadir manualmente las reglas mediante iptables. Pero, después de añadir las reglas, todo lo que pase por esa interfaz se guardará en los logs*.
El peligro está en que si esta nueva interfaz tiene mucho tráfico, los logs pueden crecer GBs, llegando a saturar la partición donde se almacenan.

Hay una forma de solucionar esto, añadiendo las reglas necesarias en /etc/firestarter/user-pre.
Por ejemplo, si firestarter está controlando una interfaz de red inalámbrica (wlan0), para permitir todo el tráfico a través de una interfaz de red cableada (eth0), hay que añadir:

iptables -A INPUT -i eth0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j ACCEPT

*Llegados a este punto, he de decir que para evitar saturar los logs lo he intentado todo, o, por lo menos, todo lo que se me ocurrió. He intentado añadir reglas con -m limit, --limit, --limit-burst, LOG, añadir las reglas a las creadas por firestarter... Pero todo se seguía guardando en los logs.
Si conoces otra forma de evitarlo, agradecería un comentario ;)

domingo, 23 de septiembre de 2012

protege tu grub

La configuración por defecto de GRUB permite que cualquier persona con acceso físico a la máquina, pueda acceder a él y editarlo, pudiendo así obtener una GRUB shell. El problema aparece cuando esa persona tiene ciertos conocimientos y se hace con una root shell, como explican en flu-project en el artículo "El Sticky Keys (sethc.exe) de GNU/Linux".

No es un fallo de seguridad, como bien aclaran en flu-project y el proyecto GNU. Se deja así para facilitar la recuperación de sistemas estropeados, lo cual se consiera la opción más razonable para la mayoría de sistemas. Ya que una persona con acceso físico a la máquina podría utilizar distintas técnicas para comprometerla. De todas formas, en GNU, reconocen y advierten de que en ciertos entornos es conveniente bloquear el cargador de arranque. Así que, si no os fiais del entorno en el que puede acabar vuestro ordenador, bloqueadlo ;)

Cómo podemos bloquear el GRUB?

En dos sencillos pasos:


1. Generar una contraseña de forma segura:

$ grub-mkpasswd-pbkdf2

2. Editar el fichero /etc/grub.d/40_custom y añadir dos líneas:

set superusers="nombreUsuario"
password_pbkdf2 nombreUsuario grub.pbkdf2.sha512.password.increiblmente.larga.que.generamos.antes

Si la opción --unrestricted no es usada en las entradas de grub (y no es añadida por defecto), sólo los usuarios especificados en la lista de superusers podrán editarlo.

Fuentes:

domingo, 22 de julio de 2012

evitar los inhibidores de señal

Imagina que una noche cualquiera estás en tu casa, durmiendo o viendo la televisión, tranquilamente. Cuando, de repente, un grupo de individuos armados decide asaltar tu pueblo con nocturnidad y alevosía. Usando para ello inhibidores de señal (GSM,CDMA,3G,Wifi), prentendiendo así evitar que se conozca y se difunda semejante atrocidad de espectáculo.

Imaginemos, también, que los mass media están durmiendo sus 24h diarias, o demasiado ocupados estudiando ese gran capítulo del periodismo "en verano se habla del calor, en invierno del frío". Pero tú quieres ejercer tus derechos constitucionales, libertad de expresión e información, y hacer saber al mundo lo que está pasando. Cómo puedes evitar sus inhibidores de señal?

  • Cualquier bloqueo: Los inhibidores de señal tienen un alcance limitado. Camina en sentido opuesto a dónde creas que está situado el inhibidor. Una vez salgas de su radio de acción podrás comunicarte con normalidad.
  • Bloqueo de la señal de internet móvil: Usa redes sociales que permitan envíos por sms, como twitter o facebook.
  • Bloqueo de toda señal móvil: Si toda señal móvil se encuentra bloqueada, pero no la señal wifi, se pueden abrir todas las wifis, creando así puntos de acceso distribuidos y accesibles por todo el mundo en toda la zona afectada.
  • Bloqueo de toda señal móvil y wifi: Organización. Creo que llegados a este punto es la mejor alternativa. Por ejemplo, una persona que viva cerca de la primera línea se queda conectada en casa, esperando a que los que retratan el conflicto agoten sus memorias y se las lleven. Esa persona será la encargada de vaciar las memorias y publicar todo el material recogido. Que esa persona esté lo más cerca posible de la primera línea evitará carreras a los intrépidos reporteros y permitirá una retransmisión lo más inmediata posible.
  • Bloqueo de señales móviles, wifi e internet: Aquí se empieza a poner peliaguda la cosa, pero hay alternativas:
    • Módems: En las revueltas de Egipto, varios colectivos de diversos países habilitaron números de teléfono para conectarse mediante módem. Las desventajas son evidentes, hay que tener un módem, un PC en dónde todavía se pueda montar, un número al que conectarse... Pero llegado el caso, tenerlo a mano, o incluso montado y listo para funcionar, puede que no esté de más.
    • Internet por satélite: Si el escenario se localiza en una zona rural, no es raro que algún vecino o edificio público posea una de estas comunicaciones.
    • Radio: Dos alternativas
      • Red de packet radio: Aunque bastante improbable, es una alernativa. Es muy difícil encontrarse a alguien que posea el hardware necesario para montar una emisión de este tipo.
      • Emisoras y teléfonos fijos: Usar las emisoras de radio y los teléfonos fijos para contar a gente cercana lo que está pasando y que ellos lo puedan publicar en todos los medios posibles.
    • Fax: Un gran olvidado, pero empresas, locutorios e incluso alǵun particular, los conservan y les dan uso. Muy útil para poder enviar la información fuera de la zona del conflicto, a tanta distancia como se quiera. Amigos, familiares, algún medio de comunicación (incluso extranjeros), seguro que están encantados de recibirla.

Son sólo unas ideas y técnicas recogidas de diversas revoluciones en todo el mundo. Si quieres aportar alguna más siéntete libre de usar los comentarios -;)

Si has llegado hasta aquí, quizás también te interesen:

domingo, 20 de mayo de 2012

usando la nube con sentido común y p7zip

Al hilo del anterior post ( usando la nube con sentido común y aespipe ), y después de investigar un poco, voy a explicar algo más la última nota del artículo, porque creo que quedó bastante escueta y aislada, y merece profundizar un poco más ;)

p7zip Es, hoy por hoy, mi utilidad favorita para comprimir. Es la versión, en línea de comandos, de 7zip para sistemas POSIX. Es open source, consigue muy buenos ratios de compresión, usa varios núcleos, soporta un montón de formatos y puede cifrar usando AES-256.

*Si lo que queremos es comprimir con contraseña, el script se puede adaptar cambiando la línea de aespipe por el comando que queramos ejecutar. Por ejemplo, para comprimir con contraseña usando p7zip y header encryption (mhe=on):
7z a -r -mhe=on -pCONTRASEÑA $i.7z $i

Esta nota, hace referencia a compimir con contraseña usando p7zip, lo que yo no sabía cuando lo escribí es que, de forma resumida, viene siendo un "comprimir y cifrar para vagos".

Cuando comprimimos con p7zip y usamos contraseña, p7zip aplica una función de derivación basada en SHA-256 a la contraseña, y usa el resultado como clave para cifrar con el algoritmo AES-256.

Resumiendo, sería parecido al método explicado usando aespipe, pero todo en uno ;)

domingo, 13 de mayo de 2012

usando la nube con sentido común y aespipe

Con el reciente auge de los servicios de almacenamiento "gratuítos" en la nube, dropbox, skydrive, google drive... Aparecen unas posibilidades de uso interesantes. Una de ellas es la de usarlos para guardar pequeños backups o utilidades a las que poder acceder desde cualquier sitio con conexión a internet.

Llegados a este punto, deberíamos reflexionar sobre qué información almacenar en este tipo de servicios. Si la información es de carácter crítico, almacenarla en un servicio de este tipo, no es buena idea. En este caso sería más conveniente utilizar un servicio de almacenamiento de pago, o contratar los servicios de una empresa de backuping, con unos términos de uso claros y definidos que garanticen que nuestra información no será accedida por ninguna persona, OCR, bot...

Una vez decidida la información que queremos almacenar en la nube, no todo lo que subamos va a tener el mismo nivel de relevancia o privacidad. Deberíamos clasificar la información, y definir unas políticas de seguridad claras en base a cada tipo. Es decir, no es lo mismo subir unos ebooks, subir unos ficheros de configuración, subir algún proyecto personal o subir una lista de passwords. Por eso habrá que separar la información, básicamente en dos grupos, la que nos da igual que se vea o sea indexada, y la que queremos que permanezca totalmente privada.

Para evitar miradas ajenas sobre la información que queremos que se mantenga privada, tenemos varias alternativas. Entre ellas:

  • Subir el contenido comprimido con contraseña (y confiar en que no se van a realizar ataques de fuerza bruta).
  • Cifrar, cifrar y cifrar

Como la segunda es más segura que la primera, para este punto, tendremos varias posibilidades:

  1. Truecrypt: Todo un clásico y un indispensable en nuestros ordenadores, está claro. La parte mala de usar truecrypt es que requiere crear volúmenes/contenedores de datos, y por pequeños que sean, suponen una gran descarga de datos adicional. Es decir, si el fichero que nos queremos bajar es de 500Kb, por pequeño que sea el contenedor de truecrypt (50Mb, 10Mb?),descargarse el contenedor entero, supone una descarga de datos inmensa en relación con el tamaño del fichero.
  2. GPG: Otro clásico. Una buena elección para cifrar fichero por fichero, siempre que seas ordenado, y guardes y exportes correctamente tus claves gpg. (No es mi caso ;))
  3. Aespipe: Aespipe es una utilidad para cifrar fichero a fichero. Crea ficheros .tar o .cpio cifrados. Lo mejor de usarlo, es que los ficheros mantienen su tamaño original. Aespipe puede trabajar usando claves gpg, aunque no voy a centrarme en este caso, por lo comentado en el punto anterior.

Si escogemos aespipe, éste trabaja, por defecto, en su modo recomendado multi-key-v3, que requiere una clave con una longitud mínima de 20 caractereres. Llegados a este punto, podemos optar por usar una clave del tipo "googlemecagontostusmuertosnomiresloqueguardo", o escoger una clave (segura) que usemos habitualmente, que no llegue a los 20 caracteres y cifrarla, por ejemplo con un SHA.

$ echo -n nuestrapass | sha512sum
c9087d475d0307f2e4130f0d919084366c4572eb2ef88df62d560ba01d40a3d8ddf1c9186662903d3d27e164b6cf4acf5e1400095d3814716ac5176a756f84fe -

Con esto conseguimos una clave que supera ampliamente los 20 caracteres, y que podremos generar en cualquier equipo que utilicemos, recordando, simplemente, nuestra clave y el algoritmo de cifrado.

Si vamos a cifrar un solo fichero, copiar y pegar la pass es suficiente. Pero si vamos a cifrar varios ficheros, podemos guardar la contraseña en un fichero que almacenaremos de forma temporal y que le pasárselo a aespipe como parámetro:

  1. Exportar la clave al fichero:
    $ echo -n nuestrapass | sha512sum | cut -d " " -f1 >> passParaLaNube.txt
  2. Pasarle el fichero con la clave a aespipe como parámetro:
    $ aespipe -e aes256 -P passParaLaNube.txt ficheroCifrado.tgz
  3. Descifrar el fichero:
    $ aespipe -e aes256 -d -P passParaLaNube.txt fichero

Si vamos a cifrar una cantidad considerable de ficheros, podemos automatizar la tarea con un pequeño script en bash:

#!/bin/bash
for i in *;
do 
   if [ $i != script -a $i != passParaLaNube.txt ];
   then
      aespipe -e aes256 -P passParaLaNube.txt <$i >$i.tgz
   fi;
done;

*script es el nombre del script

*passParaLaNube.txt es el nombre del fichero con la contraseña para aespipe

*Si lo que queremos es comprimir con contraseña, el script se puede adaptar cambiando la línea de aespipe por el comando que queramos ejecutar. Por ejemplo, para comprimir con contraseña usando p7zip y header encryption (mhe=on):
7z a -r -mhe=on -pCONTRASEÑA $i.7z $i
(También habría que quitar -a $i != passParaLaNube.txt de la condición de evaluación del if ;) )

(Segunda parte) usando la nube con sentido común y p7zip

martes, 28 de febrero de 2012

en la brecha

Me complace anunciaros que, desde hoy, estoy en la brecha. Una nueva sección en el blog de psi-udc, gestionado por Nino, uno de mis "top 3 profesores", tanto por sus conocimientos, como por su forma de enseñar, como a nivel de persona.

Esta sección está dedicada a referencias vinculadas con mundo de la seguridad mantenidas por alumnos de la FIC.

Si formas parte de este grupo, anímate!

lunes, 27 de junio de 2011

google mobile app tus mails en plano

Si estás leyendo esto, estoy seguro de que tú también eres un curioso y que te gusta investigar y saber cómo funcionan las aplicaciones que usas.

Todos sabemos que a estas alturas los teléfonos móviles son ordenadores de bolsillo, los cuales cuentan con su propio sistema operativo. En estos dispositivos almacenamos información de carácter personal, casi exclusivamente, por eso debemos tener cuidado a la hora de elegir las aplicaciones que usamos.

Uno de los mayores problemas que tenemos con los teléfonos móbiles, o smartphones, a día de hoy, son las aplicaciones, diseñadas bajo el mítico lema "malo será". El diseño de las aplicaciones está orientado al uso de un único usuario.

Al estar el dispositivo mínimamente protegido, parece que algunos desarrolladores se olvidan de los casos de pérdida, robo y/o aplicación de técnicas forenses sobre el dispositivo. Dejando así nuestros datos e información personal expuestos al control de casi cualquiera, y ya sabemos aquello de "Un usuario malintencionado podría..." >;)

Personalmente, que pase esto en una aplicación de terceros de dudosa confianza, no me extraña, ni me preocupa, cada cual las instala bajo su cuenta y riesgo, pero que pase en un software propiedad de una compañía como Google, sí me parece preocupante.

Totalmente de forma casual, hoy le toca un análisis forense a google mobile app para symbian. En mi caso en un Nokia N85, que no es precisamente de última generación, pero, supongo que, lo hallado se puede extrapolar a cualquier otro teléfono con symbian s60.
Si alguno lo comprueba y quiere dejar un comentario, siempre es de agradecer ;)

Análisis a google mobile app


miércoles, 2 de febrero de 2011

saltarse el bloqueo a internet


Cómo saltarse un bloqueo a internet?
Esta cuestión puede ser básica, si por ejemplo, tu gobierno decide vetar el acceso a la red, a la totalidad de la misma o a ciertas páginas.

Antes de nada, hay que diferenciar los distintos tipos de bloqueo a los que nos podemos enfrentar:



Bloqueo de sitios
  • Bloqueo de DNS
  • Si se trata de un bloqueo de DNS, podremos seguir accediendo a las páginas bloqueadas mediante su dirección IP, aunque es más cómodo cambiar nuestras DNS actuales por otras como las Google Public DNS, OpenDNS, ScrubIT o DNS Advantage. Otra opción es montarse un BIND9 en tu propia máquina -como los hombres!- @Jordi Rubió >;).
  • Proxies
  • No muchos de nosotros disponemos de un equipo que podamos usar de proxy situado en otro país. De todas formas existen infinidad de web proxies a nuestra disposición, con los que podremos saltarnos bloqueos sobre ciertas webs.
  • Aplicaciones
    • Tor
    • Retransmite nuestras comunicaciones (navegación web y mensajería instantánea) a través de una red distribuida de usuarios por todo el mundo.
    • Plugins para navegadores (Anonimízate!)
      • Disconnect
      • Ghostery
      • Https-Everywhere
      • Notscripts
      • Tor
  • VPN's
  • Redes privadas Virtuales. Conéctate a otras redes como si fueses parte de la misma.

Internet apagado
  • SMS
  • Algunas redes sociales, como twitter, permiten subir contenido desde teléfonos móviles vía SMS.
  • Módems
  • Si aún tienes uno de estos viejos trastos, y un dinosaurio dónde poder montarlo, por soprendente que pueda parecer, comunicarse por vía telefónica mediante una de estas reliquias puede constituir una buena alternativa. También existen los módems por radio, aunque debido a que es bastante extraño poseer uno de éstos, y a que hay que transmitir la información por radio, no sé si se pueden considerar una alternativa real.

Otras alternativas
  • Internet por satélite
  • Redes Ad Hoc
  • Montar una red entre varios equipos, en las que se pueden montar todos los servicios que se desee para el intercambio de datos.
  • Radio
  • Si eres radioaficionado, esta es una buena alternativa para comunicarse y organizarse, y además, si eres geek, puedes montar una red ad-hoc de packet radio, para aquellos que tengan módems por radio.
  • Fax
  • Envío de faxes a otros sitios dónde internet no esté bloqueado y puedan hacerse eco de la información.
Más agresivas
  • Mesh Potato
  • Es un dispositivo que proporciona telefonía low-cost e internet. Muy asequible

Rozando el subrealismo (o la desesperación)
  • OpenBTS
  • Crea tu propia red de telefonía celular con OpenBTS y un USRP. Un poco caro, sí, pero cuanta gente puede presumir de tener su propia red para móviles? >;)

Fuentes:

domingo, 8 de agosto de 2010

mtr, combina ping y traceroute

MTR es una alternativa, para os x, a ping y a traceroute. Esta herramienta para diagnóstico de red muestra los detalles de la conexión entre nuestra máquina y un host destino, mostando los saltos (como traceroute) y enviando ICMP ECHOs (como ping) para calcular la calidad del enlace.

Se puede instalar desde los darwin ports o compilando el código fuente.

Vía: osxdaily

Código de MTR desde la página de los desarrolladores

Instalar MTR desde los darwin ports

martes, 29 de junio de 2010

hacking mindmap

Un impresionante, e interesante, mapa mental sobre hacking y/o protección y seguridad de la información, que a fin de cuentas, cuando no son lo mismo están íntimamente ligados...
El documento se puede descargar en varios formatos. Está en francés, pero se entiende bien, así que por eso no dejéis de echarle un ojo ;)

Documento: Hackingmindmap

Vía: daboblog

lunes, 5 de abril de 2010

mms bomber

Todos sabemos que los smartphones son pequeños ordenadores, con sus pequeños sistemas operativos, sus pequeñas aplicaciones, y sus pequeños corazoncitos :')

Por eso mismo, y por otras causas, como que en ellos almacenamos diversas informaciones de carácter personal y/o profesional, o su baja protección, los han convertido, cada vez con más frecuencia en un objetivo más para el malware.

Hace poco, estuvo en boca de todos el caso de la botnet "mariposa", y las HTC vodafone infectadas, ahora desde China llega "mms bomber", un virus que tiene infectados millones de terminales de tercera generación s60. Este virus, básicamente, una vez instalado desactiva los programas de gestión, como mecanismo de defensa, para impedir su desinstalación, se conecta a internet y envía mms a urls malignas sin que el usuario se entere.

Cada vez está más claro que hacen falta aplicaciones para mantener protegidos este tipo de dispositivos. Para los usuarios de móviles con s60, os dejo aquí algunas soluciones:

domingo, 4 de abril de 2010

'hardenizando' os x

En informática se conoce como hardening el proceso de securizar un sistema reduciendo su "superficie de vulnerabilidad", se trata de "fortificar" un sistema reduciendo sus posibles puntos débiles.
Desde el punto de vista de hardening, securizar mac os x 10.5 "Leopard" y mac os x 10.6 "Snow Leopard", es muy similar, con un par de cambios en los pasos y en algún archivo.
Para ir empezando a securizar os x 10.6, antes de que salga la guía de configuración de seguridad, podemos aplicar los pasos de la guía para os x 10.5.
Hay que recordar que estas guías son el producto de la colaboración entre Apple, NSA, NIST y DISA.
Aquí dejo un par de enlaces para los que queráis ir empezando/curioseando ;)

lunes, 29 de marzo de 2010

GIFAR otro "steganography trick"

Desde hace -relativamente- poco tiempo, cada vez es más habitual encontrarse artículos sobre esteganografía, hasta hace "poco" esa gran desconocida. La gran mayoría de estos artículos hablan sobre aplicaciones, ya sean conocidas o nuevas, y en cómo podemos camuflar un tipo de archivo dentro de otro.
En el artículo "GIFAR otro "steganography trick", nos hablan de una técnica que permite ocultar archivos .jar dentro de archivos .gif y .pdf, y de cómo un atacante podría explotar esta técnica presentada en la BlackHat US '08, uno de los eventos de seguridad más importantes del mundo.

Vía: pentester

jueves, 10 de diciembre de 2009

troyanos para linux

omgubuntu informa de que se ha encontrado malware oculto en un paquete .deb que contiene un -aparentemente inofensivo- salvapantallas, disponible en gnome-look. El .deb instala un script que deja el equipo preparado para participar en un ataque DDoS. El archivo ya ha sido eliminado de gnome-look.

En la noticia original podéis leer más información y la solución: http://www.omgubuntu.co.uk/2009/12/malware-found-in-screensaver-for-ubuntu.html

Además, leo en slashdot que hay un informe similar en digitizor, éste trata sobre malware encontrado en un tema llamado 'ninja black', en éste artículo también publican la solución al problema.

Quizás ahora a muchos ya no les parezca tan descabellado usar ciertas políticas de seguridad -bastante básicas, por cierto- en gnu/linux...

lunes, 14 de septiembre de 2009

iStat Menu, monitorizando en os x

Cuidar nuestro hardware es muy importante, así como tener monitorizada la actividad y el uso que estamos haciendo del mismo en todo momento, hasta ahora, para esta tarea, en os x, yo usaba iStat pro con el inconveniente -para mí- de ser un widget, pero gracias a os x daily, he descubierto iStat Menus, que es un monitor integrado en la barra superior de os x, es muy configurable, y muestra todo tipo de información.
Es muy útil y cómodo para monitorizar de un solo vistazo el estado de nuestro equipo. Tengo que decir que en cuanto lo he probado me he enamorado de él, sólo hecho de menos el apartado para la batería que tiene iStat pro, y que cuenta con el inconveniente de que poner demasiada información en la barra superior puede llevar a distracciones, provocando así un efecto contraproducente, pero esto ya es cosa de cada uno.

El artículo gracias al que he descubierto esta aplicación podéis leerlo aquí: Monitor Vital System Stats with iStat Menu

Vía: os x daily

domingo, 13 de septiembre de 2009

como proteger tus pertenencias

La seguridad es un aspecto importante en nuestras vidas, no sólo en lo que a ámbitos informáticos se refiere, desde lifehacker, nos dan una serie de consejos para proteger nuestras pertenencias, los puntos más interesantes, en mi opinión, son:

8. Get a carry bag that doesn't scream "Steal me!" (Consigue una funda que no grite "róbame!")
En este punto en concreto me he acordado de Jordi Rubió, porque ya hace mucho que usa esa técnica, concretamente meter el portátil dentro de uno de esos periódicos que regalan en el metro, y a pesar de su sencillez, este pequeño truco, resulta efectivo para mantener alejadas las miradas y los intereses de los amigos de lo ajeno ;)

6. Destroy a credit card the right way (destruye una tarjeta de crédito, la forma correcta)
Este apartado contiene un vídeo explicativo, como el resto del artículo se encuentra en inglés, pero se puede entender perfectamente sin tener ningún conocimiento del idioma. Con unos sencillos pasos podemos destruir de forma segura nuestras tarjetas obsoletas.

5. Erase your hard drives the permanent way (Borrar tus discos duros, la forma permanente)
Es cierto, muchos de los discos duros acaban siendo vendidos en ebay, sí, muchos otros, incluso ordenadores enteros, acaban siendo tirados en puntos limpios, regalados o donados, y muchos de éstos, van incluso sin formatear, la manera de acceder a los datos que contienen, en este caso, es trivial. Pero aún en el caso de que un disco duro se tire o regale formateado, recuperar la información que contenía no es tarea difícil, debemos tener en cuenta que dentro de toda la información contenida, siempre hay un espacio dedicado a información personal privada, documentos, fotos, vídeos, contraseñas de todo tipo... Esta información, de caer en malas manos, puede llegar a comprometer nuestra privacidad de forma drástica, para evitar eso, nos envían a un artículo, Properly Erase Your Physical Media [ENG], dónde explican algunas formas sencillas de realizar borrados seguros a nuestros discos duros, tanto a nivel lógico como físico, aunque no debemos olvidar que hay otras muchas formas, y que, estoy seguro de que como diría Nino, en caso de que consigan acceder a nuestra información, no debemos olvidar poner las cosas difíciles, y para ésto, el cifrado es un buen comienzo.


1. Set up a laptop security system (configurar un sistema de seguridad en el portátil)
Este punto me recuerda a un artículo que leí hace un tiempo, dónde un usuario de os x, gracias a estas prácticas, conseguía recuperar su portátil después de haberle sido robado. Aquí nos enlazan a otro artículo, How to Set Up a Laptop Security System [ENG], dónde nos hablan de algunos sistemas, programas (para windows y os x), y algunas consideraciones a tener en cuenta para implementar de forma efectiva este tipo de tecnología.

Dos puntos que me han llamado la atención de este artículo, y que por tanto merecen mención, son:

7. Put a cute baby in your wallet (Poner (la foto de) un bebé bonito en la cartera)
4. Uglify gear you don't want grabbed (aprox. "Enfea" tus cosas, no quieres ser "mangado")

El artículo original es muy interesante y podéis leerlo entero en "Top 10 Tactics for Protecting Your Stuff" [ENG]

Vía: lifehacker

lunes, 17 de agosto de 2009

poner una contraseña open/efi firmware en el arranque del equipo

Cómo poner una contraseña Open Firmware (en los PPC) o EFI (en los Intel) inmediatamente después del arranque del sistema, antes de que OS X se cargue, con el fin de impedir el acceso de otros usuarios al equipo, lo que equivale a la típica "contraseña de la bios" en un pc ;)

Nota:
[...] if you accidentally mess something up in OpenFirmware or EFI you could have some serious issues with your Mac. [...]


**Si accidentalmente te equivocas en algo con OpenFirmware o con EFI podrías tener algunos problemas graves con tu Mac.

Vía: osxdaily (Citando el artículo original de: support.apple)