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, por ejemplo, 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 surje 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.

jueves, 4 de septiembre de 2014

Camino a Linux: o de cómo diantres meto yo eso en el computador iv: medios arrancables

No tiene mucho sentido hacer una entrada en el blog simplemente para contar cómo se hace un DVD o un live-USB para probar o instalar cualquier distribución de GNU/Linux. Es algo lo suficientemente habitual para que sea fácil encontrar guías muy bien hechas sobre el proceso. En todo caso, en lo que sigue se verán algunos detalles a tener en cuenta.
"En esto, como en todo en Linux, prefiere siempre la información referida a tu distribución en concreto, sea cual sea"

Por ejemplo, para openSUSE podemos encontrar un buen artículo en su propia wiki respecto a la instalación desde pendriveSDB:Live_USB_stick Un artículo creado en su momento por los usuarios Xiscoj y Arag92 y mantenida al día por el usuario jcsl, como casi toda esa wiki.
openSUSE dispone de su propia herramienta para crear pendrives autoarrancables, llamada SUSEStudio Imagewriter. Es una gran herramienta para imágenes ISO creadas con su sistema En SUSEStudio, y por ende es muy fácil que no funcione con otros tipos de imágenes. Los "mortales" usan Unetbootin, que además es capaz de descargar la imagen a colocar en el pendrive. Y no sólo eso, hay un buen puñado de programas dedicados a esta tarea.

Reglas Básicas

  1. Si no tienes grabadora, comprueba que la distribución a instalar puede ser instalada desde un pendrive. Aunque es relativamente sencillo crear un pendrive que arranque cualquier imagen de un DVD que a su vez sea arrancable, lo cierto es que si la distribución proporciona soporte a ese tipo de instalación la vida será más sencilla.
  2. Busca un buen origen para conseguir la imagen de tu distribución. La imagen de la que hablamos siempre es un tipo de fichero especial, con extensión .iso, que contiene no sólo el contenido del DVD de instalación de turno, sino que está grabado de tal forma que puede volver a grabarse en un DVD de forma exacta. Por eso se le llama imagen: porque es una copia exacta desde la que es posible reconstruir el original.
  3. Puedes comprobar si tu distribución está disponible en varios lugares distintos, llamados  espejos (o más habitualmente, en inglés mirrors). A veces es más rápido descargar desde un lugar que desde otro. Puedes, por ejemplo, tratar de descargar del que esté más próximo a tu casa. De todas formas, la lista de mirrors siempre estará en la web de la distribución, no la descargues de otros lugares de los que los reponsables de tu distribución no sepan nada.
  4. Una vez guardada la imagen.iso en tu disco duro, comprueba que está bien. Para eso hay varios medios, aunque el más popular es comprobar la suma md5. Por ejemplo, en http://download.opensuse.org/distribution/13.1/iso/ se guardan las imágenes de los distintos medios de instalación de openSUSE: DVD, DVD-live, red... Para cada uno de ellos hay varios archivos: el .torrent es para realizar la descarga con un cliente torrent; los demás, para comprobar que el contenido del fichero descargado es correcto. Si intentas grabar, por ejemplo,  openSUSE-13.1-DVD-x86_64.iso en un DVD con la aplicación k3b, ésta, en primer lugar, calculará la suma md5 que corresponde a ese fichero, que se guarda en el fichero openSUSE-13.1-DVD-x86_64.iso.md5. Si todo está bien, podrás grabarlo; si no coincidiese, pues es que ha habido una alteración en el fichero tanto antes de descargarlo o bien al descargarlo. En ese caso, no deberías utilizarlo, ya que dará problemas de algún tipo (software malicioso, simples errores...).
  5. Si estás grabando un pendrive, sigue atentamente las instrucciones que disponga la web de la distribución.
  6. Si estás grabando un DVD o un Live-CD, comprueba las opciones básicas de tu programa de grabación de DVD y asegúrate de que estás grabando una imagen y no un fichero.

 Y el detalle

Cuando arrancas un medio cualquiera, un DVD para instalar Ubuntu o un disco duro con El Mal, dicho medio debe de tener algún sistema de arranque. Por eso, en el caso de un pendrive, puede no ser suficiente con copiar la imagen en orden correcto. Y esa es la misma solución cuando todo falla: ¿por qué no dotarlo de arranque? No es difícil encontrar guías para esto, e incluso suelen acompañar a las guías referidas al arranque desde pendrive como "instalación manual" o similar.

Por otra parte, para arrancar un sistema Linux simplemente necesitas un núcleo y el script de arranque, siempre y cuanto tengas un cargador de arranque. Esto es útil cuando lo que tienes es ya un Linux: descargas el núcleo y el fichero initrd, añades una entrada en el menú de tu cargador de arranque para ellos (con un título, por ejemplo, "instalación de Fedora".

Un ejemplo de esto con openSUSE, que al ser al distribución que uso es la que más conozco: el arranque de la distribución está en http://download.opensuse.org/distribution/13.1/repo/oss/boot/x86_64/loader/. Esto mismo también está en la imagen del DVD de instalación, si ya lo hemos descargado. Para otras distribuciones, es cuestión de curiosear en su documentación o de preguntar en sus foros.

Por cierto, recuerda que la copia es literal: si lo que estás copiando tiene soporte EFI lo que resulte de la copia también lo tendrá, y no le aparecerá por arte de magia si no lo tenía al principio.

Recuerda siempre la máxima: al menos hasta que te sientas a tus anchas en Linux, trata de ceñirte a tu distribución y a sus herramientas. Para instalar como para muchas otras cosas: ahórrate los sustos ;)

Con todo esto, no debería haber problemas en poner un DVD de instalación en marcha. En la próxima entrega hablaremos un poquito de cómo instalar el sistema, cómo aprovechar la memoria o el disco y otras pequeñas cosas.

lunes, 1 de septiembre de 2014

Camino a Linux: o de cómo diantres meto yo eso en el computador iii: la selección de arranque

En la entrada anterior hemos visto las posibilidades para arrancar el sistema, bien para los equipos con la BIOS tradicional bien para los equipos con las más modernas UEFI. Pero ¡ni una sola palabra de cómo seleccionar lo que queremos arrancar!

Lo de siempre...


Desde hace ya décadas es posible seleccionar el orden de arranque de los dispositivos de un computador, siempre y cuando, naturalmente, la BIOS (o UEFI) lo soporte. Las más antiguas soportan simplemente arrancar desde disquetera o disco duro, mientras que las más modernas pueden arrancar desde la red, USB, DVD y otros dispositivos menos comunes. Para ello, basta con acceder a la utilidad de configuración de la BIOS/UEFI, establecer el orden en el que se debe de intentar arrancar, guardar los cambios y reiniciar.

¿Cómo acceder a dicha utilidad? Bien, como tantas otras cosas, varía de una a otra utilidad de configuración. Muchas se arrancan pulsando la tecla suprimir (Supr), mientras que otras necesitan que se pulse la tecla de función F2. Y alguna utilidad de configuración puede ser más exótica y requerir otra tecla distinta. Algunos portátiles (por ejemplo, de HP) disponen de un menú que se muestra al pulsar la tecla ESC y que permite seleccionar otras opciones.

Podemos llamar algo así como "sesión BIOS" el tiempo en que nuestra BIOS/UEFI ejecuta sus chequeos y establece sus configuraciones. Antes la mayoría de los datos (memoria RAM disponible, discos...) se mostraba, pero ahora es más habitual poner algún dibujo o logotipo. En cualquier caso, dicha sesión puede ser relativamente breve, lo que hace que arrancar la utilidad de configuración de la BIOS no siempre sea tan trivial como parezca: en unos casos podemos apresurarnos tanto que la BIOS aun no haya detectado el teclado, mientras que otras veces podemos demorarnos lo suficiente para que la BIOS haya cargado ya el arranque del sistema operativo, aun cuando nosotros aún estemos viendo el logo de turno. En mi caso suele funcionarme pulsar varias veces la tecla de turno a intervalos regulares, por las dudas. Sea un logo o sea la información del sistema, en la parte inferior de la pantalla se mostrarán las opciones que hay, simplemente hay que estar atento (y quizás reiniciar un par de veces para poder leerlas todas correctamente).


