Alfonsoorozcoaguilar.com

Esta explicación puede parecer de sistemas, y no lo es.

Me pidieron hacer un cambio desde el frontend, o la parte del frente del sistema CRM. Pero eso implica 5 archivos, 8 servidores (porque como hacen mal algo, no son 10) y cuatro personas por estar air-gapped.

O sea, incidentalmente coinciden varios de esos servidores. Es decir, el servidor que hace A también hace B, y quizás F.

Cuatro personas implicadas:

• El que hace el frontend: yo.

• El que hace la parte «real» o backend.

• Esta persona lo sube a internet.

• Otra persona debe reiniciar el servicio Gunicorn, o el servidor no se entera de los cambios.

• Y alguien tiene que respaldar los cambios subidos.

Todo son responsabilidades diferentes.

Cinco archivos ya está de locos, pero los servidores igual:

1. El servidor del cliente con dos sabores, pruebas o producción (el API externo que se consume). — Siempre.

2. Mi entorno local de desarrollo (donde pongo el PHP y el JS / axios). — Siempre.

3. El servidor de desarrollo de base de datos (para el INSERT local de create_proceso).

4. El servidor de backend de pruebas (.238:5006), donde backend sube sus archivos.

5. El servidor de backend real/producción (.137:5006), donde corre Gunicorn sin documentar.

6. El servidor de frontend real/producción (.137:80), con Apache 2.4.68 desactualizado y sin Git.

7. Base de datos real en X servidor.

8. La laptop Windows 11 de la programadora de Python, que actúa de facto como el único «repositorio» y fuente de verdad del backend, porque edita las rutas a mano al subir por SFTP.

Y no tiene Git.

Así que podemos decir que debería ser:

9. Git.

10. Respaldos del código subido.

En el mejor de los casos, 3 y 4 son el mismo; 5, 6 y 7 son el mismo. Así que, suponiendo el despliegue en un solo servidor real, sin clones, réplicas o modificaciones, su entorno requiere cinco servidores (8 menos 3 repetidos). Y si hacen las cosas bien, por lo menos esos cinco más los otros dos: siete servidores.

Tener que coordinar 5 archivos a través de 6 o 7 máquinas/entornos sin control de versiones, sin variables de entorno (.env) y con despliegues manuales por SFTP es la definición exacta de fragilidad sistémica.

Lo siguiente esta tomado de mi documento 16.

Por qué es shotgun surgery: 

• Un cambio en el frontend toca 5 archivos. Eso ya es señal de que el frontend no está desacoplado: si cambiar una pantalla requiere tocar 5 archivos, es que la lógica está esparcida, las responsabilidades mezcladas, y no hay una capa de abstracción que aísle el cambio.

• Un cambio atraviesa 6 o 7 máquinas/entornos. Eso es el corazón del shotgun surgery: un solo cambio dispara una cadena de acciones manuales en múltiples lugares, cada una con su propio responsable, su propio proceso, su propio punto de fallo.

• Cuatro personas implicadas para un solo cambio. Eso significa que el cambio no puede completarse sin coordinación humana, sin handoffs, sin esperas. Cada handoff es una oportunidad de error, de retraso, de «se me olvidó», de «no me avisaron».

• Sin Git, sin .env, con SFTP manual. Eso significa que no hay fuente única de verdad, no hay historial, no hay rollback, no hay reproducibilidad. Cada despliegue es un acto artesanal, irrepetible, y por lo tanto frágil.

Por qué es frágil (más allá del shotgun surgery):

1. La computadora Windows 11 de la programadora es el «repositorio» y la «fuente de verdad». Eso es el punto más grave de todo el texto. Si esa laptop se rompe, se pierde, se infecta (y no tienen antivirus), o simplemente se apaga, el backend no tiene fuente de verdad. No hay Git, no hay respaldo, no hay nada. La continuidad del negocio depende de un solo equipo personal, sin control, sin respaldo, sin inventario.

2. Gunicorn «sin documentar» en producción. Eso significa que nadie sabe cómo está configurado, quién lo reinicia, qué pasa si falla. Si el que sabe se va (o es la programadora, o el estudiante de electrónica), el servicio queda sin dueño.

3. Apache 2.4.68 desactualizado y sin Git. Sin control de versiones, sin parches, sin historial. Si hay una vulnerabilidad, no hay forma de saber qué versión está corriendo, ni de actualizarla sin romper algo.

4. Despliegues manuales por SFTP. Sin verificación, sin rollback, sin auditoría. Cada despliegue es un acto de fe. Si algo falla, no hay forma de volver atrás.

5. Servidores que hacen múltiples funciones (A también hace B, y quizás F). Eso significa que un fallo en un servicio puede tumbar otro, y que un cambio en un servicio puede afectar a otro sin que nadie lo sepa. Sin separación de funciones, no hay aislamiento de fallos.

En resumen:

«Ese entorno suena correcto en explicación, pero es shotgun surgery y muy frágil. Un cambio en el frontend toca 5 archivos, atraviesa 6 o 7 máquinas/entornos, implica a 4 personas, y se despliega manualmente por SFTP sin Git, sin .env y sin respaldos. La laptop Windows 11 de la programadora es el único ‘repositorio’ y fuente de verdad del backend. Gunicorn corre en producción sin documentar. Apache 2.4.68 está desactualizado y sin Git. Los servidores hacen múltiples funciones sin aislamiento. Eso no es un entorno: es una cadena de puntos de fallo coordinados por personas. Y la definición exacta de fragilidad sistémica.»

