Tras lamentar la pérdida, tocaba contención de daños: en el móvil había fotos y otros documentos en la memoria interna que era importante recuperar. Y encima… ¡la partición de datos estaba encriptada!

Para conseguir encriptar el móvil en su día, la clave fue usar el adb conectado al recovery, una puerta de entrada excelente y sencilla al móvil en su estado actual. Así que tras múltiples intentos, y totalmente a ciegas (para empezar, sin saber nunca seguro si el móvil estaba apagado o encendido) conseguí entrar en el recovery (en el Samsung Galaxy S III, pulsando a la vez home, volumen arriba y el botón de encendido). Y supe que estaba en el recovery cuando el adb shell me funcionó (¡qué alegría me llevé!):

C:\adb>adb shell
~ #

Una vez dentro, sólo tuve que montar el sistema de ficheros (encriptado) /data con estos comandos (Android Device Encryption):

~ # setprop ro.crypto.state encrypted
setprop ro.crypto.state encrypted
~ # vdc cryptfs checkpw 'CLAVE_DE_ENCRIPTACION_DE_VICENTE'
vdc cryptfs checkpw 'CLAVE_DE_ENCRIPTACION_DE_VICENTE'
200 0 0
~ # mount -o ro /dev/block/dm-0 /data
mount -o ro /dev/block/dm-0 /data

y, no me lo podía creer… ¡ya podía ver mis ficheros!

Así que cuando finalmente pude copiarlos al disco duro local:

C:\adb>adb pull /data/media/0
pull: building file list...
...
pull: /data/media/0/DCIM/Camera/IMG_20150420_200931.jpg -> ./DCIM/Camera/IMG_20150420_200931.jpg
pull: /data/media/0/DCIM/Camera/IMG_20150415_201132.jpg -> ./DCIM/Camera/IMG_20150415_201132.jpg
pull: /data/media/0/DCIM/Camera/IMG_20150412_172014.jpg -> ./DCIM/Camera/IMG_20150412_172014.jpg
pull: /data/media/0/DCIM/Camera/VID_20150411_233428.mp4 -> ./DCIM/Camera/VID_20150411_233428.mp4
...

¡el éxtasis fue absoluto!

¡Cómo echo de menos jugar con estas cosas (y poder contarlas en el blog) más a menudo!

:wq!

Lo hice y lo entendí © Vicente Navarro 2015 con una licencia CC BY-SA | 4 comentarios
Etiquetas: adb, Android, encriptación, particiones, recovery

Entradas relacionadas

• Problemas para encriptar el móvil/tablet Android con una Custom ROM (5)
• Recuperación de particiones perdidas con gpart (1)
• Probar en VirtualBox una memoria USB de arranque (1)
• Pequeños trucos para Windows (1)
• Montar una imagen raw de Qemu. Los primeros 32 Kbytes de un disco. (1)
• Montar imágenes de disco vdi de VirtualBox (1)

Feed enhanced by Better Feed from Ozh

Sin embargo, en las últimas semanas me he visto “forzado” (¡ya!¡como si no me gustara!) a ponerme un poco las pilas con todo esto cuando mi empresa decidió exigir la encriptación del dispositivo para poder conectar al servidor de correo Exchange. Esto no le sentó nada bien a mi Samsung Galaxy SIII, que nunca antes me había dado ningún problema serio, pero que tan pronto como lo encripté pasó a tener un rendimiento realmente lamentable (p.e. lags de varios segundos en el launcher o al intentar abrir cualquier aplicación… ¡incluso la de teléfono!). Reiniciar el móvil al estado de fábrica y comenzar de nuevo (siempre con encriptación, claro) tampoco ayudaba.

Así que me decidí a probar alguna “Custom ROM“, ya que algunas tenían fama de tener muy buen rendimiento. Para ello, comencé instalando el “Custom Recovery” PhilZ Touch con Odin (Cómo instalar una custom ROM en el Samsung i9300) y empecé a probar varias ROMs, algunas basadas en la original de Samsung (stock) (como Revolutionary S5), y otras basadas en AOSP (como SmartDroid AOSP o ArchiDroid). Pero al final la que más me convenció fue simplemente la CyanogenMod 11, más que nada por su minimalismo y sencillez.

Todas ellas tenían sus pros y sus contras. Sin embargo, con todas ellas tuve el mismo problema: No podía conectarme a Exchange porque en cuanto comenzaba el proceso de encriptación de los datos, el móvil se quedaba colgado en la pantalla del comienzo de la encriptación, donde sale el robot de Android, y no hacía nada más:

Nota: Esta imagen, encroid_waiting.png, está en el Settings.apk

Incluso era posible pulsar el botón de home y volver al launcher y seguir trabajando con normalidad.

Tras instalar el Driver de Samsung para ADB y el ADB (con el “15 seconds ADB Installer“), me conecté a la shell del móvil para ver qué pasaba durante la encriptación y con el comando logcat descubrí la clave del problema:

E/Cryptfs ( 1899): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.

Dicho error me llevó a “Cm10.2 – Encryption Does Not Start, Stuck At Splash Screen” y a “[Q] ClockworkMod wipe blocking encryption?“, donde descubrí que el problema es que:

What I’ve discovered is that the dmcrypt layer requires 16kb of space at the end of the /data partition to store its volume keys.

Es decir, hay que dejar 16 KiB libres al final de la partición para poder encriptar el volumen y es obvio que el recovery que yo estaba usando no lo estaba haciendo al recrear /data (tal vez haya algún otro recovery que sí que lo haga). Así que, siguiendo las instrucciones, arranqué el móvil en modo recovery y me conecté a su shell con adb:

C:\adb>adb shell
~ # mount
mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /storage type tmpfs (rw,seclabel,relatime,mode=050,gid=1028)
tmpfs on /mnt/secure type tmpfs (rw,seclabel,relatime,mode=700)
tmpfs on /mnt/fuse type tmpfs (rw,seclabel,relatime,mode=775,gid=1000)
/dev/block/mmcblk0p8 on /cache type ext4 (rw,seclabel,relatime,errors=panic,user_xattr,barrier=1,journal_async_commit,data=ordered)
/dev/block/mmcblk0p12 on /data type ext4 (rw,seclabel,relatime,errors=panic,user_xattr,barrier=1,journal_async_commit,data=writeback,noauto_da_alloc,discard)

