El 80/20 también afecta la programación

Todos hemos oído sobre la regla del 80/20, aquella que dice que el 80% de nuestro éxito (efectos) proviene tan solo del 20% de nuestras acciones (causas). Pues bien, esta universal verdad también afecta al desarrollo de software, y en este artículo vamos a desgranar un poco de los fundamentos de esta afirmación.

BPM

Business Process Managment, por su siglas en inglés, es una disciplina de gestión (entre otras cosas) que permite comprender de manera visual los procesos que deben realizarse en un negocio (o en muchos otros lugares). Entre sus cualidades principales está el hecho de poder analizar procesos complejos y hacerlos “simples”.

Existen muchas herramientas open source que permiten desarrollar diagramas BPM, la que yo he usado para este artículo es BonitaSoft. Si desean aprender un poco más sobre la gestión de procesos existen muchos tutoriales en internet y libros referentes al tema. Ahora volvamos al tema central.

Proyectos de software

Hoy en día existen muchas metodologías para desarrollar proyectos, están las ágiles, las tradicionales, las mixtas, etc, etc. Un punto que todas tienen en común es la preparación. ¿Qué quiero decir con esto? Que el 80% de tu éxito en este proyecto de software se basará en el primer 20% de todo el proceso, la preparación. 

La preparación de un proyecto

Esto es algo lógico que en la realidad se aplica muy poco (como muchas otras cosas lógicas que son ilógicas en la práctica). Cuando hablamos de preparación debemos entender la capacidad de comprender el problema, entender la solución y sobre todo, el proceso que la solución aplica. Una de las cosas que menos se encuentran en proyectos de software poco profesionales es la falta de documentación sobre dicho tema. Esto normalmente aparece en empresas privadas puesto que el deseo de vender supera al proceso de creación.

Como muchos de los que leen estos artículos trabajan o están relacionados con la tecnología, no está de más mencionar que si en algún momento de sus vidas laborales se encuentran con una empresa/proveedor que no cumple con una buena preparación, es casi 80% seguro :P que el proyecto no va a salir bien.

La abstracción es la clave

Esto es algo que he aprendido de mi tiempo usando GNU/Linux, y que demuestra una y otra vez ser clave en el proceso de creación de software. La capacidad de abstraer problemas para convertirlos en cosas más “simples” es vital para poder generar código elegante, y sobre todo duradero. Y tal vez esta es una de las principales diferencias de los grandes proyectos profesionales y los proyectos que crecen sin control alguno. Los primeros piensan, comprenden y estructuran el proceso mientras que los segundos lo mantienen funcionando sin necesidad de entenderlo.

Stager

Este es el nombre del proyecto que desarrolla el instalador de Gentoo, como pueden imaginar, este es un proceso bastante complejo, puesto que soporta una gran cantidad de arquitecturas. Otro factor a tener en cuenta es la cantidad de configuraciones que soporta, a nivel de kernel, init system, etc. Y les cuento todo esto porque además es mi proyecto de tesis, el cual debo acabar antes de terminar de estudiar. Evidentemente no puedo hacer un programa que contemple absolutamente todas las opciones posibles en tan poco tiempo ( hasta julio del próximo año), pero al menos puedo generar uno que permita instalar de manera muy básica un sistema funcional.

Entendiendo el proceso de instalación

Gracias a las herramientas de BPM, se puede generar un diagrama de proceso que nos permite entender los pasos necesarios para la instalación exitosa de Gentoo en un equipo.

proceso de instalación de Gentoo
Diseño propio. Christopher Díaz Riveros

A pesar de contener varios procesos y subprocesos, evidentemente se ha resumido bastante y se puede apreciar que contamos con 18 pasos lineales. Esto es importante porque una aplicación que cuenta con una estructura lineal es sencilla de implementar, y al mismo tiempo se puede generar paralelismo en alguno o varios de los subprocesos en caso de ser necesario.

Otro factor importante es que nos permite abstraer conjuntos de procesos por tipo, por ejemplo, definir un subproceso kernel nos permite saber que existen tareas específicas dentro del mismo que están directamente relacionadas con el proceso de instalación de un kernel de manera exitosa.

Sub-proceso "kernel"
Diseño propio. Christopher Díaz Riveros

De esta manera cada paso “complejo” se convierte en uno “simple” de manera global, sin perder los detalles necesarios. Esto facilita la visibilidad del conjunto sin disminuir el nivel de especificación necesario para cumplir el proceso de manera exitosa. Y tampoco podemos negar que es más sencillo ver la imagen que leer todo el Handbook de golpe :)

Ahorra tiempo

Otra ventaja evidente es que al no contar con un lenguaje de programación directamente conectado, es posible realizar el análisis de la lógica sin necesariamente perder tiempo en la implementación del lenguaje. Esto es una ventaja comparado con la cantidad de tiempo que se puede invertir en implementar una funcionalidad para al final descubrir que va a ser descartada porque existe una solución más eficiente. Como lo que serían las soluciones en pseudo-código (algo que también es ignorado por muchos “desarrolladores” pero que no debería serlo).

Dirigir proyectos se hace fácil

Teniendo en cuenta estos conceptos, la dirección de proyectos (de cualquier índole) se hace más sencilla, porque enfocamos los esfuerzos donde realmente son necesarios, y si esta parte es hecha de manera correcta, el resto cae por su propio peso. Espero que les ayude a la curiosidad y los motive a investigar sobre el BPM, la algoritmia y quién sabe, tal vez los anime a ayudarme con mi tesis :P Muchas gracias por llegar hasta aquí y ya nos estamos viendo pronto. Saludos

 

Una nueva historia para Gentoo

Esta semana, como siempre, las listas de correo de Gentoo están llenas de conversaciones referentes al futuro de la distribución, y una de ellas llamó mucho mi atención, al punto de ser el tema central de este artículo. Pero antes de eso vamos a conocer un poco de historia sobre la distribución:

Su creador

Nos remontamos al milenio pasado, en 1999 Daniel Robbins, lanza la primera versión de Enoch Linux, una distribuación que deseaba romper con los estándares hasta ese momento concebidos por todas las demás distribuciones, crear paquetes en lugar de recibirlos precompilados.  La idea principal era crear un sistema que se acomode al hardware del usuario, y que no tuviera paquetes innecesarios.

FreeBSD

Tras unos cuantos problemas con Enoch, Daniel migró a FreeBSD, un sistema operativo UNIX, y fue donde conoció Ports, la herramienta de control de paquetes de la distribución. Como podrán imaginar, ports se encarga de compilar los programas en lugar de conseguir binarios, para binarios se utiliza la herramienta pkg.

Gentoo 1.0

Ya en el año 2002, tras haber solucionado el elusivo bug, Gentoo ya había adquirido su nombre oficial, así llamado por la especie de pingüino más rápida de todas, y mostraba al mundo su primer versión oficial. Este hito fue el primer paso de una larga serie de cambios y modificaciones que surgieron a lo largo de los años, pero vamos a centrarnos en las más importantes.

Gestión Comunitaria

Esta es una característica peculiar en Gentoo, puesto que al no haber una compañía específica dirigiendo, la comunidad es la que decide en última instancia lo mejor tanto para desarrolladores como para usuarios. Mas cabe mencionar que grandes empresas como Sony y Google se han valido del paradigma de Gentoo para mejorar sus sistemas.

2004

Este fue un año particularlmente complicado para Gentoo, puesto que su fundador debía ceder la dirección a la Fundación Gentoo, debido a temas personales. Debido a la explosión de popularidad que estaba teniendo Gentoo en ese momento, la gente empezaba a usar Gentoo cada vez más y los números se veían prometedores, pero un crecimiento tan acelerado hacía difícil acomodar la estructura a la escala correcta. Teniendo siempre en cuenta que muchos de estos proyectos se realizan en “tiempos libres”, una explosión de fama no podía ser tan buena si no iba a haber suficiente gente para controlar las riendas.

2007

Otro año complicado, puesto que debido a la falta de estructura adecuada, y con una especie de serie de guerrillas internas, Gentoo se hundía en el mundo GNU/Linux y pasaba a ser una distribución “secundaria”. En este ambiente Daniel decide regresar al desarrollo activo como developer, pero tras muchas diferencias personales y ataques por ambos bandos, decide retirarse poco después de su reingreso. Poco después nace Funtoo Linux, una distro basada en Gentoo, pero con algunas modificaciones esenciales que no superaron la poco estable estructura de aquel entonces.

GLEP 39

Gentoo Linux Enhancement Proposal (GLEP) son documentos en los que se proponen cambios, tanto técnicos como estructurales, a la comunidad. Un GLEP pasa por continuos procesos de elaboración, revisión, votación, y puede o no ser implementado, dependiendo de la necesidad de la comunidad y la viabilidad de la propuesta. En particular la GLEP 39 es un proyecto que desea implementar una nueva estructura para Gentoo Linux, en esta se redefine el orden y la manera de proceder de muchos proyectos y developers. Comenzó en 2005, y siguió su proceso de desarrollo hasta ser aprobada en 2008. Definitivamente fue la respuesta de la comunidad, tanto desarrolladores como usuarios, por mejorar los complicados problemas estructurales que durante años la habían estado afectando.

El daño era evidente