Una utilidad que incluyeron las BIOS desde hace bastante tiempo y que ahora también incluyen las UEFI es el menú de arranque. Este menú permite seleccionar cualquier dispositivo (disponible para la BIOS/UEFI) desde el que arrancar, con independencia del orden de prioridad prefijado en la configuración. Así, el menú se muestra al pulsar la tecla correspondiente, de forma análoga al inicio de la utilidad de configuración y siguiendo las mismas prevenciones que para ella. Por ejemplo, los portátiles HP suelen desplegar este menú tras pulsar F9, mientras que las placas base de Asus pueden usar F8 (que es la misma tecla que muestra el cargador de arranque de Windows, lo que en algunas situaciones puede inducir a confusión). Otro ejemplo, las placas Gigabyte que muestran la utilidad de configuración en F2 pueden arrancar con F2.

... Y lo moderno...

Hasta aquí todo resultaba relativamente sencillo. Es decir, tendemos a tener pocos computadores, o incluso solo uno, así que recordar cómo se arranca desde DVD en nuestro portátil no tiene por qué ser demasiado exigente. Además, muchos equipos ya bienen configurados de fábrica para que el primer dispositivo desde el que traten de arrancar sea el DVD, y en los equipos con menos de diez años arrancar desde un pendrive solamente exige el esfuerzo de buscarlo en el menú antes mentado, además de un poco de atención para pulsar la tecla que despliega dicho menú en el momento correcto.

EFI y el Secure Boot complican ligeramente la situación. Ya no basta con que la BIOS esté configurada para que arranque desde DVD para que efectivamente arranque desde DVD, como hemos visto en la entrada anterior. Es sistema EFI sólo acepta dispositivos EFI, mientras que el sistema legacy o compatible (CSM) no arrancará dispositivos EFI. Así, si uno tiene Windows 7 lo ideal es usar el modo compatible, mientras que con Windows 8 es mejor usar el sistema EFI. Nótese que, como he comentado en otras entradas del blog, un DVD original de Windows 8 puede que no seas capaz de arrancarlo en un sistema que solamente use EFI. En el caso de los portátiles con Windows 7 preinstalado, pueden usarse ambos modos.

Es tentador activar simplemente el modo compatible para cualquier eventualidad, y por sí mismo no ofrece ningún problema. Lo malo es que después hay que prestar atención para que los efectos no sean indeseados. Por ejemplo, puede no ser buena idea instalar Linux en un sistema con Windows 8 en modo "legacy".

¿Y qué hay de Windows 8 y su secure boot? Bien, por fin si grabas algo en el arranque de Windows no podrá ejecutarse sin permiso, incluso si es un virus. Eso significa que sí que es cierto que esta característica responde a una carencia técnica del sistema operativo. Claro que habría estado mejor algún sistema de control de acceso tipo lo que hace Linux, pero el mundo (del dinero) es así. Secure boot hace que UEFI compruebe que el sistema a arrancar dispone de una clave autorizada (por Microsoft, por supuesto). Si lo que quieras que vayas a arrancar dispone de una, no tendrás problemas, pero si no la tiene por cualquier razón el sistema se lo impedirá. La mayor parte de equipos con UEFI pueden ser configurados para que ignoren esta característica, una forma de lavado de conciencia por parte de los fabricantes, que saben que implementar estupideces por las necesidades de otras empresas a medio plazo no es buena idea.

... para al final...


Con todo esto, encendemos el equipo y pulsamos la tecla para seleccionar el medio a arrancar: CD/DVD si lo que tenemos es un CD/DVD, USB-disk para un disco conectado por USB (incluso para los pendrives), etc. Una vez que hemos arrancado nuestro medio de instalación, todo es más sencillo, o al menos es más fácil encontrar documentación al respecto. Se cargará el sistema de arranque del medio de turno, en función del contenido de dicho medio: una distribución Linux generalmente cargará grub2-efi o grub2, para el caso de que estemos o no usando el sistema EFI. Pese a todas las profecías y las esperanzas de Microsoft, la mayoría de distribuciones arrancarán bien en cualquier equipo. Como he dicho, más fácilmente incluso que el propio Windows.

Todo esto está muy bien, pero necesitamos tener un medio que arrancar, sea un live-DVD para probar una distribución sin cambiar nada realmente o bien un CD o pendrive con lo necesario para instalar a través de la red. De esto hablaremos en la próxima entrega.