Hello,
J'administre actuellement pas mal de serveurs et c'est un peu toujours la galère quand quelqu'un fait des modifs dans un fichier de conf pour retrouver qui l'a fait ...
Alors ça, j'aimerais que quand quelqu'un se connecte en SSH, un script lui demande son petit nom, ce qu'il vient faire et stocke tout ca et l'IP dans un fichier de log ...
Je pense qu'il n'est pas possible de faire une sorte de surcouche à SSH mais par contre, peut être qu'à l'ouverture de la session on peut lancer un script non ?
Merci :)
Forum Linux.général Accès SSH, récupérer ip, nom de la personne
30
juin
2009
# Grsecurity
Posté par nono14 (site web personnel) . Évalué à 1.
C'est un patch noyau, qui permet en autre d'auditer les commandes lancées par les utilisateurs...
Système - Réseau - Sécurité Open Source
[^] # Re: Grsecurity
Posté par Arkezis (site web personnel) . Évalué à 1.
Cependant, j'ai peur que ca soit trop compliqué pour ce que je veux faire ...
Je souhaiterais en fait, juste lancer un petit script ;-)
[^] # Re: Grsecurity
Posté par Ellendhel (site web personnel) . Évalué à 3.
Ce n'est pas un "petit script" mais celui-ci est prévu pour un besoin similaire au tiens. À adapter... (et probablement aussi corriger, tout n'est sûrement pas parfait)
#!/bin/bash
# cree un fichier journal et un fichier de configuration
# correspondant a l'action effectue sur le routeur ou le pare-feu
export LANG=fr_FR
horodatage=$(/bin/date +"%Y%m%d")
operateur=$LOGNAME
dateoperation=$(/bin/date +"%e %B %Y - %H:%M")
generelog()
{
version=1
while [ -r $fichier-$horodatage-0$version.log -o -r $fichier-$horodatage-$version.log ]
do
let version=$(($version+1))
done
if [ $version -lt 10 ]
then
fichierlog=$fichier-$horodatage-0$version.log
else
fichierlog=$fichier-$horodatage-$version.log
fi
/bin/touch $fichierlog
echo "Operateur : $operateur" > $fichierlog
echo "Date : $dateoperation" >> $fichierlog
echo "Detail de l'intervention : " >> $fichierlog
echo "Editez le fichier $fichierlog"
}
genereconf()
{
version=1
while [ -r $fichier-$horodatage-0$version -o -r $fichier-$horodatage-$version ]
do
let version=$(($version+1))
done
if [ $version -lt 10 ]
then
fichierconf=$fichier-$horodatage-0$version
else
fichierconf=$fichier-$horodatage-$version
fi
/bin/touch $fichierconf
/bin/chmod 666 $fichierconf
echo "Fichier $fichierconf genere."
}
# Tests sur les arguments passes au script
if [ $# -lt 1 ]
then
echo "usage : $0 [-r|-f]"
exit 1
fi
if [ ! -w . ]
then
echo "Repertoire non accessible"
exit 1
fi
case "$1" in
-r)
fichier="routeur"
generelog
genereconf
;;
-f)
fichier="pare-feu"
generelog
genereconf
;;
*)
echo "usage : $0 [-r|-f]"
;;
esac
# EoF
# gestion de version de /etc
Posté par niol (site web personnel) . Évalué à 1.
http://joey.kitenet.net/code/etckeeper/
[^] # Re: gestion de version de /etc
Posté par Arkezis (site web personnel) . Évalué à 1.
Donc on aurait tous les mêmes "noms".
Qui plus est, ce n'est pas que de la modif de fichier de conf mais toute sorte de choses (ajout/suppression de fichiers, modifications...)
[^] # Re: gestion de version de /etc
Posté par balzane . Évalué à 7.
Au risque d'enfoncer une porte ouverte : pourquoi ne pas créer N utilisateurs aux mêmes droits ?
[^] # Re: gestion de version de /etc
Posté par NeoX . Évalué à 6.
cet utilisateur peut donc se connecter sur la machine et ensuite il serait en mesure de faire un sudo sur les commandes souhaitées/autorisées
tu pourrais meme avoir un ldap qui gere tes utilisateurs, et un ssh qui identifie tes utilisateurs via pam_ldap
ainsi, quand quelqu'un quitte la boite, tu fermes son compte ldap, et il n'a plus acces à aucun serveur...
[^] # Re: gestion de version de /etc
Posté par LaBienPensanceMaTuer . Évalué à 3.
L'utilisation d'un login unique sur une prod est une hérésie en terme de sécurité, en terme de gestion de droits, en terme de beaucoup de choses en fait.
Pour moi une meilleure résolution de ta problématique passe effectivement par le couple 1 login/utilisateur + fichier sudoers approprié.
C'est certes plus couteux en temps, mais c'est diablement plus efficace et ça renforce la sécurité de ta prod...
Ensuite, tu couples cette solution avec des mécanismes de centralisation de logs, et ensuite t'as plus qu'à cliquer dans ton navigateur pour savoir qui a fait quoi (genre syslog-ng avec mysql, et un front end PHP quelconque). Mais ça c'est du bonus :)
[^] # Re: gestion de version de /etc
Posté par Arkezis (site web personnel) . Évalué à 1.
Mais, je vais moi aussi, faire une exception ;-)
LDAP m'intéresse beaucoup mais il semble être très compliqué. Sachant que j'ai un parc de serveurs relativement important et qu'il y a beaucoup d'utilisateur à s'y connecter et ceci, par plusieurs moyens (SSH, FTP...).
Serait ce une solution appropriée ?
De plus, nous utilisons différents logiciels de gestion (tels que Trac et OpenERP), y'a t'il des plugins pour ceux ci qui pourront permettre de les coupler à LDAP ?
Merci pour toutes vos réponses :)
[^] # Re: gestion de version de /etc
Posté par NeoX . Évalué à 3.
pour interroger ldap au lieu de /etc/passwd et /etc/group
LDAP n'est pas compliqué si tu lis bien la documentation
je ne sais pas si Trac et OpenERP dispose de module ldap
mais ils peuvent peut-etre aussi utiliser pam_ldap
# Remplacer le shell
Posté par peck (site web personnel) . Évalué à 1.
[^] # Re: Remplacer le shell
Posté par bubar🦥 (site web personnel) . Évalué à 2.
nouveau terminal ouvert
sous shell
lancement de scripts
et j en passe.
donc peut être pas vraiment valable.
y a un contournement du genre :
check première connection -> exécution -> désactivation -> ré-activation lors de la déconnection pour la session suivante.
mais c' est sale.
un script lui demande son petit nom, ce qu'il vient faire et stocke tout ca et l'IP
regarde du côté de pam et de syslog. (à mon humble avis, ton script tu dois le faire en pensant "nouvelle règle pam", même si elle est simple.)
maintenant la vraie réponse c' est peut être des vrais comptes...
Maintenant, personnellement, comme un bon gros feignant, j' utiliserai HIST de bash.
En le customisant un peu, tu peux obtenir ce que tu recherches : un fichier consignant les connections, avec horodatage et ip source, ainsi que les actions effectuées.
Reste à protéger ce fichier...
Et ensuite j' ajouterai une tache Cron à base de tail, tout simplement.
Quoi qu 'en découvrant etckeeper, ça à l' air très sympa ! pourquoi le refaire si c' est déjà fait et en mieux ?
[^] # Re: Remplacer le shell
Posté par peck (site web personnel) . Évalué à 2.
Les sous shell est autres sont comme d'habitude en /bin/kivabien et ne sont pas changés.
# Bash, ssh et history
Posté par JJD . Évalué à 2.
Est-ce que l'adresse IP du client SSH peut te suffire pour tracer ce que tu veux ?
Si c'est le cas, tu peux arriver à tes fins simplement en jouant un peu de la configuration dans le fichier .bashrc :
- lors d'une connexion SSH, tu doit avoir les variables SSH_CLIENT et SSH_CONNECTION positionnées. Le premier mot de ces variables indique l'adresse IP du client
- pour savoir s'il s'agit d'une prière connexion (et pas d'un sous-shell), il suffit de vérifier que la variable SHLVL est égale à 1 : ça peut te servir pour faire un test dans .bashrc avant de poser tes questions au besoin
- une fois que tu as récupéré l'adresse IP ou le nom du client, tu peux créer un fichier d'historique des commandes personnalisé en attribuant une valeur à la variable HISTFILE (par exemple "export HISTFILE=~/.bash_history_$IP")
- pense à modifier la valeur de HISTFILESIZE si tu veux conserver plus de commandes que les 500 par défaut
- positionne la variable HISTTIMEFORMAT à quelque chose comme "%Y%m%d-%H%M%S " pour avoir un horodatage des commandes passées par les utilisateurs
Evidemment, ce type de chose est aussi possible avec d'autres shell comme ksh (à part peut être l'horodatage) ou zsh (avec l'option EXTENDED_HISTORY on peut même avoir la durée des commandes).
Bien sûr tout ceci suppose d'avoir une certaine confiance envers les utilisateurs concernés : rien ne les empêche de supprimer les fichiers d'historiques...
J'espère que tout cela pourra t'aider.
A+
JJD
[^] # Re: Bash, ssh et history
Posté par peck (site web personnel) . Évalué à 2.
[^] # Re: Bash, ssh et history
Posté par JJD . Évalué à 1.
- comme je l'ai écrit ce type de chose (historique par utilisateur) marche parfaitement avec d'autres shells, moyennant un paramétrage spécifique par shell utilisé (je l'ai fait avec ksh sous AIX pour éviter de retrouver autre chose que mes propres commandes lorsque je remontais dans l'historique)
- dans la problématique de Tom, j'ai l'impression qu'il n'y a qu'un seul user unix utilisé par plusieurs personnes. Sauf paramétrage tordu,je pense que ces différents utilisateurs ont donc bien le même shell
# audit
Posté par neologix . Évalué à 4.
http://librenix.com/?inode=10248
http://www.cyberciti.biz/tips/linux-audit-files-to-see-who-m(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.