Para este momento, Gentoo ya había sufrido mucho debido a las guerrillas internas y la falta de dirección. Muchos usuarios y desarrolladores se habían retirado y se convertía en un pequeño proyecto que esperaba su muerte. Pero lo sorprendente es que a pesar de todo, y contra todo pronóstico, la serie de cambios hicieron que Gentoo cuente con una estructura más estable, y gracias también a la disminución de desarrolladores y usuarios (posibles puntos de vista contradictorios al momento de desarrollar) se pudo empezar a trabajar en nuevos proyectos y mejorar Gentoo en su núcleo.

La prueba definitiva, los años

Ya han pasado 10 años desde ese momento en el tiempo, y mucho ha cambiado, y otras cosas no tanto, la estructura definida en aquel entonces ya se ha establecido, y se ha aprendido mucho en el proceso, nuevos desarrolladores han llegado y otros se han retirado. En resumen, Gentoo no ha muerto (sorprendentemente). Y esta nueva sabiduría se refleja en las formas y modelos de selección, resolución de problemas, presentación de proyectos, en fin, ya se han hecho a la idea. Y esto nos lleva a esta semana nuevamente.

“A plan for Gentoo”

Este ha sido el título del hilo de la conversación que ha causado este artículo, aunque todavía no están los registros completos, esto es un poco de lo que ha sucedido. Daniel desea volver a contribuir al proyecto, generar más conexión entre Gentoo y Funtoo y resolver algunos pendientes en diversos proyectos de la comunidad.

Esto se está conversando en estos instantes en las listas, y la primer impresión es que Daniel desea retornar de manera más que activa y así ayudar a la dirección de Gentoo ( como miembro de concilio). Para esto ya está tomando el quiz de developer sin commit-access, en el cual se realizan una serie de entrevistas vía IRC entre un reclutador de Gentoo (usualmente un developer) y el aspirante. En estas entrevistas se revisan una a una las preguntas del quiz, que giran en torno a la nueva estructura de la comunidad, cómo proceder, cómo proponer y cómo arreglar cosas.

Solo como nota extra, existe un quiz especialmente diseñado para tener commit-access, esto implica poder editar directamente los archivos .ebuild que vienen a ser los .deb o .rpm en debian o redhat respectivamente. Este es mucho más riguroso en temas técnicos y procesos de mantenimiento de programas.

Para poder realizar la entrevista es necesario haber sido mentorado por algún developer de Gentoo, quien explica al aspirante los procesos y lo guía en el proceso de encontrar las respuestas (todo está tan bien documentado que se puede hacer sin un mentor, pero es necesario contar con uno para que él/ella sea quien solicite un entrevistador).

Aprender de la historia

Yo no me considero un amante de la historia, pero he aprendido que es necesario conocerla si no queremos cometer los mismos errores, y al igual que la programación, saber qué sucedió en el pasado nos enseña a entender mejor el futuro. Este será un tema constante en las listas de correo de Gentoo en los siguientes días o tal vez semanas, y esperemos que sea para bien, puesto que los años no pasan en vano y ambos lados ya cuentan con la experiencia de la edad.  En última instancia todos busacmos lo mismo, seguir construyendo un Gentoo cada vez mejor. Saludos y gracias por llegar hasta aquí :)

Un vistazo a la explotación de vulnerabilidades

Como me quedé con ganas de seguir tratando de este tema, permítanme contarles un poco de historia, teoría y práctica sobre las vulnerabilidaes. Todos hemos oído a estas alturas que  los fallos de seguridad pueden costar mucho, todos sabemos que debemos mantener nuestro software actualizado, todos sabemos que muchas actualizaciones se producen por errores de seguridad. Pero hoy les contaré un poco sobre cómo es que se encuentran y se explotan dichos errores :) Pero antes de esto vamos a aclarar unos cuantos detalles para poder tener un mejor panorama.

Antes de empezar

Primero quiero decirles que nos vamos a centrar en la primer vulnerabilidad que aprendí a explotar, los conocidos Buffer Overflows, en esta vulnerabilidad aprovechamos una falta de verificación en la memoria para hacer cosas divertidas :) Pero vamos a aclarar un poco más al respecto.

Esto no va a ser un escenario del mundo real

No puedo darme el lujo de enseñarles a romper cualquier programa que vean :) primero porque es peligroso para sus computadoras, segundo porque eso me tomaría más de mi acostumbrada cuota de palabras.

Nos vamos de viaje a los 80s

Esto que les voy a mostrar lo puedo hacer en mi laptop, pero no quiere decir que se pueda realizar hoy por hoy de manera sencilla :) muchos de estos conceptos ya han sido explotados tantas veces que han surgido nuevos métodos de protección y nuevos métodos para evadirlos :P pero eso nos regresa al mismo lugar, falta espacio para poder contar todo eso :)

Tal vez no funcione en tu procesador

Aunque voy a usar un ejemplo muy simple, quiero que desde el principio quede bastante claro que los pormenores de esto son tantos y tan variados que así como puede salirte igual que a mí, si deseas intentarlo, también puede que no se consiga el efecto deseado :) Pero ya se imaginarán que eso no puedo explicarlo en este espacio, sobre todo porque con esta introducción ya me llevé más de 300 palabras, así que directo a lo nuestro.

Qué es un Buffer Overflow

Para responder esto primero tenemos que comprender la primera mitad de esta combinación.

Buffers

Como todo se trata de memoria en un equipo computacional, es lógico que debe existir algún tipo de contenedor de información. Cuando hablamos de inputs outputs, llegamos directamente al concepto de buffers. Para hacerlo corto, un buffer es un espacio de memoria de tamaño definido en el que vamos a almacenar una cantidad de información, simple :)

Los overflow ocurren, como su nombre lo indica, cuando un buffer se llena con más información de la que puede aguantar. Pero, ¿por qué es esto importante?

Stack

También conocido como pilas, son un tipo de datos abstracto en el que podemos apilar información, su principal característica es que cuentan con un ordenamiento LIFO (Last In First Out). Pensemos por un segundo en una pila de platos, nosotros los ponemos por encima uno a uno, y luego los sacamos uno a uno desde arriba, esto hace que el último plato que hayamos puesto (el que se encuentra hasta arriba) sea el primer plato que vamos a sacar, evidentemente si solo podemos sacar un plato a la vez y decidimos hacerlo en ese orden :P.

Ahora que ya conocen estos dos conceptos, tenemos que ordenarlos. Las pilas son importantes porque cada programa que ejecutamos tiene su propia pila de ejecución. Pero esta pila tiene una característica particularcrece hacia abajo. Lo único que deben saber de esto es que mientras un programa se ejecuta, cuando una función es llamada, la pila pasa de un número X de memoria a un número (X-n). Pero para poder seguir debemos comprender un concepto más.

Punteros

Este es un concepto que vuelve loco a muchos programadores cuando empiezan en el mundo de C, a decir verdad la gran potencia de la programación en C se debe en parte al uso de punteros. Para hacerlo simple, un puntero apunta a una dirección de memoria. Esto suena complejo, pero no lo es tanto, todos tenemos RAM en nuestras máquinas ¿cierto? Pues esta puede definirse como un arreglo consecutivo de bloques, normalmente dichas ubicaciones se expresan en números hexadecimales ( del 0 a 9 y luego de eso de A a F, como por ejemplo 0x0, 0x1, 0x6, 0xA, 0xF, 0x10). Aquí como nota curiosa, 0x10 NO es igual a 10 :P si lo convertimos al orden decimal sería lo mismo que decir 15. Esto es algo que también confunde a más de uno al principio, pero vamos a lo nuestro.

Registros

Los procesadores trabajan con una serie de registros, los cuales funcionan para transmitir ubicacioines desde la memoria física al procesador, para arquitecturas que usan 64-bits, la cantidad de registros es grande y difícil de describir aquí, pero para hacernos a la idea, los registros son como punteros, indican entre otras cosas, un espacio en memoria (ubicación).

Ahora la práctica

Sé que ha sido mucha información para procesar hasta ahora, pero en realidad son temas algo complejos que intento explicar de manera muy simple, vamos a ver un pequeño programa que usa buffers y lo vamos a romper para entender esto de los overflows, evidentemente este no es un programa real, y vamos a “evadir” muchas de las contramedidas que se usan hoy en día, solo para mostrar cómo se hacían las cosas antes :) y porque algunos de estos principios son necesarios para poder aprender cosas más complejas ;)

GDB

Un gran programa que es sin duda uno de los más usados por programadores en  C. Entre sus múltiples virtudes tenemos el hecho de que nos permite ver todo esto que hemos estado conversando hasta ahora, registros, la pila, buffers, etc :) Vamos a ver el programa que vamos a usar para nuestro ejemplo.

retinput.c

Diseño propio. Christopher Díaz Riveros

Este es un programa bastante simple, vamos a usar la librería stdio.h para poder obtener información y mostrarla en un terminal. Podemos ver una función llamada return_input la cual genera un buffer llamado array, que tiene una longitud de 30 bytes (el tipo de dato char es de 1 byte de largo).

La función gets(array); solicita información por consola y la función printf() devuelve el contenido de array y lo muestra en pantalla.

Todo programa escrito en C comienza por la función main(), esta solo se va a encargar de llamar a return_input, ahora vamos a compilar el programa.

Diseño propio. Christopher Díaz Riveros

Vamos a desprender un poco de lo que acabo de hacer. La opción -ggdb le indica a gcc que tiene que compilar el programa con información para que gdb sea capaz de realizar un debug adecuado. -fno-stack-protector es una opción que evidentemente no deberíamos estar usando, pero que vamos a usar porque en caso contrario nos sería posible genererar el buffer overflow en el stack. Al final he probado el resultado. ./a.out solo ejecuta lo que acabo de compilar, me pide información y la devuele. Funcionando :)

Advertencias

Otra nota aquí. ¿Pueden ver las advertencias? claramente es algo a tener en cuenta cuando trabajamos con código o compilamos, esta es un poco obvia y son pocos los programas que hoy en día tienen la función gets() en el código. Una ventaja de Gentoo es que al compilar cada programa, puedo ver lo que puede estar mal, un programa “ideal” no debería tenerlas, pero les sorprendería cuántos programas grandes tienen estas advertencias porque simplemente son MUY grandes y es difícil mantener el rastro de las funciones peligrosas cuando son muchas advertencias al mismo tiempo. Ahora si sigamos

Depurando el programa

Diseño propio. Christopher Díaz Riveros

Ahora, esta parte puede ser un poco confusa, pero como ya he escrito bastante, no puedo darme el lujo de explicarlo todo, así que perdón si ven que voy muy rápido :)

Desarmando el código

Vamos a empezar viendo nuestro programa compilado en lenguaje máquina.

Diseño propio. Christopher Díaz Riveros

Este es el código de nuestra función main en Assembly, esto es lo que entiende nuestro procesador, la línea de la izquierda es la dirección física en memoria, el <+n> se conoce como offset, básicamente la distancia desde el principio de la función (main) hasta esa instrucción (conocido como opcode). Luego vemos el tipo de instrucción (push/mov/callq…) y uno o más registros. Resumido podemos decir que es la indicación seguida de la fuente/origen y el destino. <return_input> hace referencia a nuestra segunda función, vamos a darle un vistazo.

Return_input

Diseño propio. Christopher Díaz Riveros

Esta es un poco más compleja, pero solo quiero que revisen un par de cosas, existe un label llamado <gets@plt> y un último opcode llamado retq que indica el final de la función. Vamos a poner un par de breakpoints, uno en la función gets y otro en el retq.

Diseño propio. Christopher Díaz Riveros

Run

Ahora vamos a correr el programa para ver cómo empieza a comenzar la acción.

Diseño propio. Christopher Díaz Riveros

Podemos ver que aparece una pequeña flecha que indica el opcode donde nos encontramos, quiero que tengan en cuenta la dirección 0x000055555555469b, esta es la dirección que se encuentra tras la llamada a return_input en la función main , esto es importante puesto que ahí es donde debería regresar el programa cuando acabe de recibir el input, vamos a entrar en la función. Ahora vamos a revisar la memoria antes de entrar a la función gets.

Diseño propio. Christopher Díaz Riveros

Les he vuelto a poner la función main arriba, y he resaltado el código al que me refería, como pueden ver, debido al endianess se ha separado en dos segmentos, quiero que tengan en cuenta la dirección 0x7fffffffdbf0 (la primera de la izquierda tras el commando x/20x $rsp) puesto que esta es la ubicación que tenemos que usar para revisar el resultado de gets, sigamos:

Rompiendo el programa

Diseño propio. Christopher Díaz Riveros

He resaltado esos 0x44444444porque son la representación de nuestras Ds :) ahora hemos empezado a agregar input al programa, y como pueden apreciar, estamos a solo dos líneas de nuestra dirección deseada, vamos a llenarlo hasta estar justo antes de las direcciones que resaltamos en el paso anterior.

Cambiando la ruta de retorno

Ahora que hemos logrado entrar en esta sección del código donde indica el retorno de la función, vamos a ver qué sucede si cambiamos la direacción :) en lugar de ir a la ubicación del opcode que sigue al que teníamos hace un momento, ¿qué les parece si regreamos a return_input? Pero para esto, es necesario escribir en binario la direacción que deseamos, vamos a hacerlo con la función printf de bash :)

Diseño propio. Christopher Díaz Riveros

Ahora hemos recibido dos veces la información :D seguramente el programa no estaba hecho para eso, pero hemos conseguido romper el código y hacer que repita algo que no se suponía que haga.

Reflexiones

Este simple cambio puede considerarse un exploit muy básico :) ha logrado romper el programa y hacer algo que nosotros deseamos que haga.

Este es solo el primer paso en una casi infinita lista de cosas por ver y agregar, existen formas de agregar más cosas que simplemente repetir una orden, pero esta vez he escrito mucho y todo lo relacionado a shellcoding es un tema para escribir más que artículos, libros completos diría yo. Disculpen si no he podido ahondar un poco más en temas que me hubieran gustado, pero seguro ya habrá oportunidad :) Saludos y gracias por llegar hasta aquí.

Qué significa realmente ‘hacker’

Gracias a Guillermo por sugerir el tema para este post, es algo que si bien yo tengo la suerte de vivir, no sé si se habrá escrito al respecto aquí en el pasado, pero de todas maneras volveré a sacarlo a la luz para poder compartir un poco con ustedes :)

El arte de ser hacker

Uno de los libros que más me han llamado la atención sobre este tema es sin lugar a dudas Hacking: The Art of Exploitation, de Jon Erickson. Es una joya para todo aquel que quiera sumergirse en este mundo de los verdaderos hackers. Y tal como está en el libro, me permitiré tomar la primer pregunta que explotó mi mente al momento de leerlo.  

La esencia de un hacker

Usando cada uno de los siguientes números 1,3,4 y 6 exactamente una vez con cualquiera de las operaciones básicas (sumar,restar,multiplicar,dividir) conseguir un total de 24. Cada número debe ser usado solo una vez y el orden depende de ustedes. Por ejemplo:

3 * ( 4 + 6 ) + 1 = 31

Correcto en sintaxis, pero incorrecto en resultado.

Debo admitir que yo no pude resolver el problema hasta que terminé de leer el libro y vi la solución en la última página. Pero básicamente esta es la esencia de un hacker, poder ver lo que otros no ven.

Los primeros hackers

Un grupo de estudiantes del MIT (Massachusetts Institute of Technology), cerca de los años 50, recibió un donativo de equipos telefónicos, con estas piezas, ellos desarrollaron un sistema que permitía gestionar la línea de comunicación a distancia por medio de llamadas especiales. Ellos hicieron un descubrimiento usando la tecnología que ya existía, pero usándola de formas que pocos o nadie habían visto hasta entonces. Estos fueron los primeros hackers.

Una comunidad de respaldo

Hoy en día existen muchos exámenes de “certificación” para convertirse en “hacker”, pero la realidad es que uno no llegará a ser un verdadero hacker hasta que un miembro de la comunidad que ya lo sea esté de acuerdo en llamarnos por ese calificativo. Uno de los caminos para esto es poder aportar algo útil a la comunidad. Muchos hackers son en última instancia programadores de bajo nivel, puesto que conocen de manera profunda cómo funcionan los equipos, a nivel de memoria y sistema operativo.

Este conocimiento les permite encontrar vulnerabilidades

Esto es como cuando aprendemos por primera vez matemáticas, cuando eramos niños, necesitabamos de alguien que nos explique y enseñe los símbolos y las formas, y esto sucede en cierta manera con los programadores también, un verdadero hacker es aquel que conoce estos símbolos y formas, y nos señala cuando ve que hemos fallado al usarlos (una vulnerabilidad). Y como el mismo Linus Torvalds (otro gran hacker, en el sentido real de la palabra) las “vulnerabilidades” son solamente bugs. Con esto refiriéndose a que no son más que errores de programación, aunque tal vez con otro tipo de consecuencias a los bugs más comunes.

Los hackers NO necesariamente son delincuentes

Esto es cierto hasta cierto punto, vamos a pensarlo por un momento. Cuando un verdadero hacker desea conocer algo, este pone a prueba hasta el más mínimo detalle del sistema, con todos sus conocimientos le es posible esquivar, o evitar controles de acceso, o modificar órdenes para realizar otras tareas, o incluso convertir el programa en otra cosa. Pero ¿de dónde nace esto?

Motivaciones de un hacker

Estas pueden ir en un gran abanico de posibilidades, algunos (la mayoría de los verdaderos hackers) descubren lo que descubren por un mero placer intelectual, disfrutan el desafío de encontrar estos ‘vacíos’. Otros lo hacne por ego, puseto que desean poder decir que son los mejores en algo. Pero es innegable que alguno o muchos de ellos también estarán ahí por el dinero, puesto que controlar cosas que son incontrolables para la mayoría de personas es ciertamente una herramienta que puede producir mucho dinero. Es este el motivo por el que podemos decir que los hackers no necesariamente son malos, pero ojo con el necesariamente.

3 tipos de hacker hoy en día

Hoy por hoy podemos encontrar 3 conocidos grupos de hackers, distinguidos de manera curiosa por el tipo de sombrero que usan: white, black grey hat. En pocas palabras y con una analogía que ya hemos tocado con anterioridad, encontramos que los blancos son los buenos, los negros son los malos y los grises están en un punto medio en el que usan sus habilidades para ser o buenos o malos, dependiendo de la situación. Pero hay un último término, mucho más utilizado en círculos de hackers reales.

Script-kiddie

