AI party

Overview

En la actualidad la inteligencia artificial se ha democratizado y es ya dificil encontrar personas o empreses que no la usen o la conozcan.

Aunque no se trata de una tecnología nueva, su evolución reciente ha sido extraordinaria. El término «inteligencia artificial» se consolidó como disciplina en la conferencia de Dartmouth de 1956. Desde entonces, la disponibilidad masiva de datos, el incremento de la capacidad de cálculo y la aparición de nuevas arquitecturas han multiplicado sus posibilidades. Entre estos avances destaca la arquitectura transformer, presentada en 2017 en el artículo Attention Is All You Need. Dartmouth College y Google Research.

Esta evolución está obligando a las organizaciones a posicionarse. Sin embargo, adoptar inteligencia artificial no consiste únicamente en contratar una herramienta o desplegar un modelo: también implica analizar costes, privacidad, dependencia tecnológica, continuidad del servicio y, por supuesto, seguridad.

Situacion actual de la IA

La inteligencia artificial ya forma parte del entorno empresarial. Para muchas organizaciones, la cuestión ha dejado de ser si deben utilizarla y ha pasado a ser cómo hacerlo de forma útil, sostenible y segura.

En el momento de escribir este artículo, acceder a modelos avanzados mediante suscripciones o API continúa siendo económicamente atractivo. No obstante, los precios, límites de uso y condiciones del servicio pueden cambiar. Construir procesos críticos sobre servicios externos exige, por tanto, valorar los riesgos derivados de posibles incrementos de costes, restricciones de capacidad o modificaciones contractuales.

También existen consideraciones geopolíticas y de soberanía tecnológica. Buena parte de los modelos y de la infraestructura más relevantes se concentra en proveedores estadounidenses y chinos, sometidos a marcos regulatorios, estrategias comerciales y políticas de exportación diferentes.

Esta dependencia ha impulsado el interés por desplegar modelos en infraestructura propia. La IA local puede aportar algunas ventajas:

• Mayor control sobre los datos y la infraestructura.
• Reducción de la dependencia de proveedores externos.
• Posibilidad de trabajar en entornos aislados.
• Costes más predecibles para determinadas cargas de trabajo.
• Personalización de modelos y procesos.

Sin embargo, alojar un modelo localmente no garantiza por sí solo su privacidad ni su seguridad. Una instalación mal configurada puede trasladar el riesgo desde el proveedor externo hasta la propia infraestructura de la organización.

Servidores de IA

Uno de los servidores de modelos más conocidos es Ollama. Su facilidad de instalación lo convierte en una opción muy popular para pruebas, desarrollo y ejecución local.

Por defecto, Ollama publica su API únicamente en 127.0.0.1:11434, por lo que no debería ser accesible desde otros equipos. No obstante, esta dirección puede modificarse mediante la variable OLLAMA_HOST. Si el servicio se configura para escuchar en todas las interfaces y además se publica en Internet, su API local no incorpora un mecanismo de autenticación que proteja el acceso. La propia documentación explica cómo exponerlo mediante un proxy, pero la autenticación y los controles adicionales deben implementarse en esa capa. Documentación de Ollama y autenticación de su API.

Existen otros servidores más orientados a ofrecer inferencia con mayor rendimiento, como llama.cpp o vLLM. Ambos pueden proporcionar interfaces compatibles con la API de OpenAI. llama.cpp, por ejemplo, permite configurar una clave mediante la opción --api-key. Documentación de llama.cpp.

La disponibilidad de estas opciones no significa que la instalación quede protegida automáticamente. Si la autenticación es opcional y no se configura, el servicio puede terminar expuesto sin ningún control de acceso.

Hands on Shodan

Shodan es un motor de búsqueda que recopila información sobre servicios accesibles desde Internet. Es un viejo conocido de este blog, donde ya hablamos de su API en el artículo Shodan API Exploit entre otros.

Localizar posibles servidores Ollama expuestos no resulta especialmente complicado. Esto plantea una pregunta evidente: si Ollama está diseñado principalmente para ejecutarse de forma local y su API no requiere autenticación, ¿cuántas instalaciones podrían estar ofreciendo sus recursos públicamente por una configuración inadecuada?

Para comprobarlo analicé distintos tipos de servidores de inferencia. Durante la investigación identifiqué 402 servicios de IA que respondían activamente:

• En 227 servidores —un 56,5 %— pude obtener la lista de modelos disponibles.
• En 140 —un 34,8 %— fue posible ejecutar consultas utilizando al menos uno de los modelos alojados.

