Ubuntu-fr

jeremydu80

Re : Possible backdoor server

Et j'oubliais les trois fichiers éminemment suspects sous /usr/bin :

-rwxr-xr-x 1 root   root      625889 oct.  22 12:02  mtxvteicdv
-rwxr-xr-x 1 root   root      625878 oct.  20 00:12  mvvvotwked
-rwxr-xr-x 1 root   root      225280 oct.  20 00:09  nesyavrpah

Il y en a d'autres:

-rwxr-xr-x 1 root   root      625889 oct.  21 11:56  byfhwslwbi
-rwxr-xr-x 1 root   root      625878 oct.  19 23:26  kjlniiluhc

La compromission ne fait plus aucun doute vu les rapports virustotal.

je vais détruire la machine vous voulais un Access au pire ?
j'ai vue sur virustotal que clamav detecté les virus je lance une installation de celui si sur la machine et je lance un scan voir su je peux avoir d'autres informations

Dernière modification par jeremydu80 (Le 22/10/2022, à 13:32)

bruno

Re : Possible backdoor server

L'installation de cette seedbox je l'utilise sur des dizaines de serveurs sans jamais avoie eu aucun problème justement

Sans avoir remarqué un problème.

Le mot de passe était sécurisée 16 Caractére avec des &é"((-è

Quel mot de passe ? De quel utilisateur, pour accéder à quoi ? Et c'est la longueur de mut de passe qui est prépondérante sur l'utilisation de caractères non alphanumériques.

Vu les symptômes, il y a bien eu un accès root à ton serveur et cet accès a très probablement été obtenu via SSH.

matrix-bx

Re : Possible backdoor server

je vais détruire la machine vous voulais un Access au pire ?

Lol, pourquoi pas après tout.

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM364Rdcf0u/S0+737e0WSNQUv1Un/gPOLNzsZ+Scspv matrix-bx

---

Utilisations des balises de mises en formes.

jeremydu80

Re : Possible backdoor server

L'installation de cette seedbox je l'utilise sur des dizaines de serveurs sans jamais avoie eu aucun problème justement

Sans avoir remarqué un problème.

Le mot de passe était sécurisée 16 Caractére avec des &é"((-è

Quel mot de passe ? De quel utilisateur, pour accéder à quoi ? Et c'est la longueur de mut de passe qui est prépondérante sur l'utilisation de caractères non alphanumériques.

Vu les symptômes, il y a bien eu un accès root à ton serveur et cet accès a très probablement été obtenu via SSH.
J'ai déjà eu le cas de personnes qui m'affirmait que tous les comptes étaient hyper sécurisés et qui avaient oublié qu'il avaient un moment do

le compte root et accessible oui ( je sais pas conseiller ) mais ce que je comprend pas je travail que en local donc le serveur ne doit pas etre accecible  en ssh depuis l'extérieur je me connecte en SSH avec mon ip local

jeremydu80

Re : Possible backdoor server

je vais détruire la machine vous voulais un Access au pire ?

Lol, pourquoi pas après tout.

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM364Rdcf0u/S0+737e0WSNQUv1Un/gPOLNzsZ+Scspv matrix-bx

bon tu vas rire hein mais je sais pas ou mettre ce truc moi mdr je met ca ou ?

bruno

Re : Possible backdoor server

mais ce que je comprend pas je travail que en local donc le serveur ne doit pas etre accecible  en ssh depuis l'extérieur je me connecte en SSH avec mon ip local

En es-tu bien sûr ?
On peut tester ton IP publique si tu veux

jeremydu80

Re : Possible backdoor server

mais ce que je comprend pas je travail que en local donc le serveur ne doit pas etre accecible  en ssh depuis l'extérieur je me connecte en SSH avec mon ip local

En es-tu bien sûr ?
On peut tester ton IP publique si tu veux

ci tu veux avec plaisir je t'envoie ca ou ?

jeremydu80

Re : Possible backdoor server