y pude ver que /data era el volumen /dev/block/mmcblk0p12. Luego vi el tamaño de dicho volumen, 12091392 bloques (~11.5GB):

~ # cat /proc/partitions
cat /proc/partitions
major minor  #blocks  name

 179        0   15388672 mmcblk0
 179        1       4096 mmcblk0p1
 179        2       4096 mmcblk0p2
 179        3      20480 mmcblk0p3
 179        4       8192 mmcblk0p4
 179        5       8192 mmcblk0p5
 179        6       8192 mmcblk0p6
 179        7      32768 mmcblk0p7
 179        8    1048576 mmcblk0p8
 179        9    1572864 mmcblk0p9
 179       10     573440 mmcblk0p10
 179       11       8192 mmcblk0p11
 179       12   12091392 mmcblk0p12
 179       16   30931968 mmcblk1
 179       17   30927872 mmcblk1p1

y tras desmontar el sistema de ficheros:

~ # umount /data
umount /data

volví a crear el sistema de ficheros dejando algo de espacio al final, especificando que usara 12091300 bloques, unos pocos menos que los 12091392 disponbles:

~ # mke2fs -T ext4 -L data /dev/block/mmcblk0p12 12091300
mke2fs -T ext4 -L data /dev/block/mmcblk0p12 12091300
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=data
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
755904 inodes, 3022825 blocks
151141 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=3095396352
93 block groups
32768 blocks per group, 32768 fragments per group
8128 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 20 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

tras lo cual reinicié:

~ # reboot
reboot

y ya dentro del sistema (tuve que configurarlo todo de nuevo, claro), ¡pude finalmente encriptar /data sin problemas!

Por cierto, con CyanogenMod el rendimiento es mejor, ahora ya aceptable, pero tampoco super fluído, me temo…

:wq!

Lo hice y lo entendí © Vicente Navarro 2015 con una licencia CC BY-SA | 4 comentarios
Etiquetas: adb, Android, custom ROM, CyanogenMod, encriptación, particiones, recovery

Entradas relacionadas

• Recuperar los ficheros de un dispositivo Android encriptado cuando la pantalla no funciona (5)
• Recuperación de particiones perdidas con gpart (1)
• Probar en VirtualBox una memoria USB de arranque (1)
• Pequeños trucos para Windows (1)
• Montar una imagen raw de Qemu. Los primeros 32 Kbytes de un disco. (1)
• Montar imágenes de disco vdi de VirtualBox (1)

Feed enhanced by Better Feed from Ozh

Por ejemplo, podríamos querer abrir el puerto SSH en el router al detectar un Port Knocking. O podríamos querer abrir un puerto sólo a ciertas horas; o sólo como parte de otra tarea.

También puede ser útil para configurar el WiFi (desactivarlo, activarlo, cambiarle la clave, etc.). En esta entrada vamos a ver, a modo de ejemplo, cómo desactivar o activar el WiFi de varios routers domésticos interaccionando con su interfaz web usando únicamente wget. Un Zyxel P660HW-D1, un Home Station Amper ASL 26555 y un Cisco EPC3825 serán nuestros conejillos de indias.

Los servidores web de los routers domésticos a menudo usan autentificación básica (caso del Zyxel y del Home Station). En otros casos usan cookies para mantener la sesión (caso del Cisco). En ocasiones, la sesión se identifica únicamente con la IP del cliente, de forma que no se permiten accesos concurrentes desde otras IPs (caso del Zyxel). Dichas peticiones pueden hacerse con POSTs (Cisco, Zyxel) o simplemente con parámetros en la URL (Home Station).

La extensión “Live HTTP Headers” para Firefox nos hará muy sencillo ver qué ocurre mientras usamos la web de configuración del router. El wget nos permitirá replicar las mismas operaciones desde línea de comandos.

(...)

Leer el resto de Configurando routers domésticos desde la línea de comandos con wget (615 palabras)

Lo hice y lo entendí © Vicente Navarro 2013 con una licencia CC BY-SA | 5 comentarios
Etiquetas: Cisco EPC3825, cookies, Firefox, Home Station, wget, WiFi, Zyxel 660HW

Entradas relacionadas

• Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (2)
• Hosting casero HOWTO (2)
• Crear los certificados SSL para nuestro servidor web HTTPS con Apache, OpenSSL y Debian Lenny (2)
• Ya tenemos un plugin de Flash nativo para Linux de 64 bits (1)
• Web Fonts, fuentes descargables para la web (1)
• Wake on LAN (1)

Feed enhanced by Better Feed from Ozh

La idea sería que tras modificar los ficheros en uno de los PCs, pudiéramos copiar sólo los cambios al otro PC (que en principio sería poco volumen de datos) sin tener que copiar todos los ficheros cada vez (recordemos que hablamos de muchos GB de datos).

Si ambos sistemas están conectados por red (local, Internet), aunque puede haber otras soluciones diferentes, mi solución preferida sería usar rsync (Backups con rsync), disponible en Linux, Mac OS X y Windows/Cygwin.

También podríamos optar por almacenar los datos en “La Nube“, con Dropbox, Google Drive, Skydrive, iCloud, etc. Así, si modificamos algunos ficheros en un sistema, los ficheros modificados se actualizan en la nube y, posteriormente, en los otros sistemas. Pero ojo, imaginemos que manejamos 100GB de datos. Además de que necesitamos tener al menos dicho espacio contratado en nuestro proveedor de almacenamiento en la nube, resulta que para subir inicialmente 100GB a la nube con una conexión a Internet de 1Mbps de subida necesitaríamos varios días:

100.000.000.000 bytes / ( 1.000.000 bit/s / 8 bytes/bit ) = 800.000 s = 9,26 días

Si no tenemos rsync, ni almacenamiento en la nube, y tal vez ni acceso por red, habría quien copiaría todos los ficheros a un disco duro externo (cientos de GB) o tal vez quien llevara cuenta de qué ficheros han cambiado para copiar sólo esos a una memoria USB. Y posteriormente aún habría que volver a copiar los ficheros en el sistema destino…

