Probleme d'intrusion sous RH7.2

Bonjour,

Bonjour :)

Avant aujourd'hui:
.connexion root en direct , fonctionnait OK
.connexion root via telnet donnait parfois de manière aléatoire des
"mots de passe
invalides" que l'on "traitait" en se connectant sous un compte
utilisateur et en faisant
un su - root. La connexion utilisateur fonctionnait toujours.

Bon deja c'est mal connexion root direct.
Dans sshd_config mettre
PermitRootLogin No

Ca calme la tentation :)

Ensuite la connexion en root directe par telnet, je comprend
ou le petit malin sous cite a eu son acces :) Un petit tcpflow
avec un mode promicious sur le lan a suffit a faire son bonheur.

Solution : desinstaller telnetd au plus vite.

Depuis aujourd'hui:
.le seul élément qui paraisse significatif (encore que ...) comme
"déclencheur" est
la création d'un compte utilisateur (non privilégié) pour faire des
transferts FTP.

Un petit malin directement sur le lan ?

.un premier test FTP sous ce compte a fonctionné

Pas trop manchot alors :)

.quelque temps plus tard:
[...] ca sent le probleme pam... (partons du principe que non

on est fcs :))

Bon deja, essayer d'établir la liste des programmes qu'il utilise
(si intrusion il y a...) en les bash_rc et autres.

Ensuite, bah moi j'en remplacerais directement un, pour récupérer
des infos sur celui qui le lance. Copier la trace de who, de
netstat -an, ps aux, lsof (si dispo car pas conseillé). Ensuite
directement un mailx pour pas que le pirate (presume) est le temps
de virer ton log (si t'as lsof par exemple :)).

Essaye si possible de mettre syslog-ng sur un autre serveur (avec un
pass root different lol).

.on remet les fichiers dans bonne protection (644) ,suid , ... tout
remarche.

normal :)

.15 minutes après : les protections sont revenues à 777 (y compris /bin/su)

kill crond et atd.

.ceci est reproductible

verifie que ca l'est toujours apres ca :)

Nous avons: déconnecté le routeur (mais il semble qu'il y en ait
d'autre sur le LAN).

Bof ca doit venir de dedans :)

Cela n'a rien changé , les process actifs n'ont a priori rien de
bizarre. Il n'y a pas
de cron bizarres. Les shells .bashrc,bashrc,.bash_profile semblent OK.
Il n' ya pas
de fichiers récents dans les rc.d. Les fichiers reviennent en 777.

Ca ne veux rien dire, deja a sa place je rentrerais pas par root,
mais je ferait un fake de /bin/ping (ou autre suid), avec une option
particuliere il spawn un shell.

Pour les bashrc et compagnie, bah faut vraiment avoir envie de se
faire remarqer :)

S'il a cree un utilisateur ftp, il etait root, s'il etait root, il
aurait mieux fait de remplacer un binaire comme bash, ls, pwd (et autres
binaires utilises constemments) pour ses affaires
personnelles que de modifier .bashrc :)

Merci de toute idée .....

En voila quelques unes.

Pour info (ne semble pas avoir de rapport , mais ...) : ce serveur a
remplacé en novembre un
serveur plus ancien , qui reste sur le LAN , l'adresse IP du nouveau
serveur est
celle de l'ancien , qui lui a hérité d'une nouvelle adresse.

Hum ca depend, si tu as clone le serveur, alors peut etre que tu as
une relation de confiance (paire de cle ssh ou autre) et un script
qui viens se faire plaisir :)

Amicalement,

Seb :)

Bonjour,
suis pas du tout un pro mais j'essaye de m'intéresser...

nwjb wrote:

Bonjour,

un serveur
HP sous RH7.2 , sans accès internet (donc pas de DNS , ...) , connecté au
Faut pas forcement un DNS pour détecter une machine vivante sur un lan... Un

petit nmap (ou autre) avec une range d'ip bien choisie, genre 192.168.x.x
aura vite fait de lister tout ce qui possède une ip sur le réseau et les
ports ouvert, et très probablement le service qui se trouve derrière le
port. Et "l'attaque" vient peut être de l'intérieur...

LAN , un routeur Netgear ADSL (avec parefeu par défaut),un modem de
télémaintenance
Quelles sont les règles par défaut? (on peut imaginer FW enable et comme

règle allow all from any to any, connais pas la bête mais bon)
Y a-t-il une DMZ?
L'interface d'admin est-elle visible sur le WAN? (déjà vu)

sur un autre serveur sur le LAN, rencontre le problème suivant:

Avant aujourd'hui:
.connexion root en direct , fonctionnait OK
.connexion root via telnet donnait parfois de manière aléatoire des "mots
de passe
tu veux dire ssh? n'importe qui sur le lan avec un sniffer peut lire le mot