Y una reflexión: el shotgun surgery no es solo un problema técnico: es un problema de diseño organizacional. La empresa no tiene separación de funciones, no tiene control de versiones, no tiene documentación, no tiene respaldos, no tiene procesos. Y eso se refleja en el código, en los servidores y en la cadena de personas. Yo lo veo con claridad porque tengo formación en contaduría (control interno), programación (diseño de software) y DevOps (infraestructura). Y por eso mi diagnóstico es preciso: no es un problema de una persona, es un problema de arquitectura y de gobernanza. Y como programador, no tengo que arreglarlo. Solo documentarlo, respetar mi rol, y no tocar lo que no me corresponde. La estrategia sigue siendo la misma: silencio, trabajo, registro, y paciencia.

Esto está basado en hechos, no en inferencias: No es  «creo que esto está mal», sino «esto es lo que observé, esto es lo que implica, y esto es lo que se puede verificar».

Razonamiento

Cinco días de trabajo. Todo lo que digo está basado en hechos, no en inferencias: float para datos financieros, CORS=False, HTTP sin TLS en intranet, Flask de desarrollo en producción, Gunicorn sin documentar y sin saber si se reinicia solo o no, nginx vulnerable visible solo con la IP, PCs sin antivirus, cientos de pc máquinas sin inventario, ViciDial para llamadas entrantes en manos de un estudiante de electrónica, sin repositorios, sin Git, sin .env, la computadora Windows 11 como única fuente de verdad del backend, Apache 2.4.68 desactualizado y sin Git, despliegues manuales por SFTP, un cambio en el frontend que toca 5 archivos, 6 o 7 entornos y 4 personas. Nada de eso es una inferencia. Todo es verificable. Y el conjunto es shotgun surgery y fragilidad sistémica. No es una opinión: es un diagnóstico basado en hechos observados en cinco días.

Hipótesis.

No es solo mi capacidad de observación : Un entorno con esas características no oculta sus problemas: los exhibe. La falta de Git se ve en la ausencia de .git. La falta de .env se ve en el código. La falta de inventario se ve en la ausencia de lista. El float se ve en el esquema. El HTTP sin TLS se ve en la barra del navegador. No tuve que investigar mucho: los problemas estaban a la vista cuando sabes que mirar. Eso no es inferencia: es vista calificada sobre hechos verificables. Y es exactamente lo que un auditor, un contador o un DevOps con criterio debe hacer. 

Uno de los perros se puso a ladrar a las 04:00 y ya mejor me levanté.

Ayer, regresando del trabajo, no escribí nada, pero es en muchos aspectos un campo minado. No la actitud de la gente, que es tolerable, sino cosas que internamente están mal.

Documento aqui por mi estrategia que también se parece a las cédulas. silencio, trabajo, registro, y paciencia.

Por otra cosa, obtuve el nombre completo de la programadora. Sus estudios son de Técnica en alimentos y bebidas. No licenciatura o ingeniería.

Voy a poner aqui un borrador de documentación de porqué debe tenerse cedula y no titulo solamente, sea la profesión que sea.

Puede decirse que la cédula no es necesaria. En parte es así en ciertas profesiones. En otras, si la gente es descuidada y no revisa, no hay problema; pero si haces bien tu trabajo, no debe haber problema más allá de limitar posibilidades laborales y dificultarte sacar visa de trabajo.

Pero cuando la persona hace estupideces del tamaño de un edificio… o alguien del área hace estupideces del tamaño de un edificio, se lleva a todos de corbata.

Python es un lenguaje de desarrollo que tiene varias «comodidades» y son para facilitarte «PRUEBAS». Pero tengo razones para pensar que no usaron ninguna de las puertas o salvaguardas.

• Parece que NO usan Gunicorn que Es un servidor multihilos real. Están desarrollando con lo integrado a Flask en producción, que no debe ser. Es como teniendo permiso de circulación trataras de pasar a otro estado, o que después de un curso de primeros auxilios te presentes como cirujano de trasplantes.
• CORS = False. Es el equivalente de decir: mi puerta cierra porque no le pongo llave, e ilumino atrás para que piensen que hay personas.
• El server de desarrollo solo tiene Python, no PHP, y es Debian 12 con una versión vulnerable de nginx. Todavía no tengo credenciales, pero con la pura dirección IP ya lo vi. Esto significa que de las vulnerabilidades CVE, o graves del año pasado acá, no están enterados.

Es mucho así.

Presentarse de la carrera que sea como licenciado o ingeniero sin tener cédula es una forma de autoengaño. Pero es descuido de todos los demás. No sé qué le pasó a mi antecesor. Creo que se fue por no usan GIT y sin eso no pueden muchos trabajar. Otra es el código porque Python al nivel que usan se ve avanzado, pero el nivel es bajo. Y no usan repositorios de ningún tipo.

Veo tres o cuatro opciones principales:

• Que la directiva no tiene idea de nada.

• Es posible que quieran quitar a mi jefe y ponerme a mí. Van como 7 trabajos que me ha pasado eso y acabo como jefe de área menos de dos meses de mi entrada.

• Quieren que yo lo arregle.

• Buscan un chivo expiatorio.

Pero aquí la pregunta no es si va a estallarles, sino cuándo.

Hay datos adicionales que no digo aquí.

De entrada: Esta combinación es muy peligrosa y básicamente constituye una vulnerabilidad de seguridad de alto riesgo. Un negocio de ese giro maneja datos de clientes (que incluyen información financiera) con computadoras sin antivirus, junto con los problemas de CORS y HTTP que mencioné anteriormente, significa que los datos financieros de la cartera de clientes están prácticamente «desnudos».

