domingo, 8 de julio de 2018

Cambio de Blog

Hola.

No solo he vuelto, sino que he cambiado de blog. Ahora publico en wordpress:

https://sementesdotempoblog.wordpress.com

Nos vemos!!

miércoles, 27 de julio de 2016

Filosofía tradicional y pensamiento empírico

El periodo histórico que solemos denominar "Ilustración" arranca, quizá, con Isaac Newton. Sus trabajos cimientan nuestra comprensión del mundo y nos permite, por primera vez, disponer de herramientas intelectuales para explicar la mayoría de sucesos que acontecen cada día.  Es más que notable, máxime si tenemos en cuenta que Newton, en su fuero interno, creía firmemente en la alquimia y tenía una visión religiosa bastante extrema.

Por entonces, el pensamiento empírico se hacía sitio entre la práctica totalidad de pensadores. La primer característica de este casi nuevo sistema de pensamiento es la necesidad de someter cualquier hipótesis a ejercicios de prueba y refutación. Pasarían doscientos años hasta que esta simple idea, que ya había sido experimentada con anterioridad, se extendiese lo suficiente para proporcionar mecanismos para poder evaluar hipótesis que no podrían ser medibles directamente. En la física moderna con frecuencia en lugar de probar o refutar los hechos sujetos a estudio, lo que se hece es probar o refutar todos los corolarios disponibles.

El pensamiento empírico se ha adueñado de todas las esferas de conocimiento, pero lamentablemente muchas capas de la sociedad permanecen perennes a él. Encontrar ejemplos de esto es sencillo: transgénicos, vacunas, homeopatía... Sin embargo, también puede utilizarse en las quizá mal llamadas ciencias sociales, no tanto por la inaplicabilidad de las herramientas científicas, sino precisamente por la ausencia de su uso para explicar los fenómenos sociales.

Un ejemplo trivial resultado de una reciente discusión a propósito del terrorismo islamista: escribe La Voz de Galicia que Alemania, que ha sufrido en una semana varios atentados de diferente índole con el resultado de 12 muertos, "ha sufrido su semana más trágica desde la posguerra". Uno que es así, acude a Google y pregunta el número de asesinatos en ese país, y obtiene 734 para 2014. Como quiera que 12/7 es menor que 734/365, es más que poco probable que esta semana sea la de más muertos por asesinato. Y peor aun, en los últimos 20 años, la mayoría de ellos se ha superado esa cifra. Así que el texto de la noticia es evidentemente falso, lo que no evita que sea probable que en Alemania tengan cierta alarma por estos atentados.

Otro debate en el que raramente se utiliza el pensamiento empírico es el que utilizan muchos xenófobos para criticar la inmigración. Si, la célebre afirmación de que los inmigrantes reducen salarios y aumentan el paro de los "nativos". Se escucha mucho este mantra, pero rara vez se aporta datos que lo sustenten. Y eso que sea sencillo apreciar que los países con fuertes convenios e inspección laboral puedan incluso aumentar rentas y empleabilidad gracias a esta nueva mano de obra.

Otras veces lo que nos presentan es información incompleta, en forma de "medias verdades". Un ejemplo es la célebre tasa de autónomos, donde nos muestran como "milagrosamente" en algunos países por cuatro duros uno puede pagar su cotización social. En uno de ellos incluso se pone un porcentaje para un país que es temporal y mayor que el que se pagaría en España para el mismo caso.

En un blog que suelo leer y recomendar, https://nomejodasquemeincomodas.wordpress.com/ , es frecuente ver refutaciones de afirmaciones similares de estos y otros temas. A veces utiliza fuentes de datos correctas y accesibles, pero en otras son breves búsquedas en motores como Google.

En estos meses de 2016 los temas más célebres en España son las elecciones y la formación de gobierno, por un lado, y la supuesta proliferación del terrorismo por otro. Respecto a este último tema he mencionado antes el ejemplo en La Voz de Galicia. Bien, de forma más general, el terrorismo musulmán no está aportando, en Europa, cifras de víctimas siquiera comparables a las que eran frecuentes en Europa hace 20 años. La constante aparición de estos sucesos en la televisión y otros medios de comunicación hacen que se de por supuesto que estamos atravesando un periodo histórico muy duro, y nadie se plantea si los datos reales demuestran esta información.

Las formas que reviste el sistema de pensamiento "tradicional" son tan variadas como erróneas. Por ejemplo, la necesidad de elegir entre una u otra opción, descartando opciones intermedias. Otras veces nos encontramos medias verdades que descartan deliberadamente la parte omitida. Con frecuencia, se trata simplemente de simples falacias.

Por ejemplo, la comparación entre el catolicismo/cristianismo con el islamismo. Sabemos que las dos religiones son en realidad forks del judaísmo y que comparten los sistemas de ley básicos. Sin embargo con frecuenca vemos que se opone una contra otra como si hubiese diferencias significativas, confundiendo el hecho de que en gran parte de Occidente imperen sistemas laicos con la esencia de la religión cristiana. ¿Que en España asesinamos a una mujer a la semana? ¿que violamos una cada 8 horas? Sin embargo, al parecer, en nuestra cultura no hay nada que esté mal, sólo en la de los integristas estos...

Naturalmente, hay muchos ejemplos, pero sería imposible tratarlos en este artículo. Es difícil leer un artículo -ni siquiera ya de opinión- de prensa o ver una noticia de noticiario que no contenga múltiples ejemplos de esto. Si queréis reíros, al próximo que os utilice un argumento como los aludidos, preguntadle ¿y eso según quién? o ¿tienes datos que apoyen tu argumento?

miércoles, 6 de abril de 2016

La seguridad en el conocimiento: puertos y protocolos

