Quelqu'un est en train d'attaquer mon serveur depuis ce mati

http://vohu.free.fr/log/sshlog.log

je fais quoi ??? :s je porte plainte ou ?? lol

Non. La personne ne fait rien de réprehensible, elle teste des mots de passe, ça n’est pas interdit, c’est juste louche. Tes serveurs fonctionnent et il n’y a pas de dommage. Laisse, surveille et relaxe toi…

ben, la, il cherche un compte utilisateur j’ai l’impression…
j’ai envie de déconnecter mon serveur… mais dans un sens, ca me gave…
je peux envoyer les logs à numéricable ?

Ben oui, et sauf si tu as un compte «melinda» pass «melinda», il ne trouvera pas.

Ouvre une bière regarde les logs défiler :mrgreen:

ça va faire beaucoup de bière ça … vohu en a t’il les moyens ?

justement, je viens de faire un script qui me met tout ca dans un fichier toutes les 15 minutes et que mon ecran de veille phosphore lit, mais y a t’il un moyen de voir en direct les lignes qui s’ajoutent au fur et a mesure…
ou sans devoir faire un “sudo cat /var/log/auth.log | grep ssh” toutes les 10 secondes…

tail -qf mais relaxe toi, dis toi bien que ça arrive tous les jours…

oui, mais la, c’est chez moi… j’ai mis ces serveur en amateur… et je ne me sens pas très sur, en ce qui concerne leur sécurité…

sudo tail -qf
tail: warning: following standard input indefinitely is ineffective

et ne donne rien :frowning:

Pas certain qu’on puisse faire une attaque force brute impunément. surtout de manière si insistante. Moi, ça me stresse ce genre de log. Alors j’ai mis en place plusieurs mesures de protection pour l’accès ssh:

Dans sshd_config:

# Authentication: LoginGraceTime 30 AllowUsers <ici la liste de tes users autorisés> PermitRootLogin no MaxAuthTries 2

TCP wrapper:
hosts.deny:

hosts.allow

sshd: LOCAL sshd: <liste des hosts et IP autorisés à accéder à sshd> sshd: fichier-des-hosts-autorisés

La dernière ligne ci-dessus inclut un fichier que tu peux modifier dynamiquement. Par un script par exemple. Pas besoin de relancer sshd après chaque changement. A chaque demande de session ssh, les fichiers hosts.deny, allow et les autres inclus seront lus.

Enfin, tu peux resserrer les règles iptables pour n’autoriser que certaines IP sur le port ssh. Ici aussi un script peut facilement modifier dynamiquement les IP autorisées.

Pour ma part, quand je suis à l’extérieur, je me logge sur une page web connue de moi seul, protégée par un mdp qui enregistre l’IP appelante dans un fichier texte sur le serveur web. Sur le serveur sur lequel je souhaite me connecter en ssh, un script en cron va lire ce fichier toutes les 5 minutes, s’il y trouve une IP, il mets à jour iptables et hosts.allow.

Un peu parano, mais je suis moins nerveux quand je lis mes log.

[quote] nmap -O -F 61.128.122.13

Starting nmap 3.81 ( insecure.org/nmap/ ) at 2008-04-28 19:43 CEST
Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
Interesting ports on 61.128.122.13:
(The 1216 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
3306/tcp open mysql
8080/tcp open http-proxy
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.7 - 2.6.8
Uptime 42.900 days (since Sun Mar 16 21:29:20 2008)

Nmap finished: 1 IP address (1 host up) scanned in 1302.223 seconds
[/quote]Le gars a un tomcat, et un proxy qui est peut être ouvert…

faut pas céder à la panique, il suffit de mettre des mots de passe qui vont bien ( minimum 8caractères mininuscules, majuscules, chiffres et caractères spéciaux mélangés) aux utilisateurs ayant accès aux services de ta machine et je t’assure qui peut toujours continuer avec le brute force et ferme les ports des serveurs quand tu ne les utilisent pas ça sert à rien qui reste en écoute.

Tu peux aussi empecher les ping et le scan de ports sur ton serveur afin de ne pas figurer sur sa liste de machines qui répondent et qui sont après victime de ce type de tentative d’attaque.

Il faut éviter de lancer les serveurs avec root aussi au cas où et biensur interdire l’utilisation du compte root pour l’accès direct à ssh comme ripat.

Personnellement je pense que si tu respecte les régles élémentaires de sécurités ce genre d’attaque ne fera rien de plus que polluer tes logs

mes mots de passe sont assez long et mélangent chiffres et lettres minuscule/majuscule…

j’essaye de fermer tous les services qui me servent pas… mais j’ai quand meme peur d’un coup…

bonjour, john est un bon outil pour vérifier la sécurité de ces mots de passe :slightly_smiling:
NAME
john - a tool to find weak passwords of your users

Bonjour

Moi aussi je me fais scanner mais au bout de deux heures il s’en va. je ne m’ inquiete pas du tout,

Vsftp chroote :laughing:

Pour la resistance des mots de passes:

lockdown.co.uk/?pg=combi&s=articles

perso le fait d’avoir changer le port d’ecoute de ssh (dans sshd) à fait disparaitre les attaques.

Il n’y a pas un outils, qui lorsque 5 (paramétrable) connexion ssh on échoué dans un temps définis l’ip est bannie pendant X heure ?

Il y a déjà la directive MaxAuthTries et MaxStartups qui peuvent ralentir l’attaquant.

[code]MaxAuthTries
Specifies the maximum number of authentication attempts permitted
per connection. Once the number of failures reaches half this
value, additional failures are logged. The default is 6.

MaxStartups
Specifies the maximum number of concurrent unauthenticated con-
nections to the sshd daemon. Additional connections will be
dropped until authentication succeeds or the LoginGraceTime
expires for a connection. The default is 10.

     Alternatively, random early drop can be enabled by specifying the
     three colon separated values ``start:rate:full'' (e.g.,
     "10:30:60").  sshd will refuse connection attempts with a proba-
     bility of ``rate/100'' (30%) if there are currently ``start''
     (10) unauthenticated connections.	The probability increases lin-
     early and all connection attempts are refused if the number of
     unauthenticated connections reaches ``full'' (60).[/code]

Sinon, fail2ban ou un petit script maison qui lis automatiquement les logs (cron) et qui bloque dans iptables l’ip trop insistante.

Titillé par le problème je viens de faire un petit script qui va extraire des auth.log les tentatives de connexion ssh non réussies, les analyser et sortir la liste des IP qui ont fait plus de x tentatives par minute. Ce fichier sera utilisé par le deamon tcpd, un “tcp wrapper” installé par défaut qui n’accordera une connexion ip qu’après avoir lu des règles se situant dans les fichiers hosts.allow et hosts.deny. Pour bloquer des IP suspectes, il suffit d’inclure dans le fichier host.deny une référence à un fichier contenant la liste des IP bannies. Par exemple, si notre liste d’IP bannies se trouve dans /tmp/ipban-ssh:

[code]# /etc/hosts.deny: list of hosts that are not allowed to access the system.

See the manual pages hosts_access(5) and hosts_options(5).

sshd: /tmp/ipban-ssh[/code]

Le script qui va analyser les log (auth.log) et extraire les IP qui ont tenté plus de x connexions par minutes:

[code]#!/bin/bash

Utilisation:

$ ipban 15

extraction des IP ayant tenté plus de 15 connexions par minute

if [ $# = 0 ]; then echo “Vous devez donner un seuil de tentatives par min.”; exit 1; fi

Paramètres et création fichier ban

LOG_FILE=’/var/log/auth.log’
DENY_FILE=’/tmp/ipban-ssh’
echo “# fichier des ip ayant tenté plus de $1 connexions ssh par minute - $(date)” > $DENY_FILE

extraction du log des tentatives ratées de connexion ssh

awk ‘/sshd.+Invalid user/ {print $1,$2,$3,$10}’ $LOG_FILE | sort -k4n | \

calcul de la fréquence de connexions par minute

et stockage des IP coupables dans le fichier $DENY_FILE

awk '
BEGIN {
i = 1
previous = “”
}
{
# boucle sur les lignes identiques (date + HH:mm + IP)
while ($1 $2 substr($3, 1, 5) $4 == previous) {
i++
ip = $4
next
}
# si seuil $1 atteint --> impression IP
if (i >= ‘$1’){
print ip
}
i = 1
previous = $1 $2 substr($3, 1, 5) $4
}

END {
if (i >= ‘$1’){
print ip
}
}’ | uniq >> $DENY_FILE

cat $DENY_FILE
exit 0[/code]

Attention, ce script est basé sur un format de log standard. Les messages de sshd peuvent également différer de ce qui donné dans le log de vohu. A vous d’adapter la ligne:

Faites tourner ce script toutes les 5 minutes par exemple (cron). Il est assez rapide: moins d’une seconde pour un fichier log de 20.000 lignes. Il peut également servir de base pour ajouter des règles iptables pour bloquer les IP suspectes, mais le bloquage hosts.deny suffit déjà à décourager les scanner de ports.

Si vous voulez vous amuser aux dépens des IP suspectes, il sera très simple d’utiliser la liste des IP bannies pour les flooder ou autres mesures vengeresses! :smiling_imp:

Si vous trouvez ça utile, je le mettrai dans Truc & Astuces.