Conectarte al SSH desde Firefox con FireSSH – SSH Desde el Navegador

Hoy de casualidad me pase por la web del autor de FireFTP el famoso cliente FTP que se integra en firefox, ya que lo necesitaba en esta PC en la que no lo había instalado, y en eso al descargarlo vi que había un anuncio que decia Mira mis nuevos proyectos, y de esta manera me encontré con FireSSH.

Usarlo es muy sencillo, podemos abrirlo al igual que FireFTP solo tenemos que dar un clic en las herramientas y listo.

Nos saldrá una ventanita igual a la de la siguiente imagen en la que podremos poner nuestros datos de conexión al SSH:

Aparte de la ventanita de conexión no les puedo decir nada mas, el cliente es como cualquier cliente SSH, sirve para conectarse y hacer lo que se tiene que hacer, yo personalmente no uso ningún cliente y mucho menos putty, ( no es malo pero no me gusta ) me conecto con el cliente ssh de Linux desde la consola y así estoy mas a gusto..

Es compatible con la versión 6 de Firefox ( en esa lo probé ) y supongo que será compatible con la 5, 4 y anteriores.

Tal vez algo que no me a gustado de FireSSH es que se abre en una ventana nueva y no como su primo FireFTP que se abre en una pestaña, al menos no me gusta mucho así pero tampoco me quejo ya que no lo voy a usar muy seguido o al menos no tanto como el FireFTP, aunque uno nunca sabe tal vez en futuras versiones el autor haga que este se habrá en una pestaña.

Por mi parte es todo, pueden descargarlo de mozdev.org o bien desde la página de add ons de FireFox en este enlace

Esto fue todo sobre:

Cliente Para Conectarse al SSH Desde el Navegador Firefox

Otra vez me estan atacando… [Detener Ataque de fuerza Bruta ssh Linux Debian] [ Configurar IPtables y Puerto 22 ]

Hoy que me da por revisar y veo que aun me siguen atacando al ssh en el puerto 22, reviso el auth.log de mi debian y no vean la lista que tengo de logs fallidos, la ultima vez, al parecer se me olvido instalar el fail2ban, tengo una lista interminable, les dejo una parte, del dia 11 que estaban dando duro y el dia de hoy que al parecer vuelven al ataque.

Ahora bien por que atacan los chinos a las computadoras con linux y en algunos casos windows ? y por que al puerto ssh ?

Esto solo lo sabran ellos, aunque una de las principales razónes es entrar en un pc con linux por el puerto mas fácil de atacar o el puerto abierto mas comun en todas las computadoras, los logs son interminables, tal vez lo hacen para crear enormes botnets para luego atacar a servidores mas grandes, o no solo eso todo una pais, como lo hicieron hace algunos años con racsa en Costa Rica miles de pcs infectados provenientes del oriente casi tumbaron a la compania que provee internet en Costa Rica, haciendo mas lento el servicio por varias horas.

Esa puede ser una razón por la cual atacan, otra cosa es si seran orientales o simplemente usaran un proxy 😉

Aquí les dejo como prevenir un ataque y/o detenerlo por completo.

Sep 11 14:59:49 debian sshd[4012]: Failed password for invalid user costos1 from 190.11.14.82 port 33779 ssh2
Sep 11 14:59:50 debian sshd[4014]: Invalid user costos2 from 190.11.14.82
Sep 11 14:59:50 debian sshd[4014]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 14:59:50 debian sshd[4014]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=proxy.inamhi.gov.ec
Sep 11 14:59:52 debian sshd[4014]: Failed password for invalid user costos2 from 190.11.14.82 port 33829 ssh2
Sep 11 14:59:53 debian sshd[4016]: Invalid user calidad from 190.11.14.82
Sep 11 14:59:53 debian sshd[4016]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 14:59:53 debian sshd[4016]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=proxy.inamhi.gov.ec
Sep 11 14:59:55 debian sshd[4016]: Failed password for invalid user calidad from 190.11.14.82 port 50011 ssh2
Sep 11 14:59:57 debian sshd[4018]: Invalid user portatil from 190.11.14.82
Sep 11 14:59:57 debian sshd[4018]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 14:59:57 debian sshd[4018]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=proxy.inamhi.gov.ec
Sep 11 14:59:59 debian sshd[4018]: Failed password for invalid user portatil from 190.11.14.82 port 50081 ssh2
Sep 11 15:00:00 debian sshd[4020]: Invalid user aodria from 190.11.14.82
Sep 11 15:00:00 debian sshd[4020]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 15:00:00 debian sshd[4020]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=proxy.inamhi.gov.ec
Sep 11 15:00:02 debian sshd[4020]: Failed password for invalid user aodria from 190.11.14.82 port 50135 ssh2
Sep 11 15:00:04 debian sshd[4022]: Invalid user jmeza from 190.11.14.82
Sep 11 15:00:04 debian sshd[4022]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 15:00:04 debian sshd[4022]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=proxy.inamhi.gov.ec
Sep 11 15:00:06 debian sshd[4022]: Failed password for invalid user jmeza from 190.11.14.82 port 50341 ssh2
Sep 11 15:00:07 debian sshd[4024]: Invalid user htejada from 190.11.14.82
Sep 11 15:00:07 debian sshd[4024]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 15:00:07 debian sshd[4024]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=proxy.inamhi.gov.ec
Sep 11 15:00:09 debian sshd[4024]: Failed password for invalid user htejada from 190.11.14.82 port 50398 ssh2
Sep 11 15:00:10 debian sshd[4026]: Invalid user mlparedes from 190.11.14.82
Sep 11 15:00:10 debian sshd[4026]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 15:00:10 debian sshd[4026]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=proxy.inamhi.gov.ec
Sep 11 15:00:13 debian sshd[4026]: Failed password for invalid user mlparedes from 190.11.14.82 port 50462 ssh2
Sep 11 15:00:14 debian sshd[4028]: Invalid user mnieto from 190.11.14.82
Sep 11 15:00:14 debian sshd[4028]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 15:00:14 debian sshd[4028]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=proxy.inamhi.gov.ec
Sep 11 15:00:16 debian sshd[4028]: Failed password for invalid user mnieto from 190.11.14.82 port 50627 ssh2
Sep 11 15:00:18 debian sshd[4032]: Invalid user mrojas from 190.11.14.82
Sep 11 15:00:18 debian sshd[4032]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 15:00:18 debian sshd[4032]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=proxy.inamhi.gov.ec
Sep 11 15:00:20 debian sshd[4032]: Failed password for invalid user mrojas from 190.11.14.82 port 50665 ssh2
Sep 11 15:00:21 debian sshd[4034]: Invalid user jesilva from 190.11.14.82
Sep 11 15:00:21 debian sshd[4034]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 15:00:21 debian sshd[4034]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=proxy.inamhi.gov.ec
Sep 11 15:00:24 debian sshd[4034]: Failed password for invalid user jesilva from 190.11.14.82 port 50712 ssh2
Sep 11 15:00:25 debian sshd[4036]: Invalid user gtorres from 190.11.14.82
Sep 11 15:00:25 debian sshd[4036]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 15:00:25 debian sshd[4036]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=proxy.inamhi.gov.ec
Sep 11 15:00:25 debian gdm[2339]: pam_unix(gdm:session): session closed for user maks
Sep 11 15:00:25 debian gnome-keyring-daemon[2363]: failed to shutdown HAL context: (null)
Sep 11 15:00:27 debian sshd[4036]: Failed password for invalid user gtorres from 190.11.14.82 port 50743 ssh2
Sep 11 15:00:28 debian sshd[4082]: Invalid user ezevallos from 190.11.14.82
Sep 11 15:00:28 debian sshd[4082]: pam_unix(sshd:auth): check pass; user unknown
Sep 11 15:00:28 debian sshd[4082]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=proxy.inamhi.gov.ec
Sep 17 11:47:24 debian sshd[2065]: Server listening on :: port 22.
Sep 17 11:47:24 debian sshd[2065]: Server listening on 0.0.0.0 port 22.
Sep 17 11:47:25 debian sshd[2065]: Received signal 15; terminating.
Sep 17 11:47:25 debian sshd[2185]: Server listening on :: port 22.
Sep 17 11:47:25 debian sshd[2185]: Server listening on 0.0.0.0 port 22.

Bueno la cosa es como solucionar esto ? Y se puede por medio de fail2ban que explico aquí como instalarlo

Y con eso banea la ip que tenga logs fallidos, claro esta el número de intentos que ustedes configuren en el /ect/fail2ban/jail.conf

Aunque claro se cambia la ip y se sigue atacando pero igual sera baneada.. A mi este método del fail2ban siempre me a gustado, Ya que también puedo ver a los que e baneneado en /var/log/fail2ban.log

El problema de esto es que alguna que otra vez fail2ban se cae o no inicia, aunque pocas veces pasa esto, así que de vez en cuando hay que estar checando esto en el mismo fail2ban.log te dice si a caído, si a iniciado o si tiene errores, y esas cosas, también se puede configurar para que te mande un mail en caso de que el demonio de fail2ban pare o se cuelgue.

Pero bueno yo como no quiero que nadie se conecte al ssh y no quiero estar checando el auth.log, ni el fail2ban.log por que no tengo tiempo para eso..

Pero tampoco quiero desinstalar fail2ban por que algunas veces lo uso para cubrir otros puertos. así que la solución es usar iptables también para bloquear estos ataques, la casa es muy fácil de hacer solo basta agregar una linea a las reglas del iptables, o pegar esto en consola para que se agregue la linea.

/sbin/iptables -A INPUT -p tcp –dport 22 -j DROP

Esa regla lo que hace es rechazar todas las peticiones que vallan alpuerto 22 así que nadie se podrá conectar al ssh que es el que corre en ese puerto.

Y ya que estamos en eso, si alguien quiere bloquear todo lo que venga al puerto 22 excepto una u dos ips que esten en su red o que les interese dejar conectarse a tu servidor o pc, pueden dejar pasar el trafico de esas ips agregando esta otra regla al iptables

/sbin/iptables -A INPUT -s 95.xx.xx.x/24 -p tcp –dport 22 -j ACCEPT

OJO recuerden que primero an de agregar la regla que permite pasar el trafico y luego la que bloquea, quedaria así

sbin/iptables -A INPUT -s 95.xx.xx.x/24 -p tcp –dport 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp –dport 22 -j DROP

Y otra forma de hacer si no quieren usar el fail2ban y tampoco quieren bloquear el acceso al iptables por completo ya que tienen ip dinámica de donde se conectan, es hacer lo que hace el fail2ban osea bloquear después de cierto numero de intentos pero esta vez hacerlo con iptables

Que quedaria así la regla.

/sbin/iptables -I INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –set
/sbin/iptables -I INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –update –seconds 600 –hitcount 4 -j DROP

Y eso es todo puerto 22 asegurado, tal vez no evitamos los ataques pero si podemos evitar que los ataques tengan éxito.

Nos vemos