Hola a todos: Tengo la siguiente duda. Quiero abrir el puerto el puerto 22 para ssh para entrar a la maquina remotamente, tanto desde la red local interna como desde el exterior. Aqui os pego parte del SuSEfirewall2: # Examples: "ssh", "123 514", "3200:3299", "ftp 22 telnet 512:514" # FW_SERVICES_EXT_TCP="" ## Type: string # # Which UDP services _on the firewall_ should be accessible from # untrusted networks? # # see comments for FW_SERVICES_EXT_TCP # # Example: "53" # FW_SERVICES_EXT_UDP="" ## Type: string Mi duda es tiene que ir así: FW_SERVICES_EXT_TCP="ssh" hay bastante con ssh o hay que poner el puerto 22 o en otro lado? Así como UDP hay que ponerlo tambien, yo creo que no. gracias manel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-01-21 a las 14:31 +0100, manel escribió:
Tengo la siguiente duda.
Quiero abrir el puerto el puerto 22 para ssh para entrar a la maquina remotamente, tanto desde la red local interna como desde el exterior.
FW_SERVICES_EXT_TCP="ssh" FW_SERVICES_INT_TCP="ssh" - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD0j1itTMYHG2NR9URAtZPAKCVgtXG7TjW0yZ2aus0fmd/vU8tPgCdGny2 V0ri6snzvmesQ4YZCHEaBQA= =DGo0 -----END PGP SIGNATURE-----
Muchas gracias Carlos Saludos Manel
Quiero abrir el puerto el puerto 22 para ssh para entrar a la maquina remotamente, tanto desde la red local interna como desde el exterior.
FW_SERVICES_EXT_TCP="ssh" FW_SERVICES_INT_TCP="ssh"
- -- Saludos Carlos Robinson
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-01-21 a las 19:04 +0100, manel escribió:
Quiero abrir el puerto el puerto 22 para ssh para entrar a la maquina remotamente, tanto desde la red local interna como desde el exterior.
FW_SERVICES_EXT_TCP="ssh" FW_SERVICES_INT_TCP="ssh"
Muchas gracias Carlos
Por cierto, mucho cuidado con el ssh abierto al exterior, hay scripts por ahí bombardeando para tratar de encontrar password debiles en el ssh y entrar. Merece la pena permitir la entrada sólo con pareja de llaves, y quizás alguna estrategia para bloquear las IPs de imbéciles bombardeantes. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD0twQtTMYHG2NR9URAvbcAJ9epf9n42jYrz6/q/Tms7icQ/HzLgCfZCYk wp9OKXxswBO6yxUgLiUmkCI= =31kH -----END PGP SIGNATURE-----
Por cierto, mucho cuidado con el ssh abierto al exterior, hay scripts por ahí bombardeando para tratar de encontrar password debiles en el ssh y entrar
Se trata de gusanos molestos pero no peligrosos (salvo que consigan su objetivo.) Mia eso es un "log" de ayer de uno de esos gusanos: Jan 21 21:04:16 ironhost sshd[16809]: Invalid user paul from ::ffff:66.221.90.110 Jan 21 21:04:26 ironhost sshd[16809]: Failed password for invalid user paul from ::ffff:66.221.90.110 port 3238 ssh2 Jan 21 21:08:00 ironhost sshd[16811]: Invalid user insert from ::ffff:66.221.90.110 Jan 21 21:08:10 ironhost sshd[16811]: Failed password for invalid user insert from ::ffff:66.221.90.110 port 2480 ssh2 Jan 21 21:09:00 ironhost sshd[16811]: Invalid user root from ::ffff:66.221.90.110J an 21 21:10:39 ironhost sshd[16813]: Failed password for root from ::ffff:66.221.90.110 port 1632 ssh2 Jan 21 21:13:29 ironhost sshd[16815]: Invalid user test from ::ffff:66.221.90.110 Jan 21 21:13:39 ironhost sshd[16815]: Failed password for invalid user test from ::ffff:66.221.90.110 port 4868 ssh2 Jan 21 21:16:29 ironhost sshd[16836]: Invalid user aa from ::ffff:66.221.90.110 Jan 21 21:16:39 ironhost sshd[16836]: Failed password for invalid user aa from ::ffff:66.221.90.110 port 4012 ssh2 Fíjate que intenta la conexión como "root" cuando lo más lógico es que "root" no pueda hacer conexiones remotas :-)
Merece la pena permitir la entrada sólo con pareja de llaves, y quizás alguna estrategia para bloquear las IPs de imbéciles bombardeantes.
La pareja de llaves es una buena solución si se prohibe el acceso por password. Lo de bloquear las IPs es perder el tiempo. Normalmente se trata de maquinas "zombies" con IPs dinámicas conectadas las 24 h. por ADSL o por cable, cuyos propietarios no tienen ni la más mínima idea de lo que hace su ordenador (ni de como funciona) Digo "normalmente" porque no parece ser precisamente el caso del ejemplo. :-) -- Saludos, Josep M. Queralt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-01-22 a las 11:49 +0100, Josep M. Queralt escribió:
Por cierto, mucho cuidado con el ssh abierto al exterior, hay scripts por ahí bombardeando para tratar de encontrar password debiles en el ssh y entrar
Se trata de gusanos molestos pero no peligrosos (salvo que consigan su objetivo.) Mia eso es un "log" de ayer de uno de esos gusanos:
Claro, claro... pero eso como el chiste del tonto y los dos ladrillos, si aciertan nos j... [logs]
Fíjate que intenta la conexión como "root" cuando lo más lógico es que "root" no pueda hacer conexiones remotas :-)
Si, prueba una lista de usuarios habituales, y si cree que existen, lanza un ataque de tipo diccionario. Había un "agujero" en el sshd, que el tiempo de respuesta al login si el usuario existe o no era ligeramente distinto, y así detectaban los usuarios válidos para lanzar el ataque. Ese agujero ya está corregido, pero los scripts siguen ahí.
Merece la pena permitir la entrada sólo con pareja de llaves, y quizás alguna estrategia para bloquear las IPs de imbéciles bombardeantes.
La pareja de llaves es una buena solución si se prohibe el acceso por password.
A eso me refiero.
Lo de bloquear las IPs es perder el tiempo. Normalmente se trata de maquinas "zombies" con IPs dinámicas conectadas las 24 h. por ADSL o por cable, cuyos propietarios no tienen ni la más mínima idea de lo que hace su ordenador (ni de como funciona)
Ya, ya. Pero el bloqueo también puede ser dinámico. Yo estoy usando esto en "/etc/sysconfig/scripts/SuSEfirewall2-custom", que publicó uno en la lista de seguridad: fw_custom_before_antispoofing() { #Cer 2051225 - de un correo en suse-security # Blocking ssh attacks iptables -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'SSH attack: ' iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 60 --hitcount 6 -j REJECT # This will block all further syns from an IP address starting on the # sixth port 22 connection within 60 seconds. It takes 60 seconds of # absolute quiet from that same ip address (or a reboot) to make the # block go away. Kills a LOT of brute force ssh attacks. I've also # used this both against web statistics spammers and email DOSers with # good results. true } No se si debiera usar DROP en vez de REJECT :-? Lo que hace es bloquear la IP a partir del sexto intento de conexión al puerto 22; a partir de ese momento necesita un minuto de silencio desde esa IP antes de borrar el bloqueo.
Digo "normalmente" porque no parece ser precisamente el caso del ejemplo. :-)
No, una vez que detectan un linux por ahí lo masacran a intentos hasta entrar o darlo por imposible. Los ordenadores son pacientes, el script seguirá dale que te pego. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD03vntTMYHG2NR9URAh97AJ0RHJMqUh57x7TweYvVPrSthcJn7gCfewQK mjKdPuiL+1SV/of1bNoL7Z4= =K+PJ -----END PGP SIGNATURE-----
Ya, ya. Pero el bloqueo también puede ser dinámico. Yo estoy usando esto en "/etc/sysconfig/scripts/SuSEfirewall2-custom", que publicó uno en la lista de seguridad:
[parte del script] Me podrias enviar al privado el script y decirme donde lo pongo. Gracias Carlos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-01-22 a las 14:39 +0100, manel escribió:
Ya, ya. Pero el bloqueo también puede ser dinámico. Yo estoy usando esto en "/etc/sysconfig/scripts/SuSEfirewall2-custom", que publicó uno en la lista de seguridad:
[parte del script]
Me podrias enviar al privado el script y decirme donde lo pongo.
¡Si ya lo mandé! El script es el /etc/sysconfig/scripts/SuSEfirewall2-custom, que existe, sólo tienes que modificar la función fw_custom_before_antispoofing, que está en blanco. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD0571tTMYHG2NR9URAgSIAKCBdoGO2PPcAG+tJ03BT+/GB8kRRgCfV5F9 F8LF39kndGaHfmFuw5fWH84= =VMCT -----END PGP SIGNATURE-----
La pareja de llaves es una buena solución si se prohibe el acceso por password.
A eso me refiero.
Es que se puede permitir el acceso indistinto. Si no hay llave pide password.
Ya, ya. Pero el bloqueo también puede ser dinámico. Yo estoy usando esto en "/etc/sysconfig/scripts/SuSEfirewall2-custom", que publicó uno en la lista de seguridad:
Este script me lo quedo. :-)
Digo "normalmente" porque no parece ser precisamente el caso del ejemplo. :-)
No, una vez que detectan un linux por ahí lo masacran a intentos hasta entrar o darlo por imposible. Los ordenadores son pacientes, el script seguirá dale que te pego.
No, lo decía por la IP atacante, 66.221.90.110 te lleva a la página principal de una compañía de "hosting" y de servicios web, que SI vale la pena bloquear permanentemente. Bien por negligencia (tienen el gusano dentro) bien por mala leche (son conscientes de lo que estan haciendo) mejor no tener tratos con ellos. -- Salutacions - Saludos, Josep M. Queralt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-01-22 a las 18:52 +0100, Josep M. Queralt escribió:
La pareja de llaves es una buena solución si se prohibe el acceso por password.
A eso me refiero.
Es que se puede permitir el acceso indistinto. Si no hay llave pide password.
Es que lo dije: |> Merece la pena permitir la entrada sólo con pareja de llaves, ·····································^^^^^ ;-)
Ya, ya. Pero el bloqueo también puede ser dinámico. Yo estoy usando esto en "/etc/sysconfig/scripts/SuSEfirewall2-custom", que publicó uno en la lista de seguridad:
Este script me lo quedo. :-)
Es que es mucho más sencillo que la historia de analizar los logs y bloquear en hosts.deny... Había por ahí un contrascript, que lo que hacía, he oido, era responder dejando abierta la conexión hasta que temporizaba: esto es, convertir el atacante en atacado por DOS :-p Lo que pasa que lo retiraron porque eso en usalandia podía ser delictivo.
No, una vez que detectan un linux por ahí lo masacran a intentos hasta entrar o darlo por imposible. Los ordenadores son pacientes, el script seguirá dale que te pego.
No, lo decía por la IP atacante, 66.221.90.110 te lleva a la página principal de una compañía de "hosting" y de servicios web, que SI vale la pena bloquear permanentemente.
¡No fastidies! :-O Que una empresa de hospedaje "pofesional" esté "violada" o violando... tiene narices la cosa. ¡Ostrás!
Bien por negligencia (tienen el gusano dentro) bien por mala leche (son conscientes de lo que estan haciendo) mejor no tener tratos con ellos.
Caray... - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD098DtTMYHG2NR9URAgRSAJwJ/bDGpp3tFriV47twfjmIrEjzwwCfX4rq o8cBPy/mK5HGQcCx/yZbsQo= =P1Wg -----END PGP SIGNATURE-----
El Domingo, 22 de Enero de 2006 13:34, Carlos E. R. escribió:
Claro, claro... pero eso como el chiste del tonto y los dos ladrillos, si aciertan nos j...
* ssh implementa mecanismos muy suficientes. LoginGracetime MaxStartups MaxAuthTries http://lists.suse.com/archive/suse-linux-s/2005-Feb/0224.html
No se si debiera usar DROP en vez de REJECT :-?
* Depende de los gustos, segun el mio indudablemente.
No, una vez que detectan un linux por ahí lo masacran a intentos hasta entrar o darlo por imposible. Los ordenadores son pacientes, el script seguirá dale que te pego.
* En estos casos generar automaticamente una lista negra en un fichero, es bueno, a partir del flag "Invalid" de los logs del cortafuegos, o en el caso que pones de 'SSH attack: ' y aplicar la regla de denegacion de ip's a partir de los distintos ficheros comparados y autoalimentados. --------------- touch historico_ssh sleep 10 grep Invalid /var/log/messages > ips cat ips | awk '{ FS = " " } { print $10 | "uniq" }' | sort | uniq > ext_ip comm -1 historico_ssh ext_ip > nueva_ip cat ips | awk '{ FS = " " } { print $10 | "uniq" }' | sort | uniq > / historico_ssh cat nueva_ip | sed -e '/^\t/d' > bloquear_estas_ips cat bloquear_estas_ips >> black_list.txt cat bloquear_estas_ips | awk '{ system("iptables -A INPUT -i eth0 -p tcp / --dport 22 \ -j DROP -s " $0 )}' ------------------
Merece la pena permitir la entrada sólo con pareja de llaves, y quizás alguna estrategia para bloquear las IPs de imbéciles bombardeantes.
OK Gracias Carlos por el consejo así lo are, de momento hasta que no este configurado no le doy permiso desde fuera. Gracias manel
participants (4)
-
Carlos E. R.
-
jose maria
-
Josep M. Queralt
-
manel