Ce serveur est-il piraté ou simplement des tentatives de connexion? Voir journal

13

Quelqu'un peut-il dire ce que cela signifie? J'ai essayé une commande comme lastbpour voir les dernières connexions des utilisateurs et je vois des connexions étranges en provenance de Chine (le serveur est UE, je suis en UE). Je me demandais s'il pouvait s'agir de tentatives de connexion ou de connexions réussies?

Ceux-ci semblent être très anciens et généralement je verrouille le port 22 uniquement sur mes IP, je pense que j'ai eu le port ouvert pendant un certain temps, le dernier journal est en juillet.

root     ssh:notty    222.92.89.xx     Sat Jul  9 12:26 - 12:26  (00:00)
root     ssh:notty    222.92.89.xx     Sat Jul  9 12:04 - 12:04  (00:00)
oracle   ssh:notty    222.92.89.xx     Sat Jul  9 11:43 - 11:43  (00:00)
gary     ssh:notty    222.92.89.xx     Sat Jul  9 11:22 - 11:22  (00:00)
root     ssh:notty    222.92.89.xx     Sat Jul  9 11:01 - 11:01  (00:00)
gt05     ssh:notty    222.92.89.xx     Sat Jul  9 10:40 - 10:40  (00:00)
admin    ssh:notty    222.92.89.xx     Sat Jul  9 10:18 - 10:18  (00:00)
adrianTNT
la source
1
Voyez-vous ces noms avec cette adresse IP dans / var / log / auth aussi?
ott--

Réponses:

16

lastbaffiche uniquement les échecs de connexion . Utilisez lastpour voir les connexions réussies.

Michael Hampton
la source
6

Il montre des personnes essayant de télécharger ou de télécharger du contenu. La partie "notty" signifie pas de tty (où tty est l'abréviation de télétype), ce qui signifie de nos jours aucun moniteur ou gui, et le ssh indique le port 22, qui ensemble signifie quelque chose comme scp ou rsync.

Donc pas de piratage ou de tentatives de connexion, mais des mots de passe incorrects ou mal tapés. Il se peut que certains contenus aient été localisés via Google, mais nécessitent un mot de passe que quelqu'un a essayé de deviner.

En fait, à la réflexion, ce qui précède n'est pas juste. Il peut s'agir de tentatives de connexion infructueuses via ssh, comme le suspecte le soupçonnait; et (comme je l'ai raté pour la première fois), ils sont à intervalles réguliers de 21 ou 22 minutes, ce qui suggère un certain degré d'automatisation, mais lastbmontre des échecs par définition, de sorte que ces résultats devraient être comparés lastpour voir si certains ont réussi.

ramruma
la source
3

Fermez le port 22. Configurez votre sshd pour écouter sur un autre port, puis installez et exécutez denyhosts.

tzakuk
la source
2

Pourquoi ne pas utiliser le dernier ?? Veuillez utiliser la commande «last» et recherchez les adresses IP de Chine ou de l'extérieur des États-Unis.

Aussi ... l'homme est ton ami homme lasttb

Lastb est le même que le dernier, sauf que par défaut, il affiche un journal du fichier / var / log / btmp, qui contient toutes les tentatives de connexion incorrectes.

3.14
la source
1

Oui, il s'agit de tentatives de connexion car la même IP a utilisé plusieurs noms d'utilisateur pour tenter d'entrer. Très probablement une attaque de Brute Force.

Pour résoudre ce problème:

Installez Fail2Ban et bloquez les tentatives de connexion ayant échoué avec un -1, ce qui rend leur interdiction permanente.

Ajoutez un fichier de prison pour protéger SSH. Créez un nouveau fichier avec l'éditeur Nano ou vi, vim

nano /etc/fail2ban/jail.d/sshd.local

Au fichier ci-dessus, ajoutez les lignes de code suivantes.

[sshd]

activé = vrai

port = ssh

"#" action = pare-feucmd-ipset

logpath =% (sshd_log) s

maxretry = 5

bantime = -1

Greygan
la source
0

RE: lastb

Les entrées "ssh: notty" / var / log / btmp indiquent l'échec des tentatives de connexion à partir du numéro de port SSH attribué dans "/ etc / ssh / sshd_config".

Pour des raisons de sécurité, le port SSH aura généralement été changé en un nombre autre que "22". Ainsi, "ssh", dans ce contexte, signifie simplement le numéro de port SSH actuellement attribué (non-22).

Comme une négociation réussie de certificat SSH DEVRAIT toujours être nécessaire pour atteindre l'écran de connexion, toutes les entrées de journal "ssh: notty" résultent probablement de vos propres tentatives de connexion infructueuses; généralement à partir d'un nom d'utilisateur mal saisi. Notez l'adresse IP associée à l'entrée de journal ... c'est probablement la vôtre!

"notty" signifie "no tty".

Apprenez la sécurité de base, comment cela fonctionne, où se trouvent les journaux et comment les interpréter, où se trouvent les différents fichiers de configuration et ce que signifient les directives, et comment configurer IPTables, avant d'installer et d'utiliser un serveur Linux. Limitez les connexions à une "adresse IP statique" et limitez les tentatives de connexion / restrick:

Directives de configuration SSH de BASE qui restreignent les connexions et autorisent uniquement les connexions d'utilisateurs et d'adresses IP particuliers:

LoginGraceTime 30
MaxStartups 3:50:10
MaxAuthTries 4
PermitRootLogin no
AllowUsers YourUserName@YourIPAddress
PubkeyAuthentication yes
AuthorizedKeysFile   %h/.ssh/authorized_keys
PasswordAuthentication no

N'oubliez pas de "redémarrer" le service SSH après la modification.

Règles IPTables de base qui autorisent uniquement les connexions SSH à partir d'une adresse IP statique particulière:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW                                 -j DROP
-A INPUT -m state --state INVALID -j DROP
-A INPUT -f -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j DROP
-A INPUT -p tcp -m tcp --tcp-flags PSH,ACK PSH -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags ACK,URG URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp -s YourStaticIPAddress -m multiport --dports SSHPortNumber -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j DROP
COMMIT

N'oubliez pas de "restaurer" les tables IP après les modifications.

Sur un LAN, ou dans un environnement cloud "hébergé", n'oubliez pas de sécuriser le côté "privé" (carte réseau). Vos ennemis ont souvent déjà accès à votre réseau et entrent par la porte arrière.

Si vous êtes dans un environnement cloud tel que RackSpace ou DigitalOcean, et que vous bloquez les configurations et vous verrouillez, vous pouvez toujours accéder à la console et y remédier. FAITES TOUJOURS DES COPIES DES FICHIERS DE CONFIGURATION AVANT DE LES MODIFIER !!!

SandPond
la source