- January 2012
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- July 2007
- hector Gracias, muy util!!...
- Makendra It's always a pleasure to hear from someone with eexrpitse....
- Rubén Ortiz Hola dependerá de varias cosas pero la respuesta sería NO. ...
- jose miguel perea Buenos días, ¿La replicación entre maestro y esclavo es i...
- Rubén Ortiz Si lo hacéis legal, con VMware el único problema son los cos...
SSH – Intentos intrusión
Por lo que he podido leer, circula por la red un script que algunos lammers utilizan para probar conexiones contra el puerto 22, que normalmente suele ser donde escucha el servicio SSH(secure shell). Estos intentos también pueden deberse a otros pcs zoombies o simplemente, gente que quiere intentar entrar en el host por ssh. Esto es especialmente peligroso, si se tiene habilitado el acceso root por ssh. Aunque puede que exista la necesidad imperiosa de entrar por ssh para tareas de mantenimiento y no haya otra.
Más que el peligro de que accedan por ssh, cosa que no deja de ser complicada al fin y al cabo, lo que me molesta es la cantidad de accesos a disco que provocan estos intentos de acceso. Si vemos el log del secure, en /var/log/secure se puede ver algo así:
#Jan 14 00:31:00 dns7 sshd[3207]: Did not receive identification string from 189.17.176.130
#Jan 14 00:31:00 dns7 sshd[3208]: Did not receive identification string from 189.17.176.130
#Jan 14 00:46:20 dns7 sshd[3982]: Illegal user rhiroot from 189.17.176.130
#Jan 14 00:46:20 dns7 sshd[3983]: Illegal user rhiroot from 189.17.176.130
#Jan 14 00:46:31 dns7 sshd[3987]: Failed password for root from 189.17.176.130 port 36975 ssh2
#Jan 14 00:46:31 dns7 sshd[3988]: Failed password for root from 189.17.176.130 port 41299 ssh2
#Jan 14 00:46:37 dns7 sshd[3991]: Failed password for root from 189.17.176.130 port 37094 ssh2
#Jan 14 00:46:37 dns7 sshd[3992]: Failed password for root from 189.17.176.130 port 41420 ssh2
He leído que hay algunos scripts que, utilizando el iptables, banean automáticamente las ips que intentan acceder al sistema. De momento, lo que voy implementando es cambiar el puerto por el que escucha el ssh. Es una solución fácil que sólo implica recordar el puerto por el que nos debemos conectar a la máquina.
Para ver que puertos escuchan en el sistema
1 | <strong>#netstat -antuwp | egrep "(^[^t])|(^tcp.*LISTEN)"</strong> |
o
1 | <strong>#nmap -sS</strong> |
Editamos el fichero de configuración del ssh
1 | <strong>#vi /etc/ssh/sshd_config</strong> |
Output:
1 2 3 4 | #Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: |
Cambiamos el número de port, el 22 que es el por defecto, por el que nosotros consideremos. Tenemos que reiniciar el servicio y probar la conexión de nuevo al nuevo puerto y ver que efectivamente, nos podemos conectar.
1 | <strong>#/etc/init.d/sshd restart</strong> |
o
1 | <strong>#service sshd restart</strong> |
Ahora sólo falta comprobar si los intentos de acceso por ssh remiten, comprobando los logs del secure dentro de /var/log/secure. Si alguien quiere colaborar con algún consejo bienvenido sea 
I found this post from a Google search for “rhiroot”. I too have SSH logs containing attempts from “rhiroot” followed immediately by “root”. The attempts are from January 8, 2008. But the source IP is different. The IP is 196.206.200.9. The intruder is probably using TOR for anonymity. We should talk more.
Hi Samuel
i don’t believe that the attack came from the same person or same host in both cases. Im sure that one way to avoid this, not completely of course, is to change the ssh port. Most of this attacks always are trying to find the sshd listening from port 22. You`re right, we should talk more
Aquí una petita taula amb uns pocs consells sobre securització del ssh: http://enchufado.com/?p=128
I ara que hi penso, també tens altres històries (més paranoiques, això sí) com el ‘port knocking’ (que es combina amb iptables mateix).