Contreur d'intrusion en SSH
Fermé
Monosinus
-
Modifié par Monosinus le 16/11/2010 à 18:19
mamiemando Messages postés 33381 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 26 novembre 2024 - 17 nov. 2010 à 01:00
mamiemando Messages postés 33381 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 26 novembre 2024 - 17 nov. 2010 à 01:00
A voir également:
- Contreur d'intrusion en SSH
- Ssh download - Télécharger - Divers Web & Internet
- Fortiguard intrusion prevention - access blocked - Forum Virus
- Ssh n'est pas reconnu en tant que commande interne - Forum Linux / Unix
- Intrusion sur un terrain de foot - Forum Loisirs / Divertissements
- Access denied putty ssh ubuntu - Forum Linux / Unix
3 réponses
zipe31
Messages postés
36402
Date d'inscription
dimanche 7 novembre 2010
Statut
Contributeur
Dernière intervention
27 janvier 2021
6 418
16 nov. 2010 à 18:25
16 nov. 2010 à 18:25
Salut,
Normalement un :
après le "sleep 5" devrait tuer le dernier processus lancé en arrière-plan...
Normalement un :
kill $!
après le "sleep 5" devrait tuer le dernier processus lancé en arrière-plan...
Salut et merci pour une réponse aussi rapide.
Pour moi ca serait plutôt :
Recherche des intrus,
"Yessage" des intrus (boucle for)
Attendre 5 sec
Tuer les processus de yessage.
Merci :)
kill $!va-t-il supprimer le dernier processus en arrière plan, ou tuer tous les processus appelés dans la boucle for? Parce qu'avouons que tuer le processus dans la boucle et attendre 5s ne servirait pas à grand chose :/.
Pour moi ca serait plutôt :
Recherche des intrus,
"Yessage" des intrus (boucle for)
Attendre 5 sec
Tuer les processus de yessage.
Merci :)
zipe31
Messages postés
36402
Date d'inscription
dimanche 7 novembre 2010
Statut
Contributeur
Dernière intervention
27 janvier 2021
6 418
Modifié par zipe31 le 16/11/2010 à 18:58
Modifié par zipe31 le 16/11/2010 à 18:58
Il va tuer le dernier processus lancé en arrière-plan ;-(
A ce moment là, il te faut regrouper ta boucle for et les commandes qui suivent entre parenthèses (regroupement de commandes) et mettre ce groupe en arrière-plan.
A ce moment là, il te faut regrouper ta boucle for et les commandes qui suivent entre parenthèses (regroupement de commandes) et mettre ce groupe en arrière-plan.
( for... do commande1 commande2 done )& sleep 5 kill $!
mamiemando
Messages postés
33381
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
26 novembre 2024
7 802
16 nov. 2010 à 20:45
16 nov. 2010 à 20:45
Ça aurait été cool de donner des vrais noms à tes variables :s Un truc dans ce goût là par exemple
Je te laisse de voir ton soucis avec zipe31 pour les histoires de kill.
Au fait, pourquoi ne pas simplement limiter l'accès à certains utilisateurs en ssh (voir /etc/ssh/sshd_config) avec la directive AllowUser ?
Dans cet exemple, seul admin peut se connecter en ssh :
http://www.faqs.org/docs/securing/chap15sec122.html
Pense à relancer sshd pour prendre les modifications en compte. En root :
ou sur les vieilles distributions :
Bonne chance
#!/bin/sh message="Ouste petit garnement" while true; do who | while read ligne do login=$(echo $ligne | cut -d" " -f1) pts=$(echo $ligne | cut -d" " -f2) yes $message | write $login $pts done sleep 5 done
Je te laisse de voir ton soucis avec zipe31 pour les histoires de kill.
Au fait, pourquoi ne pas simplement limiter l'accès à certains utilisateurs en ssh (voir /etc/ssh/sshd_config) avec la directive AllowUser ?
Dans cet exemple, seul admin peut se connecter en ssh :
http://www.faqs.org/docs/securing/chap15sec122.html
Pense à relancer sshd pour prendre les modifications en compte. En root :
service sshd restart
ou sur les vieilles distributions :
/etc/init.d/sshd restart
Bonne chance
Je suis d'accord avec ton idée, le truc c'est que vu que je suis à l'IUT deja je ne peux pas passer en root ^^. De plus c'est peut etre sadique mais j'imagine deja la déception de mes futurs assaillants quand ils vont essayer de me "forker" (ben ouais faut bien s'occuper).
En tout cas j'essaierai demain pour le kill :)
En tout cas j'essaierai demain pour le kill :)
mamiemando
Messages postés
33381
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
26 novembre 2024
7 802
17 nov. 2010 à 01:00
17 nov. 2010 à 01:00
Mouais enfin tu sais bloquer un write c'est un peu l'enfance de l'art :
C'est même un peu une condition de survie en milieu hostile ;-)
De toute façon ne cherche pas tu ne peux pas empêcher en tant qu'utilisateur d'empêcher quelqu'un de venir se connecter chez toi et de travailler. Pouvoir le bloquer ou le pourrir serait intrusif ce qui va à l'encontre de la philosophie linux (un utilisateur non root ne doit pas pouvoir pénaliser un autre utilisateur). On donne donc aux utilisateurs des moyens pour se prémunir d'outils potentiellement intrusif (write par exemple peut être avec mesg) mais ça s'arrête là.
La seule manière de "cloisonner" requiert des droits root :
- authentification ssh
- allocation de ressources par quota (espace disque ...)
- etc ...
Mais bon au moins ça t'entraîne à faire du shell donc c'est déjà ça ;-)
You can prevent people (other than the super-user) from writing to you with the mesg(1) command.
C'est même un peu une condition de survie en milieu hostile ;-)
De toute façon ne cherche pas tu ne peux pas empêcher en tant qu'utilisateur d'empêcher quelqu'un de venir se connecter chez toi et de travailler. Pouvoir le bloquer ou le pourrir serait intrusif ce qui va à l'encontre de la philosophie linux (un utilisateur non root ne doit pas pouvoir pénaliser un autre utilisateur). On donne donc aux utilisateurs des moyens pour se prémunir d'outils potentiellement intrusif (write par exemple peut être avec mesg) mais ça s'arrête là.
La seule manière de "cloisonner" requiert des droits root :
- authentification ssh
- allocation de ressources par quota (espace disque ...)
- etc ...
Mais bon au moins ça t'entraîne à faire du shell donc c'est déjà ça ;-)