Re: [FRnOG] [MISC] Re: Diffusion du virus "gendarmerie" par javascripts modifiés

2011-12-25 Thread RobOEM
Bon, OK, on ne navigue pas dans les mêmes sphères, mais:
1) concernant la légalité de faire un grep sur les sites que vous
hébergez : personne ne parle de le faire sur tous les fichiers
présents dans l'espace de stockage que vous louez. Vous pouvez le
faire sur tout ce que vos clients exposent aux Internets (plus
difficile, mais bon), les prévenir le cas échéant qu'ils servent un
contenu malicieux, expliquer comment l'enlever, bref, ajouter un bout
de valeur au service que vous vendez.
2) concernant votre légitimité à faire ça : vous n'en avez aucune si
vous pensez que c'est le cas. En tant qu'utilisateur cependant, je
serais bien content qu'un mec sachant me prévienne d'une brèche sur
mon CMS, même si la solution c'est d'appliquer les patches que je n'ai
pas appliqué depuis 2003. Après, si je veux servir du contenu
malveillant, j'ignorerai le mail, et au pire si on vit dans un état
policier, je bougerai mon hébergement en ukraine ou en israel.
3) ok, les flics sont tous des imbéciles. Mais je vous laisse tous
réfléchir là dessus : http://news.abidjan.net/h/420775.html quand on
laisse le 'net devenir une zone de non-droit, à un moment les
législateurs réagissent et ça n'est pas forcément en faveur de ce que
nous défendons.

C'est pas non plus la mort de prévenir nos clients qu'il hébergent un
contenu malveillant. Ils ont la liberté d'ignorer notre avertissement,
en tous cas pour l'instant.

Mes deux centimes,
--rde

2011/12/25 Michel Py :
>> Thomas Samson a écrit:
>> On pourrait imaginer diffuser aux gens (à ses
>> clients par exemple)  ce genre de quizz :
>> http://www.opendns.com/phishing-quiz/
>> http://www.sonicwall.com/furl/phishing/
>> (et refuser l'accès aux services complets s'ils
>> échouent... on est vendredi, après tout  :) )
>
> Ah, le fameux permis d'utiliser un ordinateur ou de se connecter à l'Internet 
> :-D Un grand classique.
>
> Ce sont des bon liens, et-ce qu'il y a un équivalent en Français?
>
>
>> Morgan Hamart a écrit:
>> j'ai moi même appelé le service de gendarmerie il y a
>> quelques temps pour signaler un gros problème sur le
>> site internet d'une banque...l'accueil n'était pas ce
>> qui se fait de plus chaleureux, et on m'a finalement
>> répondu que j'avais qu'a informer mon conseiller
>> clientèle...
>
> Tu as perdu ton temps, et tu l'as probablement perdu aussi si tu as appelé la 
> banque.
>
> Ce que je fais en tant qu'utilisateur (chacun adapte à son navigateur et 
> langage) c'est Safety -> SmartScreen Filter -> Report Unsafe Website (IE8, 
> EN-US). Ca pointe vers:
> https://feedback.smartscreen.microsoft.com/feedback.aspx
>
> Ca n'enlève pas le virus, mais ça limite la casse. Le temps de réaction est 
> critique, et AMHA c'est aujourd'hui le mécanisme le plus rapide entre la 
> diffusion et le blocage.
>
> Il y a des seuils à franchir, ceci dit, que ce soit pour qu'un humain regarde 
> la page en question ou pour qu'elle soit bloquée automatiquement, donc il est 
> important que tout le monde le fasse.
>
>
>> Pierre Chapuis a écrit:
>> Peut-être plus pour FrSAG que FrNOG ?
>
> Pour la partie vulnérabilité, certainement. Quoi que je me demande si les 
> gens qui n'on pas encore mit les rustines sur les vulnérabilités connues 
> depuis des années la lisent, mais ne décourageons pas les mauvaises volontés. 
> FrSAG me semble nettement mieux ciblé que frnog-alert.
>
> Pour la partie virus, pourquoi ne pas aller directement discuter avec 
> Symantec, Kaspersky, McAffee, Spybot, MalwareBytes et consorts?
>
>
> Tout est dans le temps de réaction. Une fois la vulnérabilité remédiée par 
> une rustine, le site web blacklisté par les fonctions du navigateur, et les 
> logiciels de sécurité mis à jour pour inclure le nouveau virus, le reste est 
> un combat d'arrière-garde et, AMHA, une perte de temps.
>
> La durée de vie utile d'un virus se mesure en heures ou en jours, pas en 
> semaines. Une fois le problème contenu, il vaut mieux dépenser son énergie à 
> reprendre de l'avance sur l'ennemi que d'éradiquer les dernières traces d'un 
> problème qui fait désormais parti du passé.
>
> Bon réveillon, bouffez bien, buvez bien, et ne conduisez pas si vous êtes 
> bourrés.
>
> Michel.
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Spoof UDP

2011-12-29 Thread RobOEM
Bonjour,
On re-parle de sécurité sur FRnOG... J'en profite donc pour
troller^H^H^H^H^H^H^H apporter ma brique de bois à la discussion.

> AMHA ce devrait être le genre de choses inscrites dans la loi, cette
> réactivité.

