briaeros007 a écrit 9441 commentaires

il a enregistré un site dans le nom correspond à une marque notoire sur laquelle il n'a aucun droit

Ah non, le nom ne correspond pas, le nom contient. Implication n'est pas équivalence!

il profite de la notoriété pour drainer du trafic sur le site web utilisant le nom de domaine (il n'est pas précisé qu'on doit en tirer du profit)

Ah, et de quelle façon ? Tu veux dire que si RATP est 5 fois plus connus que maintenant, et sans aucun incidents, le domaine aura 5 fois plus de visites ? Et si RATP est 5 fois moins connus que maintenant mais avec 2 fois plus d'incidents que maintenant, le site aura 5 fois moins de visites ? J'y crois pas trop.

il nuit à l'image de la marque ou de la société (ben oui, présenter les incidents c'est pas vraiment positif - ça me paraissait à peu près clair)

Oula on se calme. Présenter la réalité ce n'est pas avoir la volontée de nuire hein. Si une société exploite des enfants dans des pays du tiers monde, il faut surtout pas en parler parce que ça "nuit à l'image de la marque" ? Bien sur que si!

si la licence ne leur plait pas, ils respectent la licence et ne touchent pas au logiciel.
Ah vraiment?
Et ça, c'est quoi alors ?
http://www.zdnet.fr/actualites/microsoft-contraint-de-publie(...)


Donc quand la licence ne leur plait pas, ils font croire que c'est à eux et emmerde les autres.
Et seulement une fois qu'ils ne peuvent pas/plus nier qu'ils ont piqué du code, ils sont "d'accord" (comme si ils avaient le choix) pour accepter la licence.

Ne pas tout confondre, merci.

oh il le fera, ne t'inquiète pas.

pourtant ca semble pas les gêner d'imposer des tas de trucs dans leur cluf.

Ils aiment bien faire aux autres ce qu'ils n'aiment pas qu'on leur fait ?
Me semble pas très chrétien comme façon de faire :P

juste pour troller :
ce qui fait qu'ajourd'hui les gens téléchargent en HTTP 1.1 et pensent être en bonne conscience « J'ai un MSOffice tipiaké, mais j'ai pas fauté, c'est pas sur zMule que je l'ai téléchargé »

Et ceux qui utilisent http 1.0, ils ont bonne ou mauvaise conscience ?

arrête tu vas me faire pleurer....

ça veut pas dire que le prix est justifié.

Mon ancienne fac payait environ, si je ne dis pas de connerie, 500 k à 750k de lignes spécialisé pour connecter ses différents sites (17 environs).

Un moment ils ont eu la possibilité de se "patcher" sur un projet départemental/régional/... de pose de fibre, et ils donc reçu quelques fibres noires entre 3 de leurs plus gros sites.

Il fallait qu'ils paient la fibre, plus un certain nombre d'investissement toussa.

Bref un ticket de plusieurs millions d'euros, sans compter les routeurs nécessaires pour gérer tout le traffic qui allait passer.

Ils avaient un ROI en moins de 5 ans.

Donc tu n'arriveras pas à me faire pleurer sur les pauvres LS qui coutent extrêmement cher au opérateur pour atteindre du pauvre 200 kbps.

si tu pars dans les jeux, les démos actuelles font toutes 1 ou 2 Go...
Au rythme de deux démos par semaine, ca te fait déjà 16 Go rien que pour les demo

ah c'est cher la bp ?

Dans un accord de peering, ca vaut, tiens toi bien, 0€.

Allez tu as les couts fixes (électricité, location des baies, et investissement), mais c'est absolument pas dépendant du débit.

je travaille avec des serveurs de pro à l'autre bout (ben oui google c'est des pros), donc il faut que je paie un abonnement de pro ?

que tu n'en ais pas l'utilité ne veux pas dire que d'autres n'en on pas l'utilité.

oui mais non.

Si tu parles de la TV sur adsl, j'ai l'honneur de t'informer qu'elles sont déjà transmises en multicast dans le réseau de coeur.

tiens, on peut pas le faire avec un petit moteur, une webcam, et une box adsl ?
bizarre ... XD

swap cause conséquence.

ca va pas détecter une véritable compromission bien menée, et il peut y avoir deux trois faux positifs, mais ils sont intéressant :
-> chkrootkit
-> pour debian et dérivée : debsums

Ensuite, savoir à quoi correspond ces ports (netstat -alpent |grep -e 443 -e 1720) lorsqu'ils sont ouverts peut être interessant

Vérifier si les ports "fermés" sont toujours protégés par gufw.

Et vérifier si lorsque ces ports sont ouverts, ce n'est pas suite à une requête upnp

ça ne me semble pas si gagné d'avance, car c'est exactement ce qui se passe actuellement sur les consoles (en bien pire), et la justice américaine ne semble pas plus émue que ça.

Quand à la justice francçaise, elle ne c'est pas non plus emparée du dossier, même quand sony a décidé de _supprimer_ des fonctionnalitées à distance.

ben là tu sais que c'est bon, et tu fais \rm

oui, mais c'est une interface graphique à gdb, donc je doute fortement qu'il comprenne "of" ou "if"

ça peut se passer par udev, et on peut dire que tel utilisateur à le droit sur le péréphirique mode bloc / carac de tel device.

je fréquente pas, je recherche ...

a marche pas non plus chez moi
cat /foo/bar/[...].avi > /mnt
zsh: est un dossier: /mnt
zsh/2 17 [1] # df -h /mnt
Sys. de fichiers Taille Uti. Disp. Uti% Monté sur
/dev/loop0 504M 17M 462M 4% /mnt

