epmap ?

Le 02 Dec 2003 09:55:08 GMT, Cedric Blancher a ecrit:
|> dans une declaration de principe, non.
|
| En sécurité, les principes doivent être confrontés à la dure
| réalité...
|
<troll>
J'ai laisse un windows2000 a poil sur internet (pas de FW ni d'AV)
pendant une vingtaine d'heure pour essayer emule.
Oh surprise: rien. Pas de virus, pas de troyen, pas de pourrissement
de machine. Etonnant, non?
J'etais seulement passe sur windows update avant de la mettre en prise
directe sur l'internet.
</troll>

|> Mais par rapport a ma question initiale d'arreter les machines a
|> distance via le port 4444, pas de commentaires?
|
| Pourquoi les arrêter alors que tu peux les désinfecter et les patcher
| par ce même moyen ? voir "Honeyd Vs MSBLAST.EXE" :
|
| http://www.citi.umich.edu/u/provos/honeyd/msblast.html
|
Oui, j'avais lu ca sur ce groupe. Mais bon, patcher des machines
qui ne sont pas les miennes, ca me laisse un peu froid.

--
Kevin

<troll>
J'ai laisse un windows2000 a poil sur internet (pas de FW ni d'AV)
pendant une vingtaine d'heure pour essayer emule.
</troll>

un uptime de 20 heures ;-)) j'espère que tes 350 serveurs de prod n'ont pas
le même ... ;p

|> Mais par rapport a ma question initiale d'arreter les machines a
|> distance via le port 4444, pas de commentaires?

non pas de commentaire, tout le monde est libre de faire ce qu'il veut....
arrêter une machine infectée oui , mais lorsqu'elle redémarre tu les éteinds
à nouveau ? sinon ça sert pas à grand chose...vaut mieux les patcher comme
le dit cedric ou plus plus soigneusement juste arrêter le service à problème
et laisser les autres tourner!

| Pourquoi les arrêter alors que tu peux les désinfecter et les patcher
| par ce même moyen ? voir "Honeyd Vs MSBLAST.EXE" :

dans ton réseau local bien sûr :)

Oui, j'avais lu ca sur ce groupe. Mais bon, patcher des machines
qui ne sont pas les miennes, ca me laisse un peu froid.

AHMA c'est mieux que les rebooter mais de toute façon les 2 sont interdites
...


A+

Dans sa prose, Kevin DENIS nous ecrivait :

J'ai laisse un windows2000 a poil sur internet (pas de FW ni d'AV) pendant
une vingtaine d'heure pour essayer emule. Oh surprise: rien. Pas de virus,
pas de troyen, pas de pourrissement de machine. Etonnant, non?
J'etais seulement passe sur windows update avant de la mettre en prise
directe sur l'internet.

Tu as bien de la chance, ou suffisament de bande passante. En pleine vague
de Blaster, j'ai vu deux personnes de connecter en RTC et se faire
pourrir avant même d'avoir eu la liste de updates critiques sur Windows
Update. Étonnant, non ?

--
Je parlais au nom de tous les frjviens, ne joue pas au con... VOUS
n'avez pas à détruire NOTRE ng. C'est clair comme ça ou il faut que je
te l'explique avec des mots plus faciles encore ?
-+- in Guide du Neuneu d'Usenet - Mon niouzegroup à moi ke G -+-

On 07 Dec 2003 19:10:46 GMT, Cedric Blancher wrote:

J'ai laisse un windows2000 a poil sur internet (pas de FW ni d'AV) pendant
une vingtaine d'heure pour essayer emule. Oh surprise: rien. Pas de virus,
pas de troyen, pas de pourrissement de machine. Etonnant, non?
J'etais seulement passe sur windows update avant de la mettre en prise
directe sur l'internet.

Tu as bien de la chance, ou suffisament de bande passante. En pleine vague
de Blaster, j'ai vu deux personnes de connecter en RTC et se faire
pourrir avant même d'avoir eu la liste de updates critiques sur Windows
Update. Étonnant, non ?

