Blog

Archive for julio, 2017

Integración con Crad-Log-Watcher para bloquear IPs por fallos de login para aplicaciones web/servidor

[extoc]

Para integrar los fallos de login con crad-log-watcher y hacer que la IP remota sea bloqueada automáticamente cuando el número de fallos de login sean alcanzados, entonces siga la siguiente guía.

Los siguientes pasos le ayudarán a crear un handler para gestionar fallos de login que serán trazados y marcados para cualquier aplicación, de manera que la IP de origen sea bloqueada cuando un humbral configurable sea alcanzado.

  1. Primero, haga que su aplicación web o servidora genere una indicación de log con la IP que debería ser bloqueada (o controlada).

    Recomendamos enviar este log a syslog debido a que este log es accesible a todos los usuarios del sistema y no requiren un usuario ni permisos especiales. Esto simplificará los siguientes pasos. Si decide enviar esta información a otro log, simplemente adapte los siguientes pasos como corresponda.

    Con PHP, generar dichos logs, sería:

    // en caso de logins fallidos ::
            $remoteAddr = $_SERVER['REMOTE_ADDR'];
            $currentWeb   = $_SERVER['SERVER_NAME'];
            $loginAttempted = // apunte esta variable al login que ha sido intentado y ha fallado
            syslog (LOG_INFO, "Login failure from [$remoteAddr] access denied to [$currentWeb] with user [$loginAttempted]");
            

    Esto hará que se registre un log en el syslog cada vez que haya un fallo de login.
    Esto será necesario para cada aplicación web o servicio que sea necesario proteger.

  2. Ahora, cree un handler personalizado para crad-log-watcher que lea estos logs, lleve una traza de los logins fallidos y bloquee las IPs alcanzado los umbrales:

    Para eso, cree un fichero llamado login_failure_handler.py con el siguiente contenido (adapte a sus necesidades):

    #!/usr/bin/python
    
    from core_admin_common import support
    from core_admin_agent  import checker, watcher
    
    # database for tracking login failures
    database_path = "/etc/core-admin/client/my.watcher.sql"
    
    def init ():
    
        # notify this is child for checker notification
        checker.is_child = True
    
        # track and lock login failures
        (status, info) = watcher.create_track_login_failure_tables (database_path)
        if not status:
            return (False, "Unable to create ip_registry table, error was: %s" % info)
    
        return (True, None) # return ok init
    
    def handle_line (line, source_log):
    
        # only process log failures to block
        if "login failure from [" in line.lower () and "access denied to [" in line.lower ():
            
            # assuming log error format:
            # Jul  7 16:15:29 node04-grupodw python: Login failure from [88.99.109.209] access denied to [http://foobar.com] with user [userAccess1]
        
            source_ip_to_block    = line.lower ().split ("login failure from [")[1].split ("]")[0]
            login_failure_because = line.lower ().split ("access denied to [")[1].split ("]")[0]
            user_login            = line.lower ().split ("with user [")[1].split ("]")[0]
    
            # configure notification
            reason                   = "Access failure to %s" % login_failure_because
            fail_logins_before_block = 10
            
            # call to track user and ip
            watcher.track_and_report_login_failure (user_login, source_ip_to_block, reason, database_path, fail_logins_before_block, source_log)
    
        # end if
        
        return
    
  3. Ahora, ajuste este fichero dentro de /var/beep/core-admin/client-agent/log-handlers (cópielo dentro de este directorio)

  4. Ahora, dentro de /etc/core-admin/client/log-watcher.d, cree un fichero que vincule su /var/log/syslog con el handler que acaba de crear. Por ejemplo, haga que el fichero tenga la siguiente ruta: /etc/core-admin/client/log-watcher.d/custom-login-failures-blocker

    <log src="/var/log/syslog" handler="login_failure_handler" />
  5. Después de eso, simplemente reinicie crad-log-watcher para hacer que lea su handler y la configuración creada con:

    /etc/init.d/crad-log-watcher restart
  6. Supervise la ejecución de crad-log-watcher para asegurar que todo está funcionando con:
    # tail -f /var/log/syslog | grep crad-log-watcher
  7. Ahora, pruebe el desarrollo causando login fallidos al sistema protegido. Debería ver logs creados en /var/log/syslog.

    Si no ve ningún fallo de login, entonces el sistema no funcionará. Revise su código para asegurar que estos logs son creados.

  8. Si los logs de fallo de login son creados, entonces use el siguiente comando para mostrar si el trazado de login fallidos está ocurriendo:

    # sqlite3 -column -header /etc/core-admin/client/syslog.watcher.sql "select * from login_failure"

¿Alguna cuestión? Contacte con nosotros en support@core-admin.com (https://www.core-admin.com/portal/about-us/contact).

Posted in: Blacklist, Firewall, Seguridad

Leave a Comment (0) →

Solucionando el error de Dovecot panic mail-index-sync-keywords.c

Índice de claves

  • Dovecot índices rotos en el buzón
  • Panic: file mail-index-sync-keywords.c:
  • dovecot_mailbox_broken_indexes

Introducción

Si tiene problemas mientras accede a un buzón y después de revisar los logs, encuentra algo como:

Jul  4 10:44:22 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:44:31 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:45:04 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:45:23 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:45:34 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:46:40 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:48:45 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))

Entonces, uno o más índices o cachés de dovecot están defectuosos. Esto ocurre debido a mover buzones desde distintas versiones de dovecot. También
puede ocurrir con versiones no actualizadas de servidores dovecot.

Resolución

Core-Admin detectará estos errores automáticamente y los notificará como: dovecot_mailbox_broken_indexes

Pinche sobre él, y luego pinche sobre “Reset dovecot indexes”.

Esto limpiará todos los índices de dovecot en la máquina de destino para el buzón que esté fallando.

Si quiere solucionarlo manualmente, localice el buzón asociado al usuario y ejecute el siguiente comando (actualízelo accorde al usuario fallando):

>> find /var/spool/dovecot/mail/core-admin.com/someuser  -name 'dovecot*' -type f -delete" 

Después de esto, ya debería haber corregido el problema. No hace falta reiniciar Dovecot.

Posted in: Core-Admin, Dovecot

Leave a Comment (0) →