El análisis no se realizó manualmente. Para automatizar las comprobaciones desarrollé AI Scanner, una pequeña herramienta que permite identificar estos servicios y verificar algunas de sus características de forma programática.

Estas cifras representan una fotografía tomada durante un periodo concreto. Los servicios publicados en Internet aparecen, desaparecen o cambian de configuración constantemente. Además, conviene diferenciar entre un servicio técnicamente accesible y uno publicado de forma accidental: desde el exterior no siempre es posible conocer la intención de su propietario.

El objetivo de esta investigación es concienciar sobre la importancia de proteger cualquier servicio que publiquemos en Internet, no fomentar su utilización abusiva. Las comprobaciones se limitaron a las acciones mínimas necesarias para verificar la exposición y no se intentó acceder a información privada, modificar configuraciones ni alterar los sistemas analizados.

¿Qué riesgos implica esta exposición?

Aunque un servidor de inferencia abierto no exponga directamente documentos privados, su publicación puede introducir distintos riesgos:

• Uso no autorizado de recursos. Un tercero puede consumir CPU, GPU, memoria, energía y ancho de banda.
• Denegación de servicio. Las consultas costosas o concurrentes pueden agotar la capacidad del servidor y afectar a las aplicaciones legítimas.
• Enumeración de modelos. La lista de modelos puede revelar información sobre la infraestructura y los casos de uso de la organización.
• Manipulación del servicio. Dependiendo del servidor y de los endpoints expuestos, podría ser posible descargar o eliminar modelos en el servidor expuesto.
• Explotación de vulnerabilidades. El servicio pasa a formar parte de la superficie de ataque y queda expuesto a posibles vulnerabilidades presentes o futuras.
• Acceso indirecto a datos. Si el modelo está integrado con sistemas RAG, agentes, herramientas o repositorios internos, el impacto puede ir mucho más allá del propio servidor de inferencia.
• Costes y responsabilidad. La infraestructura podría utilizarse para generar contenido abusivo o realizar actividades atribuibles inicialmente a la dirección IP de su propietario.

El riesgo aumenta considerablemente cuando el servidor no se limita a generar texto, sino que dispone de herramientas, acceso a archivos, bases de datos, buscadores internos o capacidad para ejecutar acciones.

Recomendaciones de seguridad

Si una organización necesita desplegar este tipo de servicios, debería aplicar al menos los siguientes controles:

• No publicar directamente el puerto del servidor de inferencia en Internet.
• Mantener el servicio escuchando en localhost o en una red interna segmentada.
• Utilizar un proxy inverso o una pasarela de API con autenticación robusta.
• Aplicar autorización por usuario, aplicación y modelo.
• Restringir el acceso mediante VPN, listas de control o políticas de red.
• Establecer límites de peticiones, concurrencia, tiempo y consumo.
• Deshabilitar endpoints administrativos que no sean necesarios.
• Registrar y monitorizar los accesos y patrones anómalos.
• Mantener actualizados el servidor, sus dependencias y los modelos.
• Revisar las integraciones con RAG, agentes, herramientas y fuentes de datos.
• Evitar que las credenciales aparezcan en registros, archivos de configuración o repositorios.
• Realizar revisiones periódicas de exposición mediante inventario, escaneo externo y gestión de superficie de ataque.

Conclusiones

La implantación de inteligencia artificial en infraestructura propia puede ser una estrategia adecuada cuando se busca control, privacidad, soberanía tecnológica o previsibilidad de costes. Sin embargo, una IA local no es automáticamente una IA segura.

Exponer un servidor de inferencia no implica necesariamente publicar los datos con los que se entrenó el modelo, pero sí amplía la superficie de ataque. Como mínimo, permite consumir recursos sin autorización y puede provocar degradaciones o interrupciones del servicio. En determinadas configuraciones también podría facilitar la manipulación de modelos o convertirse en una vía de acceso a otros componentes internos.

La facilidad con la que actualmente podemos desplegar un modelo no debe hacernos olvidar que seguimos publicando un servicio informático. Por tanto, deben aplicarse los mismos principios que utilizaríamos con cualquier otra API crítica: mínima exposición, autenticación, autorización, segmentación, monitorización y actualización continua.

Hasta aquí el post de hoy. Espero haya sido de vuestro interés.

No dudéis en contactar mediante el formulario para hacerme llegar vuestros comentarios.