Ci-apr=E8s le contenu de deux logchecks de ce matin. Il me semble qu'il
s'agit de tentatives (infructueuses:) de se loguer sur ma machine via
ssh.
Quelqu'un peut-il m'indiquer comment je devrais r=E9agir en termes de
s=E9curisation, identification (commandes) et r=E9pression (abuse)?
Journal de 5h02:
Security Events
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
Mar 23 04:46:03 GDem3 sshd[11168]: Failed password for illegal user
test from ::ffff:211.176.33.46 port 50152 ssh2 Mar 23 04:46:06 GDem3
sshd[11174]: Failed password for illegal user guest from
::ffff:211.176.33.46 port 50252 ssh2 Mar 23 04:46:08 GDem3 sshd[11176]:
Illegal user admin from ::ffff:211.176.33.46 Mar 23 04:46:08 GDem3
sshd[11176]: Failed password for illegal user admin from
::ffff:211.176.33.46 port 50344 ssh2 Mar 23 04:46:11 GDem3 sshd[11182]:
Illegal user admin from ::ffff:211.176.33.46 Mar 23 04:46:11 GDem3
sshd[11182]: Failed password for illegal user admin from
::ffff:211.176.33.46 port 50439 ssh2 Mar 23 04:46:14 GDem3 sshd[11184]:
Failed password for illegal user user from ::ffff:211.176.33.46 port
50526 ssh2 Mar 23 04:46:17 GDem3 sshd[11190]: Failed password for root
from ::ffff:211.176.33.46 port 50618 ssh2 Mar 23 04:46:20 GDem3
sshd[11192]: Failed password for root from ::ffff:211.176.33.46 port
50711 ssh2 Mar 23 04:46:23 GDem3 sshd[11199]: Failed password for root
from ::ffff:211.176.33.46 port 50797 ssh2 Mar 23 04:46:26 GDem3
sshd[11201]: Failed password for illegal user test from
::ffff:211.176.33.46 port 50890 ssh2
System Events
=3D-=3D-=3D-=3D-=3D-=3D-=3D
Mar 23 04:46:03 GDem3 sshd[11168]: Illegal user test from
::ffff:211.176.33.46 Mar 23 04:46:03 GDem3 sshd[11168]: error: Could not
get shadow information for NOUSER Mar 23 04:46:06 GDem3 sshd[11174]:
Illegal user guest from ::ffff:211.176.33.46 Mar 23 04:46:06 GDem3
sshd[11174]: error: Could not get shadow information for NOUSER Mar 23
04:46:08 GDem3 sshd[11176]: error: Could not get shadow information for
NOUSER Mar 23 04:46:11 GDem3 sshd[11182]: error: Could not get shadow
information for NOUSER Mar 23 04:46:14 GDem3 sshd[11184]: Illegal user
user from ::ffff:211.176.33.46 Mar 23 04:46:14 GDem3 sshd[11184]: error:
Could not get shadow information for NOUSER Mar 23 04:46:26 GDem3
sshd[11201]: Illegal user test from ::ffff:211.176.33.46 Mar 23 04:46:26
GDem3 sshd[11201]: error: Could not get shadow information for NOUSER
Journal de 10h02:
Security Events
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
Mar 23 09:11:39 GDem3 sshd[27590]: Failed password for root from
::ffff:62.193.236.45 port 45567 ssh2 Mar 23 09:11:40 GDem3 sshd[27592]:
Failed password for root from ::ffff:62.193.236.45 port 45687 ssh2 Mar
23 09:11:41 GDem3 sshd[27594]: Failed password for root from
::ffff:62.193.236.45 port 45769 ssh2 Mar 23 09:11:42 GDem3 sshd[27596]:
Failed password for root from ::ffff:62.193.236.45 port 45851 ssh2 Mar
23 09:11:42 GDem3 sshd[27598]: Failed password for root from
::ffff:62.193.236.45 port 45936 ssh2 Mar 23 09:11:43 GDem3 sshd[27600]:
Failed password for root from ::ffff:62.193.236.45 port 46006 ssh2 Mar
23 09:11:44 GDem3 sshd[27602]: Failed password for root from
::ffff:62.193.236.45 port 46076 ssh2 Mar 23 09:11:44 GDem3 sshd[27608]:
Failed password for root from ::ffff:62.193.236.45 port 46156 ssh2
Le mercredi 23 mars 2005, à 11:56:18, SULEK Nicolas DSIC BA écrivait :
a écrit :
>Hello, > > > >>Bonjour, >> >>Ci-après le contenu de deux logchecks de ce matin. Il me semble >qu'il >s'agit de tentatives (infructueuses:) de se loguer sur ma >machine via >ssh. >> >>Quelqu'un peut-il m'indiquer comment je devrais réagir en termes de >>sécurisation, identification (commandes) et répression (abuse)? >> >> > >1/ Ne pas permettre de se logguer directement root en SSH >2/ Mettre les IPs dans le host.deny >3/ Tracer les IPs >4/ Surveiller les logs >5/ Mailer le provider de l'IP >6/ Garder les logs > >Voilà ce que je peux te dire. Il y a certainement d'autres choses à >faire ;) > >++ > > > on peut aussi changer le port de ssh, ça permet d'éviter pas mal de scripts dans ce genre.
Ministère de l'Intérieur SG/DSIC/SDEL/BA Pôle Architecture Technique
Merci pour vos réponses, donc dans l'ordre:
1/ ok déjà fait. su,sudo,sux sont là pour ça
2/ c'est vrai que les IP dynamiques changent de moins en moins souvent, mais est-ce que ce n'est pas un peu radical comme solution? ou alors temporairement (1 jour/mois/an?).
3/ Pour le premier:
traceroute 211.176.33.46 ... 13 so-0-0-0.mpr3.pao1.us.above.net (64.125.27.81) 179.499 ms 226.335 ms 179.101 ms 14 208.185.161.164.hanaro.com (208.185.161.164) 236.438 ms 223.844 ms 198.113 ms ... et je le touche au 19ème saut
Pour le second:
traceroute 62.193.236.45 ... 5 wpc0616.amenworld.com (62.193.236.45) 41.739 ms 44.809 ms 41.366 ms
4/ d'où ce fil
5 et 6/ avec les logs en pj, ok
Réduire l'utilisation en local : pas possible pour moi, j' ai un 'trusted network', ssh ne me sert que via internet.
Changer le port d'écoute: comment le choisir? < ou >1024? selon /etc/services?
Bannière: désactivée par défaut.
Connexion sans clés: ok, mais le StrictHostKeyChecking sur des IP dynamiques, c'est pas toujours facile.
Le mercredi 23 mars 2005, à 11:56:18, SULEK Nicolas DSIC BA écrivait :
franck@linuxpourtous.com a écrit :
>Hello,
>
>
>
>>Bonjour,
>>
>>Ci-après le contenu de deux logchecks de ce matin. Il me semble
>qu'il >s'agit de tentatives (infructueuses:) de se loguer sur ma
>machine via >ssh.
>>
>>Quelqu'un peut-il m'indiquer comment je devrais réagir en termes de
>>sécurisation, identification (commandes) et répression (abuse)?
>>
>>
>
>1/ Ne pas permettre de se logguer directement root en SSH
>2/ Mettre les IPs dans le host.deny
>3/ Tracer les IPs
>4/ Surveiller les logs
>5/ Mailer le provider de l'IP
>6/ Garder les logs
>
>Voilà ce que je peux te dire. Il y a certainement d'autres choses à
>faire ;)
>
>++
>
>
>
on peut aussi changer le port de ssh, ça permet d'éviter pas mal de
scripts dans ce genre.
Ministère de l'Intérieur
SG/DSIC/SDEL/BA
Pôle Architecture Technique
Merci pour vos réponses, donc dans l'ordre:
1/ ok déjà fait. su,sudo,sux sont là pour ça
2/ c'est vrai que les IP dynamiques changent de moins en moins souvent,
mais est-ce que ce n'est pas un peu radical comme solution? ou alors
temporairement (1 jour/mois/an?).
3/
Pour le premier:
traceroute 211.176.33.46
...
13 so-0-0-0.mpr3.pao1.us.above.net (64.125.27.81) 179.499 ms 226.335
ms 179.101 ms
14 208.185.161.164.hanaro.com (208.185.161.164) 236.438 ms 223.844 ms
198.113 ms
... et je le touche au 19ème saut
Pour le second:
traceroute 62.193.236.45
...
5 wpc0616.amenworld.com (62.193.236.45) 41.739 ms 44.809 ms 41.366
ms
4/ d'où ce fil
5 et 6/ avec les logs en pj, ok
Réduire l'utilisation en local : pas possible pour moi, j' ai un
'trusted network', ssh ne me sert que via internet.
Changer le port d'écoute: comment le choisir? < ou >1024? selon
/etc/services?
Bannière: désactivée par défaut.
Connexion sans clés: ok, mais le StrictHostKeyChecking sur des IP
dynamiques, c'est pas toujours facile.
Le mercredi 23 mars 2005, à 11:56:18, SULEK Nicolas DSIC BA écrivait :
a écrit :
>Hello, > > > >>Bonjour, >> >>Ci-après le contenu de deux logchecks de ce matin. Il me semble >qu'il >s'agit de tentatives (infructueuses:) de se loguer sur ma >machine via >ssh. >> >>Quelqu'un peut-il m'indiquer comment je devrais réagir en termes de >>sécurisation, identification (commandes) et répression (abuse)? >> >> > >1/ Ne pas permettre de se logguer directement root en SSH >2/ Mettre les IPs dans le host.deny >3/ Tracer les IPs >4/ Surveiller les logs >5/ Mailer le provider de l'IP >6/ Garder les logs > >Voilà ce que je peux te dire. Il y a certainement d'autres choses à >faire ;) > >++ > > > on peut aussi changer le port de ssh, ça permet d'éviter pas mal de scripts dans ce genre.
Ministère de l'Intérieur SG/DSIC/SDEL/BA Pôle Architecture Technique
Merci pour vos réponses, donc dans l'ordre:
1/ ok déjà fait. su,sudo,sux sont là pour ça
2/ c'est vrai que les IP dynamiques changent de moins en moins souvent, mais est-ce que ce n'est pas un peu radical comme solution? ou alors temporairement (1 jour/mois/an?).
3/ Pour le premier:
traceroute 211.176.33.46 ... 13 so-0-0-0.mpr3.pao1.us.above.net (64.125.27.81) 179.499 ms 226.335 ms 179.101 ms 14 208.185.161.164.hanaro.com (208.185.161.164) 236.438 ms 223.844 ms 198.113 ms ... et je le touche au 19ème saut
Pour le second:
traceroute 62.193.236.45 ... 5 wpc0616.amenworld.com (62.193.236.45) 41.739 ms 44.809 ms 41.366 ms
4/ d'où ce fil
5 et 6/ avec les logs en pj, ok
Réduire l'utilisation en local : pas possible pour moi, j' ai un 'trusted network', ssh ne me sert que via internet.
Changer le port d'écoute: comment le choisir? < ou >1024? selon /etc/services?
Bannière: désactivée par défaut.
Connexion sans clés: ok, mais le StrictHostKeyChecking sur des IP dynamiques, c'est pas toujours facile.
Steve
Arrêtez, je vais rougir ;)
Bon ok, laissez-moi un peu de temps pour nettoyer le code et je le mets en ligne.
A+
Le mercredi 23 mar 2005 à 13 h 04, Pierre a dit:
Bonjour,
Je suis également intéressé !
Pierre
Le mercredi 23 mars 2005 à 20:55 +0900, Charles Plessy a écrit :
> On Wed, Mar 23, 2005 at 12:21:02PM +0100, Steve wrote : > > > j'ai écrit un petit programme qui me résume ces tentatives, dont > > voici le résutat: > > Sympa, le programme... Il est disponible quelque part ? > > -- > Charles >
Arrêtez, je vais rougir ;)
Bon ok, laissez-moi un peu de temps pour nettoyer le code et je le
mets en ligne.
A+
Le mercredi 23 mar 2005 à 13 h 04, Pierre a dit:
Bonjour,
Je suis également intéressé !
Pierre
Le mercredi 23 mars 2005 à 20:55 +0900, Charles Plessy a écrit :
> On Wed, Mar 23, 2005 at 12:21:02PM +0100, Steve wrote :
>
> > j'ai écrit un petit programme qui me résume ces tentatives, dont
> > voici le résutat:
>
> Sympa, le programme... Il est disponible quelque part ?
>
> --
> Charles
>
Bon ok, laissez-moi un peu de temps pour nettoyer le code et je le mets en ligne.
A+
Le mercredi 23 mar 2005 à 13 h 04, Pierre a dit:
Bonjour,
Je suis également intéressé !
Pierre
Le mercredi 23 mars 2005 à 20:55 +0900, Charles Plessy a écrit :
> On Wed, Mar 23, 2005 at 12:21:02PM +0100, Steve wrote : > > > j'ai écrit un petit programme qui me résume ces tentatives, dont > > voici le résutat: > > Sympa, le programme... Il est disponible quelque part ? > > -- > Charles >
fra-duf-no-spam
Le 12865ième jour après Epoch, écrivait:
Hello,
Bonjour,
Ci-après le contenu de deux logchecks de ce matin. Il me semble qu'il s'agit de tentatives (infructueuses:) de se loguer sur ma machine via ssh.
Quelqu'un peut-il m'indiquer comment je devrais réagir en termes de sécurisation, identification (commandes) et répression (abuse)?
1/ Ne pas permettre de se logguer directement root en SSH
Ou alors, et aussi: Ne permettre la connection qu'avec un échange de clefs
2/ Mettre les IPs dans le host.deny
Elles changent tout le temps.
3/ Tracer les IPs
Pour en faire quoi?
4/ Surveiller les logs
Alors que surveiller sa porte d'entrée est pertinent car on peut arrêter le voleur quand il rentre, surveiller les logs ne permet pas tellement d'agir. On sait juste, après coup, qu'il y a eu effraction. Et c'est déjà trop tard.
5/ Mailer le provider de l'IP
Question subsidiaire: Existe-t-il un moyen d'avoir cette info de façon automatique? Il y a quelque temps, j'avais fait un script permettant de récupérer l'adresse email du FAI à partir d'une IP, mais c'était un peu de la cuisine.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le 12865ième jour après Epoch,
franck@linuxpourtous.com écrivait:
Hello,
Bonjour,
Ci-après le contenu de deux logchecks de ce matin. Il me semble qu'il
s'agit de tentatives (infructueuses:) de se loguer sur ma machine via
ssh.
Quelqu'un peut-il m'indiquer comment je devrais réagir en termes de
sécurisation, identification (commandes) et répression (abuse)?
1/ Ne pas permettre de se logguer directement root en SSH
Ou alors, et aussi: Ne permettre la connection qu'avec un échange de
clefs
2/ Mettre les IPs dans le host.deny
Elles changent tout le temps.
3/ Tracer les IPs
Pour en faire quoi?
4/ Surveiller les logs
Alors que surveiller sa porte d'entrée est pertinent car on peut
arrêter le voleur quand il rentre, surveiller les logs ne permet pas
tellement d'agir. On sait juste, après coup, qu'il y a eu
effraction. Et c'est déjà trop tard.
5/ Mailer le provider de l'IP
Question subsidiaire: Existe-t-il un moyen d'avoir cette info de façon
automatique? Il y a quelque temps, j'avais fait un script permettant
de récupérer l'adresse email du FAI à partir d'une IP, mais c'était un
peu de la cuisine.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Ci-après le contenu de deux logchecks de ce matin. Il me semble qu'il s'agit de tentatives (infructueuses:) de se loguer sur ma machine via ssh.
Quelqu'un peut-il m'indiquer comment je devrais réagir en termes de sécurisation, identification (commandes) et répression (abuse)?
1/ Ne pas permettre de se logguer directement root en SSH
Ou alors, et aussi: Ne permettre la connection qu'avec un échange de clefs
2/ Mettre les IPs dans le host.deny
Elles changent tout le temps.
3/ Tracer les IPs
Pour en faire quoi?
4/ Surveiller les logs
Alors que surveiller sa porte d'entrée est pertinent car on peut arrêter le voleur quand il rentre, surveiller les logs ne permet pas tellement d'agir. On sait juste, après coup, qu'il y a eu effraction. Et c'est déjà trop tard.
5/ Mailer le provider de l'IP
Question subsidiaire: Existe-t-il un moyen d'avoir cette info de façon automatique? Il y a quelque temps, j'avais fait un script permettant de récupérer l'adresse email du FAI à partir d'une IP, mais c'était un peu de la cuisine.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
antoine roy
> 1/ ok déjà fait. su,sudo,sux sont là pour ça
Attention tout de meme avec sudo puisqu'il n'est pas nécessaire d'avoir l e passwd root pour l'utiliser.
il n'y a donc qu'un seul mdp à casser si le user peut faire un "sudo su" ou encore un "sudo vi" etc ..
-- Antoine Roy http://www.fbx.homeunix.com
>
1/ ok déjà fait. su,sudo,sux sont là pour ça
Attention tout de meme avec sudo puisqu'il n'est pas nécessaire d'avoir l e
passwd root pour l'utiliser.
il n'y a donc qu'un seul mdp à casser si le user peut faire un "sudo su"
ou encore un "sudo vi" etc ..
Attention tout de meme avec sudo puisqu'il n'est pas nécessaire d'avoir l e passwd root pour l'utiliser.
il n'y a donc qu'un seul mdp à casser si le user peut faire un "sudo su" ou encore un "sudo vi" etc ..
-- Antoine Roy http://www.fbx.homeunix.com
antoine roy
ils tentent root aussi.
Mar 21 19:51:46 bilbao sshd[89481]: Failed password for root from 200.93.166.173 port 41313 ssh2 Mar 21 19:51:48 bilbao sshd[89483]: Failed password for root from 200.93.166.173 port 41387 ssh2 Mar 21 19:51:51 bilbao sshd[89485]: Failed password for root from 200.93.166.173 port 41467 ssh2
Mar 20 16:50:48 bilbao sshd[85864]: Failed password for root from 208.35.255.125 port 32925 ssh2 Mar 20 16:50:51 bilbao sshd[85866]: Failed password for root from 208.35.255.125 port 33035 ssh2 Mar 20 16:50:53 bilbao sshd[85868]: Failed password for root from 208.35.255.125 port 33150 ssh2
je trouve moi meme des disaines de lignes comme celles ci tous les jours. il n'y a à mon avis pas de quoi s'en inquieter, à moins bien sur que le s passwords soient du style "toto*" :))
la meilleure chose à faire est encore de ne pas autoriser les connections sur le 22 depuis partout .
On Wednesday 23 March 2005 12:51, SULEK Nicolas DSIC BA wrote:
Yves Rutschle a écrit : >On Wed, Mar 23, 2005 at 12:21:02PM +0100, Steve wrote: >>à part de pas donner l'accès root sur >>ton serveur sshd et choisir des bons mots de passe.. > >Pourquoi ne pas donner l'accès à root? Dans la liste de noms >utilisés que tu donnes, root n'est jamais tenté. Donc, il >vaut mieux ouvrir root que andrew ou stan. > >Quand aux mots de passe, à mon avis, si tu veux un semblant >de sécurité, il faut interdire les connections sans clés. > >Y.
interdire l'accès à root directement oblige à casser deux mots de p asse au lieu d'un seul, celui de l'utilisateur pouvant utiliser su et celui de root.
--
Nicolas SULEK
Ministère de l'Intérieur SG/DSIC/SDEL/BA Pôle Architecture Technique
-- Antoine Roy http://www.fbx.homeunix.com
ils tentent root aussi.
Mar 21 19:51:46 bilbao sshd[89481]: Failed password for root from
200.93.166.173 port 41313 ssh2
Mar 21 19:51:48 bilbao sshd[89483]: Failed password for root from
200.93.166.173 port 41387 ssh2
Mar 21 19:51:51 bilbao sshd[89485]: Failed password for root from
200.93.166.173 port 41467 ssh2
Mar 20 16:50:48 bilbao sshd[85864]: Failed password for root from
208.35.255.125 port 32925 ssh2
Mar 20 16:50:51 bilbao sshd[85866]: Failed password for root from
208.35.255.125 port 33035 ssh2
Mar 20 16:50:53 bilbao sshd[85868]: Failed password for root from
208.35.255.125 port 33150 ssh2
je trouve moi meme des disaines de lignes comme celles ci tous les jours.
il n'y a à mon avis pas de quoi s'en inquieter, à moins bien sur que le s
passwords soient du style "toto*" :))
la meilleure chose à faire est encore de ne pas autoriser les connections sur
le 22 depuis partout .
On Wednesday 23 March 2005 12:51, SULEK Nicolas DSIC BA wrote:
Yves Rutschle a écrit :
>On Wed, Mar 23, 2005 at 12:21:02PM +0100, Steve wrote:
>>à part de pas donner l'accès root sur
>>ton serveur sshd et choisir des bons mots de passe..
>
>Pourquoi ne pas donner l'accès à root? Dans la liste de noms
>utilisés que tu donnes, root n'est jamais tenté. Donc, il
>vaut mieux ouvrir root que andrew ou stan.
>
>Quand aux mots de passe, à mon avis, si tu veux un semblant
>de sécurité, il faut interdire les connections sans clés.
>
>Y.
interdire l'accès à root directement oblige à casser deux mots de p asse
au lieu d'un seul, celui de l'utilisateur pouvant utiliser su et celui
de root.
--
Nicolas SULEK
Ministère de l'Intérieur
SG/DSIC/SDEL/BA
Pôle Architecture Technique
Mar 21 19:51:46 bilbao sshd[89481]: Failed password for root from 200.93.166.173 port 41313 ssh2 Mar 21 19:51:48 bilbao sshd[89483]: Failed password for root from 200.93.166.173 port 41387 ssh2 Mar 21 19:51:51 bilbao sshd[89485]: Failed password for root from 200.93.166.173 port 41467 ssh2
Mar 20 16:50:48 bilbao sshd[85864]: Failed password for root from 208.35.255.125 port 32925 ssh2 Mar 20 16:50:51 bilbao sshd[85866]: Failed password for root from 208.35.255.125 port 33035 ssh2 Mar 20 16:50:53 bilbao sshd[85868]: Failed password for root from 208.35.255.125 port 33150 ssh2
je trouve moi meme des disaines de lignes comme celles ci tous les jours. il n'y a à mon avis pas de quoi s'en inquieter, à moins bien sur que le s passwords soient du style "toto*" :))
la meilleure chose à faire est encore de ne pas autoriser les connections sur le 22 depuis partout .
On Wednesday 23 March 2005 12:51, SULEK Nicolas DSIC BA wrote:
Yves Rutschle a écrit : >On Wed, Mar 23, 2005 at 12:21:02PM +0100, Steve wrote: >>à part de pas donner l'accès root sur >>ton serveur sshd et choisir des bons mots de passe.. > >Pourquoi ne pas donner l'accès à root? Dans la liste de noms >utilisés que tu donnes, root n'est jamais tenté. Donc, il >vaut mieux ouvrir root que andrew ou stan. > >Quand aux mots de passe, à mon avis, si tu veux un semblant >de sécurité, il faut interdire les connections sans clés. > >Y.
interdire l'accès à root directement oblige à casser deux mots de p asse au lieu d'un seul, celui de l'utilisateur pouvant utiliser su et celui de root.
--
Nicolas SULEK
Ministère de l'Intérieur SG/DSIC/SDEL/BA Pôle Architecture Technique
-- Antoine Roy http://www.fbx.homeunix.com
Gwendal Demaille
Le mercredi 23 mars 2005, à 13:07:46, antoine roy écrivait :
> > 1/ ok déjà fait. su,sudo,sux sont là pour ça >
Attention tout de meme avec sudo puisqu'il n'est pas nécessaire d'avoir le passwd root pour l'utiliser.
il n'y a donc qu'un seul mdp à casser si le user peut faire un "sudo su" ou encore un "sudo vi" etc ..
info intéressante je ne le savais pas, je n'utilise que les deux autres!
Le mercredi 23 mars 2005, à 13:07:46, antoine roy écrivait :
>
> 1/ ok déjà fait. su,sudo,sux sont là pour ça
>
Attention tout de meme avec sudo puisqu'il n'est pas nécessaire
d'avoir le passwd root pour l'utiliser.
il n'y a donc qu'un seul mdp à casser si le user peut faire un "sudo
su" ou encore un "sudo vi" etc ..
info intéressante
je ne le savais pas, je n'utilise que les deux autres!
Ben tu peu toujour utiliser telnet si ssh n'est pas sur.
Georges
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jean-Marie Fourcade
Bonjour Antoine.
Histoire de ne pas mourir idiot et que je puisse vérifier sur ma machine linux que j'accède via putty en ssh, il est où le fichier log et comment il s'appel ?
Merci.
Le mercredi 23 mars 2005 à 13:03:37, tu écris :
ar> ils tentent root aussi.
ar> Mar 21 19:51:46 bilbao sshd[89481]: Failed password for root from ar> 200.93.166.173 port 41313 ssh2 ar> Mar 21 19:51:48 bilbao sshd[89483]: Failed password for root from ar> 200.93.166.173 port 41387 ssh2 ar> Mar 21 19:51:51 bilbao sshd[89485]: Failed password for root from ar> 200.93.166.173 port 41467 ssh2 ............ Amicalement,
Jean-Marie
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Bonjour Antoine.
Histoire de ne pas mourir idiot et que je puisse vérifier sur ma
machine linux que j'accède via putty en ssh, il est où le fichier log et
comment il s'appel ?
Merci.
Le mercredi 23 mars 2005 à 13:03:37, tu écris :
ar> ils tentent root aussi.
ar> Mar 21 19:51:46 bilbao sshd[89481]: Failed password for root from
ar> 200.93.166.173 port 41313 ssh2
ar> Mar 21 19:51:48 bilbao sshd[89483]: Failed password for root from
ar> 200.93.166.173 port 41387 ssh2
ar> Mar 21 19:51:51 bilbao sshd[89485]: Failed password for root from
ar> 200.93.166.173 port 41467 ssh2
............
Amicalement,
Jean-Marie
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Histoire de ne pas mourir idiot et que je puisse vérifier sur ma machine linux que j'accède via putty en ssh, il est où le fichier log et comment il s'appel ?
Merci.
Le mercredi 23 mars 2005 à 13:03:37, tu écris :
ar> ils tentent root aussi.
ar> Mar 21 19:51:46 bilbao sshd[89481]: Failed password for root from ar> 200.93.166.173 port 41313 ssh2 ar> Mar 21 19:51:48 bilbao sshd[89483]: Failed password for root from ar> 200.93.166.173 port 41387 ssh2 ar> Mar 21 19:51:51 bilbao sshd[89485]: Failed password for root from ar> 200.93.166.173 port 41467 ssh2 ............ Amicalement,
Jean-Marie
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
antoine roy
On Wednesday 23 March 2005 14:01, Jean-Marie Fourcade wrote:
Bonjour Antoine.
Salut .
Histoire de ne pas mourir idiot et que je puisse vérifier sur ma machine linux que j'accède via putty en ssh, il est où le fichier log et comment il s'appel ?
/var/log/auth.log
Merci.
De rien :-)
-- Antoine Roy http://www.fbx.homeunix.com
On Wednesday 23 March 2005 14:01, Jean-Marie Fourcade wrote:
Bonjour Antoine.
Salut .
Histoire de ne pas mourir idiot et que je puisse vérifier sur ma
machine linux que j'accède via putty en ssh, il est où le fichier log et
comment il s'appel ?
On Wednesday 23 March 2005 14:01, Jean-Marie Fourcade wrote:
Bonjour Antoine.
Salut .
Histoire de ne pas mourir idiot et que je puisse vérifier sur ma machine linux que j'accède via putty en ssh, il est où le fichier log et comment il s'appel ?
