Diario de un sysadmin

Mantener la calma en un mundo complicado

[unsysadmin]

Esta marca ha mejorado muchísimo, su firmware hoy día es bastante completo

[unsysadmin]

Probando systemd-nspawn para crear y administrar contenedores simples

Hoy día es común el uso de contenedores para desarrollo, prueba y despliegue de aplicaciones.

Un contenedor se puede entender como una máquina virtual ligera, que comparte el núcleo del sistema operativo con el equipo anfitrión, pero que tiene una vista limitada de los demás recursos del sistema, en especial de los sistemas de archivos.

¿Entonces un contenedor es como una jaula de chroot? Tampoco, un contenedor es más avanzado que un chroot, ya que además de mostrar a los procesos allí contenidos una vista limitada de los sistemas de archivos, muestra a estos procesos una vista limitada de los procesos, llamadas del sistema, y de la red del sistema.

systemd provee una utilidad para crear y administrar contenedores de forma rápida, systemd-nspawn. systemd-nspawn no es una solución tan completa como Docker o LXC, pero puede ser muy útil para el desarrollo y prueba de software y en algunos casos incluso en producción. Como punto a favor de systemd-nspawn, si también dentro del contenedor se ejecuta systemd se logra una integración entre las herramientas administrativas del host y del contenedor que simplemente no es posible con Docker o LXC.

Para crear un contenedor de systemd-nspawn, generalmente es suficiente con instalar un sistema linux mínimo en un subdirectorio de /var/lib/machines, operación que se puede realizar con yum, dnf o debootstrap:

# dnf --installroot=/var/lib/machines/contenedor1/ --nogpgcheck --releasever=22 install httpd php passwd # # systemd-nspawn -M contenedor1 # passwd # exit # # machinectl start contenedor1

¿Qué pasó aquí? Con el comando dnf instalamos apache, php y el sistema base de Fedora 22 en /var/lib/machines/contenedor1, con systemd-nspawn abrimos un shell dentro del contenedor para cambiar la clave de root del mismo, y por último arrancamos el contenedor en segundo plano. La útilidad básica de administración de contenedores es machinectl.

Como el contenedor incluye systemd, podemos usar el comando systemctl para iniciar, habilitar y administrar servicios dentro del contenedor:

# systemctl -M contenedor1 list-units # systemctl -M contenedor1 start httpd.service # systemctl -M contenedor1 start httpd.service

Con el comando machinectl podemos administrar el contenedor como un servicio más de nuestro host:

# machinectl restart contenedor1 # machinectl enable contenedor1 Created symlink from /etc/systemd/system/machines.target.wants/[email protected] to /usr/lib/systemd/system/[email protected].

Para hacer login en un contenedor:

machinectl login contenedor1

Gracias al canal de comunicación dbus entre el host y el contenedor, podemos usar journalctl para examinar los log del contenedor

# journalctl -M contenedor1 # journalctl -M contenedor1 # journalctl -r

También posemos usar systemd-analyze para revisar los tiempos de arranque de los servicios del contenedor:

# systemd-analyze -M contenedor1 blame # systemd-analyze -M contenedor1 critical-chain

Una forma sencilla de configurar la red del contenedor es usar systemd-networkd tanto en el host como dentro del contenedor:

# systemctl start systemd-networkd # systemctl enable systemd-networkd # systemctl -M contenedor1 start systemd-networkd # systemctl -M contenedor1 start systemd-resolved # systemctl -M contenedor1 enable systemd-networkd # systemctl -M contenedor1 enable systemd-resolved # # ping contenedor1

Por último, si queremos que el contenedor tenga cierta utilidad práctica vamos a querer mapear un(os) puerto(s) del host con un(os) puerto(s) del contenedor. Esto no se puede hacer aún con la versión de machinectl disponible en Fedora 22, pero se puede lograr fácilmente creando un unit file de systemd:

# machinectl stop contenedor1 # machinectl disable contenedor1 # cat >/etc/systemd/system/contenedor1.service <<EOF [Unit] Description=Mi contenedor de prueba [Service] ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-veth --port=tcp:80:80 --machine=contenedor1 KillMode=mixed Type=notify RestartForceExitStatus=133 SuccessExitStatus=133 Slice=machine.slice Delegate=yes EOF # # systemctl daemon-reload # systemctl start contenedor1.service

Para extra puntos, se pueden configurar en el mismo unit file los límites de uso de recursos del contenedor. Man systemd.exec

Estos ejemplos muestran sólo una pequeña parte de las posibilidades de systemd-nspawn, para más ejemplos e ideas hay que consultar las páginas de manual de systemd-nspawn y machinectl.

[two-bit-idiot]

The CIO of GHash.io talks about the recent hullabaloo over his company and mining pool. Canada amends its money laundering laws to account for digital currencies like Bitcoin. New Jersey may sue student bitcoiners, but Jersey aims to be a bitcoin paradise. And I’m offering a bitcoin bounty to the...

[unsysadmin]

Guía de Bitcoin para el "dummie" venezolano

Desde el año 2003 se encuentra vigente en Venezuela un sistema de control de cambio, que regula y limita severamente la compra y venta de moneda extranjera. El ciudadano venezolano que quiera comprar o vender moneda extranjera deberá adaptarse a una serie de normativas propias del uso que dará a esa moneda y acatar un precio fijo para esa moneda, precio establecido por el Estado. Incluso para ciertos casos (compras electronicas, viajes) de uso existe un monto tope anual de moneda extranjera disponible por ciudadano por año, es decir el tristemente conocido "cupo".

El que no quiera adaptarse a las normas del control de cambio o simplemente tenga necesidades que no están previstas en dicha normativa, deberá conseguir la moneda extranjera, generalmente dólares, mediante métodos informales y no garantizados por el sistema bancario, métodos que desde el 2010 son incluso ilegales.

Hoy día existe una alternativa a la compra y venta de dólares, que si bien aún no ha sido definida su legalidad o no en Venezuela, podemos decir que es más fácil y segura de mover que los dólares comprados a desconocidos y de paso no afecta las preciadas "reservas internacionales" del país. Esta alternativa son los Bitcoin.

Qué es Bitcoin

Bitcoin es una red p2p (peer to peer) que mantiene un libro contable donde se registran las transacciones (pagos) realizados entre usuarios de la red. Cada usuario de la red posee unas llaves privadas que le permiten gastar sus pertenencias digitales, también llamadas Bitcoin. Cada usuario también posee una varias llaves públicas, llamadas direcciones de pago, que le permiten recibir Bitcoins desde otros usuarios.

Para empezar a usar la red de Bitcoin un usuario instala en su PC o teléfono una "billetera" (wallet) de Bitcoin, que no es otra cosa sino un programa que genera llaves privadas y direcciones de pago, conectándose a la red p2p para manejar transacciones salientes y entrantes. Todas las billeteras permiten manejar una libreta de direcciones de pago y la mayoría de ellas manejan la generación y lectura de códigos QR para un intercambio rápido de direcciones o instrucciones de pago entre usuarios.

Billeteras de Bitcoin

La billeteras de Bitcoin más comunes para PC (Windows, Linux, MAC, Unix, etc) son el cliente oficial y Multibit, mientras que para celulares Android tenemos el Bitcoin Wallet.

Es importante saber que el cliente oficial de Bitcoin mantiene localmente una copia completa del registro de transacciones de Bitcoin lo que lo hace más seguro y ayuda a mantener el funcionamiento de la red, la contrapartida es que la sincronización inicial requiere varios días y muchos Gigabytes de espacio en disco (16G a la fecha). En general hoy día se recomienda empezar con Multibit o el cliente Android.

Una billetera de Bitcoin no es más que un programa que genera llaves privadas y llaves públicas para identificarse ante la red de Bitcoin, el dinero (los Bitcoin) no se encuentran "en la billetera" sino que están en el registro de transacciones de Bitcoin. De esto nace un posible problema: si pierdes la billetera de Bitcoin pierdes el acceso a tu dinero, para siempre, de forma irreversible. Por otro lado si alguien tiene acceso a tu billetera de Bitcoin puede realizar una copia de la misma y gastar tu dinero por ti, y para cuando te des cuenta va a ser demasiado tarde.

Para mantener segura la billetera de Bitcoin, inmediatamente después de la instalación hay que realizar dos tareas indispensables, proteger la billetera con una contraseña y respaldarla. En ese mismo orden, al revés no sirve.

Como obtener los Bitcoin

Hay dos formas básicas de obtener Bitcoin, realizando "minería" o comprándolos.

La minería de Bitcoin es un tema extenso que amerita un artículo aparte. Por ahora, baste saber que para el correcto funcionamiento de la red de Bitcoin es indispensable verificar que los usuarios no gasten su dinero múltiples veces (double spending) y para ello varios de los nodos que participan en la red verifican activamente las transacciones. El proceso de verificación es bastante costoso en término de capacidad de cómputo, principalmente para evitar que un ente malintencionado pueda conectar a la red una cantidad suficiente de nodos maliciosos y así aceptar o rechazar transacciones a conveniencia. Si un atacante tuviera a disposición por lo menos el poder de cómputo del 51% de la red podría forjar transacciones, sin embargo lo costoso del proceso de verificación impide que esto pase.

El proceso de verificar transacciones se llama "minería" ya que es premiado con una cantidad de Bitcoin para que sea atractivo económicamente.

No hay que pensar que la minería de Bitcoin sea como la gallinita de los huevos de oro, al contrario, minar exitosamente requiere de una fuerte inversión en hardware, que se traduce en un riesgo financiero. La compra del hardware equivocado o la baja de valor del Bitcoin podría ocasionar pérdidas.

La compra de Bitcoin (o incluso de fracciones de Bitcoin) se puede realizar a través de un "exchange" o simplemente mediante intercambio personal, con conocidos o a través de un sitio como Local Bitcoins que facilita el contacto entre compradores y vendedores.

Los exchange funcionan como casas de bolsa: los usuarios colocan ordenes de compra o de venta en un libro de órdenes y donde se hace match entre las ordenes apropiadas. Generalmente el exchange se queda con un 0,3% o 0,25% de cada orden ejecutada con éxito.

Al manejarse la compra y venta de Bitcoin a través de oferta y demanda podremos notar que su precio es muy variable, normalmente hay variaciones de 20-50$ por día en el precio de un Bitcoin, que en el 2013 su precio pasó de $50 a $1200 para luego establecerse en el rango de $600-$700 que posee a la fecha.

Algunos exchange conocidos son BTC-e y Bitstamp, especializados en compra y venta de Bitcoin frente al dólar. También tenemos Bitcoin Central, especializado en el transacciones entre Euro y Bitcoin.

Como sistema de pago electrónico, Bitcoin es un concepto bastante novedoso, y si lo vemos como una moneda no respaldada por un gobierno o un banco central es un concepto completamente revolucionario. Una de las desventajas de un sistema tan nuevo y sin regulaciones es el ambiente de "viejo oeste" que conlleva, con un nutrido grupo de charlatanes y estafadores. Moraleja del cuento: no le confíes a nadie más Bitcoin de los que puedas permitirte perder, y esto incluye hasta los exchange más conocidos.

Donde gastar los Bitcoin

Si se formalizó la inscripción en un exchange reputado, se podrán cambiar los Bitcoin a dólares o euro para la transferencia a una cuenta corriente. Algunos exchange manejan transferencias a medios de pago como PayPal u OkPay.

Una nota acerca de OkPay. Mientras Paypal hoy día es casi off-limits para los ciudadanos venezolanos, yo logré inscribirme en OkPay y obtener una cuenta verificada presentando copia de mi cédula y del estado de cuenta de la tarjeta de crédito. Una vez lograda la verificación de la cuenta logré mover Bitcoin hacia y desde OkPay, pero no pude usar su característica más interesante que era la tarjeta de débito prepagada. Al parecer no permiten usar los dólares obtenidos de la venta de los Bitcoin como recarga para la tarjeta.

