Solicitud GET extraña a /proxychecker/check.cgi [duplicar]

Question

Solicitud GET extraña a /proxychecker/check.cgi [duplicar]

#1 de Anders (1 votos)

-1

Comencé a ejecutar una aplicación de matraz en una pi frambuesa anoche. No se escondía detrás de apache o nginx, atendía las solicitudes por sí mismo. Configuré mi enrutador para reenviar el tráfico http hacia él como una prueba de concepto. Ahora, para mostrarle a alguien cómo se ve, lo dejé encendido durante la noche. Esta mañana me desperté con algunas solicitudes GET que no entiendo muy bien:

[ip-address] - - [date] "GET http://[ip-address]/proxychecker/check.cgi?action=getinfo HTTP/1.1" 404-

y

[another ip-address] - - [date] "GET /xmlrpc.php HTTP/1.1" 404 -

¿Algo de esto es algo de lo que deba preocuparme? ¿Qué es exactamente lo que están tratando de lograr con estas solicitudes? Particularmente el primero.

webserver raspberry-pi

pregunta CodyJae 15.09.2016 - 14:18

fuente

1 respuesta

Lea otras preguntas en las etiquetas webserver raspberry-pi

¿Limitar la cadena de cinco letras para incluir solo las palabras del diccionario en Crunch? Puedo tener un virus. ¿Que puedo hacer? [duplicar]

score 1 · Accepted Answer

Es un escaneo automatizado para software vulnerable. Si se conecta solo a Internet, recibirá solicitudes como estas antes de poder decir "seguridad de la información".

El primero comprueba si eres un proxy abierto , por ejemplo. si permites que alguien te use como servidor proxy. Encontrarlos es útil cuando está ejecutando ataques automatizados porque significa que los ataques pueden ser transmitidos por ellos. No me sorprendería si los números de IP en sus registros provienen de servidores con este tipo de vulnerabilidad.

La segunda prueba si está ejecutando WordPress y tiene activada la interfaz XML-RPC. Se puede usar para hacer ataques de fuerza bruta en la contraseña del administrador .

Es importante comprender que estas no son explotaciones reales, sino exploraciones para detectar vulnerabilidades que pueden explotarse en el siguiente paso. Dado que devolvió 404 en ambos casos, lo que indica que no es un proxy y no está ejecutando WordPress, el resultado fue negativo para el atacante. Probablemente siguieron adelante, y no estaría muy preocupado si fuera tú.