Bueno, pues resulta que rdiffdir es una solución excelente a este problema. rdiffdir está escrito en Python, es parte de la aplicación duplicity (para hacer backups de directorios), se basa en rdiff y usa la librería librsync. Con rdiffdir podemos crearnos muy fácilmente un fichero que contenga sólo los cambios con el algoritmo de rsync y aplicar dichos cambios en el sistema que esté desfasado.

Usemos por ejemplo el caso del directorio con documentos profesionales que queremos sincronizar entre el PC de casa y el del trabajo para entender cómo lo haríamos con rdiffdir:

Partimos de un escenario en el que los directorios están perfectamente sincronizados en ambos sistemas. Acabamos de llegar al trabajo, y el directorio que queremos sincronizar contiene lo siguiente:

trabajo ~ $ find directorio/
directorio/
directorio/subdirectorio1
directorio/subdirectorio1/ficheroA.txt
directorio/subdirectorio2
directorio/subdirectorio2/ficheroB.txt

trabajo ~ $ cat directorio/subdirectorio1/ficheroA.txt
Prueba A

trabajo ~ $ cat directorio/subdirectorio2/ficheroB.txt
Prueba B

Antes de comenzar a trabajar, generamos un fichero con los checksums de los bloques de los ficheros y con la información de los directorios con rdiffdir:

trabajo ~ $ rdiffdir signature directorio signature_$(date +%y%m%d).rdiffdir

Y comenzamos a trabajar: editamos ficheros, añadimos ficheros y directorios, borramos ficheros…

trabajo ~ $ echo "Nueva linea" >> directorio/subdirectorio1/ficheroA.txt

trabajo ~ $ rm -rf directorio/subdirectorio2/

trabajo ~ $ mkdir directorio/subdirectorio3

trabajo ~ $ echo "Prueba C" > directorio/subdirectorio3/ficheroC.txt

y al final de la jornada, copiamos el fichero de firmas y generamos un fichero con los cambios:

trabajo ~ $ rdiffdir delta signature_130208.rdiff directorio cambios_$(date +%y%m%d).rdiffdir

Nos vamos a casa, copiamos el fichero de cambios, y lo aplicamos sobre el directorio:

casa ~ $ rdiffdir patch directorio cambios_130208.rdiffdir

y verificamos que, efectivamente, tenemos los cambios del día:

casa ~ $ find directorio
directorio
directorio/subdirectorio1
directorio/subdirectorio1/ficheroA.txt
directorio/subdirectorio3
directorio/subdirectorio3/ficheroC.txt

casa ~ $ cat directorio/subdirectorio1/ficheroA.txt
Prueba A
Nueva linea

casa ~ $ cat directorio/subdirectorio3/ficheroC.txt
Prueba C

Si pensamos hacer cambios en casa, habría que repetir el proceso: generar un fichero de firmas antes de empezar, y uno de cambios al finalizar.

Pero, ¡a ver si va a costar más el collar que el perro! ¿Qué ocupa un fichero de firmas de un directorio enorme? ¿Qué tarda en generarlo? Pues acabo de probar con un directorio con 22000 ficheros, 1400 directorios y 10GB y ha tardado sobre 6 minutos y ocupa unos 130MB: Un tamaño adecuado para poder transportarlo en una memoria USB.

duplicity está disponible en algunas distribuciones Linux (Fedora, Ubuntu, Debian). En otras, podemos compilarlo. También podemos usarlo en Windows bajo Cygwin. Hay que instalar previamente los paquetes python, librsync1 y librsync-devel y luego, sólo hay que bajar el fichero con las fuentes, descomprimirlo, entrar en él desde la shell de Cygwin y ejecutar:

python setup.py install

:wq!

Lo hice y lo entendí © Vicente Navarro 2013 con una licencia CC BY-SA | 5 comentarios
Etiquetas: Cygwin, GNU/Linux, Internet, La Nube, rdiffdir, rsync, Windows

Entradas relacionadas

• Backups con rsync (4)
• rsync siempre sincroniza ciertos ficheros. Ver los segundos de la fecha de un fichero. (3)
• Hosting casero HOWTO (3)
• El paso a UTF-8 con Ubuntu Hardy Heron: rsync entre sistemas con distinto juego de caracteres (3)
• ¿Piensas en si un día te roban el portátil? (3)
• Wake on LAN (2)

Feed enhanced by Better Feed from Ozh

De momento, aún no me he decidido a probar nada “no oficial” hasta que entienda un poco mejor cómo funciona todo, pero sí que me he atrevido a probar a actualizar con el firmware oficial de otro país (Instalar Jelly Bean [4.1.1][OFICIAL][P5110XXCLK7]). Cuando he visto que el fichero del firmware era un fichero .tar.md5, no he podido resistirme a desempaquetarlo e intentar entender qué hay dentro.

Lo primero que uno se pregunta es que qué es eso de .tar.md5. Pues es simplemente un fichero tar con formato “ustar” (POSIX.1-1988) al que le añadirmos al final un md5sum de sí mismo (How to make an Odin flashable .tar from .img):

$ tar -H ustar -c image_1 [image_2 ...] > your_odin_package.tar
$ md5sum -t your_odin_package.tar >> your_odin_package.tar
$ mv your_odin_package.tar your_odin_package.tar.md5

La siguiente pregunta sería: ¿cómo podemos verificar la integridad de un fichero .tar.md5?

Podemos ver que el resultado del md5sum está claramente visible al final del fichero:

$ tail -c 100 P5110XXCLK7_P5110OXACLK7_HOME.tar.md5 | hexdump -C -v
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  65 63 39 66 61 34 62 31  38 66 64 31 36 35 38 63  |ec9fa4b18fd1658c|
00000030  62 30 61 36 65 39 62 31  63 62 39 66 66 32 62 63  |b0a6e9b1cb9ff2bc|
00000040  20 20 50 35 31 31 30 58  58 43 4c 4b 37 5f 50 35  |  P5110XXCLK7_P5|
00000050  31 31 30 4f 58 41 43 4c  4b 37 5f 48 4f 4d 45 2e  |110OXACLK7_HOME.|
00000060  74 61 72 0a                                       |tar.|
00000064

Sabiendo que la longitud de un hash MD5 es 128-bits (32 dígitos hexadecimales), el tamaño del nombre del fichero y que el md5sum deja dos espacios entre el hash MD5 y el nombre y añade un fin de línea (0x0a), podemos extraer el fichero .md5 leyendo sólo los últimos “32(MD5)+2(espacios)+1(0x0a)-4(.md5)+nombre del fichero” caracteres:

$ FICHERO_FIRMWARE=P5110XXCLK7_P5110OXACLK7_HOME.tar.md5
$ tail -c $(( $( echo -n $FICHERO_FIRMWARE | wc -c )+32+2+1-4 )) $FICHERO_FIRMWARE
ec9fa4b18fd1658cb0a6e9b1cb9ff2bc  P5110XXCLK7_P5110OXACLK7_HOME.tar

y verificar la integridad del fichero leyendo todo el fichero menos la parte del md5sum:

$ head -c -$(( $( echo -n $FICHERO_FIRMWARE | wc -c )+32+2+1-4 )) $FICHERO_FIRMWARE | md5sum
ec9fa4b18fd1658cb0a6e9b1cb9ff2bc  -

Una vez verificada la integridad del fichero, se desempaqueta como cualquier otro fichero tar:

$ tar xvf P5110XXCLK7_P5110OXACLK7_HOME.tar.md5
Sbl.bin
boot.img
cache.img
hidden.img
recovery.img
system.img

El fichero Sbl.bin es el Secondary Bootloader, del que se suele hablar a menudo en los foros de XDA Developers (por ejemplo: [LISTING] Firmware with Fixed (OS X Compatible) Secondary Bootloader (Sbl.bin)). El artículo “The Android boot process from power on” es una buena referencia para entender cómo es el proceso de arranque de Android.

El resto de ficheros .img son imágenes de las particiones de Android (Android Partitions Explained: boot, system, recovery, data, cache & misc).

Los ficheros boot.img y recovery.img contienen el kernel Linux y un initrd para arrancar el sistema. boot.img es el principal y recovery.img se usa para arrancar en modo recovery (en las tablets Samsung, suele ser arrancar con el botón de Power y el de “volumen abajo” apretados y en los móviles Samsung, suele ser arrancar con el botón de Power, Home y el de “volumen arriba” apretados).

Ambos ficheros están en formato Android Boot Images. Podemos desempaquetar dicho formato con abootimg o con el script del artículo Extracting, Editing and Re-Packing boot.img in Windows. Si nos decidimos por esta última opción, obtenemos los mencionados ficheros y las opciones de arranque que se le han de pasar al kernel:

$ ./split_bootimg.pl boot.img
Page size: 2048 (0x00000800)
Kernel size: 4385112 (0x0042e958)
Ramdisk size: 485026 (0x000766a2)
Second size: 0 (0x00000000)
Board name:
Command line: console=ttyO2,115200n8 mem=1024M androidboot.console=ttyO2 vram=20M omapfb.vram=0:16M androidboot.carrier=wifi
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.

$ ./split_bootimg.pl recovery.img
Page size: 2048 (0x00000800)
Kernel size: 4385112 (0x0042e958)
Ramdisk size: 1195680 (0x00123ea0)
Second size: 0 (0x00000000)
Board name:
Command line: console=ttyO2,115200n8 mem=1024M androidboot.console=ttyO2 vram=20M omapfb.vram=0:16M androidboot.carrier=wifi
Writing recovery.img-kernel ... complete.
Writing recovery.img-ramdisk.gz ... complete.

Los kernels de ambos ficheros son idénticos:

# md5sum boot.img-kernel recovery.img-kernel
89d3f9249d218e10e08f9b947188a76a  boot.img-kernel
89d3f9249d218e10e08f9b947188a76a  recovery.img-kernel

pero los initrd, no. Como es habitual en los initrd de los sistemas Linux de escritorio, es posible desempaquetarlos con “cpio -i -v” (o “cpio -t -v” si sólo queremos ver los ficheros que llevan):

gzip -d -c boot.img-ramdisk.gz | cpio -i -v
gzip -d -c recovery.img-ramdisk.gz | cpio -i -v

y veremos que más o menos llevan los mismos ficheros; con la particularidad de que el recovery.img-ramdisk.gz lleva además las típicas imágenes que componen la animación de cuando Android se está actualizando:

Finalmente, los ficheros cache.img, hidden.img y system.img son imágenes sparse de sistemas de ficheros ext4. Podemos convertirlas a imágenes normales con la utilidad simg2img (ver [REF] Unpacking and repacking stock rom .img files):

$ /tmp/ext4_utils/simg2img system.img system_normal.img

y ya montarla en modo loopback:

# mount -t ext4 -o loop system2.img /mnt/loop/

# ll /mnt/loop/
total 72
drwxr-xr-x  2 root root  8192 Nov 22 14:27 app
drwxr-xr-x  2 root 2000  4096 Nov 22 14:27 bin
-rw-r--r--  1 root root  2781 Nov 22 14:27 build.prop
drwxr-xr-x  2 root root  4096 Nov 22 14:27 cameradata
drwxr-xr-x 11 root root  4096 Nov 22 14:36 etc
drwxr-xr-x  2 root root  4096 Nov 22 14:27 fonts
drwxr-xr-x  2 root root  4096 Nov 22 14:27 framework
drwxr-xr-x  2 root root  4096 Nov 22 14:27 hdic
drwxr-xr-x  9 root root 12288 Nov 22 14:36 lib
drwxr-xr-x  4 root root  4096 Nov 22 14:27 media
drwxr-xr-x  4 root root  4096 Nov 22 14:27 tts
drwxr-xr-x  8 root root  4096 Nov 22 14:27 usr
drwxr-xr-x  8 root 2000  4096 Nov 22 14:36 vendor
drwxr-xr-x  4 root root  4096 Nov 22 14:27 vsc
drwxr-xr-x  2 root 2000  4096 Nov 22 14:27 xbin

Y en este punto, hemos conseguido acceso a todos los ficheros del firmware. Qué hacer ahora con ellos es otra, muy larga, historia…

Actualización 28/2/2013: He descubierto un interesante documento muy similar a esta entrada: HOWTO: Unpack, Edit, and Re-Pack Boot Images

:wq!

Lo hice y lo entendí © Vicente Navarro 2013 con una licencia CC BY-SA | 2 comentarios
Etiquetas: Android, cpio, GNU/Linux, initrd, tar

Entradas relacionadas

• Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio. (4)
• Solucionando el error “attempt to access beyond end of device” con reglas de udev, hal y/o un parche del kernel (2)
• Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID (2)
• Compilar el kernel de Linux (2)
• Ya tenemos un plugin de Flash nativo para Linux de 64 bits (1)
• Wake on LAN (1)

Feed enhanced by Better Feed from Ozh

Es frecuente leer (HD sin hache, La Alta Definición en la TDT roza la ilegalidad en cuanto a calidad) que el problema de las emisiones de TDT en HD en España es que el bitrate es muy bajo (cuando no es que los contenidos son simplemente contenidos de definición estándar reescalados). He querido demostrar que realmente es así y me he puesto manos a la obra con mi viejo PC con la VIA EPIA SP8000E y sintonizadora Hauppauge WinTV-HVR-1100. Es fácil analizar en Debian las emisiones DVB-T gracias a los paquetes w-scan, dvbsnoop y dvb-tools.

Antes de empezar, conviene aclarar algunos conceptos del estándar DVB-T: En cada canal de radiofrecuencia de 8 MHz de los que tradicionalmente se usaban para la televisión analógica, el estándar DVB-T transmite un flujo de datos digitales (MPEG-TS) de entre unos 5 y 30 Mbps (en España típicamente 20 Mbps), en función de la modulación, codificación y otros parámetros (DVB-T: Available bitrates (Mbit/s) for a DVB-T system in 8 MHz channels). En ese flujo de datos, típicamente llamado múltiplex, se multiplexan en el tiempo varios flujos de datos de vídeo y de audio, permitiendo así que en cada múltiplex viajen varios programas de TV y de radio a la vez. Cada uno de los flujos de vídeo y audio tiene un PID (Program Identification) que lo identifica.

Pasemos ahora a medir el bitrate de los flujos de vídeo de las emisiones de TDT en España. Para usar los siguientes comandos se supone que tenemos una sintonizadora de DVB-T correctamente configurada en un sistema Linux.

(...)

Leer el resto de Midiendo la calidad de la TDT en alta definición en España (1,430 palabras)

Lo hice y lo entendí © Vicente Navarro 2012 con una licencia CC BY-SA | 53 comentarios
Etiquetas: DVB-T, dvdsnoop, Full HD, GNU/Linux, H.264, Hauppauge WinTV-HVR-1100, HD, MPEG2, pv, TDT, Televisión, tzap

Entradas relacionadas

• La TDT en alta definición en España: Llegará pero, ¿la podremos ver? (5)
• Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG (3)
• La resolución 1366×768 (3)
• Configuración de una Hauppauge WinTV-HVR-1100 en Linux (3)
• Usando ntfsclone y dd para clonado por red con netcat (2)
• Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (2)

Feed enhanced by Better Feed from Ozh

Esconder un usuario de la pantalla inicial de selección de usuario

Cuando usamos Windows XP, Vista, 7, etc. con la configuración doméstica de por defecto (en la que sale una imagen para cada usuario y no en la que hay que escribir a mano el nombre del usuario), podemos querer ocultar alguno de los usuarios de dicha pantalla. Eso me pasó a mí recientemente tras instalar el servicio sshd de Cygwin en un Windows 7 (Servicios en Cygwin (syslogd, sshd, telnetd, ftpd, nfsd, etc.)): pasé de tener en la pantalla de inicio sólo el usuario habitual de Windows a tener también el usuario cyg_server (que aparece como Privileged User). Pude esconderlo con facilidad abriendo el regedit, yendo a:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon

y añadiendo una clave “SpecialAccounts” y dentro de ella otra llamada “UserList”. A continuación, dentro de:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\SpecialAccounts\UserList

creamos una entrada de tipo DWORD cuyo nombre sea el nombre del usuario que queremos esconder (en mi caso cyg_server) y con valor cero (0). Tras un reinicio, el usuario que no queremos ver deja de estar disponible.

• Hide User Accounts on Windows 7 Logon
• Hide user account from welcome screen in windows 7

Utilidad para configuración avanzada de usuarios

En Windows XP y Windows Vista, la utilidad estándar para configurar usuarios que encontramos en el Panel del Control es muy “doméstica” y le faltan muchas opciones. La utilidad típica de configurar usuarios que venía con Windows 2000 seguía estando en sus sucesores XP y Vista pero había que lanzarla a mano con el comando:

control userpasswords2

En Windows 7, la utilidad de gestión de usuarios estándar sigue siendo “doméstica” y la utilidad “alternativa” sigue estando disponible, aunque ahora hay que lanzarla con el comando:

netplwiz

Un dato importante es que desde esta utilidad no podremos lanzar la utilidad de gestión avanzada de usuarios y grupos locales en las versiones Home de Windows 7, sólo en las Professional, Ultimate y Enterpise.

• How to turn on automatic logon in Windows XP
• Configure a User Account to Log On Automatically on Windows 7
• How to Open “Local Users and Groups” in Windows 7

Extraer los ficheros de un .msi

¿Te ha pasado alguna vez tener un fichero .msi de Windows Installer y necesitar extraer algún fichero de dentro pero sin querer instalar la aplicación? Sólo tienes que ejecutar este comando:

msiexec /a PathToMSIFile /qb TARGETDIR=DirectoryToExtractTo

Por ejemplo:

msiexec /a 7z920-x64.msi /qb TARGETDIR=c:\Temp\7z

El directorio destino se creará si no existe.

• Howto: extract files from a .msi file using the Windows command line

Obtener el BSSID y otros detalles adicionales de las redes WiFi al alcance

¿Necesitas saber más detalles sobre las redes WiFi que tienes a tu alcance y no tienes ninguna herramienta adicional, sólo las que trae Windows por defecto? En Windows Vista, 2008 y 7, ¡netsh te puede ayudar! (netsh está disponible en versiones anteriores, pero sólo en éstas lleva funciones de WiFi).

C:\Users\Usuario\Desktop>netsh
netsh>wlan
netsh wlan>show networks mode=Bssid

Interface name : Wireless Network Connection
There are 2 networks currently visible.

SSID 1 : Jazztel_A6
    Network type            : Infrastructure
    Authentication          : WPA-Personal
    Encryption              : CCMP
    BSSID 1                 : c4:75:0f:2b:b6:25
         Signal             : 52%
         Radio type         : 802.11g
         Channel            : 1
         Basic rates (Mbps) : 1 2 5.5 6 9 11 12 18 24 36 48 54

SSID 2 : WLAN_99
    Network type            : Infrastructure
    Authentication          : Open
    Encryption              : WEP
    BSSID 1                 : 01:21:c8:fe:6f:df
         Signal             : 63%
         Radio type         : 802.11g
         Channel            : 9
         Basic rates (Mbps) : 1 2 5.5 11
         Other rates (Mbps) : 6 9 12 18 24 36 48 54

• Netsh Command Reference

Barra de inicio rápido (Quick Launch) en Windows 7

Aquellos de vosotros que, como yo, seáis unos reaccionarios de las nuevas interfaces de usuario (Windows 7, KDE 4, Gnome 3, Unity) seguro que renegaréis de la nueva barra de tareas de Windows 7 y tal vez tratéis de configurarla de la forma más parecida posible a lo que solía ser en versiones anteriores. En tal caso, seguro que os vendrá bien saber cómo volver a añadir la barra de inicio rápido.

Sólo hay que hacer clic con el botón derecho sobre la barra de tareas, ir a “Barras de herramientas”, elegir “Nueva barra de herramientas” y cuando nos pida la localización de ésta, escribir:

%userprofile%\appdata\roaming\microsoft\internet Explorer\Quick Launch

A continuación, haremos clic con el botón derecho sobre la nueva barra y quitaremos las opciones “Mostrar texto” y “Mostrar título” para tener una barra de inicio rápido como siempre.

• Cómo usar el inicio rápido en Windows 7

Extender o reducir una partición NTFS de Windows

Imaginemos la siguiente situación bastante típica: Tienes un PC con Windows instalado en una única partición que ocupa todo el disco en el que queremos instalar, por ejemplo, alguna distribución de Linux. ¿Qué haríamos? Pues podríamos arrancar con cualquier LiveCD de alguna distribución de Linux que contenga el GParted (también tiene su propio LiveCD) y usarlo para hacer la partición de Windows más pequeña. Pero ahora, con Windows 7, también podemos usar el propio gestor de discos de Windows para hacerlo muy fácilmente. Lo lanzamos ejecutando:

diskmgmt.msc

Y aquí, haciendo clic con el botón derecho sobre cualquier partición, encontraremos opciones para reducir y ensanchar el tamaño de las particiones (siempre que estas operaciones sean posibles).

• Extend a Basic Volume
• Shrink a Basic Volume

:wq!

Lo hice y lo entendí © Vicente Navarro 2011 con una licencia CC BY-SA | 2 comentarios
Etiquetas: Cygwin, NTFS, particiones, Windows

Entradas relacionadas

• Usando ntfsclone y dd para clonado por red con netcat (2)
• Trabajando con Cygwin (2)
• Servicios en Cygwin (syslogd, sshd, telnetd, ftpd, nfsd, etc.) (2)
• Recuperación de particiones perdidas con gpart (2)
• rdiffdir: Sincronizando directorios entre sistemas distintos sin usar la red (2)
• Instalar un Cygwin portable en una memoria USB (2)

Feed enhanced by Better Feed from Ozh

Pero esta configuración genera problemas con el reenvio de ventanas X11 a través de SSH. Por ejemplo, con sistemas HP-UX y Solaris (luego veremos qué pasa con Linux), cuando accedes por SSH con un usuario reenviando las ventanas X11 y luego haces un su, perdemos el túnel de X11:

$ ssh -X usuarioprueba@solx86
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
$
$ echo $DISPLAY
localhost:10.0
$
$ /usr/openwin/bin/xclock
$
$ su -
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
#
# echo $DISPLAY
#
# /usr/openwin/bin/xclock
Error: Can't open display:

Si ponemos a mano la variable $DISPLAY, el error pasará de ser que no puede acceder al display a que no tiene autorización para usar el display:

# DISPLAY=localhost:10.0
# export DISPLAY
# 
#  /usr/openwin/bin/xclock
X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).

Una solución, aprovechando que root puede acceder a los ficheros de todos los usuarios, es modificar la variable $XAUTHORITY para usar el fichero .Xauthority del usuario con el que entramos y no el de root:

# XAUTHORITY=/export/home/usuarioprueba/.Xauthority
# export XAUTHORITY
#
# /usr/openwin/bin/xclock

Al entrar a un sistema por SSH con la opción de reenvío de X11 activada, el servidor SSH añade una MIT-MAGIC-COOKIE-1 al fichero $HOME/.Xauthority para que sólo ese usuario (y no otros que estén conectados a la máquina e intenten usar el mismo $DISPLAY) pueda usar su túnel SSH para reenviar ventanas X11. Si el usuario root usa la misma magic cookie, pues podrá entrar sin problemas.

Otra opción para no reemplazar por completo el .Xauthority de root pasa por listar las magic cookies disponibles en el .Xauthority del usuario:

$ /usr/openwin/bin/xauth list
clientessh:0  MIT-MAGIC-COOKIE-1  e712f99f148d5bf00e5df9f345635434
sistemavncserver:1  MIT-MAGIC-COOKIE-1  d30c3ab6ca017837260ff6221fd80da7
solx86/unix:10  MIT-MAGIC-COOKIE-1  1d9076a2068a5e79d1259bea382cec2d

extraemos en formato binario sólo la entrada que nos interesa:

$  /usr/openwin/bin/xauth extract .Xauthority_solx86 solx86/unix:10

y ya como root, unimos la entrada a las existentes y ya podremos acceder al servidor X:

$ su -
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
# DISPLAY=localhost:10.0
# export DISPLAY
#
# /usr/openwin/bin/xauth merge /export/home/prueba/.Xauthority_solx86
#
# /usr/openwin/bin/xauth list
solx86/unix:10  MIT-MAGIC-COOKIE-1  1d9076a2068a5e79d1259bea382cec2d
#
# /usr/openwin/bin/xclock

Y otra opción más sería, tras listar las entradas existentes, simplemente añadir la magic cookie a mano en el .Xauthority de root:

# /usr/openwin/bin/xauth add solx86/unix:10  MIT-MAGIC-COOKIE-1  1d9076a2068a5e79d1259bea382cec2d
#
# /usr/openwin/bin/xclock