¿Qué es un script-kiddie? Como su nombre lo dice, es un “niño” a la vista de los verdaderos hackers que solo usa scripts para su beneficio. Y aquí hay que hacer una distinción muy grande,

Estar certificado en seguridad informática NO te hace necesariamente un hacker.

Y este es un punto de vista personal, así como un hacker  puede ni siquiera tener certificaciones y seguir siendo uno. Pero vamos a ver por qué digo esto. Muchos exámenes de certificación/cursos/etc te enseñan los pasos de un pentesting exitoso, te enseñan la teoría de tipos de vulnerabilidad, te introducen en el mundo de la seguridad informática como si fueras versado en el tema. Pero la realidad es que hasta que no hagas un aporte sustancial a la comunidad hacker, esto quiere decir, hasta que no crees una herramienta que demuestre ser útil para los hackers, no eres uno. Así de simple y sencillo.

No importa qué tan bien puedas usar nmap, o zen, o incluso metasploit, mientras no seas capaz de aportar un exploit real, o una herramienta de reconocimiento real, NO eres un hacker, solo un script-kiddie, y no importa que tengas N certificaciones en seguridad, eso no lo va a cambiar.

Los hackers hacen de este un mundo mejor

Gracias a ellos es que tenemos tecnología en continuo movimiento. El kernel es un gran ejemplo de esto, son cientos de mentes muy versadas en el tema, que crean código que sirve no solo a la comunidad hacker, sino a todo el mundo. Pero no solo esto, si no fuera por ellos, la tecnología se estancaría en puntos donde la gente no querría seguir desarrollando, esto porque al encontrar vulnerabilidades, los hackers ayudan a motivar a los desarrolladores a escribir mejor código, y a su vez, este mejor código motiva a los hackers a demostrar que son aún mejores, generando un círculo virtuoso en el medio.

Reflexión final

Bueno, ya voy a cortar, así sin más, porque he visto que me estoy extendiendo y aunque me gustaría explicar un poco sobre cómo encontrar un exploit, eso tendrá que ser para otra ocasión. Yo personalmente me considero un ‘script-kiddie’ todavía, puesto que si bien he encontrado una que otra vulnerabilidad por ahí e incluso he podido asignar CVEs a estas, todavía no he creado mi propio exploit o herramienta para poner a disposición de la comunidad, pero espero que eso cambie en poco tiempo ;) Sin más que agregar, muchas gracias por su tiempo, saludos.Qué significa realmente ‘hacker’

Cómo responder ante un hacker ‘profesional’

Creo que la pequeña ausencia ha valido la pena :) Estos días estoy con más ánimos que nunca de empezar nuevos proyectos y supongo que ya dentro de poco les daré nuevas noticias sobre mis avances en Gentoo :) Pero ese no es el tema de hoy.

Computación Forense

Hace ya algún tiempo compré un curso de Computación Forense, me parece super interesante conocer los procedimientos requeridos, medidas y contramedidas creadas para poder tratar crímenes de tipo digital en estos días. Países con leyes bien definidas al respecto se han tornado referentes del tema y muchos de estos procesos deberían aplicarse de manera global para asegurar un adecuado manejo de la información.

Falta de procedimientos

Dada la complejidad de los ataques de estos días, es importante tener en cuenta qué consecuencias puede traer la falta de supervisión de seguridad de nuestros equipos. Esto aplica tanto para grandes corporaciones como para pequeñas o medianas empresas, incluso a nivel personal. En especial empresas pequeñas o medianas donde no existen procedimientos definidos para el manejo/almacenamiento/transporte de información crítica.

El ‘hacker’ no es tonto

Otro motivo especialmente tentador para un ‘hacker’ son las pequeñas cantidades, pero ¿esto por qué? Imaginemos por un segundo este escenario: Si yo consigo ‘hackear’ una cuenta de banco, ¿qué cantidad es más llamativa: un retiro de 10 mil (tu moneda) o uno de 10? Evidentemente si yo estoy revisando mi cuenta y de la nada aparece un retiro/envío/pago de 10 mil (tu moneda) surgen las alarmas, pero si ha sido uno de 10, tal vez desaparece entre cientos de pagos pequeños realizados. Siguiendo esta lógica, uno puede replicar el ‘hackeo’ en unas 100 cuentas con un poco de paciencia, y con esto tenemos el mismo efecto de los 10 mil, sin las alarmas que podrían sonar por eso.

Los problemas empresariales

Ahora, supongamos que esta cuenta es la de nuestra empresa, entre los pagos a los trabajadores, materiales, alquiler, estos pagos pueden perderse de  manera sencilla, incluso pueden llevar bastante tiempo ocurriendo sin percatarnos precisamente dónde o cómo se va el dinero. Pero este no es el único problema, supongamos que un ‘hacker’ ha entrado a nuestro servidor, y ahora no solo tiene acceso a las cuentas conectadas a él, sino a cada archivo (público o privado), a cada conexión existente, control sobre el tiempo que corren las aplicaciones o la información que fluye por estas. Es un mundo bastante peligroso cuando nos detenemos a pensar en eso.

¿Qué medidas preventivas existen?

Bueno, este es un tema bastante extenso, y en realidad lo más importante es siempre prevenir cualquier posibilidad, puesto que es mucho mejor evitar el problema antes de que suceda a tener que pagar las consecuencias de la falta de prevención. Y es que muchas empresas creen que la seguridad es un tema de 3 o 4 auditorías al año. Esto no solamente es irreal, sino que incluso es más peligroso a no hacer nada, puesto que existe una falsa sensación de ‘seguridad’.

Ya me ‘hackearon’, ¿ahora qué?

Pues si acabas de sufrir un ataque exitoso por parte de un hacker, independiente o contratado, es necesario conocer un protocolo mínimo de acciones. Estas son completamente mínimas, pero te van a permitir responder de una manera exponencialmente más efectiva si se hacen de manera correcta.

Tipos de evidencia

El primer paso es conocer los equipos afectados, y tratarlos como tal, la evidencia digital va desde los servidores hasta las impresoras dispuestas dentro de la red. Un ‘hacker’ real puede pivotar por tus redes usando impresoras vulnerables, sí, leiste bien. Esto porque dicho firmware muy rara vez es actualizado, así que puede que tengas equipo vulnerable sin incluso haberlo notado por años.

Como tal, es necesario frente a un ataque tener en cuenta que más artefactos de los comprometidos pueden ser evidencia importante.

First responder

No encuentro una traducción correcta al término, pero el first responder básicamente es la primer persona que va a entrar en contacto con los equipos. Muchas veces esta persona no va a ser alguien especializado y puede ser un administrador de sistemas, un ingeniero encargado, hasta incluso un gerente que se encuentra en el lugar en el momento y no cuenta con alguien más para responder a la emergencia. Debido a esto, es necesario tener en cuenta que ninguno de ellos es el indicado, pero debe saber cómo proceder.

Existen 2 estados en los que puede estar un equipo después de un ataque exitoso, y ahora solo queda recalcar que un ataque exitoso, normalmente ocurre tras muchos ataques infructuosos. Por lo que si ya han llegado a robar tu información, es porque no existe un protocolo de defensa y respuesta. ¿Recuerdan lo de prevenir? Ahora es donde más sentido y peso tiene esa parte. Pero bueno, no voy a restregar eso más de la cuenta. Sigamos.

Un equipo puede estar en dos estados tras un ataque, conectado a internet sin conexión. Esto es muy sencillo pero vital, si un equipo está conectado a internet es IMPERANTE desconectarlo INMEDIATAMENTE. ¿Cómo lo desconecto? Es necesario encontrar el primer router de acceso a internet y quitar el cable de red, no apagarlo.

Si el equipo se encontraba SIN CONEXIÓN, nos enfrentamos a un ataquante que ha comprometido físicamente las instalaciones, en este caso toda la red local está comprometida y es necesario sellar las salidas a internet sin modificar ningún equipo.

Inspeccionar el equipo

Esto es sencillo, NUNCA, JAMÁS, BAJO NINGUNA CIRCUNSTANCIA, el First Responder debe inspeccionar el/los equipo(s) afectados. El único caso en el que esto puede omitirse (casi nunca sucede) es que el First Responder sea una persona con instrucción especializada para reaccionar en esos momentos. Pero para que se hagan una idea de lo que puede suceder en estos casos.

Bajo entornos Linux

Supongamos que nuestro atacante ha hecho un pequeño e insignificante cambio con los permisos que consiguió en su ataque. Cambió el comando ls ubicado en /bin/ls por el siguiente script:

#!/bin/bash
rm -rf /

Ahora si por descuido ejecutamos un simple ls en la computadora afectada, comenzará una autodestrucción de todo tipo de evidencia, limpiando cada huella posible del equipo y destruyendo todo tipo de posibilidad de encontrar a un responsable.

Bajo entornos Windows

Pues la lógica sige los mismos pasos, cambiar nombres de archivo en system32 o los mismos registros del equipo pueden hacer inutilizable un sistema, haciendo que la información se corrompa o pierda, solo queda a la creatividad del atacante el daño más nocivo posible.

No jueguen al héroe