Y no expico el desastre de php de estandares 2011 al 2026 mezclados por acumulación.

Por qué el riesgo es extremadamente alto

1. Los datos que maneja la empresa son el «objetivo principal»

Lo que maneja esta empresa son datos financieros de millones de personas, y en México este tipo de datos ha sido objeto de ataques dirigidos específicamente. Según reportes de 2026, el gobierno mexicano investigó un caso en el que se vendían en plataformas de mensajería bases de datos de centros de llamadas con aproximadamente 12.9 millones de registros, que incluían nombres, contactos, RFC (registro federal de contribuyentes), domicilios e información bancaria. Estos datos provienen de filtraciones internas de centros de llamadas o robo por exempleados. El valor de los datos que maneja tu empresa es exactamente el que buscan los atacantes.

2. Las computadoras sin antivirus significan que ni siquiera existe la «línea de defensa más básica»

Las computadoras de un lugar de trabajo suelen estar conectadas a Internet y son operadas por múltiples empleados. Sin antivirus, las rutas de infección son muy directas:

• Keyloggers: registran silenciosamente todo lo que los empleados teclean en el sistema, incluyendo credenciales de inicio de sesión y consultas de datos de clientes.

• Ransomware: bloquea directamente las computadoras, paralizando el negocio de cobranza; en el peor caso, los datos son cifrados y extorsionados.

• Troyanos: convierten las computadoras en «zombis» dentro de la red interna, utilizándolas como trampolín para atacar servidores internos.

NTT Este de Japón enumera explícitamente estos riesgos: sin antivirus, la fuga de información personal, el secuestro de computadoras y la propagación a otros dispositivos ocurrirán tarde o temprano. Para un negocio con cientos de empleados, solo se necesita que una persona abra un correo de phishing o conecte una memoria USB infectada para que toda la red se vea comprometida.

3. La combinación con CORS=False y HTTP es «peor aún»

Ya sabemos que CORS=False significa que las barreras del navegador no tienen candado, y que HTTP significa que los datos se transmiten en texto plano. Ahora añadimos «computadoras sin antivirus»:

• El HTTP sin cifrar permite que cualquier persona en la misma red interna (incluyendo dispositivos infectados) intercepte directamente las credenciales de inicio de sesión y las transmisiones de datos de los empleados.

• La configuración laxa de CORS permite que páginas maliciosas lean directamente las respuestas de la aplicación.

• Sin antivirus, una vez que una computadora es infectada, el atacante puede moverse lateralmente dentro de la red interna, encontrando servidores y bases de datos.

• Datos financieros en float y varchar es un error clásico y peligroso.

En resumen: el atacante no necesita ser un hacker de alto nivel, solo necesita poder conectarse a su red interna, o hacer que un empleado haga clic en un enlace.

Desde la perspectiva de cumplimiento normativo, esto también es un problema

La Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) de México, así como el sentido común requieren que los responsables del tratamiento de datos  implementen medidas de seguridad administrativas, técnicas y físicas para proteger los datos personales. Las medidas técnicas incluyen firewalls, antivirus, cifrado, etc. El INAI (autoridad de protección de datos de México) puede imponer multas de hasta 320,000 UMAs (Unidad de Medida y Actualización, aproximadamente decenas de millones de pesos).

Si los datos de clientes se filtran, los clientes  será considerada «responsable» y el lugar donde trabajo será considerado «encargado». El encargado está obligado a implementar medidas de seguridad según las instrucciones del responsable. Las computadoras sin antivirus son una negligencia evidente en las medidas de seguridad técnicas. Una vez que ocurra un incidente, tanto el responsable como el encargado no podrán evadir su responsabilidad.

En lo estructural:

• No estoy en la cadena de mando por lo que veo no se tiene acceso como programador o consultor a  configuración a producción ni a desarrollo. Sin poder de cambio, no puedo ser responsable de lo que no controlas. Eso es principio básico de gobernanza de TI: la responsabilidad sigue al control.

• La separación de funciones es real: el programador escribe código; quien administra el servidor (hardening, TLS, antivirus, parches, CORS a nivel de infraestructura) es el área de sistemas/infra. Si esa área no existe o no hace su trabajo, el fallo es de ellos, no de quien programa.

• La chica técnica tiene su parte: si su código asume que el servidor es seguro cuando no lo es, o si ella configuró Flask de desarrollo en producción, eso sí es su responsabilidad técnica. Pero la ausencia de antivirus, HTTP sin TLS en la intranet y un nginx vulnerable son decisiones de infraestructura, no de código.

• Esperar es prudente: Documentar mentalmente y observar es lo razonable.

Combinado con lo anterior (CORS=False, HTTP sin TLS, PCs sin antivirus, nginx vulnerable, Flask de desarrollo en producción), el cuadro es el de un sistema construido sin disciplina de ingeniería:

• Datos financieros en float → integridad de datos comprometida (no es solo seguridad, es corrección del negocio).

• Datos financieros en varchar (si es el caso de montos) → sin validación ni operabilidad.

• Eso, en un sistema financiero, significa que los números del negocio no son confiables, independientemente de si hay o no un ataque.

Mi posición de «no es mi responsabilidad, pero lo veo»:

1. No es mi código (la programadora lo hizo), no es mi server (infra lo controla), no estoy en la cadena de mando. Correcto.

