Serveur hacked

Support Debian
#1

Bonjour a tous,

Je viens de recevoir par mail un truc sympa comme ca:

[i]To whom it may concern.

We have detected a hack attempt originating from your network from ip: ns1.yourdomain.com

This suggests that the above server has been compromised and is a participant in a botnet.

This means that this server has been hacked and now, in turn, is attempting to hack other servers on the Internet.

This IP address has now been blacklisted to protect our service from further brute force attacks. Furthermore, this IP address has been uploaded to the DenyHosts database. This means that this IP address will also shortly be blacklisted by all DenyHosts members who query this central database.

An excerpt from our logfiles. All times shown are in GMT:

Apr 7 07:51:50 [sshd] error: PAM: Authentication failure for root from ns1.distribatinfo.com
Apr 7 07:51:50 [sshd] error: PAM: Authentication failure for root from ns1.distribatinfo.com
Apr 7 07:51:50 [sshd] error: PAM: Authentication failure for root from ns1.yourdomain.com[/i]

Le probleme est que je n’ai rien vu dans mes logs qui pourrait ressembler a du hacking, donc pour faire la verification de ce mail, j’aimerais ssavoir si il est possible de faire une verification des logs sortant de mon serveur.

Ou alors, si vous avez une autre idee, elle est la bienvenue.

merci par avance

JP

#2

Ben par acquis de conscience, j’ai regardé dans mes logs:

[quote]Apr 7 06:44:02 cerbere sshd[27633]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ns1.distribatinfo.com user=root
Apr 7 06:44:04 cerbere sshd[27619]: error: PAM: Authentication failure for root from ns1.distribatinfo.com
[/quote]
donc si tu ES ns1.distribatinfo.com, effectivement tu as un cheval de troie sur ta machine.

#3

tu sais de qui vient ce mail ??

les logs donnés dans le message sont en heure GMT, donc par rapport aux tiens il faudra sans doute enlever 2 heures.( chez toi regarde vers 05h51 ce matin)

comment savoir si ton serveur contacte d’autres serveurs en ssh ??

  • est ce que iptables t’autorise à sortir vers internet sur le port 22 ??
  • dans iptables active un log sur les connexions sortantes et entrantes pendant un temps
  • fait un netstat -laputen pour voir si quelqu’un est connecté sur ta machine, et lance le toutes les 10 minutes (cron) et redirige le vers un mail

à mon avis il est plutôt ns1.yourdomain.com

#4

[quote=“thomas.leclerc”]

à mon avis il est plutôt ns1.yourdomain.com[/quote]
exact, le mail est curieux, il cite 2 fois ns1.distribatinfo.com, j’ai pensé qu’il voulait cacher son domaine…

Le plus simple est de tout tracer pendant quelques temps (pas que le port 22), et bien sûr de faire un checkrootkit et une vérification sur l’intégrité des fichiers.
PS: Pour info, moi c’est netstat -lataupe :smiley: C’est plus innocent…

#5

mouais, avec deux fois le a et pas de n ??

moi je prefere tout en numerique, ça prend moins de temps (par de requete dns) et les N° de port sont en clair

#6

bon ben au moins je vous faire rire avec mes ns, c’est deja ca!!!

merci pour votre reactivite, je vais voir tout cela de suite

#7

bonsangmaisc’estbiensur jplorans de casablanca, je n’avais pas fait le raprochement

ben non, en fait c’est bien lui distribatinfo.com. alors t’essaye de pirater fran.b ?? salopiaud va.

#8

lsof -i -P :wink:
en root :smt006

#9

