Honeypots XIII. Phpmyadmin + modsecurity+lua parser.

Amigos de Inseguros.

Hemos escrito ya algunos artículos sobre Honeypots (1, 2, 3, 4 ,5, 6 , 7. 8 9 11 12 ).

Dentro de los artículos que estoy escribiendo sobre recolección de inteligencia, vamos a hablar hoy de un pequeño Honeypot llamado PHPMYADMIN. Podemos usarlo para crear nuestra base de datos de reputación online. Con nuestro sistema de despliegue automático de Honeypot.

El título lo explica todo. Es un honeypot de interacción media. No solo tenemos el formulario de login sino un interface de uso "parecido" al real.




La instalación del honeypot es muy sencillo, seguimos el manual, simplemente copiamos el directorio del proyecto bajo nuestro webserver, le damos unos permisos al fichero de log y listo. En el fichero de login.php podemos habilitar el usuario/contraseña que dará acceso al falso phpmyadmin.

Lo interesante de este honeypot para mí es la pequeña interacción que le permite al atacante, ya que el sistema de logs que proporciona es muy escueto, quedando reducido a fecha, ip, recurso.


Con esta información podría trabajar con la dirección IP, pero prefiero saber qué está pasando realmente. Para ello, he instalado Mod Security sobre el Apache que sirve al honeypot, para recolectar toda la información sobre el ataque. El proceso lo he realizado sobre una máquina Honeydrive, por lo que el proceso de instalación de mod security para debian/ubuntu genérico me sirve. 

apt-get install libapache2-modsecurity
mv /etc/modsecurity/modsecurity.conf-recommended modsecurity.conf
service apache2 reload

Modifico el fichero modsecurity.conf para indicarle que me haga log de todos los eventos, no solo los 400 y 500 como se marca por defecto SecAuditLogRelevantStatus lo dejó así: SecAuditLogRelevantStatus "^(?:5|2|4(?!04))" y por supuesto hago un apache2 reload.

Para quitarme los Internal Dummy de Apache, configuro en apache2.conf la siguiente directiva:

SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
SetEnvIf User-Agent ".*internal dummy connection.*" dontlog

De esta manera ya podemos ver la información detallada de la actividad maliciosa sobre el honeypot.


Bien, ahora tenemos un honeypot funcionando y modsecurity generando fichero de logs. Todos sabemos lo complicado de parsear este log, y mucho mas si modificamos las opciones de "profundidad" de log. Para solventar este problema, voy a usar la posibilidad de mod security para ejecutar scripts.

Podemos ejecutar cualquier scripts en sh, pero si queremos tomar variables de mod security debemos emplear un script en LUA. La directiva está bien documentada en el manual de referencia. SecRuleScript y el script en LUA podría tener algo de este aspecto.

function main()
        local remote_addr = m.getvar("REMOTE_ADDR");
        if remote_addr == nil then
                return nil
        end
local request_uri = m.getvar("REQUEST_URI");
        if request_uri == nil then
                return nil
        end
-- INFO:::RULE_ID. Contiene el id de la regla que se ha ejecutado.
        local rule_id = m.getvar("RULE.id");
        if rule_id == nil then
                return nil
        end
-- INFO:::RULE_MSG. Contiene una descripcion de la rule que se ha ejecutado.
        local rule_msg = m.getvar("RULE.msg");
        if rule_msg == nil then
                return nil
        end
 local log_file = "/turuta//modsec_full.log"
        file = io.open(log_file,"a")
        file:write("IP: "..remote_addr.."\n".."Metodo: "..request_method.."\n".."Protocolo: "..request_protocol.."\n"..Matched by: "..matched_vars_names.."\n".."Regla id: "..rule_id.."\n".."Regla msg: "..rule_msg.."\n".."Hora: "..time.."\n".."----------------------".."\n")
        file:close()
end

De esta manera podemos obtener en un único registro, todas las variables o campos que nos interesan del log de Mod Security. Con esa información podemos alimentar nuestro sistema de inteligencia o de base de datos de reputación online con la información que nos llega de este honeypot, basado en PhpMyAdmin.

Como siempre, gracias por leerme, espero que os guste.