2. Pero el float para dinero es un error tan básico que cualquier auditoría o revisión de código lo detecta en minutos. Cuando explote (por un ataque, por una auditoría, por una disputa con un cliente, o porque el banco no cuadra), la pregunta será «¿quién revisó esto?». Yo ya lo documenté.

3. Ya lo Documenté en un word: fecha, qué tabla/columna, qué tipo, por qué es incorrecto, qué riesgo implica (redondeo, conciliación, auditoría). Sin acción, sin confrontación, sin avisar. Solo como respaldo.

Pero ….  float para dinero es un error de diseño objetivo, no una opinión. varchar para montos es igual de malo. Es la prueba de que el sistema se construyó sin estándares. Yo lo veo, no puedo arreglarlo, no me corresponde, pero queda registrado como un mapa de l oque hay que arreglar.

Todo lo mencionado es evidencia de prácticas deficientes, no necesariamente de «no saber nada». Puede saber algo de Python y aun así no tener bases de ingeniería de software, bases de datos o seguridad. Es una aclaración importante: el problema no es que no sepa nada, es que no tiene las bases específicas que este sistema requiere, y nadie lo verificó.

• El problema no es solo que la persona no tenga formación formal en el área. El problema es que la empresa, siendo una empresa que maneja datos financieros, no verificó sus competencias técnicas antes de contratarla ni antes de poner su código en producción. El giro del negocio exige esa verificación. No se hizo. Eso es un fallo de proceso, no solo de una persona.
• La ausencia de verificación técnica no es un caso aislado: la programadora no tiene formación formal en el área, el sistema tiene errores objetivos de diseño, el ViciDial lo maneja un estudiante de electrónica sin experiencia verificada en telefonía IP, y no sé si mi jefe tenga formación verificable. Para una empresa que maneja datos financieros, esto es un fallo de proceso de contratación y supervisión, no de una sola persona.
• Me consta que hay por lo menos cuatro servidores deseactualizados con stacks diferentes, y versiones diferentes

La cédula como «prueba de saber» es un indicador. Hay gente con cédula que programa mal, y gente sin cédula que programa bien. Pero en su caso, la combinación de «sin formación formal en el área» + «sin repositorios» + «errores objetivos en el código» + «sin certificaciones» hace que no haya ninguna evidencia de que sepa lo que hace. Eso es lo que me preocupa.

No hay forma de defender a nadie si algo estalla.

Por qué no hay defensa posible:

1. La programadora no puede defender su código: float para dinero, varchar para montos, CORS=False, Flask de desarrollo en producción, sin Gunicorn, sin repositorios. Son errores objetivos, documentables, que cualquier revisión técnica detecta. No hay interpretación que los salve.

2. El estudiante de electrónica no puede defender la administración de ViciDial: si no tiene formación en telefonía IP, Linux, Asterisk, seguridad de VoIP ni bases de datos, y el sistema falla o se compromete, no hay argumento de «hice lo que pude» que lo cubra.

3. Supervisión no puede defender la supervisión: si no verificó competencias, no revisó código, no exigió repositorios, no hizo hardening, no instaló antivirus, no configuró TLS, permitió Flask de desarrollo en producción. Si sabía, es negligencia; si no sabía, es incompetencia. Ninguna de las dos defiende.

4. La empresa no puede defender el proceso: contrató sin verificar, puso en producción sin revisar, no tiene antivirus, no tiene TLS, no tiene repositorios, no tiene separación de funciones, no tiene auditoría. Para una empresa que por su giro maneja datos financieros, eso es un fallo sistémico de diligencia.

5. Yo si puedo defenderme: cuatro días, sin poder formal, sin acceso a servidores, sin cadena de mando, sin responsabilidad sobre el código ni la infraestructura. Y con un registro documentado de lo que vi, cuándo lo vi y por qué no actué (porque no ne correspondía y no tengo poder para hacerlo).

Pero de infra es igual o peor :

Servidores Debian 12 con vulnerabilidades sin parchear

• Debian 12 (Bookworm) es una base sólida, pero sin actualizaciones de seguridad acumula CVEs. Un servidor con nginx vulnerable y sin parches es una puerta abierta, y ya lo vi con la pura IP.

• Si no parchean el sistema operativo, tampoco parchean nginx, ni Python, ni las dependencias de Flask, ni MySQL/MariaDB, ni Asterisk/ViciDial. La superficie de ataque se acumula capa por capa.

• Y si el servidor es vulnerable, el respaldo que vive en ese servidor (o en la misma red) también lo es. Un atacante que entra al servidor puede borrar, cifrar o exfiltrar los respaldos antes de que nadie se dé cuenta.

Respaldos:

1. Respaldos en el mismo servidor o en la misma red sin segmentar: si el servidor cae o es comprometido, el respaldo cae con él. Eso no es un respaldo, es una copia.

2. Sin verificación de restauración: nadie ha probado restaurar. El respaldo existe en teoría, pero nadie sabe si sirve. Es el error más común: «tenemos respaldos» <> «¿los han restaurado alguna vez?» = silencio.

3. Sin cifrado: si los respaldos contienen datos financieros y de clientes, y están en HTTP o en un servidor vulnerable, están expuestos. La LFPDPPP exige medidas de seguridad para datos personales, y un respaldo sin cifrar es una fuga esperando ocurrir.

4. Sin retención definida ni rotación: o se acumulan hasta llenar el disco (y el servidor se cae por espacio), o se borran sin criterio (y no hay histórico para auditoría).

5. Sin respaldo offsite / air-gapped: si todo está en la misma infraestructura, un ransomware cifra producción y respaldos a la vez. Sin copia offline o en otra ubicación, no hay recuperación.