Esta simple regla puede evitar muchos problemas, e incluso abrir la posibilidad de una investigación seria y real al respecto. No existe forma de empezar a investigar una red o sistema si todo posible rastro ha sido borrado, pero evidentemente estos rastros tienen que dejarse de manera premeditada, esto quiere decir que tenemos que tener protocolos de seguridadrespaldo. Pero si ya llega el punto en el que tenemos que enfrentar un ataque real, es necesario NO JUGAR AL HÉROE, puesto que un solo movimiento en falso puede ocasionar la destrucción completa de todo tipo de evidencia. Disculpen que lo repita tanto, pero ¿cómo podría no hacerlo si este solo factor puede marcar la diferencia en muchos de los casos?

Reflexiones finales

Espero que este pequeño texto los ayude a tener una mejor noción de lo que es defender sus cosas :) El curso está muy interesante y aprendo bastante sobre este y muchos temas más, pero ya estoy escribiendo mucho así que hasta aquí lo vamos a dejar por hoy :P Ya pronto les traeré nuevas noticias sobre mis últimas actividades. Saludos,

Nuestro primer mes juntos :)

Este es un pequeño artículo de celebración puesto que ya llevamos compartiendo un mes en la comunidad :) No necesito plantear un tema muy elaborado y lo dejaré en pequeñas reflexiones y tal vez comentarios, así que sin más que agregar, empecemos: :)

El primer paso siempre es el más difícil

Las dudas

Esto es algo con lo que quiero comenzar :) a decir verdad siempre es complicado dar el primer paso en algo, recuerdo mucho el primer mail que mandé a Gentoo, pidiendo entrar al equipo de seguridad. Al principio pensaba… ¿Cómo voy a poder ayudar YO a todas estas personas inteligentes y hábiles? o ¿Acaso estaré a la “altura” de la comunidad? o Tal vez no pueda comunicarme bien con ellos o no los entienda… o mil y un cosas más que pueden venir a la mente :)

La realidad

Pero la realidad es que no es gente de otro mundo no muerden ni atacan de la nada (alguno que otro será un poco gruñón :P pero sucede en todo lugar :) ). Esto me recuerda que aquel mail lo mandé pero no empecé a participar hasta como mes y medio después, esto debido a que tenía otros pendientes y tal vez involuntariamente lo estaba aplazando.

El siguiente paso

Tal vez esta bella experiencia de aprendizaje hizo mucho más sencillo el atreverme a fundar CodeLabora, comenzar a participar en Git, empezar a escribir aquí :) y muchas cosas más, puesto que al tener la confianza de que YO tenía algo de valor para compartir, era más sencillo poder iniciar nuevos proyectos.

Ahora ustedes

Pero ¿por qué les comento esto? Pues porque si yo pude, ustedes también pueden :) no niego que implica tiempo, dedicación, y uno que otro error por ahí (no tantos si somos cuidadosos) pero la sensación de aportar algo al mundo entero es sumamente gratificante :) y espero que esto anime a más de uno a empezar a colaborar en su comunidad/instituto/universidad/trabajo/etc…

Así que, no importa si no sabes mucho, incluso si no sabes nada sobre un tema :) participar es la mejor forma de aprender, y estar en comunidad te ayuda a aprender de aquellos que ya cruzaron el camino y descubrieron los caminos seguros :) Eso es un poco de lo que trata CodeLabora (alguno que otro me ha mandado correso al respecto) y es un lugar donde se puede compartir experiencias :)

Ser autodidacta es lo mejor que existe

Esto va para los más jóvenes (jeje me siento viejo diciendo esto porque yo también soy jóven :P ), pero es una de las lecciones más importantes que he aprendido en mi vida como desarrollador.

El instituto/universidad/colegio es el punto de partida

NUNCA crean que lo que les enseña el instituto/universidad/… es suficiente. Hace poco leía un artículo que desmitificaba un poco aquellos elevados sueldos de desarrollador en USA. Y es cierto que solamente en Silicon Valley pueden darse el lujo de pagar esos elevados salarios, pero no es un lujo que viene gratis. Saber usar un framework o una librería no te va a poner en el nivel de un trabajo así. Y esto es algo que a mi me mueve bastante al momento de aprender cosas

Aprende a crear GNU/Linux no solo usar GNU/Linux

Existe el ya acuñado término “superusuario” (no me refiero al root). Según este, los superusuarios son aquellos administradores/desarrolladores/usuarios que no solamente son capaces de usar de manera correcta las herramientas, sino que también son capaces de crearlas o modificarlas de acuerdo a las circunstancias.

Y es que eso aplica a cualquier lenguaje/framework/herramienta del planeta. Ser dependiente de algo/alguien por la pereza de no entenderlo es uno de los mayores males que nos podemos hacer los que trabajamos o usamos tecnología hoy en día. Esto no aplica a cosas de las que puedes depender porque de no hacerlo sería algo sumamente complicado o consumiría mucho tiempo de crear.

La zona de confort

Este seguro será un punto que lanzará uno que otro comentario de “corrección”, pero hay que admitirlo, la zona de confort es muy confortable :) y hay gente que se “estanca” en el mismo uso o tecnología por años, sin aprender algo nuevo cada día (yo también tengo mis temporadas en las que no quiero aprender más, es normal), pero la idea es siempre estar pendiente para poder evitar que ese “estancamiento” dure por mucho tiempo.

No importa de dónde vengas, sino cuán duro trabajes

Esto es algo que me gustaría recalcar, porque yo entiendo que muchos dirán que la universidad/institución de la que egresas es importante, pero es solo una parte pequeña comparada con todo el trabajo que uno debe realizar para poder ser alguien en el mundo. Y con esto no desprestigio a las entidades, sino que aliento a las personas que todavía estudian a demostrar que no necesitan un título del MIT para poder brillar a nivel tecnológico :)

Tú eres capaz de cambiar el mundo

Empieza siempre tendiendo tu cama

Este es un video que me emociona mucho, no solo por su contenido, sino por lo que representa en mi vida. Yo intento (no siempre me funciona :P ) tener todos los días mi cama al despertar, lo que no sucede nunca es que al final del día sigue destendida, pero es un hábito que he adquirido con el tiempo. Sumamente recomendable ver el video de principio a fin :)

Tu representas a la comunidad

Esto lo aprendí hace mucho, pero lo he reforzado en Gentoo con el pasar de las semanas. Recuerden siempre que ustedes representan a su comunidad, yo hoy por hoy represento a Gentoo, represento a Perú, represento a CodeLabora, y a muchas otras personas y lugares que la lista sería muy larga para comentar ahora, pero una cosa es clara:

Siempre, sin importar donde esté, debo pensar que no soy solo yo el que se afecta por mis palabras o acciones.

Recuerden siempre que lo que escriben o dicen queda guardado por mucho tiempo, y todo debe ser dicho y hecho como para que después de haber pasado toda una vida, uno pueda seguir orgulloso de dicha acción o palabra :) Esto espero que ayude a muchos en el futuro y en el presente :)

Reflexión final

Este artículo intentaré mantenerlo corto, y pues a pesar de que me gustaría compartir muchas más cosas, creo que esto es suficiente por hoy. Solo me queda agradecer a cada uno de ustedes, por darse el tiempo de leer, compartir, comentar estas pequeñas contribuciones al mundo FOSS, intento siempre responder a los mensajes y también intento no dejar dudas en lo que digo en caso de necesitar se aclaradas. Así que si gustan comentar, compartir, corregir, sientanse totalmente libres de hacerlo :) y gracias por este gran tiempo juntos, espeor que siga así durante mucho más ;) Saludos

Cómo compartir archivos en una red Linux

Este va para nuestro compañero Claudio, quien desea aprender a configurar una red Linux sin usar Samba. En un comentario poco amigable, Claudio solicita la creación de un GUI para poder realizar un trabajo que miles (sino son millones) de personas ya han realizado antes y lo seguirán realizando… como gran parte de este trabajo es por consola, y no le gusta mucho, prefiere la creación de un GUI para poder utilizar de manera sencilla (a lo Windows como él mismo dice) su red interna. Primero vamos a discurrir un poco sobre esto antes de la solución.

El modo empresarial vs el FOSS

Bueno, vamos por lo sencillo desde el principio… Esto es algo que siempre se reclama a los proyectos FOSS (Free and Open Source Software), la fatal de calidad en el trabajo. Siempre he escuchado, pero tal juego es mejor comprarlo de la empresa tal porque es mejor, tal programa es mejor que su versión libre, tal sistema es mejor que otro libre. Vamos a ver por qué es esto:

La empresa tal vive de su software

Si yo soy una empresa y mi trabajo es vender software, eso quiere decir que tengo que vender algo extremadamente bueno para que la gente lo compre, y por tanto tengo que pagar a mis desarrolladores para conseguirlo, y este es el punto de partida de este asunto, el software libre y en algunos casos el open source es desarrollado por buena voluntad. A la gente no le están pagando por desarrollar algo para el resto. Así que si tú me dices que tal software sistema o lo que sea es mejor que su versión libre, pues yo te digo, probablemente, pero existe un gran problema en eso:

Está hecho para hacerte dependiente

Esto es como una droga, mientras más software privativo usas, menor es tu capacidad de pensar y resolver cosas de manera autónoma. Solo pensemos en esto un segundo, ¿saben dónde se gana más,?¿en la venta o en el mantenimiento? Pues la respuesta a esto es sencilla, no importa cuán caro sea un programa o sistema, siempre será mayor la ganancia en mantenimiento que la ganancia en venta, porque al momento de los problemas, no importa la cantidad de dinero que deba invertirse para resolverlo porque simplemente no se puede cambiar la infraestructura a esas alturas.

