Tengo un servidor ejecutándose con fines de prueba que últimamente detectó algunas entradas de registro extrañas en /var/log/syslog, /var/log/user.log y /var/log/messages. auth.log no muestra nada sospechoso. Ningún usuario (humano) debería haber iniciado sesión durante este tiempo.
El servidor casi no ejecuta software, solo el demonio sshd.
Las entradas del registro no revelan qué programa las creó; parecen originarse a partir de alguna actividad de exploración y sondeo de puertos.
¿Alguien tiene una idea de dónde pueden venir estos mensajes? (SOMEDATETIME es la hora de la entrada del registro y SOMEIP es una dirección IP desconocida)
SOMEDATETIME GET / HTTP/1.0#015
SOMEDATETIME SOMEIP #015
SOMEDATETIME SOMEIP #015
SOMEDATETIME SOMEIP #015
SOMEDATETIME OPTIONS / HTTP/1.0#015
SOMEDATETIME SOMEIP #015
SOMEDATETIME OPTIONS / RTSP/1.0#015
SOMEDATETIME SOMEIP #015
SOMEDATETIME SOMEIP HELP#015
SOMEDATETIME SOMEIP #026#003#000#000S#001#000#000O#003#000?G���,���`~�#000��{�Ֆ�w����<=�o�#020n#000#000(#000#026#000#023
SOMEDATETIME SOMEIP #026#003#000#000i#001#000#000e#003#003U#034��random1random2random3random4#000#000#014#000/
SOMEDATETIME SOMEIP #000#000#000qj�n0�k�#003#002#001#005�#003#002#001
SOMEDATETIME GET /nice%20ports%2C/Tri%6Eity.txt%2ebak HTTP/1.0#015
SOMEDATETIME SOMEIP #015
SOMEDATETIME SOMEIP #001default
SOMEDATETIME SOMEIP #002
SOMEDATETIME OPTIONS sip: nm SIP/2.0#015
SOMEDATETIME SOMEIP Via: SIP/2.0/TCP nm;branch=foo#015
SOMEDATETIME SOMEIP From: <sip:nm@nm>;tag=root#015
SOMEDATETIME SOMEIP To: <sip:nm2@nm2>#015
SOMEDATETIME SOMEIP Call-ID: 50000#015
SOMEDATETIME SOMEIP CSeq: 42 OPTIONS#015
SOMEDATETIME SOMEIP Max-Forwards: 70#015
SOMEDATETIME SOMEIP Content-Length: 0#015
SOMEDATETIME SOMEIP Contact: <sip:nm@nm>#015
SOMEDATETIME SOMEIP Accept: application/sdp#015
SOMEDATETIME SOMEIP #015
Respuesta1
Es el resultado de que alguien ejecute un escaneo de Nmap en su servidor: Nmap encuentra un puerto TCP abierto y luego envía varios paquetes tratando de descubrir si alguno de los tipos de servicios comunes (HTTP, RTSP, SIP,...) está activo. en ese puerto.
(Intenté ejecutar Zenmap 7.40 en una aplicación de servidor que estoy desarrollando y registré exactamente la misma secuencia de cadenas).
Respuesta2
Descubrí que la explicación de este comportamiento está en la configuración de rsyslog. De forma predeterminada, rsyslog acepta entradas UDP desde el puerto 514 y registra cualquier paquete entrante en los archivos de registro de mensajes, syslog y usr.log. Esto se debe a que rsyslog también está configurado para actuar como un servicio de registro remoto de forma predeterminada. Esto se puede desactivar comentando.
#$ModLoad imudp
#$UDPServerRun 514
#$ModLoad imtcp
#$InputTCPServerRun 514
en /etc/rsyslog.conf
Respuesta3
El registro que mostró no es extremadamente útil: no está claro si SOMEIP es siempre el mismo o no, o si SOMEEDATETIMEs son muy diferentes, o todos ocurren en una ráfaga, o están agrupados alrededor de una pequeña cantidad de intervalos de tiempo.
En cualquier caso, son básicamente intentos de comunicarse con su servidor web, que no está ejecutando, por lo tanto, los mensajes se registran en /var/log en lugar de /var/log/apache2algo así. Parece un poco extraño que alguien se esfuerce tanto en intentar abrir un servidor web que no está escuchando, asegúrese de hacerlo.notener un servidor web en ejecución comprobando la salida de
ss -lntp
para servidores que escuchan en puertos estándar (80,443) o no estándar.
Los registros restantes se vuelven más interesantes porque registran los intentos de contactar con una PBX a través de su servidor web, PBX que, según su OP, no está ejecutando. Sin embargo, el protocolo (SIP), la dirección <sip:nm@nm>y elProtocolo de descripción de sesión( Accept: application/sdp) todos dicen mucho sobre esto.
Una vez más, ¿está seguro de que no está ejecutando unPBX? Parece que alguien ha colocado uno en su máquina. De nuevo,sicree que su máquina no ha sido violada, el comando
ss -lnup
(para el protocolo UDP, en lugar del protocolo TCP) le indicará qué proceso está escuchando en qué puerto.
Pero, si su máquina ha sido violada, es muy posible que lo anterior no informe nada sospechoso, aunque en realidad están sucediendo muchas cosas ilegales. Puedes intentar calmar tus temores (bien fundados, por desgracia) descargando y ejecutando chkrootkity rkhunter. tu también puedesleer aquí(disculpas por referirme a mi propia respuesta, sé que no es agradable pero me ahorra algo de trabajo). Y sobre todo deberías preguntarte:¿Desactivé el inicio de sesión con contraseña en ssh e introduje claves criptográficas en su lugar?Si la respuesta a esta pregunta esNo, entonces es probable que su máquina haya sido violada. Luego debe volver a instalarlo desde cero y seguir las instrucciones anteriores para deshabilitar el inicio de sesión con contraseña y sshutilizar claves públicas/privadas, que son inmensamente más seguras.