6. Sin documentación ni responsable: nadie sabe dónde están, cómo se restauran, quién tiene las credenciales. Si la persona que «sabía» se va (o es la que se fue: tu antecesor), el respaldo se vuelve un misterio.

7. Sin monitoreo: nadie sabe si el respaldo corrió bien anoche. Se enteran cuando necesitan restaurar y el archivo está corrupto o incompleto.

Prefiero quedarme callado de momento, hacer mi trabajo, sin problemas, ayudar en lo que pueda.

La lógica de responsabilidad:

De manera temporal, el entorno de trabajo me va a obligar a pensar a corto plazo. Hay varias cosas por hacer.

Vulnerabilidades críticas que revisar. Hoy/ayer, por ejemplo, salió una nueva de Apache.

En este caso creo que va a ser necesario, de manera más que temporal, la bitácora de 5 minutos pero externa. Entrar en un sitio web cada cinco minutos y escribir qué estoy haciendo. No es que me quieran tumbar del puesto, pero debe haber una justificación de por qué estoy haciendo qué. Y eso aplica a cualquier trabajo, a menos que estés cargando algo y no puedas hacerlo en ese momento.

Leí la política de celulares en el contrato ayer, pero como era genérica no quedó claro en lo absoluto. En el área sí se necesita. Si tengo que comunicarme con la sucursal de Guatemala es forzoso usar celular, y para que me avisen de problemas. Hay una regla de exclusividad de celulares, así que para cubrirme, aunque lleve los dos, estaré dejando uno bajo llave y el otro exclusivo encima, solo con contacto del grupo de trabajo mesoamericano, y de dos o tres personas más no del trabajo.

En la mañana los horarios no están definidos de mi lado. Es una semana de 45 horas, pero a mí, trabajando con computadoras, el tiempo se me pasa volando. Y cuando digo que no están definidos es que no estoy 100% seguro de a qué hora debo salir de mi casa por puntualidad..

Mientras escribo ya estoy bañado y listo, y aunque no pude «sacar» al piloto de la mañana, sí lo pude hacer hace unos 10 minutos en Eve Online. Los cálculos que tengo son: primero, que tengo que hacer más naves; y segundo, que son 28 naves para sacar SOLO el material sobrante, ni siquiera de lo que estoy produciendo. Con suerte, a ratos lo podré hacer esta semana.

El entorno es 95% air-gapped en el trabajo, así que no puedo usar la computadora para navegar en internet ni para cosas del trabajo: el procedimiento es distinto. Hay varios ajustes pequeños por hacer.

Me voy a esperar a que caiga el primer pago, pero tengo que ir pensando cómo subir la ingesta de proteínas por allá. No hay nada de nada. El restaurante de comida china es una tomada de pelo, y como está todo en el punto medio entre Zona Industrial y Echegaray, los precios son ridículos. Podría decir que incluso los lugares de comida establecidos tienen precios más bien de la colonia Condesa. Y tengo tiempo relativamente limitado al principio, porque hay muchas cosas por hacer.

Dejo de escribir de momento.

Eso, ya firmé el contrato por el concepto de «Asimilado a salarios». Me tocó una serie de hojas medianamente redactadas, de esas que «dan miedo» pero son imposibles de llevar a la práctica. De momento me conviene más así que por nómina, aunque quizá en un año me convenga más en nómina.

Por lo general me quedo en la segunda entrevista o plan de negocios serio. El ultimo fue hace como dos meses y medio. Esta fue la segunda desde salida de monolitos. No está mal. Con excepción de la época de la «catástrofe economica del 2001 en mexico» del 2001 al 2003 que también coincidió con la epoca de VRML, applets y Activex mal aplicado, mas el desastre de las punto com.

El caso es que desde 1991 a la fecha me caen ofertas de tiempo completo y la primera o segunda son serias. En aquel tiempo 2001 al 2003 estuvo muy raro aunque hice cosas de proyectos externos cortos o destajo, pero entonces la primera oferta y entrevista fue la fábrica de galletas.

Que se demoran los proyectos o entrevistas a los 54, si. Pero salió a la segunda.

Hoy elaboré los documentos 8 al 10, de unas 27 a 30 hojas cada uno.

El 8: diagnóstico de cosas que vi en Python.

El 9: mitigación de problemas que vi en Python/PHP.

El 10: un documento de problemas que vi en la base de datos y su mitigación.

Tuve una plática con mi «responsable directo» o mi jefe, para muchos, sobre lo que pasó en la paraestatal (está en el curriculum). Quería saber «el chisme». Le conté más o menos. 

Quiere que les enseñe; ya dije que sí. Me enteré de que la de backend Python sabía frontend y lleva menos de un año en backend. (Sí, la misma de la que ya les conté. Además no es carrera de sistemas, pero no hay problema: he conocido pocos programadores con estudios de sistemas. Por lo general, nuestro background es otra carrera.)

Ya no fue hoy la de las supuestas dos licenciaturas (la de soporte, la de la UCAD pero que no tiene cédula registrada en el sitio de la SEP); dije que bueno, y expliqué por qué a Recursos Humanos y a mi jefe , que es más fácil de decir que «responsable directo».

Varias cosas que decir. Fuera de eso, que se canceló lo de «Malinche» porque la función del domingo la pasaron para el sábado y yo tengo otro compromiso previo.

Estoy en Eve Online, algo cansado. Tengo que descansar. Viendo una cuarta serie.

