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.
PME de 5 personnes; 2 site web sous apache-2.0.53_1 + squid-2.5.9_3 (2
failles) derrière un pare-feu géré par notre FAI, 4 bases
postgresql-server-7.4.7_2, isc-dhcp3-server-3.0.1.r14_6, pas de serveur
mail, sauvegarde sur DVD-RW tout les 2 jours. L'OS a été mis à jour le 21
avril par un buildworld, mais de nouvelles failles sont apparues depuis.
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).
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.
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.
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.
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?
Vos idées, avis, expériences et commentaires sont les bienvenus..
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).
Tu viens de décrire ce bon vieux "tripwire" il me semble... http://sourceforge.net/projects/tripwire/
Z.
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).
Tu viens de décrire ce bon vieux "tripwire" il me semble...
http://sourceforge.net/projects/tripwire/
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).
Tu viens de décrire ce bon vieux "tripwire" il me semble... http://sourceforge.net/projects/tripwire/
Z.
Fabien LE LEZ
On 24 Jun 2005 07:12:25 GMT, news :
Je pense a une machine frontale qui aurait une seconde carte reseau pour prendre ses donnees sur un serveur nfs en mode read-only
Un serveur web fonctionne rarement en mode "lecture seule" : généralement, il contient des scripts et/ou des CGI qui s'attendent à pouvoir écrire des données sur le disque. Et il arrive même que les données en question soient plus importantes que les pages web en elles-mêmes (commandes, coordonnées de clients, etc.)
On 24 Jun 2005 07:12:25 GMT, news <news@nowhere.org>:
Je pense a une machine frontale qui
aurait une seconde carte reseau pour prendre ses donnees sur un serveur
nfs en mode read-only
Un serveur web fonctionne rarement en mode "lecture seule" :
généralement, il contient des scripts et/ou des CGI qui s'attendent à
pouvoir écrire des données sur le disque. Et il arrive même que les
données en question soient plus importantes que les pages web en
elles-mêmes (commandes, coordonnées de clients, etc.)
Je pense a une machine frontale qui aurait une seconde carte reseau pour prendre ses donnees sur un serveur nfs en mode read-only
Un serveur web fonctionne rarement en mode "lecture seule" : généralement, il contient des scripts et/ou des CGI qui s'attendent à pouvoir écrire des données sur le disque. Et il arrive même que les données en question soient plus importantes que les pages web en elles-mêmes (commandes, coordonnées de clients, etc.)
Cedric Blancher
Le Fri, 24 Jun 2005 09:14:17 +0000, Fabien LE LEZ a écrit :
Un serveur web fonctionne rarement en mode "lecture seule" : généralement, il contient des scripts et/ou des CGI qui s'attendent à pouvoir écrire des données sur le disque.
J'aurais tendance à aller dans l'autre-sens, dans la mesure où la plupart des applications que j'ai vues en production s'appuyaient sur des bases de données pour le stockage des données, les autres ayant toutes été vouées à la migration vers une SGBDR tellement c'était cochon. Tu me diras, une BDD, c'est stocké sur le disque, ce que je t'accorde volontiers, mais pas par le serveur HTTP.
C'est mon expérience à 0,02EUR...
-- MB: Wolf est dans un grand hôtel parisien ; si vous voulez, j'ai toutes les photos (un peu floues hélas). FR: Le talon aiguille de Wolf est exposé au Musée du Ritz. -+- in: Guide du Cabaliste Usenet - Wolf : L'étalon aiguille ? -+-
Le Fri, 24 Jun 2005 09:14:17 +0000, Fabien LE LEZ a écrit :
Un serveur web fonctionne rarement en mode "lecture seule" :
généralement, il contient des scripts et/ou des CGI qui s'attendent à
pouvoir écrire des données sur le disque.
J'aurais tendance à aller dans l'autre-sens, dans la mesure où la
plupart des applications que j'ai vues en production s'appuyaient sur des
bases de données pour le stockage des données, les autres ayant toutes
été vouées à la migration vers une SGBDR tellement c'était cochon. Tu me
diras, une BDD, c'est stocké sur le disque, ce que je t'accorde
volontiers, mais pas par le serveur HTTP.
C'est mon expérience à 0,02EUR...
--
MB: Wolf est dans un grand hôtel parisien ; si vous voulez, j'ai toutes
les photos (un peu floues hélas).
FR: Le talon aiguille de Wolf est exposé au Musée du Ritz.
-+- in: Guide du Cabaliste Usenet - Wolf : L'étalon aiguille ? -+-
Le Fri, 24 Jun 2005 09:14:17 +0000, Fabien LE LEZ a écrit :
Un serveur web fonctionne rarement en mode "lecture seule" : généralement, il contient des scripts et/ou des CGI qui s'attendent à pouvoir écrire des données sur le disque.
J'aurais tendance à aller dans l'autre-sens, dans la mesure où la plupart des applications que j'ai vues en production s'appuyaient sur des bases de données pour le stockage des données, les autres ayant toutes été vouées à la migration vers une SGBDR tellement c'était cochon. Tu me diras, une BDD, c'est stocké sur le disque, ce que je t'accorde volontiers, mais pas par le serveur HTTP.
C'est mon expérience à 0,02EUR...
-- MB: Wolf est dans un grand hôtel parisien ; si vous voulez, j'ai toutes les photos (un peu floues hélas). FR: Le talon aiguille de Wolf est exposé au Musée du Ritz. -+- in: Guide du Cabaliste Usenet - Wolf : L'étalon aiguille ? -+-
MaXX
F. Senault wrote:
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é. Pour ma part je n'ai jamais eu de bol avec Freebie, mais je n'ai pas
réessayé depuis un bon moment et j'avais fais mes essais dans la précipitation (trop content d'avoir reçu mon Netfinity 7000).
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 :
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). Je vais réessayer tout ça en essayant de prendre des notes lisibles...
Avec toutes les idées qui m'ont été données sur f.c.o.b et f.c.s (merci à tous) je crois que je vais commencer par faire un portupgrade de mes quelques ports verollés pour boucher les trous et plancher à mon aise sur une config solide avec toutes les redondances nécessaires (machine de backup quelque part), une bonne surveillance et la sécurité le plus haut possible (tant que la machine est utilisable et fait ce que je veux)
Autre chose, y a-t-il un équivalent de portaudit pour le système autre que de se taper la mailing-list de FreeBSD???
Fred
-- MaXX
Vivement ce soir... Un Péket bien frais pour se détendre!
F. Senault wrote:
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é.
Pour ma part je n'ai jamais eu de bol avec Freebie, mais je n'ai pas
réessayé depuis un bon moment et j'avais fais mes essais dans la
précipitation (trop content d'avoir reçu mon Netfinity 7000).
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 :
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).
Je vais réessayer tout ça en essayant de prendre des notes lisibles...
Avec toutes les idées qui m'ont été données sur f.c.o.b et f.c.s (merci à
tous) je crois que je vais commencer par faire un portupgrade de mes
quelques ports verollés pour boucher les trous et plancher à mon aise sur
une config solide avec toutes les redondances nécessaires (machine de
backup quelque part), une bonne surveillance et la sécurité le plus haut
possible (tant que la machine est utilisable et fait ce que je veux)
Autre chose, y a-t-il un équivalent de portaudit pour le système autre que
de se taper la mailing-list de FreeBSD???
Fred
--
MaXX
Vivement ce soir... Un Péket bien frais pour se détendre!
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é. Pour ma part je n'ai jamais eu de bol avec Freebie, mais je n'ai pas
réessayé depuis un bon moment et j'avais fais mes essais dans la précipitation (trop content d'avoir reçu mon Netfinity 7000).
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 :
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). Je vais réessayer tout ça en essayant de prendre des notes lisibles...
Avec toutes les idées qui m'ont été données sur f.c.o.b et f.c.s (merci à tous) je crois que je vais commencer par faire un portupgrade de mes quelques ports verollés pour boucher les trous et plancher à mon aise sur une config solide avec toutes les redondances nécessaires (machine de backup quelque part), une bonne surveillance et la sécurité le plus haut possible (tant que la machine est utilisable et fait ce que je veux)
Autre chose, y a-t-il un équivalent de portaudit pour le système autre que de se taper la mailing-list de FreeBSD???
Fred
-- MaXX
Vivement ce soir... Un Péket bien frais pour se détendre!
espie
In article <d9cr0m$3bs$, 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).
Ils ont mtree chez FreeBSD ? dans OpenBSD, c'est l'outil du systeme de base qui permet de faire ca...
sinon, tripwire, aide...
aide doit etre dans les ports.
In article <d9cr0m$3bs$1@talisker.lacave.net>,
MaXX <bs139412@skynet.be> 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).
Ils ont mtree chez FreeBSD ? dans OpenBSD, c'est l'outil du systeme de base
qui permet de faire ca...
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).
Ils ont mtree chez FreeBSD ? dans OpenBSD, c'est l'outil du systeme de base qui permet de faire ca...
sinon, tripwire, aide...
aide doit etre dans les ports.
espie
In article , VANHULLEBUS Yvan wrote:
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).
Concretement, on ne sait pas generer un fichier ayant le meme MD5 qu'un fichier donne, mais on sait generer deux fichiers de MD5 identique.
Ca veut dire que toutes les applications ou `le mechant' controle le fichier de base et utilise MD5 pour prouver son authenticite sont cassees.
Par contre, celle ou le gentil utilise MD5 pour s'assurer que son fichier ne va pas etre corrompu sont encore valables.
La question qui se pose, c'est la perennite de la chose: MD5 a du plomb dans l'aile, et peut-etre que la prochaine faille finira de tout casser. Note que SHA1 n'est pas beaucoup mieux loti, il se pose la question de savoir par quoi les remplacer...
In article <87is05wjig.fsf@actarus.zen.inc>,
VANHULLEBUS Yvan <vanhu@nospam_free.fr> wrote:
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).
Concretement, on ne sait pas generer un fichier ayant le meme MD5 qu'un
fichier donne, mais on sait generer deux fichiers de MD5 identique.
Ca veut dire que toutes les applications ou `le mechant' controle le
fichier de base et utilise MD5 pour prouver son authenticite sont cassees.
Par contre, celle ou le gentil utilise MD5 pour s'assurer que son fichier
ne va pas etre corrompu sont encore valables.
La question qui se pose, c'est la perennite de la chose: MD5 a du plomb
dans l'aile, et peut-etre que la prochaine faille finira de tout casser.
Note que SHA1 n'est pas beaucoup mieux loti, il se pose la question de
savoir par quoi les remplacer...
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).
Concretement, on ne sait pas generer un fichier ayant le meme MD5 qu'un fichier donne, mais on sait generer deux fichiers de MD5 identique.
Ca veut dire que toutes les applications ou `le mechant' controle le fichier de base et utilise MD5 pour prouver son authenticite sont cassees.
Par contre, celle ou le gentil utilise MD5 pour s'assurer que son fichier ne va pas etre corrompu sont encore valables.
La question qui se pose, c'est la perennite de la chose: MD5 a du plomb dans l'aile, et peut-etre que la prochaine faille finira de tout casser. Note que SHA1 n'est pas beaucoup mieux loti, il se pose la question de savoir par quoi les remplacer...
MaXX
Cedric Blancher wrote: [...]
J'aurais tendance à aller dans l'autre-sens, dans la mesure où la plupart des applications que j'ai vues en production s'appuyaient sur des bases de données pour le stockage des données, les autres ayant toutes été vouées à la migration vers une SGBDR tellement c'était cochon. Tu me diras, une BDD, c'est stocké sur le disque, ce que je t'accorde volontiers, mais pas par le serveur HTTP. Faut être sûr que les applis/CGIs/autres sont propres... Par ex un machin
qui permet une injection SQL; dans ce cas que la BDD soit locale ou distante ne changera rien, seuls les droits sur les différents objets peuvent éviter de tout casser (au moins limiter les dégâts).
-- MaXX
Cedric Blancher wrote:
[...]
J'aurais tendance à aller dans l'autre-sens, dans la mesure où la
plupart des applications que j'ai vues en production s'appuyaient sur des
bases de données pour le stockage des données, les autres ayant toutes
été vouées à la migration vers une SGBDR tellement c'était cochon. Tu me
diras, une BDD, c'est stocké sur le disque, ce que je t'accorde
volontiers, mais pas par le serveur HTTP.
Faut être sûr que les applis/CGIs/autres sont propres... Par ex un machin
qui permet une injection SQL; dans ce cas que la BDD soit locale ou
distante ne changera rien, seuls les droits sur les différents objets
peuvent éviter de tout casser (au moins limiter les dégâts).
J'aurais tendance à aller dans l'autre-sens, dans la mesure où la plupart des applications que j'ai vues en production s'appuyaient sur des bases de données pour le stockage des données, les autres ayant toutes été vouées à la migration vers une SGBDR tellement c'était cochon. Tu me diras, une BDD, c'est stocké sur le disque, ce que je t'accorde volontiers, mais pas par le serveur HTTP. Faut être sûr que les applis/CGIs/autres sont propres... Par ex un machin
qui permet une injection SQL; dans ce cas que la BDD soit locale ou distante ne changera rien, seuls les droits sur les différents objets peuvent éviter de tout casser (au moins limiter les dégâts).
-- MaXX
Dominique Blas
[...]
- Quelle serait l'efficacite d'un serveur qui servirait des pages web lues sur une machine distante ? Je pense a une machine frontale qui aurait une seconde carte reseau pour prendre ses donnees sur un serveur nfs en mode read-only situe sur un reseau pas directement accessible de l'exterieur. Est-ce que ce serait efficace (en terme de secu) ou est-ce que ca apporterait plus de probleme que de solutions?
En terme de fiabilité ce n'est pas bon : tu compliques la chaîne de liaison inutilement. Cela rajoute un élément faillible (et hautement) en plus du disque, de la CPU, de la mémoire, du réseau côté Internet, du routeur et de l'accès lui-même sans parler du fournisseur. C'est un ajout << actif >>.
Si le partage NFS saute (pour quelque raison que ce soit) ton service est out.
En outre, si ton service Web est très sollicité tu sollicites également le réseau interne. Si tu tiens à une telle config il vaudrait mieux t'orienter vers du SAN ou, du moins, une baie raccordée en Gbit ou en Fiber Channel. C'est fait pour cela : tu dédoubles tes données d'une part et d'autre part tu bénéficies de la possibilité de les placer en lecture seule. Mais c'est dans ce sens que ça fonctionne : tu as d'ABORD besoin du SAN et tu en profites ENSUITE pour réaliser la mise en lecture seule.
La solution de la machine de surveillance est, à mon avis, la plus simple et la plus économique. C'est une action << passive >> : si elle tombe en panne elle ne pénalise pas le service, il sera simplement plus vulnérable ; elle permet de rationaliser les autorisations d'accès et le circuit de mise à jour ; elle offre, en outre, la possibilité de superviser le serveur.
- Est-ce que faire un serveur virtuel peut aider (exemple usermode-linux sous linux, mais y'a pas que ca)? De mon point de vue ca permettrait d'avoir sur une meme machine une image d'une partition de reference et un serveur virtuel tournant sur une copie de cette partition. Est-ce que ca parait viable ou est-ce qu'il est trop facile de remonter du serveur virtuel a la vraie machine?
Il est possible sous certaines conditions de remonter d'un espace chrooté vers la machine. Pour une machine virtuelle cela dépend du soft de virtualisation mais ce doit être possible si une faille existe, oui. Je n'en sais pas davantage.
En ce qui concerne les serveurs virtuels c'est avant tout pour des questions de coût que le principe se répand. En terme de sécurité ça peut apporter un plus dans la notion de contingentement (un piratage n'affecte que la machine virtuelle) et de secours des données (image de la partition réalisée à intervalle régulier).
Est-ce que je suis trop parano/complique/irrealiste?
Non mais tout a un coût et un MRBF. Le serveur NFS c'est fragile et le jeu n'en vaut pas la chandelle à moins de pouvoir se permettre des indisponiblités conséquentes. Le serveur virtuel c'est avant tout la raison de la mutualisation qui fera pencher vers cette solution. Ceci dit, cela est valable en 2005. En 2006 le raisonnement sera peut-être différent.
db
--
Courriel : usenet blas net
[...]
- Quelle serait l'efficacite d'un serveur qui servirait des pages web
lues sur une machine distante ? Je pense a une machine frontale qui
aurait une seconde carte reseau pour prendre ses donnees sur un serveur
nfs en mode read-only situe sur un reseau pas directement accessible de
l'exterieur. Est-ce que ce serait efficace (en terme de secu) ou est-ce
que ca apporterait plus de probleme que de solutions?
En terme de fiabilité ce n'est pas bon : tu compliques la chaîne de
liaison inutilement. Cela rajoute un élément faillible (et hautement)
en plus du disque, de la CPU, de la mémoire, du réseau côté Internet, du
routeur et de l'accès lui-même sans parler du fournisseur.
C'est un ajout << actif >>.
Si le partage NFS saute (pour quelque raison que ce soit) ton service
est out.
En outre, si ton service Web est très sollicité tu sollicites également
le réseau interne.
Si tu tiens à une telle config il vaudrait mieux t'orienter vers du SAN
ou, du moins, une baie raccordée en Gbit ou en Fiber Channel.
C'est fait pour cela : tu dédoubles tes données d'une part et d'autre
part tu bénéficies de la possibilité de les placer en lecture seule.
Mais c'est dans ce sens que ça fonctionne : tu as d'ABORD besoin du SAN
et tu en profites ENSUITE pour réaliser la mise en lecture seule.
La solution de la machine de surveillance est, à mon avis, la plus
simple et la plus économique. C'est une action << passive >> : si elle
tombe en panne elle ne pénalise pas le service, il sera simplement plus
vulnérable ; elle permet de rationaliser les autorisations d'accès et le
circuit de mise à jour ; elle offre, en outre, la possibilité de
superviser le serveur.
- Est-ce que faire un serveur virtuel peut aider (exemple usermode-linux
sous linux, mais y'a pas que ca)? De mon point de vue ca permettrait
d'avoir sur une meme machine une image d'une partition de reference et
un serveur virtuel tournant sur une copie de cette partition. Est-ce que
ca parait viable ou est-ce qu'il est trop facile de remonter du serveur
virtuel a la vraie machine?
Il est possible sous certaines conditions de remonter d'un espace
chrooté vers la machine.
Pour une machine virtuelle cela dépend du soft de virtualisation mais ce
doit être possible si une faille existe, oui.
Je n'en sais pas davantage.
En ce qui concerne les serveurs virtuels c'est avant tout pour des
questions de coût que le principe se répand.
En terme de sécurité ça peut apporter un plus dans la notion de
contingentement (un piratage n'affecte que la machine virtuelle) et de
secours des données (image de la partition réalisée à intervalle régulier).
Est-ce que je suis trop parano/complique/irrealiste?
Non mais tout a un coût et un MRBF.
Le serveur NFS c'est fragile et le jeu n'en vaut pas la chandelle à
moins de pouvoir se permettre des indisponiblités conséquentes.
Le serveur virtuel c'est avant tout la raison de la mutualisation qui
fera pencher vers cette solution.
Ceci dit, cela est valable en 2005. En 2006 le raisonnement sera
peut-être différent.
- Quelle serait l'efficacite d'un serveur qui servirait des pages web lues sur une machine distante ? Je pense a une machine frontale qui aurait une seconde carte reseau pour prendre ses donnees sur un serveur nfs en mode read-only situe sur un reseau pas directement accessible de l'exterieur. Est-ce que ce serait efficace (en terme de secu) ou est-ce que ca apporterait plus de probleme que de solutions?
En terme de fiabilité ce n'est pas bon : tu compliques la chaîne de liaison inutilement. Cela rajoute un élément faillible (et hautement) en plus du disque, de la CPU, de la mémoire, du réseau côté Internet, du routeur et de l'accès lui-même sans parler du fournisseur. C'est un ajout << actif >>.
Si le partage NFS saute (pour quelque raison que ce soit) ton service est out.
En outre, si ton service Web est très sollicité tu sollicites également le réseau interne. Si tu tiens à une telle config il vaudrait mieux t'orienter vers du SAN ou, du moins, une baie raccordée en Gbit ou en Fiber Channel. C'est fait pour cela : tu dédoubles tes données d'une part et d'autre part tu bénéficies de la possibilité de les placer en lecture seule. Mais c'est dans ce sens que ça fonctionne : tu as d'ABORD besoin du SAN et tu en profites ENSUITE pour réaliser la mise en lecture seule.
La solution de la machine de surveillance est, à mon avis, la plus simple et la plus économique. C'est une action << passive >> : si elle tombe en panne elle ne pénalise pas le service, il sera simplement plus vulnérable ; elle permet de rationaliser les autorisations d'accès et le circuit de mise à jour ; elle offre, en outre, la possibilité de superviser le serveur.
- Est-ce que faire un serveur virtuel peut aider (exemple usermode-linux sous linux, mais y'a pas que ca)? De mon point de vue ca permettrait d'avoir sur une meme machine une image d'une partition de reference et un serveur virtuel tournant sur une copie de cette partition. Est-ce que ca parait viable ou est-ce qu'il est trop facile de remonter du serveur virtuel a la vraie machine?
Il est possible sous certaines conditions de remonter d'un espace chrooté vers la machine. Pour une machine virtuelle cela dépend du soft de virtualisation mais ce doit être possible si une faille existe, oui. Je n'en sais pas davantage.
En ce qui concerne les serveurs virtuels c'est avant tout pour des questions de coût que le principe se répand. En terme de sécurité ça peut apporter un plus dans la notion de contingentement (un piratage n'affecte que la machine virtuelle) et de secours des données (image de la partition réalisée à intervalle régulier).
Est-ce que je suis trop parano/complique/irrealiste?
Non mais tout a un coût et un MRBF. Le serveur NFS c'est fragile et le jeu n'en vaut pas la chandelle à moins de pouvoir se permettre des indisponiblités conséquentes. Le serveur virtuel c'est avant tout la raison de la mutualisation qui fera pencher vers cette solution. Ceci dit, cela est valable en 2005. En 2006 le raisonnement sera peut-être différent.
db
--
Courriel : usenet blas net
Dominique Blas
[...]
SMS? Short Message System?
Service !
Je cherche désespérément un soft qui peut en envoyer via un modem RTC (en cas de panne du routeur ADSL). Ca existe sous Windows mais je n'ai pas encore trouvé sous Linux/*BSD.
J'en utilise un tous les jours : scmxx pour téléphones mobiles Siemens. J'en ai réalisé la traduction en français. Mais il faut un modem-GSM, c'est cher, c'est vrai.
Il existe 2 autres solutions : les passerelles Web/SMS et le service SMS sur ligne fixe de FT. Dans le premier cas il suffit d'un client HTTP adhoc (développement sous Perl, PHP, Java, Python ou Ruby) mais c'est indépendant du type d'accès (ADSL, sans-fil ou RTC) mais également payant. Dans le second cas il faut un modem adapté au service (ça existe ?) et ensuite ce sont de << bêtes >> commandes AT à automatiser.
Selon le cas on préférera la première ou la seconde.
[...]
J'endosse tous ces rôles... Mais je suis très (très) loin d'être une bête... J'essaye de faire de mon mieux cependant...
Faut savoir déléguer parfois ou se syndiquer :-)
[...]
C'est la raison pour laquelle je veux vérifier que mes procédures sont OK et que "n'importe qui" qui a déjà un minimum d'expérience avec la ligne de commande est capable de le faire.
Oui, les procédures. Non seulement les procédures mais les vérifier (comme un exercice incendi) à intervalle régulier.
[...]
Faudra que j'essaye.. ça a l'air moins pelant à mettre à jour que le le CD-RW...
Tu mets à jour une autre CF que tu testes sur une machine d'homologation et tu permutes ensuite les 2 CF. Tout comme le CD-RW du reste.
[...]
Je suis en train de pousser pour acheter une vraie armoire ventilée pour mettre les machines, plutôt d'un stupide machin que je sais ouvrir avec un ouvre bouteilles. Quand au réseau "interne", il est super facile à pénétrer... Je ne serais averti que trop tard de la présence d'une nouvelle adresse MAC sur le réseau (arpwatch).
Si tu es près de l'océan tente le bunker :-)
[...]
Comme tu dis ça je sens que je vais relire à deux fois les clauses de mon assurance voyage quand je vais partir en Australie...
L'assurance peut se résumer à débrancher le portable dès le retrait des billets. Du reste c'est surtout le contrat de travail pour lequel il faudra vérifier les clauses : ton employeur pourra-t-il te reprocher de n'avoir pas vérifier qu'il avait bien compris tes consignes ?
[...]
Les coûts (mon temps) je m'en préoccupe peu, je met en place au boulot, je répercute chez moi donc j'allie l'utile à l'agréable en quelques sortes. Je ne me casses pas la tête pour des heures (je sais je suis con).
Tu n'es pas con, c'est con. Car ne pas répercuter ces coûts biaise le véritable coût de l'infrastructure ce qui ne permet pas de comparer par rapport aux solutions équivalentes du marché. Ta hiérarchie est sans doute très contente de cet état mais n'est pas consciente que c'est elle, un jour, qui en paiera les frais.
[...]
Moins il y en en a mieux je me porte et plus je suis résistant au ScriptKiddies lambda, je crois que personnes n'est à l'abri d'un type qui soit plus à l'aise avec un désassembleur qu'avec une femme.
Désassmebler une femme ça a son charme également : MOV, JMP, ADD, SUB, ADD, SUB, MUL !
Ca relève plus du hasard/intérêt/parano.
Le vieux coincé militaire qui rentre de force avec son AMX-30 aussi, c'est vrai.
[...]
Malheureusement, je doute qu'on me le reproche, vu que je suis obligé de repasser régulièrement sur toutes le machines pour vérifier que les antivirus sont à jour. Je pourrais encore ajouter la liste grandissante des ACL de squid pour barrer l'accès à des sites douteux voire pire...
Toi, tu es dans une PME hein ? Ca se voit tout de suite :-)
db
--
Courriel : usenet blas net
[...]
SMS? Short Message System?
Service !
Je cherche désespérément un soft qui peut en
envoyer via un modem RTC (en cas de panne du routeur ADSL). Ca existe sous
Windows mais je n'ai pas encore trouvé sous Linux/*BSD.
J'en utilise un tous les jours : scmxx pour téléphones mobiles Siemens.
J'en ai réalisé la traduction en français.
Mais il faut un modem-GSM, c'est cher, c'est vrai.
Il existe 2 autres solutions : les passerelles Web/SMS et le service SMS
sur ligne fixe de FT.
Dans le premier cas il suffit d'un client HTTP adhoc (développement sous
Perl, PHP, Java, Python ou Ruby) mais c'est indépendant du type d'accès
(ADSL, sans-fil ou RTC) mais également payant.
Dans le second cas il faut un modem adapté au service (ça existe ?) et
ensuite ce sont de << bêtes >> commandes AT à automatiser.
Selon le cas on préférera la première ou la seconde.
[...]
J'endosse tous ces rôles... Mais je suis très (très) loin d'être une bête...
J'essaye de faire de mon mieux cependant...
Faut savoir déléguer parfois ou se syndiquer :-)
[...]
C'est la raison pour laquelle je veux vérifier que mes procédures sont OK et
que "n'importe qui" qui a déjà un minimum d'expérience avec la ligne de
commande est capable de le faire.
Oui, les procédures. Non seulement les procédures mais les vérifier
(comme un exercice incendi) à intervalle régulier.
[...]
Faudra que j'essaye.. ça a l'air moins pelant à mettre à jour que le le
CD-RW...
Tu mets à jour une autre CF que tu testes sur une machine d'homologation
et tu permutes ensuite les 2 CF.
Tout comme le CD-RW du reste.
[...]
Je suis en train de pousser pour acheter une vraie armoire ventilée pour
mettre les machines, plutôt d'un stupide machin que je sais ouvrir avec un
ouvre bouteilles.
Quand au réseau "interne", il est super facile à pénétrer... Je ne serais
averti que trop tard de la présence d'une nouvelle adresse MAC sur le
réseau (arpwatch).
Si tu es près de l'océan tente le bunker :-)
[...]
Comme tu dis ça je sens que je vais relire à deux fois les clauses de mon
assurance voyage quand je vais partir en Australie...
L'assurance peut se résumer à débrancher le portable dès le retrait des
billets.
Du reste c'est surtout le contrat de travail pour lequel il faudra
vérifier les clauses : ton employeur pourra-t-il te reprocher de n'avoir
pas vérifier qu'il avait bien compris tes consignes ?
[...]
Les coûts (mon temps) je m'en préoccupe peu, je met en place au boulot, je
répercute chez moi donc j'allie l'utile à l'agréable en quelques sortes. Je
ne me casses pas la tête pour des heures (je sais je suis con).
Tu n'es pas con, c'est con. Car ne pas répercuter ces coûts biaise le
véritable coût de l'infrastructure ce qui ne permet pas de comparer par
rapport aux solutions équivalentes du marché. Ta hiérarchie est sans
doute très contente de cet état mais n'est pas consciente que c'est
elle, un jour, qui en paiera les frais.
[...]
Moins il y en en a mieux je me porte et plus je suis résistant au
ScriptKiddies lambda, je crois que personnes n'est à l'abri d'un type qui
soit plus à l'aise avec un désassembleur qu'avec une femme.
Désassmebler une femme ça a son charme également :
MOV, JMP, ADD, SUB, ADD, SUB, MUL !
Ca relève plus
du hasard/intérêt/parano.
Le vieux coincé militaire qui rentre de force avec son AMX-30 aussi,
c'est vrai.
[...]
Malheureusement, je doute qu'on me le reproche, vu que je suis obligé de
repasser régulièrement sur toutes le machines pour vérifier que les
antivirus sont à jour. Je pourrais encore ajouter la liste grandissante des
ACL de squid pour barrer l'accès à des sites douteux voire pire...
Toi, tu es dans une PME hein ? Ca se voit tout de suite :-)
Je cherche désespérément un soft qui peut en envoyer via un modem RTC (en cas de panne du routeur ADSL). Ca existe sous Windows mais je n'ai pas encore trouvé sous Linux/*BSD.
J'en utilise un tous les jours : scmxx pour téléphones mobiles Siemens. J'en ai réalisé la traduction en français. Mais il faut un modem-GSM, c'est cher, c'est vrai.
Il existe 2 autres solutions : les passerelles Web/SMS et le service SMS sur ligne fixe de FT. Dans le premier cas il suffit d'un client HTTP adhoc (développement sous Perl, PHP, Java, Python ou Ruby) mais c'est indépendant du type d'accès (ADSL, sans-fil ou RTC) mais également payant. Dans le second cas il faut un modem adapté au service (ça existe ?) et ensuite ce sont de << bêtes >> commandes AT à automatiser.
Selon le cas on préférera la première ou la seconde.
[...]
J'endosse tous ces rôles... Mais je suis très (très) loin d'être une bête... J'essaye de faire de mon mieux cependant...
Faut savoir déléguer parfois ou se syndiquer :-)
[...]
C'est la raison pour laquelle je veux vérifier que mes procédures sont OK et que "n'importe qui" qui a déjà un minimum d'expérience avec la ligne de commande est capable de le faire.
Oui, les procédures. Non seulement les procédures mais les vérifier (comme un exercice incendi) à intervalle régulier.
[...]
Faudra que j'essaye.. ça a l'air moins pelant à mettre à jour que le le CD-RW...
Tu mets à jour une autre CF que tu testes sur une machine d'homologation et tu permutes ensuite les 2 CF. Tout comme le CD-RW du reste.
[...]
Je suis en train de pousser pour acheter une vraie armoire ventilée pour mettre les machines, plutôt d'un stupide machin que je sais ouvrir avec un ouvre bouteilles. Quand au réseau "interne", il est super facile à pénétrer... Je ne serais averti que trop tard de la présence d'une nouvelle adresse MAC sur le réseau (arpwatch).
Si tu es près de l'océan tente le bunker :-)
[...]
Comme tu dis ça je sens que je vais relire à deux fois les clauses de mon assurance voyage quand je vais partir en Australie...
L'assurance peut se résumer à débrancher le portable dès le retrait des billets. Du reste c'est surtout le contrat de travail pour lequel il faudra vérifier les clauses : ton employeur pourra-t-il te reprocher de n'avoir pas vérifier qu'il avait bien compris tes consignes ?
[...]
Les coûts (mon temps) je m'en préoccupe peu, je met en place au boulot, je répercute chez moi donc j'allie l'utile à l'agréable en quelques sortes. Je ne me casses pas la tête pour des heures (je sais je suis con).
Tu n'es pas con, c'est con. Car ne pas répercuter ces coûts biaise le véritable coût de l'infrastructure ce qui ne permet pas de comparer par rapport aux solutions équivalentes du marché. Ta hiérarchie est sans doute très contente de cet état mais n'est pas consciente que c'est elle, un jour, qui en paiera les frais.
[...]
Moins il y en en a mieux je me porte et plus je suis résistant au ScriptKiddies lambda, je crois que personnes n'est à l'abri d'un type qui soit plus à l'aise avec un désassembleur qu'avec une femme.
Désassmebler une femme ça a son charme également : MOV, JMP, ADD, SUB, ADD, SUB, MUL !
Ca relève plus du hasard/intérêt/parano.
Le vieux coincé militaire qui rentre de force avec son AMX-30 aussi, c'est vrai.
[...]
Malheureusement, je doute qu'on me le reproche, vu que je suis obligé de repasser régulièrement sur toutes le machines pour vérifier que les antivirus sont à jour. Je pourrais encore ajouter la liste grandissante des ACL de squid pour barrer l'accès à des sites douteux voire pire...
Toi, tu es dans une PME hein ? Ca se voit tout de suite :-)
db
--
Courriel : usenet blas net
Cedric Blancher
Le Fri, 24 Jun 2005 11:34:14 +0000, MaXX a écrit :
Faut être sûr que les applis/CGIs/autres sont propres... Par ex un machin qui permet une injection SQL; dans ce cas que la BDD soit locale ou distante ne changera rien, seuls les droits sur les différents objets peuvent éviter de tout casser (au moins limiter les dégâts).
Tu remarqueras que je n'ai pas dit que c'était plus sûr, mais que ça évitait que le httpd n'écrive sur le disque. Et je n'ai pas non plus parlé de distance... Bref...
-- Je constate que à part ceux qui sont contre, ces 2 groupes rencontrent un consensus. On est à 100% d'accord, excellent ! -+-GA in : Guide du Neuneu d'Usenet - Le consensus pour les nuls -+-
Le Fri, 24 Jun 2005 11:34:14 +0000, MaXX a écrit :
Faut être sûr que les applis/CGIs/autres sont propres... Par ex un machin
qui permet une injection SQL; dans ce cas que la BDD soit locale ou
distante ne changera rien, seuls les droits sur les différents objets
peuvent éviter de tout casser (au moins limiter les dégâts).
Tu remarqueras que je n'ai pas dit que c'était plus sûr, mais que ça
évitait que le httpd n'écrive sur le disque. Et je n'ai pas non plus
parlé de distance... Bref...
--
Je constate que à part ceux qui sont contre, ces 2 groupes rencontrent
un consensus. On est à 100% d'accord, excellent !
-+-GA in : Guide du Neuneu d'Usenet - Le consensus pour les nuls -+-
Le Fri, 24 Jun 2005 11:34:14 +0000, MaXX a écrit :
Faut être sûr que les applis/CGIs/autres sont propres... Par ex un machin qui permet une injection SQL; dans ce cas que la BDD soit locale ou distante ne changera rien, seuls les droits sur les différents objets peuvent éviter de tout casser (au moins limiter les dégâts).
Tu remarqueras que je n'ai pas dit que c'était plus sûr, mais que ça évitait que le httpd n'écrive sur le disque. Et je n'ai pas non plus parlé de distance... Bref...
-- Je constate que à part ceux qui sont contre, ces 2 groupes rencontrent un consensus. On est à 100% d'accord, excellent ! -+-GA in : Guide du Neuneu d'Usenet - Le consensus pour les nuls -+-