Si je ne m’abuse, le protocole IRC est couramment utilisé pour le contrôle des botnets. Mais en général les machines compromises enrôlées de force dans ces botnets sont plutôt clientes IRC et se connectent à un serveur sous le contrôle du pirate pour y attendre leurs ordres.
PS : c’est quoi ces adresses IP chinoises ?
Ce n’est pas discutable, un administrateur ne se logue jamais en tant que root encore moins directement.
Mieux tu désactive l’authentification par mot de passe et tu passe par un système de clés PGP.
Et comme le précise dmon, tu installe fail2ban et là tu peux dormir tranquille.
Dans les fichiers, il y avait les résultats des scans (IP + login + passwd). vuln était vide, par contre nobash.txt était non vide et contient des comptes existant mais sans bash (on doit pouvoir faire du scp et autres peut être). J’ai testé deux adresses…
gege2061: Non, il n’est pas toujours possible d’avoir ses clefs, elles peuvent disparaitre. Un bon mot de passe est tout aussi sûr et permet un accès en urgence.
fail2ban ne peut rien contre les botnets, j’ai une tentative d’accès sur un de mes serveurs depuis 1-2 semaine, le gars essaye un dictionnaire de plusieurs dizaine de milliers de login/passwd à partir de 1000-2000 machines (1 à 3 essais par machines). Il peut continuer…
remarks: ±-------------------------------------------------------------+
remarks: | ABUSE CONTACT: abuse@rcs-rds.ro IN CASE OF HACK ATTACKS, |
remarks: | ILLEGAL ACTIVITY, VIOLATION, SCANS, PROBES, SPAM, ETC. |
remarks: | !! PLEASE DO NOT CONTACT OTHER PERSONS FOR THESE PROBLEMS !! |
remarks: ±-------------------------------------------------------------+
remarks: ------------------------------------------------
remarks: | Please don’t send me any abuse complaints. |
remarks: | Use abuse@rcs-rds.ro for that or contact |
remarks: | your service provider or local authorities |
remarks: | !! DO NOT CALL ME REGARDING ABUSE ISSUES !! |
remarks: ------------------------------------------------
Apparament, il a l’habitude que des gens viennent se plaindre …
Ce n’est pas discutable, un administrateur ne se logue jamais en tant que root encore moins directement.
Mieux tu désactive l’authentification par mot de passe et tu passe par un système de clés PGP.
Et comme le précise dmon, tu installe fail2ban et là tu peux dormir tranquille.
Plus d’info…[/quote]
Au lieu de laisser ssh à disposition de tout le monde, il est possible d’utiliser openvpn pour se connecter sur son serveur et de cette connexion vpn, se connecter à ssh. De là, qu’on se connecte via ssh en root ou avec un autre user…Je vois déjà moins le moins problème.
Changer le port ssh par défaut si c’est pas déjà fait…
2222 au lieu de 22 par exemple
+fail2ban comme dit plus haut
Ou encore mieux : pas de ssh :smt003
yeas fail2bann est super !!
j’avais noter dans un commentaire dan T&A ou pause café les choses a modifier pour ne pas que cela arrive ,je vais voir si je te retrouve ça, mais sinon pratiquement tout a ete dit sur ce thread !!
tu devrais etre tranquille maintenant !! ^^
Sûr, et on peut supprimer la machine aussi. Le problème est qu’on est parfois amener à agir sur le serveur derrière un parefeu à partir d’une machine tierce. J’ai même un telnet-ssl sur mon serveur…
et pourtant:
[quote]francois@cerbere:~$ expr zcat /var/log/auth.log*gz | grep -c "authentication failure" + cat /var/log/auth.log* | grep -c "authentication failure"
11037
francois@cerbere:~$
[/quote]soit 11037 tentatives depuis le 6 novembre soit 1500 à 1600 par jour avec parfois des pics à 20000. C’est comme ça depuis 2003, date où un gars était entré sur ma machine.
PS: J’ai l’équivalent de fail2ban avec ipt_recent mais les botnets sont redoutables.
Depuis je pars du principe quoi que je fasse, la faille est toujours possible, donc le but n’est pas de la contrer à tout prix mais de la détecter.
Je ne dis pas que ma machine est sûre mais si il y a une intrusion, je le saurais (du moins je fais tout pour).
je voudrai aussi proposer:)
iptables permet de filtrer par utilisateur, donc on autorise tout ce qui est user sauf root et les port obligatoire en principe le port 22 est interdis a root, si le mec tante la connections direct en root tu peux lui planter un ban 
en plus je pense qu’on voyage pas a tombouctou .il suffi d’autorisé que les pays ou on va et donc sa ferme la porte à pas mal de monde
Si autoriser que le pays genre la France , les attaques *.eu *.ch peuve pas joindre le port 22 sa filtre pas mal de monde 
bon il peux toujours trouver un chmin qui fini par aboutir par la suisse, mai pour trouver un paquet de machine venant du meme pays c est plus dificile
en gros: ssh securiser comme il ce doit + iptables c’est assez costaud
hihiih tiens ca me fais penser a la serie 24h chrono …loool
Ce n’est pas discutable, un administrateur ne se logue jamais en tant que root encore moins directement.[/quote]
Le login root peut être utile pour transférer des fichiers avec scp par exemple.
Bof, ça rajoute une authentification OpenVPN en plus de l’authentification SSH. Si c’est un cache-misère pour compenser une faiblesse d’authentification de SSH, autant renforcer celle-ci plutôt, non ?
Sécurité par l’obscurité. Ça n’arrêtera pas un pirate déterminé alors qu’une attaque au dictionnaire n’a aucune chance de réussir avec une authentification raisonnablement robuste.
On en revient toujours au même point : il faut une authentification SSH robuste.
Je ne reviendrai pas dessus mais j’ai déjà expliqué pourquoi je trouvais l’approche basée sur ipt_recent moins sûre que les techniques de type fail2ban.
Marchera pas : le processus sshd qui gère la connexion SSH appartient à root.
De toute façon, même dans le cas contraire seuls les paquets émis par un processus local ont un propriétaire, pas les paquets entrants. On ne pourrait au mieux que bloquer les paquets sortants de la connexion SSH une fois celle-ci établie et l’authentification réalisée. Très moche du point de vue réseau.
[quote=“panthere”]il suffi d’autorisé que les pays ou on va et donc sa ferme la porte à pas mal de monde
Si autoriser que le pays genre la France , les attaques *.eu *.ch peuve pas joindre le port 22[/quote]
Tu confonds le TLD du reverse et la “localisation” de l’adresse IP. Une adresse IP en France peut avoir un reverse en autre chose que .fr et inversement. D’autre part la localisation d’une adresse IP n’est pas fiable, il y a risque de faux positifs et faux négatifs.
Moche peut etre mai sa marche essaye je te dit:) et le module onwer filtre seulement en sortie ce qui comme tu le dit normal
je dit que ce qui permet de securiser meme faible devrait être utilisé
Tu confonds le TLD du reverse et la "localisation" de l'adresse IP. Une adresse IP en France peut avoir un reverse en autre chose que .fr et inversement. D'autre part la localisation d'une adresse IP n'est pas fiable, il y a risque de faux positifs et faux négatifs.euh je doit dire le je voit pas ce que tu entend par un reverse ?
pas fiable, ? euh je suppose m’enfin j’ai jamais compris l’histoire si tu as un lien qui explique comment je veux bien. car en principe l’ip est fourni par le fai c est donc facie de savoir si on est juste ou pas (après je supose qu’on peux utilisé des relait pour changer la source mai bon… 
Petite question qui me chatouille depuis un moment que en est il de l’ipv6 ? je voit tout un bordel arriver dans le kernel mai aux niveau des adresse ip rare son celle qui semble l’utiliser ? 
je liste les ip avec lsof -i -P ou netstat ,ou iptraf j’ai jamais croiser d’ipv6 ?
c’est pas supposer être plus fiable justement ? 
sinon un truc fiable : la virtualisation si c est haker on restore le fichier on corrige et zou :smt003 j’utilise ce stratagème pour apache
Oui, j’y ai même repensé en écrivant ces lignes. Je ne me souviens plus lra raison exacte (mis à part un débordement de tables) mais elle était simple, c’est quoi déjà?
sa rempli un fichier + mauvaise gestion des connection actuel. par surcharge sa peux faire lacher la machine il me semble
Saturation de la table oui, mais je crois me souvenir d’un pbm plus subtil… (celui ci, je me le rappelais).
@ fran.b :
Les techniques de type failban se basent sur les échecs des tentatives d’authentification SSH depuis une adresse IP donnée, alors que celles basées sur la correspondance recent d’iptables se basent sur les paquets de demande de connexion (paquets SYN) sur le port SSH. Ces dernières sont donc vulnérables à l’usurpation (spoofing) de l’adresse IP source, qui peut être exploitée aussi bien pour bannir l’adresse IP d’un utilisateur légitime que pour faire sortir sa propre adresse IP de la liste des bannis, dont la capacité est limitée (et réglable) comme tu le rappelles, en y faisant entrer suffisamment d’adresses usurpées. Aucun risque de faire exploser la machine en revanche, faut pas exagérer.
Néanmois je reconnais volontiers que cette faiblesse n’est pas exploitable par le premier script kiddie venu.
Je me demande s’il n’y aurait pas aussi un risque de se faire bannir accidentellement en cas de dysfonctionnement temporaire du réseau qui induisent le client à envoyer plusieurs SYN. Ce risque n’existe pas avec les techniques basées sur l’échec de l’authentification.
@ panthere :
Pour essayer, je veux bien les règles iptables qui te permettent de discriminer les connexions SSH entrantes en fonction du login utilisateur.
La seule donnée réseau qui identifie la source d’une connexion SSH est l’adresse IP source, or toi tu parles de .eu et .ch qui sont des noms de domaines de premier niveau (TLD). J’ai donc supposé que tu faisais référence au reverse DNS de l’adresse IP. Mais outre le fait qu’iptables ne peut pas se baser sur le reverse, un nom de domaine n’est pas fiable pour localiser une adresse puisqu’on peut mettre ce qu’on veut comme reverse. Une adresse IP “française” peut très bien avoir un reverse en .com, .net, .org, .eu, .ch…
Concernant IPv6, ça marche grosso modo comme IPv4, ce n’est pas plus sûr. La seule grosse différence, c’est la taille des adresses. Si tu n’as pas de connectivité internet IPv6, tu ne risques pas de voir du trafic IPv6 en provenance d’internet.
Voilà, c’était le spoofing… Note que à partir d’une machine à partir d’un FAI, le spoofing d’IP est souvent impossible. Par exemple chez moi, pas moyen de faire partir un paquet n’ayant pas mon IP comme IP source… Par contre, en local ou à partir du réseau d’une grosse boite, c’est différent.
Il y a un deuxième souci à ipt_recent, c’est l’impossibilité d’enchainer des «scp» car ça multiplie les connexions…
La multiplicité des connexions est un souci important si on l’utilise sur le POP3 par exemple à cause des gadgets qui sondent toutes 15s si tu as du courrier…
Ce sujet est passionnant ! Merci pour vos précieuses infos et retours à tous.
[quote=“fran.b”]
[quote]francois@cerbere:~$ expr zcat /var/log/auth.log*gz | grep -c "authentication failure" + cat /var/log/auth.log* | grep -c "authentication failure"
11037
francois@cerbere:~$
[/quote][/quote]
J’étais en train de me dire que j’allais faire un petit jeu de mot à propos du cerbère de la porte, et puis j’ai eu envie d’essayer la commande de François, pour voir
~/ expr `zcat /var/log/auth.log*gz | grep -c "authentication failure"` + ` cat /var/log/auth.log* | grep -c "authentication failure"`
4736
J’ai laissé tombé l’idée du jeux de mot…
ça fait beaucoup 
J’ai réinstallé mon serveur il y a 1 mois et demi. Je n’ai même pas une IP fixe… Et ma machine n’est allumée que 12 heures par jour…
J’hallucine, je pensais être tranquille avec mes 15 Ko…
Comment être certain que personne n’est entré 