Ouais c'est cool, moi aussi j'aimerais ça. D'ailleurs ça m'aurait bien
simplifié la vie quand, au début de ma carrière, je bossais pour
$infogerance, que mon boulot c'était le monitoring de sécurité de
réseaux, et que j'envoyais à abuse@{$isp} des mails disant : "une IP
$IP à vous est en train de scanner|attaquer|[faire des trucs pas
jolis] à mon client dont l'IP est $IPclient, merci de bien vouloir me
contacter pour plus de ...".

A ces mails j'avais souvent comme réponse /null/ et un peu moins souvent :
>Bonjour, vous êtes qui?
Je suis un employé du SOC de la société $bla, je représente les
intérêts du client $blabla, et j'ai constaté qu'un de *vos* clients
[fait de la merde]...
>Ha bon, [qui me le prouve|c'est pas possible|j'ai regardé et je vois rien|mon 
>réseau est sécurisé]
[Rien si ce n'est les admin@$domainclient qui sont en cc|sisi c'est
possible|évidemment pauvre naze, tu me réponds deux jours après, y'a
plus rien|ah ouais, tu veux le dump réseau de mon côté?]

Tout ça pour souligner le problème que, si on veut inscrire dans la
loi ce genre de réactivité, il faudra à un moment (pour que ce soit
/timely/) lister des sources dignes de confiance pour envoyer ce genre
d'alertes, et que les agents possiblement capables de faire ça sont
nombreux et hétéroclites. Et que dans ces agents il y aura des CERTS
(privés, donc susceptibles d'avoir un agenda qu'on ne peut pas
vraiment contrôler) et l'ANSSI en france (publique, donc à agenda,
mais on pourra aller creuser) et d'autres acteurs tout à fait
légitimes qui n'auront pas pris la peine de devenir CERT (et les seuls
qui pourront leur reprocher ça c'est les boites qui ont pris la peine
d'être ISO27, imho)

En l'absence de cette liste de sources de confiance pour des reports à
abuse@ inscrits dans la loi, les reports seront pourris de faux
positifs malveillants (point négatif de la contre-mesure, les abus de
la contre-mesure, voir DMCA).

Et l'engagement en question supposera bien d'enquêter sur tous les
reports, déterminer lesquels sont de vrais positifs, ce qui suppose du
fric pour la sécurité (sur ma liste pour papa noel cette année, on
verra bien) et des gens compétents chez les FAI qui répondent à abuse
(j'ose même pas mettre ça sur ma liste). Que ce soit un accès à
internet livré à domicile ou hébergé dans un datacenter.

Et faute de ce truc centralisé, on verra chaque hébergeur dérouler sa
solution de blacklist plus ou moins aboutie, on reverra les problèmes
des premiers temps du SPAM, et surtout chacun pourra, au nom de la
sécurité, faire ce qu'il veut en étant moyennement responsable.

L'obligation que j'aimerais voir, c'est celle de "balayer devant sa
porte", comme dit plus haut, soit de scanner ses plages IP en
cherchant des Bad Things, et de fournir une information "adaptée" aux
clients. Éventuellement, prendre des mesures conservatives genre
bloquer le port 25 sortant pour tous les clients à moins que ceux-ci
en fassent la demande expresse, mesure justifiée par le fait qu'une
minorité de clients se sert du mail, au pire imposer un serveur mail
sortant avec un filtre anti spam (et s'amuser en passant que tout le
monde accepte l'anti spam sur les relays sans crier au DPI)

Le consensus ici semble être qu'il faut le faire, mais sans non plus
que ça soit imposé passque sinon on va devoir augmenter nos prix et
tous nos clients ils partiront à l'étranger (facilement délocalisable,
l'hébergement).

Le problème semble donc la marketabilité de la sécurité (qui serait
ici aussi plus de la qualité, en fait) vis à vis des clients. Comment
justifier d'un prix plus élevé pour un service incluant un
accompagnement sécurité? D'après ce que je vois du marché, ça se fera,
dans une dizaine d'années (le temps que les jeunes qui ont grandi avec
facebook aient envie de se faire un site web). Bref, comment en pas
être un hébergeur du dimanche, si je vous suis bien. D'ici là, ceux
qui auront pris la pointe auront la compétence et les outils pour
faire bien.


2011/12/28 Rémi Bouhl :
> Bonjour,
>
[snip]
>
>
> Il y a un autre paramètre qui est, à mes yeux, plus utiles que l'IP fixe:
> c'est la réactivité du FAI.
>
> Par rapport à ton suisse, il m'est arrivé d'envoyer à un hébergeur suisse
> une plainte sur son abuse: un de ses clients envoyait du spam. Pas du spam
> tout laid avec du v14gR4, mais du spam "pro", qui voulait me vendre je sais
> plus quelle fourniture de bureau, sur mon adresse @grunt.fdn.fr
> (certainement confondue avec une adresse pro).
>
> Hé bien, l'hébergeur suisse a pris mon mail au sérieux: il a répondu
> immédiatemment, a acquiescé du fait que ce n'était pas normal, a dit qu'il
> allait voir avec son client. Je n'ai plus reçu de spam venant de cette @IP.
>
> Quand je compare à des FAI comme Free ou Bouygues qui font totalement la

Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks

2012-03-20 Thread RobOEM
Merci pour le document et son analyse, qui a au moins le mérite de
poser des bases de travail. Remédier à l'infection des utilisateurs
par des maliciels devrait être, et je ne pense pas être le seul à le
penser, un des service fournis par les FAI. Effectivement, cette RFC
est (sans doutes pour des raisons politiques) succincte et n'aborde
peu le point de que faire, si ce n'est par les problèmes que cela peut
engendrer en termes de privacy. Cela dit, on se retrouve dans la même
problématique de nettoyer devant sa porte (quid ne l'action volontaire
d'un utilisateur spammeur, ou DoSeur, doit on chercher à le détecter
proactivement, réagir quand la cible se plaint, ne rien faire tant que
cela n'impacte pas les autres utilisateurs ou nous mêmes en tant que
FAI?).

Je mords néanmoins au troll

> À noter qu'une autre faiblesse de ce document est que, pour éviter de
> déchainer les avocats de Microsoft, le fait que la quasi-totalité des
> zombies soient aujourd'hui des machines Windows est tout simplement
> absent...

Peut être pour éviter de dire une évidence, qui est que la quasi
totalité des machines des end-users sont des machines windows. Je sais
que cet argument peut dans certains contextes ne pas être valide, mais
ici il l'est. Les bot herders cherchent la rentabilité, le plus grand
nombre de machines infectées par leur code, la majorité des postes
vulnérables à n'importe quoi (y compris l'utilisateur) sont sous
windows, ergo la majorité des zombies sont sous windows.

