Barrapunto

YO USO UNA KONTRASENYA KE NO ES UNA POR DEFEKTO Y KE ES MUY LARGA Y CON MUCHOS KARAKTERES RAROS. AUNKE NO USO MINUSCULAS.

...capa en el router todas las demás IPs menos las que te interese permitir.

De todas formas, ¿qué problema hay con que la gente intente entrar por SSH? Para eso están las contraseñas... No veo el problema, simplemete mantente protegido contra todas las posibles vulnerabilidades, y punto pelota...

Supongo que habrá medidas mucho más elaboradas y eficaces pero para protegerse de ataques automatizados de ese tipo lo primero que se podría hacer es cambiar de puerto el ssh del 22 a otro del que te acuerdes fácilmente. Y por supuesto añadir un "PermitRootLogin no" a tu sshd_config

... esto ya tiene un tiempecito... Muppet SSH brute-forcer [mongers.org], aunque no sé de donde saca la relación P2P/ataque a ssh y el "grupo organizado" será una botnet [wikipedia.org].

¿Qué usáis para protegeros?

1. No tener abierto el puerto 22, sino otro.
2. Permitir que sólo algunos usuarios puedan iniciar sesión ssh.
3. No usar como nombre de usuario en el aMule ningún nombre de usuario del sistema.
4. No tener puesto el ssh si no es necesario (cuando estoy en casa, lo primero es matar al demonio sshd).

-

Esto ya se ha comentado muchas veces, pero parece que no termina de calar. La mejor manera de protegerse de estos ataques es desactivar el acceso con contraseña, y permitir únicamente el acceso por medio de clave pública/privada con su frase de paso.

En el servidor instalas la clave pública, y la privada (yo en mi caso la llevo en el llavero, en un pendrive, con una buena frase de paso). Al haber desactivado el acceso con contraseña, el atacante al no tener la clave privada, no tiene ni si quiera la oportunidad de intentar introducir una contraseña.

Otras cosas que se pueden hacer es mover de puerto el servicio, por ejemplo. Y por supuesto ajustar la configuración de tu servidor para permitir únicamente el protocolo SSHv2.

Existen varias circustancias que suelen desencadenar ataques al conectar a redes p2p, el porno infantil y las cuestiones relacionadas con terrorismo. Actualmente existen redes de bots y ordenadores zombies las cuales intentaran hurgar en le ordenador que comience a descargar lo que "ellos" (los padres de la red de bots) consideren inapropiado.

Aunque esto pueda parecer un mal menor, ya que algunos consideraran que solo persiguen a los malos, se estan empezando a dar casos en los que el ataque sobreviene al descargar contenidos protegidos por copyright.

Asi que ya sabes, segun lo que intentes bajar, un monton de peña a tu puerta vendra a llamar...

Con un NAT puedes tener varios PCs conectados a la misma conexión de Internet. Además solo los puertos que abres especificamente en el NAT son de entrada. El resto de entradas el NAT las descarta.
De esta manera no hay ningún problema y hasta el Windows que tengo está protegido. En una ocasión puse una IP por defecto en el NAT, la de mi PC con Windows. ¡Craso error! Al hacer una reinstalación se contaminó con un gusano nada más acabar. Nunca hay que poner una IP de recepción por defecto.

El NAT actua de firewall y además tengo varios PCs conectados. :)

En septiembre del año pasado sufri los mismos ataques y me pico la curiosidad. Por lo que descubri googleando un poco era un gusano que iba probando logins y pass tipicos (root/root, user/user y cosas asi) y si entraba en una maquina se instalaba y atacaba desde ahi.
No tiene nada que ver con un grupo organizado, sino con ordenadores con malas instalaciones por defecto y gente que no las controla lo suficiente

En la UCM no hay máquinas corriendo programas P2P porque los de servicios informáticos tienen todo el tráfico P2P capado. Sin embargo, TODAS las IPs de la UCM reciben este tipo de ataques (al menos las que administramos).

Llevamos detectando estos ataques desde hace casi un año, ninguna de las máquinas que administramos tiene ningún tipo de software P2P ni nada por el estilo instalado. Tiene pinta de ser un simple escaneo masivo.

La mejor manera de protegerse contra ataques es no ser standard.
Si el puerto por defecto del ssh es el 22, usa el 2222 por ejemplo.

Una pregunta un tanto tonta… ya que soy desarrollador y no se mucho de soporte. SHH es solo para Linux? .. Alguna vez usé telnet…

MSN Virtual Earth [neuronaltraining.net]

Yo tengo filtradas todas las IPs que conectan. Sólo permito conexiones desde la red en la que estoy, así me quito de encima de un plumazo al resto del mundo mundial. Incluídos los koreanos, que por lo menos a mí son los que más me han incordiado.

Y luego, por supuesto, tengo deshabilitadas las contraseñas. Utilizo llaves criptográficas para las conexiones.

Actualmente uso: clave pública (pero tambien admito ocntraseña por si estoy en otro PC en otro lado). No permito entrar al root tampoco.

De todos modos ver esos ataques mosquea bastante. La relación entre el P2P y los ataques me la comentó un compañero, la cual puede ser cierta, si te conectas a alguien que busque ips ¿Que mejor que investigar a los que se conectan a ti para bajarse cualquier cosa?

Por cierto ni soy terrorista ni pedófilo. (lo comento por curiosidad y tal... para que no me vengan los geos a casa).

A lo que voy, es lo suficientemente seguro esto?. Y si intentan un DDOS? (ya se que soy paranoico).

Con NAT un poquillo chungo, pero hay por ahí implementaciones muy chulas de Port-knocking. Incluso algunas utilizan contraseñas dinámicas.

No tengo puerto 22 abierto.
Refinitivo.

Port-knocking [faq-mac.com] es una solución bastante interesante. No lo he probado todavía porque no dejo ningún servicio abierto, además estoy detrás de un router. Ahora mismo en los logs del susodicho tengo como 50 ICMP redirect, algún ataque LAND y Smurf. Son un poquito pesados pero el router y un Linux te permiten tenerlo todo semi-controlado. No lo digo muy alto por si acoso y derribo.

Cuanto más conozco a las mujeres, más quiero a mi perro.

De tu lista de atacantes elegí una cualquiera y con la herramienta de turno me da esta identidad para esa IP: Search results for: 66.132.143.172 OrgName: Interland OrgID: INTD Address: 101 Marietta Street City: Atlanta StateProv: GA PostalCode: 30039 Country: US NetRange: 66.132.128.0 - 66.132.255.255 CIDR: 66.132.128.0/17 NetName: DIALTONEINTERNET-4 NetHandle: NET-66-132-128-0-1 Parent: NET-66-0-0-0-0 NetType: Direct Allocation NameServer: NS.DIALTONEINTERNET.NET NameServer: NS2.DIALTONEINTERNET.NET Comment: RegDate: 2003-08-08 Updated: 2004-06-07 OrgAbuseHandle: ABUSE579-ARIN OrgAbuseName: ABUSE OrgAbusePhone: +1-404-260-8434 OrgAbuseEmail: abuse@interland.com OrgTechHandle: ASNAD3-ARIN OrgTechName: ASNADMIN OrgTechPhone: +1-404-260-8434 OrgTechEmail: asnadmin@interland.com ------------------------------------- Creo que no sirve de nada pero a mi me parece interesante 'identificar' a toda esa tropa.

También he notado esos ataques últimamente... Sobre algunos de los comentarios que he estado leyendo, algunas puntualizaciones: 1) Que el servidor ssh sea accesible por otro puerto que no sea el estandar lo único que evita es este tipo concreto de ataques (brute-force script, que creo yo que es). Un atacante "serio" descrubrirá el puerto del servidor en cuestión de minutos (un simple nmap -P0 es suficiente). 2) Limitar el número de usuarios/grupos a los que se permite conectar es buena idea (por supuesto, deshabilita el acceso a root). 3) También es buena idea el configurar el acceso con clave pública/privada, y deshabilitar el acceso con contraseña. Además de todo esto, hay una herramienta llamada "fail2ban" (http://fail2ban.sourceforge.net/) que puede banear ips que hagan demasiados intentos fallidos de conexión. La tengo instalada una semana y funciona de maravilla.... Por ejemplo, puedes configurarla para que banee durante 20 minutos a una ip desde la que se ha fallado 3 veces en el login/password.

Vosotros prohibirles el acceso. ¡Qué vengan a mí! Así me lo paso guay mirando los log de mi Honeypot :)