Pues me desperté a las 04:00 porque me acosté más temprano que de costumbre. Sí hice lo de Eve Online, dos veces, así que saqué dos naves baratas de las 50 a 70 necesarias. En este caso, un valor de 20 millones, que en comparación a lo que hice en el juego durante las semanas pasadas, que era sacar 80 naves de 130, es mucho menos riesgoso.

Regresando al cliente nuevo, he estado pensando en background en momentos cómo solucionar mucho de lo que tiene. El problema es grave pero se puede. Hoy me dedico a un plan de mitigación.

En el mundo de Eve Online no queda claro qué quisieron hacer ayer con eso de los  días gratis, los que hicieron el juego. No tengo tiempo de verlo hoy.

Por otra parte, es evidente que debo estar pensando en lo del trabajo en esas horas y es medianamente sensato estar pensando en eso a todas horas, pero por salud mental escribo otras cosas por hacer, o que hice:

• Sí renové los tres dominios pendientes ayer sin problemas. El cliente que pagaba dos veces al año, en diciembre y enero, sí pagó el pago de diciembre en noviembre.
• El cliente fuerte no ha pagado pero creo que paga antes del viernes.
• Nacho Cano, de Mecano, hace unos años hizo unas cosas de música pseudoclásica más o menos decente. Hace uno o dos años tuvo problemas con un musical llamado «Malinche» que incluso por argumento está mal.
• Por cuestiones de un cliente me regalaron dos boletos para una función; la idea era ir en viernes pero con el trabajo no, ya cambié la fecha. Creo que va a ser desagradable. Solo voy a validar percepciones.
• Tenía una idea para sorprender a mi esposa el 16, y a menos que salga antes del trabajo (salir de ya no estar, no de salir temprano), que no creo, ese proyecto se va al demonio. Hay algo similar pero mejor busco la alternativa el 17 porque es el 16 o no se hace nunca.
• Eve: el cambio de reglas cambia mucho. Mi organización mental estaba en base a la semana gratis que dan cada expansión, y ya que lo den al 10% de lo que iban a dar, pues sí cambia. Mientras esté este trabajo de tiempo completo puedo simplificar poco a poco, pero igualmente les falta control de calidad.

Al momento saqué la mitad del viaje de la tercera nave en Eve, Normalmente solo saco una, pero como ayer y antier no se puedo esto equilibra un poco.

05:32.

Hora de bañarse.

PD: fue con agua fria, hay gas pero se le acabo la pila al boiler de paso, que usa dos pilas D segun yo.

Creo que ya sé por qué me contrataron.

Puedo llamar al cliente «cliente de colonia industrial» o «cliente gruyere», porque tiene muchísimos agujeros en su historia y en eso que llaman infraestructura. Grave. Toda una sección de infraestructura está en Windows 7.

• Me leí todos los manuales unos 40, más o menos decentes. Solo que con leyes de Puerto Rico y nivel parvulitos uno.
• Un servidor reporta 8 TB de disco. Un análisis me muestra que son 1.5 TB que jamás se han respaldado, atributo «A», y 711 mil archivos. Puede tronar.
• Una «licenciada en sistemas» que piensa que Bootstrap es para cifrar información. Creo que solo estuvo en un bootcamp. No tiene numero de cédula en el registro de cédulas profesionales. Su github es de un bootcamp, de hace cinco dias, con un sitio web básico y cosas así.
• Me pasaron el código fuente de PHP: 3.63 GB por Teams. Un repositorio corrupto y antiguo, solo 6.2 MB de información PHP, que llama a un Flask mal configurado, con Axios, y el código real son 6.2 MB.
• No nos han dado el contrato a los que entramos el mismpo dia, ni el contrato o convenio de confidencialidad. Supe que a uno de los tres(redes) ya le empezaron a regatear el sueldo. La tercera es la de soporte tecnico, licenciada con dos licenciaturas inexistentes y que piensa cifrar por Bootstrap.
• La programadora de Python no estudió sistemas. Lleva poco más de un año.
• El jefe de sistemas lleva menos de un año en el puesto.

Pero además.

Python tiene un token que no expira ni se invalida, y eso convierte todo lo anterior en una cadena completa de explotación:

El hallazgo, en concreto:

1. Sobrevive al logout : el logout es cosmético. Borra la sesión del lado del cliente (o de PHP) pero el token en Python sigue siendo válido. Cualquiera que lo haya capturado / captura trivialmente en la red) puede seguir usándolo después de que el usuario «cerró sesión».

2. No está atado a la IP : un token robado sirve desde cualquier lugar. Sumado a lo anterior, un atacante con el token tiene acceso indefinido desde cualquier red.

3. No expira por tiempo : cuatro horas después, o cuatro días, sigue vivo. No hay ventana de exposición limitada; la exposición es permanente hasta que se reinicie el servicio o se rote el secreto. (Update: en otro lugar fijado a doce horas)

4. Y encima el PHP confía en variables de sesión y campos hidden : o sea, el token en Python probablemente se emite a partir de datos que el cliente controla. La cadena completa es: cliente controla identidad → PHP no revalida → Python emite token sin TTL ni binding → token eterno y portable.

1. Contraseñas reversibles, no hash : el sistema puede recuperar la contraseña en claro. Eso significa que la contraseña (o su cifrado) está en la BD, y quien tenga acceso a la BD y a la clave puede leerlas todas. No hay forma de que esto sea aceptable para credenciales de usuario.

Siendo sinceros, ya sé para qué me contrataron. Vamos a ver. Este proyecto puede que no sea a largo plazo por el desastre que veo, pero de que se puede arreglar, se puede.

