Software

Seguridad por Oscuridad

Algo que me logrado tocar ver con implementaciones  y soluciones  es adoptar algunos conceptos de seguridad por oscuridad que se aplican y que personalmente tienen poco aporte a las medidas de seguridad de un sistema informático. Puedes ver más información del concepto de Seguridad por oscuridad en Wikipedia.

De las medidas que se adoptan pueden mitigar los problemas pero realmente hacen una estela de humo que nos hace sentir algo mas seguros pero en terminos de seguridad propia poco aportan.

Algunas medidas que me encontrado es cambiar número del puerto del servicio por otro que no sería el estandar, por ejemplo de SSH del 22 a 2222.

Otro caso es cambiar el nombre del agente servicio ya sea el servicio HTTP de Apache por algún otro nombre que no corresponda o con módulos no los correspondientes.

Un nuevo caso es de DROP versus REJECT, donde el caso de DROP podría tener mas consecuencias negativas de usar REJECT. Todo esto en relación a IPTABLES.

Si bien los casos anteriores pueden ayudar a esconder o obtener seguridad por oscuridad creo que realmente no son efectivos.

¿Que opinas?

2 thoughts on “Seguridad por Oscuridad”

  1. Puede ser util para «retrasar» un scaneo basico, pero lo mejor para un puerto como el del ssh es escondelo detras de un portknoking o un fwknop, asegurandonos que siquiera esté abierto a ataques externos

  2. la verdad siempre he pensado que la seguridad por oscuridad a lo mucho te da tiempo.

    los temas de seguridad deberían tratarse como se hace con la criptografía: si no eres un experto, no escribes tus propios sistemas criptográficos (o inventas tus propias políticas de seguridad), y si es que no es 100% abierto y que todos lo puedan auditar, realmente no es seguro.

    me parece buena la idea de aplicarse a las buenas prácticas y la idea de hardened linux me parece bien
    nunca me había puesto apensar entre drop vs reject.

    en el caso de DROP vs REJECT, me parece que lo mejor sería imitar cualquier sea el comportamiento que venga por defecto, onda, si un servidor no tiene apache instalado, (no sé si linux responde con drop o reject)
    pero si tuviera apache instalado detrás de IP tables y quisiera que no se pudiera acceder, me parece que lo mejor sería tener el mismo comportamiento que si no estuviera instalado

    como dice «Hiding information about which ports are active requires making the server response indentical whether or not it offers a particular service. This is technically very difficult, and in some cases will be more error prone than actually providing the service!»
    REJECT suena mejor que DROP

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.