root@ubuntu:~# tail -f /var/log/resul_freshclam.txt
Sat Oct 22 14:36:31 2022 -> *Current working dir is /var/lib/clamav/
Sat Oct 22 14:36:31 2022 -> *check_for_new_database_version: Local copy of main found: main.cvd.
Sat Oct 22 14:36:31 2022 -> *query_remote_database_version: main.cvd version from DNS: 62
Sat Oct 22 14:36:31 2022 -> main.cvd database is up-to-date (version: 62, sigs: 6647427, f-level: 90, builder: sigmgr)
Sat Oct 22 14:36:31 2022 -> *fc_update_database: main.cvd already up-to-date.
Sat Oct 22 14:36:31 2022 -> *Current working dir is /var/lib/clamav/
Sat Oct 22 14:36:31 2022 -> *check_for_new_database_version: Local copy of bytecode found: bytecode.cvd.
Sat Oct 22 14:36:31 2022 -> *query_remote_database_version: bytecode.cvd version from DNS: 333
Sat Oct 22 14:36:31 2022 -> bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2)
Sat Oct 22 14:36:31 2022 -> *fc_update_database: bytecode.cvd already up-to-date.

-------------------------------------------------------------------------------

/usr/bin/x86_64-linux-gnu-gcov-tool: Symbolic link
/usr/bin/iptables-xml: Symbolic link
/usr/bin/infobrowser: Symbolic link
/usr/bin/atrm: Symbolic link
/usr/bin/col3: Symbolic link
/usr/bin/lzless: Symbolic link
/usr/bin/ftp: Symbolic link
/usr/bin/on_ac_power: Symbolic link
/usr/bin/strip: Symbolic link
/usr/bin/which: Symbolic link
/usr/bin/x86_64-linux-gnu-g++: Symbolic link
/usr/bin/run-one-until-success: Symbolic link
/usr/bin/pinentry: Symbolic link
/usr/bin/python3: Symbolic link
/usr/bin/psfaddtable: Symbolic link
/usr/bin/objcopy: Symbolic link
/usr/bin/mcview: Symbolic link
/usr/bin/gcc-nm-9: Symbolic link
/usr/bin/snice: Symbolic link
/usr/bin/x86_64-linux-gnu-gcc-ar: Symbolic link
/usr/bin/gtbl: Symbolic link
/usr/bin/gpic: Symbolic link
/usr/bin/paplay: Symbolic link
/usr/bin/pdb3: Symbolic link
/usr/bin/edit: Symbolic link
/usr/bin/lzfgrep: Symbolic link
/usr/bin/tclsh: Symbolic link
/usr/bin/size: Symbolic link
/usr/bin/x-window-manager: Symbolic link
/usr/bin/pdb3.8: Symbolic link
/usr/bin/fwupdagent: Symbolic link
/usr/bin/telnet: Symbolic link
/usr/bin/c99: Symbolic link
/usr/bin/c++: Symbolic link
/usr/bin/cpp-9: Symbolic link
/usr/bin/reset: Symbolic link
/usr/bin/g++: Symbolic link
/usr/bin/ginstall-info: Symbolic link
/usr/bin/ubuntu-bug: Symbolic link
/usr/bin/print: Symbolic link
/usr/bin/pbget: Symbolic link
/usr/bin/x-terminal-emulator: Symbolic link
/usr/bin/write: Symbolic link
/usr/bin/unxz: Symbolic link
/usr/bin/X: Symbolic link
/usr/bin/cc: Symbolic link
/usr/bin/lzegrep: Symbolic link
/usr/bin/ua: Symbolic link
/usr/bin/dwp: Symbolic link
/usr/bin/vi: Symbolic link
/usr/bin/xzegrep: Symbolic link
/usr/bin/pico: Symbolic link
/usr/bin/lzcat: Symbolic link
/usr/bin/gcov-dump-9: Symbolic link
/usr/bin/infotocap: Symbolic link
/usr/bin/pydoc3: Symbolic link
/usr/bin/rrsync: Symbolic link
/usr/bin/x-session-manager: Symbolic link
/usr/bin/vimdiff: Symbolic link
/usr/bin/python2: Symbolic link
/usr/bin/c89: Symbolic link
/usr/bin/ranlib: Symbolic link
/usr/bin/gcc-ranlib-9: Symbolic link
/usr/bin/xzcmp: Symbolic link
/usr/bin/c++filt: Symbolic link
/usr/bin/GET: Symbolic link
/usr/bin/strings: Symbolic link
/usr/bin/pyversions: Symbolic link
/usr/bin/run-one-constantly: Symbolic link
/usr/bin/pdb2: Symbolic link
/usr/bin/gcov-9: Symbolic link
/usr/bin/unlzma: Symbolic link
/usr/bin/gcc-9: Symbolic link
/usr/bin/dumpkeys: Symbolic link
/usr/bin/geqn: Symbolic link
/usr/bin/rview: Symbolic link
/usr/bin/lz4cat: Symbolic link
/usr/bin/pygettext2: Symbolic link
/usr/bin/git-upload-pack: Symbolic link
/usr/bin/linux64: Symbolic link
/usr/bin/editor: Symbolic link
/usr/bin/gio-querymodules: Symbolic link
/usr/bin/atq: Symbolic link
/usr/bin/gcc-ranlib: Symbolic link
/usr/bin/unattended-upgrades: Symbolic link
/usr/bin/ld.bfd: Symbolic link
/usr/bin/fakeroot: Symbolic link
/usr/bin/lz4c: Symbolic link
/usr/bin/xzcat: Symbolic link
/usr/bin/col9: Symbolic link
/usr/bin/pdb3.6: Symbolic link
/usr/bin/ld.gold: Symbolic link
/usr/bin/diypseyypw: Unix.Malware.Xorddos-9856891-0 FOUND
/usr/bin/compose: Symbolic link
/usr/bin/col8: Symbolic link
/usr/bin/rtstat: Symbolic link
/usr/bin/col4: Symbolic link
/usr/bin/x86_64-linux-gnu-cpp: Symbolic link
/usr/bin/ctstat: Symbolic link
/usr/bin/lessfile: Symbolic link
/usr/bin/pbputs: Symbolic link
/usr/bin/mcdiff: Symbolic link
/usr/bin/xzfgrep: Symbolic link
/usr/bin/x86_64: Symbolic link
/usr/bin/gcc-ar: Symbolic link
/usr/bin/xfrun4: Symbolic link
/usr/bin/locate: Symbolic link
/usr/bin/linux32: Symbolic link
/usr/bin/grub-ntldr-img: Symbolic link
/usr/bin/ld: Symbolic link
/usr/bin/slogin: Symbolic link
/usr/bin/elfedit: Symbolic link
/usr/bin/gcc-nm-7: Symbolic link
/usr/bin/git-receive-pack: Symbolic link
/usr/bin/pdb2.7: Symbolic link
/usr/bin/awk: Symbolic link
/usr/bin/x86_64-linux-gnu-gcc-ranlib: Symbolic link
/usr/bin/ex: Symbolic link
/usr/bin/run-this-one: Symbolic link
/usr/bin/snapctl: Symbolic link
/usr/bin/getfacl: Symbolic link
/usr/bin/gnome-help: Symbolic link
/usr/bin/gcc-nm: Symbolic link
/usr/bin/gcc-7: Symbolic link
/usr/bin/as: Symbolic link
/usr/bin/mcedit: Symbolic link
/usr/bin/gcov-tool-7: Symbolic link
/usr/bin/py3versions: Symbolic link
/usr/bin/chardet3: Symbolic link
/usr/bin/apt-add-repository: Symbolic link
/usr/bin/psfgettable: Symbolic link
/usr/bin/setfacl: Symbolic link
/usr/bin/cpp-7: Symbolic link
/usr/bin/systemd-resolve: Symbolic link
/usr/bin/parec: Symbolic link
/usr/bin/gpg2: Symbolic link
/usr/bin/keep-one-running: Symbolic link
/usr/bin/gprof: Symbolic link
/usr/bin/lzdiff: Symbolic link
/usr/bin/cal: Symbolic link
/usr/bin/see: Symbolic link
/usr/bin/pygettext3: Symbolic link
/usr/bin/pstree.x11: Symbolic link
/usr/bin/rcp: Symbolic link
/usr/bin/lzma: Symbolic link
/usr/bin/gcov-tool: Symbolic link
/usr/bin/pamon: Symbolic link
/usr/bin/x86_64-linux-gnu-ld: Symbolic link
/usr/bin/unlz4: Symbolic link
/usr/bin/vim: Symbolic link
/usr/bin/captoinfo: Symbolic link
/usr/bin/HEAD: Symbolic link
/usr/bin/desktop-file-edit: Symbolic link
/usr/bin/glib-compile-schemas: Symbolic link
/usr/bin/gcc-ar-9: Symbolic link
/usr/bin/pro: Symbolic link
/usr/bin/from: Symbolic link
/usr/bin/touch: Symbolic link
/usr/bin/cpp: Symbolic link
/usr/bin/ar: Symbolic link
/usr/bin/nm: Symbolic link
/usr/bin/run-one-until-failure: Symbolic link
/usr/bin/apport-collect: Symbolic link
/usr/bin/g++-9: Symbolic link
/usr/bin/nawk: Symbolic link
/usr/bin/col7: Symbolic link
/usr/bin/gcov-7: Symbolic link
/usr/bin/x86_64-linux-gnu-gold: Symbolic link
/usr/bin/objdump: Symbolic link
/usr/bin/NF: Symbolic link
/usr/bin/X11: Symbolic link
/usr/bin/traceroute6: Symbolic link
/usr/bin/gcov-dump-7: Symbolic link
/usr/bin/md5sum.textutils: Symbolic link
/usr/bin/atopsar: Symbolic link
/usr/bin/pager: Symbolic link
/usr/bin/gcc-ranlib-7: Symbolic link
/usr/bin/git-upload-archive: Symbolic link
/usr/bin/updatedb: Symbolic link
/usr/bin/byobu-tmux: Symbolic link
/usr/bin/byobu-screen: Symbolic link
/usr/bin/i386: Symbolic link
/usr/bin/apropos: Symbolic link
/usr/bin/psfstriptable: Symbolic link
/usr/bin/rlogin: Symbolic link
/usr/bin/w: Symbolic link
/usr/bin/iscsiadm: Symbolic link
/usr/bin/sudoedit: Symbolic link
/usr/bin/gold: Symbolic link
/usr/bin/gcov-dump: Symbolic link
/usr/bin/pftp: Symbolic link
/usr/bin/rvim: Symbolic link
/usr/bin/lastb: Symbolic link
/usr/bin/python: Symbolic link
/usr/bin/gcov: Symbolic link
/usr/bin/POST: Symbolic link
/usr/bin/col2: Symbolic link
/usr/bin/gcc: Symbolic link
/usr/bin/distro-info: Symbolic link
/usr/bin/col6: Symbolic link
/usr/bin/x86_64-linux-gnu-gcc: Symbolic link
/usr/bin/view: Symbolic link
/usr/bin/hd: Symbolic link
/usr/bin/parecord: Symbolic link
/usr/bin/gcov-tool-9: Symbolic link
/usr/bin/pydoc2: Symbolic link
/usr/bin/lzgrep: Symbolic link
/usr/bin/ubuntu-core-launcher: Symbolic link
/usr/bin/lzmore: Symbolic link
/usr/bin/chacl: Symbolic link
/usr/bin/x86_64-linux-gnu-gcov: Symbolic link
/usr/bin/x86_64-linux-gnu-gcov-dump: Symbolic link
/usr/bin/systemd-umount: Symbolic link
/usr/bin/rsh: Symbolic link
/usr/bin/browse: Symbolic link
/usr/bin/gcc-ar-7: Symbolic link
/usr/bin/loadkeys: Symbolic link
/usr/bin/pkill: Symbolic link
/usr/bin/col5: Symbolic link
/usr/bin/sg: Symbolic link
/usr/bin/addr2line: Symbolic link
/usr/bin/Thunar: Symbolic link
/usr/bin/readelf: Symbolic link
/usr/bin/x86_64-linux-gnu-gcc-nm: Symbolic link
/usr/bin/lzcmp: Symbolic link