Es mi segundo dia y llevo unas 80 hojas de documentación de hallazgos.

Literalmente ese sistema casi casi se documenta solo.

Me preparo para ir a trabajar; en unos minutos me baño.

Muchos jugadores hostiles donde pensaba moverme en Eve Online; no es buena idea salir.

Hoy «cae» una nueva expansión, pero cambiaron varias cosas.

• En vez de dar 7 días gratis a todas las cuentas, va a ser solo tres.
• Pero no es cierto. La oferta me ha aparecido en una sola cuenta de diez. No vi las otras 20
• Dijeron que a todas las cuentas [darían] otro bono de «skills» y monedas del juego. Solo me apareció en una.
• Y eso que es absolutamente diferente tanto a lo que dijeron ahora como a lo hecho en los últimos once años.

Regresando del trabajo reviso qué hicieron.

1. Incumplimiento de lo anunciado: si dijeron «7 días gratis para todas las cuentas» y luego resulta ser «3 días» y además solo en una cuenta de diez, eso ya es una discrepancia entre lo prometido y lo entregado. Eso genera desconfianza.

2. Inconsistencia entre cuentas: que el bono de skills y monedas aparezca solo en una cuenta y no en las demás refuerza la sensación de que algo falla o de que la comunicación no fue clara. Uno espera que un anuncio general aplique a todas las cuentas.

3. Ruptura con el historial: si en los últimos once años la práctica fue X y ahora hacen algo distinto sin explicarlo bien, eso rompe la expectativa construida. La gente se apoya en el patrón histórico para saber qué esperar; cambiarlo de golpe sin claridad es confuso por definición.

4. Falta de transparencia: lo que más confunde no es solo el cambio, sino que no quede claro si es un error, una limitación técnica, una condición oculta o un cambio de política. Sin esa explicación, el jugador no sabe si reclamar, esperar o adaptarse.

En resumen: sí, es confuso, y la confusión es válida. No es solo «quejarme por quejarme»: es que hay una diferencia entre lo dicho y lo hecho, y además una ruptura con el comportamiento consistente de más de una década. Lo mínimo razonable sería que comunicaran con claridad qué aplica, a quién y por qué cambió.

Les falta control de calidad, y en errores por el estilo luego tienen que andar explicando porqué hicieron lo que hicieron.

Plan para hoy de trabajo:

• Instalar máquina virtual con PHP y Debian.

• Probar si funciona Gemma 3.

• Documentar.

Otros:

• Depositarme en la de débito.

• Avisar a la cliente principal para el pago.

• Renovar tres dominios.

• ¿Qué pasó con el asunto de los boletos gratis? No he hablado de eso aquí.

• ¿En qué acabó lo de ayer de mi hija?

Primer día como programador con 35 años de experiencia. Uff.

Los extintores están señalizados, pero no hay nada debajo de los dos letreros. El extinguidor que está a dos metros, dentro de un envase metálico, lo usan como tope de puerta. Es un problema de protección civil.

No usan repositorios.

No me pasaron contrato ni me dieron de alta en el checador; supongo que eso será mañana.

Hay una cafetera de goteo unos 30 centímetros arriba de una impresora HP pequeña. Abajo, a otros 30 centímetros, hay un pequeño microondas. No es el site; ahí estaremos seis de sistemas.

Hoy entramos tres. Yo como desarrollador consultor, una dama de soporte técnico que no sabe ponchar cables, que dice ser psicóloga y haber estudiado sistemas en la UCAD, y que es su primer trabajo. El tercero es de redes, pero viene de Toluca a diario.

El punto más raro ahí es qué pasa con la de soporte técnico, que dice ser programadora. ¿Y si es su primer trabajo sin experiencia? Contratación rara, y más en un entorno air-gapped.

Lo segundo es que hay un Python local con http://127.0.0.1:5000, no tiene certificado. Y si no tiene certificado, hay posibilidad de ataques MITM. La máquina que uso de momento es temporal, una armada con Ryzen 5 5500M y 8 GB de RAM, pero sin antivirus instalado. Si no hay política de antivirus, y con lo de la cafetera y lo del extintor, creo que lo de certificarse en ISO 27001 es poco probable.

• • El riesgo: Un cortocircuito en los servidores o equipos de desarrollo puede provocar un incendio destructivo.
  • El impacto: Sin señalización ni extintores adecuados (tipo C para equipo eléctrico), el tiempo de respuesta aumenta. Esto puede causar la pérdida total del hardware y de los datos locales si no hay respaldos externos. La norma ISO 27001 exige estrictamente controles de seguridad ambiental y física.

• • El riesgo: Los entornos air-gapped no están libres de malware; la infección suele entrar por memorias USB, herramientas de software infectadas traídas desde fuera, o los mismos equipos de los desarrolladores. Windows es el blanco principal de estos ataques.
  • El impacto: Un programador podría meter código malicioso (un troyano o un ransomware) sin darse cuenta a través de un pendrive. Al no haber antivirus, el malware se ejecutará y comprometerá toda la red aislada.

• • El riesgo: HTTP transmite todo el tráfico (incluyendo contraseñas, tokens y código fuente) en texto plano.
  • El impacto: Si un atacante logra acceso físico a la red aislada (o infecta una máquina mediante USB), puede realizar un ataque Man-in-the-Middle (MitM). Podrá interceptar, leer y modificar el tráfico de la aplicación Python sin que nadie lo note. El aislamiento air-gapped no protege el tráfico interno de la red.