En anteriores entradas he dicho que Internet no provee seguridad en ninguno de sus aspectos y que son herramientas añadidas las que proporcionan la seguridad que se requiera. Y que lo mismo rige para Unix y sus derivados. Pero esto puede aplicarse a todo aquello que forma parte de Internet.
Un sistema informático sólo puede llegar a ser razonablemente seguro si no está conectado a Internet.
En general solemos ver Internet como un sistema de transmisión de información a través de las webs. Puedes acceder a otras webs pulsando enlaces o localizar información concreta usando buscadores como Google, Bing y Yahoo. Pero a poco que pienses, encontrarás otro sistema para compartir información en Internet que no es la web: el correo electrónico, por mucho que una forma bastante popular de acceder a los mismos sea a través de una aplicación... en una página web.

También están los sistemas de mensajería instantánea como el popular Whatsapp, que es una forma de comunicación exclusivamente a través de smartphones pero que usa Internet igualmente.

En realidad hay un puñado de servicios que están disponibles a través de Internet: recordemos, Internet es simplemente un sistema que permite conectar redes heterogéneas, incluyendo, por supuesto, los servicios que ofrezcan dichas redes.

Dejemos claras algunas ideas, si es posible: un protocolo es, a grandes rasgos, una descripción estándar de cómo se realiza un tipo de comunicación determinado, principalmente desde el punto de vista del sistema operativo; por su parte, un puerto es una definición técnica del sistema operativo que asocia un protocolo o servicio a una numeración. Constituyen un detalle de implementación y si bien son muy importantes, no son muy conocidos. Echa un vistazo a la entrada de la wikipedia al respecto; y un servicio es una aplicación que utiliza un protocolo determinado para intercambiar información.

Un aspecto de la comunicación por Internet es que siempre se explica que la dirección de las máquinas es un conjunto de enteros (p.ej. en IPv4 puedes tener una dirección como 92.68.165.210) y que unas máquinas especiales llamadas "servidores de nombres" (DNS) se encargan de hacer las traducciones oportunas desde las direcciones alfanuméricas típicas. Bien, DNS es un ejemplo de protocolo por el cual una máquina "servidora" recibe una entrada alfanumérica y la traduce a una dirección que siga el protocolo IP.

Pero ésta no es toda la historia. Una dirección de internet contiene dos partes: la dirección ip (o la alfanumérica aún sin traducir) y el número de puerto. Así: midireccion.com:80

http/https es uno de los protocolos más conocido y quizá el más famoso. Corresponde a la navegación web y sus siglas significan "HyperText Transport Portocol" (Protocolo de Transporte de HiperTexto). "Hipertexto" significa que lo que se envía no es texto simple, sino que incluye enlaces a otras direcciones web a través de enlaces (también llamados hipervínculos o hiperenlaces). http define la forma en la que una web es enviada a través de internet y la forma en la que los navegadores deben de interpretar los paquetes que va recibiendo para visualizar la web de forma correcta. Desde su punto de vista, enlazar con una web significa simplemente que al pinchar en el enlace se comience a enviar el contenido de la página web de destino del enlace.

En la comunicación http simpre hay al menos una máquina que contiene la web a consultar, denominada "servidor" y otra que es donde se efectúa la consulta denominada "cliente". Eventualmente, el servidor puede ser la misma máquina que el cliente, aunque generalmente desde un cliente accedamos a un montón de servidores que son los que contienen cada contenido concreto. Sí, los hipervínculos nos permiten acceder no sólo a otro contenido de la misma web, sino a contenido de otras web situadas en otras máquinas servidoras.

Para que una máquina pueda funcionar como servidor web necesita ejecutar una aplicación especial también llamada "servidor web". Un ejemplo muy popular de este tipo de software es Apache. Esta aplicación lo que hace básicamente es "escuchar el puerto web", hasta que recibe "una petición" que se ajuste al estándar http. Sí, Apache no sabría qué hacer si en lugar de una solicitud de una página concreta de la web que sirve recibiese un correo electrónico, y lo descartaría como una petición errónea.

"Escuchar un puerto" es una expresión técnica que significa que hay alguna aplicación en el sistema que está pendiente de que el sistema reciba algún paquete de Internet dirigido al puerto de turno. Puedes verlo como un barco que llega a un puerto y se le asigna una dársena concreta, o si llegas a un centro médico con una cita: llegas y consultas dónde está el despacho médico que te corresponde en función de tu cita.
"Escuchar un puerto" significa tener una aplicación especial que se encarga de los paquetes de Internet que se dirigen a dicho puerto.
"Una petición" es un paquete que sigue las especificaciones del protocolo correspondiente para que la aplicación servidora "sirva" su contenido. En el caso de una web, una petición podría ser algo como "envía el contenido de miweb.com/unapagina.hmlt a mi dirección de procedencia", pero escrito en un lenguaje que se ajuste a lo especificado por el protocolo http.

https es una "versión" del protocolo. Significa "HyperText Transport Protocol Secure" (Protocolo de Transporte de HiperTexto Seguro). Básicamente permite modificar la configuración del servidor web para hacer uso de certificados de autenticidad con los que cifrar la conexión y asegurarse de que las distintas peticiones y atenciones se dan entre el mismo servidor y el mismo cliente. Es decir, https lo que hace es:
  • Cifrar la conexión
  • Asegurar que la conexión que se ha establecido entre dos máquinas sigue siendo entre las mismas dos máquinas.
Hay montones de protocolos de Internet, cada uno de los cuales puede funcionar con uno o varios puertos. Por ejemplo, está imap/pop/smtp, que son protocolos para el correo electrónico.  Hay protocolos para su uso en redes privadas pero que pueden (y son) utilizarse a través de Internet, como ssh (shell seguro, un sistema de obtener un terminal remoto para conectarse a un sistema operativo a través de la red). ftp es un sistema para transmitir ficheros entre máquinas conectadas a una red, aunque lo más probable es usar alguna versión como vsftp (ftp "muy seguro", según su  propio nombre: very secure ftp). Los navegadores web están diseñados y optimizados para trabajar con el protocolo http/https, pero eso no impide que hasta no hace mucho fuera frecuente que permitiesen usar alguna forma de ftp. Esto ha caído en desuso porque los servidores web son capaces también de servir ficheros, por lo que es más fácil utilizar un servidor web para servir la web y ficheros que se quieran compartir que tener dos servidores (uno web y otro ftp).

También se han desarrollado aplicaciones capaces de ser ejecutadas por un servidor web y un simple navegador que permiten acceder a contenidos de otros protocolos. Así, puedes tener un servidor "webmail" que permite a sus usuarios gestionar su correo electrónico sin requerir aplicaciones específicas para ello (pero sí tiene que existir un servidor de correo). También puedes usar aplicaciones web que te permiten compartir ficheros en algún sistema de sincronización como Dropbox o Google Docs. Esa es la razón por la que http/https sea con diferencia el protocolo más conocido.

Y por supuesto los navegadores y los servidores web son tan listos así que, a falta de puerto, entienden que una petición al protocolo http va al puerto 80 y si es al protocolo https va al puerto 443. Por supuesto, eso pasa con todos los protocolos: una petición al servidor ssh irá al puerto 22, ftp al 21 y así. En ocasiones, es buena idea configurar algunos servidores como el de ftp en otros puertos, así que las peticiones a ftp deben llevar ese nuevo puerto. Por ejemplo, si le decimos a nuestro servidor ftp que "escuche" el puerto 40000, entonces la máquina que se conecte a nuestro servidor deberá indicar que quiere conectarse al puerto 40000. Si pide otro puerto (incluido el estándar, el 21), simplemente será ignorada porque no hay nadie "escuchando" allí.
Siempre está llegando información a las máquinas, tengan una aplicación esperándola o no.
Todo esto es muy interesante o un simple ladrillo. Lo interesante es que una máquina conectada a Internet siempre recibe lo que se le envíe, tenga o no un programa apropiado para tratarlo. Así, si tu IP pública es 80.116.112.86 y yo escribo en mi navegador escribo http://80.116.112.86, mi sistema enviará una petición a tu máquina para que me sirva el contenido web del servidor... cosa que no tienes. Lo interesante es que tu sistema recibe igualmente la petición. Es la idea que está tras eso de tener puertos "abiertos" o "cerrados". La idea es poner una aplicación que hace de intermediaria entre la comunicación exterior y el sistema operativo. Así, dicha aplicación, llamada "Cortafuegos", sólo acepta las comunicaciones que van a algún puerto abierto, desechando las demás. Otro ejemplo de seguridad "añadida" por "encima del sistema".
Cada puerto abierto en nuestro sistema lo hace más débil. 
 En la práctica, la mayoría de usuarios tenemos un router proporcionado por nuestro proveedor de Internet. Por definición, todo el tráfico entre Internet y nuestro equipo pasa por dicho router, por lo que es un buen lugar para poner un cortafuegos es justo en ese router. Si los proveedores tuviesen vergüenza los proporcionarían con los puertos cerrados siempre, de forma que si necesitamos abrir uno lo haremos nosotros mismos. Nótese que el tráfico "normal" pasa por el cortafuegos igualmente, porque lo importante para un cortafuegos es proteger los puertos que no uses del exterior, para que no puedan ser utilizados por otras personas para introducir malware en nuestro equipo: se da por supuesto que el usuario va a conectarse a otros servidores para navegar por otras páginas, y ese tráfico se permite, de la misma forma que el usuario también podría conectarse a un servidor ftp (si encuentra alguno). En la práctica, lo que se hace es permitirte recibir tráfico general de sitios a los que te conectas tú en primer lugar.

De lo dicho, especialmente en el último párrafo, se entiende rápidamente que un usuario responsable debería de usar un equipo con todos los puertos cerrados salvo lo necesario para poder conectarse a otros servicios, particularmente servidores web. Explicar cómo los puertos abiertos pueden facilitar la vida de un atacante de nuestro sistema está mucho más allá del ámbito de las cosas que escribo, pero en general un puerto abierto es una debilidad, pero un puerto abierto sin uso es un problema de seguridad importante.

miércoles, 30 de marzo de 2016

La Seguridad en la tradición: el surgimiento del ordenador personal

Yo no lo llamo "ordenador personal", que es un neologismo para no utilizar la traducción directa del anglosajón. No sé realmente por qué después les tenemos tanta inquina a los franceses... Bien, en mis artículos verás siempre "computador personal".

Hemos hablado de las estaciones Unix en el artículo anterior y también en otros artículos. Básicamente, existía un gran computador o mainframe al que se conectaban otros equipos clientes o terminales, bien en la propia red de la organización o bien a través de Internet. Podías tener tu cuenta Unix del trabajo o bien contratar una para casa.

Hubo varios experimentos para tratar de desarrollar un computador que pudiera ser utilizado de forma aislada por una sola persona. El más exitoso fue el computador personal de IBM con su sistema operativo MS-DOS, desarrollado, como su nombre nos indica, por Microsoft. Y "Personal Computer" era el nombre que IBM le iba a dar a su criatura, con hardware IBM, procesador de Intel 8086 y sistema operativo MS-DOS.

Dicen las malas lenguas que los dispositivos "compatibles" surgieron porque a alguien se le ocurrió que si el sistema de IBM identificaba los dispositivos IBM porque ponía IBM y PC en el software del dispositivo, la frase "IBM/PC", ellos podían poner "IBM/PC compatible" sin saltarse ninguna ley y así garantizar que el dispositivo funcionase aun sin haber sido fabricado por IBM. Como quiera que fuese, lo cierto es que pronton empezaron a surgir fabricantes de dispositivos compatibles de todo tipo, incluso microprocesadores. Pongamos esto en contraste con la plataforma Apple de esa época, que sí utilizaba hardware fabricado o licenciado por ellos mismos. El efecto es que los PC se hicieron cada vez más populares, hasta hoy en día que son la base de los propios computadores de Apple. Y vemos que haya sido o no así, la existencia de la compatibilidad no fue una característica deseada por IBM, sino algo que sucedió sin su permiso: como error, no está mal...

El Personal Computer, como hemos dicho, estaba pensado para la utilización por su propietario o su familia. Eligieron MS-DOS por muchos motivos y la culpa de la desdicha universal no viene de ese día. Bueno, sí, fue la peor elección de la Humanidad desde... no sé, no se me ocurre una elección tan malhadada.
El Computador Personal estaba pensado para la utilización por su propietario o su familia.
Un PC con MS-DOS se encendía pulsando el botón de encendido, hasta que te aparecía el intérprete de comandos o shell de MS-DOS. En ese intérprete de comandos tú puedes hacer eso, escribir comandos para que el intérprete los ejecute de forma adecuada. Existen varios tipos de ficheros: ejecutables, regulares y otros especiales. Entre los primeros, los programas y los ficheros que contienen listas de comandos para ser ejecutados en sucesión. Entre los segundos, los ficheros de texto o de aplicaciones concretas, como un fichero para WordStar (aun no existía Word). Más tarde a MS-DOS se le añadió una interfaz gráfica al estilo Mac (que no deja de ser un tipo de computador personal), denominada Windows, que años después absorbió al propio MS-DOS y ahora es un sistema operativo completo.

Esto es importante. En los terminales Unix tú te conectabas con otro equipo que realmente era donde se ejecutaban tus aplicaciones y donde en general tendrías tus ficheros. Los PC y las plataformas del mismo tipo como la de Apple (Mac) comenzaron siendo sistemas aislados por diseño. Unix favorecía compartir información y eso dificulta asegurar dicha información; los PC y similares ni siquiera tenían el concepto de acceso a la información por otra persona, o acceso al equipo desde otro equipo.

Tanto PC como Mac tardaron años en incorporar un sistema de red. Para ello se aprovecharon del trabajo para desarrollar un sistema Unix de tipo BSD llamado FreeBSD. Este proyecto es software libre, con una licencia que permite que quien modifique un código pueda cambiar la licencia de dicho código mientras mantenga la autoría. Así que tanto Apple como Microsoft adaptaron el sistema de red de FreeBSD para sus sistemas. Más adelante, Mac cambió todo sus sistema por uno basado en un proyecto (Darwin) a su vez basado en FreeBSD. Eso le permitió adoptar un sistema no limitado a una sola plataforma hardware y características como la red y la gestión multiusuario. Por su parte, Microsoft fue añadiendo estas características a medida "que pudo".
Unix favorecía compartir información y eso dificulta asegurar dicha información; los PC y Mac ni siquiera tenían el concepto de acceso a la información por otra persona, o acceso al equipo desde otro equipo.
Así, realmente no hace mucho que los sistemas Windows y Mac se han tenido que comenzar a preocupar por la seguridad o privacidad de nuestros ficheros. De hecho, hoy en día ambos utilizan información recogida de nuestros equipos para beneficiarse, y si empleas sus servidores de cuentas, pueden proporcionarle a los servicios de inteligencia la información personal tuya que les requieran. Pero lo más importante es que en sus diseños originales nunca han tenido que preocuparse por las cuestiones a las que nos lleva la seguridad informática. Y por supuesto, nada en el hardware se preocupa. La única preocupación de los desarrolladore de dispositivos es la compatibilidad con la plataforma de turno.

Aunque las cosas cambian hoy en día, si bien es difícil de saber si para mejor o para peor desde el punto de vista del usuario. Por ejemplo, hace pocos años Intel comenzó a desarrollar un sistema de encriptación por hardware. Esto es importante en los computadores modernos porque generar datos o claves completamente aleatorias no es fácil, así que un dispositivo que genere información arbitraria el principio pareció un gran avance en la privacidad. Pero Intel tiene acuerdo, como tantas otras empresas, con la NSA y otras organizaciones de USA. Y como el software que maneja ese dispositivo es secreto, no puedes garantizar que dicho dispositivo no proporcione una especie de puerta de atrás a la NSA o al FBI.

Y es que las plataformas de computadores personales si hacen una cosa bien es proteger la información de las propias plataformas, para que al usuario le cueste identificar siquiera el hecho de ser susceptible de espionaje. Y no es que no nos fiemos de las organizaciones de USA. Porque podría ser un extrabajador, o podría ser un tercero que encuentra un fallo por sí mismo. No hay garantía de que lo que examine el FBI se quede en las oficinas del FBI.

Podríamos añadir la necesidad de un buen antivirus en la plataforma Windows y un buen puñado más de cuestiones. No obstante, aun sin tener eso en cuenta podemos estar seguros de que los computadores personales nunca estuvieron diseñados para ser seguros.


sábado, 26 de marzo de 2016

La Seguridad en el origen: Unix e Internet

El tema de fondo en éste y otros artículos es la seguridad informática y de ahí el título cuando se desarrolla un texto que pretende comentar unos cuantos aspectos muy importantes para entender la cuestión: cómo fueron las cosas al principio. Pero un título más correcto para el contenido de este artículo debería de ser: "La Inseguridad en el origen: Unix e Internet"