Des amis ont eu une expérience similaire : un PC acheté en grande
surface le lundi, un accès au net configuré le mardi à 19h, la première
connexion à 19h10 et une machine infectée à 19h11.
Ils n'ont rien eu le temps de faire sur Internet.
L'ordinateur n'arrêtait pas de demarrer car le service RPC de Windows
plantait sans cesse et Windows ne trouve rien de mieux à faire que de
redémarrer la machine quand un service plante. Très pratique.

Ce qui est grave dans cette histoire, c'est que :
- un antivirus était installé sur la machine en standard
- l'utilisateur n'a fait aucune faute, aucune erreur, juste celle de
connecter son ordinateur tout neuf et tout frais installé à Internet

Je trouve ça vraiment effarant de constater que j'ai du envoyer un CD
avec tous les patchs et les service packs actuels, ainsi qu'une
explication sur comment activer le firewall, pour que cet ordinateur
puisse effectuer la tâche banale pour laquelle il avait été acheté !


--
Olivier

"Cedric Blancher" <blancher@cartel-securite.fr> a écrit dans le message de
news:pan.2003.12.01.10.09.27.364998@cartel-securite.fr...
| Je tiens quand même à rappeler que contrairement à CodeRed et Nimda qui
| exploitaient des failles sur un service destiné à Internet, c'était
| loin d'être le cas de Slammer et Blaster. Bref, que les gens qui avaient
| un firewall, même configuré par défaut, n'ont pas été infecté. Et
| dans le cas de Slammer, c'est encore pire, puisque ce sont des
| applications _professionnelles_ qui se sont majoritairement faite
| infecter... Aucune excuse pour ces "professionnels" pas foutu de
| configurer un firewall devant leur backend de BDD...

Si, je leur trouve une excuse quand même (bien que ça ne me soit pas arrivé
et que ça ne me concerne pas directement) : les VPN. Il suffit qu'un
partenaire/filiale avec lequel on est relié en VPN et dont on ne gère pas la
sécurité frontale d'accès à internet soit infecté, parce qu' effectivement
les responsables sécurité de ladite filiale n'ont pas fait leur boulot, pour
qu'on puisse se voir infecté via le VPN. Et si on considère la vitesse de
propagation de slammer on se dit que beaucoup de serveurs ont du être
infectés avant même que les responsables sécu/systèmes aient pensé qu'il
pouvaient être vulnérables si la filiale avec laquelle ils échangent du
traffic concernant la BDD était infectée. Et quand on sait comme certains
rechignent, et parfois à juste titre, à appliquer trop rapidement des patchs
sur un système critique en production... A mon avis, les VPN ont joué un
rôle prépondérant dans l'importante virulence de slammer.

| Limite bien fait pour
| leur gueule (4 jours d'indisponibilité pour je ne sais plus quel
| fournisseur de mail, ça laisse rêveur...).

Caramail, si je ne me trompe pas, mais ils ont toujours été nuls.

--
Fabien SPAGNOLO

Dans sa prose, Fabien SPAGNOLO nous ecrivait :

Si, je leur trouve une excuse quand même (bien que ça ne me soit pas
arrivé et que ça ne me concerne pas directement) : les VPN.

Je suis d'accord, mais ça ne les excuse pas pour autant.

Il suffit qu'un partenaire/filiale avec lequel on est relié en VPN et
dont on ne gère pas la sécurité frontale d'accès à internet soit
infecté, parce qu' effectivement les responsables sécurité de ladite
filiale n'ont pas fait leur boulot, pour qu'on puisse se voir infecté
via le VPN.

Ah oui, mais là non.

Quand on est connecté à un réseau qu'on ne maîtrise pas, même par
VPN, on met ce qu'il faut pour se protéger de ce qui peut se passer chez
l'autre d'en face qui fait pas son boulot. Décharger la responsabilité
de l'inefficacité de sa politique de filtrage sur les partenaires qui
arrivent en VPN ou sur extranet, c'est un peu gros, non ?

Mais les VPNs... Ah les VPNs... Combien de boîtes ont ramassé Blaster
par une connexion VPN nomade ? Où par un mec qui a voulu lire son mail
depuis son PC perso à la maison qu'il n'avait pas mis à jour depuis 3
mois ? Et les laptops ? Hein, les laptops ? Le mec qui revient d'une
mission de 2 mois, qui se connecte à la maison, ramasse son Blaster et
revient sur le réseau corporate...

Caramail, si je ne me trompe pas, mais ils ont toujours été nuls.

C'est pas moi qui l'ait dit ;)

--
BOFH excuse #387:

Your computer's union contract is set to expire at midnight.

"Cedric Blancher" <blancher@cartel-securite.fr> a écrit dans le message de
news:pan.2003.12.07.20.51.39.965922@cartel-securite.fr...
| Ah oui, mais là non.
|
| Quand on est connecté à un réseau qu'on ne maîtrise pas, même par
| VPN, on met ce qu'il faut pour se protéger de ce qui peut se passer chez
| l'autre d'en face qui fait pas son boulot. Décharger la responsabilité
| de l'inefficacité de sa politique de filtrage sur les partenaires qui
| arrivent en VPN ou sur extranet, c'est un peu gros, non ?

Pas si simple, je pense, pour slammer. Imagine que tu administres un réseau
A. Tu as un réseau B, d'une filiale, sur lequel tu n'as pas la main. Sur le
réseau B il y a un sqlserver qui fait par exemple de la réplication avec ton
sqlserver sur ton réseau A par exemple, ou d'autres besoins qui nécessitent
que sqlserver B communique avec sqlserver A (je ne suis pas expert en
sqlserver). Pour cela il y a un VPN entre A et B. Dans ton filtrage tu vas
devoir laisser passer le traffic à destination du port 1434 entre ces 2
machines. Or c'est le port utilisé par slammer. Donc si sqlserver B est
infecté, sqlserver A risque de l'être aussi. Dans un tel cas, difficile
d'empêcher sqlserver A d'être infecté à moins de mettre le patch quelques
minutes après la découverte de slammer. Et quand on connait l'aspect
critique des serveurs de BDD et lorsqu'on sait que slammer est apparu le
week-end...

Bien sûr ça reste une situation théorique censée montrer qu'on peut avoit
été infecté par slammer tout en ayant fait son boulot correctement (on peut
dire aussi qu'il aurait fallu exiger un audit de la sécurité de la filiale
avant, mais bon ...). Bien entendu je pense que dans la vraie vie c'est
certainement la trop grande permissivité entre des réseaux internes qui a
effectivement accru la virulence de slammer.

| Mais les VPNs... Ah les VPNs... Combien de boîtes ont ramassé Blaster
| par une connexion VPN nomade ? Où par un mec qui a voulu lire son mail
| depuis son PC perso à la maison qu'il n'avait pas mis à jour depuis 3
| mois ? Et les laptops ? Hein, les laptops ? Le mec qui revient d'une
| mission de 2 mois, qui se connecte à la maison, ramasse son Blaster et
| revient sur le réseau corporate...

Plein plein plein. Je ne compte plus les clients qui m'ont demandé "Pourquoi
est-ce qu'une de mes machines est infectée par le virus untel sur mon lan
alors que j'ai une passerelle antivirale à jour ?". "Vous avez des
utilisateurs nomades qui se connectent sur internet à l'extérieur ? Oui ?
Vous êtes certain que l'antivirus local est jour ? Vous n'êtes pas sûr ? Eh
bien voilà" .

Toutefois dans le cas de slammer c'est différent car pour être infecté il
faut quand même avoir un sqlserver d'installé ce qui ne se trouve pas sur
les machines nomades, a priori, contrairement aux autres virus. C'est
pourquoi je pense que des réseaux internes infectés alors qu'ils bloquaient
les flux sqlserver depuis internet se sont vus infectés surtout via les VPN.

