miércoles, 30 de septiembre de 2015

¿MBR o GPT? deep dive

Un poco la idea de este post es forzarme a repasar algunos conceptos e interiorizarme en algunos nuevos :P, así que posiblemente lo encuentren aburrido o tedioso.

Tanto MBR como GPT son distintas maneras de administrar las particiones en nuestros discos rígidos. Por lo general todos los mortales nos enfrentamos eventualmente con al menos 2 particiones en nuestros discos (algunos un poco mas experimentados con algunas mas), una para el sistema y todos sus archivos y otra para swap en el caso de entornos Unix like. Básicamente MBR y GPT, cada uno a su manera, se encargan de proveer la información para que podamos identificar donde comienzan y terminan las particiones, entre otra cosas.

Un poco de MBR


La MBR o Master Boot Record (también conocida como tabla de particiones msdos) se encuentra almacenada en el primer sector disponible del disco o LBA0 a partir de ahora. La MBR consiste de 512 bytes y está conformada mas o menos de la siguiente manera:
  • Los primeros 446 bytes están ocupados en buena parte por código binario ejecutable, el bootloader en esencia, por ejemplo la primera etapa de grub. Este código es cargado en memoria por la BIOS y luego ejecutado.
  • A continuación se encuentran las 4 entradas de 16 bytes que describen las particiones.
    • El primer byte describe el estado de la partición, por ejemplo si es bootable o no.
    • Los siguientes 3 bytes describen la dirección CHS del primer sector de la partición.
    • El siguiente byte describe el tipo de partición: hay varios tipos, mas de los que puedo recordar, pero en esencia aquí se define si se trata de una partición primaria o extendida.
    • 3 bytes mas que describen el último sector de la partición en formato CHS.
    • 4 bytes que describen el primer sector de la partición en formato LBA
    • 4 bytes que describen la cantidad de sectores que tiene la partición.
En este link de wikipedia pueden verlo con más detalle. Pasemos a ver un caso particular utilizando parted para analizar el disco de mi laptop:

juan@moon:~/Escritorio/POSTS/mbr_gpt$ sudo parted
GNU Parted 2.3
Usando /dev/sda
¡Bienvenido/a a GNU Parted! Teclee «help» para ver la lista de órdenes.
(parted) unit s                                                          
(parted) print                                                          
Modelo: ATA TOSHIBA MK2555GS (scsi)
Disco /dev/sda: 488397168s
Tamaño de sector (lógico/físico): 512B/512B
Tabla de particiones. msdos

Numero  Inicio      Fin         Tamaño      Tipo     Sistema de archivos  Banderas
 1      63s         413636607s  413636545s  primary  ext4
 2      413636608s  475985919s  62349312s   primary  ext4                 arranque
 3      475985920s  488396799s  12410880s   primary  linux-swap(v1)


(parted)  


como pueden ver el disco consta de 488397168 sectores de 512 Bytes (250 Gbytes). Tiene una tabla de particiones tipo msdos (básicamente MBR) con 3 particiones (todas primarias):
  • La primera partición comienza en el sector 63 (LBA63) y termina en el sector 413636607, es decir que consta de 413636545 sectores (aprox 195 GBytes es la partición /home)
  • La segunda partición que comienza en el sector siguiente y se encuentra marcada como de arranque (bootable) tiene 62349312 sectores (aprox 30GBytes es la partición /, donde se encuentra el directorio /boot)
  • La tercera partición, tiene 12410880 sectores (aprox 6GBytes y es la swap)
Hay una columna que indica el Sistema de archivos de la partición, esto NO está dentro de la información provista por la MBR, es información adicional agregada por parted en este caso.

Podemos ir un poco mas lejos y analizar directamente el primer sector del disco /dev/sda con un lector hexadecimal de la siguiente forma:

juan@moon:~/Escritorio/POSTS/mbr_gpt$ sudo dd if=/dev/sda bs=512 count=1 2>/dev/null | hexdump -C
00000000  eb 63 90 d0 bc 00 7c 8e  c0 8e d8 be 00 7c bf 00  |.c....|......|..|
00000010  06 b9 00 02 fc f3 a4 50  68 1c 06 cb fb b9 04 00  |.......Ph.......|
00000020  bd be 07 80 7e 00 00 7c  0b 0f 85 0e 01 83 c5 10  |....~..|........|
00000030  e2 f1 cd 18 88 56 00 55  c6 46 11 05 c6 46 10 00  |.....V.U.F...F..|
00000040  b4 41 bb aa 55 cd 13 5d  72 0f 81 fb 55 aa 75 09  |.A..U..]r...U.u.|
00000050  f7 c1 01 00 74 03 fe 46  10 66 00 80 01 00 00 00  |....t..F.f......|
00000060  00 00 00 00 ff fa 90 90  f6 c2 80 74 05 f6 c2 70  |...........t...p|
00000070  74 02 b2 80 ea 79 7c 00  00 31 c0 8e d8 8e d0 bc  |t....y|..1......|
00000080  00 20 fb a0 64 7c 3c ff  74 02 88 c2 52 bb 17 04  |. ..d|<.t...R...|
00000090  f6 07 03 74 06 be 88 7d  e8 17 01 be 05 7c b4 41  |...t...}.....|.A|
000000a0  bb aa 55 cd 13 5a 52 72  3d 81 fb 55 aa 75 37 83  |..U..ZRr=..U.u7.|
000000b0  e1 01 74 32 31 c0 89 44  04 40 88 44 ff 89 44 02  |..t21..D.@.D..D.|
000000c0  c7 04 10 00 66 8b 1e 5c  7c 66 89 5c 08 66 8b 1e  |....f..\|f.\.f..|
000000d0  60 7c 66 89 5c 0c c7 44  06 00 70 b4 42 cd 13 72  |`|f.\..D..p.B..r|
000000e0  05 bb 00 70 eb 76 b4 08  cd 13 73 0d 5a 84 d2 0f  |...p.v....s.Z...|
000000f0  83 d0 00 be 93 7d e9 82  00 66 0f b6 c6 88 64 ff  |.....}...f....d.|
00000100  40 66 89 44 04 0f b6 d1  c1 e2 02 88 e8 88 f4 40  |@f.D...........@|
00000110  89 44 08 0f b6 c2 c0 e8  02 66 89 04 66 a1 60 7c  |.D.......f..f.`||
00000120  66 09 c0 75 4e 66 a1 5c  7c 66 31 d2 66 f7 34 88  |f..uNf.\|f1.f.4.|
00000130  d1 31 d2 66 f7 74 04 3b  44 08 7d 37 fe c1 88 c5  |.1.f.t.;D.}7....|
00000140  30 c0 c1 e8 02 08 c1 88  d0 5a 88 c6 bb 00 70 8e  |0........Z....p.|
00000150  c3 31 db b8 01 02 cd 13  72 1e 8c c3 60 1e b9 00  |.1......r...`...|
00000160  01 8e db 31 f6 bf 00 80  8e c6 fc f3 a5 1f 61 ff  |...1..........a.|
00000170  26 5a 7c be 8e 7d eb 03  be 9d 7d e8 34 00 be a2  |&Z|..}....}.4...|
00000180  7d e8 2e 00 cd 18 eb fe  47 52 55 42 20 00 47 65  |}.......GRUB .Ge|
00000190  6f 6d 00 48 61 72 64 20  44 69 73 6b 00 52 65 61  |om.Hard Disk.Rea|
000001a0  64 00 20 45 72 72 6f 72  0d 0a 00 bb 01 00 b4 0e  |d. Error........|
000001b0  cd 10 ac 3c 00 75 f4 c3  87 1f b2 ba 00 00 00 01  |...<.u..........|
000001c0  01 00 83 fe ff ff 3f 00  00 00 c1 97 a7 18 80 fe  |......?.........|
000001d0  ff ff 83 fe ff ff 00 98  a7 18 00 60 b7 03 00 fe  |...........`....|
000001e0  ff ff 82 fe ff ff 00 f8  5e 1c 00 60 bd 00 00 00  |........^..`....|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200
juan@moon:~/Escritorio/POSTS/mbr_gpt$ 


Utilizando dd capturé el primer bloque del disco y lo procesé con un lector hexadecimal, como para humanizar un poco las cosas. La tabla de particiones en si misma comienza a partir del byte 01BEh

Partición 1: los bytes 3f 00 00 00 representan el primer bloque de la partición 63 (la representación es en little endian) y los bytes c1 97 a7 18 representan la cantidad de sectores asociados, en este caso 413636545 sectores.
Partición 2: El primer byte es 80 lo cual indica que se trata de la partición booteable. Los bytes 00 98 a7 18 indican que el bloque inicial de la partición es 413636608, y los bytes 00 60 b7 03 representan la cantidad de bloques 62349312.
Partición 3: los bytes 00 f8 5e 1c representan el sector inicial 475985920, y los bytes 00 60 bd 00 representan la cantidad de sectores 12410880. Los siguientes 16 bytes conformar la descripción de la cuarta partición que no existe en este caso y por eso son 0.
Boot Signature: se trata de dos bytes que siempre tienen el valor 55 aa y delimitan el fin de la MBR.

De acuerdo a wikipedia, la parte remarcada con negrita se trata de código ejecutable del bootloader, en nuestro caso GRUB. Esto le da a GRUB un total de poco mas de 400 bytes de espacio para código. Sin embargo como ven, la primer partición no comienza sino hasta el sector 63! Esto permite que booloaders como GRUB puedan disponer de unos miles de bytes extras (entre los sectores 1 y 62, 62*512 Bytes para ser mas preciso) para poder realizar su tarea. Después de todo es Grub quien tiene que cargar en memoria la imagen del kernel y darle inicio a la vida, y para esto precisa al menos saber como acceder a la partición donde se encuentran los archivos.

Limitaciones de MBR


Dado que MBR fue introducido como estándar hace mas de 30 años es lógico que presente limitaciones en su diseño. Las mas notables son:
  • La capacidad máxima de 2TB, en discos con sectores de 512 Bytes. Esto se debe a que el campo que indica la cantidad de sectores que ocupa la partición está expresado como un entero de 4 bytes (32 bits, 512 Bytes ^ 32 = 2TB).
  • La especificación básica de MBR reservó espacio para solo 4 particiones. Esto luego lo enmendaron agregando el concepto de partición "extendida", dentro de la cual es posible crear mas particiones.
Discos cada vez mas grandes, sectores cada vez mas grandes, nuevos sistemas operativos, etc son algunos de los motivos por los que MBR, con ya varias décadas en el mercado, está siendo reemplazado por GPT.

Un poco de GPT


GUID Partition Table desarrollado por los muchachos de Intel, forma parte de las especificaciones UEFI y presenta una manera bastante diferente de administrar las particiones en nuestros discos. Por ejemplo:
  • Se descartó completamente el direccionamiento CHS a favor de LBA. 
  • En lugar de utilizar 4 bytes (32 bits) para definir los sectores de una partición utiliza 8 bytes (64 bits), lo cual da una capacidad máxima de 512^64 Bytes 9.4 ZB.
  • El encabezado GPT se encuentra en en el sector LBA 1 (SIEMPRE), entre otras cosas contiene un puntero a la tabla de particiones (usualmente ubicada en LBA 2, también llamado arreglo de particiones).
  • En LBA0 se encuentra la llamada Protective MBR, cuyos fines son:
    • Evitar que software que no soporte GPT destruya la partición.
    • Hace posible bootear desde BIOS una partición GPT. Aquí tanto el bootloader como el OS deben soportar GPT.
  • El último sector del disco contiene una copia del header GPT, a modo de backup.
  • El estándar dedica 16384 bytes a la tabla de particiones, y dado que cada entrada ocupa 128 bytes es posible un máximo de 128 particiones.
    • En discos de 512 Bytes por sector el primer sector utilizable es LBA 34 (16384/512=32 bloques y dado que la tabla comienza en LBA2).
    • Si el disco tuviese sectores de 4096 bytes, el primer sector disponible sería el 5 (LBA0=MBR, LBA1=GPT header). 
  • Existen dos campos para control de integridad (CRC) en el header GPT, uno para controlar la integridad del header mismo y otro que controla la integridad del arreglo de particiones.
A modo de ejemplo a continuación utilizando parted se create una tabla de particiones GPT sobre un disco y una partición:

root@moon:/home/juan/Escritorio/POSTS/mbr_gpt# parted /dev/loop1
GNU Parted 2.3
Usando /dev/loop1
¡Bienvenido/a a GNU Parted! Teclee «help» para ver la lista de órdenes.
(parted) unit s                                                          
(parted) mklabel gpt                                                     
Aviso: La etiqueta de disco existente en /dev/loop1 se destruirá y todos los datos en este disco se perderán. ¿Desea continuar?
Sí/Yes/No? Yes                                                           
(parted) print                                                           
Modelo: Loopback device (loop)
Disco /dev/loop1: 4096000s
Tamaño de sector (lógico/físico): 512B/512B
Tabla de particiones. gpt

Numero  Inicio  Fin  Tamaño  Sistema de archivos  Nombre  Banderas

(parted) mkpart                                                       
¿Nombre de la partición?  []? Juan                                           
¿Tipo de sistema de ficheros?  [ext2]? ext4                              
¿Inicio? 2048                                                            
¿Fin? 4095999                                                            
Aviso: Usted solicitó una partición de 2048s a 4095999s.                 
La ubicación más cercana que podemos aceptar es 2048s a 4095966s.
¿Es aceptable para usted?
Sí/Yes/No? Yes                                                           
(parted) print                                                           
Modelo: Loopback device (loop)
Disco /dev/loop1: 4096000s
Tamaño de sector (lógico/físico): 512B/512B
Tabla de particiones. gpt

Numero  Inicio  Fin       Tamaño    Sistema de archivos  Nombre  Banderas
 1      2048s   4095966s  4093919s        Juan

(parted)
  quit

Ahora... de manera similar a como analizamos MBR analizamos el header GPT:

root@moon:/home/juan/Escritorio/POSTS/mbr_gpt# dd if=/dev/loop1 bs=512 count=2 2>/dev/null | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  01 00 ee fe ff ff 01 00  00 00 ff 7f 3e 00 00 00  |............>...|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  46 f7 9d ba 00 00 00 00  01 00 00 00 00 00 00 00  |F...............|
00000220  ff 7f 3e 00 00 00 00 00  22 00 00 00 00 00 00 00  |..>.....".......|
00000230  de 7f 3e 00 00 00 00 00  7a 46 44 50 5f 5b 30 43  |..>.....zFDP_[0C|
00000240  b9 2d 37 23 2b 58 93 c6  02 00 00 00 00 00 00 00  |.-7#+X..........|
00000250  80 00 00 00 80 00 00 00  0d b2 ff f0 00 00 00 00  |................|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400 
root@moon:/home/juan/Escritorio/POSTS/mbr_gpt#


Dado que el header GPT se encuentra localizado en LBA1, con dd extraje los dos primeros bloques del disco. A continuación la explicación de los campos:

Firma del GPT header: son los primeros 8 bytes de LBA1.
GPT revision: es la versión de GPT utilizada (4 bytes), en este caso es 1.0 
Tamaño del header en bytes:  el valor es de 92 bytes en este caso (4 bytes).
CRC del header: 4 bytes.
Reservados: 4 bytes en cero.
LBA del GPT header: en este caso es LBA1 (8bytes).
LBA de la copia del GPT header: en este caso es el sector LBA4095999 (último sector del disco) (8bytes)
Primer sector LBA disponible para particiones:  22h=2+16*2=34, LBA34 (8 bytes).
Último sector LBA disponible para particiones: en este caso LBA 4095966, noten como entre estos últimos valores hay 34 sectores disponibles... aquí se almacena una copia completa del arreglo de particiones.
Identificador GUID del disco: no muy útil, a no confundir con el UUID de la partición.
Sector donde comienza el arreglo de particiones: siempre es dos en la copia primaria del GPT header.
Número de particiones en el arreglo: en nuestro caso es 128 (80h).
Tamaño de cada entrada en el arreglo de particiones: 128 bytes.
CRC de la tabla del arreglo de particiones 
Los siguientes bytes (420 bytes o mas) del sector se dejan en 0 dado que están reservados para futuras ampliaciones.

Como dije antes, GPT está dividido en un header y en un arreglo de particiones. Ahora toca analizar el arreglo de particiones, que se encuentra en el LBA2

root@moon:/home/juan/Escritorio/POSTS/mbr_gpt# dd if=/dev/loop1 bs=512 skip=2 count=1 2>/dev/null | hexdump -C
00000000  af 3d c6 0f 83 84 72 47  8e 79 3d 69 d8 47 7d e4  |.=....rG.y=i.G}.|
00000010  ae 46 0e 3a 05 b0 6b 46  9c 5c 5d 38 4d 90 23 43  |.F.:..kF.\]8M.#C|
00000020  00 08 00 00 00 00 00 00  de 7f 3e 00 00 00 00 00  |..........>.....|
00000030  00 00 00 00 00 00 00 00  4a 00 75 00 61 00 6e 00  |........J.u.a.n.|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
root@moon:/home/juan/Escritorio/POSTS/mbr_gpt# 


con dd extraemos solamente el tercer sector del disco LBA2 (notese que saltee 2 sectores con skip). A continuación una brevísima explicación de los campos de la primer entrada en el arreglo de particiones (la única en este caso)

GUID del tipo de partición:
GUID de la partición: (no confundir con el UUID)
Primer LBA de la partición: 0800h=2048.
Último LBA de la partición: 3e7fdeh=4095966
Atributos extras
Nombre de la partición: Juan (72 bytes)

Si hacemos los números 72+8+8+8+16+16=128, cada entrada en la tabla de particiones tiene 128 bytes.

Por último comprobamos porque parted nos prohibió utilizar los sectores entre 4095966 y 4095999:

root@moon:/home/juan/Escritorio/POSTS/mbr_gpt# dd if=/dev/loop1 bs=512 skip=4095967 count=1 2>/dev/null | hexdump -C
00000000  af 3d c6 0f 83 84 72 47  8e 79 3d 69 d8 47 7d e4  |.=....rG.y=i.G}.|
00000010  ae 46 0e 3a 05 b0 6b 46  9c 5c 5d 38 4d 90 23 43  |.F.:..kF.\]8M.#C|
00000020  00 08 00 00 00 00 00 00  de 7f 3e 00 00 00 00 00  |..........>.....|
00000030  00 00 00 00 00 00 00 00  4a 00 75 00 61 00 6e 00  |........J.u.a.n.|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
root@moon:/home/juan/Escritorio/POSTS/mbr_gpt#


Claramente en el sector 4095967 se encuentra una copia de la primer entrada del arreglo de particiones!!!

Hasta acá llegó!!!

domingo, 27 de septiembre de 2015

Mondragon Unibersitatea: Seguridad Hacking ético

Hace unas semanas me inscribí a un curso online dictado por Mondragon Unibersitatea. A partir de ahora usaré este post para incluir las respuestas a los ejercicios propuestos.

Tarea 1


La primera tarea consiste en utilizar ping, whois, nmap como herramientas para recabar información acerca de los objetivos.

Ping a www.google.com:

juan@moon:~$ ping -c 3 www.google.com
PING www.google.com (216.58.211.164) 56(84) bytes of data.
64 bytes from dub08s01-in-f4.1e100.net (216.58.211.164): icmp_seq=1 ttl=58 time=11.3 ms
64 bytes from dub08s01-in-f4.1e100.net (216.58.211.164): icmp_seq=2 ttl=58 time=15.2 ms
64 bytes from dub08s01-in-f4.1e100.net (216.58.211.164): icmp_seq=3 ttl=58 time=13.1 ms
--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 11.392/13.259/15.209/1.565 ms
juan@moon:~$


Se puede apreciar como el host 216.58.211.164 que responde al nombre www.google.com respondió los mensajes ICMP perfectamente.

Ping a www.euskalert.net

juan@moon:~$ ping -c 3 www.euskalert.net
PING www.euskalert.net (193.146.78.12) 56(84) bytes of data.
--- www.euskalert.net ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2016ms
juan@moon:~$

A diferencia de www.google.com, el host 193.146.78.12 que responde al nombre www.euskalert.net no respondió los mensajes ICMP. Muchas veces los mensajes ICMP son restringidos porque podrían ser considerados como fuga de información. Los paquetes pueden haber sido descartados por el host mismo o por algún otro dispositivo como un firewall que se encuentre protegiéndolo.

Whois a www.google.com

juan@moon:~$ whois www.google.com
Whois Server Version 2.0
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
   Server Name: WWW.GOOGLE.COM.AR
   Registrar: ENOM, INC.
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Server Name: WWW.GOOGLE.COM.AU
   Registrar: MELBOURNE IT, LTD. D/B/A INTERNET NAMES WORLDWIDE
   Whois Server: whois.melbourneit.com
   Referral URL: http://www.melbourneit.com
   Server Name: WWW.GOOGLE.COM.BR
   Registrar: ENOM, INC.
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Server Name: WWW.GOOGLE.COM.CO
   Registrar: ENOM, INC.
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Server Name: WWW.GOOGLE.COM.DO
   Registrar: ENOM, INC.
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Server Name: WWW.GOOGLE.COM.GERRYGOULD.COM
   IP Address: 8.8.4.4
   IP Address: 8.8.8.8
   IP Address: 2001:4860:4860:0:0:0:0:8844
   IP Address: 2001:4860:4860:0:0:0:0:8888
   Registrar: GOOGLE INC.
   Whois Server: whois.rrpproxy.net
   Referral URL: http://domains.google.com
   Server Name: WWW.GOOGLE.COM.HK
   Registrar: GKG.NET, INC.
   Whois Server: whois.gkg.net
   Referral URL: http://www.gkg.net
   Server Name: WWW.GOOGLE.COM.INFO-MADA.COM
   IP Address: 216.239.32.21
   IP Address: 216.239.38.21
   IP Address: 216.239.36.21
   IP Address: 216.239.34.21
   Registrar: GODADDY.COM, LLC
   Whois Server: whois.godaddy.com
   Referral URL: http://registrar.godaddy.com
   Server Name: WWW.GOOGLE.COM.MX
   Registrar: ENOM, INC.
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Server Name: WWW.GOOGLE.COM.NAPLESCABS.COM
   IP Address: 216.239.32.21
   IP Address: 216.239.34.21
   IP Address: 216.239.36.21
   IP Address: 216.239.38.21
   Registrar: GODADDY.COM, LLC
   Whois Server: whois.godaddy.com
   Referral URL: http://registrar.godaddy.com
   Server Name: WWW.GOOGLE.COM.PE
   Registrar: DELUXE SMALL BUSINESS SALES, INC. D/B/A APLUS.NET
   Whois Server: whois.names4ever.com
   Referral URL: http://www.aplus.net
   Server Name: WWW.GOOGLE.COM.PK
   Registrar: INTERNET.BS CORP.
   Whois Server: whois.internet.bs
   Referral URL: http://www.internet.bs
   Server Name: WWW.GOOGLE.COM.SA
   Registrar: OMNIS NETWORK, LLC
   Whois Server: whois.omnis.com
   Referral URL: http://www.omnis.com
   Server Name: WWW.GOOGLE.COM.TR
   Registrar: TUCOWS DOMAINS INC.
   Whois Server: whois.tucows.com
   Referral URL: http://www.tucowsdomains.com
   Server Name: WWW.GOOGLE.COM.TW
   Registrar: ENOM, INC.
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Server Name: WWW.GOOGLE.COM.VN
   Registrar: ENOM, INC.
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
>>> Last update of whois database: Sat, 26 Sep 2015 15:01:44 GMT <<<
NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar.  Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.
TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability.  VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.
The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
For more information on Whois status codes, please visit
https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en.
juan@moon:~$


whois es un servicio de directorio que provee información pública de dominios y redes.

Nmap www.euskalert.net

Le indicamos a nmap que realice un scaneo a una serie de puertos conocidos para ver qué sucede.

juan@moon:~$ nmap -A -p 80,22,443,25,110  www.euskalert.net

Starting Nmap 6.40 ( http://nmap.org ) at 2015-09-27 13:11 IST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.24 seconds
juan@moon:~$ 


Como vimos en el punto anterior, el host no responde ping, así que nmap frena la ejecución del scaneo. Podemos indicarle que ignore ping y que intente de todas maneras:

juan@moon:~$ nmap -A -Pn -p 80,22,443,25,110  www.euskalert.net

Starting Nmap 6.40 ( http://nmap.org ) at 2015-09-27 13:11 IST
Nmap scan report for www.euskalert.net (193.146.78.12)
Host is up.
PORT    STATE    SERVICE VERSION
22/tcp  filtered ssh
25/tcp  filtered smtp
80/tcp  filtered http
110/tcp filtered pop3
443/tcp filtered https

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 3.53 seconds
juan@moon:~$


A pesar de todo parece que los puertos se encuentran filtrados, esto suele significar que los paquetes que enviamos estan siendo descartados por algún firewall. Para tener un contra ejemplo apunté nmap esta vez a www.google.com y se puede ver lo siguiente:

juan@moon:~$ nmap -A -p 80,22,443,25,110  www.google.com

Starting Nmap 6.40 ( http://nmap.org ) at 2015-09-27 13:26 IST
Nmap scan report for www.google.com (216.58.211.164)
Host is up (0.015s latency).
rDNS record for 216.58.211.164: dub08s01-in-f4.1e100.net
PORT    STATE    SERVICE  VERSION
22/tcp  filtered ssh
25/tcp  filtered smtp
80/tcp  open     http     Google httpd 2.0 (GFE)
|_http-methods: No Allow or Public header in OPTIONS response (status code 405)
| http-robots.txt: 255 disallowed entries (15 shown)
| /search /sdch /groups /catalogs /catalogues /news /nwshp
| /setnewsprefs? /index.html? /? /?hl=*& /?hl=*&*&gws_rd=ssl
|_/addurl/image? /mail/ /pagead/
|_http-title: Did not follow redirect to http://www.google.ie/?gws_rd=cr&ei=nOAHVqzaFIuNsAHL_p3IDQ
110/tcp filtered pop3
443/tcp open     ssl/http Google httpd 2.0 (GFE)
|_http-methods: No Allow or Public header in OPTIONS response (status code 405)
| http-robots.txt: 255 disallowed entries (15 shown)
| /search /sdch /groups /catalogs /catalogues /news /nwshp
| /setnewsprefs? /index.html? /? /?hl=*& /?hl=*&*&gws_rd=ssl
|_/addurl/image? /mail/ /pagead/
|_http-title: Did not follow redirect to https://www.google.ie/?gws_rd=cr&ei=nOAHVszzFciPsgHJtLWQBA
| ssl-cert: Subject: commonName=www.google.com/organizationName=Google Inc/stateOrProvinceName=California/countryName=US
| Not valid before: 2015-09-09T21:53:39+00:00
|_Not valid after:  2015-12-08T00:00:00+00:00
|_ssl-date: 2015-09-27T12:27:08+00:00; 0s from local time.
| tls-nextprotoneg:
|   h2
|   h2-15
|   h2-14
|   spdy/3.1
|   spdy/3
|_  http/1.1
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 20.85 seconds
juan@moon:~$


Claramente los servidores de google son mucho mas verborrágicos. Entre otras cosas vemos los puertos 80 y 443 abiertos, indicios de que se trata de un servidor web, también vemos información del certificado SSL usado en el puerto 443 y por último nmap nos indica que el servidor corre un Sistema Operativo tipo Linux.

Tarea 2


Personalmente sigo 2 sitios web de seguridad en español:

www.securitybydefault.com
www.segu-info.com.ar

utilizo estos dos, porque generalmente tienen noticias y posts muy interesantes y actualizados.

Por otro lado estoy suscripto a SANS y US-CERT, desde los cuales recibo mucha información de las ultimas vulnerabilidades descubiertas y a veces documentos muy interesantes para leer.

www.sans.org
www.us-cert.gov

Tarea 3


Esta tarea consiste en aprender los conceptos de criptografía y aplicarlos utilizando una herramienta como PGP (GPG en este caso particular). Al utilizar una herramienta como estamos haciendo uso de:
  • Algoritmos de cifrado simétricos (posiblemente 3DES, AES o IDEA), con los que realmente se cifra la información.
  • Algoritmos de cifrado asimétricos (posiblemente RSA, El Gamal, etc), los que se utilizan para por ejemplo cifrar la clave del algoritmo simétrico utilizado, como así también en el proceso de firmado.
  • Algoritmos de hash, utilizados principalmente en el firmado (posiblemente md5 BAD IDEA!!!, SHA1 o RIPEMD160).
A continuación se ilustran los pasos seguidos para la creación de un par de claves gpg, su utilización para el cifrado y firmado de un archivos, así como también para el decifrado y verificación de un archivo recibido.
  • Creación de par de claves
juan@moon:~$ gpg --gen-key
gpg (GnuPG) 1.4.16; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Por favor seleccione tipo de clave deseado:
   (1) RSA y RSA (predeterminado)
   (2) DSA y Elgamal
   (3) DSA (sólo firmar)
   (4) RSA (sólo firmar)
¿Su selección?: 2
las claves DSA pueden tener entre 1024 y 3072 bits de longitud.
¿De qué tamaño quiere la clave? (2048)
El tamaño requerido es de 2048 bits
Por favor, especifique el período de validez de la clave.
         0 = la clave nunca caduca
        = la clave caduca en n días
      w = la clave caduca en n semanas
      m = la clave caduca en n meses
      y = la clave caduca en n años
¿Validez de la clave (0)?
La clave nunca caduca
¿Es correcto? (s/n) s

Necesita un identificador de usuario para identificar su clave. El programa
construye el identificador a partir del Nombre Real, Comentario y Dirección
de Correo electrónico de esta forma:
    "Heinrich Heine (Der Dichter) "

Nombre y apellidos: Juan Pavlik
Dirección de correo electrónico: jjpavlik@gmail.com
Comentario: Clave de correo privado
Ha seleccionado este ID de usuario:
    «Juan Pavlik (Clave de correo privado) »

¿Cambia (N)ombre, (C)omentario, (D)irección o (V)ale/(S)alir? V
Necesita una frase contraseña para proteger su clave secreta.

Es necesario generar muchos bytes aleatorios. Es una buena idea realizar
alguna otra tarea (trabajar en otra ventana/consola, mover el ratón, usar
la red y los discos) durante la generación de números primos. Esto da al
generador de números aleatorios mayor oportunidad de recoger suficiente
entropía.
gpg: WARNING: some OpenPGP programs can't handle a DSA key with this digest size
...+++++++++++++++++++++++++..++++++++++.++++++++++++++++++++.++++++++++.+++++++++++++++....+++++.++++++++++++++++++++..+++++++++++++++.+++++++++++++++>.+++++.....+++++

No hay suficientes bytes aleatorios disponibles. Por favor, haga algún
otro trabajo para que el sistema pueda recolectar más entropía
(se necesitan 179 bytes más).
Es necesario generar muchos bytes aleatorios. Es una buena idea realizar
alguna otra tarea (trabajar en otra ventana/consola, mover el ratón, usar
la red y los discos) durante la generación de números primos. Esto da al
generador de números aleatorios mayor oportunidad de recoger suficiente
entropía.
+++++..+++++.+++++.++++++++++++++++++++.++++++++++...++++++++++..+++++++++++++++++++++++++++++++++++..+++++.....+++++.++++++++++++++++++++.++++++++++.+++++.+++++.........+++++>.++++++++++.........................................................................................................................................>+++++.........<+++++........................................................+++++^^^^
gpg: /home/juan/.gnupg/trustdb.gpg: se ha creado base de datos de confianza
gpg: clave EBB4304A marcada como de confianza absoluta
claves pública y secreta creadas y firmadas.

gpg: comprobando base de datos de confianza
gpg: 3 dudosa(s) necesarias, 1 completa(s) necesarias,
modelo de confianza PGP
gpg: nivel: 0  validez:   1  firmada:   0  confianza: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048D/EBB4304A 2015-09-27
      Huella de clave = 5512 56C3 DACF 7F93 E2B8  7488 EA41 FB13 EBB4 304A
uid                  Juan Pavlik (Clave de correo privado)
sub   2048g/1763AEAE 2015-09-27

juan@moon:~$  

  • Exportar la clave pública (para compartir con los potenciales emisores de mensajes)
juan@moon:~$ gpg --list-keys
/home/juan/.gnupg/pubring.gpg
-----------------------------
pub   2048D/EBB4304A 2015-09-27
uid                  Juan Pavlik (Clave de correo privado)
sub   2048g/1763AEAE 2015-09-27

juan@moon:~$ gpg --export --armor EBB4304A > jjpavlik.pub
juan@moon:~$ file jjpavlik.pub
jjpavlik.pub: PGP public key block
juan@moon:~$

  • Importar la clave pública del destinatario (para corroborar mensajes recibidos)
juan@moon:~$ gpg --import < alberto.asc.pub
gpg: clave 2189649E: clave pública "Alberto XXX (Ninguno) " importada
gpg: Cantidad total procesada: 1
gpg:               importadas: 1  (RSA: 1)
juan@moon:~$

  •  Cifrado y firmado de archivo a enviar
juan@moon:~$ gpg --recipient "Alberto Sanchez" --sign --encrypt archivo_confidencial.txt

Necesita una frase contraseña para desbloquear la clave secreta
del usuario: "Juan Pavlik (Clave de correo privado) "
clave DSA de 2048 bits, ID EBB4304A, creada el 2015-09-27

gpg: 0FBE2389: No hay seguridad de que esta clave pertenezca realmente
al usuario que se nombra

pub  2048R/0FBE2389 2015-09-27 Alberto XXX (Ninguno)
 Huella de clave primaria: 2625 E0DD 6949 77EE 010A  F901 83AA 1F49 2189 649E
      Huella de subclave: 2E18 3F7C 07AF E051 39A8  AD67 9E17 17C7 0FBE 2389

No es seguro que la clave pertenezca a la persona que se nombra en el
identificador de usuario. Si *realmente* sabe lo que está haciendo,
puede contestar sí a la siguiente pregunta.

¿Usar esta clave de todas formas? (s/N) s
juan@moon:~$ 

  • Decifrado y control de firma de un archivo recibido
juan@moon:~$ gpg --decrypt Descargas/mensaje_enc.txt.gpg > mensaje.txt

Necesita una frase contraseña para desbloquear la clave secreta
del usuario: "Juan Pavlik (Clave de correo privado) "
clave ELG-E de 2048 bits, ID 1763AEAE, creada el 2015-09-27 (ID de clave primaria EBB4304A)

gpg: cifrado con clave ELG-E de 2048 bits, ID 1763AEAE, creada el 2015-09-27
      «Juan Pavlik (Clave de correo privado) »
gpg: Firmado el dom 27 sep 2015 19:30:24 IST usando clave RSA ID 2189649E
gpg: Firma correcta de «Alberto XXX (Ninguno) »
gpg: AVISO: ¡Esta clave no está certificada por una firma de confianza!
gpg:          No hay indicios de que la firma pertenezca al propietario.
Huellas dactilares de la clave primaria: 2625 E0DD 6949 77EE 010A  F901 83AA 1F49 2189 649E
juan@moon:~$ cat mensaje.txt
Éste es un mensaje de prueba de encriptación/desencriptación, correspondiente a la Tarea 3, de la Unidad 1.

juan@moon:~$