J'ai cinq systèmes Linux CentOS 6 au travail et j'ai rencontré un problème assez étrange qui ne semble se produire qu'avec mon ID utilisateur sur tous les systèmes Linux que j'ai ... Ceci est un exemple du problème des entrées que j'ai excepté de la lastcommande .. .
mpenning pts/19 Fri Nov 16 10:32 - 10:35 (00:03)
mpenning pts/17 Fri Nov 16 10:21 - 10:42 (00:21)
bill pts/15 sol-bill.local Fri Nov 16 10:19 - 10:36 (00:16)
mpenning pts/1 192.0.2.91 Fri Nov 16 10:17 - 10:49 (12+00:31)
kkim14 pts/14 192.0.2.225 Thu Nov 15 18:02 - 15:17 (4+21:15)
gduarte pts/10 192.0.2.135 Thu Nov 15 12:33 - 08:10 (11+19:36)
gduarte pts/9 192.0.2.135 Thu Nov 15 12:31 - 08:10 (11+19:38)
kkim14 pts/0 :0.0 Thu Nov 15 12:27 - 15:17 (5+02:49)
gduarte pts/6 192.0.2.135 Thu Nov 15 11:44 - 08:10 (11+20:25)
kkim14 pts/13 192.0.2.225 Thu Nov 15 09:56 - 15:17 (5+05:20)
kkim14 pts/12 192.0.2.225 Thu Nov 15 08:28 - 15:17 (5+06:49)
kkim14 pts/11 192.0.2.225 Thu Nov 15 08:26 - 15:17 (5+06:50)
dspencer pts/8 192.0.2.130 Wed Nov 14 18:24 still logged in
mpenning pts/18 alpha-console-1. Mon Nov 12 14:41 - 14:46 (00:04)Vous pouvez voir deux de mes entrées de connexion pts ci-dessus qui ne sont pas associées à une adresse IP source. Mes machines CentOS ont jusqu'à six autres utilisateurs qui partagent les systèmes. Environ 10% de mes connexions voient ce problème, mais aucun autre nom d'utilisateur ne présente ce comportement . Il n'y a pas d'entrée /var/log/securepour les entrées sans adresse IP source.
Des questions
Compte tenu du type de scripts que je garde sur ces systèmes (qui contrôlent une grande partie de notre infrastructure réseau), je suis un peu effrayé par cela et j'aimerais comprendre ce qui pourrait amener mes connexions à manquer occasionnellement des adresses source.
- Pourquoi
last -is'affiche0.0.0.0pour les entrées de ligne pts (voir également cette réponse ) - Y a-t-il quelque chose (autre qu'une activité malveillante) qui pourrait raisonnablement expliquer le comportement?
- Outre l'horodatage de l'historique bash, puis-je faire d'autres choses pour suivre le problème?
Informatif
Depuis que cela a commencé, j'ai activé l' bashhorodatage de l'historique (c'est- HISTTIMEFORMAT="%y-%m-%d %T "à- dire dans .bash_profile) et j'ai également ajouté quelques autres hacks d'historique bash ; cependant, cela ne donne pas d'indices sur ce qui s'est passé lors des événements précédents.
Tous les systèmes exécutent CentOS 6.3 ...
[mpenning@typo ~]$ uname -a
Linux typo.local 2.6.32-279.9.1.el6.x86_64 #1 SMP Tue Sep 25 21:43:11 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[mpenning@typo ~]$ÉDITER
Si j'utilise last -i mpenning, je vois des entrées comme celle-ci ...
mpenning pts/19 0.0.0.0 Fri Nov 16 10:32 - 10:35 (00:03)
mpenning pts/17 0.0.0.0 Fri Nov 16 10:21 - 10:42 (00:21)Remarque pour ceux qui tentent de répondre: je ne me suis pas connecté avec la screencommande ou l'interface graphique . Toutes mes connexions proviennent de SSH; pour recevoir le prix, vous devez citer des références faisant autorité pour expliquer les last -i 0.0.0.0entrées provenant uniquement via SSH.
EDIT 2 (pour les questions d'ewwhite)
/etc/resolv.conf(notez que j'ai utilisé des .localaddrs dans la lastsortie ci-dessus pour masquer les informations de mon entreprise)
[mpenning@sasmars network]$ cat /etc/resolv.conf
nameserver 192.0.2.40
nameserver 192.0.2.60
domain mycompany.com
search mycompany.com
[mpenning@sasmars network]$/etc/hosts info (notez que ce fichier d'hôtes personnalisé n'existe que sur l'une des machines qui a ces problèmes)
[mpenning@sasmars network]$ cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
192.0.2.44 sasmars.mycompany.com sasmars
::1 localhost6.localdomain6 localhost6
## Temporary kludge until I add reverse hostname mappings...
## Firewalls
192.0.2.254 a2-inet-fw1
192.0.2.253 a2-inet-fw2
192.0.2.254 a2-wan-fw1
192.0.2.253 a2-wan-fw2
192.0.2.201 a2-fab-fw1
192.0.2.202 a2-fab-fw2
192.0.2.203 t1-eds-fw1
192.0.2.42 sasvpn
192.0.2.246 sasasa1
192.0.2.10 sasoutfw1
## Wireless
192.0.2.6 saswcs1
192.0.2.2 l2wlc3
192.0.2.4 l2wlc4
192.0.2.12 f2wlc5
192.0.2.16 f2wlc6
192.0.2.14 f2wlc1
192.0.2.8 f2wlc2
[mpenning@sasmars network]$sftpSortie de /var/log/secure*
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: called (pam_tacplus v1.3.7)
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: user [mpenning] obtained
Dec 26 10:36:37 sasmars sshd[26016]: tacacs_get_password: called
Dec 26 10:36:37 sasmars sshd[26016]: tacacs_get_password: obtained password
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: password obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: tty [ssh] obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: rhost [192.0.2.91] obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: trying srv 0
Dec 26 10:36:38 sasmars sshd[26016]: Accepted password for mpenning from 192.0.2.91 port 55118 ssh2
Dec 26 10:36:38 sasmars sshd[26016]: pam_sm_setcred: called (pam_tacplus v1.3.7)
Dec 26 10:36:38 sasmars sshd[26016]: pam_unix(sshd:session): session opened for user mpenning by (uid=0)
Dec 26 10:36:38 sasmars sshd[26018]: pam_sm_setcred: called (pam_tacplus v1.3.7)
Dec 26 10:36:38 sasmars sshd[26018]: subsystem request for sftp
Dec 26 10:37:20 sasmars sshd[26016]: pam_unix(sshd:session): session closed for user mpenning
Dec 26 10:37:20 sasmars sshd[26016]: pam_sm_setcred: called (pam_tacplus v1.3.7)
last -i mpenningmontre-t-elle les blancs?Réponses:
scriptdifférences de comportement entre RedHat et DebianBibliothèques liées
CentOS 6.3 - script (util-linux-ng 2.17.2)
Ubuntu 12.04 - script (util-linux 2.20.1)
PTY
Base sur le code source en amont ,
scriptdes deux versions ouvrent un nouveau pty. Voici le test.Ubuntu 12.04
Ubuntu 12.04
scripta ouvert un nouveau pts (2). Il n'a tout simplement pas été mis à jour/var/log/wtmp.CentOS 6
Je saute le test car nous savons déjà qu'il
scriptfaut ouvrir pty et s'enregistrer avec wtmp.libutemper
La principale différence semble donc être la bibliothèque supplémentaire (
libutempter.so.0) avec laquelle CentOS estscriptlié.Testez avec Ubuntu 12.04
Compiler
scriptavec libutempterEssai
Avant de courir
scriptDans
scriptAprès la
scriptfinLa cause première du nom d'hôte emtpy
Et oui,
script.ccréez l'wtmpentrée avec un nom d'hôte vide. Regardez le bloc de code suivant dans lautil-linux-2.20.1/term-utils/script.cligne: 245-247Baser sur
libutempter-1.1.5/utempter.hIl en
script.cest de même en passant un nom d'hôte vide dansutempter_add_record.RedHat Backport
La chose intéressante est que l'amont
util-linux-ng-2.17.2ne prend pas en chargelibutempter. Il semble que Redhat ait décidé de rajouter ce soutien.La commande ci-dessus renvoie un résultat vide.
Conclusion
La différence de comportement entre les deux distributions n'est donc pas un bug, mais un choix. RedHat a décidé de prendre en charge cette fonctionnalité, tandis que Debian l'a ignorée.
la source
coreutilsversion rpm utilisée par CentOS 5? Je dois vérifier le code source.libutemptern'est pas lié dans EL4 (vialdd), mais il est lié dans lesscriptcommandes EL5 et EL6 . Cette modification de fonctionnalité a probablement été mise en place pour les systèmes de type Red Hat depuis l'introduction en 2007 de RHEL 5.coreutilssur EL4 est la version 5.2.1. Sur EL5, c'est la version 5.97.scriptest dans util-linux.Cela me semble absolument déroutant. Soit il doit utiliser un nom DNS ou une adresse IP. J'ai également vérifié le
last.cfichier, mais je ne trouve toujours pas pourquoi il ne montre rien. Compte tenu probablement d'un certain temps, je peux comprendre la partie sur 0.0.0.0.Les deux variables globales utilisées dans le contexte sont les suivantes.
Donc, en théorie, il devrait utiliser le DNS ou IP.
Je vais voir si je peux creuser plus loin. Mais ce que ewwhite a demandé sont des questions valables.
la source
J'ai donc couru en dernier dans un débogueur qui, espérons-le, vous donnera au moins quelques réponses à votre question. Mon sentiment est que la cause profonde est plus profonde.
Pourquoi last -i affiche 0.0.0.0 pour les entrées de ligne pts
La meilleure façon d'expliquer cela est ce qui se passe lorsque vous ne réussissez pas -i.
La raison en est dans cette section de code de
last.cLes deux
usednsetuseip(en utilisant les options par défaut) ne sont pas marqués. Cela provoque la logique à copier hors de la structurep->ut_hostqui, selon,man utmpcontient le nom de connexion à distance tel qu'enregistré par tout ce qui a été écrit dans leutmp.Dans votre cas, la valeur ici est des zéros. C'est pourquoi, lorsque vous exécutez,
lastrien ne s'affiche pour vous.Dans ce cas,
last -idns_lookup est invoqué. Cela passera l'entrée (p-> ut_addr_v6) à résoudre via DNS. Dans votre cas, cette valeur contient également des zéros.L'essentiel
dns_lookupest l'habillage de fenêtre et heustérique. Ce qui compte, c'est la fonctiongetnameinfo. Il s'agit d'un appel de bibliothèque qui dans ce cas fera de son mieux pour résoudre la valeur binaire stockée dans leut_addr_v6. Lorsque cette entrée contient des zéros (comme dans votre cas), vous résolvez0.0.0.0en fait ce qui se passe avec votrelast -isortie.Y a-t-il quelque chose (autre qu'une activité malveillante) qui pourrait raisonnablement expliquer le comportement?
Eh bien, c'est probablement un bug ou une erreur. Il est peu probable qu'il soit malveillant, car il semble stupide de laisser une trace en tant qu'attaquant plutôt que d'omettre une adresse source.
Jusqu'à présent, les réponses se sont concentrées sur le mauvais endroit.
lastlit simplementutmpouwtmp. Cependantlastfait de son mieux avec les données dont il dispose.Votre cause profonde se situe quelque part dans la manière d'
utmpécrire !Bien que quelques applications écrivent directement,
utmpje suppose que la source de vos problèmes réside dans la manière desshdgérer la gestion des sessions.Outre l'horodatage de l'historique bash, puis-je faire d'autres choses pour suivre le problème?
utmpn'est généralement pas accessible en écriture et n'est pas censé l'être.utmpest écrit par des applications conçues pour vous connecter et configurer votre session. Dans votre cas, c'est le cassshd.Pourquoi sshd ne gère pas correctement votre utilisateur est très étrange car il devrait être copié correctement dans le nom d'hôte d'où vous venez. C'est là que les efforts de débogage devraient probablement être concentrés. Commencez par ajouter la sortie de débogage de sshd à vos journaux et voyez si quelque chose d'anormal se présente.
Si vous souhaitez contourner le problème (ou, peut-être même éventuellement en savoir plus sur le problème), vous pouvez l'utiliser
pam_lastlogpour le gérerutmpen l'ajoutant à l' entrée de session dans /etc/pam.d/sshd.En fait, cela ne fera pas de mal de vérifier s'il est déjà là - car
pam_lastlogcontient unenohostoption qui expliquerait certainement votre comportement que vous rencontrez.Enfin, vous ne pouviez pas utiliser du tout.
aulastfait le même travail via le sous-système d'audit.Cela pourrait valoir la peine d'essayer de voir si cela a réussi à au moins écrire la bonne adresse. Si ce n'est pas le cas, votre problème doit être avec sshd car sshd transmet les noms DNS autour de différents sous-systèmes comme utmp ou audit.
la source
pam_lastlogcomme mentionné ci-dessus?(1) Base sur la
lastsortie OPAprès vous être connecté via ssh, on peut ssh vers localhost et obtenir 0.0.0.0
last -ipour la dernière.Base sur les quatre premières lignes du journal OP
pts/19la connexion était danspts/17la période de connexion.pts/17la connexion était danspts/1la période de connexion.Pour cette occurrence spécifique, il est logique de deviner que OP ssh de 192.0.2.91 (
pty/1), puis dans cette session ssh, connectez-vous localement (ssh localhost) au serveur à nouveau (pts/17) et à nouveau (pts/19).Veuillez vérifier si ce chevauchement se produit avec une autre occurrence.
Ce qui suit peut aider à identifier la cause
(2) Secnario supplémentaire
Scénario 1 - Sudo et terminal
xhost + localhostsu - UserBousudo su - UserBalors ouvrez un nouveau terminal (xterm, gnome-terminal, etc.)UserBapparaîtra comme 0.0.0.0 danslast -isu - UserBne s'enregistrera pas en tant queUserBlogin en dernier, mais l'ouverture d'un terminal le fera.Scénario 2 - connexion
sudo loginlastetlast -ilastn'afficher aucun nom d'hôte ou IP pour lelogin session.last -iIP 0.0.0.0 pour lelogin session.La réponse de Mife montre déjà un bloc de code de
last.c. La raison pour laquelle lelastnom d'hôte / IP vide est dûut_hostau fait que ces enregistrements sont en fait vides. Pour une structure wtmp complète, faitesman wtmpsur n'importe quel système Linux.Les 2 scénarios ici montrent que même les packages standard, dans certaines situations, les créent en tant que tels.
(3) Bash History Hack
Cela ne fonctionnera que si la session est utilisée
bashcomme shell interactif..bashrcet.bash_profilene sont utilisés que parbash.Ils ne seront pas fournis automatiquement si la session utilise un autre shell (sh, csh, etc.) ou exécute directement un programme, et il n'y aura pas non plus d'historique bash.
(4) Comptabilité des processus
Étant donné que OP ne mentionne rien au sujet du
securefichier, je suppose que c'est une impasse et qu'il fournit actuellement un indice.Si l'hypothèse suivante est correcte
auth.log (debian) / secure (CentOS) n'aidera pas. Comme seule l'action liée à l'authentification y est enregistrée.
wtmp / utmp, avec la limitation de leur structure de données, est également une impasse. Il n'y a aucune information sur ce qui les a créés.
Cela nous laisse avec une option, la comptabilité des processus . C'est un gros pistolet et doit être utilisé avec prudence.
La version du package psacct devrait être 6.3.2-56 ou supérieure, selon cet article .
Si celui-ci doit être utilisé et
/var/logdispose d'un espace limité, remplacez le fichier journal acct par un répertoire (accès root uniquement) sous/home, qui a généralement beaucoup plus d'espace.C'est vraiment le gros canon. Avec un taux d'occurrence de 10% OP, il devrait y avoir un résultat dans la semaine. Si pendant cette période, une entrée vide apparaît
lastmais rien dans le journal des comptes, cela devient une situation mystérieuse et nécessiterait une action drastique .Voici un exemple de sortie de
lastcommVous pouvez également utiliser «dump-acct» pour afficher plus d'informations.
PS1: J'ai essayé d'ouvrir quelques terminaux et session ssh. Il n'est pas clair (ou difficile à cerner) ce qui ouvre un nouveau pts. Cependant, il montre tout ce qui s'est déroulé dans ce pts / session.
PS2: un article de blog sur l'utilisation de acct par un Mike.
la source
ssh localhostet vérifierlast -i.login locally, je veux dire fairessh localhostdans cette session ssh. J'ai modifié cette phrase, j'espère qu'elle est moins déroutante maintenant.Lorsque vous vous connectez à une machine, il peut s'agir de quelques entrées dans la dernière commande.
La première entrée avec tty * apparaît lorsque vous vous connectez via le terminal ou la console en appuyant sur CTRL + ALT + F1-6. C'est assez clair depuis le terminal qu'il utilise.
La deuxième entrée apparaît normalement lorsque vous vous connectez à une machine et ouvrez une fenêtre de terminal dans l'interface graphique. Il y aura également une entrée même si vous ouvrez un nouvel onglet dans la même fenêtre de terminal.
Le troisième type d'entrée survient lorsque vous ouvrez une session d'écran après vous être connecté via SSH. Cela créera également une entrée là-bas et sans aucune adresse IP.
La quatrième entrée est assez normale, ce que tout le monde comprend.
Si vous le faites
last -iavec les entrées suivantes, vous verrez quelque chose comme ceci:Je suis à peu près sûr que votre cas se présente dans l'un des 2 cas, l'un avec la fenêtre du terminal dans l'interface graphique et l'autre avec la session d'écran.
J'espère que cela a aidé.
la source
screenpour aucune des0.0.0.0entrées. Je n'utilise l'interface graphique que lorsque j'ai installé les machines (vers août / septembre). Je vois de nombreuses0.0.0.0entrées pts après cette heure.Je ne pense pas que nous allons aller loin avec cela sans déboguer last.c, mais cela ne devrait pas être trop difficile car il se compile facilement ...
Une possibilité est cependant de vider le fichier / var / log / wtmp à l'aide de la commande utmpdump et de jeter un œil aux enregistrements bruts, cela peut vous éclairer. Sinon, veuillez publier une sortie pertinente de
afin que nous puissions recréer des copies locales de votre wtmp pour déboguer avec
la source
J'ai vérifié sur 12 serveurs d'applications multi-utilisateurs CentOS et RHEL 6.3. Aucun n'a montré ce comportement. Il n'y avait aucune entrée manquante dans la
lastproduction remontant à 4-5 semaines.Je pense qu'il serait important de voir votre
/etc/hostsentrée de fichier pour vous assurer qu'elle est conforme à ce format .Aussi, que faites-vous pour la résolution DNS? Pouvez-vous poster votre
/etc/resolv.conf?Les autres réponses indiquant que
0.0.0.0représente les connexions locales sont correctes. Les exemples typiques sont les événements de redémarrage et de connexion à la console:Étant donné que cela ne semble se produire qu'avec les utilisateurs nommés, y a-t-il un changement, il y a quelque chose de génial à trouver ou à exécuter dans leurs scripts de connexion? Avez-vous changé
~/.bashrcou~/.bash_profilepar défaut? Existe-t-il d'autres scripts de connexion spéciaux dans l'environnement?--Éditer--
Je ne suis toujours pas en mesure de reproduire cela en aucune façon. Je regarde cependant deux composants critiques. La
lastcommande est stable et n'a pas été modifiée depuis longtemps. En regardant le journal des modifications pour sysvinit-tools , il n'y a pas de bogues pertinents. Idem pour les scripts d' initiation (wtmp).Si vous pouvez forcer cela à se produire, essayez-le avec un compte d'utilisateur différent des mêmes machines source. Mais je ne vois aucune indication qu'il s'agit d'un problème de système d'exploitation.
la source
/etc/hosts) devraient affecter tout le monde ... pas juste moilast -ifsur ces deux fichiers et voir si vous voyez les mêmes résultats au fil du temps?/var/log/secure... les entrées qui0.0.0.0montrent ne montrent rien/var/log/secureRÉSOLUTION FINALE
J'ai déjà attribué le bonus, c'est donc uniquement pour les futurs googleurs avec la même question.
La raison pour laquelle cela n'apparaît que dans environ 10% de mes connexions est que lorsque j'apporte des modifications majeures à nos routeurs ou commutateurs, j'utilise
script foo.logdonc j'ai un journal de terminal complet de la modification. Pour des raisons que je ne comprends toujours pas, CentOS crée uneptsentrée lorsque vous utilisez lascriptcommande ... Je vais montrer la sortielast -iavant et après l'exécutionscript...Ce comportement semble être unique à CentOS 6 ... nous avons quelques machines CentOS 4.7 dans le laboratoire qui ne mettent pas d'entrée vide dans
wtmp... Les machines Debian / Gentoo ne présentent pas ce comportement non plus. Nos administrateurs linux se grattent la tête pourquoi CentOS ajouterait intentionnellement une autreptsentrée lorsque vous exécutezscript... Je soupçonne que c'est un bogue RHEL.EDIT : J'ai classé ce problème sous le numéro d'identification de bogue RHEL 892134
REMARQUE
Certaines personnes ont supposé à tort que je mettais
scriptmon~/.bashrcou~/.bash_profile. C'est un argument erroné ... si c'était vrai, monwtmpdevrait avoir une0.0.0.0entrée après chacune de mes connexions ssh ...Bien sûr, ce n'était pas le cas ...
la source
scriptcommande dans votre question initiale.scriptprogramme fait une dactylographie de tout imprimé sur votre terminal. C'est un détail pertinent..bashrcou.bash_profileil ne l'était pas; J'exécutescript foo.loglorsque j'apporte des modifications majeures pour pouvoir avoir un journal des modifications ... c'est-à-dire que cela n'affecte que ~ 10% de mes connexions 2) Si votre accusation est correcte (et ce n'est pas le cas), je n'aurais jamais de connexion ssh qui n'a pas eu une autre0.0.0.0entrée juste après 3)scriptne fait que cela dans CentOS ... Je l'ai utilisé pendant plus d'une décennie et je n'ai jamais vu ce comportement dans une autre distribution ... à ce stade, je soutiens que c'est probablement un CentOS bugscriptne bifurquerai qu'un shell. Sur la base de ce que vous montrez ici, la version CentOS / Redhat descriptfork en fait d'abord un pty. Bien qu'un peu déçu (: P) que ce ne soit pas quelque chose de plus générique / à travers la distribution, au moins le mystère a disparu de mon esprit. PS: Je suis surpris que vous ayez Gentoo en production @. @Les connexions Pseudo Terminal Slave (pts) sont des connexions SSH ou telnet qui signifient des connexions indirectes au système. Toutes ces connexions peuvent se connecter à un shell qui vous permettra d'envoyer des commandes à l'ordinateur. Ainsi, lorsque vous ouvrez un terminal sur votre système à partir de l'interface graphique, cela ouvre un point avec l'ip source 0.0.0.0. D'après les informations fournies par vous, il semble que cela se produise en raison du script exécuté sur ce serveur ou planifié, qui utilise le service ssh ou telnet ou des points locaux pour lancer la sortie dans le terminal.
la source
Quel client ssh utilisez-vous? Certains clients ssh peuvent multiplexer plusieurs terminaux sur une seule connexion et je remarque que toutes vos sessions sans IP se trouvent dans des sessions plus longues qui ont une IP enregistrée.
Je ne peux pas reproduire ce comportement avec ssh ici.
la source
Peut-être que votre adresse IP se résout en une chaîne vide sur l'un de vos serveurs DNS, probablement le secondaire si cela ne se produit que 10% du temps (ou tout simplement un fichier d'hôtes si ceux-ci sont distribués à partir d'un référentiel central). Cela expliquerait l'entrée manquante (ou espace blanc) et serait cohérent avec la lecture de la source par Soham.
la source
"0.0.0.0" signifie qu'il s'agit d'un utilisateur local (pas une connexion à distance), probablement invoqué par l'application, par exemple cronjob.
la source
# last -i |grep 0.0.0.0 \ reboot system boot 0.0.0.0 Wed Dec 5 20:09 - 17:18 (15+21:08) # last |grep reboot \ reboot system boot 2.6.32-10-pve Wed Dec 5 20:09 - 17:18 (15+21:08)Cela se produit parce que vous utilisez le système local et que 0.0.0.0 signifie l'adresse IP de toutes les interfaces. Si vous pensez que quelqu'un a piraté, essayez de configurer la journalisation complète du shell, y compris les commandes via ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/
la source
Je l'ai résolu en ajoutant un script à ~ / .bashrc, le script trouve la dernière adresse IP source de la connexion Telnet, puis vous pouvez ajouter l'IP à un fichier journal ou faire tout ce dont vous avez besoin ..
Sharon
la source
netstat -nae | grep 23n'est pas un moyen utile pour trouver des connexions Telnet. Cette commande donne 92 résultats sur mon système, aucun d'entre eux n'étant telnet.