J’utilise aussi netstat -lataupe, c’est facile à retenir, et tant pis si certaines options y sont 2 fois.
Tu peux aussi essayer wireshark (vérifie laure tographe, il te donnera pleins d’infos sur ton trafic.

#10

Bon, j’ai regardé, tu as deux serveurs:
distribat.info sur un joomla natif dont il faudrait regarder la version (mis à jour récemment?) et la configuration (celle par défaut?)

distribatinfo.com serveur professionnel avec des liens comme
distribatinfo.com/index.php? … &Itemid=33

Regarde si il n’y a pas une faille du type include dans ton serveur. Vérifies chacun des fichiers possédés par apache notamment dans /tmp, la racine du site et /var/tmp (pense aux noms bizarroïdes). Enfin vérifies les logs d’apache aux alentours de ce matin PARTICULIÈREMENT à 8:44 (UTC+2) soit (06:44 GMT) heure où tu essayais de rentrer sur mon serveur.

#11

Bonjour Fran.b

Je suis en train regarder ce que tu m’as dit, je suis donc dans les files /tmp a la racine. Je vois les files de session “sess-01af54987324000000000” (enfin des numeros bizarre koi!!!. Seulement, en regardant dans ces fichiers, je vois des lignes telles que “REQ_URI|s:10:”/index.php";" ou “REQ_URI|s:57:”/index.php?option=com_content&task=view&id=117&Itemid=192";"

Sur Google, je ne trouve pas de reel explication, je pense que ces fichiers peuvent etre important, a votre avis comment detecter une intrusion dans les fichiers de session??

Merci d’avance

jp

#12

[color=#0000FF]je ne sais pas si cela peux t’aider …? mais il y avait cette info :

zataz.com/news/18821/Toata-d … avola.html[/color]

#13

Les fichiers session_etc sont les fichiers des sessions php interrompues, ça n’est pas bien grave. Essaye de faire une recherche sur tous les fichiers .php contenant

par exemple. Cherche des fichiers de noms simples genre a.php ou cachés comme «.a.php».
Essaye de regarder dans les logs d’apache des lignes avec comme navigateur “libwww-perl”

#14

Merci a tous pour votre support.

En checkant mes fichiers d’erreurs logs, j’ai trouve des choses qui me paraissent bizarre

03:06:50 (821.39 KB/s) - barbut' saved [22624/22624] --03:06:51-- [217.79.182.58/barbut](http://217.79.182.58/barbut) (try: 2) =>barbut.1’
Connecting to 217.79.182.58:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 22,624 (22K) [text/plain]
0K … … … 100% 701.81 KB/s
03:06:51 (701.81 KB/s) - `barbut.1’ saved [22624/22624]

J’ai bien l’impression que ce fichier a transferer le fichier barbut a sa guise, dans ce cas, pourquoi est ce que ca apparait dans les erreurs logs??

Fran.b
Pour info, je ne voulais pas t’embeter avec ca, mais j’ai effectivement trouve un dossier bizarre /racine/tmp/shell/1 avec a l’interieur des trucs tels que

handle stef
mask !@mort.users.undernet.org
prot 4
aop
channel *
access 100

Je pense que le mieux est de formater le serveur car ca devient au dessus de les competences la.

#15

Non, ner formatte pas le serveur. Tu n’as qu’une faille dans le serveur web PHP, donc ça n’est pas grave. Il te faut la localiser alors laisse le tourner le temps de la voir. Il te faut éplucher les logs apache autour de 03:06:50. Regarde soigneusement les lignes (éventuellement copie les ici) mais urtout ne formatte pas, de toute façon tu devras remettre le serveur Web en route avec les mêmes scripots DONC la même faille. Le pbm, c’est le serveur Web, pas le serveur lui même.

Eventuellement fais un

$ debsums -a
(mais ne panique pas sur les résultats)

#16

ok ok monsieur, quelque part tu me confortes dans mon idee car a quoi sert un backup avec des failles.

En revanche, j’ai vraiment note des fichiers bizarre, je les ai copies sur mon pc (ca ne craint pas bcp) et je les ai supprimes du serveur.

Je regarde les logs de suite

#17

Cela dit, d’après ce que j’ai lu tu as peut être l’identité (un mail plutôt) de ton pirate:

[quote]handle stef
mask !@mort.users.undernet.org
[/quote]

stef@mort.users.undernet.org apparemment. Envois lui un mail d’insultes, ça te soulagera.

#18

Salut fran,

j’espere que ca roule pour toi.

Heureusement que tu m’as dit de ne pas m’inquieter pour le $ debsums -a …, j’ai eu le temps de prendre un cafe le temps de l’analyse, lol.

Plus serieux, je fais comment pour recuperer le rapport en format texte?? euh si c’est possible.

Sinon, je n’avais pas de log aux alentours de 3.06 hier et pour today, le volume a sensiblement baisser, cependant je continue de tracker :slightly_smiling:

#19

J’ai dis 3:06 à cause de l’action wget à cet instant. Je suis sûr que tu as des traces dans les logs d’apache autour de cette période. Tu devrais faire le script suivant

#!/bin/sh if [ $USER = "www-data" ] ; then date +"%c Commande wget $*">> /var/log/intrusion.log pushd /tmp DIR=`date +".intrus.%s"` mkdir $DIR cd $DIR wget.org $* cd .. chmod 000 $DIR popd exit 0 else wget.org $* fi
Tu déplaces wget sur wget.org et tu mets cette commande wget en éxécutable. Comme cela un wget exécuté par l’intermédiaire de www-data (qui éxécute apache) ne sera pas éxécuté et tu auras la trace de la tentative et la chaine de commande ainsi que les fichiers qu’ils auraient du charger (par rpécaution, les droits sur /tmp/.intrus.??? sont mis à 0. En clair tu auras n…r le pirate

#20

Ah si tu le voulais, tu pourrais en faire des dégâts si tu étais un “black hat”!!!

Je ferais attention à ne jamais me fâcher avec toi :laughing: