{"partition": "head_middle", "source_domain": "linuxfr.org", "digest": "sha1:E45EYTO5GF2Z65QNB4O2DBIXGEKPD6YX", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00020.parquet"}
Journal une petite attaque
Posté par dark_star le 03/06/05 à 17:21.
3juin2005
bonjour ci joint un petit log de /var/log/secure concernantt ssh (long). depuis le 29 mai de plus en plus de personne essaye de se connecter par ssh, c'est un peu long et j'ai un peu epuré le log pour pouvoir le poster.
bon maintenant vu que de plus en plus de monde essaye de venir sur ma machine :( je soupconne l'ordinateur de ma maman compromis. Du boulot en perspective avec mon amis rpm et gpg. adieu sshd aussi. Tiens sinon je me croyais un peu au dessus de tous cela. Est ce vraiment utile d'envoyé des mail au FAI concerné?
[root@localhost log]# cat secure | grep sshd | grep Failed
May 29 12:12:17 [2969]: Failed password for nobody from X.X.X.X port 18828
May 29 12:12:24 [2971]: Failed password for illegal user patrick from X.X.X.X port 18891
May 29 12:12:37 [2975]: Failed password for root from X.X.X.X port 19040
May 29 12:12:43 [2977]: Failed password for root from X.X.X.X port 19113 May 29 12:12:50 [2980]: Failed password for root from X.X.X.X port 19185
May 29 12:13:04 [2984]: Failed password for root from X.X.X.X port 19323 May 29 12:13:11 [2986]: Failed password for illegal user rolo from X.X.X.X port 19411 May 29 12:13:18 [2988]: Failed password for illegal user iceuser from X.X.X.X port 19487
May 29 12:13:25 [2990]: Failed password for illegal user horde from X.X.X.X port 19562 May 29 12:13:32 [2993]: Failed password for illegal user cyrus from X.X.X.X port 19629
May 29 12:13:39 [2995]: Failed password for illegal user www from X.X.X.X port 19710 May 29 12:13:45 [2997]: Failed password for illegal user wwwrun from X.X.X.X port 19786
May 29 12:13:51 [2999]: Failed password for illegal user matt from X.X.X.X port 19861 May 29 12:13:58 [3001]: Failed password for illegal user test from X.X.X.X port 19932 May 29 12:14:04 [3003]: Failed password for illegal user test from X.X.X.X port 20001 May 29 12:14:12 [3005]: Failed password for illegal user test from X.X.X.X port 20065
May 29 12:14:18 [3008]: Failed password for illegal user test from X.X.X.X port 20153 May 29 12:14:25 [3010]: Failed password for illegal user www-data from X.X.X.X port 20225 May 29 12:14:31 [3012]: Failed password for illegal user mysql from X.X.X.X port 20304 May 29 12:14:37 [3014]: Failed password for operator from X.X.X.X port 20378
May 29 12:14:44 [3016]: Failed password for adm from X.X.X.X port 20446 May 29 12:14:50 [3018]: Failed password for apache from X.X.X.X port 20527 May 29 12:14:57 [3020]: Failed password for illegal user irc from X.X.X.X port 20599 May 29 12:15:04 [3023]: Failed password for illegal user irc from X.X.X.X port 20675
May 29 12:15:11 [3025]: Failed password for adm from X.X.X.X port 20746 May 29 12:15:18 [3029]: Failed password for root from X.X.X.X port 20817 May 29 12:15:25 [3031]: Failed password for root from X.X.X.X port 20889 May 29 12:15:32 [3033]: Failed password for root from X.X.X.X port 20960
May 29 12:15:39 [3035]: Failed password for illegal user jane from X.X.X.X port 21029
May 29 12:15:46 [3037]: Failed password for illegal user pamela from X.X.X.X port 21112
May 29 12:16:25 [3050]: Failed password for illegal user cosmin from X.X.X.X port 25003
May 29 12:20:25 [3128]: Failed password for root from X.X.X.X port 48291 May 29 12:20:32 [3130]: Failed password for illegal user cip52 from X.X.X.X port 48959
May 29 12:20:38 [3132]: Failed password for illegal user cip51 from X.X.X.X port 49532 May 29 12:20:44 [3134]: Failed password for root from X.X.X.X port 50141
May 29 12:20:51 [3136]: Failed password for illegal user noc from X.X.X.X port 50654 May 29 12:20:57 [3138]: Failed password for root from X.X.X.X port 51289
May 29 12:21:19 [3145]: Failed password for root from X.X.X.X port 53213 May 29 12:21:25 [3147]: Failed password for illegal user webmaster from X.X.X.X port 53836
May 29 12:21:32 [3149]: Failed password for illegal user data from X.X.X.X port 54487 May 29 12:21:39 [3151]: Failed password for illegal user user from X.X.X.X port 55109
May 29 12:21:46 [3153]: Failed password for illegal user user from X.X.X.X port 55710 May 29 12:21:53 [3155]: Failed password for illegal user user from X.X.X.X port 56375
May 29 12:22:02 [3158]: Failed password for illegal user web from X.X.X.X port 56989 May 29 12:22:12 [3160]: Failed password for illegal user web from X.X.X.X port 57776
Jun 2 10:00:31 [3833]: Failed password for illegal user sun0s from XXXXX port 53981
Jun 2 10:00:41 [3835]: Failed password for illegal user reboot from XXXXX port 54745
Machine infectée
Posté par Sébastien Koechlin le 03/06/05 à 17:30.
C'est rien, c'est normal, tous les serveurs ssh ont cela
- Ca passe par une machine infectée, il est difficile de remonter à la source, le FAI ne peut pas grand chose.
- Les logins sont toujours les mêmes, si root n'a pas le droit de se connecter et si ton user ne s'appelle pas adm, user, web, data ou quelques autres nom de programme, ça ne teste même pas la sécurité de ton mot de passe (qui n'est pas attaquable au dictionnaire de toute façon parce que tu l'as convenablement choisi).
- Ca ne diminue pas la sécurité de sshd
Re: Machine infectée
Posté par chtitux (page perso) le 03/06/05 à 18:57.
Je suis surpris qu'on puisse échouer à tant de logins ...
Sshd ne bloque pas l'IP après un nombre x d'essais qui ont échoués ?
C'est la porte ouvert à des attauqes par dictionnaires sinon ...
Mais j'espère me tromper, si il ne le fait pas par deefaut, une option doit bien exister ...
Posté par adibou le 03/06/05 à 21:46.
si sshd peut le faire ou non ne change rien au fait qu'on peut limiter le nb de requetes a n par minutes : dans le cas d'un serveur sur un pc pour peu d'utilisateur, qq chose comme 3/min suffit largement, et une attaque par dico risque d'etre bien longue...
Posté par Raoul Volfoni (page perso) le 03/06/05 à 23:45.
Évalué à 10
> Sshd ne bloque pas l'IP après un nombre x d'essais qui ont échoués ?
Et comme ça avec une IP spoofée tu peux te chopper un magnifique DOS. Si l'attaquant sait quelle est ton IP, tu ne pourras même plus te connecter à ton serveur! AMHA c'est une stratégie dangeureuse si implémentée sans précaution.
Il y a plusieurs solutions pour résoudre le petit désagrément des vilains bots:
- changer le port d'écoute de sshd (les bots pour ssh n'attaquent que le 22 la +part du temps)
- n'autoriser que les connections avec des clés valides (authorized_keys) depuis des machines connues (known_hosts)
- utiliser des mots de passes jetables (skey ou OPIE) très utile quand on se connecte depuis une machine que l'on ne connait pas (évidemment incompatible avec le known_hosts)
- désactiver la connection par mot de passe: PasswordAuthentication no
- comme indiqué + bas, utiliser Portknocking: http://www.portknocking.org/(...)
- enfin en dernier recours faire un script pour iptables qui bloque l'IP pendant un temps bien déterminé de façon à éviter le DOS. Mais je ne suis pas trop pour. :(
Sinon quelques conseils de bon sens:
- avoir évidemment des mots de passe à toute épreuve (y compris celle des Rainbow Tables C.f. http://passcracking.com/(...) Donc au minimum 20 caractères avec tous ceux que l'on utilise habituellement que pour les jurons. ;)
- éventuellement bloquer la connection à root sauf si on utilise des mots de passe jetables pour administrer la machine depuis une autre machine sans confiance. Auquel cas un su ou sudo mettrait toute la sécurité par terre si la machine est infectée par un logger.
- s'il s'agit d'une machine passerelle et que l'on a pas besoin de s'y connecter depuis un des réseaux, ne mettre sshd qu'en écoute sur l'autre adresse.
- vérifier les options de son sshd_config et surtout MaxAuthTries, PermitEmptyPasswords, UsePAM (dans ce cas voir aussi la config de PAM) et ne pas oublier de bloquer SSH1: Protocol 2
- et enfin si on est vraiment parano, utiliser Kerberos.
Finalement mettre un message d'interdiction des connections non authorisées dans /etc/ssh/banner. Les bots s'en foutent, mais si quelqu'un réussit à percer toutes les barrières précédentes, il ne pourra pas prétendre qu'il n'a pas vu l'interdiction d'entrer (pour le forensic).
Posté par DjinnS (page perso) le 03/06/05 à 17:31.
C'est en général des bots/prog/virus/vers ou tout ces saloperies qui soit sont lancées volontairement par des personnes n'ayant pas beaucoup de connaissances ... soit par des PCs infectés.
Je pense pas que t'es trop de bille à te faire. Un petit RootLogin No dans ssh et surtout un AllowGroups et AllowUsers bien placé te mettra à l'abrit de ce genre de choses ... tout en ayant un password digne de ce nom, évidement.
Ca na ne te protegera par contre les failles de SSH mais c'est un bon début !
Posté par seeschloss le 03/06/05 à 17:35.
C'est juste des trucs automatiques, moi aussi j'ai ça assez souvent...
Le dernier : Jun 3 00:07:17 [sshd] Failed password for invalid user jacob from 188.8.131.52 port 45005 ssh2)
Mais qui peut avoir un login qui s'appelle "jacob" ?!
Hier, 188.8.131.52 a aussi essayé toutes les lettres individuellement, plus eee, qqq, www, ppp, kkk, ttt, mmm et abc, j'ai aussi eu une centaine d'essais de login en root par 188.8.131.52 et divers admin, guest, mysql, etc.
Enfin bon, en désactivant le root login, l'autentification par mot de passe et avec un nom d'utilisateur pas trop facile à trouver automatiquement, il y a pas trop de risques... j'aimerais bien que sshd me montre les mots de passe qu'ils essayent, par contre :)
Re: Bof
Posté par redfish le 03/06/05 à 17:45.
quelqu'un qui s'appelle Jacob, non ?
Posté par lampapiertramol (page perso) le 03/06/05 à 23:16.
Tu te contentes de déplacer la question là. Qui peut bien appeler son enfant jacob ?
Posté par Fil Ipo (page perso) le 03/06/05 à 23:59.
Et qui peut appeler sont enfant lampapiertramol ???
Posté par jcs (page perso) le 04/06/05 à 09:42.
C'est parti, pagesblanches.fr, nom : Jacob, localité : Paris
> Il y a 322 réponses en orthographe exacte
> ce qui est supérieur au seuil autorisé de 100 réponses.
> Vous pouvez préciser la recherche
> (prénom, adresse, arrondissement, numéro de rue...)
> ou afficher les réponses concernant seulement les professionnels
Voilà 322 Monsieur ou Madame Jacob dans l'annuaire à Paris, 1084 en Ile de France.
Et son nom de famille on ne le choisit pas :-) (enfin pas complètement)
Posté par fabien le 03/06/05 à 21:13.
j'aimerais bien que sshd me montre les mots de passe qu'ils essayent, par contre :)
non, ca me semble etre une mesure de securité de base.
si tu vois dans tes logs les erreurs de tes utilisateurs tu pourrait facilement en deduire leur mot de passe (par exemple le cas d'un mot de passe suivant : "cattherine", je vous laisse deviner le bon)
or, justement, l'administrateur ne dois pas connaitre les mots de passe des utilisateurs, il peut les changer, mais pas les connaitre.
Posté par ckyl le 03/06/05 à 23:05.
Heu comment dire. L'administrateur en général il est root. Alors l'administrateur s'il veut avoir les mots de passe il les aura même si ca demande de recompiler et faire un printf au bon endroit.
De deux chose l'une. Soit le mot de passe ne se retrouve pas en clair sur la machine administrée et il ne l'aura jamais soit il l'(a|aura). Ce que tu expliques c'est de la sécurité par l'obscurité, on affiche pas par défaut une information que l'on pourrait. Mauvaise réponse ! La mesure de sécurité c'est que généralement on met en place des logs distant et que les logs se baladent en clair dans des jolies trames UDP et que c'est pas top top. M'enfin bon syslog est tellement pourri qu'on est plus à ca près :-)
Si tu n'as pas confiance dans ton root ne te connecte pas à ses machines en tout cas pas à ses machines UNIX. Exercice: Comment, sauf clé ssh, l'administrateur peut-il n'avoir aucun moyen de récuperer le mot de passe ? Sachant que pour cela il faudra utiliser (y)passwd pour le changer...
je suis d'accord, je sais bien l'aplication sshd recoit le mot de passe, et donc qu'il suffit de la recompiler pour qu'elle en fasse ce que tu en veux.
je veux juste dire que (et je ne parle pas d'impossibilité technique) root ne devrait pas connaitre les mot de passe des utilisateur.
je ne parle pas non plus en terme de securité de votre machine, simplement nombre d'utilsiateur de la vrai vie (et qui ne sont pas forcement informaticien) ont plein de mots de passe retenir et utilisent parfois les même.
par exemple pour le logiciel de gestion des payes dans ma boite, il faut un mot de passe pour y acceder, la fille qui gere celà a au moins quotidiennement 10 mots de passes pour differentes application, je suis sur qu'elle réutilise ses mots de passe, et je la comprends. et donc elle n'aimerais pas du tout que l'admin connaisse l'un de ses mot de passe. voilà.
et accessoirement quand on est root, on n'a pas besoin de connaitre le mot de passe avec la commande "su".
c'est de la sécurité par l'obscurité..(blabla)...Mauvaise réponse ! je te trouve bien sarcastique, calme toi un peu, c'est le week end.
relis moi je n'ai pas dit que ce n'etait pas possible, j'ai dis qu'il ne faudrait pas. que c'est pas bien.
Pas bien, pas pour des raisons phylosophiques (sécurité par l'obscurité...[1]) mais simplement que par principe tu ne dois pas les connaitre, je t'ai donnée un vrai exemple de la vraie vie avec des vraie gens dans mon post precedant.
[1] : ca me fais doucement rigoler les types qui balancent des "sécurité par l'obscurité", c'est à la mode. (ca fait gagner des points sur la tribune?)
Mais a ton avis, pourquoi donc on ne stoque pas les mots de passe en clair finalement dans /etc/password ? (en ne donnant les droit qu'a root bien sur). hein ? obscurité ?
Et puis tiens, lundi, je vais dire aux employés d'ecrire leur mot de passe sur un post-it a coller sur leur ecran. je leur dirait qu'un brillant conseil m'a convaincu que l'obscurité c'est pas bien, (ca doit pas être GPL?).
j'te donne une astuce : un mot de passe, intrinsequement, ca doit rester secret.
même s'il existe plein plein de moyen de les connaitre. j'ai pas dis le contraire, mais je m'en fou c'est pas l'objet. (il y a même la torture aussi, et ca ne necessite aucune competence en info).
alors, s'il te plait garde tes grandes phrases sur l'obscurité pour les cas qui le vallent vraiment.
PS : j'ai confiance en leur root, c'est moi ;)
PPS: le plus difficile avec certains informaticiens, c'est qu'ils ont le nez dans le guidon... ha ca pour la technique des le debut il va te sortir le sniff reseau, le printf... alors qu'il a tout simplement pas compris l'objet de mon message.
PPPS : si le ton ne vous plait pas, moinsez moi.
Posté par PLuG le 04/06/05 à 13:13.
>Mais a ton avis, pourquoi donc on ne stoque pas les mots de passe en clair
> finalement dans /etc/password ? >(en ne donnant les droit qu'a root bien sur). hein ? obscurité ?
C'est historique.
on ne peut pas enlever les droits lecture sur /etc/passwd pour tout le monde car c'est necessaire pou l'association uid/nom sur le systeme (un simple /bin/ls en a déjà besoin).
A l'époque, on stockait quand meme le mot de passe dans /etc/passwd (mais de façon codée on va dire). Les attaques dictionnaire et autres ont fini par générer l'évolution suivante: mot de passe dans /etc/shadow et uid dans /etc/passwd, /etc/passwd étant toujours lisible de tout le monde, /etc/shadow étant limité à root.
bref c'est historique, y'a eu des évolutions ...
mais ne pas stocker les mots de passe en clair a quand même un gros avantage. Si chaque fois qu'on regarde, on lit en clair les mots de passe, on s'en rappelle malgré nous ... on fini par les connaitre quasiement sans le vouloir. Alors que devoir lancer une attaque dictionnaire c'est pas la même démarche. Devant une accusation ce sera plus difficile de prétendre ne pas l'avoir fait exprès.
merci pour les infos, j'aurait du ecrit "/etc/shadow" c'est vrai.
mon exemple n'etait pas réaliste de toute maniere, c'etait juste pour les besoins de l'explication.
> (mais de façon codée on va dire)
il me semble que c'est un "hash" plutot qu'un codage, c-a-d une empreinte, comme un SHA un MD5...
c'est pas reversible, mais effectivement on peut l'attaquer (brut force ou dico).
PS: c'est sur ce site que j'ai appris qu'on dis pas "crypter" mais "chiffrer" :)
> (ca fait gagner des points sur la tribune?
Jamais mis les pieds sur la tribune
> par principe tu ne dois pas les connaitre
Tu as raison c'est un principe. Mais afficher les password que tu peux avoir de toute façon n'ouvre pas une faille. La faille existait avant ! Si ton mot de passe était si précieux (le même que ta banque) il n'aurait jamais du se retrouver là en clair. L'administrateur n'ouvre pas une faille il ne fait que l'exploiter. La faille c'est *toi* qui l'a introduite (c'est vrai que les outils actuels ne t'aident pas non plus).
Après il n'est clairement pas souhaitable que ca l'affiche par défaut on est d'accord la dessus.
Posté par Matthieu MARC le 05/06/05 à 09:56.
Questions bêtes et impertinentes : L'administrateur système est-il en droit de connaître les mots de passe des utilisateurs ou de mettre en oeuvre un moyen de les découvrir ?
Si jamais un utilisateur a des problèmes et se rend compte que l'administrateur connaît son mot de passe, comment fera l'administrateur pour se défendre devant la justice ? (on rencontre actuellement les mêmes problèmes pour la messagerie... des administrateurs sont traînés devant les tribunaux pour avoir lu des messages à l'insu des utilisateurs....)
Je vous laisse réfléchir à ses points...
Si l'administrateur n'a pas à connaitre les mots de passe il ne DOIT pas pouvoir les connaitre. C'est bien le point sur lequel j'insiste.
La technique de fermer les yeux et dire "je le vois pas" n'est pas une solution.
Le problème est beaucoup plus vaste. Un exemple qui me vient immédiatement en tête est "Pourquoi l'administrateur d'un l'hopital peut avoir accès à ton dossier médical ?".
Le problème est que les systèmes n'ont pas été conçu avec ces problématiques en tête, et que la plupart des protocoles non plus. On se retrouve alors avec un tas de boue ambulant sur lequel on rajoute des rustines au fur et à mesure pour que ca soit acceptable.
Sniffer un réseau wifi sur lequel tu es connecté c'est mal. Mais se baser sur le fait que c'est mal pour l'interdire... Non ca ne devrait pas être possible !
A aucun moment j'ai dis cela. Je dis simplement que y'a des choses que l'on ne peut pas faire comme modifier le code de sshd pour qu'il affiche les mots de passe en clair dans les fichiers de logs. C'est tout d'abord un problème d'éthique et de respect de la vie privée, et secondo un problème juridique (respect de la vie privée également). Il y a un problème que tu viens de faire ressurgir : nous utilisons des technologies faites pour améliorer l'ergonomie, mais désastreuse d'un point de vue sécurité. On peut prendre pour exemple le WIFI. C'est bien, c'est beau, tu fais une démo devant un public et 2 secondes après le public sort son chéquier pour t'acheter ta borne wifi. Du point de vue usabilité, le wifi est bon. Du point de vue sécurité, c'est désastreux. Tellement désastreux que je pense que si tu mets une borne wifi sur ton réseau sans l'isoler complètement, alors tu peux enlever tes firewalls (ça ne sert à rien de fermer ta porte d'entrée à triple tours si derrière tes portes fenêtres sont grandes ouvertes).
Donc on a d'un côté un outils qui peut être utilisé, mais qui n'est pas bon du point de vue sécurité. La question est maintenant : "doit-on le mettre en oeuvre ?", n'est pas tromper l'utilisateur en lui mettant en place une telle technologie, sachant que pour l'utilisateur, inconsciemment (tellement inconsciemment qu'il n'en parle plus et qu'il pense maintenant à tort que la sécurité n'a pas de contrainte), la sécurité doit être prise en compte à tout moment ? L'utilisateur pourra-t-il se retourner contre l'administrateur système en cas de problème ?
Nous pouvons faire la relation avec d'autres technologies imaginaires. Imaginons que dans l'automobile, il soit commercialisé un système qui permet de controler sa voiture à la voix (gloups). En disant "stop", la voiture s'arrête. Malheureusement, ce système n'est pas sécurisé et peut donc être utilisé à l'insu de l'utilisateur (ce ne sera pas un pirate qui va utiliser le système, mais la fonction principale sera détourné par un élément extérieur à cause d'une mauvaise conception de l'outils). Ce qui devait arriver arriva, un jour, l'automobiliste roulait à 132km/h sur l'autoroute, il écoutait sa radio quand le speaker utilisa le mot "stop". La voiture s'arrêta brusquement.. carambolage... Qu'en pensons-nous? le système de contrôle par la voix était mal conçu, non sécurisé dans le sens où un élément extérieur pu en prendre le contrôle. L'automobile est-il en droit de demander réparation auprès du vendeur de voiture ? on peut le penser fortement. L'analogie avec le wifi n'est pas très loin.
Voila quelques éléments de réflexion. Je n'ai pas de réponse, personne n'a de réponse. Mais ça nous (administrateur système/réseaux) pend au nez !
Posté par Sylvain Sauvage le 05/06/05 à 17:16.
Nous pouvons faire la relation [...] L'analogie avec le wifi n'est pas très loin.
Ça me rappelle la (sans doute fausse) anecdote sur un système de reconnaissance vocale dans les années 1990 : pendant une démo en public, le démonstrateur montre que l'on peut demander l'ouverture d'une fenêtre DOS (ben oui, ça tournait sous windows) et, à son invitation (ou non, ça n'est pas très important), quelqu'un dans le public dit « format C column, return » et un autre de crier « yes, return ».
Pour ceux qui ne comprendraient pas, demandez à quelqu'un de vous prêter son windows (ben oui : les linuxfr-iens n'ont pas de windows ou ne sont pas assez fous pour faire des tests sur le leur), ouvrez une fenêtre de commande et tapez « format C: », puis répondez « yes » à la question (comme on le fait toujours avec les questions sous windows). Prévoyez quelques heures pour réparer après coup ou bien courrez très vite.
Pour revenir à la question principale, il n'y a pas de système absolument sûr, en informatique ou ailleurs : de la même façon que les portes blindées sont toutes cassables, tous les systèmes de chiffrement sont cassables, ce que l'on espère, c'est que le cambrioleur se fatiguera avant d'y arriver ou ira cambrioler le voisin dont la porte prend moins de temps à ouvrir.
Et pour revenir à ce fil en particulier, tout en restant dans l'analogie des portes et serrures, les serruriers sont capables d'ouvrir les portes, le concierge de l'immeuble aussi, les employés de banque ont accès à vos comptes, etc.
Il y a un moment où il faut faire confiance.
Il y a aussi un moment où les abus sont punis.
Cela s'appelle l'éthique.
Ce n'est pas facile de la définir, ce n'est pas facile de l'appliquer.
Posté par bertrand (page perso) le 06/06/05 à 10:36.
"les employés de banques ont accès à vos compte" oui mais c'est enregistré et on peut retrouver qui a fait quoi. (s'il n'y a pas usurpation de login !)
Posté par briaeros007 le 12/06/05 à 19:37.
pas forcement ; les dossiers pouvant etre aussi sur papier (et les justificatif qu'ils te demandent, ils les mettent ou ? je crois pas qu'il les scannent)
> M'enfin bon syslog est tellement pourri qu'on est plus à ca près
Mon conseil: regardes du coté de syslog-ng, c'est impressionnant tout ce qu'il permet de faire:
http://www.balabit.com/products/syslog_ng/(...)
Pour information je suis contributeur à un démon syslog et au WG de l'IETF sur syslog :-)
Enfin bon si l'ensemble de nouveaux drafts arrive jusqu'au status de RFC et qu'un jour hypothétiquement elles sont adoptées ca deviendra acceptable.
Posté par igor38 le 05/06/05 à 19:45.
" adieu sshd aussi "
Euh... Pourquoi ?
Tu peux aussi configurer ton hosts.deny, et mettre seulement tes ip autorisées (ou dyndns) dans ton hosts.allow
Re: une petite attaque
Posté par le 03/06/05 à 18:07.
Oui, moi aussi j'en ai plein les logs. Les essais d'intrusion proviennent d'ordinateurs situés en Chine, Corée, Mongolie, surement des ordinateurs piratés.
Je trouve ça assez embêtant, mais on s'y fait. Un seul utilisateur a le droit de se loguer via ssh (moi), donc a priori, je ne crains vraiment rien.
M'enfin bon, pour ne pas avoir des logs pourris jusqu'à la moelle, j'ai mis sshd en écoute sur un autre port (22222). Depuis, je n'ai plus de problèmes.
Posté par smorico (page perso) le 03/06/05 à 18:19.
lol, t'as plus qu'a changer de port...
Les robots Attaques ??
Oui c'est certainement un bot...
Assure toi d'avoir un mot de passe solide...
Ce que tu peut faire, c'est déjà loguer le trafic avec iptable pour voir d'ou l'attaque vient... Tu peut ensuite bannir la ou les adresses IP.
Tu peut aussi mettre en place un truc sympa grâce au logiciel Knocker. Il s'agit d'un port knocker. Il permet de lancer un service uniquement si certains paquets précis sont reçus.
Par exemple 2 paquet SYN/ACK avec tel numéro de séquence, suivi d'un paquet RST provenant du port heu je sais pas 53...
Tu te fait ensuite un petit utilitaire qui permet d'envoyer ces paquets sur ton serveur. A son execution (sur un pc depuis lequel tu veux te connecter), ca lancera le service SSH. Tu peut executer une commande, donc par exemple ajouter une régle iptable pour autoriser seulement l'IP qui à envoyé les paquets à se connecter sur le port 22.
Plus d'info sur : http://knocker.sourceforge.net/(...)
Le paquet debian s'appelle knoker.
Re: Les robots Attaques ??
Posté par Victor le 03/06/05 à 18:30.
le packet debian s'appelerait pas knocker plutot ?
et ou vois tu qu'il peut avoir le comportement que tu decris ?
je n'ai pas reussi a trouver :(
m**** je me suis gouré désolé. knocker est un port scanner ce qui n'a rien à voir...
Je voulais parler de "Advanced Port Knocking Suite" : APKS
Tu trouvera des infos sur la page de Renaud Bidou : http://www.iv2-technologies.com/~rbidou/(...)
le readme est ici : http://www.iv2-technologies.com/~rbidou/apk.README.html(...)
C'est du perl. En fait il y a une partie "serveur" et même une partie cliente qui permet de générer les paquets donc pas besoin de coder quoi que ce soit...
Sur ubuntu, j'ai :
# apt-cache search knocker
knocker - a simple and easy to use TCP security port scanner
ainsi que la description :
Description: a simple and easy to use TCP security port scanner
Knocker is a new, simple, and easy to use TCP security port
scanner written in C, using threads. It is able to analyze hosts
and the network services which are running on them.
The URL for this project is http://knocker.sourceforge.net/(...)
Il y a comme seule dépendance libc6 je crois.
Pubkey
Posté par Bruno Hondelatte (page perso) le 03/06/05 à 18:21.
Tu peux aussi activer la connexion par clef publique uniquement. Dans ce cas, ça coupe (très) court à ces tentatives externes.
L'inconvénient, c'est qu'il faut avoir son couple de clefs sur soi (mais bon, maintenant tout le monde se balade avec sa clé usb/lecteur mp3 dans la poche, non ?)
HS : Suis-je un geek normalement constitué ?
Posté par plagiats le 03/06/05 à 18:25.
Lorsque je lis "Journal : une petite attaque", je pense à un infarctus. est-ce grave docteur ?
Re: HS : Suis-je un geek normalement constitué ?
Le plus dur c'est de pas avoir une attaque quand on t'attaque :D
Posté par M le 03/06/05 à 19:08.
perso ssh est ouvert que pour les machines auquel je fais confiance...
Pas de root par SSH
Posté par Xavier MOGHRABI (page perso) le 03/06/05 à 21:35.
désactive la connexion par root avec SSH
et pour les autres utilisateurs utilisent si possible des clefs et désactive la connexion par mot de passe
Moi aussi !
Posté par Miguel Moquillon (page perso) le 03/06/05 à 21:39.
Après lecture de ton journal, je me suis aussi penché sur mes log d'authentification. Et j'ai les même traces !
Pour mon serveur SSH, j'ai juste activé la connexion par clé publique (les clés des serveurs distants doivent être listés parmi ceux autorisés) + par user/challenge (pas par mot de passe).
Le root n'est pas non plus autorisé à se connecter par ssh.
Bien que cela devrait suffire, j'ai toutefois quelques inquiétudes.
La dernière tentative d'attaque date du 1er juin.
Host Deny
Posté par bghflt (page perso) le 03/06/05 à 22:27.
Voir:
http://freshmeat.net/projects/denyhosts/(...)
Pour éviter ces attaques en quasi temps réel...
Sinon faire des graphes pour voir l'horreur et la constance de ces attaques..
Une petite attaque : NON ! Un essai !
Évalué à -1
Et alors ton pc est mort ? Quelles consequences ?
Ta machine est tombée au moins ???