Autodefensa contra sabotajes

Allá por 1995 algunos de mis sistemas estaban corriendo en supermercados, perfumerías y farmacias. Hice un proceso que checaba el diagnóstico de espacio libre, memoria, respaldos y cosas así. Más adelante, allá por 1995-2000, tuve problemas serios con que una persona, por sabotear, a veces instalaba versiones antiguas mías encima de las más recientes. Era un solo ejecutable el cambiado. No era tan difícil arreglarlo porque mis ejecutables se autoverificaban por una librería en C y no podían ser manipulados (un software de Clipper 5.2e).

En aquella época se usaba un número de versión que promovía Microsoft, que era Major, Minor y Revision. Ese número podía ser, digamos, 2.0.1116 y para mí ese era un indicador de qué versión tenía.

El problema es que a lo mejor yo ponía una mejora 1117 y no la instalaban, y me reinstalaban el 1115.

Entonces inventé un proceso que se llamaba barrido. En realidad yo sabía que algo había sido alterado porque cada versión mandaba un BEEPER al final del día a un Skytel (beeper, buscapersonas). Si yo empezaba a ver una versión alterada, sabía que tenía que volver a ir al lugar. Hice un proceso llamado ‘BARRIDO’ que representaba con una escoba. Básicamente, con él revisaba absolutamente toda la base de datos por las últimas 100 mil operaciones a ver si había una incidencia que corregir.

• Nota : No se usan beepers ya pero puedes hacerlo con SMS que cuestan 0.50 MXN cada uno.

Entonces en la época de Clipper 5.2e (un ecosistema robusto pero manual) tuve que implementar mecanismos de autodefensa. Lo que describí era un intento de sabotaje mediante downgrade (reinstalar versiones antiguas para reintroducir bugs o vulnerabilidades que ya había curado o arreglado).

Microsoft popularizó el estándar Major.Minor.Build.Revision, pero yo lo usaba como un escudo. Clipper no tenía el dato de esos numeros pero yo lo manejaba internamente por una constante en código. No lo podía hacer en base de datos porque el sabotaje era en el ejecutable.

• La Trilogía de Defensa:

  • Identidad: El ejecutable sabe quién es (Versión Major.Minor).

  • Integridad: El ejecutable revisa su entorno (Beeper/Versión). Puede ser SMS

  • Reconstrucción: El ejecutable repara su base de datos (La escoba/Barrido).

• El “Ataque DDOS” Primitivo: Las 10 computadoras corriendo el barrido. Es una lección sobre Privilegios y Control de Recursos. Hasta una herramienta de limpieza puede ser un arma si no tiene permisos.

• Primera Conclusión: Los fundamentos no cambian. Antes era un disquete con una versión vieja, hoy es una IA generándote código con vulnerabilidades de hace 10 años. Si no tienes un proceso de ‘Barrido’, estás a merced del entorno.

Ahora bien: En un entorno real, hay otros problemas que tienes que verificar. Poder quitar permisos a un usuario de manera inmediata. Que los puertos más importantes estén abiertos o cerrados. Tener una bitácora.

Comentaba que durante años tuve que batallar con un sistema Laravel 5.2 en PHP 5.6 (en uso en junio 2025) y que no podía poner bitácora propia de visitas para saber qué hacía quién, debido a un problema con sus templates Blade.

• La situación era crítica: no podía ni siquiera insertar el proceso de barrido ni bitácoras propias. Tuve que hacer un archivo php diferente para el barrido con su propia contraseña.
• Intentar rastrear qué hacía cada usuario era imposible porque, al querer inyectar lógica de control, el sistema se caía por conflictos entre los templates de Blade y la inestabilidad de la red. Estaba en un entorno donde no tenía visibilidad ni defensa, operando a ciegas en un sistema que no era mío y que rechazaba cualquier intento de saneamiento.

Hay otro caso interesante. Imagina que una sucursal de paraestatal subía un nombre en domingo ‘PEDRO PÉREZ PÉREZ’ y el número de expediente 1234567890. Pero debía ser ‘PÉREZ PÉREZ PEDRO’, apellido primero, según otro webservice que funcionaba dos o tres horas al día. Yo no podía saturar ese webservice, así que un campo de la base se ponía en ‘webservicecuadra = NO’ y el barrido, en automático, revisaba el webservice en color blanco si no se había leído el dato del webservice. En amarillo si se había leído y estaba por comparar, y en color rojo si ya había comparado y no cuadraba. Además me decía el dato de cuanto tardó el webservice y lo guardaba en base de datos. A veces un registro tardaba 35 segundos.