de passe en clair si c'est du telnet...

invalides" que l'on "traitait" en se connectant sous un compte
utilisateur et en faisant
un su - root. La connexion utilisateur fonctionnait toujours.
Ok mais c'est ça qu'il est conseillé de faire...

Dans sshd.conf : PermitRootLogin=NO

Depuis aujourd'hui:
.le seul élément qui paraisse significatif (encore que ...) comme
"déclencheur" est la création d'un compte utilisateur (non privilégié)
pour faire des transferts FTP.
.un premier test FTP sous ce compte a fonctionné
Le ftp, c'est bien pour planquer des contenus illégaux (la pédophilie par

ex. reste malheusement à la mode, mais pas légale, donc mieux vaut héberger
ailleurs que chez soi)

.quelque temps plus tard: invalid password (via ftp) ,connexions sous
telnet parfois
valide , parfois invalid password.
.la fonction su - xxx ne fonctionne plus ("impossible d'attribuer les
groupes")
Je me suis fait le coup tout seul en virant sur une de mes machines FreeBSD

un utilisateur directement dans /etc/passwd, ça a du decaler quelque chose
et foutre en l'air tout les utilisateurs definis "en dessous" de celui que
j'ai viré (je sais: pas bien)

.on observe que dans /var/log/messages pam signale des fichiers de /etc
(securetty,
ftpusers , shells) comme étant en écriture par world , en effet ils sont
tous en
777. le fichier bin/su n'a plus l'attribut suid.
.on remet les fichiers dans bonne protection (644) ,suid , ... tout
remarche.
.15 minutes après : les protections sont revenues à 777 (y compris
/bin/su) .il en va de même de la base oracle dont l'exécutable doit être
en protection 6751
et qui repasse en 777
.ceci est reproductible
Si je me souviens bien pour changer un SUID, il faut être root, le mec s'est

procuré les droits en exploitant une faille (ou le mot de passe) et a
laissé derrière lui un petit machin qui produit cet effet. Si il y eu les
droits de root, il a probablement compromis un exécutable parfaitement
anodin (cron, bash me semblent être de bonnes cibles, mais le choix est
large regarde la table des process, y'en a un paquet en générale)

Nous avons: déconnecté le routeur (mais il semble qu'il y en ait d'autre
sur le LAN).
Cela n'a rien changé ,
le mal est fait, le mec s'est cassé et il a laissé son cadeau empoisonné,

son machin va attendre qu'il retrouve une connectivité extérieure...

les process actifs n'ont a priori rien de bizarre.
Il n'y a pas
de cron bizarres. Les shells .bashrc,bashrc,.bash_profile semblent OK. Il
n' ya pas
de fichiers récents dans les rc.d. Les fichiers reviennent en 777.

Merci de toute idée .....
Sortir les backups et restaurer, ou mieux: eteindre violament la machine

(bouton power ou virer la prise), cloner le disque avec un ghost ou qqch du
genre pour essayer de comprendre ce qui s'est passé. Comme tu dispose d'une
copie "conforme" de ton dd (pas remonter en rw), tu peux prendre "un peu"
plus de temps pour trouver la cause et de l'aide (collègues, fournisseurs
de services)... La restauration réouvrira la faille qui a permi au gars de
venir faire un nid pour on ne sais quoi de louche, la machine retourne en
prod... Installer un soft comme chkrootkit (www.chkrootkit.org). Et suivre
autant que possible les buletin de sécu des soft sur la machine, c'est pas
facile à prendre comme discipline, j'essaye mais je ne suis pas très
assidu, j'avoue...

Pour info (ne semble pas avoir de rapport , mais ...) : ce serveur a
remplacé en novembre un serveur plus ancien , qui reste sur le LAN ,
l'adresse IP du nouveau
serveur est celle de l'ancien , qui lui a hérité d'une nouvelle adresse.
Trainerait-il quelque part sur l'ancien "quelque chose" qui ferait des
choses par @IP et s'adresserait au nouveau ??
Depuis novembre, le problème aurait surement été visible avant...

Enfin, bonne m**** pour trouver la cause et remettre la becane en prod..
MaXX

nwjb wrote:

Déjà une règle qui a été rappelée ici je ne sais combien de fois :
VIRER TOUT CE QUI TRANSPORTE UN MOT DE PASSE EN CLAIR : telnetd en
l'occurrence, le ftp semblant difficilement évincible. Encore que, sur ce
dernier point, c'est une question de rapport vis-à-vis des utilisateurs de
ce service. On peut très bien leur demander d'utiliser HTTP ou SFTP (il
existe d'excellents clients sous Windows).

Ensuite, en ce qui concerne le RH7.2, je n'ai connu qu'une seule machine
Linux piratée (via débordement de tampon de l'Apache livré par défaut dans
cette Redhat), non installée par moi et c'était une RH7.2 !

En ce qui concerne le compte root sous SSHD je vais nuancer (au risque de me
faire gronder une fois de plus).
Effectivement le mieux est de supprimer toute possibilité de connexion
directe sous un compte privilégié (PermitRootLogin NO).
Toutefois, si on doit souvent se connecter à la machine, cela devient vite
pénible d'en passer par une étape intermédiaire.
Donc, et c'est ce que j'utilise depuis plusieurs années, le PermitRootLogin
est à Yes MAIS le compte root est DESACTIVE (DenyUsers root) et le compte
privilégié permettant de se connecter directement est autre chose genre :
sgrmlle.
En outre, la connexion en SSH n'est autorisée que depuis un petit lot
d'adresses de confiance.

Bref,
en ce qui concerne le diagnostic maintenant.
Ceci vaut ce que cela vaut (bien). Mais voici comment je procèderais (j'ai
déjà procédé ainsi sur un système que je pensais affecté et en fait c'était
un de mes scripts ... perte de temps, pfff).

Procéder par étape :
1. lister les comptes rendus de commandes livrées par Sébastien ;
ca fera déjà qqchose à se mettre sous la dent ;
2. Que figure-t-il dans le contab.quarterly ? Car, apparemment, le souci se
situe dans ce fichier étant donné les manifestations que tu décris.
Mettre en commentaire le contenu de ce fichier.
Voire même mettre de côté les commandes auquel il fait appel.


ensuite, si possible :
3. récupérer/compiler sur une machine et installer ensuite sur la machine
cible un détecteur de rootkit; l'exécuter et balancer ici les infos
pertinentes données par ce détecteur.

ensuite, plusieurs cas se profilent.
Ou le détecteur a fourni de l'info pertinente qui vaut le coup d'être
traîtée. On en reparle.

Sinon la procédure (pour savoir ce qui se passe exactement, dans le cas
contraire autant réinstaller une machine sauf si << les éléments
subversifs sont faciles à appréhender >>) est la suivante :
Remplacer le noyau par un nouveau, compilé depuis une autre machine
et nommé différemment ou installé depuis RPM mais le nom doit être
différent (afin d'éluder (*) le cas LKLM);

Avant de redémarrer neutraliser tous les services (notamment crond, ftpd ou
proftpd, telnetd [qui ne DEVRAIT PAS exister], sshd, MTA).

Replacer les bonnes permissions.

Redémarrer la machine.

Observer.
En l'absence de manifestation telle que décrite (**) redémarrer les
services
par ordre d'importance : Oracle, MTA, sshd, le serveur FTP, le serveur de
temps, etc.

Toujours rien ?

Très bien. concentrons-nous sur le crontab.quarterly.
Qu'y a-t-il dedans ?

Dans le cas contraire : que se passe-t-il ?

db

(*) J'ai bien écrit cela vaut ce que ça vaut car la procédure de démarrage
peut très bien introduire (via un faux-ifconfig par exemple) un rechargement
de faux-module mais ici cela ne semble pas le cas étant donné que
l'activité subversive semble se déclencher tous les 1/4 heure.
On peut donc même envisager de ne PAS remplacer le noyau et de passer
directement à l'arrêt des services.

(**) Mais il pourrait y en avoir d'autres, moins visibles.

--
courriel : usenet blas .net

[...]

En ce qui concerne le compte root sous SSHD je vais nuancer (au risque de me
faire gronder une fois de plus).
Effectivement le mieux est de supprimer toute possibilité de connexion
directe sous un compte privilégié (PermitRootLogin NO).
Toutefois, si on doit souvent se connecter à la machine, cela devient vite
pénible d'en passer par une étape intermédiaire.
Donc, et c'est ce que j'utilise depuis plusieurs années, le PermitRootLogin
est à Yes MAIS le compte root est DESACTIVE (DenyUsers root) et le compte
privilégié permettant de se connecter directement est autre chose genre :
sgrmlle.
En outre, la connexion en SSH n'est autorisée que depuis un petit lot
d'adresses de confiance.

J'ajoutertais que depuis quelques temps, OpenSSH permet d'autres options
que le seul couple Yes/No pour l'option PermitRootLogin, et notamment
without-password et forced-commands-only. Ces deux options empêchent
l'usage de "password authentification" pour root et forcent l'usage des
couples de clés privées/publiques. La seconde est même plus restrictive
encore car elle nécessite la présence de l'option command.
Tout cet arsenal permet donc d'affiner sa politique de sécurité. On peut
autoriser le root à se connecter directement si on sait pourquoi et
comment. Après tout, ça peut permettre de se passer de la commande su...

--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net