Posons nous la question de en quoi cela peut aider la remédiation. On
pourrait recommander à MS de pousser, via Windows Update, des
correctifs dédiés. Ne le font-ils pas? (<-- vraie question, leur
malware removal tool qu'ils poussent de temps en temps, je n'ai aucune
idée de ce qu'il fait). On pourrait aussi recommander à tous nos
utilisateurs de ne pas utiliser Windows, ce qui serait effectivement
très efficace comme déni de service local, ou comme permis d'utiliser
internet. J'aimerais bien savoir quelle intention non-trollesque était
derrière ce paragraphe.

Rob'


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks

2012-03-20 Thread RobOEM
Commentaires inline.

2012/3/20 Michel Py :
>>> RobOEM a écrit:
>>> Merci pour le document et son analyse, qui a au moins le mérite
>>> de poser des bases de travail. Remédier à l'infection des
>>> utilisateurs par des maliciels devrait être, et je ne pense pas
>>> être le seul à le penser, un des service fournis par les FAI.
>
>> Francois Petillon a écrit:
>> Pourquoi ? Si je veux bien croire que les FAIs soient bien placés
>> pour détecter/signaler un problème, la source de l'infection se
>> situe rarement sur son domaine de compétence.
>
> +1

La source de l'infection n'est pas de son domaine de compétence, mais
la détection l'est. Et si l'on se réfère à ce genre de posts
http://www.mail-archive.com/frnog@frnog.org/msg17023.html
http://www.mail-archive.com/frnog@frnog.org/msg17826.html c'est bien
au FAI d'intervenir, et d'aider le client à se sortir de la merde,
dans une certaine limite.

>
>> Stephane Borzmeyer a écrit:
>> Vous vous demandez peut-être quelle solution a finalement retenue
>> Comcast ? Décrite dans le RFC 6108, elle consiste à modifier le
>> contenu des pages Web vues par l'utilisateur pour y insérer une
>> fenêtre-polichinelle d'avertissement.
>
> C'est une bonne méthode, et pour des raisons que l'on ne soupçonnait pas: 
> récemment il y a eu une épidémie de faux logiciels de nettoyage (qui sont 
> eux-mêmes le problème) et les utilisateurs commencent à comprendre que les 
> fenêtres qui indiquent un problème, même si étant elles-mêmes la source du 
> problème, veulent dire qu'il faut faire quelque chose.
+1, sauf sur la partie de 'on ne soupçonnait pas'. Sisi, et on y
travaille. Etablir la légitimité de ce genre de message pour Mme Michu
est un gros boulot, qui est entrepris.
>
> Les utilisateurs recevant ce message vont donc croire qu'il contient un 
> virus, mais au bout du compte si le résultat est qu'ils nettoient leur PC, 
> l'objectif est atteint et ils pourront dire autour d'eux qu'ils ont nettoyé 
> le virus que Comcast leur avait envoyé sans comprendre que la raison pour 
> laquelle le message n'apparait plus est que Malwarebytes ou Kaspersky ont 
> enlevé le vrai ver, pas le "virus comcast".
>
>
>>> Stephane Borzmeyer a écrit:
>>> À noter qu'une autre faiblesse de ce document est que, pour éviter de
>>> déchainer les avocats de Microsoft, le fait que la quasi-totalité des
>>> zombies soient aujourd'hui des machines Windows est tout simplement
>>> absent...
>
>> RobOEM a écrit:
>> Peut être pour éviter de dire une évidence, qui est que la quasi
>> totalité des machines des end-users sont des machines windows. Je
>> sais que cet argument peut dans certains contextes ne pas être
>> valide, mais ici il l'est. Les bot herders cherchent la
>> rentabilité, le plus grand nombre de machines infectées par leur
>> code, la majorité des postes vulnérables à n'importe quoi (y
>> compris l'utilisateur) sont sous windows, ergo la majorité des
>> zombies sont sous windows.
>
> +1
>
>
>> On pourrait aussi recommander à tous nos utilisateurs de
>> ne pas utiliser Windows,
>
> 
> A tant que faire on pourrait aussi leur demander de ne pas être cons et de ne 
> pas aller à la pêche aux cracks de jeu et autre activités à haut risque de se 
> retrouver contaminé.
> 

Ah ouais, passque le drive-by download ça existe pas?

> Plus sérieusement, je pense que les fabricants d'antivirus vont trop loin 
> avec les cracks de jeux et les keygens: ils ne testent pas si le crack 
> contient un virus ou pas et marquent systématiquement le fichier comme virus. 
> C'est contre-productif, car ça pousse les utilisateurs à désactiver 
> l'antivirus quand ils sont convaincus que le crack ne présente pas de danger, 
> ce qui est parfois le cas.

Totalement +1. Et même, cela permet à des gens pas bien intentionnés
de dire "ton AV va détecter ça comme un virus mais c'est normal,
regarde comment ils détectent tel crack, ou pwdump. Ignore donc cet
avertissement et continue avec l'install.
http://pcdn.500px.net/3173305/d926d906d6d120f568898db309303947d12d9ec5/4.jpg
Après, où tirer la limite? Surement pas au cracks, mais j'aimerais
bien être prévenu (et simplement prévenu) que nmap, tcpdump, ou pwdump
ou psexec sont présents sur ma machine. Juste pour savoir s'ils ont
une bonne raison d'être là.

>
> Quand on regarde les commentaires d'un torrent sur TPB, on voit souvent 
> "attention, contient virus ne téléchargez pas" et on commence aussi à voir 
> "mais non c'est pas un virus vous pouvez prendre sans crainte".
>
> Michel.
>


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks

2012-03-22 Thread RobOEM
2012/3/21 Michel Py :
>> RobOEM a écrit:
>> La source de l'infection n'est pas de son domaine de compétence,
>> mais la détection l'est. Et si l'on se réfère à ce genre de posts
>> http://www.mail-archive.com/frnog@frnog.org/msg17023.html
>> http://www.mail-archive.com/frnog@frnog.org/msg17826.html
>> c'est bien au FAI d'intervenir, et d'aider le client à se sortir
>> de la merde, dans une certaine limite.
>
> Attention au contexte: ces billets étaient dans le domaine de l'hébergement, 
> pas de l'accès grand public, deux choses totalement différentes. Aussi, ne 
> pas confondre détection et remédiation.
>
Totalement différentes? Dans les termes de service actuels, oui, nous
sommes tout à fait d'accords. Cependant en pratique, sachant que d'une
part une minorité vocale tient à pouvoir héberger des services @home,
sur un accès 'grand public', et que d'autre part certains font
héberger des applications pas tellement mieux sécurisées que
l'ensemble windows+applications+utilisateur grand public, la seule
différence que je pourrais voir c'est qu'a priori, il n'y a pas
d'utilisateur en permanence actif sur un serveur hébergé, et qu'il n'y
a pas toujours de poste actif derrière un accès au net grand public (à
part les box, mais bon, autre débat).

Dans les deux cas, l'hébergeur ou l'ISP fournit un accès à internet à
des utilisateurs éventuellement malveillants ou incompétents (la
frontière entre les deux pouvant être infime), et si tu considères
qu'un hebergeur doit apporter du conseil à la remédiation, avoir des
capacités de détection tournées vers l'interne, et éventuellement
bloquer un de ses utilisateurs qui spamme/DoS avant de l'aider à
nettoyer ou de le sommer de nettoyer avant de se faire virer, je ne
vois pas vraiment quelle différence il y a avec un FAI et le public.
C'était justement le débat que j'essayais de lancer, mais à ce train
là il va devoir attendre vendredi.

Rob'


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Site Checkpoint.com

2012-04-03 Thread RobOEM
Bonjour,

Checkpoint a raté le renouvellement de son domaine hier, lequel a été
brièvement parqué avant de revenir à son propriétaire légitime. (voir
http://www.theregister.co.uk/2012/04/03/check_point_domain_renewal_snafu
)
Il y a surement un lien.

Rob'

2012/4/3 Martin Pernollet :
> Bonjour,
> Je n'ai pas ce problème. www.checkpoint.com dirige vers checkpoint, et
> www.networksolutions.com dirige vers network solutions.
> @+
> Martin
>
> Le 3 avril 2012 11:13, Cedric Polomack  a écrit :
>
>> Bonjour,
>> J'en appel a la liste pour savoir si quelqu'un a le même phénomène que
>> moi. En tentant de joindre le site de checkpoint je tombe sur le site de
>> network solution. En testant via un site spécialisé il semble y avoir des
>> réponses différente pointant plus ou moins également vers ce même site:
>>
>> http://www.whatsmydns.net/#A/**www.checkpoint.com
>>
>> Quelqu'un peut il me confirmer ou pas s'il à le même résultat.
>> Cédric
>>
>> --
>> ---
>> Polomack Cédric
>> http://www.secresys.fr
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>
>
> --
> Martin Pernollet
> Fondateur - Calliandra Networks
> www.calliandra-networks.com
> 06 98 23 03 60
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Re: Diffusion du virus "gendarmerie" par javascripts modifiés

2011-12-25 Thread RobOEM
Bon, OK, on ne navigue pas dans les mêmes sphères, mais:
1) concernant la légalité de faire un grep sur les sites que vous
hébergez : personne ne parle de le faire sur tous les fichiers
présents dans l'espace de stockage que vous louez. Vous pouvez le
faire sur tout ce que vos clients exposent aux Internets (plus
difficile, mais bon), les prévenir le cas échéant qu'ils servent un
contenu malicieux, expliquer comment l'enlever, bref, ajouter un bout
de valeur au service que vous vendez.
2) concernant votre légitimité à faire ça : vous n'en avez aucune si
vous pensez que c'est le cas. En tant qu'utilisateur cependant, je
serais bien content qu'un mec sachant me prévienne d'une brèche sur
mon CMS, même si la solution c'est d'appliquer les patches que je n'ai
pas appliqué depuis 2003. Après, si je veux servir du contenu
malveillant, j'ignorerai le mail, et au pire si on vit dans un état
policier, je bougerai mon hébergement en ukraine ou en israel.
3) ok, les flics sont tous des imbéciles. Mais je vous laisse tous
réfléchir là dessus : http://news.abidjan.net/h/420775.html quand on
laisse le 'net devenir une zone de non-droit, à un moment les
législateurs réagissent et ça n'est pas forcément en faveur de ce que
nous défendons.