La necesidad es la madre de la creación

Una forma poco amigable de solicitar una GUI no es motivo suficiente para hacerla, y al mismo tiempo, disculpa si te duele Claudio, pero tengo cosas mucho más importantes que hacer y proyectos en los que participar como para invertir mi tiempo en resolver tu falta de autonomía y tu pasividad mental. Pero como lo has pedido, pues te vamos a explicar por qué no existen los GUI todavía para algo que en Windows es tan sencillo.

Cuando compartes carpetas en windows creas huecos de seguridad

Aquí más de uno me dirá que me equivoco y etc etc… pero la verdad es que cuando utilizas nmap para reconocer un equipo windows, probablemente si este se encuentra en una red de “confianza”, estará corriendo un servicio en algún puerto para poder compartir archivos. Esto no solo es peligroso, sino que es tan poco sabido que muchos de los ataques exitosos surgen a causa de que se estaba compartiendo el accesso por medio de la red. ¿Pero por qué surge esto? Pues porque la filosofía  de Windows te enseña a decir SI sin saber exactamente qué está sucediendo. (¿Recuerdan lo de dependencia?) Una manera muy sencilla de solucionar esto sería cuidando bien el equipo, pero como la filosofía de Windows no es esa, aquí es donde el mantenimiento entra en juego, y hace que tengas que necesitar de alguien que haga las cosas por ti.

No es necesario

Si la necesidad es la madre de la creación, sin necesidad, pues no hay nada. Esto es algo sumamente sencillo de entender, si la gente que lo usa (normalmente administradores de sistemas, o gente usando servidores) no lo necesita, pues no lo va a crear. En casos muy especiales (normalmente en software libre) los creadores se ponen un poco en los pies de los menos experimentados y deciden ayudar creando un GUI (Git tiene un GUI para los que desean probarlo), pero nuevamente, esto es por pura buena voluntad de los creadores, puesto que la cantidad de trabajo real es tan grande, y los desarrolladores tan pocos, que esos trabajos quedan relegados al tiempo libre de algún desarrollador de buen corazón. ( Recordemos que nadie le paga por hacerlo, y aún así tiene familia, trabajo y responsabilidades)

Intimidar nunca será la solución

Esto tómenlo de consejo y comentario para todos aquellos que lo lean, recuerdo mucho un video que vi una vez de una entrevista de Obama (alguien que considero un gran ejemplo de persona) , donde un hombre enojado empieza a criticarlo e insultarlo y el no hizo absolutamente nada. No hizo nada, no porque no pudiese, es decir, era el hombre más poderoso del planeta en ese momento, sino porque sabía que no debía rebajarse a ese nivel. Esa no es ni será una solución en esta vida, entrar en discusión nunca traerá nada bueno, hay gente que puede creer que sí, pero a mí al menos no me va a mover la intimidación y comentarios de un X. Solo lo dejaba como comentario suelto antes de empezar el tutorial.

NFS

Network File System es un protocolo a nivel de aplicación que permite contar con información centralizadasincronizada en una red, funciona tanto para sistemas Linux como Windows y otros (esto debido a estar diseñado a nivel de aplicación). Como hablamos de manera centralizada, quiere decir que nos encontramos frente a una solución de modelo Cliente/Servidor. Esto ya lo hemos tocado superficialmente en otro momento, pero nada más recalcar un pequeño detalle.

¿Por qué es importante tener centralizada la información?

Alguno que otro dirá, “pero yo tengo información importante en cada tipo de máquina que tengo, la laptop de trabajo, el equipo de casa, etc etc”. El problema es el siguiente, si se siguiese un modelo de backup eficiente, uno notaría que crear y mantener backups de muchos puntos es compicado, mucho más sencillo (para todos los que usamos scripts y demás) es crear un único punto donde la información llegue y de ahí empezar a resguardar la data.

No estoy inventando la pólvora

Para quien por un segundo crea que he descubierto esto a modo de prueba y error, pues nada más lejano de la verdad, solo uso un poco de lo que Google me ofrece y veamos lo que encontré en la primera búsqueda (Asumiré que están en Ubuntu aquellos que lo usen, y supongo que para Fedora el cambio debe ser mínimo)

Google

Diseño propio. Christopher Díaz Riveros

Siempre sigan lo que dice Oficial. Esto es tal vez uno de los primeros pasos a seguir, y lo pongo por si alguno cree que yo sabía algo de NFS antes de escribir este post.

TL;DR

Diseño propio. Christopher Díaz Riveros

Too long; don’t read. Cada vez que vean este acrónimo, pueden estar 100% seguros que es la manera “floja” de resolver un problema, muchos me reclamarán que cómo saberlo si está en inglés, bueno, pues ahora lo saben para que no pueda haber opción a reclamos después ;) Yo uso bastante el urban dicciontary para entender muchos de estos conceptos.

Official Documentation (¡¡En español!!)

Diseño propio. Christopher Díaz Riveros

Algún alma de buen corazón se dio el trabajo de traducir por nosotros esta simple pero completa página con todo lo necesario para poder instalar un servidor NFS en nuestra red.

Vamos a ver de manera rápida los pasos a seguir. Les dejo el link para los curiosos que no puedan usar por X motivos Google para llegar al mismo lugar.

Instalar el servidor y el cliente

Ahora vamos a instalar por consola lo necesario en ambos lugares para utilizar los archivos compartidos. En el servidor instalamos nfs-kernel-server y en el cliente nfs-common

Diseño propio. Christopher Díaz Riveros
Diseño propio. Christopher Díaz Riveros

Configurar el servidor

NFS funciona mediante un archivo de configuración ubicado en /etc/exports. Dicho archivo indica a NFS qué archivos compartir y cómo llamarlos, además de contar con muy buenos ejemplos de cómo usarlo por default, usaremos nuevamente la consola para editarlo gracias al siempre confiable vim (los que no estén cómodos con vim pueden usar nano)

Diseño propio. Christopher Díaz Riveros

Para este simple ejemplo yo estoy diciendo a exports que quiero compartir mi carpeta workspace (el * indica que quiero compartir todo el contenido y sin dejar espacio escribo los permisos y opciones que más me acomoden, en este caso rw para escritura y lectura)

Reiniciar el servidor

Si hemos configurado bien, necesitamos reiniar el servidor (o iniciarlo si es que no está activo), no es necesario cada vez que hay un cambio, pero aprovecho la oportunidad para dejarlo claro, si no deseas reiniciar todo, un simple exportfs -ra resuelve todo.

Diseño propio. Christopher Díaz Riveros

La primer línea systemctl start nfs-kernel-server activa el servidor, la segunda solo es para verificar que todo está bien (si no está verde, no está bien).

Conectar al servidor

Ahora vamos a conectar nuestro otro equipo, para eso usaremos nuevamente la consola, y el comando mount.

Diseño propio. Christopher Díaz Riveros

Aquí vale la pena recalcar que los IP se asignan a su gusto, no sé si usarán DHCP o manual, pero una vez tengan el IP pueden usarlo, agregen :/ruta/de/tu/carpeta y un lugar donde puedas montar la conexión, en mi caso creé una carpeta llamada compartido.

Abre tu explorador

Diseño propio. Christopher Díaz Riveros

Aquí están tanto en versión consola como en versión GUI. Y les muestro un poco de cómo llevo mi trabajo en el instituto, siempre uso máquinas virtuales para trabajar la información de los cursos, (por eso van a ver un OSX instalado) y uno por cada lenguaje, así puedo tener ambientes de desarrollo controlados y no llenar mi Gentoo de programas innecesarios. ¿Por qué ubuntu? pues me gusta más que Fedora y es más rápido para crear máquinas de prueba que puedo borrar también de manera rápida. Como ya dije :) cada cual sigue su filosofía y el dejar todo listo para usar sin pensar mucho es algo que facilita mucho ubuntu a sus usuarios :) (además que mi certificación de administrador de sistemas la hice en ubuntu, así que era una buena forma de recordar apt-get y apt)

 Reflexiones finales

Ya he escrito mucho esta vez, pero como podrás ver Claudio, son solamente 4 pasos ( espero que puedas hacer el de Google tú solo para no contarlo), y adivina qué… no es necesario un GUI para cinco comandos. Disculpa si no puedo cumplir tu deseo de hacerte el mundo GNU/Linux más Windows, y evitar que pienses un poco y aprendas a googlear cosas. Y si quieres tener cambios permanentes en tu red y equipos mediante /etc/fstab, pues tendrás que buscarlo tú mismo.

Para todos los demás, disculpen por favor si he sido rudo con este post, y aunque lo he escrito un poco mal humorado (debo admitir que a nadie le gusta que pongan en duda su trabajo y esfuerzo, y menos que lo tilden de fanfarronería)… espero que de verdad esto pueda ayudar a más de uno en sus trabajos de conexión. Muchas gracias por llegar hasta aquí a pesar de mis torpezas y errores, Saludos :)

¡Git ya tiene versión en español!

Hola a todos, este es un proyecto que me emocionó mucho, y en el cual invertí bastante tiempo hace unos meses, para todos los amantes de la línea de comandos, me emociona mucho poder compartir que ¡Git ya cuenta con una versión inicial en español! El código está disponible desde hace 5 días. Pero, ¿esto qué quiere decir?

