[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: consejos para linux

Gonzalo Rodriguez escribió:


2008/11/20 Pablo Jiménez <pejimene@vtr.net <mailto:pejimene@vtr.net>>

    On Thu, Nov 20, 2008 at 05:31:25PM +0000, Alberto Vicat wrote:
    > Gonzalo Rodriguez escribió:
    >> Estimados,
    >>
    >> Un consejo muy util, cambien el puerto de SSH!!!! al atacante o
    >> "personaje no deseado" le va a ser mas dificil hacer un brute
    force.
    >>
    >> usen un puerto alto ejemplo 29123 siempre por ensima de 1000 o
    mejor
    >> 10000 para estar mas seguro.

    Gonzalo:

    Eso no es seguridad. Como dicen por ahi: "Security through obscurity,
    isn't". Si deseas asegurar el servicio SSH en tu equipo:

    + Limita el servicio únicamente a direcciones IP conocidas
     (netfilter/iptables es tu amigo).
    + Limita el no. de intentos de conexión ssh (openssh y
    netfilter/iptables
     son tus amigos y la receta al respecto la publicaron hace unos
    meses por
     aquí)
    + Restringe el acceso SSH sólo a usuarios/grupos de usuarios conocidos
     (OpenSSH, PAM y LDAP son tus amigos en este punto).

    Otra opción interesante puede ser emplear port knocking...

    --
    Pablo Jiménez


    --
    To UNSUBSCRIBE, email to
    debian-user-spanish-REQUEST@lists.debian.org
    <mailto:debian-user-spanish-REQUEST@lists.debian.org>
    with a subject of "unsubscribe". Trouble? Contact
    listmaster@lists.debian.org <mailto:listmaster@lists.debian.org>



Pablo,
Como dicen por ahí, una maquina segura es la que esta apagada y dentro de una caja fuerte.
Yo lo di como consejo ya que varios postearon sus logs, y como dicen en la tele en los "llamen ya":
Desde que le cambie el puerto al SSH, ya no tengo entradas invalidas en mi log!.
Como vos lo dices, otro consejo es limitar el acceso, etc.etc. pero la seguridad no va solo en limitar el ssh, si no de controlar todas las aplicaciones que se ejetutan en tu linux que hacen y que dejan de hacer.
Si yo quisiera "ingresar" a una maquina, lo primero que haria es ver que aplicaciones esta corriendo, por ejemplo si tiene apache y este tiene soporte para CGI o php si es asi probar si hay alguna aplicaciones que me permita hacer un POST via http para subir algun archivo ejecutable, que en muchos casos es mucho mas util que tener acceso SSH.
No dije que era seguridad en ningún momento es solo un consejo, por que a Seguro se lo llevaron preso. 

Saludos!.
Seguridad por oscuridad es un tipo de seguridad ahora en qué nivel con respecto a otros métodos mucho más abajo. Si tienes el ssh corriendo en un puerto diferente los bots que tratan de conectarse al ssh en el puerto 22 de seguro que no van a aparecer más en los logs. Pero si tienes a un tipo escanendote los puertos y hace un telnet a los puertos abiertos lo más seguro es que haga el telnet al puerto alto del ssh y salga un banner muy lindo que diga "openssh en Debian X.XX" y listo.
Tienes derecho a limitar toda la información de tus servidores por ejemplo los banners de apache, del smtp y del ssh pero eso no es una garantía de seguridad si no en Debian vendrían desactivados por defecto. Hay más de una manera de saber si un puerto pertenece a determinado servicio y más aún que programa y versión escucha en ese puerto.
Por eso la seguridad por oscuridad es un paso pero definitivamente no lo es todo y basarse solo en ella es un craso error. La administación de la seguridad debe plantearse siempre tratando de conocer la perspectiva del atacante. 

Algunas medidas que agregaría serían:

Bajar todos los servicios que no sean necesarios
Asegurar todos los servicios que sean necesarios. Estar pendiente de los fallos de seguridad, por ejemplo los famosos fallos de buffer overflow. (Que son los que dan con facilidad acceso a bash a un atacante). Usar servicios enjaulados (chroot), en especial los críticos. (Por ejemplo postfix y bind vienen enjaulados en Debian). 
Denegar el acceso a root por ssh
Si eres muy paranoico usar port nocking
Usar conexiones seguras para toda la información sensible
Usar claves publicas y privadas en el acceso por ssh y si se quiere más seguridad passphrases. 
Desactivar la shell de los usuarios que no sean interactivos
Escribir aplicaciones web teniendo en cuenta los posibles fallos de seguridad y debilidades del lenguaje (sql injection, ldap injection, etc.) No permitir que se filtre información de la configuración interna de tu red (si es interno no tienen otros por qué saberlo) 

Saludos
Reply to: