Puertas traseras de servidor

Una puerta trasera de servidor casi siempre se delata por el lugar y no por su contenido. Un directorio de datos, como el de las imágenes que suben los clientes, no debería contener scripts: si en él aparece un archivo que el servidor web sabe ejecutar, cualquiera con la dirección puede mandarle órdenes por una petición web. Por eso la primera revisión de un servidor comprometido compara cada carpeta con lo que debería guardar.

Abre la consola. El inventario del directorio de la tienda trae cada ruta, su propietario y la fecha de última modificación. Busca los scripts que están dentro de la carpeta de subidas.

El registro de acceso dice si alguien usa el archivo. Un archivo de imagen se pide con GET desde cualquier navegador; un script de control se maneja con peticiones POST, siempre desde el mismo origen, con respuestas de tamaño variable porque cada una devuelve algo distinto. Esa dirección es un indicador de red del acceso, pero no necesariamente del atacante: puede ser un intermediario.

Otra forma de volver es un proceso que escucha en un puerto abierto a toda la red. Se compara cada puerto con el inventario de servicios que la empresa declara: el acceso remoto, el servidor web y la base de datos están; la base, además, solo escucha en la propia máquina. Lo que sobra es lo que hay que explicar.

Consulta qué escucha en todas las interfaces y busca el que no pertenece a ningún servicio declarado: su nombre imita a un componente del sistema, pero corre con la cuenta del servidor web.

La tercera forma es la más discreta: añadir una clave pública al archivo de claves autorizadas de una cuenta, para entrar por el acceso remoto sin contraseña. No hay proceso ni puerto, y cada entrada es un texto de una línea. Se revisa cuenta por cuenta contra el registro de cambios de sistemas, y se mira la fecha de alta. En este ejercicio las huellas son marcadores evidentes.