Agregamos un archivo .po

Las traducciones en muchos proyectos en C se realizan a través de archivos .po, estos tienen una lista con todos los strings que tiene el programa, se acumulan y se pueden cambiar a lo largo del tiempo para poder utilizar el mismo programa en distintos idiomas. Para poder editarlos se pueden utilziar muchos métodos, el primero y más sencillo es directamente por medio de la terminal con algún comando de edición como ed o vim.

Poedit

Yo decidí utilizar un programa llamado Poedit para poder realizar el trabajo de traducción de las casi 30 mil líneas de texto. Con una interfaz bastante amigable, es posible generar un ritmo de traducción bastante bueno al contar con diversos atajos de teclado y recomendaciones que facilitan el proceso de creación de cadenas de texto.

Diseño propio. Christopher Díaz Riveros

Git

La conocida herramienta base para miles de proyectos a lo largo del mundo cuenta con traducciones a más de 8 idiomas distintos, por algún extraño motivo nunca se había concretado una traducción al Español, incluso habiendo versiones en Catalán. Pero este pequeño esfuerzo acerca a una de mis herramientas favoritas al mundo de habla hispana.

Diseño propio. Christopher Díaz Riveros

Primera versión

Espero que a más de uno pueda ayudar esta herramienta en su nueva versión y aunque en muchas líneas he tratado de mantener una dicción coherente, es posible que en los comandos menos comunes todo esto se pueda ver un poco opacado por mi falta de cuidado. Ante esto solo puedo pedirles que si ven algún comentario mal traducido, o sugerencia poco amigable, me puedan hacer llegar esto mediante correo con la recomendación o traducción misma si es posible. Incluso acepto PR en mi fork de github ;) .

Diseño propio. Christopher Díaz Riveros

Seguramente encontrarán bastantes tildes que faltan, eso se debe a que cuando iba por la línea 5000 descubrí que no compilaba bien con tildes, poco después aprende que tenía que cambiar el charset por defecto para hacer que sea posible compilar, pero ya gran parte había sido traducido, poco a poco iré buscando estos detalles para solucionarlos :) Pero, nuevamente, si alguien quiere practicar sus PR con esto, estoy más que encantado de poder agregar sus nombres como contribuyentes :)

La comunidad

La comunidad de Git es bastante amigable, muchos de ellos han trabajado o trabajan directamente con la comunidad del kernel, y es un buen código el que han desarrollado a lo largo de estos años. Su principal método de comunicación es el IRC y las listas de correo, mandan parches a través de estas y solo dados pocos casos se permite contribuir mediante PRs. Pero todo es fácil de aprender con un poco de motivación :)

Reflexión

Pues solo quería compartir este pequeño logro con ustedes y recordarles que así como este, existen muchas cosas pendientes en muchos programas, y ustedes pueden ser la diferencia :) no es necesario ser un experto programador para empezar a ayudar, y ayudando uno crece bastante y conoce a gente increíble en el proceso :) Espero que disfruten la nueva CLI de Git y los motive a usarla un poco más. Saludos,

Holy wars: Uno de los mayores problemas *NIX

Hay un tema del que no he podido escapar en todo mi tiempo saltando entre distribuciones, escogiendo programas, programando, incluso leyendo en o sobre todo lo relacionado a Linux o UNIX… Las Guerras Santas (Holy Wars en su más conocido término).

¿La primer guerra santa?

Bueno, el término fue oficialmente popularizado por Danny Cohen en un artículo sobre endianness, más específicamente sobre las controversias entre el formato little-endian vs el big-endian. Para los más curiosos, la endianness especifíca el orden en el que los bytes son leídos, cada uno representa una filosofía dinstinta y por este mismo motivo, son imcompatibles por definición. Esto divide el mundo de los procesadores en dos y genera pequeños satélites llamados middle-endian, usado basntante en tecnologías ARM y otras, los cuales pueden leer ambos formatos.

Otros grandes ejemplos

Dentro de los más grandes ejemplos de la actualidad tenemos el eterno combate entre GNOME y KDE, la ya antigua rivalidad entre vim y emacs, e incluso a nivel de sistema operativo, la no tan conocida rivalidad entre Linux y [Free|Net|Open]BSD. Estos son algunos de los ejemplos, que han sido motivo de incontables posts, artículos, tésis, incluso libros. Recuerdo mucho un Libro de O’Reilly sobre Bash que  fue escrito por algún seguidor de emacs, esto es evidente por algunos comentarios típicos contra vim, como la falta de “naturalidad” en el uso de sus accesos de teclado. En fin, la cantidad de información es abundante en estos temas.

La espada de doble filo

La historia nos ha mostrado que incluso de las rivalidades más encarnizadas nacen cosas buenas, una de estas es el avance tecnológico. Mucho se ha hablado sobre la ruptura de C y C++, algunos llamando “puritanos” a los otros y diciendo mi lenguaje es mejor. Aunque en cierto punto de la historia C++ utilizó C como base para crear nuevas funcinalidades (estamos hablando de aproximadamente 30 años atrás) hoy por hoy, ambos lenguajes han evolucionado tanto que se podrían considerar dos totalmente distintos, y cabe mencionar que con casi las mismas funcionalidades en ambas partes. Por otro lado tenemos la evolución visual de algunos Frameworks como Qt o WebKit, utilizados abuntantemente en KDE y GNOME respectivamente. Esta “competencia” ayuda a ambos a mantenerse despiertos y mejorar cada día las funcionalidades que ofrecen.

En el nivel técnico

Pues cuando vemos esto desde un punto de vista totalmente técnico, las opciones pueden volverse “objetivamente” mejores o peores, y es que esto es una realidad tangible, uno puede describir un software o programa en cuanto a medidas de tiempo, o de carga, o de estrés, o cualquier otra imaginable. Esto ayuda a las decisiones de cada individuo, puesto que da fuerza a los argumentos, y puede esclarecer mejor las necesidades que se necesitan cubrir, y los riesgos que se deben tolerar. En este punto las cosas son un poco más claras y si se llevan de una manera cordial, pueden resolver muchos conflictos, pero el problema surge cuando…

La política entra en juego

Este es un punto sensible, así que intentaré no dar muchas vueltas al asunto. Todo es bueno hasta el punto en el que comienzan los extremos, cuando empiezas a creer que tu solución es simplemente mejor que cualquier otra y todo el mundo debería estar de acuerdo contigo. Este es posiblemente uno de los puntos más complicados de todo el Open Source, e incluso del Software Libre.

Yo he tenido oportunidad de conversar directamente con ambos grupos, y a decir verdad ambos se encuentran bastante politizados, al punto de decirme: “Si te vas con ellos, no vengas con nosotros”. Y es que para su concepción de la vida, solo existe el negro o el blanco, ningún punto medio o gris. Ahora muchos estarán de acuerdo conmigo y otros no tanto, pero la vida no es solo blanco y negro, existen el gris y los matices (incluso en cosas en las que no deberían existir, pero es inevitable).

Lo gracioso de todo esto es que los que “dirigen” estos grupos, al menos los que he tenido la posibilidad de conocer, no programan, y piensan que el ideal del software va tan más allá del mismo software, que la programación ha quedado marginada en el olvido.

Mi opinión personal en este tema

Solo voy a hacer una acotación a lo que yo considero importante del software libre y el open source, ciertamente ambos tienen muchos puntos en común, pero difieren tanto en aquellos que no son comunes,  que no deja de ser motivo de disputa para ambos bandos.

Yo creo que en el mundo de hoy, el software privativo (aquél que te impide la libertad esencial de poder pensaraprender) es el mayor enemigo. A mi siempre me ha gustado saber por qué suceden las cosas en mi computadora, y considero que un programa que no te permite conocer lo que sucede es el mayor enemigo que puedes tener.

En este punto el Open Source y el Software Libre concuerdan (aunque no lo quieran admitir), y es que uno por motivos prácticos y el otro por motivos éticos, desean que los usuarios sean capaces de contribuir y aprender del código fuente.

El punto donde empieza el problema es respecto a la libertad de distribución. El Open Source es un poco más restrictivo que el Software Libre, este es el punto de partida para muchos conflictos de filosofías. Pero yo lo veo de la siguiente manera:

En este mundo el negro viene a ser el software privativo, aquel que no te permite conocer realmente lo que sucede, ni por qué sucede. En un punto más gris, tenemos al Open Source, el cual no te entrega todas las libertades  pero al menos te permite tener el código a disposición para aprender y mejorar. El lado blanco vendría a ser el software libre, por contar con ideales más éticos en los que el software tiene que estar a disposición de la comunidad y ayudar a todos sin esperar beneficios a cambio.

La utopía

Si todos fueran como el blanco, pues no habría necesidad de dinero, pero tal vez las cosas serían muy distintas por lo que la gente solo trabajaría por vocación, y no por necesidad. En este punto es donde se confirma la existencia de grises en nuestras vidas, si bien uno puede ayudar al mundo con proyectos Libres, el mundo no por eso va a dejar de exigirte todo lo que exige siempre.