La historia de Internet comienza en los años 70 y he hablado de ella en unos cuantos artículos. La historia de Unix está fuertemente entrelazada con la de Internet, al punto de que podrías pensar que durante décadas Internet ha sido la forma de conectar sistemas Unix y no estarías muy lejos de la idea.

Lo más importante es tener en cuenta que tanto Unix como Internet se desarrollaron bajo la tutela de universitarios más o menos organizados. Fueron ellos los que decidieron usar el protocolo TCP/IP para las conectar redes completas entre sí, en lugar de utilizar algún sistema "punto a punto" como el telefónico tradicional. Por su parte, Unix en su primera encarnación no incluía Internet, pero desde la segunda versión ya incluía el protocolo de comunicaciones en su propio núcleo.

No siempre es fácil valorar la importancia de ese origen: la inmensa mayoría de usuarios han conocido y utilizado internet en los últimos 20 o 25 años, y una mayoría abrumadora de éstos lo han hecho desde una computadora de escritorio doméstica, y con casi total certeza utilizando el sistema operativo Windows. Nada que ver con el investigador universitario de San Francisco que compartía su investigación con otro investigador canadiense y que intercambiaba correspondencia (electrónica) con otros investigadores europeos.

Empecemos por Unix es un sistema multiusuario. Eso significa que un montón de usuarios diferentes pueden utilizar el sistema de forma simultánea. Nuestro investigador de San Francisco probablemente compartiría el equipo de su departamento, o con menos suerte, o de varios departamientos, con otra decena de usuarios o más. El investigador canadiense estaría en una situación similar, al igual que los europeos. Al principio Unix no incorporaba cuentas de usuario: uno se conectaba, usaba el sistema para lo que fuese, se desconectaba y listo. Hay varias razones generales para añadir un sistema de control de quien se conecta, todas ellas fundamentalmente económicas: una puede ser asegurarse de que el sistema lo utilizan aquellos para quienes está destinado realmente el sistema, lo que garantiza su eficiencia y disponibilidad; otra más evidente es el cobrar por cada cuenta de usuario, que de hecho fue el modo general de negocio de las distintas empresas que proporcionaban sistemas Unix.

Sin embargo, ni la privacidad ni la seguridad aparecen remotamente. Contaba Stallman en alguna entrevista que cuando en su universidad se comenzó a incorporar el sistema de cuentas de usuario, ellos se dedicaban a obtener dichas claves, a enviársela a sus dueños en un correo tal que así: "tienes una cuenta en el sistema Unix con la clave laquesea. Esa clave es un rollo, ¿por qué no haces como nosotros y utilizas en su lugar secreto, que es más fácil de recordar?" Y es que pese a las políticas de las empresas que proporcionaban acceso a servidores Unix, el sistema operativo en sí estaba pensado para facilitar el trabajo en grupo y la colaboración. Es cierto, la seguridad, tal y como la entendemos hoy, nunca estuvo entre los principios de diseño de Unix. Unix era seguro en otro sentido: fiable, robusto, accesible.

Es interesante que 40 años después Linus Tolvards siga los mismos principios para su núcleo Linux. Según él, la seguridad debe de proveerse con herramientas específicas para el grado de seguridad requerido, y debe de estar fuera de la política general de desarrollo del núcleo del sistema operativo. Es uno (más) de los debates más interesantes alrededor del desarrollo de Linux. Las empresas que distribuyen el sistema para su uso empresarial están interesadas en garantizarle la seguridad a sus usuarios, y por ello consideran que los informes de fallos de seguridad deben de atenderse con más inmediatez que otros errores. Para Tolvards, en cambio, los errores de seguridad no dejan de ser errores a subsanar como los demás y, por tanto, no requieren de ningún trato privilegiado. Una vez le argumentaron qué pasaría si "una central nuclear que utilizase un sistema Linux y que estuviese conectada a Internet pudiese tener un fallo de seguridad aprovechable por un terrorista", a lo que Tolvards replicó preguntando quien, en su sano juicio, podía conectar una máquina tan sensible "con Internet".

El desarrollo del protocolo de comunicaciones de Internet, TCP/IP, estuvo marcado por principios similares a los que inspiraron Unix. En este caso, el protocolo pretendía ser una forma sencilla y eficaz de conectar redes de computadores, pero no muy eficiente. Veamos: tú tomas el fichero que quieres enviar por Internet y lo divides en trocitos muy pequeños que llamas "paquetes". A cada paquete le añades la dirección de envío, y la información básica para reconstruir todo el fichero en el destino. Aunque es un aproximación burda, imaginemos que lo que haces es numerarla (y añadir algún código para saber que son parte del mismo fichero). Coges todos los paquetes y los envías a tu pasarela de Internet, quien a su vez los envía a la pasarela más próxima, y así sucesivamente, hasta que llegan a destino, la máquina que los recibe es capaz de reconocerlos (lee el código de identificación y el número de orden en el fichero) y reconstruye la copia del fichero original.

¿Cómo se encaminan los mensajes hasta que llegan a su destino? bien, lo que haces es: compruebas si es para ti, o si tienes que reenviarlo; y si lo reenvías, lo haces a la máquina más próxima. La máquina más próxima, por su parte, la conoces porque en tu tiempo libre te dedicas a comprobar cuáles son las máquinas más próximas y elaboras una lista. Así, cuando encaminas un mensaje, digamos que lo mandas sin preguntar: si por cualquier razón la máquina no lo recibe, lo mandas a otra máquina. ¿Cómo sabes que la otra máquina no lo ha recibido? pues con un acuse de recibo; si transcurrido un tiempo determinado no te ha mandado el acuse, asumes que no lo ha recibido.

Bien, esto se hace con todos los mensajes a la vez. Eventualmente, puede suceder que una máquina encamine unos mensajes por una pasarela y otros mensajes (recuerda: son partes del mismo fichero) por otra, por mucho que lo usual es que si el primer mensaje va por una lo habitual es que todos vayan por la misma. Lo importante es que puede suceder. Incluso puede suceder es que la pasarela haya enviado un mensaje pero se haya recibido tarde su acuse de recibo, por lo que ya se habrá mandado una copia por otra pasarela diferente, de forma que la destinataria recibirá dos copias del mismo mensaje. Fijaos: en cada pasarela se mantiene una copia de todos los mensajes que forman nuestro fichero, al menos el tiempo suficiente para garantizar que se han enviado todos a la siguiente pasarela.

Bien, TCP/IP no incorpora ninguna medida de seguridad: está diseñado para ser simple y eficiente, como se ha dicho antes, pero no para ser seguro en su acepción moderna. Sus impulsores pretendían comunicarse, no poner trabas a dicha comunicación.

Uno de los primeros problemas es que la máquina destino tiene la información necesaria para reconstruir el fichero, pero no para saber con seguridad quién lo ha emitido. Tampoco tiene información que garantice que nadie haya interceptado la comunicación, y tampoco ofrece mecanismos útiles para garantizar que nadie ha alterado el fichero original. Al igual que en el caso de Unix o de Linux comentado antes, estas limitaciones se solventan con herramientas externas al protocolo de comunicaciones. Por ejemplo, SSL garantiza que una vez que te estás comunicando con una máquina, toda la comunicación tiene lugar con ésa máquina y no otra. TLS, además, lo que hace es encriptar la clave que permite usar SSL, ya que si alguien obtuviese la clave que requiere SSL para crear la conexión, podría suplantarte en otro momento.

Cuando pienses en la seguridad informática, recuerda: las cosas se inventaron para facilitarnos el compartir nuestras cosas. Así que poner restricciones a qué queremos compartir y con quién es, en cierta forma, actuar contra los principios de nuestros sistemas de telecomunicaciones. No esperes que el sistema te proteja en los tiempos que corren.

lunes, 14 de marzo de 2016

Una de espías!!

Vuelve el interés por la Seguridad Informática, en este caso tras la entrevista a Edward Snowden por parte de los medios de comunicación La 6 (para su programa El Objetivo) y eldiario.es.

La Seguridad Informática es un tema terriblemente complejo y muy difícil de explicar si no se poseen buenos cimientos técnicos. Se requieren estudios (formales o informales) y muchas prácticas para comprender someramente lo más básico y principal. Además, es uno de los negocios más rentables por sí mismos. Un buen analista de seguridad puede cobrar en un día lo que otros técnicos cobran en un año. Incluso técnicos del sector informático.

Así que es un tema de interés general muy difícil de enfocar para el público general. La mayoría de información que podemos encontrar en la Red al respecto es errónea cuando no deliberadamente falsa, publicada normalmente con el único objetivo de generar tráfico y publicidad gracias a la curiosidad de los usuarios. La entrevista a Snowden no está exenta de un buen montón de incoherencias, producto bien de la necesidad de adaptar la entrevista para el público que la verá o bien porque Snowden da por sentado que sus interlocutores tienen conocimientos que no es posible que posean.

Un caso interesante para ilustrar esto es la mención de la entrevistadora Ana Pastor al caso de Apple contra el FBI que se está dirimiento actualmente en USA. En dicho caso, un juez atiende la petición del FBI y le exige a Apple que proporcione acceso al dispositivo de su marca propiedad de un acusado de terrorismo. La primera incongruencia es que Snowden menciona bastantes veces que permitir o no el espionaje masivo debería de ser una opción de los ciudadanos, y también hace mención en diferentes ocasiones a la necesidad de Leyes y de control judicial.

Bien, en el caso de Apple vs FBI, lo cierto es que hay control judicial. La ley invocada puede ser más o menos justa y los partidarios de la privacidad pueden tener más o menos razón. Pero Snowden invierte mucho tiempo en justificar que esto sea posible -además, no es un caso de espionaje masivo, ya que sólo se trata de un dispositivo concreto, por lo que desde ese punto de vista debería de estar justificado: las leyes en USA pueden ser todo lo malas que quieras e influidas por los lobbies que sean, pero al final se aprueban en un Congreso elegido por los ciudadanos. También es cierto que Apple esgrime argumentos para negarse, y podemos opinar sobre ellos: pero el punto de vista sigue siendo el mismo: este caso tiene control judicial y afecta a un solo usuario.

Snowden elude esta cuestión y comienza afirmando que "algunas compañías jóvenes, como Apple, pueden querer proporcionar más privacidad a sus usuarios (...)" para luego explicar mal en qué consiste tal privacidad. Pero el historial de esta "joven compañía" está muy lejos de una compañía que se rebela contra el sistema para defender la privacidad de sus usuarios, tema que sólo es de su interés desde que un buen montón de celebridades encontaron fotografías "íntimas" suyas compartidas en Internet. Después lo explica mal: Apple no cifra ni puede cifrar las comunicaciones, al menos no de forma diferente a lo que hacen otras empresas como Microsof. Digamos simplemente que el sistema de mensajería de Apple no es Telegram ni otros sitemas más avanzados. De hecho, eso no es relevante en el caso mencionado por Ana Pastor, donde claramente el FBI lo que quiere es acceso al contenido del dispositivo, no a sus comunicaciones.