--
Fabien SPAGNOLO

Des amis ont eu une expérience similaire : un PC acheté en grande
surface le lundi, un accès au net configuré le mardi à 19h, la première
connexion à 19h10 et une machine infectée à 19h11.
Ils n'ont rien eu le temps de faire sur Internet.
L'ordinateur n'arrêtait pas de demarrer car le service RPC de Windows
plantait sans cesse et Windows ne trouve rien de mieux à faire que de
redémarrer la machine quand un service plante. Très pratique.

Je pense que nous avons tous eu des histoires comme ça ;) !

Ce qui est grave dans cette histoire, c'est que :
- un antivirus était installé sur la machine en standard
- l'utilisateur n'a fait aucune faute, aucune erreur, juste celle de
connecter son ordinateur tout neuf et tout frais installé à Internet

Qu'est ce qui est grave ? De toute façon, un antivirus n'est pas la
protection adéquat dans cette histoire. C'est un firewall personnel qui
fallait sur le portable. Un antivirus aussi à jour que tu veux n'aurait
rien pu faire.

Le seul blâme qu'il reste à donner, c'est à Microsoft pour faire des
systèmes troués jusqu'à la moëlle. Mais bon tous les systèmes peuvent
parfois être troués. Le problème ici, c'est que

- ça arrive tout le temps à Microsoft Windows (enfin très souvent).
- l'architecture sécurité de l'OS est mauvaise (séparation des
privilèges, ...)



Julien

"Fabien" == Fabien SPAGNOLO <spagno_f@epita.fr> writes:

Fabien> Sur le réseau B il y a un sqlserver
Fabien> qui fait par exemple de la réplication avec ton sqlserver sur
Fabien> ton réseau A par exemple, ou d'autres besoins qui nécessitent
Fabien> que sqlserver B communique avec sqlserver A (je ne suis pas
Fabien> expert en sqlserver). Pour cela il y a un VPN entre A et B.
Fabien> Dans ton filtrage tu vas devoir laisser passer le traffic à
Fabien> destination du port 1434 entre ces 2 machines. Or c'est le port
Fabien> utilisé par slammer. Donc si sqlserver B est infecté, sqlserver
Fabien> A risque de l'être aussi.

Ben un setup de ce type avec un tiers auquel tu n'accordes qu'une
confiance des plus relatives est une connerie à la base ;)

Il est plus sain de partir sur un export de la base source vers un
fichier texte, suivi d'un import depuis le dit fichier dans la base
cible.

Si tu ne fais pas pleinement confiance à l'autre extrémité du vpn, tu la
traites comme étant potentiellement hostile, ce qui t'évitera ce genre de
déconvenues (la notion de confiance peut reposer sur la maitrise de
l'autre extrémité du vpn ou alors sur un audit sérieux de cette même
extrémité, mais même dans ce cas, des mesures de protection ne sont pas
inutiles)

Eric Masson

--
Merci de ne plus envoyer de messages vide dans les news
-+-Youpy in Guide du Neuneu Usenet - Mais où avais-je l'en-tête -+-

Fabien SPAGNOLO wrote:

Bien sûr ça reste une situation théorique censée montrer qu'on peut avoit
été infecté par slammer tout en ayant fait son boulot correctement (on peut

En théorie oui.
En pratique, un correctif était dispo depuis plusieurs mois, si je ne me
trompe pas. Donc les admins n'ont pas fait leur boulot correctement...
Il me semble que Slammer ne laissait pas de trace sur disque, donc on
peut exclure (sauf mise en veille) le développeur qui a choppé Slammer
sur son portable et qui se reconnecte avec son portable sur le réseau
entreprise.
J'ai consience que ton exemple était choisi juste histoire d'illustrer
tes propos, mais là pour Slammer je persiste à penser que les admins
n'ont pas fait leur boulot (et ils ont été beaucoup).