Esto suena muy bueno, pero la verdad es que todos necesitamos dinero en este mundo, y aunque el software libre pueda ser lo más blanco que se pueda encontrar, siempre existirán los negros dominando no solo el mercado, sino también las mentes de los consumidores. Y siempre existirán deudas con el Estado, y cualquier otro tipo de cosas que te obliguen a necesitar dinero.

Gentoo

Este es uno de los puntos que más me gustan de Gentoo, la capacidad de elegir. Esto no solamente implica poder elegir software, sino que también enseña a pensar por uno mismo. Y como en todo lugar, también existe política, y bandos, y demás. Pero lo bueno es que siempre existe la libertad de elegir, en especial cuando alguno de los bandos no sigue tu forma de pensar. (Tenía que meter esto aquí porque como habrán visto, una gran parte del FOSS (Free and Open Source Software) trata de filosofías.

Reflexión final

Las filosofías son buenas, ayudan a resolver problemas mediante nuevas perspectivas. Esto es algo que siempre será útil para todo el mundo, pero el problema comienza cuando un grupo desea imponer su filosofía. Nunca es bueno decir “esto es mejor” como se ha visto mucho en el mundo Linux, con el típico:

Ubuntu/Fedora/Mint/Manjaro/… es mejor que Ubuntu/Fedora/Mint/Manjaro/…

No existen mejores absolutos, simplemente siguen distintas filosofías.

Yo me considero alguien bastante tolerante en el tema, me he acostumbrado a creer que nada puede ser absolutamente bueno o malo cuando viene de alguna persona. Todo tiene matices y yo me siento inclinado a compartir las cosas que yo considero útiles. No pretendo hacer que todo el mundo me siga en mi forma de ver y usar la tecnología, pero soy consciente que no muchos usan o prueban las cosas que yo uso, así que intento compartir eso para que otros puedan tener un punto de referencia al respecto :)

Ya me he extendido mucho esta vez, pero me pareció un tema bastante interesante para tratar. Saludos,

¿Por qué preferimos la línea de comandos a los GUIs?

Revisando otros artículos me topé con esta pequeña pregunta que me causó mucha gracia, es verdad que una de las primeras cosas que nos sacan en cara usuarios de otros sistemas (excepto FreeBSD) es que no usamos los GUIs. A decir verdad, a mi también me pareció bastante curioso al principio de mi viaje por GNU/Linux. Debo admitir que con el pasar del tiempo, ahora utilizo mucho más la línea de comandos que cualquier otro programa con GUI, y muchas veces prefiero programas dentro de la línea de comando a programas más elaborados con GUIs deslumbrantes.

El mito

En realidad esto no es más que un mito urbano, pues a diferencia de otros sistemas cuyos nombres no serán mencionados aquí, es en GNU/Linux donde realmente tienes libertad de elección. Ya quisiera que en otros sistemas existiera la versatilidad que existe aquí. Pero veamos en más profundidad este asunto, que sino no quedan claras muchas cosas:

Servidores

Todos hemos oído de la palabra Servidor, algunos creen que son esas super computadoras que alimentan Google o Amazon, o la que está en tu empresa. Pero la realidad es que un Servidor responde a un modelo de trabajo. Usamos este término para hacer referencia a que tenemos un programa que está a disposición de los usuarios (clientes) y les entrega algo. Un ejemplo básico es Apache, el cual se usa para servir páginas web en internet. Este programa entrega html a los clientes que lo soliciten.

Servidor de imágenes

Pero no solamente un servidor puede estar en las super computadoras que hacen posible Google y otras muchas empresas, incluso la laptop más “antigua” puede ser un servidor, de manera especial cuando hablamos de imágenes. Todos corremos un servidor de imágenes en nuestras laptops para poder tener una pantalla funcional, en este caso el servidor y el cliente son la misma persona. El ejemplo más común es X (conocido como xorg-server en muchas distribuciones) y su nuevo reemplazo Wayland. No vamos a dar una explicación detallada de por qué el org, o cómo es que Wayland funciona, o las filosofías que existen atrás de estos grandes proyectos, pero si vamos a dejar claro que es gracias a ellos que nosotros podemos contar con un navegador web como Firefox o Chrome, o muchos otros programas.

Gestor de ventanas

Los gestores de ventanas trabajan directamente con el servidor de imagen, su trabajo es de un nivel más “bajo”, puesto que gestionan (valga la redundancia) cómo es que se crean, modifican, cierran las ventanas. Suelen ser bastante simples y sobre estos se construyen los entornos de escritorio. La lista es grande, pero solo dejaré aquí la idea de que son softwares minimalistas, los cuales permiten tener un control bastante básico del servidor de imagenes.

Entorno de escritorio

Un conjunto más especializado de software que permite no solamente un funcionamiento del servidor de imagen, sino también proporcionan capacidades de personalización. Dentro de estos los más antiguos y pesados son KDE y GNOME, pero también tenemos entornos más ligeros como LXDE o Mate, Cinnamon, etc.

CLI (Command Line Interface)

Tras un breve repaso por el mundo de los servidores de imágenes, ahora nos centramos nuevamente en nuestro tema. CLI, implica todo aquel programa que se ejecuta por línea de comando, ya sea git, vim, weechat, o bueno, cualquier otro que se les venga a la mente. Pueden apreciar que estoy hablando de programas que si bien se ejecutan en la línea de comando, muestran una especie de “interfaz gráfica” como weechat o vim. Para todos los que no los hayan probado, se los recomiendo, son básicamente los que uso todo el día.

Por qué CLI es mejor que GUI

Intentemos algo bastante sencillo :) El otro día quería trabajar en un parche para Portage (el gestor de paquetes de Gentoo). Como todo buen proyecto colaborativo, la cantidad de líneas de código supera los 70k. Intenten abrir eso en un IDE como NinjaIDE (Portage está escrito en Python) y no tardarán en notar que en lo que empieza a cargar la pantalla, su máquina se pone sumamente lenta (al menos mi i7 si lo hacía) y esto solamente tratando de abrir el código y cambiar al color por defecto de “ayuda”.

Ahora intenten hacer lo mismo con vim, a mi me cargó en cuestión de milésimas de segundo, y al mismo tiempo que ponía los colores “bonitos” y todo lo demás.

CLI ha estado mucho antes

Algunos aquí dirán que esos programas son antiguos, yo los llamo robustos. Si pudiesen ver la cantidad de horas invertidas en construir emacs, vim, gdb, y otros cientos de programas para consola, podrán notar que la cantidad de código y funcionalidades es tan grande que practicamente ya han solucionado todo lo que necesitaban solucionar. Muchos GUI para programas que ya son robustos en su CLI jamás tendrán la misma cantidad de funcionalidades, esto sencillamente porque si hicieramos una pestaña para cada subcomando disponible de por ejemplo git, nos perderíamos entre las opciones y sería contraproducente, porque haría difícil el trabajar.

CLI es más rápido

La mágia comienza con la tecla Tab, esta no solamente es tu mejor amiga al momento de navegar por los escritorios en tu terminal, sino que cuando está bien configurada, te permite acortar sentencias largas a 2 letras y un Tab, 3 letras y un Tab, o incluso una letra y un Tab.

Pero esta no es la única ventaja, los que hemos tomado el tiempo de aprender vim o emacs podemos decir que aunque la curva de aprendizaje sea un poco mayor a la de los IDE de estos días, al final los resultados de productividad son asombrosos, uno no se imagina el tiempo que puede perderse al mover un mouse. El tener las manos en el teclado el 90% del tiempo no solo enseña concentración, además, el hecho de escribir tanto en el teclado te hace bastante ágil y productivo. Y ahora volvemos al punto anterior, al llevar tanto tiempo con nosotros, programas como estos ya cuentan con todas las funcionalidades que se le puedan ocurrir a alguien, un dicho bastante común para los que usamos vim me viene a la mente:

Si usas más de 4 teclas, puede haber una forma mejor.

Sencillo pero poderoso, vim te permite hacer todo con la gran cantidad de teclas y combinaciones posibles, uno nunca deja de aprender, pero no deja de ser verdad también que para poder usarlo no es necesario saberlas todas, bastan unas 10 o 15 para empezar a ser más productivo.

CLI te da el control absoluto

Cuando uno ejecuta operaciones con el mouse, o programas desde el servidor de imágenes, no siempre se tienen presente todas las configuraciones extra que se ejecutan al momento de dar click, esto no sucede con la terminal, aquí tu tienes el poder absoluto de lo que se ejecuta o no, con qué opción o hasta qué punto. Con el tiempo te vas dando cuenta que necesitas menos de lo que piensas, y eso te ayuda a hacer las cosas de forma más centrada.

GUI también tiene lo suyo

No voy a decir que todos deberíamos usar CLI siempre, eso tampoco es lo ideal, yo mismo uso GUIs casi todo el tiempo, para escribir este post estoy usando mi Chrome, y para ver mis correos uso Evolution (aunque también uso mutt bastante últimamente). Y supongo que este es el mayor mito de todos… que la gente piense que GNU/Linux son solamente termianles, a mi me gusta mi entorno de escritorio, es bastante minimalista, pero a mi me gusta así :) Y usualmente solo tengo dos o tres programas corriendo, mi Chrome, mi Evolution y mi terminal :)

Estos son unos de los motivos por los que me gustan tanto las CLI y por los que los invito a darles una oportunidad, puede que después terminen como yo usando más CLIs que GUIs ;) Saludos