Pululando por la web de VMWare, resulta que me valido para poder proceder a la descarga de sus productos, y veo que para cada descarga proporcionan los checksums correspondientes (MD5 y SHA1) de los ficheros. Esto es para comprobar que lo que te descargas es lo que VMWare dice ser, y que no ha sido modificado en ningún momento. En otras palabras (y para que suene más profesional), para comprobar la integridad de los ficheros descargados.
Entonces, vamos a ver cómo podemos averiguar los hashes de los archivos, según el sistema operativo que tengamos:
Linux: ya de forma nativa te trae los comandos md5sum y sha1sum (cómo no).
Windows: tenemos Message Digest Command Line Utility por un lado, o File Checksum Integrity Verifier por otro.
Mac: yo lo acabo de probar en un Mac OS X 10.6.8 (Snow Leopard) y es parecido a Linux. Aquí, tenemos los comandos:
#openssl md5 [archivo]
#openssl sha1 [archivo]
Una cosa que ayuda bastante, es que, una vez tecleado el comando en el Terminal, a falta de teclear el nombre del fichero, lo que puedes hacer es arrastrar el fichero que necesites desde el Finder hasta el Terminal, y ya solo te quedar darle al Enter para ver el resultado.
También tenéis el add-on o complemento de Firefox, Fire Encrypter.
También podemos buscarle otras utilidades, como por ejemplo, comprobar la seguridad de tus contraseñas.
Un saludo ;)
sábado, 18 de febrero de 2012
jueves, 26 de enero de 2012
Suspensión vs Hibernación
Cito textualmente lo que indica la ayuda de Windows (
+ F1):
La suspensión es un estado de ahorro de energía que permite al equipo reanudar rápidamente el funcionamiento a pleno rendimiento (normalmente en unos segundos) cuando desee seguir trabajando. Poner el equipo en estado de suspensión es como poner en pausa un reproductor de DVD: el equipo interrumpe inmediatamente la tarea que está realizando y está preparado para reiniciar el trabajo cuando usted lo decida.
La hibernación es un estado de ahorro de energía diseñado principalmente para equipos portátiles. Mientras que la suspensión guarda el trabajo y la configuración en la memoria y consume una pequeña cantidad de energía, la hibernación guarda los documentos y programas abiertos en el disco duro y después apaga el equipo. De todos los estados de ahorro de energía de Windows, la hibernación es el que menos energía consume. En un equipo portátil, debe usar la hibernación cuando sabe que no usará el equipo durante un largo período y que no podrá recargar la batería durante dicho lapso.
La suspensión híbrida fue diseñada principalmente para equipos de escritorio. La suspensión híbrida es una combinación del modo de suspensión e hibernación que guarda todos los documentos y programas abiertos en la memoria y en el disco duro y, a continuación, el equipo pasa a un estado de bajo consumo de energía para que pueda reanudar el trabajo rápidamente. De este modo, si se produce un error de alimentación, Windows puede restaurar el trabajo desde el disco duro. Cuando la suspensión híbrida está activada, al colocar el equipo en modo de suspensión, el equipo pasa automáticamente a la suspensión híbrida. En los equipos de escritorio, la suspensión híbrida suele estar activada de forma predeterminada.
+ F1):La suspensión es un estado de ahorro de energía que permite al equipo reanudar rápidamente el funcionamiento a pleno rendimiento (normalmente en unos segundos) cuando desee seguir trabajando. Poner el equipo en estado de suspensión es como poner en pausa un reproductor de DVD: el equipo interrumpe inmediatamente la tarea que está realizando y está preparado para reiniciar el trabajo cuando usted lo decida.
La hibernación es un estado de ahorro de energía diseñado principalmente para equipos portátiles. Mientras que la suspensión guarda el trabajo y la configuración en la memoria y consume una pequeña cantidad de energía, la hibernación guarda los documentos y programas abiertos en el disco duro y después apaga el equipo. De todos los estados de ahorro de energía de Windows, la hibernación es el que menos energía consume. En un equipo portátil, debe usar la hibernación cuando sabe que no usará el equipo durante un largo período y que no podrá recargar la batería durante dicho lapso.
La suspensión híbrida fue diseñada principalmente para equipos de escritorio. La suspensión híbrida es una combinación del modo de suspensión e hibernación que guarda todos los documentos y programas abiertos en la memoria y en el disco duro y, a continuación, el equipo pasa a un estado de bajo consumo de energía para que pueda reanudar el trabajo rápidamente. De este modo, si se produce un error de alimentación, Windows puede restaurar el trabajo desde el disco duro. Cuando la suspensión híbrida está activada, al colocar el equipo en modo de suspensión, el equipo pasa automáticamente a la suspensión híbrida. En los equipos de escritorio, la suspensión híbrida suele estar activada de forma predeterminada.
domingo, 15 de enero de 2012
Las tres barras de "file:///[path]"
Seguro que muchas veces habréis visto algún mensaje donde aparece algo como:
"No se encuentra el recurso file:///... "
Y siempre me preguntaba el por qué de las tres barras. Mediante file, lo que queremos es acceder a ficheros accesibles en un determinado host, y el formato de la URL es:
file://host/path
donde host es el FQDN del sistema que alberga el recurso, mientras que path es la ruta jerárquica donde se ubica el archivo, de la forma directorio/directorio/.../nombre_de_fichero.
Pues bien, consultando el RFC1738, referente a la URL, dice lo siguiente:
Como un caso especial, host puede ser "localhost" o la cadena vacía, lo que significa que se intenta acceder a un fichero que se encuentra en la misma máquina donde se está ejecutando la URL.
Así que creo que con ésto último, queda explicado lo de - Las tres barras de "file:///[path]" - ;)
"No se encuentra el recurso file:///... "
Y siempre me preguntaba el por qué de las tres barras. Mediante file, lo que queremos es acceder a ficheros accesibles en un determinado host, y el formato de la URL es:
file://host/path
donde host es el FQDN del sistema que alberga el recurso, mientras que path es la ruta jerárquica donde se ubica el archivo, de la forma directorio/directorio/.../nombre_de_fichero.
Pues bien, consultando el RFC1738, referente a la URL, dice lo siguiente:
Como un caso especial, host puede ser "localhost" o la cadena vacía, lo que significa que se intenta acceder a un fichero que se encuentra en la misma máquina donde se está ejecutando la URL.
Así que creo que con ésto último, queda explicado lo de - Las tres barras de "file:///[path]" - ;)
viernes, 13 de enero de 2012
SSL
El protocolo SSL (Secure Sockets Layer) es un estándar para comunicaciones seguras, normalmente a través de Internet entre cliente y servidor, encriptando los datos de forma que proporciona autenticación, integridad y privacidad. Fue creado por Netscape en 1994, siendo la versión 2.0 la que vio la luz de cara al público. Actualmente, ha evolucionado hasta convertirse en TLS (Transport Layer Security) en su versión 1.2, el cual se puede ver en más detalle en RFC5246.
Éste post está inspirado por el artículo de Chema Alonso "Cómo NO hacer una página de login" y por el test de evaluación de certificado servidor de SSLLabs. SSLLabs también proporciona una guía para entender un poco mejor los criterios empleados a la hora de dar los resultados. La web que vamos a evaluar es mail.live.com, (eso es lo que he tecleado en la barra de navegación).
Como nota, decir que existen certificados emitidos para dominios Internet, emitidos para organismos o empresas, y los certificados de validación extendida. Éstos últimos se pueden identificar a priori viendo la barra de navegación de nuestro Internet Explorer (toda verde), Firefox, Chrome, (en verde el nombre de la empresa o compañía), o lo que tengamos:
Internet Explorer 9:
Mozilla Firefox 9.0.1:
Google Chrome 16:
Las siguientes configuraciones encontradas darán directamente una puntuación de cero:
Bien, teniendo en cuenta la siguiente tabla de puntuaciones:
puntos >= 80 A
puntos >= 65 B
puntos >= 50 C
puntos >= 35 D
puntos >= 20 E
puntos < 20 F
vemos que mail.live.com tiene varios servidores, y obtiene un 85:
Escogemos el primero:
Información general del certificado:
Los tres puntos a tener en cuenta en esta evaluación son: protocolo soportado, intercambio de claves y cifrado. Seguimos con cada uno de ellos.
Protocolo soportado - 30% del total
SSL 2.0 20%
SSL 3.0 80%
TLS 1.0 90%
TLS 1.1 95%
TLS 1.2 100%
Intercambio de claves - 30% del total
Esta fase cubre dos aspectos: autenticación, identificando al menos una de las partes frente a la otra; y generación e intercambio de claves de forma segura, ya que éstas van a ser las que se usen durante el resto de la sesión. Evaluando cada una de éstas características, la tabla a tener en cuenta sería la siguiente:
Clave débil (fallo Debian OpenSSL) 0%
Intercambio de clave anónimo (sin autenticación) 0%
Longitud de clave < 512 bits 20%
Intercambio de clave exportable (limitado a 512 bits) 40%
Longitud de clave < 1024 bits (i.e., 512) 40%
Longitud de clave < 2048 bits (i.e., 1024) 80%
Longitud de clave < 4096 bits (i.e., 2048) 90%
Longitud de clave >= 4096 bits (i.e., 4096) 100%
Cifrado - 40% del total
Evaluación de la clave de cifrado, ya que, mientras más fuerte sea ésta, más complicado será de romper (elemental, ¿no?). La tabla a seguir sería:
0 bits (sin encriptar) 0%
< 128 bits (i.e., 40, 56) 20%
< 256 bits (i.e., 128, 168) 80%
>= 256 bits (i.e., 256) 100%
Como complemento, os dejo los vídeos que tiene Intypedia referentes a SSL:
Introducción a SSL:
Ataques al protocolo SSL:
Éste post está inspirado por el artículo de Chema Alonso "Cómo NO hacer una página de login" y por el test de evaluación de certificado servidor de SSLLabs. SSLLabs también proporciona una guía para entender un poco mejor los criterios empleados a la hora de dar los resultados. La web que vamos a evaluar es mail.live.com, (eso es lo que he tecleado en la barra de navegación).
Como nota, decir que existen certificados emitidos para dominios Internet, emitidos para organismos o empresas, y los certificados de validación extendida. Éstos últimos se pueden identificar a priori viendo la barra de navegación de nuestro Internet Explorer (toda verde), Firefox, Chrome, (en verde el nombre de la empresa o compañía), o lo que tengamos:
Internet Explorer 9:
Mozilla Firefox 9.0.1:
Google Chrome 16:
Las siguientes configuraciones encontradas darán directamente una puntuación de cero:
- No coincide el nombre de dominio.
- Certificado aún no válido.
- Certificado caducado.
- Certificado auto-firmado.
- Certificado en el que NO se confía (autoridad certificadora no reconocida o algún error de validación).
- Certificado revocado.
Bien, teniendo en cuenta la siguiente tabla de puntuaciones:
puntos >= 80 A
puntos >= 65 B
puntos >= 50 C
puntos >= 35 D
puntos >= 20 E
puntos < 20 F
vemos que mail.live.com tiene varios servidores, y obtiene un 85:
Escogemos el primero:
Información general del certificado:
Los tres puntos a tener en cuenta en esta evaluación son: protocolo soportado, intercambio de claves y cifrado. Seguimos con cada uno de ellos.
Protocolo soportado - 30% del total
SSL 2.0 20%
SSL 3.0 80%
TLS 1.0 90%
TLS 1.1 95%
TLS 1.2 100%
Intercambio de claves - 30% del total
Esta fase cubre dos aspectos: autenticación, identificando al menos una de las partes frente a la otra; y generación e intercambio de claves de forma segura, ya que éstas van a ser las que se usen durante el resto de la sesión. Evaluando cada una de éstas características, la tabla a tener en cuenta sería la siguiente:
Clave débil (fallo Debian OpenSSL) 0%
Intercambio de clave anónimo (sin autenticación) 0%
Longitud de clave < 512 bits 20%
Intercambio de clave exportable (limitado a 512 bits) 40%
Longitud de clave < 1024 bits (i.e., 512) 40%
Longitud de clave < 2048 bits (i.e., 1024) 80%
Longitud de clave < 4096 bits (i.e., 2048) 90%
Longitud de clave >= 4096 bits (i.e., 4096) 100%
Cifrado - 40% del total
Evaluación de la clave de cifrado, ya que, mientras más fuerte sea ésta, más complicado será de romper (elemental, ¿no?). La tabla a seguir sería:
0 bits (sin encriptar) 0%
< 128 bits (i.e., 40, 56) 20%
< 256 bits (i.e., 128, 168) 80%
>= 256 bits (i.e., 256) 100%
Como complemento, os dejo los vídeos que tiene Intypedia referentes a SSL:
Introducción a SSL:
Ataques al protocolo SSL:
miércoles, 11 de enero de 2012
Cabeceras HTTP
La intención que tenía con éste post es un poco analizar las cabeceras HTTP Request que producen los distintos navegadores al lanzar una petición a un mismo recurso, en éste caso, www.google.es. He probado ésto con 3 de los navegadores más extendidos y usados en el mercado:
Google Chrome 16.0.912.75 m:
Internet Explorer 9.00.8112.16421 (Versiones de actualización: 9.0.4):
Firefox 8.0.1:
La idea no es nada del otro mundo, ni soy un experto en la materia, pero buscando un poco y con una dosis de curiosidad he decidido redactar y explicar un poco lo que aparece en cada imagen. Ya véis que existe un mundo lleno de posibilidades y que ésto es solo la punta del iceberg. Con ésto dicho, ¡vamos al grano!
La herramienta que he usado para llevar el análisis es Fiddler - Web Debugging Proxy, herramienta para analizar todo el tráfico HTTP(S) entre nuestro equipo e Internet. Actúa como proxy y funciona con cualquier aplicativo que soporte conexiones por proxy. Es muy fácil de usar, versátil, y extensible a través de plugins.
Primero que nada, decir que HTTP viene de Hypertext Transfer Protocol, y a modo de resumen, es el protocolo empleado para navegar por páginas web. Tenéis más información en la Wikipedia. El RFC2616 es en donde se define dicho protocolo, concretamente en su versión 1.1.
HTTP URL
La forma de solicitar un recurso de red a través de http es la siguiente:
http_URL = "http:" "//" host [ ":" puerto ] [ path_absoluto [ "?" query ]]
Si no se especifica el puerto, se asume por defecto el puerto 80. Si no se define el path_absoluto, éste se establece como "/". Como nota o curiosidad, tener en cuenta que aunque HTTP es independiente de la capa de transporte, el http_URL identifica el recurso referenciado por su localización TCP, así que si dichos recursos NO son TCP, se deben de referenciar con una URI de diferente estructura o esquema.
Métodos
Los métodos son las posibles acciones que se pueden llevar a cabo sobre el recurso solicitado, el Request-URI. Los que tenemos disponibles son los siguientes (pero ya dependerá del admin si están implementados en el servidor o no): OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE y CONNECT. De todos éstos, GET y HEAD son obligatorios, mientras que el resto son opcionales. En nuestro caso, hemos empleado GET.
GET / HTTP/1.1
Bien, con todo lo explicado hasta ahora, vemos que lo que estamos haciendo es solicitar "/" (el recurso raíz) al servidor en cuestión, mediante una conexión TCP al puerto 80. ¿Y cómo sabemos cuál es el servidor? Pues ésto es por un campo que aparece más abajo, que nos indica que Host: www.google.es. Vemos también que la solicitud se realiza con HTTP versión 1.1 (junio 1999).
Ahora pasaremos a explicar algunas de las opciones que aparecen en las cabeceras tratadas:
Cache-control: no-cache
Esto indica que la respuesta que tenemos que recibir no es una que ya esté cacheada en el servidor, sino digamos, que debe procesarla desde cero. El propósito de cachés en este caso no sería más que reducir el tiempo de respuesta y ancho de banda de las comunicaciones.
Pragma: no-cache
Viene a ser lo mismo que la opción anterior, y se pone para mantener la compatibilidad con HTTP/1.0.
Accept:
Indica el tipo de contenido que acepta el cliente. El "*/*" indicaría que todos los tipos existentes, mientras que "type/*" indicaría todos los subtipos del tipo definido. El parámetro "q" se define como "factor o medida de calidad" y sirve para indicar la importancia, preferencia o peso del tipo indicado anteriormente. Los valores que puede tomar están en el rango de 0 (mínimo) y 1 (máximo). Si no se indica explícitamente este parámetro, el valor que toma por defecto es 1.
Si no se ha establecido la opción Accept, sería equivalente a:
Accept: */*; q=1
o
Accept: */*
Un ejemplo más elaborado sería:
Accept: text/*;q=0.3, text/html;q=0.7, text/html;version=2.0, */*;q=0.5
equivaldría a, por ejemplo:
text/html;version=2.0 = 1
text/html = 0.7
text/plain = 0.3
image/jpeg = 0.5
text/html;level=3 = 0.7
La opción de Accept se emplea para restringir el tipo de datos permitidos a un conjunto limitado, y ésto muchas veces viene determinado por el User-Agent y el recurso solicitado.
Accept-Charset:
Sería el juego de caracteres aceptados. Los posibles valores serían: "US-ASCII"
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
| token.
Accept-Encoding:
gzip - Codificación en formato de compresión GNU zip.
deflate - Formato "zilb" en conjunción con el método de compresión "deflate".
sdch - Shared Dictionary Compression over HTTP. Vemos que lo emplea Chrome. También conocido como "sandwich".
Accept-Language:
El lenguaje o idioma aceptado. También se puede emplear el método de preferencias con el parámetro "q", para indicar qué idioma es preferible sobre otros.
User-Agent:
El cliente que realiza la petición, el cual puede ser un navegador, un editor, un spider o robot o cualquier otro tipo de herramienta.
La nomenclatura a seguir sería la siguiente:
"User-Agent" ":" 1*( producto | comentarios )
donde si hay más de un producto, éstos se listan por orden de prioridad, y los comentarios son para dar más detalles acerca de los subproductos empleados por el agente de usuario.
En nuestro ejemplo ya podemos ver cómo cambian estos valores según el navegador. Vamos a ver una breve definición de los términos que aparecen en cada caso:
Windows NT 6.1: Indica que se trata de un Windows 7 o un Windows 2008 R2.
WOW64: Una aplicación de 32 bits ejecutada sobre una plataforma de 64 bits.
AppleWebKit: Plataforma de aplicaciones basada en el motor de renderizado KHTML del navegador Konqueror, del proyecto KDE.
KHTML: Motor de renderizado HTML libre desarrollado por KDE.
Trident: Motor de renderizado privado empleado por Internet Explorer.
Gecko: Motor de renderizado libre gestionado por Mozilla.
Puedes usar whatsmyuseragent.com para averiguar tu User-Agent ;)
Connection: Keep-Alive
También conocido como conexión persistente HTTP, donde la idea es usar una única conexión TCP para enviar múltiples peticiones/respuestas HTTP.
Host:
El nombre de Internet de la máquina que alberga el recurso. Este campo es obligatorio para HTTP/1.1 en todas aquellas peticiones que no se incluya el nombre de host en el Request-URI.
Google Chrome 16.0.912.75 m:
Internet Explorer 9.00.8112.16421 (Versiones de actualización: 9.0.4):
Firefox 8.0.1:
La idea no es nada del otro mundo, ni soy un experto en la materia, pero buscando un poco y con una dosis de curiosidad he decidido redactar y explicar un poco lo que aparece en cada imagen. Ya véis que existe un mundo lleno de posibilidades y que ésto es solo la punta del iceberg. Con ésto dicho, ¡vamos al grano!
La herramienta que he usado para llevar el análisis es Fiddler - Web Debugging Proxy, herramienta para analizar todo el tráfico HTTP(S) entre nuestro equipo e Internet. Actúa como proxy y funciona con cualquier aplicativo que soporte conexiones por proxy. Es muy fácil de usar, versátil, y extensible a través de plugins.
Primero que nada, decir que HTTP viene de Hypertext Transfer Protocol, y a modo de resumen, es el protocolo empleado para navegar por páginas web. Tenéis más información en la Wikipedia. El RFC2616 es en donde se define dicho protocolo, concretamente en su versión 1.1.
HTTP URL
La forma de solicitar un recurso de red a través de http es la siguiente:
http_URL = "http:" "//" host [ ":" puerto ] [ path_absoluto [ "?" query ]]
Si no se especifica el puerto, se asume por defecto el puerto 80. Si no se define el path_absoluto, éste se establece como "/". Como nota o curiosidad, tener en cuenta que aunque HTTP es independiente de la capa de transporte, el http_URL identifica el recurso referenciado por su localización TCP, así que si dichos recursos NO son TCP, se deben de referenciar con una URI de diferente estructura o esquema.
Métodos
Los métodos son las posibles acciones que se pueden llevar a cabo sobre el recurso solicitado, el Request-URI. Los que tenemos disponibles son los siguientes (pero ya dependerá del admin si están implementados en el servidor o no): OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE y CONNECT. De todos éstos, GET y HEAD son obligatorios, mientras que el resto son opcionales. En nuestro caso, hemos empleado GET.
GET / HTTP/1.1
Bien, con todo lo explicado hasta ahora, vemos que lo que estamos haciendo es solicitar "/" (el recurso raíz) al servidor en cuestión, mediante una conexión TCP al puerto 80. ¿Y cómo sabemos cuál es el servidor? Pues ésto es por un campo que aparece más abajo, que nos indica que Host: www.google.es. Vemos también que la solicitud se realiza con HTTP versión 1.1 (junio 1999).
Ahora pasaremos a explicar algunas de las opciones que aparecen en las cabeceras tratadas:
Cache-control: no-cache
Esto indica que la respuesta que tenemos que recibir no es una que ya esté cacheada en el servidor, sino digamos, que debe procesarla desde cero. El propósito de cachés en este caso no sería más que reducir el tiempo de respuesta y ancho de banda de las comunicaciones.
Pragma: no-cache
Viene a ser lo mismo que la opción anterior, y se pone para mantener la compatibilidad con HTTP/1.0.
Accept:
Indica el tipo de contenido que acepta el cliente. El "*/*" indicaría que todos los tipos existentes, mientras que "type/*" indicaría todos los subtipos del tipo definido. El parámetro "q" se define como "factor o medida de calidad" y sirve para indicar la importancia, preferencia o peso del tipo indicado anteriormente. Los valores que puede tomar están en el rango de 0 (mínimo) y 1 (máximo). Si no se indica explícitamente este parámetro, el valor que toma por defecto es 1.
Si no se ha establecido la opción Accept, sería equivalente a:
Accept: */*; q=1
o
Accept: */*
Un ejemplo más elaborado sería:
Accept: text/*;q=0.3, text/html;q=0.7, text/html;version=2.0, */*;q=0.5
equivaldría a, por ejemplo:
text/html;version=2.0 = 1
text/html = 0.7
text/plain = 0.3
image/jpeg = 0.5
text/html;level=3 = 0.7
La opción de Accept se emplea para restringir el tipo de datos permitidos a un conjunto limitado, y ésto muchas veces viene determinado por el User-Agent y el recurso solicitado.
Accept-Charset:
Sería el juego de caracteres aceptados. Los posibles valores serían: "US-ASCII"
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
| token.
Accept-Encoding:
gzip - Codificación en formato de compresión GNU zip.
deflate - Formato "zilb" en conjunción con el método de compresión "deflate".
sdch - Shared Dictionary Compression over HTTP. Vemos que lo emplea Chrome. También conocido como "sandwich".
Accept-Language:
El lenguaje o idioma aceptado. También se puede emplear el método de preferencias con el parámetro "q", para indicar qué idioma es preferible sobre otros.
User-Agent:
El cliente que realiza la petición, el cual puede ser un navegador, un editor, un spider o robot o cualquier otro tipo de herramienta.
La nomenclatura a seguir sería la siguiente:
"User-Agent" ":" 1*( producto | comentarios )
donde si hay más de un producto, éstos se listan por orden de prioridad, y los comentarios son para dar más detalles acerca de los subproductos empleados por el agente de usuario.
En nuestro ejemplo ya podemos ver cómo cambian estos valores según el navegador. Vamos a ver una breve definición de los términos que aparecen en cada caso:
Windows NT 6.1: Indica que se trata de un Windows 7 o un Windows 2008 R2.
WOW64: Una aplicación de 32 bits ejecutada sobre una plataforma de 64 bits.
AppleWebKit: Plataforma de aplicaciones basada en el motor de renderizado KHTML del navegador Konqueror, del proyecto KDE.
KHTML: Motor de renderizado HTML libre desarrollado por KDE.
Trident: Motor de renderizado privado empleado por Internet Explorer.
Gecko: Motor de renderizado libre gestionado por Mozilla.
Puedes usar whatsmyuseragent.com para averiguar tu User-Agent ;)
Connection: Keep-Alive
También conocido como conexión persistente HTTP, donde la idea es usar una única conexión TCP para enviar múltiples peticiones/respuestas HTTP.
Host:
El nombre de Internet de la máquina que alberga el recurso. Este campo es obligatorio para HTTP/1.1 en todas aquellas peticiones que no se incluya el nombre de host en el Request-URI.
viernes, 2 de diciembre de 2011
Pranav Mistry: La tecnología del sexto sentido
Increíble vídeo de presentación en TED India de Pranav Mistry, inventor de SixthSense, acerca del nuevo paradigma de interacción entre el mundo real y el digital. Esto es el futuro... ¿a alguien le suena Minority Report?
viernes, 11 de noviembre de 2011
Más que flexiones
Para aquellos que estén cansados de las flexiones de toda la vida, aquí os dejo algo que motiva un poco ;)
jueves, 10 de noviembre de 2011
FOCA
Ya por la versión 3.0, FOCA 3.0 FREE es una herramienta para la realización de procesos de fingerprinting e information gathering en trabajos de auditoría web. La versión Free realiza búsqueda de servidores, dominios, URLs y documentos publicados, así como el descubrimiento de versiones de software en servidores y clientes. FOCA se hizo famosa por la extracción de metadatos en documentos públicos, pero hoy en día es mucho más que eso.
Más información en la web de Informática 64.
A continuación os dejo un vídeo más que interesante de cómo funciona esta herramienta (en este caso usan la versión 2.5), explicado por Chema Alonso y José Palazón "Palako". Espero que lo disfrutéis:
Más información en la web de Informática 64.
A continuación os dejo un vídeo más que interesante de cómo funciona esta herramienta (en este caso usan la versión 2.5), explicado por Chema Alonso y José Palazón "Palako". Espero que lo disfrutéis:
FOCA 2.5 from shobhit tiwari on Vimeo.
sábado, 22 de octubre de 2011
SHODAN
Aunque ya lleva tiempo en activo, os voy a poner una pequeña introducción a lo que es SHODAN y lo que nos puede ofrecer.
Básicamente, se trata de un motor de búsqueda, al igual que Google y Bing, pero lo que busca son dispositivos en Internet (routers, servidores, etc.). ¿Cómo lo hace? Pues indexando lo que llama "banners", que no son más que las cabeceras de las respuestas que nos devuelven los servidores y que pertenecen al protocolo correspondiente (HTTP, FTP, etc.). Para más información podéis consultar el site man SHODAN.
Un ejemplo básico, muy, muy sencillo, es la comparativa del debate clásico ya entre la disputa de software propietario y software libre. Apache vs Internet Information Services, donde se emplea un argumento de peso, que es... ¿cuál de los dos es más usado a nivel mundial? Bueno, SHODAN nos puede echar una mano con eso:
Apache:
IIS:
¿Os lo creéis ahora? Obviamente, esto es lo mínimo que nos puede llegar a ofrecer esta potente y singular herramienta. Y ya si le dais un poco al coco y a la imaginación, tenéis un mundo lleno de posibilidades.
Básicamente, se trata de un motor de búsqueda, al igual que Google y Bing, pero lo que busca son dispositivos en Internet (routers, servidores, etc.). ¿Cómo lo hace? Pues indexando lo que llama "banners", que no son más que las cabeceras de las respuestas que nos devuelven los servidores y que pertenecen al protocolo correspondiente (HTTP, FTP, etc.). Para más información podéis consultar el site man SHODAN.
Un ejemplo básico, muy, muy sencillo, es la comparativa del debate clásico ya entre la disputa de software propietario y software libre. Apache vs Internet Information Services, donde se emplea un argumento de peso, que es... ¿cuál de los dos es más usado a nivel mundial? Bueno, SHODAN nos puede echar una mano con eso:
Apache:
IIS:
¿Os lo creéis ahora? Obviamente, esto es lo mínimo que nos puede llegar a ofrecer esta potente y singular herramienta. Y ya si le dais un poco al coco y a la imaginación, tenéis un mundo lleno de posibilidades.
ONO 50Mb
Ahora que me he mudado a capital city, era cuestión de cambiar de ubicación mi conexión de banda ancha con ONO. Ya que en Canarias no tenemos la opción de 50Mb ni 100Mb, he decidido probar con la de 50Mb.
Para aquellos que se pregunten si son reales o no, aquí os pongo mi Test de Velocidad:
Como contra, tengo que decir que el servicio de atención al cliente es un poco cansino y poco eficiente, sobre todo al tratar de darme de alta en el servicio de factura electrónica.
Un saludo y hasta la próxima!!
Para aquellos que se pregunten si son reales o no, aquí os pongo mi Test de Velocidad:
Como contra, tengo que decir que el servicio de atención al cliente es un poco cansino y poco eficiente, sobre todo al tratar de darme de alta en el servicio de factura electrónica.
Un saludo y hasta la próxima!!
Suscribirse a:
Entradas (Atom)