----------- SCAN SUMMARY -----------
Known viruses: 8640823
Engine version: 0.103.6
Scanned directories: 1
Scanned files: 1022
Infected files: 1
Data scanned: 148.39 MB
Data read: 147.79 MB (ratio 1.00:1)
Time: 220.471 sec (3 m 40 s)
Start Date: 2022:10:22 14:42:18
End Date:   2022:10:22 14:45:58

matrix-bx

Re : Possible backdoor server

bon tu vas rire hein mais je sais pas ou mettre ce truc moi mdr je met ca ou ?

lol, tu peux l'ajouter dans /root/.ssh/authorized_keys par exemple

---

Utilisations des balises de mises en formes.

iznobe

Re : Possible backdoor server

Bonjour , je suis pas du tout de la partie , mais une suggestion en passant vite fait :
avec netstat , on peut voir les connections , je suppose qu ' on peut aussi voir vers où vont tous les paquets en upload , mais je ne sais pas comment faire .
si toutefois ca peut aider .

---

retour COMPLET et utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .

jeremydu80

Re : Possible backdoor server

bon tu vas rire hein mais je sais pas ou mettre ce truc moi mdr je met ca ou ?

lol, tu peux l'ajouter dans /root/.ssh/authorized_keys par exemple

jeremydu80