C'est pas non plus la mort de prévenir nos clients qu'il hébergent un
contenu malveillant. Ils ont la liberté d'ignorer notre avertissement,
en tous cas pour l'instant.

Mes deux centimes,
--rde

2011/12/25 Michel Py :
>> Thomas Samson a écrit:
>> On pourrait imaginer diffuser aux gens (à ses
>> clients par exemple)  ce genre de quizz :
>> http://www.opendns.com/phishing-quiz/
>> http://www.sonicwall.com/furl/phishing/
>> (et refuser l'accès aux services complets s'ils
>> échouent... on est vendredi, après tout  :) )
>
> Ah, le fameux permis d'utiliser un ordinateur ou de se connecter à l'Internet 
> :-D Un grand classique.
>
> Ce sont des bon liens, et-ce qu'il y a un équivalent en Français?
>
>
>> Morgan Hamart a écrit:
>> j'ai moi même appelé le service de gendarmerie il y a
>> quelques temps pour signaler un gros problème sur le
>> site internet d'une banque...l'accueil n'était pas ce
>> qui se fait de plus chaleureux, et on m'a finalement
>> répondu que j'avais qu'a informer mon conseiller
>> clientèle...
>
> Tu as perdu ton temps, et tu l'as probablement perdu aussi si tu as appelé la 
> banque.
>
> Ce que je fais en tant qu'utilisateur (chacun adapte à son navigateur et 
> langage) c'est Safety -> SmartScreen Filter -> Report Unsafe Website (IE8, 
> EN-US). Ca pointe vers:
> https://feedback.smartscreen.microsoft.com/feedback.aspx
>
> Ca n'enlève pas le virus, mais ça limite la casse. Le temps de réaction est 
> critique, et AMHA c'est aujourd'hui le mécanisme le plus rapide entre la 
> diffusion et le blocage.
>
> Il y a des seuils à franchir, ceci dit, que ce soit pour qu'un humain regarde 
> la page en question ou pour qu'elle soit bloquée automatiquement, donc il est 
> important que tout le monde le fasse.
>
>
>> Pierre Chapuis a écrit:
>> Peut-être plus pour FrSAG que FrNOG ?
>
> Pour la partie vulnérabilité, certainement. Quoi que je me demande si les 
> gens qui n'on pas encore mit les rustines sur les vulnérabilités connues 
> depuis des années la lisent, mais ne décourageons pas les mauvaises volontés. 
> FrSAG me semble nettement mieux ciblé que frnog-alert.
>
> Pour la partie virus, pourquoi ne pas aller directement discuter avec 
> Symantec, Kaspersky, McAffee, Spybot, MalwareBytes et consorts?
>
>
> Tout est dans le temps de réaction. Une fois la vulnérabilité remédiée par 
> une rustine, le site web blacklisté par les fonctions du navigateur, et les 
> logiciels de sécurité mis à jour pour inclure le nouveau virus, le reste est 
> un combat d'arrière-garde et, AMHA, une perte de temps.
>
> La durée de vie utile d'un virus se mesure en heures ou en jours, pas en 
> semaines. Une fois le problème contenu, il vaut mieux dépenser son énergie à 
> reprendre de l'avance sur l'ennemi que d'éradiquer les dernières traces d'un 
> problème qui fait désormais parti du passé.
>
> Bon réveillon, bouffez bien, buvez bien, et ne conduisez pas si vous êtes 
> bourrés.
>
> Michel.
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Spoof UDP

2011-12-29 Thread RobOEM
Bonjour,
On re-parle de sécurité sur FRnOG... J'en profite donc pour
troller^H^H^H^H^H^H^H apporter ma brique de bois à la discussion.

> AMHA ce devrait être le genre de choses inscrites dans la loi, cette
> réactivité.

Ouais c'est cool, moi aussi j'aimerais ça. D'ailleurs ça m'aurait bien
simplifié la vie quand, au début de ma carrière, je bossais pour
$infogerance, que mon boulot c'était le monitoring de sécurité de
réseaux, et que j'envoyais à abuse@{$isp} des mails disant : "une IP
$IP à vous est en train de scanner|attaquer|[faire des trucs pas
jolis] à mon client dont l'IP est $IPclient, merci de bien vouloir me
contacter pour plus de ...".

A ces mails j'avais souvent comme réponse /null/ et un peu moins souvent :
>Bonjour, vous êtes qui?
Je suis un employé du SOC de la société $bla, je représente les
intérêts du client $blabla, et j'ai constaté qu'un de *vos* clients
[fait de la merde]...
>Ha bon, [qui me le prouve|c'est pas possible|j'ai regardé et je vois rien|mon 
>réseau est sécurisé]
[Rien si ce n'est les admin@$domainclient qui sont en cc|sisi c'est
possible|évidemment pauvre naze, tu me réponds deux jours après, y'a
plus rien|ah ouais, tu veux le dump réseau de mon côté?]

Tout ça pour souligner le problème que, si on veut inscrire dans la
loi ce genre de réactivité, il faudra à un moment (pour que ce soit
/timely/) lister des sources dignes de confiance pour envoyer ce genre
d'alertes, et que les agents possiblement capables de faire ça sont
nombreux et hétéroclites. Et que dans ces agents il y aura des CERTS
(privés, donc susceptibles d'avoir un agenda qu'on ne peut pas
vraiment contrôler) et l'ANSSI en france (publique, donc à agenda,
mais on pourra aller creuser) et d'autres acteurs tout à fait
légitimes qui n'auront pas pris la peine de devenir CERT (et les seuls
qui pourront leur reprocher ça c'est les boites qui ont pris la peine
d'être ISO27, imho)

En l'absence de cette liste de sources de confiance pour des reports à
abuse@ inscrits dans la loi, les reports seront pourris de faux
positifs malveillants (point négatif de la contre-mesure, les abus de
la contre-mesure, voir DMCA).

Et l'engagement en question supposera bien d'enquêter sur tous les
reports, déterminer lesquels sont de vrais positifs, ce qui suppose du
fric pour la sécurité (sur ma liste pour papa noel cette année, on
verra bien) et des gens compétents chez les FAI qui répondent à abuse
(j'ose même pas mettre ça sur ma liste). Que ce soit un accès à
internet livré à domicile ou hébergé dans un datacenter.

Et faute de ce truc centralisé, on verra chaque hébergeur dérouler sa
solution de blacklist plus ou moins aboutie, on reverra les problèmes
des premiers temps du SPAM, et surtout chacun pourra, au nom de la
sécurité, faire ce qu'il veut en étant moyennement responsable.

L'obligation que j'aimerais voir, c'est celle de "balayer devant sa
porte", comme dit plus haut, soit de scanner ses plages IP en
cherchant des Bad Things, et de fournir une information "adaptée" aux
clients. Éventuellement, prendre des mesures conservatives genre
bloquer le port 25 sortant pour tous les clients à moins que ceux-ci
en fassent la demande expresse, mesure justifiée par le fait qu'une
minorité de clients se sert du mail, au pire imposer un serveur mail
sortant avec un filtre anti spam (et s'amuser en passant que tout le
monde accepte l'anti spam sur les relays sans crier au DPI)

Le consensus ici semble être qu'il faut le faire, mais sans non plus
que ça soit imposé passque sinon on va devoir augmenter nos prix et
tous nos clients ils partiront à l'étranger (facilement délocalisable,
l'hébergement).

Le problème semble donc la marketabilité de la sécurité (qui serait
ici aussi plus de la qualité, en fait) vis à vis des clients. Comment
justifier d'un prix plus élevé pour un service incluant un
accompagnement sécurité? D'après ce que je vois du marché, ça se fera,
dans une dizaine d'années (le temps que les jeunes qui ont grandi avec
facebook aient envie de se faire un site web). Bref, comment en pas
être un hébergeur du dimanche, si je vous suis bien. D'ici là, ceux
qui auront pris la pointe auront la compétence et les outils pour
faire bien.


2011/12/28 Rémi Bouhl :
> Bonjour,
>
[snip]
>
>
> Il y a un autre paramètre qui est, à mes yeux, plus utiles que l'IP fixe:
> c'est la réactivité du FAI.
>
> Par rapport à ton suisse, il m'est arrivé d'envoyer à un hébergeur suisse
> une plainte sur son abuse: un de ses clients envoyait du spam. Pas du spam
> tout laid avec du v14gR4, mais du spam "pro", qui voulait me vendre je sais
> plus quelle fourniture de bureau, sur mon adresse @grunt.fdn.fr
> (certainement confondue avec une adresse pro).
>
> Hé bien, l'hébergeur suisse a pris mon mail au sérieux: il a répondu
> immédiatemment, a acquiescé du fait que ce n'était pas normal, a dit qu'il
> allait voir avec son client. Je n'ai plus reçu de spam venant de cette @IP.
>
> Quand je compare à des FAI comme Free ou Bouygues qui font totalement la

Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks

2012-03-20 Thread RobOEM
Merci pour le document et son analyse, qui a au moins le mérite de
poser des bases de travail. Remédier à l'infection des utilisateurs
par des maliciels devrait être, et je ne pense pas être le seul à le
penser, un des service fournis par les FAI. Effectivement, cette RFC
est (sans doutes pour des raisons politiques) succincte et n'aborde
peu le point de que faire, si ce n'est par les problèmes que cela peut
engendrer en termes de privacy. Cela dit, on se retrouve dans la même
problématique de nettoyer devant sa porte (quid ne l'action volontaire
d'un utilisateur spammeur, ou DoSeur, doit on chercher à le détecter
proactivement, réagir quand la cible se plaint, ne rien faire tant que
cela n'impacte pas les autres utilisateurs ou nous mêmes en tant que
FAI?).

Je mords néanmoins au troll

> À noter qu'une autre faiblesse de ce document est que, pour éviter de
> déchainer les avocats de Microsoft, le fait que la quasi-totalité des
> zombies soient aujourd'hui des machines Windows est tout simplement
> absent...

Peut être pour éviter de dire une évidence, qui est que la quasi
totalité des machines des end-users sont des machines windows. Je sais
que cet argument peut dans certains contextes ne pas être valide, mais
ici il l'est. Les bot herders cherchent la rentabilité, le plus grand
nombre de machines infectées par leur code, la majorité des postes
vulnérables à n'importe quoi (y compris l'utilisateur) sont sous
windows, ergo la majorité des zombies sont sous windows.