Decíamos que en Linux no tenemos este problema. Al pasarnos a root, la variable $DISPLAY se conserva y no necesitamos añadir la magic cookie para que el reenvío de ventanas X11, simplemente, siga funcionando:

# ssh -X usuariopruebap@rh5x64
usuariopruebap@rh5x64's password:
$
$ xclock
$
$ echo $DISPLAY
localhost:10.0
$
$ su -
Password:
[root@rh5x64 ~]# echo $DISPLAY
localhost:10.0

Esta magia de los sistemas Linux la proporciona el módulo PAM pam_xauth:

The pam_xauth PAM module is designed to forward xauth keys (sometimes referred to as “cookies”) between users.

Without pam_xauth, when xauth is enabled and a user uses the su(1) command to assume another user’s privileges, that user is no longer able to access the original user’s X display because the new user does not have the key needed to access the display. pam_xauth solves the problem by forwarding the key from the user running su (the source user) to the user whose identity the source user is assuming (the target user) when the session is created, and destroying the key when the session is torn down.

Así, en el fichero /etc/pam.d/su, típicamente encontraremos una línea como ésta:

session         optional        pam_xauth.so

El módulo guarda las magic cookies necesarias en diferentes ficheros $HOME/.xauth??????:

# xauth -f .xauthrBGj8r list
rh5x64/unix:10  MIT-MAGIC-COOKIE-1  aaceeca9bf499b5c85aba64a3ae42bd0

que, aunque normalmente se eliminan solos al salir, en ocasiones se quedan ahí abandonados. Por ello, en Google podemos encontrar bastantes casos de gente preguntando qué son dichos ficheros .xauthXXXXX y por qué tienen muchos.

Y para finalizar, una mención al Remote X Apps mini-HOWTO, en el que podremos repasar los conceptos básicos sobre cómo ejecutar aplicaciones X11 de un sistema en el servidor X de otro sistema UNIX/Linux.

:wq

Lo hice y lo entendí © Vicente Navarro 2011 con una licencia CC BY-SA | 8 comentarios
Etiquetas: GNU/Linux, HP-UX, OpenSSH, Solaris, SSH, UNIX, X Window System

Entradas relacionadas

• VPN con OpenSSH (3)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (3)
• Memoria swap en un fichero. ¿Cuánta memoria swap necesitamos? (3)
• Evitando problemas con la “host key” en sesiones no interactivas de OpenSSH (3)
• Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (3)
• Autentificación trasparente por clave pública/privada con OpenSSH (3)

Feed enhanced by Better Feed from Ozh

Por ejemplo, cualquiera que tenga un sistema con un servidor SSH expuesto a Internet sabrá que no es nada infrecuente encontrar registrados diferentes intentos de intrusión en el sistema (en el /var/log/auth.log en un sistema Debian):

Oct 19 09:31:49 darkstar sshd[13481]: Invalid user fluffy from 202.102.XX.XX
Oct 19 09:32:02 darkstar sshd[13493]: Invalid user oracle from 202.102.XX.XX
Oct 19 09:32:08 darkstar sshd[13500]: Invalid user www from 202.102.XX.XX
Oct 19 09:32:17 darkstar sshd[13508]: Invalid user postmaster from 202.102.XX.XX
Oct 19 09:32:31 darkstar sshd[13520]: Invalid user file from 202.102.XX.XX

Si el servidor de SSH sólo permite autentificación por clave privada/pública (Autentificación trasparente por clave pública/privada con OpenSSH) podemos estar razonablemente tranquilos de que el intento de intrusión no tendrá éxito. Pero como nunca se puede estar seguro del todo, puede ser buena idea añadir, adicionalmente, un sistema de port knocking para abrir el puerto SSH sólo cuando realmente lo vayamos a usar.

En un sistema basado en Debian, esto se puede hacer muy fácilmente con el demonio knockd, uno de los paquetes oficiales de la distribución. Tras instalar el paquete, tenemos que editar el fichero /etc/default/knockd para permitir que el demonio arranque:

# PLEASE EDIT /etc/knockd.conf BEFORE ENABLING
START_KNOCKD=1

y especificarle cualquier opción que queramos usar, especialmente en qué interfaz tiene que escuchar si no es el "eth0":

# command line options
# KNOCKD_OPTS="-i eth1"

Hay que tener en cuenta que el knockd siempre ve los paquetes llegar, incluso si los puertos están cerrados y si alguna regla de iptables rechaza el paquete. Podríamos decir que se comporta como el tcpdump, en el sentido de que el interfaz se pone en modo promiscuo y ve todo lo que llega a él. Pero adicionalmente, según qué paquetes vea, ejecuta una acción. Por cierto, parece que no funciona poner dos interfaces con "-i eth0 -i eth1".

A continuación, tenemos que personalizar el fichero /etc/knockd.conf para especificar qué secuencia de puertos queremos y qué hacer cuando ésta llegue. En el “man knockd” encontramos interesantes ejemplos de uso, pero podemos centrarnos en el más típico que es el que instala Debian por defecto:

[openSSH]
        sequence    = 7000,8000,9000
        seq_timeout = 5
        command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags    = syn

[closeSSH]
        sequence    = 9000,8000,7000
        seq_timeout = 5
        command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags    = syn

Vemos que cuando llega una secuencia de paquetes TCP con el flag de SYN a los puertos 7000, 8000 y 9000 en menos de 5 segundos, el demonio knockd añade una regla de iptables para permitir el acceso al servicio SSH a la IP que ha hecho el port knocking. Y con otra secuencia, podemos cerrar el puerto posteriormente.

Tras configurar el /etc/knockd.conf a nuestro gusto, arrancamos el knockd con “/etc/init.d/knockd start“.

Para mandar la secuencia que active la acción podemos usar, desde otro sistema, el comando knock, que se instala también al instalar el paquete knockd:

[root@clientessh ~]# knock 192.168.100.2 7000 8000 9000

y en el sistema en el que hemos arrancado el knockd vemos cómo los paquetes llegan y se ejecuta la acción planificada para dicha secuencia:

Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: Stage 1
Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: Stage 2
Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: Stage 3
Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: OPEN SESAME
Oct 19 21:55:17 darkstar knockd: openSSH: running command: /sbin/iptables -A INPUT -s 192.168.100.1    -p tcp --dport 22 -j ACCEPT