Re : Possible backdoor server

Bonjour , je suis pas du tout de la partie , mais une suggestion en passant vite fait :
avec netstat , on peut voir les connections , je suppose qu ' on peut aussi voir vers où vont tous les paquets en upload , mais je ne sais pas comment faire .
si toutefois ca peut aider .

Bonjour iznobe,
la première choses que j'ai pensé avec un iftop tu peux justement voir plus facilement ce qu'il ce passe et ou vas le trafic d'où j'ai obtenue la plage IP qui réceptionner ( je sais toujours pas quoi d'ailleurs ce serveur n'a que des films )

matrix-bx

Re : Possible backdoor server

il faut probablement que tu crées le répertoire /root/.ssh puis le fichier /root/.ssh/authorized_keys avant d'y rajouter la clef

ss -tunp le permet également

Dernière modification par matrix-bx (Le 22/10/2022, à 14:09)

---

Utilisations des balises de mises en formes.

bruno

Re : Possible backdoor server

@iznobe : cela ne servirait a rien. Il a été clairement établi que le serveur a été compromis et qu'il contient au moins un logiciel malveillant de type XOR DDOS (utilisé par un botnet). On a également vu que le serveur envoyait des données vers un gros hébergeur cloud (plage IP repérée par @jeremydu80 ).