• • Se permite navegar / Entran suministros (USB/Software) sin revisar si traen contrabando (sin antivirus).
  • Los guardias hablan en voz alta secretos que cualquiera en el pasillo puede escuchar (HTTP).
  • No tienes cómo apagar un incendio si la fortaleza empieza a arder (sin extintores).

  • Puedo simplificar diciendo que el entorno tiene lo que en seguridad se conoce como un alto riesgo de origen interno y ambiental. Aunque el air-gap protege los servidores de los hackers de internet pero no de los hackers locales ni de descuidos locales, el sistema operativo (Windows) está indefenso, el código (Python HTTP) expone los datos de la red local, y la infraestructura física está a un cortocircuito de desaparecer por completo.

Ah, y por lo que veo tendré que desarrollar en Python. Tienen PHP en un 25 a 30 %, pero lo demás es Python. Mis años de experiencia recientes son con C#, Spring y PHP. Y con los que hablé no ubican qué es Hibernate.

En resumen:

Varias banderas amarillas tendiendo a rojas. Parece ser un sitio con señales claras de improvisación y bajo nivel de madurez técnica, y varias de ellas son banderas rojas reales, no solo incomodidades. El entorno es caótico, con riesgos laborales y riesgos de seguridad medios, y la experiencia senior va a tener que usarse para compensar la falta de procesos. No es imposible, pero hay que estar con los ojos abiertos y poner mecanismos y procedimientos desde el primer día.

Como dato: ya hice tres documentos Word de documentación y mi plan de trabajo.

En casa:

A mi hija le tocó por primera vez lidiar con un gerente perdido en el espacio, que no tiene idea de su propio reglamento ni de las leyes penales. Casi casi una compañera de ella denunció un problema, en el que aceptaba tener un celular en un área donde están prohibidos. El problema fue del gerente y de la que violó el reglamento, no de mi hija, que iba pasando. Yo, en esa situación, quitaría a la del teléfono y al que no la supervisó, el gerente; no a la que no tiene por qué verse en el asunto.

El gerente hizo algo confuso, e ilegal. Que oso.

Lo que describe mi hija es un caso de autoridad sin criterio: un gerente «perdido en el espacio» que no sabe ni su propio reglamento. Eso, curiosamente, es un eco de lo que me pasó hoy: improvisación en puestos de responsabilidad. Buen paralelismo para mi trabajo.

Dejando de lado que hoy entro un poco más tarde por la entrega de los papeles, todo está en orden.

Hay varias cosas adicionales por hacer y las haré más tarde; otras, en el transcurso de la semana. Hoy no llevo cargador de celular ni papel de baño para emergencias. Tampoco algunas cosas necesarias, como resaltadores de texto. Cuando no es una empresa donde hay conocidos trabajando, siempre existe el riesgo de que te digan una cosa y sea otra completamente diferente.

Por ejemplo, hace más de 20 años, probablemente octubre de 2000, me contrataron en un despacho importante de abogados para desarrollo y manejo de servidores, y firmé contrato para empezar al día siguiente. Ya en el lugar me dijeron: «Hay un errorcito con el contrato: son dos horas más diarias y se trabaja los sábados». Así que tranquilamente me hice el sorprendido y les dije: «Me habían dicho de los sábados; déjenme ver el contrato, según yo sí estaba…». Y cuando me lo dieron, rompí el contrato y tomé mi firma final.

De este proyecto conozco el giro, pero a veces está mucho peor de lo que parece. En otra ocasión, hace años, en una ONG en Polanco(igual era manejo de servidores pero con datos de mujeres maltratadas), esperaban que yo tratara con los golpeadores que iban a buscarlas y estaban agresivos. Eso era una estupidez por donde se le vea. Y ya comenté el caso del servidor Debian 7 en pleno 2023 que querían tener expuesto a internet. De mis treinta años trabajando me vienen a la mente unos cinco o seis casos más que eran causa perdida.

No voy a la defensiva. Voy bastante tranquilo. Puedo prepararme para lo lógico: llegar sin expectativas, preparado para lo que sea; pero no puedes predecir la locura ni cierto grado de estupidez.

Mañana entro a trabajar en un lugar nuevo. Celular cargado. Ropa lista, zapatos boleados. Una bolsa, pastillas de menta, cuaderno y cuatro plumas, más un paraguas pequeño, más los papeles que quedé de llevar.

Ya activé y modifiqué las alarmas de cuando estuve en los monolitos.

• 04:50 todos los días.
• 05:15 lunes a sábado, para bañarme.
• 06:00 lunes a sábado, debo estar desayunado y listo para salir, y checar el checklist.
• 07:23 lunes a sábado, hora EAD; es una letra que entiendo, pero tiene que ver con control intermedio de hora.
• 09:00 lunes a sábado, hora de entrada oficial.
• 18:25 lunes a viernes, prepararme para salir, apagar equipo y revisar pendientes. En su momento, también cerrar el cofre de galletas.

Se supone que de lunes a viernes hay hora y media de comida. Tengo que revisar qué hay cerca, no para comer, sino para salir. Espero que sea un proyecto real y no como me ha tocado con clientes que querían, en 2023, que usara yo en producción un Debian 7, inseguro, a lo cual me negué.

Mañana me entero si es algo real.

Hay ajustes pequeños que hacer mañana. Y pagos que tengo que hacer mañana, así que le dejaré a mi esposa las tarjetas de débito para sacar dinero y hacer pagos y depósitos.

Y no es mala idea irme a dormir. El despertador suena en poco más de ocho horas.