Muestre los ataques entrantes del servidor dando el marcador de registros del servidor

En el mundo de los servidores, hay una conclusión predictiva de que los puertos no deben estar expuestos a Internet más grande si no son necesarios. En todas partes hay robots maliciosos que intentarán acceder accidentalmente a todo lo que esté conectado a una red, y es mejor simplemente apagarlos. Si necesita tener un puerto abierto, como el 22 para SSH, deberá verificarlo y verificarlo de manera segura para que el administrador lo rastree. Por lo general, esto se hace en un protocolo sistemático y se deja de lado, pero [Nick] Quería un recordatorio anterior de cuántas pruebas se habían escrito en sus sistemas.

Esta compilación monitorea activamente los intentos de iniciar sesión en su servidor en el puerto 22 y lo notifica a través de una pantalla numérica y una serie de LED. Se basa en una Raspberry Pi Zero W alojada en un contenedor impreso en 3D y funciona a través de una interfaz con un programa llamado fail2ban ejecutándose en el servidor. fail2banLa tarea principal es bloquear las direcciones IP que fallan en un cierto número de intentos de inicio de sesión en un servidor, pero al ser FOSS, se puede modificar para situaciones como esta. Con algún código de Python ejecutándose en la Pi, puede recopilar los datos que se le envían fail2ban y muéstralo.

[Nick] también podría ver resultados inmediatos. En 24 horas, vio 1633 intentos de inicio de sesión en un servidor con un inicio de sesión normal habilitado, que se mostró inmediatamente en la pantalla. Un video del contador en acción está vinculado a continuación. Sin embargo, no siempre necesita una pantalla secundaria si necesita información en tiempo real en su servidor. Este servidor Pi tiene su propia pantalla incorporada en su caja.

  • Mariusz dice:

    A finales de la década de 1990 tenía una impresora matricial conectada a un syslog, cada intento de inicio de sesión se guardaba permanentemente en papel. Todo estuvo bien hasta que los niños del guión comenzaron a escanear puertos como locos ... Todavía extraño ese sonido ...

    • Sameer A dice:

      "Guión de niños". No he usado / escuchado estas palabras en mucho tiempo. Gracias. 🙂 Incluiremos también a los "lamers". Entonces se necesitaban conocimientos básicos.

  • epitaxia dice:

    Ni siquiera ejecuto ssh a través del puerto estándar y esta pantalla se activará en unos días. Siempre fue bastante liviano hasta la semana pasada, cuando muchas direcciones aleatorias comenzaron a intentar usar la fuerza bruta. Desactive las contraseñas y solo permito las claves de inicio de sesión ahora.

    • Triplr dice:

      Incluya a sus usuarios en la lista blanca
      /etc/ssh/sshd_config.d/match-uaer.conf
      Rechazar inicio de sesión
      Denegar cáscara
      Rechazar comandos ssh

    • NiHaoMike dice:

      ¿Qué pasaría si alguien configurara una trampa SSH que aceptara una conexión de fuerza bruta, pero luego arrojara basura con la intención de bloquear el sistema que intenta ingresar?

      • Cyleleghorn dice:

        Tienen servidores Honey y contenedores de acoplamiento que puede configurar, y he visto casos en los que la gente reemplaza el ejecutable de inicio de sesión con scripts personalizados que hacen todo tipo de cosas, como pretender estar conectado a diferentes servidores (piense en ataques de phishing) o respuestas. a ls y cd y los comandos de hardware de manera diferente para confundir, excitar o aterrorizar al atacante para que se comporte de manera diferente.

        Tu comentario, sin embargo, me fascinó. ¿Qué vulnerabilidades tienen los clientes típicos de ssh en relación con cosas como desbordamientos de búfer? Al escribir nuestro propio programa de servidor que no necesita cumplir con el protocolo SSH, ¿cómo podríamos abusar del protocolo (que no ha cambiado mucho en décadas) para arruinar a las personas que lo usan para pruebas de fuerza bruta? Incluso si no se pudiera causar un daño constante, me gustaría mucho que pudiéramos bloquear esos scripts automáticos que barren todo el rango de ipv4 cada pocos minutos y obligarlos a reiniciarse manual o automáticamente. ¿Quizás podríamos dejarlos pasar el tiempo una vez, para que sepamos su parámetro de límite de tiempo, y luego dejar que sigan intentando ingresar varias veces y devolver una respuesta solo unos ms antes de que comience su límite de tiempo? Dependiendo de cuántas veces lo intenten antes de darse por vencido, esto podría ralentizar enormemente las secuencias de comandos automáticas para probar los 100 mejores usuarios / combinaciones de pases, ¡especialmente si su pausa fue de 15 o 30 segundos!

        No sería mucho, pero sería satisfactorio saber que estamos haciendo algo para solucionar este problema. Puntos adicionales si la NSA o la CIA acude a usted quejándose de que su servidor impide su capacidad para recopilar datos de acuerdo con la ley patriótica.

        • BillSF9c dice:

          +1 para puntos de bonificación ...

  • Menno dice:

    A finales de los noventa, cuando estaba empezando a explorar Linux, tenía mi computadora jugando Seven of Nine diciendo "Esta nave está bajo ataque" cuando alguien me buscó. (La computadora estaba conectada directamente al cable módem, los enrutadores aún no son visibles).
    Sin embargo, olvidé CÓMO lo configuré.

  • Tof dice:

    Necesita una interfaz fail2ban con MQTT 🙂

Miguel Vidal
Miguel Vidal

Deja una respuesta

Tu dirección de correo electrónico no será publicada.