La seule chose utile maintenant serait de savoir comment la machine a été compromise afin que @jeremydu80 ne reproduise pas la même erreur. Il ferait bien d'ailleurs de s'assurer que le reste de son infrastructure est saine.

Je laisse @matrix-bx s'amuser à essayer de trouver une réponse en se connectant au serveur.

Dernière modification par bruno (Le 22/10/2022, à 14:11)

matrix-bx

Re : Possible backdoor server

La seule chose utile maintenant serait de savoir comment la machine a été compromise afin que @jeremydu80 ne reproduise pas la même erreur. Il ferait bien d'ailleurs de s'assurer que le reste de son infrastructure est saine.

Je laisse @matrix-bx s'amuser à essayer de trouver une réponse en se connectant au serveur.

Je suis parfaitement en accord avec les remarques exprimées.
Allez ! Viens jouer avec nous

---

Utilisations des balises de mises en formes.

jeremydu80

Re : Possible backdoor server

il faut probablement que tu crées le répertoire /root/.ssh puis le fichier /root/.ssh/authorized_keys avant d'y rajouter la clef

ss -tunp le permet également

root@ubuntu:~# ss -tunp
Netid       State       Recv-Q       Send-Q             Local Address:Port               Peer Address:Port       Process
tcp         ESTAB       0            0                   192.168.1.14:22                192.168.1.139:59883       users:(("sshd",pid=5914,fd=4))
tcp         ESTAB       0            0                   192.168.1.14:22                192.168.1.139:49924       users:(("sshd",pid=24219,fd=4))
tcp         ESTAB       0            0                   192.168.1.14:22                192.168.1.139:61521       users:(("sshd",pid=7757,fd=4))

tcp         ESTAB       0            0                   192.168.1.14:49260               172.xx.xx.:23          users:(("diypseyypw",pid=11042,fd=3))
eux ta commande me donne ca que je ne connais pas c'est en temps réelle cette commande ? jai caché une parti de l'ip l'utilisateur diypseyypw ne ne connais pas non plus
ps : j'ouvre le port 22 ta besoin de mon IP ?

tcp         ESTAB       0            0                   192.168.1.14:22                192.168.1.139:64968       users:(("sshd",pid=20199,fd=4))

Dernière modification par jeremydu80 (Le 22/10/2022, à 14:29)

jeremydu80

