Desde pequeño, me han fascinado las computadoras. Recuerdo experimentar con Visual Basic, probar homebrew para Nintendo DS e incluso modificar la consola Wii de mi familia antes de los 12 años. Sorprendentemente, nunca la rompí. Por eso, no fue una sorpresa para nadie cuando solicité estudiar informática en la universidad. Ya contaba con varias habilidades técnicas antes de ingresar, y adquirí más durante mis estudios, pero mi laboratorio personal ha sido lo que realmente me ha enseñado más.
Estudié informática en University College Dublin, donde el curso de cuatro años abarcó una amplia gama de temas. Comenzamos con C, luego pasamos a Java, con incursiones breves en Ruby y Lisp, junto con robótica introductoria y varios módulos de ingeniería de software. El plan de estudios se complementó con redes, sistemas operativos y computación paralela (como OpenBLAS y GEMM), así como una sólida dosis de matemáticas, algoritmos y lógica. En los dos últimos años, pudimos especializarnos, y me orienté hacia la ingeniería de software segura, el hacking ético, la seguridad de la información y el aprendizaje automático, con un módulo de desarrollo de videojuegos por puro interés. Estos últimos resultaron ser algunos de los módulos más gratificantes de todo el curso.
Dicho esto, la mayor parte de lo que hago en términos de desarrollo, redes y experimentación en mi laboratorio personal proviene de fuera de mi título universitario. ¿Ayudó la informática a construir una base más sólida de la que habría tenido sin ella? Casi con seguridad. Pero aparte de los módulos relacionados con la seguridad, que sigo utilizando con frecuencia, he aprendido mucho que realmente se ha quedado conmigo gracias a los servidores que he construido y a los proyectos basados en ESP32.
Abstracciones versus realidad
Entender no es lo mismo que hacer
La universidad prepara para la realidad tecnológica al explicar el por qué funcionan las cosas, pero entender por qué algo se rompe es otra cuestión. Aprendí algoritmos, estructuras de datos y cómo diseñar interfaces limpias para el software que escribo. Comprendí cómo deberían comportarse los sistemas operativos y cómo definir entradas y salidas para cualquier sistema computarizado, todo gracias a lo que aprendí durante el curso. Lo que no aprendí, porque es difícil enseñarlo en un aula, es cómo esas abstracciones pueden fallar debido a un sistema mal configurado, con recursos insuficientes o parcialmente dañado. Las máquinas de Turing, la arquitectura de computadoras (incluida la escritura de ensamblador para el microprocesador Z80) y la computación paralela son valiosas para comprender el mundo de la informática, pero comprender la teoría es muy diferente a comprender lo que se está ejecutando frente a ti.
Para ponerlo en contexto, gran parte de mi adolescencia la pasé administrando servidores de Minecraft en VPS económicos, pero siendo un niño en internet, era difícil tener dinero para gastar. Gané dinero haciendo trabajos ocasionales y finalmente alquilé un servidor dedicado de OVH que solo desactivé hace unos meses después de usarlo durante casi una década. Fue allí donde tuve mi primer contacto con la creación de un laboratorio personal, ya que en casa tenía una conexión ADSL2+ capaz de alrededor de 12 Mbps de bajada y 0.5 Mbps de subida. El auto-alojamiento no era una opción, pero con mi servidor dedicado que ejecutaba Plex, TeamSpeak y cualquier servidor de juegos que quisiera, rápidamente me convertí en la persona a la que recurrían mis amigos para configurar un servidor de Counter-Strike o Gary’s Mod para una noche de juegos.
Sin embargo, todo esto requería solucionar problemas, comprender los permisos y leer mucho. Años después, en mi laboratorio personal, muchas de estas lecciones son las que se han quedado conmigo y las uso mucho más que la mayoría de mi experiencia universitaria. Implementar una aplicación multi-hilo en mi servidor es más fácil gracias a mi comprensión de la computación paralela, pero el aspecto práctico de hacerlo en primer lugar es algo que aprendí a través de años de pruebas, errores y correcciones. Incluso ahora, cuando ayudo a una empresa local a implementar un sistema de gestión de inventario o una pila de seguridad, son mis años de experiencia con Linux y redes los que más me ayudan.
Seguridad y redes son más que teoría
El contexto importa en ambos casos
La programación es una historia similar, y a pesar de no haberla utilizado realmente en la universidad, casi toda mi programación actual se realiza en Python. Aparte de mi módulo de aprendizaje automático (y una pequeña parte de mi módulo de big data), no tenía razón para usarlo, sin embargo, mi tesis de licenciatura fue escrita en Python y ya no utilizo Java o Ruby. Incluso en el caso de C, hasta que comencé a desarrollar para el ESP32, no lo había usado desde mis primeros dos años de universidad.
Sin embargo, tanto en Python como en C, tener una sólida comprensión de lo que está sucediendo en segundo plano se vuelve invaluable en el momento en que algo deja de funcionar. Esto es especialmente cierto con C. No hay un intérprete o entorno de ejecución que te aísle del sistema subyacente; administras la asignación de memoria, los búferes y el espacio libre tú mismo. Ese nivel de control es poderoso, pero también es la razón por la que tantas vulnerabilidades explotan el código C o similar.
El exploit Fusée Gelée de Nintendo Switch es una excelente ilustración de esto. En esa instancia particular, la longitud de los datos (es decir, el tamaño) se asigna en la memoria para que sea del tamaño solicitado por el host, en lugar de uno limitado por software, lo que resulta en un desbordamiento de búfer que cubre la región de memoria de la pila de aplicaciones, que es ejecutable. Ese es solo un ejemplo de cómo el código C mal escrito puede causar problemas de seguridad.
Comprender por qué existen vulnerabilidades como esta y cómo surgen de la interacción entre el código y el sistema operativo es algo para lo que la universidad me preparó bien. Los módulos de ingeniería de software segura, hacking ético y seguridad de la información me brindaron la base teórica para comprender estos problemas. Pero internalizar realmente esas lecciones y aplicarlas instintivamente llegó con la experiencia. Saber lo que estás viendo en un desensamblador o un depurador es mucho más importante cuando comprendes por qué el sistema se comporta de la manera en que lo hace, y lo mismo ocurre cuando observas código desensamblado en una aplicación como Ghidra.
Las redes, sin embargo, son una bestia ligeramente diferente.
En la universidad, aprendimos el modelo OSI, el enrutamiento, los protocolos y la conmutación en gran medida de forma aislada. Trabajamos con topologías de red limpias y aptas para exámenes que tenían sentido en el papel, pero no necesariamente eran representativas del mundo real. Conceptos como VLAN, NAT o multidifusión se introdujeron en teoría, pero rara vez se exploraron de las formas desordenadas e interconectadas en las que tienden a fallar en la práctica.
No fue hasta que comencé a ejecutar mis propios servicios que las redes realmente hicieron clic. Las configuraciones erróneas de VLAN, las peculiaridades de NAT, el comportamiento inesperado de DNS multicast, el tráfico de difusión que abruma partes de una red… todos estos son problemas que no se pueden abstraer completamente en un marco de enseñanza generalizado. Cada red es diferente, y mi laboratorio personal me obligó a enfrentarme a esa realidad. Al hacerlo, me enseñó mucho más sobre cómo se comportan realmente las redes que cualquier diagrama.
Para ser honesto, es difícil abstraer muchos de estos conceptos a un marco de aprendizaje generalizado que simplemente no puede abarcar todas las posibles permutaciones de una red o sus problemas. Sin embargo, mi laboratorio personal me permitió aprender todo eso, hasta el punto de que entiendo las redes mucho más ahora que cuando estaba en la universidad. La universidad me dio el vocabulario y los modelos mentales, pero mi laboratorio personal me dio la capacidad de comprender cuándo y dónde aplicarlos.
Un título en informática seguía siendo valioso
Solo que no de la manera que esperaba
Mirando hacia atrás, está claro que la universidad me brindó una base estructurada sobre la que trabajar. Me dio el lenguaje para describir sistemas, los modelos mentales para pensar en ellos de la manera correcta y la base teórica para comprender por qué existen ciertos problemas. Esa base sigue siendo importante, particularmente en lo que respecta a la seguridad, los sistemas de bajo nivel y la comprensión de cómo el software interactúa con el hardware y los sistemas operativos. Pero es la experiencia posterior, en el mundo real, la que me ha enseñado gran parte de lo que puedo hacer hoy.
Mi laboratorio personal se convirtió en el campo de pruebas donde realmente tuve que pensar rápido. Atrás quedaron las topologías de red limpias y aptas para exámenes, los diagramas y las soluciones simples a problemas complejos. Se trata de utilizar la teoría para informar las soluciones basadas en el instinto y, con el tiempo, tus instintos se sintonizan más con la realidad de los sistemas modernos. Esas experiencias se han quedado grabadas mucho más profundamente que cualquier cosa posible en un entorno académico controlado, pero mentiría si dijera que mi título no me ayudó.
Un laboratorio personal no es un sustituto de la educación formal, ni estoy diciendo que un título en informática sea innecesario. Es la combinación de ambos lo que me brindó un valor inmenso, ya que aprender la teoría y poder interactuar con los aspectos prácticos saca lo mejor de ambos. Para mí, aprendí cómo deberían funcionar los sistemas, y mi laboratorio personal dejó claro cómo aplicar esos conceptos cuando no funcionan tan bien como lo hacían en esas clases.
El aprendizaje no termina con la graduación y, honestamente, diría que apenas está comenzando. He trabajado en todo tipo de proyectos para varias personas diferentes, además de administrar mi laboratorio personal, y aunque muchos de esos proyectos tienen sus raíces en los fundamentos de lo que he aprendido, es la experiencia de construir y romper mi laboratorio personal, junto con una década de experiencia con Linux, lo que hizo todo esto posible.