Posons nous la question de en quoi cela peut aider la remédiation. On
pourrait recommander à MS de pousser, via Windows Update, des
correctifs dédiés. Ne le font-ils pas? (<-- vraie question, leur
malware removal tool qu'ils poussent de temps en temps, je n'ai aucune
idée de ce qu'il fait). On pourrait aussi recommander à tous nos
utilisateurs de ne pas utiliser Windows, ce qui serait effectivement
très efficace comme déni de service local, ou comme permis d'utiliser
internet. J'aimerais bien savoir quelle intention non-trollesque était
derrière ce paragraphe.

Rob'


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks

2012-03-20 Thread RobOEM
Commentaires inline.

2012/3/20 Michel Py :
>>> RobOEM a écrit:
>>> Merci pour le document et son analyse, qui a au moins le mérite
>>> de poser des bases de travail. Remédier à l'infection des
>>> utilisateurs par des maliciels devrait être, et je ne pense pas
>>> être le seul à le penser, un des service fournis par les FAI.
>
>> Francois Petillon a écrit:
>> Pourquoi ? Si je veux bien croire que les FAIs soient bien placés
>> pour détecter/signaler un problème, la source de l'infection se
>> situe rarement sur son domaine de compétence.
>
> +1

La source de l'infection n'est pas de son domaine de compétence, mais
la détection l'est. Et si l'on se réfère à ce genre de posts
http://www.mail-archive.com/frnog@frnog.org/msg17023.html
http://www.mail-archive.com/frnog@frnog.org/msg17826.html c'est bien
au FAI d'intervenir, et d'aider le client à se sortir de la merde,
dans une certaine limite.

>
>> Stephane Borzmeyer a écrit:
>> Vous vous demandez peut-être quelle solution a finalement retenue
>> Comcast ? Décrite dans le RFC 6108, elle consiste à modifier le
>> contenu des pages Web vues par l'utilisateur pour y insérer une
>> fenêtre-polichinelle d'avertissement.
>
> C'est une bonne méthode, et pour des raisons que l'on ne soupçonnait pas: 
> récemment il y a eu une épidémie de faux logiciels de nettoyage (qui sont 
> eux-mêmes le problème) et les utilisateurs commencent à comprendre que les 
> fenêtres qui indiquent un problème, même si étant elles-mêmes la source du 
> problème, veulent dire qu'il faut faire quelque chose.
+1, sauf sur la partie de 'on ne soupçonnait pas'. Sisi, et on y
travaille. Etablir la légitimité de ce genre de message pour Mme Michu
est un gros boulot, qui est entrepris.
>
> Les utilisateurs recevant ce message vont donc croire qu'il contient un 
> virus, mais au bout du compte si le résultat est qu'ils nettoient leur PC, 
> l'objectif est atteint et ils pourront dire autour d'eux qu'ils ont nettoyé 
> le virus que Comcast leur avait envoyé sans comprendre que la raison pour 
> laquelle le message n'apparait plus est que Malwarebytes ou Kaspersky ont 
> enlevé le vrai ver, pas le "virus comcast".
>
>
>>> Stephane Borzmeyer a écrit:
>>> À noter qu'une autre faiblesse de ce document est que, pour éviter de
>>> déchainer les avocats de Microsoft, le fait que la quasi-totalité des
>>> zombies soient aujourd'hui des machines Windows est tout simplement
>>> absent...
>
>> RobOEM a écrit:
>> Peut être pour éviter de dire une évidence, qui est que la quasi
>> totalité des machines des end-users sont des machines windows. Je
>> sais que cet argument peut dans certains contextes ne pas être
>> valide, mais ici il l'est. Les bot herders cherchent la
>> rentabilité, le plus grand nombre de machines infectées par leur
>> code, la majorité des postes vulnérables à n'importe quoi (y
>> compris l'utilisateur) sont sous windows, ergo la majorité des
>> zombies sont sous windows.
>
> +1
>
>
>> On pourrait aussi recommander à tous nos utilisateurs de
>> ne pas utiliser Windows,
>
> 
> A tant que faire on pourrait aussi leur demander de ne pas être cons et de ne 
> pas aller à la pêche aux cracks de jeu et autre activités à haut risque de se 
> retrouver contaminé.
> 

Ah ouais, passque le drive-by download ça existe pas?

> Plus sérieusement, je pense que les fabricants d'antivirus vont trop loin 
> avec les cracks de jeux et les keygens: ils ne testent pas si le crack 
> contient un virus ou pas et marquent systématiquement le fichier comme virus. 
> C'est contre-productif, car ça pousse les utilisateurs à désactiver 
> l'antivirus quand ils sont convaincus que le crack ne présente pas de danger, 
> ce qui est parfois le cas.

Totalement +1. Et même, cela permet à des gens pas bien intentionnés
de dire "ton AV va détecter ça comme un virus mais c'est normal,
regarde comment ils détectent tel crack, ou pwdump. Ignore donc cet
avertissement et continue avec l'install.
http://pcdn.500px.net/3173305/d926d906d6d120f568898db309303947d12d9ec5/4.jpg
Après, où tirer la limite? Surement pas au cracks, mais j'aimerais
bien être prévenu (et simplement prévenu) que nmap, tcpdump, ou pwdump
ou psexec sont présents sur ma machine. Juste pour savoir s'ils ont
une bonne raison d'être là.

>
> Quand on regarde les commentaires d'un torrent sur TPB, on voit souvent 
> "attention, contient virus ne téléchargez pas" et on commence aussi à voir 
> "mais non c'est pas un virus vous pouvez prendre sans crainte".
>
> Michel.
>


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks

2012-03-22 Thread RobOEM
2012/3/21 Michel Py :
>> RobOEM a écrit:
>> La source de l'infection n'est pas de son domaine de compétence,
>> mais la détection l'est. Et si l'on se réfère à ce genre de posts
>> http://www.mail-archive.com/frnog@frnog.org/msg17023.html
>> http://www.mail-archive.com/frnog@frnog.org/msg17826.html
>> c'est bien au FAI d'intervenir, et d'aider le client à se sortir
>> de la merde, dans une certaine limite.
>
> Attention au contexte: ces billets étaient dans le domaine de l'hébergement, 
> pas de l'accès grand public, deux choses totalement différentes. Aussi, ne 
> pas confondre détection et remédiation.
>
Totalement différentes? Dans les termes de service actuels, oui, nous
sommes tout à fait d'accords. Cependant en pratique, sachant que d'une
part une minorité vocale tient à pouvoir héberger des services @home,
sur un accès 'grand public', et que d'autre part certains font
héberger des applications pas tellement mieux sécurisées que
l'ensemble windows+applications+utilisateur grand public, la seule
différence que je pourrais voir c'est qu'a priori, il n'y a pas
d'utilisateur en permanence actif sur un serveur hébergé, et qu'il n'y
a pas toujours de poste actif derrière un accès au net grand public (à
part les box, mais bon, autre débat).

Dans les deux cas, l'hébergeur ou l'ISP fournit un accès à internet à
des utilisateurs éventuellement malveillants ou incompétents (la
frontière entre les deux pouvant être infime), et si tu considères
qu'un hebergeur doit apporter du conseil à la remédiation, avoir des
capacités de détection tournées vers l'interne, et éventuellement
bloquer un de ses utilisateurs qui spamme/DoS avant de l'aider à
nettoyer ou de le sommer de nettoyer avant de se faire virer, je ne
vois pas vraiment quelle différence il y a avec un FAI et le public.
C'était justement le débat que j'essayais de lancer, mais à ce train
là il va devoir attendre vendredi.

Rob'


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Site Checkpoint.com

2012-04-03 Thread RobOEM
Bonjour,

Checkpoint a raté le renouvellement de son domaine hier, lequel a été
brièvement parqué avant de revenir à son propriétaire légitime. (voir
http://www.theregister.co.uk/2012/04/03/check_point_domain_renewal_snafu
)
Il y a surement un lien.

Rob'

2012/4/3 Martin Pernollet :
> Bonjour,
> Je n'ai pas ce problème. www.checkpoint.com dirige vers checkpoint, et
> www.networksolutions.com dirige vers network solutions.
> @+
> Martin
>
> Le 3 avril 2012 11:13, Cedric Polomack  a écrit :
>
>> Bonjour,
>> J'en appel a la liste pour savoir si quelqu'un a le même phénomène que
>> moi. En tentant de joindre le site de checkpoint je tombe sur le site de
>> network solution. En testant via un site spécialisé il semble y avoir des
>> réponses différente pointant plus ou moins également vers ce même site:
>>
>> http://www.whatsmydns.net/#A/**www.checkpoint.com
>>
>> Quelqu'un peut il me confirmer ou pas s'il à le même résultat.
>> Cédric
>>
>> --
>> ---
>> Polomack Cédric
>> http://www.secresys.fr
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>
>
> --
> Martin Pernollet
> Fondateur - Calliandra Networks
> www.calliandra-networks.com
> 06 98 23 03 60
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/