Re : Possible backdoor server

@iznobe : cela ne servirait a rien. Il a été clairement établi que le serveur a été compromis et qu'il contient au moins un logiciel malveillant de type XOR DDOS (utilisé par un botnet). On a également vu que le serveur envoyait des données vers un gros hébergeur cloud (plage IP repérée par @jeremydu80 ).

La seule chose utile maintenant serait de savoir comment la machine a été compromise afin que @jeremydu80 ne reproduise pas la même erreur. Il ferait bien d'ailleurs de s'assurer que le reste de son infrastructure est saine.

Je laisse @matrix-bx s'amuser à essayer de trouver une réponse en se connectant au serveur.

ci ca peut permettre a d'autres de ne pas reproduire mes erreurs par la suite pourquoi pas

iznobe

Re : Possible backdoor server

Bonjour , je suis pas du tout de la partie , mais une suggestion en passant vite fait :
avec netstat , on peut voir les connections , je suppose qu ' on peut aussi voir vers où vont tous les paquets en upload , mais je ne sais pas comment faire .
si toutefois ca peut aider .

Bonjour iznobe,
la première choses que j'ai pensé avec un iftop tu peux justement voir plus facilement ce qu'il ce passe et ou vas le trafic d'où j'ai obtenue la plage IP qui réceptionner ( je sais toujours pas quoi d'ailleurs ce serveur n'a que des films )

Dans ce cas , peut etre qu ' une solution serait d' utiliser les fichiers host/deny et de blacklister le serveur tout simplement par son adesse ip ? en attendant de trouver d' ou provient le probleme et comment le serveur a été compromis ...

Dernière modification par iznobe (Le 22/10/2022, à 14:30)

---

retour COMPLET et utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .

jeremydu80

Re : Possible backdoor server

La seule chose utile maintenant serait de savoir comment la machine a été compromise afin que @jeremydu80 ne reproduise pas la même erreur. Il ferait bien d'ailleurs de s'assurer que le reste de son infrastructure est saine.

Je laisse @matrix-bx s'amuser à essayer de trouver une réponse en se connectant au serveur.

Je suis parfaitement en accord avec les remarques exprimées.
Allez ! Viens jouer avec nous

Si tu veux jouer avec nous a chercher viens, il y a pas de limite de temps j'ai booter le disque sur un serveur que j'utilise pas

Dernière modification par jeremydu80 (Le 22/10/2022, à 14:31)

matrix-bx

Re : Possible backdoor server

il faut probablement que tu crées le répertoire /root/.ssh puis le fichier /root/.ssh/authorized_keys avant d'y rajouter la clef

ss -tunp le permet également

root@ubuntu:~# ss -tunp
Netid       State       Recv-Q       Send-Q             Local Address:Port               Peer Address:Port       Process
tcp         ESTAB       0            0                   192.168.1.14:22                192.168.1.139:59883       users:(("sshd",pid=5914,fd=4))
tcp         ESTAB       0            0                   192.168.1.14:22                192.168.1.139:49924       users:(("sshd",pid=24219,fd=4))
tcp         ESTAB       0            0                   192.168.1.14:22                192.168.1.139:61521       users:(("sshd",pid=7757,fd=4))

tcp         ESTAB       0            0                   192.168.1.14:49260               172.xx.xx.:23          users:(("diypseyypw",pid=11042,fd=3))
eux ta commande me donne ca que je ne connais pas c'est en temps réelle cette commande ? jai caché une parti de l'ip
ps : j'ouvre le port 22 ta besoin de l'ip ?

tcp         ESTAB       0            0                   192.168.1.14:22                192.168.1.139:64968       users:(("sshd",pid=20199,fd=4))

Non, tu l'as déjà donnée précédemment (avec ss -tunlp), le port 22 était déjà ouvert, je suis connecté.

---

Utilisations des balises de mises en formes.

jeremydu80

Re : Possible backdoor server

il faut probablement que tu crées le répertoire /root/.ssh puis le fichier /root/.ssh/authorized_keys avant d'y rajouter la clef

ss -tunp le permet également