El hecho de que podamos ejecutar cualquier comando nos da total flexibilidad. Por ejemplo, se me ocurre que en vez de, o adicionalmente a añadir o quitar reglas de iptables, también podríamos incluso arrancar o parar el demonio sshd:

[openSSH]
        sequence    = 7000,8000,9000
        seq_timeout = 5
        command     = /etc/init.d/ssh start
        tcpflags    = syn

[closeSSH]
        sequence    = 9000,8000,7000
        seq_timeout = 5
        command     = /etc/init.d/ssh stop
        tcpflags    = syn

Lo que nos quedaría por ver es qué alternativas tenemos para mandar la secuencia de puertos. Hemos visto que el propio paquete knockd de Debian lleva el comando knock. Pero, ¿hay alternativas? ¿y si queremos hacer port knocking desde Windows? ¿y si queremos hacerlo desde un sistema que no tenga ningún software especial?

La propia página de man de knockd nos sugiere algunas alternativas:

knock is the accompanying port-knock client, though telnet or netcat could be used for simple TCP knocks instead. For more advanced knocks, see hping, sendip or packit.

Una posibilidad para Windows también es el KnockKnock, descubierto gracias a “Add Port Knocking to SSH for Extra Security“:

pero un inconveniente del KnockKnock es que lanza la secuencia más de una vez:

Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 1
Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 2
Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 3
Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 4
Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: OPEN SESAME
Oct 19 22:38:32 darkstar knockd: Prueba: running command: /sbin/iptables -A INPUT -s 192.168.100.1    -p tcp --dport 22 -j ACCEPT
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 1
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 2
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 3
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 4
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: OPEN SESAME
Oct 19 22:38:33 darkstar knockd: Prueba: running command: /sbin/iptables -A INPUT -s 192.168.100.1    -p tcp --dport 22 -j ACCEPT
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 1
Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: Stage 2
Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: Stage 3
Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: Stage 4
Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: OPEN SESAME
Oct 19 22:38:34 darkstar knockd: Prueba: running command: /sbin/iptables -A INPUT -s 192.168.100.1    -p tcp --dport 22 -j ACCEPT

Si el comando a ejecutar se puede ejecutar más de una vez sin otros efectos, como es el caso del iptables, nos da igual, pero en otros casos, puede ser un problema.

Otra solución es usar el cliente de telnet de Windows contra los diferentes puertos para activar la secuencia. Para ello, en Windows se puede usar un .bat con este aspecto:

start telnet 192.168.100.2 7000
start telnet 192.168.100.2 8000
start telnet 192.168.100.2 9000

El resultado no siempre es el deseado. El telnet de Windows envía varios paquetes SYN cuando falla el primero y parece que el knockd no siempre acepta la secuencia. Pero bueno, normalmente antes de 4 o 5 intentos, ya ha funcionado la secuencia.

Por supuesto, el knockd es un punto de fallo adicional en el acceso al sistema. Si le pasa algo a este demonio, nos quedaremos sin poder acceder.

Actualización 21/10/11: Como comentan Dany y SebaMinguez en los comentarios, también podemos configurar port knocking sólo con reglas iptables: Multiple-port knocking Netfilter/IPtables only implementation.

:wq

Lo hice y lo entendí © Vicente Navarro 2011 con una licencia CC BY-SA | 12 comentarios
Etiquetas: Debian, GNU/Linux, OpenSSH, Redes, Windows

Entradas relacionadas

• Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (5)
• VPN con OpenSSH (4)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (4)
• Accediendo a una red mediante NAT en Linux (4)
• Usando ntfsclone y dd para clonado por red con netcat (3)
• Hosting casero HOWTO (3)

Feed enhanced by Better Feed from Ozh

• Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH
• VPN con OpenSSH

Cuando digo “métodos no estándar”, me refiero a que normalmente la conectividad entre redes en una intranet o en Internet se consigue con las rutas definidas en los routers de la red. Los routers saben (o deberían saber) cómo llegar de un nodo en la red A a otro nodo en la red B.

Ahora supongamos que estamos en una gran intranet corporativa con muchas subredes. Supongamos también que tenemos un sistema con Linux con dos interfaces Ethernet. Uno de ellos conectado a la red “oficial” y el otro conectado a un switch al que conectamos varios servidores (Linux, Windows, etc.). Necesitamos que dichos servidores puedan llegar a nodos de la intranet “oficial” y necesitamos acceder a ciertos servicios de los servidores desde la intranet. De momento, esos servidores estarán en una “red oculta” o “inalcanzable” para el resto de nodos de la intranet.

El “método estándar” sería que el administrador de la intranet definiera en los routers de la intranet una ruta para que todos los nodos de la red supieran llegar. Pero si eso no es posible o conveniente (lo contrario implicaría mucha burocracia, va a ser una situación temporal, así proporcionamos más seguridad a la red oculta), es cuando tenemos que usar “metodos no estándar”.

Las soluciones usando OpenSSH descritas en entradas anteriores nos resolvían esta situación perfectamente. Pero, ¡ay! Resulta que OpenSSH introduce una sobrecarga importante: Los nodos que mantienen la conexión SSH estarán permanentemente cifrando toda la comunicación, usarán más CPU y la conexión será menos ligera y fluida.

La alternativa, en la que usamos únicamente técnicas estándar del protocolo IP, sería usar NAT. La idea sería que el sistema Linux se comportara como un router ADSL o de cable como los que solemos tener en casa, que hacen NAT y que nos permiten abrir sólo unos pocos puertos para acceder a ciertos servicios de la red interna.

Así, consideremos el siguiente diagrama en el que vemos que el Linux tiene la IP 10.25.25.2 (eth0) en la intranet “oficial” y la IP 172.16.20.2 (eth1) en la red interna “oculta”:

(...)

Leer el resto de Accediendo a una red mediante NAT en Linux (976 palabras)

Lo hice y lo entendí © Vicente Navarro 2011 con una licencia CC BY-SA | 2 comentarios
Etiquetas: GNU/Linux, iptables, NAT, OpenSSH, Redes, Windows

Entradas relacionadas

• VPN con OpenSSH (4)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (4)
• Port Knocking (4)
• Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (4)
• Usando ntfsclone y dd para clonado por red con netcat (3)
• Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (3)

Feed enhanced by Better Feed from Ozh