A moins que tu ais fait directement sur la device, en root, mais dans ce cas tu cherchais beaucoup énormément les ennuis.

en même temps les updates sont faites par toi, donc quand tu as un message qui dis "coucou il y a eu tout ça qui a changé" le même jour que ton update, tu sais d'où ça vient ;)

Ensuite si tu n'as pas trop envie de te prendre la tête, tu peux toujours utiliser "debchecksum" sous debian, qui va checker les md5 des binaires avec le md5 stocké dans le paquet (il faut donc que /var/lib, de tête, et les binaires de debchecksum soient sur).

pour puppet et cfengine, jamais utilisé. Mais cfengine pour moi est plus un repo/validation de conf, qu'un outil de monitoring.et de relance.

enfin si un simple driver suffit à détruire une carte graphique (sans mise à jour de son firmware itou), c'est que de base la carte graphique a été faite avec deux pieds gauches!

en virtualisation : les processus et les fichiers sont isolés les uns des autres. Le seul lien entre machines passe par le réseau (penser à configurer son garde-barrière)
Le seul lien entre les machines invitées.
Parce que l'hote à accès à tout.




Pour ce qui est continuité du service, un MAC* n'apportera rien du tout.
(* : oui je viens de me rendre compte que j'ai inversé MAC et DAC dans mon précédent message

DAC -> on peut les modifier.
Ca veut dire "Discretionnary Access Control"

MAC -> on ne peut pas
Ca veut dire "Mandatory Access Control"
)
--------------------------- POINT 1 --------------------------------------
1 - la confidentialité de certaines données


Donc point "1", quelques éclaircissement sur les MAC.
(je pense que la virtualisation tu as déjà une bonne idée).

sur les MAC, il y a deux approches, les approches par label, et les approches par pathname.
apparmor travaille sur les chemins de fichier, alors que selinux travaille sur les labels.

Ensuite je ne te cache pas qu'une MAC est pas forcément simple a configurer, mais normalement la plupart des services basiques ont déjà leur règles selinux, et que si le service ne fait rien de trop particulier, ça ne pose pas plus de problème que ça à configurer (comme disais eric gerbier, tu lance le "learning mode" (ou mode persmissif sous selinux)
tu as la liste des accès qui sont censés être refusés, et ensuite tu créé ta règle, après avoir vu ceux qui sont normal, et ceux qui sont inutiles (par exemple un certain nombre de soft essaient d'ouvrir /dev/urandom, mais en réalité n'en ont absolument pas besoin).


Le gros intérêt de selinux, c'est le mode MLS (assez mal supporté par les distribs, donc il faudra mettre la main à la pate), qui permet de faire de la hierarchie dans les droits (par exemple top secret > secret > confidential), avec des règles style bell lapadula

De base selinux (sans mls) permet aussi de faire de la catégorisation (MCS : multi catégory security).
Apparmor je ne connais pas donc je ne peux pas trop te dire, mais je pense que ça ne pose forcément trop de problème.

Ensuite , si on le veut avec selinux, même en étant admin de la machine, on peut bloquer la possibilité de changer les règles de sécurité et de voir les audits de sécu et les données (on peut lancer/arrêter les services etc..., mais pas interagire avec la sécurité selinux)


Bien entendu ces règles ne s'entendent pas avec un accès physique à la machine ;)


Bref, on peut faire des trucs très complet, mais peut être beaucoup overkill pour un truc perso.


Le problème de la virtualisation, c'est que c'est la même approche de la sécurité que le NAT, ça n'a pas été pensé pour.
Si j'ai un accès à une de tes machines, il faut que j'ai accès aux autres.
Donc il faut que tu blinde chacune de tes machines virtuelle, non seulement contre l'extérieur, mais aussi contre chacune de ses copines, parce que dès qu'une de ses copines est infectée elle va servir de relais d'attaque et de bastion.

Niveau temps et complexité sur la conf à faire en plus, je pense que la virtualisation est gagnante (moins couteux en temps, et plus "classique" ).
Niveau challenge, ben c'est inversement proportionnel ;)


------------------------------ POINT 2 ------------------------------------

2 - l'intégrité des données du serveur
Quel que soit la solution, comme disait goëdel (incomplétude toussa), on ne peut pas s'assurer que l'ensemble est bon si on reste au sein du même ensemble.

Il faut donc avoir fatalement une base, considéré comme "sur" (accès en lecture seule) indiquant une signature des données.
Il faut aussi que le logiciel/... qui effectue la vérification soit sur (sur ce même accès).

Une fois que ce postulat est complété, tu as plusieurs logiciels qui font ça, comme samhain ou tripwire, de tête.


Mais quel que soit la solution choisie, tu auras le même problème.

---------------------------------- POINT 3 ----------------------------------
3 - la continuité des services (à mon niveau bien sûr, pas à 100%)

Quel que soit la solution choisis, il faudra détecter la perte de service, et le relancer.
Sachant que la perte de service n'implique pas forcément la perte du système (par exemple, un système de virtualisation peut considérer que tout fonctionne bien même si le service applicatif ne tourne pas dans l'OS invité).

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

Par contre, le gros "plus" des VM "niveau OS" (et au dessus : noyau + os) , c'est que si tu te trompe dans la conf de la machine, tu as toujours la solution de repli d'attaquer l'host pour reconfigurer la vm.



Bon c'est un peu brouillon, donc je me delande si je ne t'ai pas plus embrouillé qu'autre chose ^^

faudrait déjà qu'elles embauchent en direct, cad autrement que par des SSII