root@ubuntu:~# ss -tunp
Netid       State       Recv-Q       Send-Q             Local Address:Port               Peer Address:Port       Process
tcp         ESTAB       0            0                   192.168.1.14:22                192.168.1.139:59883       users:(("sshd",pid=5914,fd=4))
tcp         ESTAB       0            0                   192.168.1.14:22                192.168.1.139:49924       users:(("sshd",pid=24219,fd=4))
tcp         ESTAB       0            0                   192.168.1.14:22                192.168.1.139:61521       users:(("sshd",pid=7757,fd=4))

tcp         ESTAB       0            0                   192.168.1.14:49260               172.xx.xx.:23          users:(("diypseyypw",pid=11042,fd=3))
eux ta commande me donne ca que je ne connais pas c'est en temps réelle cette commande ? jai caché une parti de l'ip
ps : j'ouvre le port 22 ta besoin de l'ip ?

tcp         ESTAB       0            0                   192.168.1.14:22                192.168.1.139:64968       users:(("sshd",pid=20199,fd=4))

Non, tu l'as déjà donnée précédemment (avec ss -tunlp), le port 22 était déjà ouvert, je suis connecté.

Parfait je te laisse t'amusée alors essaye de regardée qui et cette utilisateur que je ne connais pas : diypseyypw

Dernière modification par jeremydu80 (Le 22/10/2022, à 14:40)

jeremydu80

Re : Possible backdoor server

@iznobe : cela ne servirait a rien. Il a été clairement établi que le serveur a été compromis et qu'il contient au moins un logiciel malveillant de type XOR DDOS (utilisé par un botnet). On a également vu que le serveur envoyait des données vers un gros hébergeur cloud (plage IP repérée par @jeremydu80 ).

La seule chose utile maintenant serait de savoir comment la machine a été compromise afin que @jeremydu80 ne reproduise pas la même erreur. Il ferait bien d'ailleurs de s'assurer que le reste de son infrastructure est saine.

Je laisse @matrix-bx s'amuser à essayer de trouver une réponse en se connectant au serveur.

Vérifié tout mon infrastructure risque de prendre du temps pour le coup les Synology je m'inquiète pas trop et les serveur maitre sont en production donc impossible de vérifié en journée

matrix-bx

Re : Possible backdoor server

Compromission du compte root par ssh depuis la Chine.

root@ubuntu:~# zgrep ssh /var/log/auth.log* | grep -i -E "accepted password for root" | grep -c -v -E "$TONLOGIN|192.168."
2
root@ubuntu:~# zgrep ssh /var/log/auth.log* | grep -i -E "accepted password for root" | grep -v -E "$TONLOGIN|192.168." | cut -d ":" -f2,3
Sep 24 19:19
Sep 24 19:19
root@ubuntu:~# for ip in $(zgrep ssh /var/log/auth.log* | grep -i -E "accepted password for root" | grep -v -E "$TONLOGIN|192.168." |cut -d" " -f11); do whois $ip |head -20 | grep -E "inetnum|netname|country"; done
inetnum:        61.177.0.0 - 61.177.255.255 <====== la ça brute force
netname:        CHINANET-JS
country:        CN
inetnum:        218.90.0.0 - 218.94.255.255 <====== la une seule connexion pour confirmer et exploiter probablement.
netname:        CHINANET-JS
country:        CN
root@ubuntu:~#

Le mot de passe était sécurisée 16 Caractére avec des &é"((-è

Celui de ton user ou celui de root ?

Config sshd défaillante.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
PermitRootLogin yes
#PasswordAuthentication yes

Je préfère et de très loin :

PasswordAuthentication no
PermitRootLogin no # ou prohibit-password
Port xxxx # éventuellement car moins visible donc moins sollicité.
AllowUsers user1 user2

Si besoin particulier, on peux quand même faire

match user user1
PasswordAuthentication yes

Et si c'est pour un usage strictement local, sshd n'a pas a écouter sur 0.0.0.0 et ::

Il y avait un fail2ban, il a été désinstallé.

Start-Date: 2022-10-20  00:20:01
Commandline: apt remove fail2ban
Remove: fail2ban:amd64 (0.10.2-2)
End-Date: 2022-10-20  00:20:16

Et n'avait été installé que juste avant l'incident.

Start-Date: 2022-09-21  23:22:32
Commandline: apt-get install -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold -y fail2ban

Et avait réussi à bloquer l'attaquant 20 fois.

root@ubuntu:~# zgrep ssh /var/log/fail2ban* | grep -i -E "$IP_Chinoise_1" | grep -c Ban 
20
root@ubuntu:~#

Parfait je te laisse t'amusée alors essaye de regardée qui et cette utilisateur que je ne connais pas : diypseyypw

C'est pas un user mais juste le nom du binaire.

root@ubuntu:~# grep diypseyypw /etc/passwd || echo user inconnu
user inconnu
root@ubuntu:~# which diypseyypw
/usr/bin/diypseyypw
root@ubuntu:~#

Je te laisse le soins de corriger ce qui doit l'être ou mieux encore ré installer pour plus de sérénité.
J'ai supprimé ma clef de /root/.ssh/authorized_keys.

Dernière modification par matrix-bx (Le 22/10/2022, à 16:17)

---

Utilisations des balises de mises en formes.

jeremydu80

Re : Possible backdoor server

Compromission du compte root par ssh depuis la Chine.

root@ubuntu:~# zgrep ssh /var/log/auth.log* | grep -i -E "accepted password for root" | grep -c -v -E "$TONLOGIN|192.168."
2
root@ubuntu:~# zgrep ssh /var/log/auth.log* | grep -i -E "accepted password for root" | grep -v -E "$TONLOGIN|192.168." | cut -d ":" -f2,3
Sep 24 19:19
Sep 24 19:19
root@ubuntu:~# for ip in $(zgrep ssh /var/log/auth.log* | grep -i -E "accepted password for root" | grep -v -E "$TONLOGIN|192.168." |cut -d" " -f11); do whois $ip |head -20 | grep -E "inetnum|netname|country"; done
inetnum:        61.177.0.0 - 61.177.255.255 <====== la ça brute force
netname:        CHINANET-JS
country:        CN
inetnum:        218.90.0.0 - 218.94.255.255 <====== la une seule connexion pour confirmer et exploiter probablement.
netname:        CHINANET-JS
country:        CN
root@ubuntu:~#

Le mot de passe était sécurisée 16 Caractére avec des &é"((-è

Celui de ton user ou celui de root ?

Config sshd défaillante.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
PermitRootLogin yes
#PasswordAuthentication yes

Je préfère et de très loin :

PasswordAuthentication no
PermitRootLogin no # ou prohibit-password
Port xxxx # éventuellement car moins visible donc moins sollicité.

Et si c'est pour un usage strictement local, sshd n'a pas a écouter sur 0.0.0.0 et ::

Il y avait un fail2ban, il a été désinstallé.

Start-Date: 2022-10-20  00:20:01
Commandline: apt remove fail2ban
Remove: fail2ban:amd64 (0.10.2-2)
End-Date: 2022-10-20  00:20:16

Et n'avait été installé que juste avant l'incident.

Start-Date: 2022-09-21  23:22:32
Commandline: apt-get install -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold -y fail2ban

Et avait réussi à bloquer l'attaquant 20 fois.

root@ubuntu:~# zgrep ssh /var/log/fail2ban* | grep -i -E "$IP_Chinoise_1" | grep -c Ban 
20
root@ubuntu:~#

Parfait je te laisse t'amusée alors essaye de regardée qui et cette utilisateur que je ne connais pas : diypseyypw

C'est pas un user mais juste le nom du binaire.

root@ubuntu:~# grep diypseyypw /etc/passwd || echo user inconnu
user inconnu
root@ubuntu:~# which diypseyypw
/usr/bin/diypseyypw
root@ubuntu:~#

Je te laisse le soins de corriger ce qui doit l'être ou mieux encore ré installer pour plus de sérénité.
J'ai supprimé ma clef de /root/.ssh/authorized_keys.

Celui de mon user donc le problème viens de l'activation du root je vais faire autrement pour une nouvelle installation et rajoutée un Cisco sur la machine j'en et encore 2 ou 3 qui traine et qui serve a rien

Mais dans tout les cas oui le formatage n'etait pas une option mais une obligation pour le coup

Merci encore

bruno

Re : Possible backdoor server

Tu peux remercier @matrix-bx pour son analyse.
Si j'ai bien compris, ton serveur a été compromis parce que tu as activé le compte root et tu lui as attribué un mot de passe faible (apparemment trouvé immédiatement par une attaque par dictionnaire).