Algunas tiendas en línea aceptan directamente el pago en Bitcoin. Las más conocidas son Coinsfortech, Overstock y TigerDirect. Otras tiendas en línea no aceptan directamente el pago en Bitcoin pero existe una alternativa interesante: Gyft permite cambiar Bitcoin por gift cards de las cadenas de tiendas más reconocidas, incluyendo Amazon.

Espero que este artículo haya servido como abre boca, en los próximos hablaremos de paper wallets, la minería de Bitcoin y de los altcoin.

[unsysadmin]

Houston, we have a problem!

Ayer, 28/02/2014, algunos usuarios de twitter empezaron a reportar que los DNS de Cantv estaban sufriendo un ataque de envenenamiento del caché del DNS, en particular con respecto a la zona google.com.

Los twitteros decían que las respuestas a consultas sobre la zona google.co.ve estaban devolviendo unas IP de Cantv (201.248.x.x) en lugar de las IP tradicionales de Google (74.125.x.x). En ese momento andaba ocupado en otras cosas así que hice un chequeo rápido (host google.co.ve), vi que devolvía las IP correctas y me olvidé del asunto.

Sin embargo en la noche veo la siguiente imagen, publicada por el usuario @indiferencia:

Pues ya la situación parecía algo extraña así que empecé a verificar de nuevo, y todo se vio aún más extraño:

$ host google.com 200.44.32.12 Using domain server: Name: 200.44.32.12 Address: 200.44.32.12#53 Aliases: google.com has address 201.248.76.35 google.com has address 201.248.76.16

--

$ host www.google.com 200.44.32.12 Using domain server: Name: 200.44.32.12 Address: 200.44.32.12#53 Aliases: www.google.com has address 74.125.196.106 www.google.com has address 74.125.196.103

--

$ curl http://google.com/?q=fuck+the+police <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="http://www.google.com/?q=fuck+the+police">here</A>. </BODY></HTML>

Con el primer comando se puede ver como el DNS de Cantv devuelve una IP 201.248.x.x para la zona google.com, con el segundo se ve como devuelve las IP tradicionales 74.125.x.x para la zona www.google.com. Con el tercer comando se puede ver como http://google.com es una página que simplemente recibe la consulta del usuario y luego redirige a la página completa http://www.google.com.

¡Holy shit! ¡Nos están haciendo un MITM con la página de google! En otras palabras lo que me pareció al momento fue que alguien montó ese servicio de redirección para recopilar las consultas realizadas y luego mostrar la página oficial de google. ¿Quién sería? ¿Cantv, N33, el CESSPA?

Ya va, que no panda el cúnico, los certificados SSL nos pueden ayudar

Un momento, pensé, para determinar con seguridad si de verdad hay un MITM hay que realizar la misma prueba usando HTTPS. Si tanto el certificado de google.com como el de www.google.com son válidos y correctos no se puede tratar de un MITM.

¿Por qué digo válidos y correctos? ¿Y no es suficiente con ver el candadito en la página del navegador? Pues no es tan sencillo.

Resulta que el protocolo HTTPS, que está basado en el protocolo SSL, no solo maneja cifrado sino que maneja también el tema de la autenticación, es decir que nos confirma la identidad del sitio web con el que nos estamos comunicando. Este servicio de autenticación se da a través de una Infraestructura de clave pública, donde nuestro navegador confía en unas autoridades de certificación que a su vez firman los certificados de los sitios web que visitamos.

En pocas palabras, mediante HTTPS y PKI, podemos verificar que el certificado que nos presenta https://www.google.com es válido (firmado correctamente, no expirado) y firmado por una de las autoridades de certificación confiada por nuestro navegador.

Como toda cadena, que revienta por el eslabón más débil, el sistema PKI se basa completamente en la confianza con las autoridades certificadoras: Si una cualquiera de estas autoridades certificadoras emite certificados alegremente pues estamos en problemas.

Me explico: Los certificados SSL de Google normalmente son firmados por la autoridad certificadora Equifax. Sin embargo si una cualquiera de las otras autoridades certificadoras (por negligencia o hack) también emite un certificado para google.com, nuestro navegador aceptará alegremente dicho certificado y confiará plenamente en el sitio web remoto, que probablemente estará realizando un MITM.

Si el atacante que estaba realizando el MITM en Cantv tuvo acceso a una autoridad certificadora negligente nos jodimos, pensé yo. Fácilmente podía presentar un certificado aparentemente válido para google.com, interceptar las consultas y luego redirigir a www.google.com. Incluso en un segundo momento este podría realizar un ataque de SSL Stripping para terminar de interceptar todo el tráfico entre los usuarios de ABA y google.com.

Justo mientras pensaba en estos escenarios catastróficos, el usuario @jtelos me comentó que no, que según el no se trataba de un MITM sino de un CDN o acelerador de contenido de google.com.

Hora de verificar los certificados

Como google.com redirige inmediatamente a www.google.com resulta bastante complicado verificar el certificado de la primera página desde el navegador, así que es preferible usar el subcomando s_client de OpenSSL:

$ openssl s_client -connect google.com:443 CONNECTED(00000003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority ---

--

$ openssl s_client -connect www.google.com:443 CONNECTED(00000003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority ---

La salida de los dos comandos anteriores lo aclara todo. Los certificados de google.com y de www.google.com son ambos válidos, ambos firmados por Equifax y poseen ambos la misma ruta de certificación, y esta es válida en cada paso. ¡Falsa alarma!

Probablemente el DNS devuelve IPs diferentes para google.com y www.google.com porque aún el sistema de caché está en fase de prueba. En efecto el DNS de Google, 8.8.8.8, ya devuelve las nuevas IP para ambas consultas.

En fin nadie está interceptando nuestra comunicación con Google. Al menos nadie nuevo, ya que la NSA lo está haciendo desde hace bastante tiempo.

Gracias a @jtelos por el heads up con respecto al servicio de CDN de Google.

[screenshotsofdespair]

[m-agda-deactivated20190929]

where is your god now

[ph4z0n]

Viper Window Manager (VWM) is a lightweight, extensible window manager for the console. Originally, VWM was designed to be the reference implementation of libviper. In fact, the two projects were initially one before public release.

From conception, VWM was designed to be both lightweight and ssh friendly. Character based line-art compresses very well as do the escape sequences which handle cursor manipulation. This makes VWM quite suitable for low-bandwidth, remote connectivity over ssh.

It is also very easy to extend the functionality of VWM. By following a few simple API rules, anyone can create a “native application” which will appear on the VWM Main Menu. The mechanism for this is very similar to Mozilla-style plugins.

http://vwm.sourceforge.net/screenshots.html

[unsysadmin]

El caso para una red social alternativa

Recientemente fue noticia el cierre de 6.000 cuentas por parte de la red social Twitter. En primera instancia se planteó que el cierre había sido por una razón política ya que la mayoría de las cuentas cerradas eran de seguidores del presidente venezolano Nicolás Maduro, sin embargo es una posibilidad que desde un primer momento pareció poco probable al tratarse de apenas el 0,3% de los seguidores del primer mandatario.

A todas luces el motivo de cierre de las 6000 y tantas cuentas es técnico, al parecer todos estos usuarios habían permitido el uso de su cuenta por parte de un App que realizaba RT automáticos de cada tweet escrito por el presidente Maduro y aparte de eso la mayoría de las cuentas cerradas eran bots, cuentas controladas por una o más apps y no por humanos. Solo un pequeño porcentaje de las cuentas eran cuentas reales, manejadas directamente por gente y no por aplicaciones, y estas fueron restablecidas en pocas horas.

Era de esperarse que un caso como este, que por un motivo u otro, afectó justo a una parcialidad política, generara repercusiones políticas y acusaciones de censura. Hay que estar claros, Twitter es un servicio prestado por una empresa extranjera, de forma gratuita, y a cambio de este servicio Twitter Inc se reserva el derecho de mostrarnos anuncios publicitarios y a compartir lo que publicamos con otras empresas:

Esta licencia incluye el derecho de Twitter a prestar, promocionar y mejorar la prestación de los Servicios y permite a Twitter que el Contenido que se reproduzca en los Servicios o a través de los mismos quede a disposición de otras compañías, organizaciones o personas físicas que se asocien con Twitter para la sindicación, retransmisión, distribución o publicación de tal Contenido en otros medios y servicios, de conformidad con nuestros términos y condiciones que regulan el uso de tal Contenido.

Dichos usos adicionales que puedan darse por parte de Twitter o por parte de otras compañías, organizaciones o personas físicas asociadas con Twitter en relación con el Contenido que se pudiese enviar, mostrar, transmitir o que pudiese ser puesto a disposición a través de los Servicios se realizarán sin compensación alguna a su favor.

Estos términos de servicio son bastante comunes en el caso de servicios comunes e implican que el usuario no es realmente cliente de la empresa Twitter, sino más bien el producto que este empresa vende a sus anunciantes. Personalmente no veo nada de escandaloso en esto, es su modelo de negocio y les permite ofrecer un buen servicio sin cobrar a cada usuario por el mismo.

Como parte de las reglas de uso, Twitter se reserva el derecho de cerrar cuentas por múltiples razones, y, aunque no se indican causas políticas allí, es cierto que las reglas de uso podrían cambiar en cualquier momento y la empresa podría cerrar las cuentas que considere convenientes sin estar obligada a dar explicaciones a sus usuarios.

El problema es que dependemos siempre más de las redes sociales para comunicarnos, y al estar estas redes controladas por un puñado de corporaciones, les estamos dando un poder inmenso. Entre estas corporaciones probablemente Twitter ha sido la que menos ha interferido con la libertad de expresión de sus usuarios, sin embargo no existen garantías de que esto sea siempre así, y es conveniente buscar alternativas.

Una posibilidad para la creación de una red social alternativa sería el uso del mismo código de Twitter, ya que este es Open Source, sin embargo esta opción serviría para crear otra red igual a Twitter, monolítica, con todas sus desventajas como la necesidad de contar con una enorme cantidad de servidores e igual de expuesta al peligro de una censura. De paso esta red social seguramente carecería de una masa crítica de usuarios lo que la haría poco atractiva y la convertiría en una triste cámara de eco.

La solución está en construir una red social descentralizada, con federación de servidores, cada uno con un estilo de comunicación, sus normas de uso, su target político y social. Múltiples comunidades interconectadas. ¿No es ese el espíritu de Internet?

Si a esta federación de redes sociales le agregamos unas pasarelas de interconexión con las redes sociales de moda (Twitter, Facebook, etc.) tendríamos lo mejor de los dos mundos: comunicación bidireccional con los millones de usuarios de las redes sociales corporativas, y protección contra censuras empresariales o gubernamentales.

El software para crear estas nuevas redes sociales existe. Si el gobierno es serio en su objetivo de crear una red social alternativa muy bien podría contribuir uno o dos recursos para desarrollar las pasarelas y los clientes para esta solución. Luego con una pequeña inversión infraestructura podrían crear un "Pump" gubernamental (y de repente otro para las comunidades) interconectado con Twitter.

[unsysadmin]

¿Hacker o cracker?

Parece ser parte de la idiosincrasia de todo entusiasta del Software Libre en Venezuela: si alguien comenta que un hacker se metió en una página, o dañó un sistema, o realizó cualquier acto ilegal cerca de una computadora, se debe contestar que no fue un hacker sino un cracker. Hasta el son de hoy los jóvenes integrantes de la comunidad son iniciados a esta campaña para el correcto uso del vocabulario, en donde un hacker es un impoluto estudioso de los sistemas mientras que un cracker es un obscuro personaje que se dedica a dañar la propiedad electrónica ajena.

¿De donde vienen esas definiciones?, ¿son estas apropiadas y actuales?

El término hacker por lo menos en lo relacionado con la informática tiene ya sus 50 años de vida, según el Jargon File de Eric Raymonds, suerte de enciclopedia de la cultura de entusiastas de la informática nacida alrededor de las principales universidades tecnológicas de EEUU en los años 60. El Jargon File describe el hacker como una persona que disfruta de la exploración de los detalles de sistemas programables buscando llevarlos a sus límites. Al mismo tiempo define los Hacker como una suerte de élite basada en la meritocracia dentro de la comunidad global que es Internet.

Según el mismo Jargon File un cracker es quien penetra un sistema informático mediante medios subrepticios, y el término fue creado en respuesta al uso incorrecto del término hacker por parte de la prensa no técnica.

La distinción parece bastante clara al menos como establecimiento de modelos: el hacker es un ejemplo de curiosidad, inteligencia y perseverancia a seguir, mientras que un cracker no es más que un vulgar pirata informático.

Todo claro, al menos según Eric Raymond y su Jargon File.

Hay varios problemas con estas definiciones. El primero es que por donde se le mire un cracker es también un hacker simplemente uno dedicado a negocios algo turbios. De alguna forma los cracker forman un subgrupo de la comunidad hacker, y si vamos a ser estrictos la carga ética negativa sobre el término fue impuesta por el mismo Eric Raymonds y es una forzadura de su significado técnico.

Desde el punto de vista técnico un cracker es quien se dedica a romper algo, sea un algoritmo de cifrado, un sistema de protección a la copia, un sistema DRM: si partimos del supuesto que un sistema DRM está diseñado para restringir los derechos del usuario, entonces ¿cómo podemos dar una connotación negativa al acto de romper un sistema de este tipo?

La definición ética de la palabra cracker resulta totalmente incompatible con su definición técnica, y en mi opinión deberíamos limitarnos a esta última.

Dicho sea de paso, hay muchos otros muchos tipos de hacking, aparte del cracking: desde el antiguo phreaking hasta el social engineering, pasando por el phishing. Sólo recordemos algo, estas son definiciones técnicas, no éticas.

Si en verdad necesitamos asignar una caracterización ética o legal a un determinado Hacker, podemos usar la definición basada en el color de su sombrero. Un hacker de sombrero blanco es el mítico amante de la tecnología, siempre dedicado a llevar al límite los sistemas informáticos, mientras que el hacker de sombrero negro representa el villano dedicado a vulnerar sistemas ajenos y a vender zero days en el mercado negro.

La mayoría de los hacker, la mayoría de nosotros, no calzamos en ninguna de las dos definiciones sino que somos hacker de sombrero gris, o grey hats, hábiles para movernos en las fisuras de la red, no siempre atentos a las consecuencias éticas y legales.

[ph4z0n]

[linuxart]

[unsysadmin]

La carga política del Software Libre

El pan de cada día de los activistas del Software Libre en Venezuela consiste en discutir acerca del sesgo político que puede tener o no el Software Libre.

Un bando, generalmente cercano al gobierno, asevera que el Software Libre es una tecnología con una carga política socialista ya que promueve el libre intercambio de ideas sobre el puro comercio de productos que podemos encontrar en el campo del Software Privativo. Además según este grupo el apoyo del gobierno al Software Libre es una característica de los gobiernos de izquierda, progresistas, y que los gobiernos de derecha prefieren proteger las empresas que comercian con las licencias de Software antes que el libre intercambio de ideas e información.

El otro bando, compuesto generalmente por opositores al gobierno desmontan el argumento del primer grupo mostrando como el Software Libre es usado por gobiernos de derecha y por grandes corporaciones incluso más que en gobiernos de izquierda. En efecto para hacer un pequeño ejemplo una sola empresa como Google posee entre 2 y 3 millones de servidores que corren con el sistema operativo libre Linux, es decir dos o 3 ordenes de magnitud más equipos con Software Libre que pueden estar corriendo en la administración pública venezolana. Además las corporaciones como Google, IBM, Oracle, Red Hat aportan más horas hombres y líneas de código que cualquier otro gobierno de izquierda. La conclusión de este último grupo es que el Software Libre es una tecnología neutra, que puede ser usada por igual por "socialistas" y "liberales" con fines éticos o no tan éticos.

Entonces, ¿el Software Libre es socialista o no? Hay que preguntarse qué grupo tiene la razón, sin embargo si analizamos a fondo la cuestión veremos que ambos grupos juegan sobre lo ambiguo del término "socialismo" o sobre lo que pueda significar "tecnología neutra".

Una tecnología no se puede definir como neutra sólo porque puede ser usada por individuos de múltiples afinidades políticas o ideológicas, si empezáramos por ese supuesto llegaríamos a la conclusión de que un arma de fuego es neutra ya que puede ser usada para el mal (matar) o para el bien (defenderse). Esa es una forma incorrecta de medir la neutralidad de una tecnología ya que desde ese ángulo prácticamente cualquier tecnología tendría una carga neutral, al ser usada por individuos de distintos orígenes con distintos fines en diferentes momentos de la historia.

Donde tenemos que buscar la carga política de una tecnología (que es lo mismo que decir su no-neutralidad) es en la forma como esta cambia las relaciones sociales entre diferentes grupos humanos:

«Las relaciones sociales están íntimamente vinculadas a las fuerzas productivas. Con la adquisición de nuevas fuerzas productivas, los hombres cambian su modo de producción, y con el cambio del modo de producción, de la manera de ganarse la vida, cambian todas sus relaciones sociales... Los mismos hombres que establecen las relaciones sociales en consonancia con su producción material, producen también los principios, las ideas, las categorías, en consonancia con sus relaciones sociales.» (Marx, La miseria de la filosofía, 1847)

Una tecnología que hoy parece tan simple como el arado tiene una gran carga política y social ya que permite pasar de una sociedad nómada y basada en la recolección a una sociedad sedentaria basada en la agricultura.

La carga política y social de un arma de fuego no está en quien jala el gatillo en un determinado momento sino en que permite matar de forma rápida y limpia. De cierta forma la pistola aleja la violencia de quien jala el gatillo, permite matar más y al mismo tiempo parecer menos salvaje que alguien que usa un cuchillo para matar.

Llegando al Software Libre podemos ver que este tiene una carga política, social e ideológica enorme ya que este permite, en plena era del consumo, que el consumidor se vuelva inmediatamente dueño no sólo del producto como tal sino ¡incluso de la tecnología usada para generar el producto! Si además de eso combinamos el Software Libre con el desarrollo de Internet tenemos un modelo de producción con costos de reproducción y distribución que tienden a cero… y como todo economista (liberal o marxista que sea) sabe, cuando los costos de producción tienden a cero se genera una situación de oferta ilimitada donde la demanda está siempre satisfecha y a cualquier precio. Pues sí, con el Software Libre se da aquella situación descrita por la frase «De cada cual según su capacidad; a cada cual según sus necesidades» . Es definitivamente una tecnología disruptiva y "revolucionaria".

Sin embargo decir que el Software Libre (o cualquier tecnología, si al caso vamos) es de izquierda o de derecha no es más que una vulgar manipulación, casi siempre orientada a acarrear votos a uno que otro partido político, y basada en argumentos muy pobres que se desmontan fácilmente notando como cualquier clase social puede aprovecharse de esta tecnología.

Las tecnologías realmente disruptivas, como el Software Libre, modifican las relaciones sociales llevando a la larga a redefinir el significado de "izquierda" y "derecha". Si existiera en el mundo físico una tecnología con el mismo impacto en los modos de producción que ha tenido en el mundo digital la combinación de Software Libre e Internet esta llegaría incluso a borrar la distinción entre clases sociales, y no lo digo a la ligera.

Con el Software Libre tenemos una tecnología profundamente revolucionaria, más no "de la revolución", y aquí se que mis conciudadanos captaron la idea.

[8bitfuture]

[unsysadmin]

Múltiples conexiones a Internet con una tarjeta de red (3era parte)

En la primera y segunda parte de este post vimos como conectar un equipo Linux a múltiples redes lógicas usando Vlans, y comenté que puede presentarse un problema cuando estas múltiples redes lógicas son varias conexiones al mismo ISP.

Usar una sola tarjeta de red en lugar de varias presenta algunos inconvenientes menores, por ejemplo no se pueden establecer parámetros de transmisión (tamaño de la cola, offloading, etc.) para cada subinterfaz, sino que los parámetros de la interfaz física se aplicarán a todas las subinterfaces.

Otro "inconveniente" es que todas las subinterfaces poseen el mismo MAC address, sin embargo en la práctica no es mayor problema ya que al estar cada subinterfaz en una red lógica separada no existe la posibilidad que estas múltiples interfaces lógicas con la misma MAC entren en contacto entre si. Excepto en un caso: cuando estas múltiples interfaces lógicas se usan para realizar múltiples conexiones al mismo ISP.

El problema

Pues bien este caso me pasó con el mayor ISP venezolano, CANTV. Inicialmente no había problemas ya que las diferentes conexiones a este ISP pertenecían todas a redes IP diferentes (p. ej. 190.86.0.0/16, 190.87.0.0/16), sin embargo hace unos meses el router Linux empezó a comportarse de forma extraña: Las tres conexiones a internet levantaban bien, cada una en una red IP separada, pero a las pocas horas una interfaz perdía su dirección IP. Al Levantar de nuevo esta interfaz su dirección IP cambiaba, y en unos minutos fallaba la siguiente interfaz y así sucesivamente.

Definitivamente el problema me tuvo pensando por varias semanas tanto así que opté por dejar una sola conexión arriba mientras conseguía el origen del problema. La solución no era evidente ya que las 3 interfaces obtenían direcciones en 3 redes separadas, no existía la posibilidad de que la misma MAC apareciera dos veces en una de las redes... aparte de que antes estaba funcionando bien... hasta que por fin un día el bombillo se prendió!

Cantv cambió el funcionamiento de sus dhcp. Al parecer anteriormente cada uno de los rangos IP manejados por Cantv poseía su propio servidor DHCP independiente, con su propia lista de correspondencia entre MAC y direcciones IP asignadas; Luego del cambio Cantv empezó a manejar un menor número de servidores DHCP a nivel nacional y con una base de datos global de asociaciones entre MAC address e IP y esa fue la causa de mis problemas:

La interfaz lógica eth0.1001 (MAC 11:22:33:44:55:66) levantaba y solicitaba una dirección IP a Cantv

El servidor DHCP de Cantv entregaba una IP a la interfaz eth0.1001 y registraba la asignación en la base de datos de los DHCP (11:22:33:44:55:66 ⇔ 190.37.45.56/16)

La interfaz lógica eth0.1002 (MAC 11:22:33:44:55:66) levantaba y solicitaba una dirección IP a Cantv

El servidor DHCP de Cantv revisando su tabla de asignaciones encontraba que la MAC address 11:22:33:44:55:66 estaba asociada a una ip en otra red física, así que invalidaba la primera asignación y asignaba una nueva IP

A las pocas horas expiraba la asignación de la primera interfaz lógica (eth0.1001) y esta intentaba renovar esa IP, pero como la asignación había sido invalidada en el paso anterior la renovación fallaba y la interfaz se quedaba sin IP. Al intentar una renovación manual el servidor DHCP entregaba una dirección IP diferente a la anterior... y así sucesivamente, ocasionando innumerables dolores de cabeza y las amenazas del cliente de botar el servidor Linux e instalar una cajita TP-Link

La solución

Una vez descubierto el problema la solución resulta sencilla: asignar una MAC address diferente a cada interfaz lógica. Se pueden ubicar páginas que generan direcciones MAC aleatorias en la web, alternativamente existen aplicaciones de líneas de comandos que hacen lo mismo. En última instancia podemos usar la mac address de otro equipo que esté en una red diferente, siempre y cuando podamos estar seguros de que ese equipo nunca entrará en contacto con nuestro router linux. Al final me gustó este script:

# perl -e 'printf "54:52:00:%02X:%02X:%02X\n", rand 0xFF, rand 0xFF, rand 0xFF'

Obtenidos los Mac address, estos se pueden asignar a cada interfaz lógica usando el parámetro de configuración MACADDR del archivo de configuración /etc/sysconfig/network-scripts/ifcfg-eth0.XXXX. Los archivos de configuración quedaron así:

/etc/sysconfig/network-scripts/ifcfg-eth0.1001:

DEVICE=eth0.1001 ONBOOT=yes BOOTPROTO=dhcp VLAN=yes METRIC=1 MACADDR=54:52:00:60:14:BF

/etc/sysconfig/network-scripts/ifcfg-eth0.1002:

DEVICE=eth0.1002 ONBOOT=yes BOOTPROTO=dhcp VLAN=yes METRIC=2 MACADDR=54:52:00:52:6C:6D

/etc/sysconfig/network-scripts/ifcfg-eth0.1003:

DEVICE=eth0.1003 ONBOOT=yes BOOTPROTO=dhcp VLAN=yes METRIC=3 MACADDR=54:52:00:49:55:41

[8bitfuture]

[unsysadmin]

Conexión IPv6 a través de un túnel (1era parte)

«A medida que se van acabando las direcciones IPv4 disponibles se hace cada día más importante poseer conectividad a Internet mediante IPv6»

La verdad es que yo tengo casi 10 años repitiendo esto pero hay muchos ISP que no sienten la misma urgencia: por ejemplo aquí en Venezuela el ISP Cantv.net no pareciera tener en sus planes un deployment de conectividad IPv6 en un futuro cercano, ni siquiera para opciones de conexión comerciales (carísimas!), así que uno siente que se está quedando por fuera con respecto a los avances tecnológicos.

Existe una solución a este problema, bastante fácil de implementar y sin costos de mantenimiento: me refiero a una conexión a IPv6 vía túnel, es decir encapsulando los paquetes IPv6 dentro de paquetes IPv4 hasta un endpoint conectado a Internet vía IPv6 que se encargará de desencapsular los paquetes hasta su destino final.

Hay varios proveedores de conectividad a IPv6 y uno de ellos, gratuito, es Tunnelbroker de Hurricane Electric. Posee múltiples puntos de acceso, permitiéndonos escoger el que nos genere la menor latencia, permite hasta 5 túneles, y nos da para cada extremo de túnel una /64 o incluso una /48! Es decir que con tunnelbroker podríamos tener 5*2^80 direcciones IPv6… supongo que serán suficientes para unos cuantos años!

Configurando el tunel

Obviamente hay que subscribirse al servicio, luego entrar a la página web del servicio e iniciar la configuración de un nuevo tunel

Hay que ingresar la dirección IP pública del gateway local, luego escoger un gateway de Hurricane Electric (Miami es el más apropiado para Venezuela) y hacer click en "Create Tunnel". Obtendremos un resultado similar a este:

La dirección IPv6 resaltada en rojo es nuestro extremo del túnel y el que vamos a usar en esta primera parte de la configuración. Para configurar un equipo Linux de la familia Red Hat (RHEL, CentOS, Fedora) hay que editar el archivo /etc/sysconfig/network-scripts/ifcfg-sit1:

DEVICE=sit1 BOOTPROTO=none ONBOOT=yes IPV6INIT=yes IPV6TUNNELIPV4=209.51.161.14 IPV6ADDR=2001:470:4:eed::2/64

El parámetro IPV6TUNNELIPV4 corresponde a la dirección IPv4 del gateway de Hurricane Electric, mientras que en IPV6ADDR colocaremos la dirección IPv6 asignada (la que está resaltada en rojo en la imágen.

Levantamos la interfaz ejecutando ifup sit1.

Probando la conexión

Las conexiones IPv6 se prueban con el comando ping6. Primero intentamos conectarnos a la dirección IPv6 del gateway de Hurricane Electric y si esto funciona bien deberíamos tener conexión a cualquier host con dirección IPv6:

# ping6 2001:470:4:eed::1 PING 2001:470:4:eed::1(2001:470:4:eed::1) 56 data bytes 64 bytes from 2001:470:4:eed::1: icmp_seq=1 ttl=64 time=1.50 ms 64 bytes from 2001:470:4:eed::1: icmp_seq=2 ttl=64 time=1.30 ms 64 bytes from 2001:470:4:eed::1: icmp_seq=3 ttl=64 time=1.20 ms 64 bytes from 2001:470:4:eed::1: icmp_seq=4 ttl=64 time=1.63 ms --- 2001:470:4:eed::1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3204ms rtt min/avg/max/mdev = 1.206/1.412/1.634/0.168 ms # ping6 www.google.com PING www.google.com(iad23s07-in-x11.1e100.net) 56 data bytes 64 bytes from iad23s07-in-x11.1e100.net: icmp_seq=1 ttl=58 time=13.2 ms 64 bytes from iad23s07-in-x11.1e100.net: icmp_seq=2 ttl=58 time=8.30 ms 64 bytes from iad23s07-in-x11.1e100.net: icmp_seq=3 ttl=58 time=8.37 ms --- www.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2152ms rtt min/avg/max/mdev = 8.302/9.986/13.277/2.327 ms

Excelente, podemos celebrar! Eso es todo, ya tenemos conectividad IPv6 con el resto del mundo. Incluso la mayoría de nuestros programas (navegador, etc.) intentarán en lo posible establecer conexiones vía IPv6 con el resto del mundo.

Si no funciona es probablemente porque estamos detrás de un firewall o nat, ya que para establecer una conexión con Hurricane Electric necesitamos una dirección IPv4 pública y enrutable en nuestro extremo del túnel.

Direcciones IPv4 dinámicas

Algunos ISP (Cantv!) tienen la maña de cambiar periódicamente las direcciones IPv4 de sus usuarios ADSL. Si nuestra dirección IPv4 local cambia perderemos la comunicación con Hurricane Electric. Si esto pasa tenemos que volver a entrar a la página tunnelbroker.net y modificar la configuración del túnel. Alternativamente podemos agregar este comando a un script que se ejecute en caso de que cambié nuestra dirección IP:

curl -k -s "https://ipv4.tunnelbroker.net/ipv4_end.php?ip=NUEVAIP&pass=CLAVE&apikey=USUARIO&tid=TUNNELID"

Donde:

USUARIO es nuestro usuario de tunnelbroker.net

CLAVE es nuestra clave de tunnelbroker.net

TUNNELID es el identificador del túnel, lo podemos ver en la página de configuración del túnel.

NUEVAIP es nuestra nueva IPv4 local

Más adelante veremos como distribuir la /64 asignada en nuestra LAN y como integrar el direccionamiento IPv6 con el firewall y al DNS

[unsysadmin]

Integrar un proxy Squid a un dominio de freeIPA…

…con soporte a autenticación Kerberos, Single Sign On, autorización por grupos, compatible con equipos Windows, Linux y Unix, con navegadores Firefox, Chrome, IE 8+, incluso cuando los usuarios están en dominios de Active Directory que tienen relaciones de confianza con el dominio de freeIPA. ¿Parece imposible o muy complicado, cierto? En realidad es bastante simple.

La idea principal es que squid deje navegar solo a los usuarios autorizados, donde usuarios autorizados son los que pertenecen a cierto grupo. Si el equipo cliente pertenece al dominio de freeIPA, o a un dominio que posee una relación de confianza con este, incluso si es Active Directory, el proxy no tiene que pedir la clave del usuario, sino que a través de su ticket de kerberos y las funciones de Single Sign On, squid conocerá la identidad del usuario automáticamente.

El Single Sign On (SSO de aquí en adelante) es muy cómodo para el usuario ya que no obliga al usuario a ingresar la contraseña cada vez que abre un navegador, pero además de eso mejora la seguridad de la red en general: En un esquema de autenticación HTTP simple, donde el usuario comunica su clave directamente al proxy, la contraseña viaja en claro por la red con el riesgo de poder ser interceptada. Con las funciones de SSO de Kerberos la contraseña no viaja por la red.

Implementación

¿Qué hace falta?

Un servidor freeIPA (recomiendo RHEL o CentOS 6.4+)

Un cliente freeIPA. Puede ser cualquier Linux reciente aunque es más fácil trabajar en equipos que posean el comando ipa-client-install, como RHEL, CentOS, Fedora, Ubuntu. Alternativamente se pueden usar clientes Unix como FreeBSD e incluso estaciones de trabajo MS Windows conectadas a un Active Directory que posea relación de confianza con freeIPA

Un servidor proxy con squid. Para los ejemplos usaremos un CentOS 6.4

No voy a entrar en detalles sobre el proceso de instalación del servidor IPA ni del cliente IPA ya que están bien documentados, sino que voy a pasar directamente a las instrucciones relacionadas con el proxy.

Integración del servidor squid con el dominio IPA

Es importante unir el equipo squid al dominio IPA antes de proceder con el resto de las operaciones. Como siempre se recomienda en el caso de IPA, el equipo debe poseer un nombre completo (nombre.dominio.com), y este nombre debe poderse resolver por DNS. Luego ejecutamos:

# ipa-client-install

Creación de los grupos y reglas de control de acceso en IPA

En el servidor IPA crearemos un grupo para los usuarios autorizados a navegar y agregaremos a ese grupo los usuarios apropiados. También, si usamos control de acceso HBAC en IPA, podemos crear las reglas correspondientes. Este último punto no es necesario si no se usan reglas HBAC.

# kinit [email protected] # ipa group-add navegacionlibre # ipa group-add-members navegacionlibre --users=pperez,mrodriguez # ipa hbacsvc-add squid # ipa hbacrule-add accesoProxy --usercat=all # ipa hbacrule-add-host accesoProxy --hosts=proxy.midominio.com # ipa hbacrule-add-service accesoProxy --hbacsvcs=squid

Creación del servicio de kerberos para squid

En el servidor IPA hay que crear un servicio de kerberos para squid, donde por convención el nombre del servicio será HTTP/nombreDelServidor :

# ipa service-add HTTP/proxy.midominio.com

Instalación del keytab de squid

# ipa-getkeytab -k /etc/squid/squid.keytab -p HTTP/proxy.midominio.com -s servidorIpa.midominio.com # chown squid:squid /etc/squid/squid.keytab

Configuración del servicio PAM

Ya que estamos integrando la autenticación y autorización de squid con los usuarios y grupos del sistema, hay que crear un archivo de configuración para el servicio squid en PAM

/etc/pam.d/squid:

#%PAM-1.0 auth include password-auth account include password-auth

Configuración de squid

Estas son las líneas relevantes de la configuración de squid. Primero se indica que la autenticación usará kerberos (negotiate_kerb_auth), luego que la autorización se realizará por grupos del S.O. (squid_unix_group) y por último se declaran los acl y las reglas de control de acceso de squid:

auth_param negotiate program /usr/lib/squid/negotiate_kerb_auth -s HTTP/[email protected] auth_param negotiate children 10 auth_param negotiate keep_alive on external_acl_type grupo %LOGIN /usr/lib/squid/squid_unix_group acl grp_navegacionlibre external grupo navegacionlibre http_access allow …. http_access allow grp_navegacionlibre http_access deny all

¿Por qué usar los grupos del S.O. y no la consulta de grupos en ldap? La consulta de grupos en ldap (squid_ldap_group) funciona bien para los casos simples pero no maneja bien el failover en caso de la falla de un servidor IPA, no funciona bien con grupos anidados y no funciona con usuarios de dominios que tienen relaciones de confianza con IPA.

Consideraciones para el cliente

Hay varios requisitos de configuración del cliente que es bueno detallar:

El equipo cliente debe estar integrado con el dominio IPA (o con un dominio confiado)

El usuario debe pertenecer al dominio

El usuario _debe_haber iniciado la sesión en el dominio (debe poseer un ticket válido de kerberos)

El navegador debe estar configurado para usar el proxy squid. El modo de proxy transparente NO es compatible con la autenticación

Por requerimiento de kerberos, el navegador debe apuntar al proxy por nombre, si se configura por dirección IP no puede funcionar. Un URL válido para el proxy sería proxy.midominio.squid:8080, mientras que 192.168.3.4:8080 no funcionaría.

Recomiendo el uso de WPAD para que el navegador descubra automáticamente el proxy apropiado.