No era raro que mejor yo editara a mano el nombre del ciudadano para que cuadrara si el error era ortográfico o de orden de apellidos. Pero pasaba que el expediente y el nombre no fueran para nada de la misma persona (generalmente error en num de expediente), y si no podía corregirlo le avisaba a analistas para que avisaran a la sucursal. Era un barrido que evitaba problemas. Puedo decirte que en promedio mi proceso de barrido funcionaba unas 30 veces al día, y no se tardaba gran cosa. Por ejemplo, a veces eran 90 nuevos expedientes en domingo y había que revisar tres. Me parece que la lógica se cargaba a sí misma a los 75 registros, y si cuadraba con el webservice, además de poner en amarillo, lo fijaba a ‘sí’. Por lo cual la próxima vez se mostraban, digamos, 15 en blanco pendientes de revisar y tres en rojo que quedaron pendientes del anterior.

El proceso de barrido, cuando salí, verificaba como 30 cosas diferentes, algunas con webservice, otras con lógica de errores que había detectado en expedientes previos. Igual el barrido revisaba el resultado de los expedientes de los últimos 45 días por si notaba un error.

Hoy en día, delegamos todo en ‘logs’ que nadie lee. El Barrido es diferente porque no solo anota el error, actúa sobre él. Es la diferencia entre un guardia de seguridad que mira una pantalla y uno que sale a cerrar la puerta que alguien dejó abierta. En mi caso aparecían dos botones en cada renglón. Uno me llevabaa editar el ciudadano (y al ver su INE podía ver el nombre correcto) y otro pegaba un mensaje  en web.whatsapp.com diciendo  a la analista principal “Hola, noté este error  en el ciudadano tal”.

Y tenemos otro problema más que mencionamos antes: los permisos a usuarios. Suelen ser muy, pero muy amplios. Este tema lo seguimos en el próximo Fundamentos: Permisos. Nosotros debemos poder cambiar al vuelo el nivel de un usuario o sus permisos, porque a veces no podemos sacarlo. Y esto es parte de un barrido también: detectar inconsistencias y no confiar en los logs de Apache que a lo mejor no puedes ver.

Por lo mismo, el próximo artículo va sobre permisos negativos y bitácoras reales, así como lo que necesitamos para una gestión eficiente de usuarios cuando pensamos que ha sido comprometido el sistema, o simplemente cambia la versión de una librería o una regla de seguridad.

🛠️ El barrido te sirve también en sistemas “intocables”:

1. La impotencia del Senior: Es importante mostrar que, a veces, el fundamento no es “cómo lo arreglé”, sino “por qué no se podía arreglar” debido a la deuda técnica extrema.

2. El peligro del “Vuelo a ciegas”:  Si no puedes poner una bitácora porque el sistema colapsa, el control de permisos y de los tiempos de respuesta de un webservice se vuelve tu única línea de defensa (o de ataque) para evitar un desastre. Y además debes detectar los problemas que antes resolviste, y evitas quese repita creando una nueva regla de negocios ( ese dashboard de amarillo rojo blanco con botón de edición para que alguien lo revise)

3. Contexto de Red: Mencioné que la red también fallaba. Por eso un “barrido” (que requiere consultas a la base de datos) era indispensable. Era importante porque a veces no podía entrar en tres días y las sucursales seguían subiendo expedientes, o el webservice se tardaba hasta tres minutos por expediente.

Conclusión dos: La gestión de usuarios suele ser el talón de Aquiles de la seguridad. Revisar lo que puede estar mal y/o que ya pasó antes es ser proactivo.

A esto se le llama Seguridad Basada en el Conocimiento:. No solo barres la basura, sino que aprendes de dónde vino para que no vuelva

Tienes que defenderte.

Por eso el artículo se llama “Autodefensa contra sabotajes”.

Por eso hablaremos de permisos negativos, de cómo quitar el acceso a alguien ‘en caliente’ sin tirar el servidor y por qué no puedes ni debes confiar ciegamente en los logs de Apache. El sabotaje no siempre viene de afuera; a veces, viene de una mala configuración de permisos que le dimos a alguien hace tres años, o de administradores de sistemas y redes que no tienen idea de lo que hacen.