También se hacen referencias a los "metadatos", que es un nombre ampuloso para referirse a información asociada a un fichero determinado. Snowden utiliza una analogía con una fotografía que no es muy útil para entender el concepto del tratamiento de metadatos. Lo que Snowden menciona realmente son "etiquetas" que pueden o no ser metadatos o pueden ser parte del fichero. Pero los metadatos incluyen a las etiquetas de igual forma que incluyen al contenido del fichero: nadie es tonto, y mejor leer el correo que tratar de adivinar de qué va, y lo mismo para las etiquetas: tienes que poder leerlas en algún lado y ni siquiera tienen por qué existir. Eso podemos verlo si trasladamos nuestras fotos al computador: dependiendo del programa utilizado, incluso de la cámara utilizada, pueden existir o no. Y pueden estar o no acompañados de otras etiquetas, como nombres comunes y propios -lugares, motivos, quienes aparecen en ellas... Pero hay metadatos que siempre existen: la hora de creación del fichero, por ejemplo -en el caso de la foto, la hora en nuestro computador no tiene por qué coincidir con la hora en la que se hizo la foto. En el caso de un correo electrónico, la dirección de envío, de recepción, el asunto, si hay anexos, y un buen puñado de cosas.

Otro aspecto interesante de los metadatos -a diferencia de las etiquetas aludidas por Snowden- es que por sí mismos no tienen ningún valor: los metadatos se convierten en información al ser relacionados con otros metadatos. En el ejemplo de la llamada al ex a las 2 de la mañana, la llamada en sí no tiene mucho valor; incluso que después se encuentren en el mismo hotel puede ser sospechoso pero no más que una coincidencia. Sin embargo, la unión de ambos datos nos proporciona prácticamente una evidencia.

Es algo similar al uso que hace la Agencia Tributaria de Facebook. Bien, que tú poses con tu flamante deportivo no es muy importante para ellos. Pero si pones varios contenidos que den una idea de nivel de vida muy alto, a la par que tienen una declaración tuya en la que figuras como un pobre obrero, bien, digamos que pasas a ser alguien "interesante". Y si una empresa "dudosa" te tiene en sus ficheros, vamos, que más pronto que tarde te va a aparecer un inspector a preguntarte "un par de cosillas".

En mi opinión, el contexto es muy importante para comprender cualquier información. Esto sirve también para los metadatos, que proporcionan un contexto incluso cuando se carece de la información a contextualizar. Siguiendo el ejemplo de Facebook, la empresa no tiene forma de saber que te entusiasma un tipo de coche y que tienes intención de invertir una cantidad de dinero en él. Sólo sabe que 9 de cada 10 enlaces externos que consultas tiene que ver con coches deportivos, y se supone que tal interés es por algo. Incluso si después eres un simple técnico que le gusta estar al tanto de qué coches hay en el mercado, aun así siempre puedes recomendar determinados modelos a determinados clientes. Esto no es muy diferente a que Facebook te haga una encuesta sobre si te gustan los coches y por qué, con la diferencia de que en la encuesta te puedes negar a responder o incluso mentir, mientras que el interés.. vamos, que no consultas esas páginas para que Facebook tenga una imagen errónea de ti.


Un tema diferente es que no tiene tanta utilidad pinchar un cable interoceánico si lo que vas a buscar son los metadatos de las comunicaciones. Al fin y al cabo, las leyes europeas y americanas obligan a los proveedores de acceso a internet a almacenarlos, así que sólo es cuestión de pedírselos o robárselos. En mi opinión, si pinchas un cable es para espiar el contenido de las comunicaciones, aun cuando sea buscando comunicaciones que contengan palabras clave, por ejemplo, o al menos saber cuáles están cifradas. En los casos elegidos, podrías guardar sus contenidos a la espera de que se manifiesten de utilidad. Aquí hay que añadir la participación de las empresas como Facebook, Twitter o Google. Bien, ellos no proporcionan cifrado en las comunicaciones, así que pueden proporcionar tus contenidos al FBI sin problema alguno. Es mucho más sencillo que procesar millones de comunicaciones: básicamente, le dices a otra empresa que haga ella ese proceso.

El contexto también es importante para comprender esto de la Seguridad Informática. Decía Hawkins en su popular obra "Breve Historia del Tiempo" (Hawkins, 1988) que su editor le decía que con cada ecuación perdería la mitad de lectores, pero que tenía que poner al menos la popular E=mc², y que si con eso perdía una mitad... pues ¡qué se le iba a hacer! En el caso de la Seguridad Informática es similar. Puede (y debe) explicarse con muy pocos tecnicismos para sea más accesible. Pero es inevitable tener que comprender un puñado de cosas. En mi opinión, para entender la cuestión deberían tratarse varios aspectos.

El origen de Unix e Internet
El origen de la computadora personal
Qué son los protocolos y puertos informáticos.

Sólo así podremos comenzar a entender la complejidad de una cuestión que a este ritmo en pocos años puede monopolizar nuestras vidas.

Pdata: en el texto no hay un sólo enlace y sólo una referencia a un libro que no tiene que ver con el texto. Bien, si todo el mundo puede publicar así y ser líder de opinión, ¿para qué voy a invertir yo el tiempo? todo lo dicho puede encontrarse en diversas fuentes secundarias, comenzando por la popular Wikipedia ;)

miércoles, 17 de septiembre de 2014

mini-manual de instalación: Arch

En esta ocasión nos tomaremos un respiro de tanto tratar la instalación de GNU/Linux en abstracto, y para ello nada mejor que una prueba concreta. Arrancaremos Arch en una máquina virtual y realizaremos una instalación sencilla. Esto surge porque algunos usuarios de ForoSUSE han manifestado encontrar difícil esta instalación que, como vemos, realmente es tan sencilla como cabe esperar.

Repasemos lo que hemos aprendido hasta ahora y lo que vamos a aprender más tarde. Para instalar un sistema operativo cualquiera, en primer lugar necesitamos el medio, y el dispositivo en el que vamos a instalar. Para ello, el medio lo obtendremos en cualquiera de los enlaces de descarga que se proporciona en la web de Arch; En cuanto al dispositivo de instalación, será un disco duro virtual.

Una vez que tenemos qué instalar y dónde instalarlo, podemos comenzar la instalación. Básicamente, se crea la estructura de directorios apropiada para organizar las cosas, se copia el núcleo, las utilidades de sistema (con una configuración básica) y el software elegido por el usuario. En general, la mayor parte de este proceso es más o menos automático; además, la mayoría de distribuciones GNU/Linux incluyen una selección de software determinada.

Arch es un sistema operativo con filosofía KISS. La interpretación que ellos hacen a algunos puede sonarles un poco extrema. Su instalación consiste en iniciar un sistema de arranque más o menos básico con un terminal de comandos, desde el que se va preparando el sistema paso a paso: creas, formateas y montas las particiones, instalas el sistema básico y a partir de ahí según las necesidades del usuario.

Para seguir todos estos pasos, lo que he hecho es acceder a la documentación en español sobre el tema. Ahí nos va diciendo los pasos a ejecutar y nos enlaza con documentación complementaria para cada parte de la instalación. Dicho esto, en el blog desdelinux tienen una guía lo suficientemente detallada para realizar una instalación sencilla. Había pensado ilustrar esto con mis propias capturas, pero las de esta guía están bastante bien.


En el blog, una vez definidas las particiones, comienzan por instalar el sistema básico, al que añaden NetworkManager y grub-bios. El primero no tiene mucho que comentar: es un grupo con el núcleo, el script que carga el sistema y todas las utilidades que constituyen el sistema operativo en sí; el segundo es el gestor de redes moderno, NetworkManager (que es el que manejamos con el applet de escritorio); instalarlo en este momento, nos simplifica todo lo demás. El tercero es el cargador de arranque para sistemas con BIOS tradicional. Para BIOS modernas, es decir, UEFI, véase grub-efi, aunque el procedimiento será igual.


En esta instalación se utiliza el mismo perfil para el usuario administrador que para el usuario normal, salvo la contraseña que puede ser o no distinta. Sin embargo, es posible definir perfiles distintos, particularmente si se utiliza un escritorio gráfico.

Arch no presupone nada. Los grupos de paquetes pueden tener las dependencias que sean, pero por defecto se instalarán unas y otras, sin más. Por ejemplo, si quieres Firefox tendrás que instalarlo explícitamente. También cualquier servicio adicional que quieras utilizar deberás hacerlo arrancar explícitamente. La filosofía KISS consisten principalmente en eso: tú eliges qué quieres usar. Naturalmente, el reto está en saber qué quieres utilizar, o dicho de otra forma, qué es lo que necesitas para hacer qué cosas.


No hay mucho que comentar de la instalación en sí. En mi caso, he tenido que ajustar la selección de tarjeta gráfica, ya que utilizo una máquina virtual. Para no complicarme, utilizo VMVGA y para ella cargo el driver VESA. Sin complicaciones, ya que mi propósito es probar la instalación. Naturalmente, en su caso hay que utilizar el driver apropiado.

Una curiosidad: al menos en la descripción de la instalación de KDE, concluye activando el arranque de KDM, pero sin embargo indica que se reinicie el sistema. ¿Para qué? Basta con iniciar KDM, o bien el target gráfico: sudo systemctl start kdm

Es importante hacer las cosas con calma y en orden. Resumamos:
  1. Activamos el teclado español
  2. Creamos y formateamos las particiones. Si tenemos BIOS normal, podemos usar fdisk o cfdisk, por ejemplo; para EFI, podemos usar gdisk.
  3. Instalamos el sistema básico, el gestor de redes y el cargador de arranque. Naturalmente, si disponemos del gestor de arranque de otra distribución no tenemos por qué añadir otro. Fijaos que en el blog recomiendan añadir ya en este momento el soporte para el touchpad si estamos con un portátil
  4. Generar /etc/fstab, el fichero que define qué particiones contiene el sistema y cómo y dónde se montan.
  5. chroot para comenzar a utilizar el las herramientas del sistema instalado.
  6. Nombre del equipo.
  7. Localización: idioma, idioma del teclado.
  8. Configuración del arranque (si se ha instalado ;) ).
  9. Contraseña de root
  10. Reinicio para iniciar el nuevo sistema.
Hasta aquí tenemos un sistema básico. Lo siguiente es configurar un usuario. También podemos, por ejemplo, poner un sistema gráfico.
  1. Activar NetworkManager y configurarlo para que se arranque al inicio.
  2. Crear usuario y contraseña.
  3. Asegurarse de que el usuario puede utilizar sudo (instalar sudo si no se ha hecho aún: pacman -S sudo)
  4. Instalar X
  5. Instalar el driver de nuestra gráfica.
  6. En este punto, en el blog prueban el sistema gráfico instalando un sistema mínimo. Si estamos seguros de nuestro driver, podemos obviar esto e instalar el sistema gráfico que queramos directamente. En mi caso, instalé KDE siguiendo también la guía al efecto.
Para el caso de KDE:
  1. Instalamos el metapaquete o patrón para KDE, kde-meta. Cuando pregunta, seleccionamos "todos", que es la selección por defecto.
  2. Instalamos el idioma español, el plasmoide para NetworkManager y la aplicación para instalar paquetes.
  3. Activamos y arrancamos el gestor de sesiones gráficas, KDM.
No he añadido más capturas porque la guía lo documenta bastante bien. Solo añado el resultado de la instalación de KDE.