Mira que quejaros... ¡Con lo divertido que es!

En iptables hay opciones para decir cuantos peticiones aceptamos por unidad de tiempo, para un determinado puerto e ip de origen. Con esto, ante un ataque por dicionario, el atacante se vera bloqueado cada x intentos de conexion tcp puerto 22. Por ejemplo, cada 3 conexiones desde la misma ip en un minuto, lo bloqueamos durante 1 hora. Esto es posible con iptables ( el firewall del kernel). Esto hace que un posible ataque por diccionario sea mas lento en obtener resultado, o necesite el atacante distribuir el ataque. Quiero decir que no es la panacea, pero es como todos los candados que les ponemos a las motos, cuantos mas pongas mas pesado les haces el trababajo al ladrón. Salu2

Si pishing es el acto de hacer pis, ¿ssh qué es? ¿Mandar callar?

¿A que soy chiposo?

Yo uso ésto [aczoom.com] en los servidores del kurro y va bastante bien :)

Yo también tuve una oleada de ataques por ssh, lo descubrí casi por casualidad y supuse que tal vez sería la principal causa por la que el servidor de vez en cuando no podía con las pelotas XD, de manera que corté el ssh al interfaz externo al darme cuenta que rara vez accedía desde el exterior. Es una manera de cortarlo por lo sano XD, supongo que otra solución sería en permitir tan sólo 3 intentos fallidos de acceso por ip por cada 24 horas.

Despues de leer la noticia he echado un vistazo a los logs (en los ordenadores de casa suelo pasar de hacerlo), y efectivamente hay un huevo de intentos, aunque solo de unas pocas ip's:

grep illegal /var/log/sshd/* | gawk '{print $12}' | sort -n | uniq
24.39.103.80
195.31.203.164
202.5.145.22
220.130.153.124
220.65.52.101

Asi que lo que voy a hacer cuando tenga tiempo es montar un honeypot [umich.edu] y currarme algun script que permita login y haga chroot a algun sitio con archivos multimedia o algo por el estilo, para ver si es verdad lo de los espias, etc.

Si alguien pica, y el hilo sigue activo ya cometare que tal.

Por cierto, para protegerse, aparte de desactivar PermitRootLogin, viene bien echar un vistazo a MaxStartups y LoginGraceTime. Mas info en man sshd_config.

Lo de la oleada de ataques realmente no es nada nuevo. De hecho, junto con los envíos masivos de SPAM, se vienen registrando ya hace tiempo, desde la zona de la APNIC, multiples intentos de login en varios de los servicios habituales aparte del SSH, como el FTP y el SFTP. Mis logs estan llenitos de ellos.

Aparte de las normas básicas que se han dicho antes (generar contraseñas inteligentes, cambio de puertos, cerrar servicios no usados, iptables, etc...) se puede probar de usar tcpwrappers (para aquellos servicios que lo soporten). Tras una entretenida lectura de los logs, puedes actualizar tcpwrappers o iptables con un montón de IPs nuevas. Tras varios meses, verás que tienes que cerrarte en banda a rangos enteros, pero es que no hay alternativa.

Otra alternativa que se puede probar es forzar el uso de variantes SSL de todos los servicios que se ofrezcan al publico. Algunos de estos grandes bots rastreadores no tienen soporte para hacer frente a servicios solo prestados bajo conexión segura, con lo cual tienen la batall perdida nada más empezar. Y no deja de ser un beneficio, respecto a la privacidad, para sus usuarios.

Finalmente, y en concreto para el SSH, puedes probar de colocar en sshd_config la opción "PermitRootLogin without-password", lo cual deshabilita la identificación interactiva mediante teclado para el superusuario, pero le permite los demas sistemas, como clave pública y PAM. Un saludo

No se si son las que aparecen el los links de tu página porque el servidor al que apuntan está inaccesible pero hace tiempo me plantee lo mismo y encontre estas soluciones: timelox [ethernet.org] y SSH Blocker [usebox.net]

La semana pasada sufri un ataque por descuido en la seguridad de mi server, he publicado la cronica de como llevo el ataque el hacker en Cronica de un ataque ssh [canarysystem.com] en cuanto a las herramientas a utilizar en esta dirección les indico dos que he encontrado y son muy eficientes Herramientas Herramientas [canarysystem.com] Espero que les sirva de algo ...

Demasiada paranoia o flipada h4x0r es lo que tienes chaval... ya puedes mirar el log del apache o del resto de servicios que tengas pa que veas lo que se mueve por el vasto oceano de la Red... no seas tan flipao dandotelas de super admin super secure y aprende un poco ignorante.

Vengo viendo ataques de estos desde hace como un año y el rastrear la IP no sirve de mucho, generalmente son direcciones fake, o sea que se ponen direcciones que no les pertenecen. Como trabajo bajo subcontrato para algunas empresas montándoles servidores, generalmente los entrego con claves extremadamente simples con la advertencia que ellos las cambien inmediatamente y que yo no la sepa, bueno hubieron algunos que no las cambiaron y estos servidores cayeron con el ataque, lo que me permitió rastrear el asunto: Primero adivinan la clave de root con fuerza bruta y un diccionario, me dí cuenta que era un programa porque en los logs aparecía hasta dos intentos por segundo. Generalmente quienes conducen estos ataque son script kiddies, porque una vez irrumpieron ni siquiera fueron capaces de borrar las huellas, pude ver incluso el .bash_history para darme cuenta que instalan un root kit en /tmp, el cual lo decargan de un sitio de warez, este rootkit comienza a explorar más equipos que tengan el puerto ssh abierto y les genera una lista de direcciones, y así apuntan el ataque a otros equipos. La mejor manera de frenar estos ataques es poniendo un máximo de reintentos y una clave fuerte. Saludos.

he mirado mis logs y están hasta la bola. alguien conoce un buen analizador de logs para revisar si tengo algún acceso indebido, son un montos de ficheros enormes.

Existen algunos scripts para controlar e informar de los accesos "raros" al sshd.
Uno de estos es tattle [sodaphish.com], cuya función es informar a los proveedores de esas ips de los ataques hechos por sus usuarios de forma automática
Para debian hay que cambiar el modo de registro del log para que funcione, en modo INFO no funciona (por ahora).
Este tipo de ataques a SSH se han vuelto muy comunes estos últimos meses y, sin lugar a dudas, no tiene nada que ver con el uso o no de P2P. Ya se comentaba en Slashdot hace unas semanas (no tengo la url a mano)

Con estos dos me va perfecto APF [webhostgear.com] BFD [webhostgear.com] Y me llega un lindo reporte al mail cada ves que bloquea alguna ip junto con su log respectivo

y a tomar por saco, hace tiempo me encontre , contandolas unas 7000 entradas en el auth.log, intentando con una pechá enorme de nombres de usuario, pero como he aprendido bien de los buenos ya tenia echo lo de allowusers y algunas cosas mas.

Para el que le interese: como veo util mi script (y quien no ve útiles sus propios scripts, xD) porque se puede poner en medio de un firewall ya configurado (tal como lo tengo yo y en los otros no se puede o es demasiado complicado), he publicado una nueva version y le he llamado banfromlog [serhost.com] .

Ahora tiene compatibilidad con sqlite (gracias a que un lector de aqui la implementó). Espero que le sea útil a alguien, tengo pensado mejorarlo bastante y personalizar tiempo de baneo, si reincide, etc.