[freebsd] Blinder le systeme

MaXX wrote:

Une fois que j'aurais tout terminé, j'aimerais faire "une sorte de photo" de
tous les exécutables du système (nom de fichier / hash MD5) et la graver
sur CD afin de vérifier toute les nuits (au pire à intervalle régulier en
fonction du temps nécessaire) qu'il n'y a aucune altération
(rootkit/corruption d'origine suspecte).

Je sens que je vais déclencher un troll ici (ce n'est pas mon intention,
hein...), mais je constate que certains outils de gestion de paquets
(par exemple, rpm) font tout ce que vous souhaitez
(empaquetage-compression/timestamp/signature MD5/mini-database).

Pourquoi ne pas organiser vos fichiers en paquetages et les gérer avec
l'outil de paquetage de votre choix ? Pour ma part, j'utilise rpm et ça
me convient. la db de signatures peut être stockée sur un système
distant (la console de l'admin :-)) ?), et rpm peut être invoqué par ssh
depuis une machine distante, ou éventuellement compilé en statique sur
un montage nfs ro pour être disponible sur le système à auditer.

Sinon, pour des sauvegardes périodiques automatisées, je trouve amanda
très pratique : on est pas obligé de disposer d'un lecteur de bande pour
l'employer, mais il faut alors scripter un peu.

On 23 Jun 2005 00:08:48 GMT, MaXX <bs139412@skynet.be>:

J'en suis au point de vouloir booter la machine sur un cd live

Mouais... et à la moindre mise à jour, il faut regraver un CD et
redémarrer la machine.

Note que les logiciels que tu utilises ont vraisemblablement des
failles, et qu'il est possible que certaines de ces failles peuvent
puissent être utilisées directement pour détruire/falsifier des
données. Et mettre lesdits logiciels sur CD ne changera rien.

In article <d9cr0m$3bs$1@talisker.lacave.net>, bs139412@skynet.be
says...

Une fois que j'aurais tout terminé, j'aimerais faire "une sorte de photo" de
tous les exécutables du système (nom de fichier / hash MD5) et la graver
sur CD afin de vérifier toute les nuits

L'idée de base est d'être prévenu par mail le plus rapidement possible de
toute modification, quitte à mettre le serveur hors ligne avant qu'il n'ait
pu faire trop de dégâts.

http://la-samhna.de/samhain/

peut faire ça et t'alerter en cas de modification.

MaXX <bs139412@skynet.be> writes:

Bonjour à tous,

Désolé de crossposter, mais je ne parviens pas à choisir le groupe le plus
approprié, merci de placer le suivi dans le bon groupe.

Fu2 fr.comp.securite pour cette partie de reponse, en tout cas....

Je compte réinstaller le serveur web du boulot début Juillet afin de patcher
toutes les applications et l'OS en un coup et en profiter pour remettre au
propre mes procédures.
[....]

Une fois que j'aurais tout terminé, j'aimerais faire "une sorte de photo" de
tous les exécutables du système (nom de fichier / hash MD5) et la graver
sur CD afin de vérifier toute les nuits (au pire à intervalle régulier en
fonction du temps nécessaire) qu'il n'y a aucune altération
(rootkit/corruption d'origine suspecte).

Nom de fichier + MD5 est aujourd'hui considere comme "leger", meme si
les exploitations concretes sont encore experimentales pour ce que
j'en ai vu (en tout cas pas facilement generalisables).

Au minimum, ajoutes la taille du fichier (ca complique la generation
d'un fichier "kivabien" avec le meme hash MD5), l'ideal amha etant
SHA1 / MD5 / taille de fichier.

Bien que ce soit facile à mettre en place (et détectable) via un crontab, je
me demande si c'est une mesure d' _alerte_ suffisante et si il n'y a pas
quelque chose de plus simple/sur.

Si j'etais l'attaquant, une des premieres choses que je ferais apres
avoir pris le controle d'une machine, c'est regarder la crontab.

Meme si tes empreintes sont sur un CD (donc impossibles a modifier),
il suffit que les binaires concernes soient accessibles sur le disque
(on les remplace par des binaires qui sortent directement la sortie
"voulue", par exemple), ou simplement que leur appel automatique soit
aussi accessible pour facilement contourner ca (on change l'appel pour
"un truc qui va bien").

L'idée de base est d'être prévenu par mail le plus rapidement possible de
toute modification, quitte à mettre le serveur hors ligne avant qu'il n'ait
pu faire trop de dégâts.

Ca peut quand meme etre interessant a mettre en place, mais il ne faut
pas oublier de faire une verif complete a la main, avec outils "surs"
(sur le CD aussi) a l'occasion, et de se souvenir des possibilite de
contourner la verification automatique.

Pour l'instant, cette machine tourne en mode "parano" (kern.securelevel=5),
system accouting activé, j'essaie d'inspecter les logs tout les 2 à 4
jours, mais je ne me sens pas assez à l'aise.

Les logs sur la machine peuvent tout a fait etre modifies par
l'attaquant...

Si vraiment tu veux des logs "fiables" et "te sentir mieux", l'ideal
me semble etre d'envoyer les logs au fur et a mesure sur une autre
machine, et d'avoir des outils d'analyse automatiques sur cette autre
machine (qui remonte toute chose anormale / inconnue / inhabituelle /
etc).

Ca ne dispense toujours pas de jeter "un coup d'oeil a la main" a
l'occasion.

Si quelqu'un peut me donner des informations pour blinder le système...

J'en suis au point de vouloir booter la machine sur un cd live avec
uniquement les données sur le disque dur; quitte à sacrifier qq Mb de
RAM... Bonne idée, perte de temps ou pur délire?

Mouaif.... tant qu'on reboote pas, ca resoud rien (on peut pas ecrire
de nouvelles versions des binaires sur le CD, mais ca n'empeche pas de
pouvoir s'installer en memoire quand meme), le principal avantage est de
pouvoir faire un reboot d'urgence en cas de problemes (le CD n'est pas
corrompu), mais si quelqu'un a su rentrer une fois sur un systeme, il
saura y rentrer de nouveau tant que le systeme n'a pas ete corrige
(donc nouveau CD a sortir).


Bon, a cote de ca, faut aussi savoir relativiser, tout ce que tu as
propose permet deja de monter le niveau de securite, de se proteger de
la plupart des attaques automatiques (qui n'iront pas faire les manips
dont je parle, ou d'autres auxquelles j'ai pas pense) et les
attaquants "debutants".

Mais il est toujours important de bien avoir conscience des limites
des outils qu'on met en place....


A +

VANHU.

Mollo wrote:

In article <d9cr0m$3bs$1@talisker.lacave.net>, bs139412@skynet.be
says...

L'idée de base est d'être prévenu par mail le plus rapidement possible de
toute modification, quitte à mettre le serveur hors ligne avant qu'il
n'ait pu faire trop de dégâts.
http://la-samhna.de/samhain/

peut faire ça et t'alerter en cas de modification.
J'ai un peu feuilleté la documentation et il me semble très sympa ce petit

soft... Je vais faire des tests, voir si il est compliqué à configurer
correctement.
--
MaXX

J'en suis au point de vouloir booter la machine sur un cd live avec
uniquement les données sur le disque dur; quitte à sacrifier qq Mb de
RAM... Bonne idée, perte de temps ou pur délire?

Tout ce que je peux en dire (c'est pour ça que je retourne sur fcob),
c'est que la réalisation d'un CD Live en FreeBSD est d'une étonnante
simplicité. Tu fais une poignée de scripts avec un $DESTDIR vers un
répertoire quelconque, pour faire un buildkernel et buildworld les plus
allégés possibles (en fonction des besoins), un peu de peaufinage des
scripts de démarrage peut-être, puis quelque chose du goût de :

mkisofs -RU -b boot/cdboot -no-emul-boot -o .../bla.iso $DESTDIR

Et zoup, c'est à peu près bon. Bon, après, il y a quelques itérations
pour obtenir exactement ce qu'il faut, évidemment... Je te conseille de
prototyper sur un CD-RW... :)

Ah, et pour les mises à jour, mergemaster comprend $DESTDIR aussi
(pratique).

Fred
--
The deeper you stick it in your vein
The deeper the thoughts, there's no more pain
I'm in heaven, I'm a god
I'm everywhere, I feel so hot (K's Choice, Not an Addict)

Fabien LE LEZ wrote:

On 23 Jun 2005 00:08:48 GMT, MaXX <bs139412@skynet.be>:

J'en suis au point de vouloir booter la machine sur un cd live
Mouais... et à la moindre mise à jour, il faut regraver un CD et

redémarrer la machine.
Je m'en doute bien, et c'est une charge de travail importante si portaudit

commence à se faire trop bavard...

Note que les logiciels que tu utilises ont vraisemblablement des
failles, et qu'il est possible que certaines de ces failles peuvent
puissent être utilisées directement pour détruire/falsifier des
données. Et mettre lesdits logiciels sur CD ne changera rien.
De fait, je vais essayer de repenser un peu tout ça...

Merci
--
MaXX

VANHULLEBUS Yvan wrote:

MaXX <bs139412@skynet.be> writes:

Bonjour à tous,
Désolé de crossposter, mais je ne parviens pas à choisir le groupe le
plus approprié, merci de placer le suivi dans le bon groupe.
Fu2 fr.comp.securite pour cette partie de reponse, en tout cas....

[....]

Une fois que j'aurais tout terminé, j'aimerais faire "une sorte de photo"
de tous les exécutables du système (nom de fichier / hash MD5) et la
graver sur CD afin de vérifier toute les nuits (au pire à intervalle
régulier en fonction du temps nécessaire) qu'il n'y a aucune altération
(rootkit/corruption d'origine suspecte).
Nom de fichier + MD5 est aujourd'hui considere comme "leger", meme si

les exploitations concretes sont encore experimentales pour ce que
j'en ai vu (en tout cas pas facilement generalisables).
Au minimum, ajoutes la taille du fichier (ca complique la generation
d'un fichier "kivabien" avec le meme hash MD5), l'ideal amha etant
SHA1 / MD5 / taille de fichier.

Samhain, proposé par Mollo semble faire ça très bien et tout seul, il peut
utiliser SHA1, MD5 et un autre algorhytme que je ne connais pas TIGER192.

Il surveille les fichiers que tu veux et peut envoyer les logs et les
alertes par mail ou directement sur une autre machine Samhain.

[...]

Meme si tes empreintes sont sur un CD (donc impossibles a modifier),
il suffit que les binaires concernes soient accessibles sur le disque
(on les remplace par des binaires qui sortent directement la sortie
"voulue", par exemple), ou simplement que leur appel automatique soit
aussi accessible pour facilement contourner ca (on change l'appel pour
"un truc qui va bien").

D'accord. Je vais essayer de cracker une de mes machines à la maison à des
fins didactiques, histoire de mieux comprendre comment tout ça marche...

Question à deux balles: c'est dangereux de conserver ses sources (/usr/src)
sur un machine de 'prod'? Je me vois bien y insérer du code suspect et
attendre que le système soit recompilé... Sur cette machine, je ne le
conserve pas, je fais un rm -r /usr/src + cvsup avant le buildworld pour
être sur, mais ce n'est pas le cas à la maison.

[...]

Bon, a cote de ca, faut aussi savoir relativiser, tout ce que tu as
propose permet deja de monter le niveau de securite, de se proteger de
la plupart des attaques automatiques (qui n'iront pas faire les manips
dont je parle, ou d'autres auxquelles j'ai pas pense) et les
attaquants "debutants".
Mais il est toujours important de bien avoir conscience des limites
des outils qu'on met en place....
A +
VANHU.
En tout cas, merci je vais encore potasser un peu notament les chroots, ACLs

et autres trucs dans le genre...


--
MaXX

"MaXX" <bs139412@skynet.be> a écrit dans le message de news:
d9cr0m$3bs$1@talisker.lacave.net...

Bonjour à tous,

Désolé de crossposter, mais je ne parviens pas à choisir le groupe le plus
approprié, merci de placer le suivi dans le bon groupe.

Je compte réinstaller le serveur web du boulot début Juillet afin de
patcher

toutes les applications et l'OS en un coup et en profiter pour remettre au
propre mes procédures.

Bjr,

Tu bosses pour la DST Tant de précautions me semblent relever de la
paranoïa..
Certes, c'est mieux d'être trop précautionneux que pas assez..
Mais là, je trouve que ca fait beaucoup tout de même..
Peut etre (même probablement) ais je tort, et ne suis je pas suffisament
conscient des dangers.
Cela dit, tout cela dépend bien sur de la sensibilité des donnnées..

Salutations.

[...]

Une fois que j'aurais tout terminé, j'aimerais faire "une sorte de photo" de
tous les exécutables du système (nom de fichier / hash MD5) et la graver
sur CD afin de vérifier toute les nuits (au pire à intervalle régulier en
fonction du temps nécessaire) qu'il n'y a aucune altération
(rootkit/corruption d'origine suspecte).

Excellente idéé (lorsqu'on en a les moyens) mais ceci doit être réalisé
au départ de la machine propre qui, bien entendu, ne doit avoir (dans
l'esprit) aucune porte ouverte.
C'est elle qui vérifie, via un ssh par exemple, les checksums des
différents fichiers. Il existe des applications toutes faites pour
parcourir une arborescence ou il y a toujours la solution du script maison.
Ce n'est détectable que si l'on observe le journal (si SSH) et il y
plusieurs façons de rendre cela invisible (sauf à effectuer un netstat
bien entendu).

Du même coup, cette machine permet de vérifier l'accessibilité de la
machine de production et d'informer par SMS (rupture protocolaire) le
cas échéant.
J'ai mis en place ce type de système il ya plusieurs années pour la
partie Web : contrôle régulier (tous les 1/2 heure ou toutes les heures)
et remplacement avec alerte si différence. Les développeurs mettaient à
jour la machine de surveillance bien entendu.
Efficace contre les << defacements >>, pratique pour une
responsabilisation par métiers de l'exploitation (seuls les
administrateurs et opérateurs ont accès à la production, pas les
développeurs) et utile pour l'administration de manière générale.

J'en suis au point de vouloir booter la machine sur un cd live avec
uniquement les données sur le disque dur; quitte à sacrifier qq Mb de
RAM... Bonne idée, perte de temps ou pur délire?

Question de coût ... comme d'hab. Si pb survient durant ton absence
(vacances, maladie, déplacement) qui fait quoi ? Normalement il suffit
de rebooter mais ... si ça se passe mal ?
As-tu fait passer les consignes de ne PAS, sous aucun prétete, retirer
le CD ?
Dans cette optique, le mieux est de booter sur une CF en lecture seule.
Au moins la CF est à l'intérieur et personne ne risque de la retirer par
inadvertance (ce qui serait le cas d'une clé USB également).

Il faut gérer par niveau : sécurité des données, sécurité des accès,
sécurité de l'OS, supervision, maintenance, alignement avec la
stratégie, etc.
Ainsi que par périmètre : l'entreprise, le personnel, l'extérieur, les
sous-traitants, stagiaires, le dirlo, etc.

Dans bien des cas l'hébergement pro permet de s'affranchir du pb de
vacance et de manque de personnel qualifié. Mais c'est cher.
Ensuite c'est encore une question d'argent.
Envisager 2 machines, hébergées en 2 endroits différents qui se
surveillent l'une l'autre et qui prennent chacune le relais de l'autre
ça se fait (y compris avec des bases de données) mais sans astreinte
c'est de la haute-voltige. Ca fonctionne bien, très bien jusqu'au jour
où ... ça ne fonctionne plus parce que ceci ou cela.
Et c'est justement un jour où tu es parti en trekking en Mongolie que
cela se produit.

Sécuriser a toujours un revers : les coûts. Au fur et à mesure les coûts
diminuent pour une même parade mais d'autres menaces apparaissent.

Les failles c'est une chose mais toutes ne sont pas critiques, tu n'es
pas concerné par tous les avis paraissant et selon ce que tu accueilles
tu seras plus ou moins candidat à l'attaque (même si celles-ci ont
tendance à pratique le systématisme du fait des scripts automatiques
[mais l'injection SQL sur une appli perso n'est pas encore le fait de
scripts automatiques).

Donc sécurise à mort si tu veux mais pense au reste : qualification
nécessaire en ton absence, niveau de service aux clients ainsi qu'au
personnel, procédure de mise à jour (mieux vaut disposer de 2 machines
dans ce cas cela évite l'interruption de service).

Dans de nombreux cas on te reprochera bien davantage d'impacter le temps
de service de la machine avec tes considérations hautement sécuritaires
que de laisser entrer quelques troyens inoffensifs parfois.

db


--

Courriel : usenet blas net