Re: [FRnOG] [TECH] detection VPN SSL

[Pierre Colombier]

Je suis d'accord avec ça.

J'ajouterai que les methodes de contournement sont potentiellement des 
nuisances bien pires que celles que l'on essaie de bloquer.
Il existe des methodes de tunelling sur DNS qui explosent 
inmanquablement le cache du resolveur local.
Et là, à part des quotas, je n'ai pas franchement trouvé de solution 
technique.


Mon expérience en la matière c'est que le mieux est d'aller voir le gars 
qui abuse pour une petite explication du genre


"écoute, c'est dans l'intéret de tout le monde que les règles de 
filtrage restent relativement simples et je n'ai pas envie de passer du 
temps à bloquer tes tentatives de contournement de la sécurité. Par 
contre, il faudrait quand voir à ne pas trop me prendre pour un con. Là, 
je passe l'éponge, mais si tu n'arretes pas ça tout de suite, je vais 
être obligé de faire un rapport à la direction."


En l'occurence, je ne m'étais pas déplacé, et je n'ai même pas identifié 
le bonhomme.

J'ai juste réduit son traffic internet à 1kbps.
Il n'a pas fallu 5 minutes pour qu'il vienne râler ;)



On 09/03/2016 07:19, Michel Py wrote:

David Ponzone a écrit :
Le plus simple c’est d’ajouter dans le règlement intérieur de la société que les
connexions VPN sortantes personnelles sont interdites sous peine de sanction 
grave.

Rapport efficacité / prix imbattable, en effet. Ca va pas tout empêcher, mais 
c'est la première chose à faire. Parce que filtrer les geeks barbus de la liste 
du FRnOG qui contournent les filtrages de la boite sans aucun besoin, juste 
pour la difficulté, ç'est du travail.

Michel.

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



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

RE: [FRnOG] [TECH] detection VPN SSL

[Michel Py]

> David Ponzone a écrit :
> Le plus simple c’est d’ajouter dans le règlement intérieur de la société que 
> les
> connexions VPN sortantes personnelles sont interdites sous peine de sanction 
> grave.

Rapport efficacité / prix imbattable, en effet. Ca va pas tout empêcher, mais 
c'est la première chose à faire. Parce que filtrer les geeks barbus de la liste 
du FRnOG qui contournent les filtrages de la boite sans aucun besoin, juste 
pour la difficulté, ç'est du travail.

Michel.

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

Re: [FRnOG] [ALERT] Cryptolock

[David Ponzone]

> Le 9 mars 2016 à 06:18, Michel Py  a 
> écrit :
> 
>> David Ponzone a écrit :
>> Puisqu’on parle de solutions, est-ce qu’il existe des filesystem réseau qui 
>> force le client à entrer un mot de
>> passe quand il veut accéder en écriture à un fichier sur un partage, et qui 
>> n’est valable que pour X minutes ?
> 
> Multics ?

Trop dinosaure pour moi :)

>> Dans le monde réel, l’employé de base (au niveau IT) ne devrait JAMAIS
>> télécharger un exe ou un msi sur son PC pour l’installer lui-même.
> 
> Je suis à peu près d'accord sur cette partie, sauf que j'ai déjà une 
> exception : mon masque de clavier QWERTY avec les accents, c'est un .exe. 
> Pourquoi ? parce que j'avais pas envie de ré-inventer la roue et que le 
> générateur produit un .exe. C'est facile à dire, pas forcément à faire.
> 

C’est quand même marginal comme cas non ?
Si tu avais ce besoin justifié dans une boite et que tu étais un employé 
lambda, tu pourrais attendre 1 ou 2 semaines que l’IT s’en occupe.

> 
>> De même, l’employé de base ne devrait jamais utiliser le mail pour échanger 
>> des zip, ou autre.
> 
> Ca dans mon monde c'est carrément impossible, les utilisateurs faisant çà 
> toute la journée. Dans une banque ou un hopital quand la majorité de tes 
> employés sont des droides (pour ce qui est d'utiliser l'informatique) c'est 
> possible (d'ailleurs ils n'ont probablement pas de client mail) mais dès que 
> tu commence à avoir des utilisateurs un peu au dessus du niveau "script 
> monkey", c'est pas possible de bloquer zip.

Attention, j’ai dit « par mail » .
Ils peuvent toujours utiliser un système de partage de fichiers type Dropbox, 
Google Drive, ou Nomadesk.

> C'est malheureusement vrai. Ceci étant dit, le dirigeant qui est assez con 
> pour payer alors qu'il a une sauvegarde pour se retrouver dans la même 
> situation un peu plus tard mérite de se faire virer. Payer la rançon quand on 
> n'a pas de sauvegarde viable, c'est comme "l'apprentissage par le 
> kilométrage" : en général une fois suffit pour comprendre. Payer la rançon 
> pour faire des économies, c'est impardonnable. La perte de productivité elle 
> va devenir pire si on n'éradique pas le problème. Vous avez 3 heures, rangez 
> votre bureau.

Tiens au fait, ils fournissent une facture les escrocs ? Et ça va où dans la 
compta ? :)


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

Re: [FRnOG] [TECH] detection VPN SSL

[David Ponzone]

Le plus simple c’est d’ajouter dans le règlement intérieur de la société que 
les connexions VPN sortantes personnelles sont interdites sous peine de 
sanction grave.


> Le 9 mars 2016 à 06:42, Michel Py  a 
> écrit :
> 
>> Jocelyn Lagarenne a écrit :
>> particulierement ce genre de VPN SSL, les autres sont simple à filtrer).
> 
> Les autres ne sont pas simples à filtrer. Bon PPTP c'est facile à filtrer, 
> mais voir plus bas :
> 
>> Tristan Mahé a écrit :
>> ça m'étonne que personne n'ai mentionné les iodines ( 
>> http://code.kryo.se/iodine/README.html ) et autres vpn-ws
> 
> Par exemple. J'ai essayé récemment, sur un réseau "complètement sécurisé", çà 
> a marché !
> 
> Jocelyn, filtrer les VPNs c'est une guerre dont on ne voit pas la fin, tout 
> comme le glaive contre le bouclier. Principe de l'action et de la réaction : 
> chaque fois que tu filtres quelque chose, le résultat est que quelqu'un va 
> trouver un mécanisme pour le contourner.
> 
> Un VPN, c'est encapsuler les données à l'intérieur de quelque chose d'autre. 
> On peut plus faire de VPN transporté sur PPTP ? on fait du VPN transporté sur 
> SSL. On peut plus faire de VPN transporté sur SSL ? on fait du VPN transporté 
> sur DNS. Le monde ne s'arrête pas de tourner à chaque fois qu'une solution de 
> contournement est trouvée, la solution de remplacement est déjà en cours. 
> 
> RFC 1149 pour les VPN !
> 
>> Tout ça pour dire que le plus simple est peut-être le contrôle du parc
> 
> Ce n'est pas plus simple. Nice try, no cigar.
> 
> Michel.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

RE: [FRnOG] [TECH] detection VPN SSL

[Michel Py]

> Jocelyn Lagarenne a écrit :
> particulierement ce genre de VPN SSL, les autres sont simple à filtrer).

Les autres ne sont pas simples à filtrer. Bon PPTP c'est facile à filtrer, mais 
voir plus bas :

> Tristan Mahé a écrit :
> ça m'étonne que personne n'ai mentionné les iodines ( 
> http://code.kryo.se/iodine/README.html ) et autres vpn-ws

Par exemple. J'ai essayé récemment, sur un réseau "complètement sécurisé", çà a 
marché !

Jocelyn, filtrer les VPNs c'est une guerre dont on ne voit pas la fin, tout 
comme le glaive contre le bouclier. Principe de l'action et de la réaction : 
chaque fois que tu filtres quelque chose, le résultat est que quelqu'un va 
trouver un mécanisme pour le contourner.

Un VPN, c'est encapsuler les données à l'intérieur de quelque chose d'autre. On 
peut plus faire de VPN transporté sur PPTP ? on fait du VPN transporté sur SSL. 
On peut plus faire de VPN transporté sur SSL ? on fait du VPN transporté sur 
DNS. Le monde ne s'arrête pas de tourner à chaque fois qu'une solution de 
contournement est trouvée, la solution de remplacement est déjà en cours. 

RFC 1149 pour les VPN !

> Tout ça pour dire que le plus simple est peut-être le contrôle du parc

Ce n'est pas plus simple. Nice try, no cigar.

Michel.


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

RE: [FRnOG] Re: [ALERT] Cryptolock

[Michel Py]

> David Ponzone a écrit :
> Puisqu’on parle de solutions, est-ce qu’il existe des filesystem réseau qui 
> force le client à entrer un mot de
> passe quand il veut accéder en écriture à un fichier sur un partage, et qui 
> n’est valable que pour X minutes ?

Multics ?

> Dans le monde réel, l’employé de base (au niveau IT) ne devrait JAMAIS
> télécharger un exe ou un msi sur son PC pour l’installer lui-même.

Je suis à peu près d'accord sur cette partie, sauf que j'ai déjà une exception 
: mon masque de clavier QWERTY avec les accents, c'est un .exe. Pourquoi ? 
parce que j'avais pas envie de ré-inventer la roue et que le générateur produit 
un .exe. C'est facile à dire, pas forcément à faire.


> De même, l’employé de base ne devrait jamais utiliser le mail pour échanger 
> des zip, ou autre.

Ca dans mon monde c'est carrément impossible, les utilisateurs faisant çà toute 
la journée. Dans une banque ou un hopital quand la majorité de tes employés 
sont des droides (pour ce qui est d'utiliser l'informatique) c'est possible 
(d'ailleurs ils n'ont probablement pas de client mail) mais dès que tu commence 
à avoir des utilisateurs un peu au dessus du niveau "script monkey", c'est pas 
possible de bloquer zip.


> Clement Cavadore a écrit :
> On ne limite pas l'accès au net à un réseauteux ! 
> Il est forcément plus con(pétant) que le responsable bureautique :-))

Je vote pour Clement :-)


> Sylvain Vallerot a écrit :
> Il a par contre intérêt à se faire respecter : la boite qui contre l'attaque 
> en restaurant ses backups c'est pas bon pour lui.
> C'est pourquoi une évolution logique de ces rançongiciels serait que le 
> sinistre soit réitéré jusqu'au paiement effectif.
> C'est aussi le mécanisme qui fait que le dirigeant va être motivé à payer la 
> rançon, il n'y a pas que la perte de certaines
> données, il y a aussi la perte de productivité Quand une boite passe une 
> journée à restaurer ses backups le temps perdu a un
> coût qui peut être très important. Sans compter la nécessité de nettoyer les 
> postes infectés qui peut nécessiter un travail
> voire une expertise, coûteux eux aussi.

C'est malheureusement vrai. Ceci étant dit, le dirigeant qui est assez con pour 
payer alors qu'il a une sauvegarde pour se retrouver dans la même situation un 
peu plus tard mérite de se faire virer. Payer la rançon quand on n'a pas de 
sauvegarde viable, c'est comme "l'apprentissage par le kilométrage" : en 
général une fois suffit pour comprendre. Payer la rançon pour faire des 
économies, c'est impardonnable. La perte de productivité elle va devenir pire 
si on n'éradique pas le problème. Vous avez 3 heures, rangez votre bureau.

Michel.


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

Re: [FRnOG] [ALERT] Cryptolock

[lilian coupat]

> Le 8 mars 2016 à 15:59, Barthélémy DELUY  a écrit :
> 
> Je penche plutôt pour l'autre option .
> 
> Un hacker n'a RIEN à gagner à faire grimper les enchères une fois que le
> système est infecté. S'il fait ça, il perd en crédibilité, donc plus aucun
> client ne paiera. Ils ont au contraire tout à gagner à livre la clé de
> déchiffrement le plus rapidement possible, pour gagner la "confiance" d'un
> maximum de victimes potentielles. Il vaut mieux tirer cent fois 1000$
> qu'une fois 10'000$ parce que les autres se seront résignés à perdre leurs
> données...
> Ce genre de malwares est fait pour infecter beaucoup de machines
> rapidement, donc le pirate doit réclamer une somme que tout américain moyen
> serait capable de payer s'il veut espérer recevoir un maximum de paiements.
> S'il veut toucher une fois une grosse somme, le "pirate" s'attaquera à une
> cible spécifique dont il connaîtra les moyens financiers.
> 
> 



je suis tout à fais d'accord. Pour avoir déjà eu à gérer les relations avec ces 
escrots pour des clients la hotline de certains d’entre nous sont loins d’être 
aussi rapide ;-)
On correspond par mail et les réponses tombes dans les minutes qui suivent. Ils 
ont tout intérêt à ce que leurs business tourne le mieux possible. Pour info en 
regardant le blockchain, le wallet en Bitcoin des ravisseur avait engrangé 75 
bitcoin en une semaine… c’est très lucratif, donc ca va perdurer … 

Un conseil si vous souhaitez payer. Lorsque vous prenez contact avec eux et 
qu’ils vous demande un document comme preuve qu’ils sont bien en capacité de le 
décoder, envoyez une photo de vous en vacance, ça coutera moins chères que si 
vous envoyé une facture ou une pièce ayant un caractère professionnel. Pour du 
perso c’est de l’ordre de 1 bitcoin alors que du pro c’est 4 et plus …

  

Lilian Coupat | Abeille Informatique
5 Avenue du Maréchal Leclerc - 63800 Cournon d'Auvergne
04 73 145 145 | lil...@abeille.com  | 
www.abeille.com 


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

Re: [FRnOG] [TECH] detection VPN SSL

[Tristan Mahé]

Hello,

ça m'étonne que personne n'ai mentionné les iodines (
http://code.kryo.se/iodine/README.html ) et autres vpn-ws dans les trucs
à detecter si tu veux vraiment couper
toutes les solutions VPN...

Le fait d'enforce un proxy sur tcp/443 en cassant les connections
'longues', tu va casser websocket avec, et n'empechera pas le reconnect
auto ;)

Tout ça pour dire que le plus simple est peut-être le contrôle du parc
et/ou l'injection du CA dans les postes clients ;)

My 2 cents...

On 03/08/2016 03:44 AM, Erik LE VACON wrote:
> Bonjour,
>
> Sans faire de uutbound SSL Decryption via un SSL Forward Proxy, tu risques un 
> jeu du chat et de la souris éternel.
> Le filtrage par IP cible via présence d'un reverse selon un format peut 
> aider, mais le mec qui tape une instance AWS ou un VPS chez un gros hébergeur 
> de contenu "standard" te ferme la porte des blocs IP sortants sans risquer de 
> bloquer du trafic légitime.
> Si ton client a des moyens, seul l'interco en coupure d'un boitier de 
> déchiffrement "on the fly"  via présentation d'un certificat bidon "on 
> behalf" du serveur cible, présente une efficacité supérieure vis-à-vis d'un 
> filtrage par ip/domaine cible, regex sur fqdn, etc...
> Le processus est le suivant: le boitier intercepte les requêtes SSL/TLS 
> sortantes; et génère un certif à la volée du site cible. En général, même la 
> date de validité est "fakée" pour reprendre celle du site cible. 
> Concrètement, l'autorité de délivrance du fake-certif est le boitier 
> lui-même, ce qui génère un warning côté utilisateur si l'AC du boitier n'est 
> pas ajoutée aux AC "clean" du browser client (lourd à mettre en oeuvre sur 
> les grosses infras composites)
> Autant dire que le petit malin aura un warning à la connexion s'il n'est pas 
> en mode "ignore cert warnings/self-signed certifs" sur son client VPN, donc 
> soit ca le calme, soit il va chercher une alternative.
> Plusieurs constructeurs proposent de tels boitiers (PaloAlto par ex) avec des 
> résultats inégaux selon les contextes.
> Bon courage (c'est le genre de défis où on sait quand ca commence  ;) 
> )
>
> My two...
>
> - Mail original -
> De: "Jocelyn Lagarenne" 
> À: "Bruno LEAL DE SOUSA" 
> Cc: "Jérôme MARTINIERE" , 
> frnog-t...@frnog.org
> Envoyé: Mardi 8 Mars 2016 11:56:24
> Objet: Re: [FRnOG] [TECH] detection VPN SSL
>
> Merci de vos retours.
>
> 2016-03-08 11:40 GMT+01:00 Bruno LEAL DE SOUSA :
>
>> Hello,
>>
>> Le proxy est interne ou externe ?
>> Ils doivent obligatoirement passer par le proxy ?
>>
>> J'ai connu un cas où le proxy était externe et pour protéger des VPN, la
>> règle était :
>>
>>- On bloque tous les connexions chiffrées https, ssl-smpt, pptp, etc...
>>- On autorise la sortie https uniquement vers le proxy
>>
>> Ainsi toutes les connexions vpn étaint bloquées.
>>
>> les proxies sont internes, tout passe par eux. mais je ne comprend pas en
> quoi cela va bloquer les VPN SSL. En effet on peut bloquer les VPN du type
> PPTP, IPsec, ssh etc, mais concernant les vpn ssl utilisant la connexion du
> navigateur, il me semble que cela ne change rien. Je me trompe peut etre.
> Je vais faire des tests avec un serveur opensource : adito voir ce que ça
> me genere comme traffic.
>
>
>
>> A+
>>
>> Le 8 mars 2016 à 11:19, Jérôme MARTINIERE <
>> j.martini...@groupe-alliance.com> a écrit :
>>
>>> Bonjour,
>>>
>>> Quel est le but final du filtrage ?
>>>
>> limiter les fuites d'information, et mieux contrôler notre réseaux.
> L'entreprise possède plusieurs 100aine d'utilisateurs dont beaucoup
> d'informaticiens, et cela devient de plus en plus dur de "maîtriser" le
> réseau.
>
>
>>> Sans casser le chiffrage par un proxy, il est possible de filtrer par
>>> FQDN ou classes d’IP, notamment pour exclure les tunnels vers des IP de FAI
>>> « grand public » par exemple ou vers les fournisseurs de proxy web.
>>>
>>> h, je vais voir ce qu'il est possible de faire avec ça, je n'y avais
> pas spécialement pensé. est ce que c'est réellement réalisable ? j'avais
> penser en effet à un whitelistage, mais je me suis dit que ça deviendrait
> ingerable tres vite ... mais peut etre au niveau classes d'IP, cela fera
> deja un filtre...
>
>
>
>> Cordialement,
>>> Jérôme MARTINIERE
>>>
>>> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part
>>> de Jocelyn Lagarenne
>>> Envoyé : mardi 8 mars 2016 10:45
>>> À : frnog-t...@frnog.org
>>> Objet : [FRnOG] [TECH] detection VPN SSL
>>>
>>> Bonjour à tous,
>>>
>>> je me retrouve face à un dilemme. On me demande de proposer une solution
>>> pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le
>>> traffic au travers d'un proxy est identique à un traffic https. il est donc
>>> impossible de le detecter non ? ou est ce que je fais fausse route ?
>>> Il est techniquement envisageable de casser le https sur les proxys mais
>>> 

Re: [TECH] [FRnOG] Cryptolog et clients mails

[Xavier Beaudouin]

Hello,

(ceci ne reflete que mon expérience et je ne suis pas le shaman du réseau, hein 
romain).

> Euh, c’est plutôt le client léger qui est le moins vulnérable, à priori.

+1 mais bon leger... Firefox / Chrome -> joker.


>> Partant du principe que cette saleté se propage -pour le moment- par email,
>> pensez vous que les utilisateurs de clients léger (de type webmail) soient 
>> plus
>> vulnérables que ceux utilisant des clients lourds ? (Thunderbird par ex).
>> 
>> A titre personnel, j'ai modifié le réglage de certains de mes comptes pour 
>> que
>> TB ne relève que les en-têtes des mails. Libre à moi de poursuivre le
>> chargement unique ment pour les courriers vraiment intéressant.
>> 
>> La première conséquence de tout cela, est que suivre une discussion sur FrnOG
>> devient un peu plus contraignant :)
>> Et j'imagine que pour un Dupuy-Morizeau, ça doit devenir un cauchemar !
>> 
>> Pensez vous que cette solution du client lourd pourrait s’avérer être un
>> "filtre" un peu efficace contre ce genre de menaces ?
>> J'ai quelques doutes sur la capacité de mes clients à utiliser leur tête 
>> avant
>> de cliquer... Je sais que je vais faire un bide auprès de mes trafiquant de
>> .pps

Aucune idée, je viens de voir arriver le coup des pseudo message vocaux avec un 
.wav.zip.

Par contre vu que les clients leger ne lance pas n'importe quoi tout seul... ca 
peux "limiter" la chose.

Mais dans un milieu "boite" y a tjrs des gens qui sont plus attaché a leur truc 
lourd : outlook / thunderbird / mail.app... Bref.

A part mutt je ne vois pas comment by passer ce genre de choses (ah si : ne pas 
utiliser windows... pour l'instant).

Xavier


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

Re: [FRnOG] [TECH] Wake On Lan Routage

[Louis]

de mémoire, il faut que le routeur qui porte la gateway du niveau 2 soit
configuré pour router les IPs de broadcast

Le 8 mars 2016 à 13:09, Sylvain Rochet  a écrit :

> Salut Hugo,
>
> On Tue, Mar 08, 2016 at 01:06:36PM +0100, Sylvain Rochet wrote:
> > On Tue, Mar 08, 2016 at 12:02:01PM +, SIMANCAS Hugo wrote:
> > >
> > > Est-ce que le WOL est fonctionnel sur un réseau routé ou la demande
> > > doit forcément venir d'un même réseau L2 ?
> >
> > WOL est fonctionnel sur un réseau routé, c'est de l'UDP/IP.
>
> Plus exactement, avant qu'un pinailleur se réveille ;-), c'est un peu
> tout ce que tu veux, tant que ça arrive sur la machine:
>
> https://en.wikipedia.org/wiki/Wake-on-LAN#Magic_packet
>
> Sylvain
>

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

Re: [FRnOG] Re: [ALERT] Cryptolock (faites des sauvegardes)

[MANGA Willy Ted]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Le 08/03/2016 13:45, Carroussel Informatique a écrit :
> [...] J'ai contacté le cabinet, qui développe lui même son 
> joliciel, et lui ai demandé s'il comptait faire une version linux. 
> On m'a envoyé me faire lanlaire...

Tu places leur environnement dans une VM (gérée par KVM) :P

- -- 
Willy Manga
freenode: ongolaBoy
Ubuntu Cameroonian Loco Team
https://launchpad.net/~manga-willy
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iQIcBAEBAgAGBQJW3wsRAAoJELJWcwZanTJqh0YP/1QP82wYCf7CqSN6ZloNbTWs
Iz4sA4uok+eXEABrTX5Ff3HP1lw0ppHB/TFS6qW+GsGPgHbcZhX4NzIDPScu0sdy
YIFfc2j0SLmvuX9dQR0alSkkAAKMTJDoGQ0/Ykf6xobMVZqcV5bgzrFuQ60J+2Qz
XoybORAf/hQ4cgT0N8P+4TdcCArkvkNBnF7LhEU5K+HGdlJRvDvsnrOutzPZw/9A
Mu1S0lDLGcFvdHhZ7kLegJ40U3thbXZXgktPdyqW9Q8lCT+BUk0NPyvOe7r1ww/k
cEbMlNr7e37wFZTPLPCmwIoDB0rKFy8q4L6Md3SGh+5XxKijCiPifevA/Saatwkp
Tm7C1dlVQzauy2hjWl2TaH6F+x1DvSKgbf/iN8JX3RTBOKwiqdAs9E1dv9th8gDX
ao5QQuzuvHsB/e7qHvHN7nNKZQXUAFOXReXrZO7cvLKb58cqCVT2urhsoXMEJvgI
iqSuUWzzRbkkfiE2OzC80Ju3HXtTcX5Euhtk2j7EJsDqouNmwSB0ANJhhjNPnj7n
NMVLiYO4yBk37UGOVYvTAXufv7d1WK/VBNOSwUR8UZ+FGxNV9Q0mmlTHpJJxutO1
E2JOLkeM+NiwU/Jg1M5hqiPIcxc3NiCG/BEGf26lPvCR06ZwljOUhpfEHU6qCW4n
RSBliVZ5yRcQhHLKQv+D
=ZScN
-END PGP SIGNATURE-


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

Re: [FRnOG] Re: [ALERT] Cryptolock

[Laurent Cheylus]

Bonjour,

On Mon, Mar 07, 2016 at 03:55:49PM +0100, Yannick Guerrini wrote:
> Il me semble avoir également vu passer du pdf. C'est possible d'ailleurs
> de lancer automatiquement un script avec ce type de fichier ?

Bien sûr que ce possible, malheureusement :( Il est possible d'embarquer
du Javascript dans du PDF et de le faire exécuter à l'ouverture par
Adobe Reader : https://www.adobe.com/devnet/acrobat/javascript.html

J'ai pas vérifié dernièrement la conf. par défaut mais pour ceux qui
utilisent Adobe (crap) Reader pour lire du PDF, c'est une sage
précaution de désactiver l'exécution du Javascript dans ses paramètres
de conf.

PS : SVP "chiffrés" les fichiers ils sont, pas "cryptés" ! Allez relire le
Bortz :) http://www.bortzmeyer.org/cryptage-n-existe-pas.html

A++ Laurent


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

Re: [FRnOG] Re: [ALERT] Cryptolock

[Sylvain Vallerot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 08/03/2016 15:59, Barthélémy DELUY wrote:
> Je penche plutôt pour l'autre option .
> 
> Un hacker n'a RIEN à gagner à faire grimper les enchères une fois que le
> système est infecté. 
[..]
> S'il veut toucher une fois une grosse somme, le "pirate" s'attaquera à une
> cible spécifique dont il connaîtra les moyens financiers.

Il a par contre intérêt à se faire respecter : la boite qui contre l'attaque
en restaurant ses backups c'est pas bon pour lui. C'est pourquoi une évolution
logique de ces rançongiciels serait que le sinistre soit réitéré jusqu'au
paiement effectif.


On 07/03/2016 23:06, frnog.kap...@antichef.net wrote:
> Se servir d'un rançongiciel pour saboter discrètement une entreprise c'est 
> une 
> utilisation inhabituelle de ce type d'attaque.

C'est aussi le mécanisme qui fait que le dirigeant va être motivé à payer la 
rançon,
il n'y a pas que la perte de certaines données, il y a aussi la perte de 
productivité
Quand une boite passe une journée à restaurer ses backups le temps perdu a un 
coût qui
peut être très important. Sans compter la nécessité de nettoyer les postes 
infectés
qui peut nécessiter un travail voire une expertise, coûteux eux aussi.

Si ça se produit à répétition la restauration des archives n'est plus d'un très
grand secours.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iF4EAREIAAYFAlbe67MACgkQJBGsD8mtnRHDXAEAhX6BpfzjThcoSS6qCvxgYMCU
2HgbYSpefxV0JLDHr1QA/RZaORuGxYIDKt/4dfluT4Iq8aaCBOjLeVuvwlBrE8uw
=Jbio
-END PGP SIGNATURE-


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

Re: [FRnOG] Re: [ALERT] Cryptolock

[Barthélémy DELUY]

Je penche plutôt pour l'autre option .

Un hacker n'a RIEN à gagner à faire grimper les enchères une fois que le
système est infecté. S'il fait ça, il perd en crédibilité, donc plus aucun
client ne paiera. Ils ont au contraire tout à gagner à livre la clé de
déchiffrement le plus rapidement possible, pour gagner la "confiance" d'un
maximum de victimes potentielles. Il vaut mieux tirer cent fois 1000$
qu'une fois 10'000$ parce que les autres se seront résignés à perdre leurs
données...
Ce genre de malwares est fait pour infecter beaucoup de machines
rapidement, donc le pirate doit réclamer une somme que tout américain moyen
serait capable de payer s'il veut espérer recevoir un maximum de paiements.
S'il veut toucher une fois une grosse somme, le "pirate" s'attaquera à une
cible spécifique dont il connaîtra les moyens financiers.



Le 8 mars 2016 à 12:22, Carroussel Informatique  a
écrit :

> J'imagine que oui... mais :
> - Rien n’empêche le maitre chanteur de décider abruptement, une fois la
> rançon payé,  que en fait c'est pas 300 boules, mais 400.
> - Le rancongiciel peut être à deux étages, se planquer et attendre
> quelques jours avant de repasser une seconde couche...
>
> On a affaire à des maitres chanteurs... ne pas l'oublier. :(
>
>
> Le 08/03/2016 12:09, Louis a écrit :
>
>> Une question que je me pose : si on paye la rançon, est-ce qu'on récupère
>> un moyen de déchiffrer les fichiers?
>>
>>
>> Le 7 mars 2016 à 23:06,  a écrit :
>>
>> On lundi 7 mars 2016 18:04:24 CET Sylvain Vallerot - sylv...@gixe.net
>>> wrote:
>>>
 Bonsoir,

 On 07/03/2016 17:43, frnog.kap...@antichef.net wrote:

> L'éfficacité de l'extorsion par rançongiciel exploite le fait que
>
 presque
>>>
 personne ne fait de sauvegarde. Plus les gens feront des sauvegardes et
> moins cette attaque sera profitable, Ce qui est encore le meilleur
>
 moyen
>>>
 de défense contre ce type d'attaque.
>
 Pas vraiment d'accord, si la machine est compromise le rançongiciel est
 toujours capable de faire des dégâts et de ruiner la productivité d'une
 personne ou entreprise.

>>> Se servir d'un rançongiciel pour saboter discrètement une entreprise
>>> c'est
>>> une
>>> utilisation inhabituelle de ce type d'attaque. Pour l'instant l'analyse
>>> du
>>> marché indique que la motivation dérrière les rançongiciels c'est de
>>> rapporter
>>> de l'argent, à la fois au programmeur qui le vends et aux escrocs qui
>>> s'en
>>> servent.
>>>
>>> Pour ça il faut que les victimes payent la rançon, ce qui n'arrive pas
>>> quand
>>> on a une sauvegarde à restaurer. Le sabotage est un effet de bord qui ne
>>> rapporte pas d'argent en soi et donc n'intéresse pas les opérateurs
>>> actuels.
>>>
>>> Dans tous les cas, avoir des sauvegardes limite les dégats.
>>>
>>> Le rançongiciel laisse deux options:
>>>   1. payer et espérer récupérer ses données
>>>   2. renoncer à ses données et réinstaller
>>> Avoir une sauvegarde et un plan d'action prédéfini ça rajoute une
>>> troisième
>>> option:
>>>   3. restaurer le système et les données les plus récentes
>>>
>>> Suffit d'une toute petite variante pour ça, et
 une autre variante consistera à menacer d'envoyer tes fichier à tes
 concurrents ou les publier sur le net. Tes archives ne te protégeront
 pas de ça.

>>> Chiffrer indistinctement les fichiers d'une machine et identifier les
>>> fichiers
>>> ayant de la valeur et de les transférer sur un serveur distant, ce n'est
>>> pas
>>> une petite variante, c'est même un tout autre type d'attaque qui existe
>>> depuis
>>> bien longtemps, la plus connue étant les numéros de carte bancaires.
>>>
>>>
>>> La sécurité c'est plusieurs volets : pas seulement la disponibilité des
 données mais aussi qu'elles soient disponibles au bon moment et pour la
 bonne personne.

>>> Je parlais quand à moi du volet "quand le désastre est survenu malgré les
>>> mesures de prévention", c'est à dire quand les données ne sont plus
>>> disponibles et qu'il faut rétablir tout ça dans un délai le plus court
>>> possible.
>>>
>>> C'est le même principe que pour la surveillance globale, plus les
> internautes auront recours au chiffrement et plus le coût de cette
> surveillance augmente, diminuant de fait son intérêt.
>
 Pas d'accord non plus. Quand tout le monde chiffrera ses communications
 les gouvernements qui le voudront ne cesseront pas de surveiller mais
 interdiront (comme c'était le cas il y a quelques années encore en
 France
 avec la limitation des tailles des clés autorisées) les pratiques de
 chiffrement qu'ils ne savent pas casser ou contourner. C'est une course
 que ceux qui disposent de la puissance publique (ou financière)

>>> gagneront,
>>>
 et donc probablement une erreur pour les autres de l'encourager ou de la
 hâter puisqu'ils arriveront certainement perdants.

>>> Si tu as suivi 

Re: [FRnOG] [ALERT] Cryptolock

[David Ponzone]

> Le 7 mars 2016 à 18:28, Michel Py  a 
> écrit :
> 
>> David Ponzone a écrit :
>> Pour ma part, j’ai commencé par interdire les pièces jointes contenant zip, 
>> exe, bat, cmd, msi, etc….
>> ainsi que le téléchargement de fichiers du même type.
> 
> Efficace mais impossible dans la plupart des organisations. C'est valable 
> pour les geeks, tu renommes toto.zip toto.zip.xxx avant de l'envoyer,
> Impossible à mettre en pratique dans le monde réel.

Dans le monde réel, l’employé de base (au niveau IT) ne devrait JAMAIS 
télécharger un exe ou un msi sur son PC pour l’installer lui-même.
C’est contamination garantie à court terme.
De même, l’employé de base ne devrait jamais utiliser le mail pour échanger des 
zip, ou autre.

Ensuite, sur le plupart des firewall, tu peux mettre des exceptions pour que 
les geeks puissent jouer.
Tu peux aussi interdire les exe, et autres dangers, seulement dans les mails et 
les laisser passer en HTTP mais bon…

Le seul problème, c’est pour que les mises à jour (et autres) de Microsoft se 
passent normalement, il faut autoriser les dll et cab.

Petit bug chez Checkpoint sur la gamme 600: si on interdit les gzip par HTTP, 
on ne peut plus accéder à impots.gouv.fr.
Si quelqu’un sait pourquoi….mais ça ressemble fortement à une boulette.


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

Re: [FRnOG] [BIZ] Prix fibre Km

[Jean-Pierre Roussanidès]

Cela n'est pas grave car tu a répondu exactement à mon interrogation.

Encore merci.

Le 08/03/2016 13:43, Vincent PINEL a écrit :

Bonjour,

Désolé pour le top post de mon dernier message :(

Le 08/03/2016 12:46, Jean-Pierre Roussanidès a écrit :

Bonjour,

Quelqu'un a une idée du prix d'achat au mètre pour une fibre noire ?

Attention, je ne souhaite pas d'offre commercial d'opérateur qui ne 
possède pas leur réseaux et qui font de la revente, mais bien le prix 
de gros avec les gros fournisseurs d'infra fibre.


Merci de à vous.

JP Roussanidès


---
Liste de diffusion du FRnOG
http://www.frnog.org/
Cela dépend beaucoup du projet, car le prix varie en fonction de la 
durée du contrat et de la distance (et de l'opérateur bien sûr). Il 
existe 2 grands types de mise à disposition :


Le forfait annuel sur 1, 3 ou 5 ans pour une paire de fibre par 
exemple, les tarifs allant de 0,8€/an/ml pour 5 ans et plus de 150km à 
3€/an/ml sur un engagement d'un an et moins de 500m.


Cela peut être également en IRU (droit irrévocable d'usage) de 10, 15 
ou 20 ans. Dans ce cas, il s'agit d'une redevance payable d'avance 
pour la totalité de la durée. Par exemple une paire de fibre de plus 
de 10km sur 10 ans revient à 10€/ml (pour les 10 ans) soit 100K€


Il faut évidemment ajouter après la maintenance de la FON (de 15 cts à 
30 cts du mètre / an)


Mes prix datent peut être un peu mais je doute que cela ait beaucoup 
changé.


++

Vincent


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



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

Re: [FRnOG] Re: [ALERT] Cryptolock (faites des sauvegardes)

[Manu]

Le 08/03/2016 13:45, Carroussel Informatique a écrit :

J'ai contacté le cabinet, qui développe lui même son joliciel,


OMG. La pire horreur que je lis aujourd'hui.

--
Manu Jacquet


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

Re: [FRnOG] [TECH] detection VPN SSL

[Jocelyn Lagarenne]

merci de vos retours. Oui en effet j'ai vu ce genre de boitier et les
documents de l'ANSSI dessus :
http://www.ssi.gouv.fr/uploads/IMG/pdf/NP_TLS_NoteTech.pdf
personnellement je n'aime pas trop ce genre de choses, mais on devra
surement y venir un jour ou l'autre au niveau des entreprises.

est ce que quelqu'un a déjà utilisé des solutions comme adito (aka openvpn
ALS) : https://sourceforge.net/projects/openvpn-als  ?
je n'ai pas encore pu testé, mais je voudrais confirmer ce que je pense :
le traffic vpn est totalement encapsulé dans du https donc totalement
"indetectable" d'un point de vu proxy/firewall/IDS si ce n'est en cassant
le https ou en gérant des catégorisations sur le proxy ou via les
catégories d'IP.

si vous avez des exemples dans vos boites comment vous gérez la gestion des
VPNs je suis très interessé aussi (au sens autorisé/interdit si interdit,
est ce que vous le controlé et si oui: comment, particulierement ce genre
de VPN SSL, les autres sont simple à filtrer).


merci encore de vos differents retours.


2016-03-08 12:44 GMT+01:00 Erik LE VACON :

> Bonjour,
>
> Sans faire de uutbound SSL Decryption via un SSL Forward Proxy, tu risques
> un jeu du chat et de la souris éternel.
> Le filtrage par IP cible via présence d'un reverse selon un format peut
> aider, mais le mec qui tape une instance AWS ou un VPS chez un gros
> hébergeur de contenu "standard" te ferme la porte des blocs IP sortants
> sans risquer de bloquer du trafic légitime.
> Si ton client a des moyens, seul l'interco en coupure d'un boitier de
> déchiffrement "on the fly"  via présentation d'un certificat bidon "on
> behalf" du serveur cible, présente une efficacité supérieure vis-à-vis d'un
> filtrage par ip/domaine cible, regex sur fqdn, etc...
> Le processus est le suivant: le boitier intercepte les requêtes SSL/TLS
> sortantes; et génère un certif à la volée du site cible. En général, même
> la date de validité est "fakée" pour reprendre celle du site cible.
> Concrètement, l'autorité de délivrance du fake-certif est le boitier
> lui-même, ce qui génère un warning côté utilisateur si l'AC du boitier
> n'est pas ajoutée aux AC "clean" du browser client (lourd à mettre en
> oeuvre sur les grosses infras composites)
> Autant dire que le petit malin aura un warning à la connexion s'il n'est
> pas en mode "ignore cert warnings/self-signed certifs" sur son client VPN,
> donc soit ca le calme, soit il va chercher une alternative.
> Plusieurs constructeurs proposent de tels boitiers (PaloAlto par ex) avec
> des résultats inégaux selon les contextes.
> Bon courage (c'est le genre de défis où on sait quand ca commence 
> ;) )
>
> My two...
>
> - Mail original -
> De: "Jocelyn Lagarenne" 
> À: "Bruno LEAL DE SOUSA" 
> Cc: "Jérôme MARTINIERE" ,
> frnog-t...@frnog.org
> Envoyé: Mardi 8 Mars 2016 11:56:24
> Objet: Re: [FRnOG] [TECH] detection VPN SSL
>
> Merci de vos retours.
>
> 2016-03-08 11:40 GMT+01:00 Bruno LEAL DE SOUSA :
>
> > Hello,
> >
> > Le proxy est interne ou externe ?
> > Ils doivent obligatoirement passer par le proxy ?
> >
> > J'ai connu un cas où le proxy était externe et pour protéger des VPN, la
> > règle était :
> >
> >- On bloque tous les connexions chiffrées https, ssl-smpt, pptp,
> etc...
> >- On autorise la sortie https uniquement vers le proxy
> >
> > Ainsi toutes les connexions vpn étaint bloquées.
> >
> > les proxies sont internes, tout passe par eux. mais je ne comprend pas en
> quoi cela va bloquer les VPN SSL. En effet on peut bloquer les VPN du type
> PPTP, IPsec, ssh etc, mais concernant les vpn ssl utilisant la connexion du
> navigateur, il me semble que cela ne change rien. Je me trompe peut etre.
> Je vais faire des tests avec un serveur opensource : adito voir ce que ça
> me genere comme traffic.
>
>
>
> > A+
> >
> > Le 8 mars 2016 à 11:19, Jérôme MARTINIERE <
> > j.martini...@groupe-alliance.com> a écrit :
> >
> >> Bonjour,
> >>
> >> Quel est le but final du filtrage ?
> >>
> > limiter les fuites d'information, et mieux contrôler notre réseaux.
> L'entreprise possède plusieurs 100aine d'utilisateurs dont beaucoup
> d'informaticiens, et cela devient de plus en plus dur de "maîtriser" le
> réseau.
>
>
> >
> >> Sans casser le chiffrage par un proxy, il est possible de filtrer par
> >> FQDN ou classes d’IP, notamment pour exclure les tunnels vers des IP de
> FAI
> >> « grand public » par exemple ou vers les fournisseurs de proxy web.
> >>
> >> h, je vais voir ce qu'il est possible de faire avec ça, je n'y avais
> pas spécialement pensé. est ce que c'est réellement réalisable ? j'avais
> penser en effet à un whitelistage, mais je me suis dit que ça deviendrait
> ingerable tres vite ... mais peut etre au niveau classes d'IP, cela fera
> deja un filtre...
>
>
>
> > Cordialement,
> >>
> >> Jérôme MARTINIERE
> >>
> >> De : frnog-requ...@frnog.org 

Re: [FRnOG] Re: [ALERT] Cryptolock (faites des sauvegardes)

[Carroussel Informatique]

Bonjour

Le 08/03/2016 12:48, err...@free.fr a écrit :

À vous lire, j'ai l'impression qu'il n'y a que les ordinateurs avec windows qui 
sont touchés, car ça télécharge un exécutable.
j'ai une pensée un peu égoïste: tant pis pour les gens qui sont encore sous 
windows (je ne fais plus d'acharnement thérapeutique).

tandis que sous linux, lorsqu'on télécharge un fichier, il n'est pas executable 
par defaut, il faut le faire volontairement.
ce qui représente une protection naturelle (quoique...)
Et quand bien même on rendrait ce fichier executable, cela n'affecterait que 
les données de l'utilisateur et les fichiers dont il à le droit en écriture.
(ce qui peut faire beaucoup)

mais il y a des environnement de bureau qui utilisent le javascript, ce qui 
pourrai représenter un problème car il ne s'agira pas d'un executable?

on arrive à une forme de selection naturelle sur les systèmes d'exploitation.
sélection naturelle qui est biaisée par la vente forcée (il est encore 
difficile, et pas automatique de se faire rembourser les logiciels fournis avec 
le matériel)
J'ai quelques objections vis à vis du concept de "sélection naturelle" 
des OS...


S'il est vrai que dans le problématique qui nous occupe, ça éliminerais 
beaucoup de problèmes, ça en créerait d'autres :
Déjà, laisser les windowsiens se démener dans leur panade, ça reviens à 
construire un navire, et ne mettre des canots de sauvetage que pour les 
premières classes... Caymal  :)
Ensuite, toutes ces utilisateurs de windows, régulièrement infectés ou 
emmiellés, ça fait des clients et ça me permet de nourrir ma famille 
autrement qu'en perçant des coffres-forts ou en tabassant des petites 
vieilles à la sortie de la messe:p
Et cela fait aussi un paquet d'utilisateur à migrer sous Sinux et à 
éduquer...
Voyons le bon coté des choses : pour des particuliers, sous linux, il y 
a encore beaucoup à faire, et pour certains professionnels, il y en a 
encore plus.

Deux exemples tirés de ma clientèle :
- Un couple d'agriculteurs travaillant en Bio. A priori, plutôt tentés 
par le passage à linux, oui, mais voila, le logiciel de compta utilisé 
par leur cabinet comptable ne tourne "que" sous Windows XP, et requiert 
.Net Framework !
J'ai contacté le cabinet, qui développe lui même son joliciel, et lui ai 
demandé s'il comptait faire une version linux. On m'a envoyé me faire 
lanlaire...
- Un cabinet de gynécologie et un cabinet médical : Le logiciel Vitale 
(qui permet au praticien d’être payé ) tourne sous windows. Le logiciel 
de compta, idem...


Dans l'absolu, ces deux là seraient bien passés sous Sinux, oui, mais 
des outils qui leur sont essentiels ne sont (a priori) pas disponible...
Alors je fait quoi ? Ils me paient pour leur porter assistance, je ne 
peux pas leur sortir l'argument de la sélection naturelle...
Sinon, la sélection naturelle fera son œuvre et c'est moi qui vais 
crever. De faim.


J'enrage, la survie de mon activité est subordonnée à la pérennité d'un 
OS que je n'aime pas.

C'est y pas une belle contradiction ?

Alors je biaise. Les utilisateurs qui n'ont pas spécifiquement besoin de 
Windows, je les passe sous linux, progressivement... au coup par coup...
Mais chez certains, linux marche tellement bien, qu'ils ne m’appellent 
plus pour les dépanner...


Pour en revenir à cette affaire de cryptolock, combien de temps avant 
que linux soit aussi affecté ?


Je crois que je vais tout plaquer et aller faire pousser des chèvres 
dans le Larzac ! ;-)



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

Re: [FRnOG] [BIZ] Prix fibre Km

[Vincent PINEL]

Bonjour,

Cela dépend beaucoup du projet, car le prix varie en fonction de la 
durée du contrat et de la distance (et de l'opérateur bien sûr). Il 
existe 2 grands types de mise à disposition :


Le forfait annuel sur 1, 3 ou 5 ans pour une paire de fibre par exemple, 
les tarifs allant de 0,8€/an/ml pour 5 ans et plus de 150km à 3€/an/ml 
sur un engagement d'un an et moins de 500m.


Cela peut être également en IRU (droit irrévocable d'usage) de 10, 15 ou 
20 ans. Dans ce cas, il s'agit d'une redevance payable d'avance pour la 
totalité de la durée. Par exemple une paire de fibre de plus de 10km sur 
10 ans revient à 10€/ml (pour les 10 ans) soit 100K€


Il faut évidemment ajouter après la maintenance de la FON (de 15 cts à 
30 cts du mètre / an)


Mes prix datent peut être un peu mais je doute que cela ait beaucoup changé.

++

Vincent


Le 08/03/2016 12:46, Jean-Pierre Roussanidès a écrit :

Bonjour,

Quelqu'un a une idée du prix d'achat au mètre pour une fibre noire ?

Attention, je ne souhaite pas d'offre commercial d'opérateur qui ne 
possède pas leur réseaux et qui font de la revente, mais bien le prix 
de gros avec les gros fournisseurs d'infra fibre.


Merci de à vous.

JP Roussanidès


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



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

Re: [FRnOG] [TECH] Wake On Lan Routage

[Sylvain Rochet]

Salut Hugo,

On Tue, Mar 08, 2016 at 01:06:36PM +0100, Sylvain Rochet wrote:
> On Tue, Mar 08, 2016 at 12:02:01PM +, SIMANCAS Hugo wrote:
> > 
> > Est-ce que le WOL est fonctionnel sur un réseau routé ou la demande 
> > doit forcément venir d'un même réseau L2 ?
> 
> WOL est fonctionnel sur un réseau routé, c'est de l'UDP/IP.

Plus exactement, avant qu'un pinailleur se réveille ;-), c'est un peu 
tout ce que tu veux, tant que ça arrive sur la machine:

https://en.wikipedia.org/wiki/Wake-on-LAN#Magic_packet

Sylvain


signature.asc
Description: Digital signature

Re: [FRnOG] [TECH] Wake On Lan Routage

[Jérôme Nicolle]

Hugo,

Le 08/03/2016 13:02, SIMANCAS Hugo a écrit :
> Est-ce que le WOL est fonctionnel sur un réseau routé ou la demande doit 
> forcément venir d'un même réseau L2 ?

WoL est en UDP, donc routable. Il faut que la cible soit joignable, donc
le port UP et l'IP cible dans la table MAC du switch.

@+

-- 
Jérôme Nicolle
06 19 31 27 14


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

Re: [FRnOG] [TECH] Wake On Lan Routage

[David Ponzone]

https://fr.wikipedia.org/wiki/Wake-on-LAN#Fonctionnement


> Le 8 mars 2016 à 13:02, SIMANCAS Hugo  a 
> écrit :
> 
> Bonjour,
> 
> Est-ce que le WOL est fonctionnel sur un réseau routé ou la demande doit 
> forcément venir d'un même réseau L2 ?
> 
> Merci
> 
> Hugo
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Wake On Lan Routage

[Sylvain Rochet]

Salut Hugo,

On Tue, Mar 08, 2016 at 12:02:01PM +, SIMANCAS Hugo wrote:
> 
> Est-ce que le WOL est fonctionnel sur un réseau routé ou la demande 
> doit forcément venir d'un même réseau L2 ?

WOL est fonctionnel sur un réseau routé, c'est de l'UDP/IP.

Sylvain


signature.asc
Description: Digital signature

[FRnOG] [TECH] Wake On Lan Routage

[SIMANCAS Hugo]

Bonjour,

Est-ce que le WOL est fonctionnel sur un réseau routé ou la demande doit 
forcément venir d'un même réseau L2 ?

Merci

Hugo

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

Re: [FRnOG] [TECH] Logiciel d'analyse de chargement de page web

[Yanik Cawidrone]

Bonjour,

Avez vous pensé à des choses comme yslowjs (node.js phantomjs).
Je ne sais plus si il a le degré de granularité souhaité mais il est tout
en cli, scriptable donc et en plus pour les fans il peut formatter sa
sortie en json.

Yanik
On 8 Mar, 2016 7:52 pm, "Pierre DOLIDON"  wrote:

> Gans le même genre, ya https://gtmetrix.com/
>
> Le 07/03/2016 20:12, Raphael Luta a écrit :
>
>> Le meilleur outil sur le sujet est http://www.webpagetest.org qui te
>> permet de faire tes tests depuis plusieurs points dans le monde avec des
>> profils bande passante/latence spécifiques, faire un filmstrip, tester des
>> scenarios de panne partielle, etc...
>>
>> En outil à installer en local, les profilers Firefox et Chrome sont bien,
>> tu peux installer sitespeed.io en plus si tu veux un diagnostic un peu
>> plus en profondeur.
>>
>> -- raphael
>>
>> Le 7 mars 2016 à 19:40, Michel Py  a
>>> écrit :
>>>
>>> Bonjour à tous,
>>>
>>> Est-ce que quelqu'un pourrait recommander un logiciel d'analyse de
>>> chargement d'une page web ?
>>>
>>> L'Internet est lent !

>>> Plein de bande passante, et c'est seulement certaines pages qui sont
>>> lentes. Je cherche un logiciel qui permettrait d'identifier quels sont les
>>> éléments de la page en question qui ralentissent le chargement, combien de
>>> requêtes sont envoyées, etc. Gratuit ou abordable de préférence. C'est OK
>>> si çà demande de sniffer, par exemple un add-on de Wireshark ou autre qui
>>> nécessite de spanner un port serait acceptable.
>>>
>>> Merci
>>> Michel.
>>>
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] Re: [ALERT] Cryptolock (faites des sauvegardes)

[Alexis Lameire]

Un petit dicton bien vrai sur les sauvegardes

La périodicité des sauvegardes est inversement proportionel à la quantité
de travail qui peut être recommancé"

Alexis

Le 8 mars 2016 à 12:48,  a écrit :

>
> À vous lire, j'ai l'impression qu'il n'y a que les ordinateurs avec
> windows qui sont touchés, car ça télécharge un exécutable.
> j'ai une pensée un peu égoïste: tant pis pour les gens qui sont encore
> sous windows (je ne fais plus d'acharnement thérapeutique).
>
> tandis que sous linux, lorsqu'on télécharge un fichier, il n'est pas
> executable par defaut, il faut le faire volontairement.
> ce qui représente une protection naturelle (quoique...)
> Et quand bien même on rendrait ce fichier executable, cela n'affecterait
> que les données de l'utilisateur et les fichiers dont il à le droit en
> écriture.
> (ce qui peut faire beaucoup)
>
> mais il y a des environnement de bureau qui utilisent le javascript, ce
> qui pourrai représenter un problème car il ne s'agira pas d'un executable?
>
> on arrive à une forme de selection naturelle sur les systèmes
> d'exploitation.
> sélection naturelle qui est biaisée par la vente forcée (il est encore
> difficile, et pas automatique de se faire rembourser les logiciels fournis
> avec le matériel)
>
> Dans tous les cas (quelque soit le système d'exploitation), il faut faire
> des sauvegarde des fichiers importants
> (celà a déjà été dit plusieurs fois dans le fil de discussion)
> car on n'est pas toujours à l'abri d'un accident (innondation, incendie,
> foudre...)
> ou d'une erreur de manipulation (sans parler des vols ou cambriolages).
>
> j'ai déjà subi des pertes de fichiers importants, soit parce que je
> n'avais pas de sauvegarde, soit parce que la sauvegarde ne fonctionnait pas
> non plus.
> (on finit par devenir de plus en plus mefiant :p )
> Ces pertes de fichiers ont été dues à des disques durs qui sont mort avant
> que j'ai le temps de récupérer les données,
> ou parce qu'un admin s'était trompé de client et avait écrasé les données
> de mon serveur brutalement (ça ne m'est arrivé qu'une seule fois, pour un
> serveur chez Online).
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Logiciel d'analyse de chargement de page web

[Pierre DOLIDON]

Gans le même genre, ya https://gtmetrix.com/

Le 07/03/2016 20:12, Raphael Luta a écrit :

Le meilleur outil sur le sujet est http://www.webpagetest.org qui te permet de 
faire tes tests depuis plusieurs points dans le monde avec des profils bande 
passante/latence spécifiques, faire un filmstrip, tester des scenarios de panne 
partielle, etc...

En outil à installer en local, les profilers Firefox et Chrome sont bien, tu 
peux installer sitespeed.io en plus si tu veux un diagnostic un peu plus en 
profondeur.

-- raphael


Le 7 mars 2016 à 19:40, Michel Py  a écrit :

Bonjour à tous,

Est-ce que quelqu'un pourrait recommander un logiciel d'analyse de chargement 
d'une page web ?


L'Internet est lent !

Plein de bande passante, et c'est seulement certaines pages qui sont lentes. Je 
cherche un logiciel qui permettrait d'identifier quels sont les éléments de la 
page en question qui ralentissent le chargement, combien de requêtes sont 
envoyées, etc. Gratuit ou abordable de préférence. C'est OK si çà demande de 
sniffer, par exemple un add-on de Wireshark ou autre qui nécessite de spanner 
un port serait acceptable.

Merci
Michel.


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



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

Re: [FRnOG] Re: [ALERT] Cryptolock (faites des sauvegardes)

[err404]

À vous lire, j'ai l'impression qu'il n'y a que les ordinateurs avec windows qui 
sont touchés, car ça télécharge un exécutable.
j'ai une pensée un peu égoïste: tant pis pour les gens qui sont encore sous 
windows (je ne fais plus d'acharnement thérapeutique).

tandis que sous linux, lorsqu'on télécharge un fichier, il n'est pas executable 
par defaut, il faut le faire volontairement.
ce qui représente une protection naturelle (quoique...)
Et quand bien même on rendrait ce fichier executable, cela n'affecterait que 
les données de l'utilisateur et les fichiers dont il à le droit en écriture.
(ce qui peut faire beaucoup)

mais il y a des environnement de bureau qui utilisent le javascript, ce qui 
pourrai représenter un problème car il ne s'agira pas d'un executable?

on arrive à une forme de selection naturelle sur les systèmes d'exploitation.
sélection naturelle qui est biaisée par la vente forcée (il est encore 
difficile, et pas automatique de se faire rembourser les logiciels fournis avec 
le matériel)

Dans tous les cas (quelque soit le système d'exploitation), il faut faire des 
sauvegarde des fichiers importants
(celà a déjà été dit plusieurs fois dans le fil de discussion)
car on n'est pas toujours à l'abri d'un accident (innondation, incendie, 
foudre...)
ou d'une erreur de manipulation (sans parler des vols ou cambriolages).

j'ai déjà subi des pertes de fichiers importants, soit parce que je n'avais pas 
de sauvegarde, soit parce que la sauvegarde ne fonctionnait pas non plus.
(on finit par devenir de plus en plus mefiant :p )
Ces pertes de fichiers ont été dues à des disques durs qui sont mort avant que 
j'ai le temps de récupérer les données,
ou parce qu'un admin s'était trompé de client et avait écrasé les données de 
mon serveur brutalement (ça ne m'est arrivé qu'une seule fois, pour un serveur 
chez Online).


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

[FRnOG] [BIZ] Prix fibre Km

[Jean-Pierre Roussanidès]

Bonjour,

Quelqu'un a une idée du prix d'achat au mètre pour une fibre noire ?

Attention, je ne souhaite pas d'offre commercial d'opérateur qui ne 
possède pas leur réseaux et qui font de la revente, mais bien le prix de 
gros avec les gros fournisseurs d'infra fibre.


Merci de à vous.

JP Roussanidès


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

Re: [FRnOG] [TECH] detection VPN SSL

[Erik LE VACON]

Bonjour,

Sans faire de uutbound SSL Decryption via un SSL Forward Proxy, tu risques un 
jeu du chat et de la souris éternel.
Le filtrage par IP cible via présence d'un reverse selon un format peut aider, 
mais le mec qui tape une instance AWS ou un VPS chez un gros hébergeur de 
contenu "standard" te ferme la porte des blocs IP sortants sans risquer de 
bloquer du trafic légitime.
Si ton client a des moyens, seul l'interco en coupure d'un boitier de 
déchiffrement "on the fly"  via présentation d'un certificat bidon "on behalf" 
du serveur cible, présente une efficacité supérieure vis-à-vis d'un filtrage 
par ip/domaine cible, regex sur fqdn, etc...
Le processus est le suivant: le boitier intercepte les requêtes SSL/TLS 
sortantes; et génère un certif à la volée du site cible. En général, même la 
date de validité est "fakée" pour reprendre celle du site cible. 
Concrètement, l'autorité de délivrance du fake-certif est le boitier lui-même, 
ce qui génère un warning côté utilisateur si l'AC du boitier n'est pas ajoutée 
aux AC "clean" du browser client (lourd à mettre en oeuvre sur les grosses 
infras composites)
Autant dire que le petit malin aura un warning à la connexion s'il n'est pas en 
mode "ignore cert warnings/self-signed certifs" sur son client VPN, donc soit 
ca le calme, soit il va chercher une alternative.
Plusieurs constructeurs proposent de tels boitiers (PaloAlto par ex) avec des 
résultats inégaux selon les contextes.
Bon courage (c'est le genre de défis où on sait quand ca commence  ;) )

My two...

- Mail original -
De: "Jocelyn Lagarenne" 
À: "Bruno LEAL DE SOUSA" 
Cc: "Jérôme MARTINIERE" , frnog-t...@frnog.org
Envoyé: Mardi 8 Mars 2016 11:56:24
Objet: Re: [FRnOG] [TECH] detection VPN SSL

Merci de vos retours.

2016-03-08 11:40 GMT+01:00 Bruno LEAL DE SOUSA :

> Hello,
>
> Le proxy est interne ou externe ?
> Ils doivent obligatoirement passer par le proxy ?
>
> J'ai connu un cas où le proxy était externe et pour protéger des VPN, la
> règle était :
>
>- On bloque tous les connexions chiffrées https, ssl-smpt, pptp, etc...
>- On autorise la sortie https uniquement vers le proxy
>
> Ainsi toutes les connexions vpn étaint bloquées.
>
> les proxies sont internes, tout passe par eux. mais je ne comprend pas en
quoi cela va bloquer les VPN SSL. En effet on peut bloquer les VPN du type
PPTP, IPsec, ssh etc, mais concernant les vpn ssl utilisant la connexion du
navigateur, il me semble que cela ne change rien. Je me trompe peut etre.
Je vais faire des tests avec un serveur opensource : adito voir ce que ça
me genere comme traffic.



> A+
>
> Le 8 mars 2016 à 11:19, Jérôme MARTINIERE <
> j.martini...@groupe-alliance.com> a écrit :
>
>> Bonjour,
>>
>> Quel est le but final du filtrage ?
>>
> limiter les fuites d'information, et mieux contrôler notre réseaux.
L'entreprise possède plusieurs 100aine d'utilisateurs dont beaucoup
d'informaticiens, et cela devient de plus en plus dur de "maîtriser" le
réseau.


>
>> Sans casser le chiffrage par un proxy, il est possible de filtrer par
>> FQDN ou classes d’IP, notamment pour exclure les tunnels vers des IP de FAI
>> « grand public » par exemple ou vers les fournisseurs de proxy web.
>>
>> h, je vais voir ce qu'il est possible de faire avec ça, je n'y avais
pas spécialement pensé. est ce que c'est réellement réalisable ? j'avais
penser en effet à un whitelistage, mais je me suis dit que ça deviendrait
ingerable tres vite ... mais peut etre au niveau classes d'IP, cela fera
deja un filtre...



> Cordialement,
>>
>> Jérôme MARTINIERE
>>
>> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part
>> de Jocelyn Lagarenne
>> Envoyé : mardi 8 mars 2016 10:45
>> À : frnog-t...@frnog.org
>> Objet : [FRnOG] [TECH] detection VPN SSL
>>
>> Bonjour à tous,
>>
>> je me retrouve face à un dilemme. On me demande de proposer une solution
>> pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le
>> traffic au travers d'un proxy est identique à un traffic https. il est donc
>> impossible de le detecter non ? ou est ce que je fais fausse route ?
>> Il est techniquement envisageable de casser le https sur les proxys mais
>> ce n'est pas une recommandation que j'aime.
>> la seul solution que je vois est de détecter les connexions SSL "longue"
>> et de vérifier ce qu'elles sont (eliminer les faux positives comme par
>> exemple gtalk), mais je ne suis meme pas sure que des logs proxy puissent
>> me donner cette information.
>>
>> Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas
>> dans vos entreprises ?
>>
>> d'avance merci de vos retours
>>
>> Cordialement,
>> --
>> Jocelyn Lagarenne
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>
>
> --
> Bruno LEAL DE SOUSA
> IT System and Network Administrator
> Co-founder and editor of 

Re: [FRnOG] [TECH] Aruba non conciliant avec les VLAN attribués par freeradius

[Antoine Benkemoun-André]

Bonjour à tous,

Je vous fais un retour rapide de sorte à ce que si quelqu’un retombe sur ces 
messages ultérieurement, il aura au moins une piste.

Après avoir posté sur le forum d’Aruba, nous avons eu accès à leur support et 
ils nous ont aidé à troubleshooter tout ca. Le résultat est que c’est un bug 
dans le firmware et ils vont le réparer. La nouvelle version sortira mi-Mars et 
devrait résoudre ce bug.

Bonne journée,

Antoine

> On 29 Feb 2016, at 17:30, Antoine Benkemoun  
> wrote:
> 
> Bonjour à tous,
> 
> Cette requête serait idéalement dirigée vers le support Aruba/HP mais nous
> sommes en train d'essayer de nous démêler au niveau de nos contrats avec
> eux et donc nous sommes coincés en attendant. C'est assez fou comment
> obtenir du support pour des équipements achetés par les canaux officiels du
> constructeur peut être compliqué... Bref.
> 
> Nous avons 5 bornes Aruba IAP-205 qui vont remplacer nos bornes Cisco
> Aironet 2609. Une de ces bornes est master des autres.
> 
> Nous avons fait la configuration du freeradius pour qu'il fasse
> l'authentification des clients en 802.1X via le NTLM et qu'il fasse ensuite
> un lookup LDAP pour envoyer des attributs en fonction de la présence de
> l'utilisateur dans un groupe donné. On a essayé d'utiliser les attributs
> vendor-specific Aruba-User-Vlan et Aruba-User-Role ainsi que les attributs
> Tunnel de Microsoft.
> 
> Cette partie-là fonctionne car dans le freeradius -X les attributs
> s'affichent correctement et sur la capture Wireshark les attributs sont
> bien présents dans les paquets.
> 
> Néanmoins, lorsque l'Aruba reçoit ces attributs, il n'en fait rien 2 fois
> sur 3. Avec certains utilisateurs, 2 de leurs équipements sont dans le VLAN
> par défaut et 1 équipement est dans le bon VLAN. Pour les autres, c'est
> apparemment aléatoire.
> 
> On a sorti le débug des AP et on remarque que lorsque ca fonctionne on a la
> ligne suivante :
> 
> <501142>  <172.17.16.2 84:D4:7E:C0:A0:FA>  Derive user vlan:
> 98:e0:d9:ae:83:29 Derive user Vlan 1700 from VSA
> 
> Lorsque ca ne fonctionne pas, on a quelque chose comme ca à la place :
> 
> <172.17.16.2 84:D4:7E:C0:A0:FA> stm[1852]:
> VLAN_HIGHER_PRECEDENCE_THAN_STORED: 1064: vlan_rule_index=ff,
> sap_sta->vlanhow=ff, precedence_result=1
> <172.17.16.2 84:D4:7E:C0:A0:FA> stm[1852]: __HIGHER_PRECEDENCE_COMPARE:
> 1041: matched_rule_index=37fff, sap_sta->acl_rule_index=0,
> precedence_result=1
> stm[1852]: <501146>  <172.17.16.2 84:D4:7E:C0:A0:FA>  Derive user
> role: cc:20:e8:b9:45:43 Match user role  acl 136 rule_index 0x37fff
> 
> On dirait donc qu'il trouve le rôle ailleurs lorsque ca ne fonctionne pas
> mais la question est où ?
> 
> Évidemment quand on faisait les tests dans le lab, ça fonctionnait tout à
> fait correctement sinon c'est pas rigolo !
> 
> Si quelqu'un a déjà rencontré ce problème ou un problème similaire, nous
> sommes donc preneurs de retour :-)
> 
> Merci par avance,
> 
> Antoine
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] wikipedia

[Manu]

Le 08/03/2016 12:09, Olivier Benghozi a écrit :

Il arrive en effet que sur Wikipedia certains cancrelats glaireux
psychorigides, pédants et donneurs de leçons, tout auréolés de leur
prétendue distinction de "mainteneur", prodigues en critiques mais stériles
en constructivité, viennent démontrer leur médiocrité en se comportant tels
un guichetier qui ferait la grève du zèle.


J'ai pas osé.. mais s'il y a bien un souci parfois avec Wikipedia, ce 
sont ces admin :-) Il faut juste faire en sorte que l'article soit un 
peu propre avec quelques références. Et trouver un utilisateur avec plus 
de 50 modif qui donne son avis.


--
Manu Jacquet


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

Re: [FRnOG] [TECH] detection VPN SSL

[Solarus Lumenor]

 

Le 2016-03-08 09:44, Jocelyn Lagarenne a écrit : 

> Bonjour à tous,
> 
> je me retrouve face à un dilemme. On me demande de proposer une solution
> pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le
> traffic au travers d'un proxy est identique à un traffic https. il est donc
> impossible de le detecter non ? ou est ce que je fais fausse route ?
> Il est techniquement envisageable de casser le https sur les proxys mais ce
> n'est pas une recommandation que j'aime.
> la seul solution que je vois est de détecter les connexions SSL "longue" et
> de vérifier ce qu'elles sont (eliminer les faux positives comme par exemple
> gtalk), mais je ne suis meme pas sure que des logs proxy puissent me donner
> cette information.
> 
> Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans
> vos entreprises ?
> 
> d'avance merci de vos retours
> 
> Cordialement,

Les VPN ont un port par défaut qui diffère du port HTTPS, mais
effectivement ils utilisent souvent le TCP/443 pour traverser les proxys
ou pour éviter les QOS non-neutres.Effectivement, il est inconcevable de
casser du HTTPS ou de faire du man in the middle, pour autant il y a des
solutions. 

La première c'est la gestion de parc en interdisant les logiciels de
VPN, mais cela implique d'avoir la main sur tout le parc et sur tous les
équipements qui se connectent.

La seconde c'est de travailles avec un système de blacklist.
Elle consiste à relever les IP jointes en SSL sur le port 443 et à faire
2 vérifications simples.
D'abord un simple reverse de l'IP donne généralement de bonnes infos sur
l'usage de cette IP.
Ensuite avec un telnet sur le port 443 de l'IP en question, on peut voir
si c'est un serveur HTTP au bout ou autre chose. 

La difficulté reste de faire ça à grande échelle ou d'automatiser ça
mais ça me semble la bonne solution. 

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

Re: [FRnOG] Re: [ALERT] Cryptolock

[Carroussel Informatique]

J'imagine que oui... mais :
- Rien n’empêche le maitre chanteur de décider abruptement, une fois la 
rançon payé,  que en fait c'est pas 300 boules, mais 400.
- Le rancongiciel peut être à deux étages, se planquer et attendre 
quelques jours avant de repasser une seconde couche...


On a affaire à des maitres chanteurs... ne pas l'oublier. :(

Le 08/03/2016 12:09, Louis a écrit :

Une question que je me pose : si on paye la rançon, est-ce qu'on récupère
un moyen de déchiffrer les fichiers?


Le 7 mars 2016 à 23:06,  a écrit :


On lundi 7 mars 2016 18:04:24 CET Sylvain Vallerot - sylv...@gixe.net
wrote:

Bonsoir,

On 07/03/2016 17:43, frnog.kap...@antichef.net wrote:

L'éfficacité de l'extorsion par rançongiciel exploite le fait que

presque

personne ne fait de sauvegarde. Plus les gens feront des sauvegardes et
moins cette attaque sera profitable, Ce qui est encore le meilleur

moyen

de défense contre ce type d'attaque.

Pas vraiment d'accord, si la machine est compromise le rançongiciel est
toujours capable de faire des dégâts et de ruiner la productivité d'une
personne ou entreprise.

Se servir d'un rançongiciel pour saboter discrètement une entreprise c'est
une
utilisation inhabituelle de ce type d'attaque. Pour l'instant l'analyse du
marché indique que la motivation dérrière les rançongiciels c'est de
rapporter
de l'argent, à la fois au programmeur qui le vends et aux escrocs qui s'en
servent.

Pour ça il faut que les victimes payent la rançon, ce qui n'arrive pas
quand
on a une sauvegarde à restaurer. Le sabotage est un effet de bord qui ne
rapporte pas d'argent en soi et donc n'intéresse pas les opérateurs
actuels.

Dans tous les cas, avoir des sauvegardes limite les dégats.

Le rançongiciel laisse deux options:
  1. payer et espérer récupérer ses données
  2. renoncer à ses données et réinstaller
Avoir une sauvegarde et un plan d'action prédéfini ça rajoute une troisième
option:
  3. restaurer le système et les données les plus récentes


Suffit d'une toute petite variante pour ça, et
une autre variante consistera à menacer d'envoyer tes fichier à tes
concurrents ou les publier sur le net. Tes archives ne te protégeront
pas de ça.

Chiffrer indistinctement les fichiers d'une machine et identifier les
fichiers
ayant de la valeur et de les transférer sur un serveur distant, ce n'est
pas
une petite variante, c'est même un tout autre type d'attaque qui existe
depuis
bien longtemps, la plus connue étant les numéros de carte bancaires.



La sécurité c'est plusieurs volets : pas seulement la disponibilité des
données mais aussi qu'elles soient disponibles au bon moment et pour la
bonne personne.

Je parlais quand à moi du volet "quand le désastre est survenu malgré les
mesures de prévention", c'est à dire quand les données ne sont plus
disponibles et qu'il faut rétablir tout ça dans un délai le plus court
possible.


C'est le même principe que pour la surveillance globale, plus les
internautes auront recours au chiffrement et plus le coût de cette
surveillance augmente, diminuant de fait son intérêt.

Pas d'accord non plus. Quand tout le monde chiffrera ses communications
les gouvernements qui le voudront ne cesseront pas de surveiller mais
interdiront (comme c'était le cas il y a quelques années encore en France
avec la limitation des tailles des clés autorisées) les pratiques de
chiffrement qu'ils ne savent pas casser ou contourner. C'est une course
que ceux qui disposent de la puissance publique (ou financière)

gagneront,

et donc probablement une erreur pour les autres de l'encourager ou de la
hâter puisqu'ils arriveront certainement perdants.

Si tu as suivi un peu l'actualité politique mondiale, les gouvernements
n'ont
pas attendu que tout le monde ait recours au chiffrement, ils sont déjà en
train d'essayer de contrôler le chiffrement.

Le but n'est pas de se débarasser de la surveillance gouvernementale (pour
ça
il faudrait se débarasser du gouvernement), il s'agit de réduire la
surveillance globalisée, tout enregistrer tout le temps, pour revenir a de
la
surveillance ciblée.  Il est plus rentable de casser le chiffrement de
cibles
définies que de casser le chiffrement de toutes les communications pour en
extraire celles qui nous intéressent. Un retour à la présomption innocence.

Si tu te souviens du passage de la hadopi, la NSA s'était opposée à cette
loi
parce qu'elle risquait de pousser la population a avoir recours au
chiffrement:

http://www.generation-nt.com/hadopi-cryptologie-service-renseignement-chiffrement-actualite-1094171.html


Juste mon avis perso.

Regards,


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




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


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




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

Re: [FRnOG] [MISC] wikipedia

[Olivier Benghozi]

Il arrive en effet que sur Wikipedia certains cancrelats glaireux
psychorigides, pédants et donneurs de leçons, tout auréolés de leur
prétendue distinction de "mainteneur", prodigues en critiques mais stériles
en constructivité, viennent démontrer leur médiocrité en se comportant tels
un guichetier qui ferait la grève du zèle.

Bref, pour résumer on a Docteur Tocard qui vient foutre sa merde parce
qu'il s'ennuie pendant les vacances scolaires.

Comme dans les arts martiaux il faut utiliser la force de l'adversaire
contre lui-même, donc il faudrait que tu ailles (aussi) écrire afin que ça
rentre dans les bonnes cases du règlement de Docteur Tocard :P


Le 8 mars 2016 à 09:19, Philippe Bourcier  a écrit :

>
> Bonjour,
>
> Si des personnes avec un peu de talent d'écriture veulent bien s’atteler à
> la tâche, il semblerait que l'article wikipedia sur FRnOG soit sur le point
> de disparaître (bon, il n'est pas super bien écrit), ce qui serait bien
> dommage, je trouve :
> https://fr.wikipedia.org/wiki/FRnOG
>
> Je pense qu'il manque des références au France-IX et à la participation à
> la poussée des IX en France (via les IX updates lors des réunions)... mais
> bon j'estime que je ne suis pas le mieux placé pour écrire l'article (et
> surtout je suis pas un écrivain né, autant utiliser les talents de gens
> meilleurs que moi :)).
>
> Bonne prose :)
>
>
> Cordialement,
> --
> Philippe Bourcier
> web : http://sysctl.org/
> blog : https://www.linkedin.com/today/author/2298865
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] Re: [ALERT] Cryptolock

[Louis]

Une question que je me pose : si on paye la rançon, est-ce qu'on récupère
un moyen de déchiffrer les fichiers?


Le 7 mars 2016 à 23:06,  a écrit :

> On lundi 7 mars 2016 18:04:24 CET Sylvain Vallerot - sylv...@gixe.net
> wrote:
> > Bonsoir,
> >
> > On 07/03/2016 17:43, frnog.kap...@antichef.net wrote:
> > > L'éfficacité de l'extorsion par rançongiciel exploite le fait que
> presque
> > > personne ne fait de sauvegarde. Plus les gens feront des sauvegardes et
> > > moins cette attaque sera profitable, Ce qui est encore le meilleur
> moyen
> > > de défense contre ce type d'attaque.
> >
> > Pas vraiment d'accord, si la machine est compromise le rançongiciel est
> > toujours capable de faire des dégâts et de ruiner la productivité d'une
> > personne ou entreprise.
>
> Se servir d'un rançongiciel pour saboter discrètement une entreprise c'est
> une
> utilisation inhabituelle de ce type d'attaque. Pour l'instant l'analyse du
> marché indique que la motivation dérrière les rançongiciels c'est de
> rapporter
> de l'argent, à la fois au programmeur qui le vends et aux escrocs qui s'en
> servent.
>
> Pour ça il faut que les victimes payent la rançon, ce qui n'arrive pas
> quand
> on a une sauvegarde à restaurer. Le sabotage est un effet de bord qui ne
> rapporte pas d'argent en soi et donc n'intéresse pas les opérateurs
> actuels.
>
> Dans tous les cas, avoir des sauvegardes limite les dégats.
>
> Le rançongiciel laisse deux options:
>  1. payer et espérer récupérer ses données
>  2. renoncer à ses données et réinstaller
> Avoir une sauvegarde et un plan d'action prédéfini ça rajoute une troisième
> option:
>  3. restaurer le système et les données les plus récentes
>
> > Suffit d'une toute petite variante pour ça, et
> > une autre variante consistera à menacer d'envoyer tes fichier à tes
> > concurrents ou les publier sur le net. Tes archives ne te protégeront
> > pas de ça.
>
> Chiffrer indistinctement les fichiers d'une machine et identifier les
> fichiers
> ayant de la valeur et de les transférer sur un serveur distant, ce n'est
> pas
> une petite variante, c'est même un tout autre type d'attaque qui existe
> depuis
> bien longtemps, la plus connue étant les numéros de carte bancaires.
>
>
> > La sécurité c'est plusieurs volets : pas seulement la disponibilité des
> > données mais aussi qu'elles soient disponibles au bon moment et pour la
> > bonne personne.
>
> Je parlais quand à moi du volet "quand le désastre est survenu malgré les
> mesures de prévention", c'est à dire quand les données ne sont plus
> disponibles et qu'il faut rétablir tout ça dans un délai le plus court
> possible.
>
> > > C'est le même principe que pour la surveillance globale, plus les
> > > internautes auront recours au chiffrement et plus le coût de cette
> > > surveillance augmente, diminuant de fait son intérêt.
> >
> > Pas d'accord non plus. Quand tout le monde chiffrera ses communications
> > les gouvernements qui le voudront ne cesseront pas de surveiller mais
> > interdiront (comme c'était le cas il y a quelques années encore en France
> > avec la limitation des tailles des clés autorisées) les pratiques de
> > chiffrement qu'ils ne savent pas casser ou contourner. C'est une course
> > que ceux qui disposent de la puissance publique (ou financière)
> gagneront,
> > et donc probablement une erreur pour les autres de l'encourager ou de la
> > hâter puisqu'ils arriveront certainement perdants.
>
> Si tu as suivi un peu l'actualité politique mondiale, les gouvernements
> n'ont
> pas attendu que tout le monde ait recours au chiffrement, ils sont déjà en
> train d'essayer de contrôler le chiffrement.
>
> Le but n'est pas de se débarasser de la surveillance gouvernementale (pour
> ça
> il faudrait se débarasser du gouvernement), il s'agit de réduire la
> surveillance globalisée, tout enregistrer tout le temps, pour revenir a de
> la
> surveillance ciblée.  Il est plus rentable de casser le chiffrement de
> cibles
> définies que de casser le chiffrement de toutes les communications pour en
> extraire celles qui nous intéressent. Un retour à la présomption innocence.
>
> Si tu te souviens du passage de la hadopi, la NSA s'était opposée à cette
> loi
> parce qu'elle risquait de pousser la population a avoir recours au
> chiffrement:
>
> http://www.generation-nt.com/hadopi-cryptologie-service-renseignement-chiffrement-actualite-1094171.html
>
> > Juste mon avis perso.
> >
> > Regards,
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] detection VPN SSL

[Jocelyn Lagarenne]

Merci de vos retours.

2016-03-08 11:40 GMT+01:00 Bruno LEAL DE SOUSA :

> Hello,
>
> Le proxy est interne ou externe ?
> Ils doivent obligatoirement passer par le proxy ?
>
> J'ai connu un cas où le proxy était externe et pour protéger des VPN, la
> règle était :
>
>- On bloque tous les connexions chiffrées https, ssl-smpt, pptp, etc...
>- On autorise la sortie https uniquement vers le proxy
>
> Ainsi toutes les connexions vpn étaint bloquées.
>
> les proxies sont internes, tout passe par eux. mais je ne comprend pas en
quoi cela va bloquer les VPN SSL. En effet on peut bloquer les VPN du type
PPTP, IPsec, ssh etc, mais concernant les vpn ssl utilisant la connexion du
navigateur, il me semble que cela ne change rien. Je me trompe peut etre.
Je vais faire des tests avec un serveur opensource : adito voir ce que ça
me genere comme traffic.



> A+
>
> Le 8 mars 2016 à 11:19, Jérôme MARTINIERE <
> j.martini...@groupe-alliance.com> a écrit :
>
>> Bonjour,
>>
>> Quel est le but final du filtrage ?
>>
> limiter les fuites d'information, et mieux contrôler notre réseaux.
L'entreprise possède plusieurs 100aine d'utilisateurs dont beaucoup
d'informaticiens, et cela devient de plus en plus dur de "maîtriser" le
réseau.


>
>> Sans casser le chiffrage par un proxy, il est possible de filtrer par
>> FQDN ou classes d’IP, notamment pour exclure les tunnels vers des IP de FAI
>> « grand public » par exemple ou vers les fournisseurs de proxy web.
>>
>> h, je vais voir ce qu'il est possible de faire avec ça, je n'y avais
pas spécialement pensé. est ce que c'est réellement réalisable ? j'avais
penser en effet à un whitelistage, mais je me suis dit que ça deviendrait
ingerable tres vite ... mais peut etre au niveau classes d'IP, cela fera
deja un filtre...



> Cordialement,
>>
>> Jérôme MARTINIERE
>>
>> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part
>> de Jocelyn Lagarenne
>> Envoyé : mardi 8 mars 2016 10:45
>> À : frnog-t...@frnog.org
>> Objet : [FRnOG] [TECH] detection VPN SSL
>>
>> Bonjour à tous,
>>
>> je me retrouve face à un dilemme. On me demande de proposer une solution
>> pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le
>> traffic au travers d'un proxy est identique à un traffic https. il est donc
>> impossible de le detecter non ? ou est ce que je fais fausse route ?
>> Il est techniquement envisageable de casser le https sur les proxys mais
>> ce n'est pas une recommandation que j'aime.
>> la seul solution que je vois est de détecter les connexions SSL "longue"
>> et de vérifier ce qu'elles sont (eliminer les faux positives comme par
>> exemple gtalk), mais je ne suis meme pas sure que des logs proxy puissent
>> me donner cette information.
>>
>> Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas
>> dans vos entreprises ?
>>
>> d'avance merci de vos retours
>>
>> Cordialement,
>> --
>> Jocelyn Lagarenne
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>
>
> --
> Bruno LEAL DE SOUSA
> IT System and Network Administrator
> Co-founder and editor of *Bidouille-IT* : http://bidouilleit.com
>
> « Failure is the foundation of success, and the means by which it is
> achieved. » - *Lao Tzu*
>



-- 
Jocelyn Lagarenne
06 28 78 30 50

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

Re: [FRnOG] [TECH] detection VPN SSL

[Nathan delhaye]

Hello,

Sinon tu éduque tes décisionnaires/clients et tu leur explique que les VPN
c'est forcément pas le mal :

Si c'est pour éviter les fuites de données, il faut une sécurité de bout en
bout qui commence par interdire aux gens d'installer n'importe quoi sur
leur station de travail/portable. Interdire les VPN ne servira a rien sinon.

Si c'est pour une question de responsabilité (mec qui fait du torrent avec
la fibre @work ou qui visite des sites peu recommendables) le problème ne
se pose pas car on va remonter au niveau du fournisseur de VPN qui lui aura
un compte avec des info associées à la connexion. Et si le fournisseur te
renvois la balle, et bien le simple log des CONNECT pourra te permettre de
lier la connexion à la personne.

Et détecter le connections longues, c'est bien, mais comment tu fait la
diff entre un websocket SSL, un longpooling ajax HTTPS et un VPN? Et pour
information j'ai déjà contourné ce genre de restriction a la noix quand
j'était étudiant avec un VPN OpenVPN tcp 443, des gros buffer, des gros
timeout et un reconnect agressif, le tout sur une box OVH perso à 5€.

My 20 cents

Le 8 mars 2016 à 10:44, Jocelyn Lagarenne  a
écrit :

> Bonjour à tous,
>
> je me retrouve face à un dilemme. On me demande de proposer une solution
> pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le
> traffic au travers d'un proxy est identique à un traffic https. il est donc
> impossible de le detecter non ? ou est ce que je fais fausse route ?
> Il est techniquement envisageable de casser le https sur les proxys mais ce
> n'est pas une recommandation que j'aime.
> la seul solution que je vois est de détecter les connexions SSL "longue" et
> de vérifier ce qu'elles sont (eliminer les faux positives comme par exemple
> gtalk), mais je ne suis meme pas sure que des logs proxy puissent me donner
> cette information.
>
> Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans
> vos entreprises ?
>
> d'avance merci de vos retours
>
> Cordialement,
> --
> Jocelyn Lagarenne
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Nathan Delhaye
06 69 27 64 25
0805 696 494

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

Re: [FRnOG] [TECH] detection VPN SSL

[Bruno LEAL DE SOUSA]

Hello,

Le proxy est interne ou externe ?
Ils doivent obligatoirement passer par le proxy ?

J'ai connu un cas où le proxy était externe et pour protéger des VPN, la
règle était :

   - On bloque tous les connexions chiffrées https, ssl-smpt, pptp, etc...
   - On autorise la sortie https uniquement vers le proxy

Ainsi toutes les connexions vpn étaint bloquées.

A+

Le 8 mars 2016 à 11:19, Jérôme MARTINIERE 
a écrit :

> Bonjour,
>
> Quel est le but final du filtrage ?
>
> Sans casser le chiffrage par un proxy, il est possible de filtrer par FQDN
> ou classes d’IP, notamment pour exclure les tunnels vers des IP de FAI «
> grand public » par exemple ou vers les fournisseurs de proxy web.
>
> Cordialement,
>
> Jérôme MARTINIERE
>
> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part
> de Jocelyn Lagarenne
> Envoyé : mardi 8 mars 2016 10:45
> À : frnog-t...@frnog.org
> Objet : [FRnOG] [TECH] detection VPN SSL
>
> Bonjour à tous,
>
> je me retrouve face à un dilemme. On me demande de proposer une solution
> pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le
> traffic au travers d'un proxy est identique à un traffic https. il est donc
> impossible de le detecter non ? ou est ce que je fais fausse route ?
> Il est techniquement envisageable de casser le https sur les proxys mais
> ce n'est pas une recommandation que j'aime.
> la seul solution que je vois est de détecter les connexions SSL "longue"
> et de vérifier ce qu'elles sont (eliminer les faux positives comme par
> exemple gtalk), mais je ne suis meme pas sure que des logs proxy puissent
> me donner cette information.
>
> Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans
> vos entreprises ?
>
> d'avance merci de vos retours
>
> Cordialement,
> --
> Jocelyn Lagarenne
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Bruno LEAL DE SOUSA
IT System and Network Administrator
Co-founder and editor of *Bidouille-IT* : http://bidouilleit.com

« Failure is the foundation of success, and the means by which it is
achieved. » - *Lao Tzu*

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

RE: [FRnOG] [TECH] detection VPN SSL

[Jérôme MARTINIERE]

Bonjour,

Quel est le but final du filtrage ?

Sans casser le chiffrage par un proxy, il est possible de filtrer par FQDN ou 
classes d’IP, notamment pour exclure les tunnels vers des IP de FAI « grand 
public » par exemple ou vers les fournisseurs de proxy web.

Cordialement,

Jérôme MARTINIERE

De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Jocelyn Lagarenne
Envoyé : mardi 8 mars 2016 10:45
À : frnog-t...@frnog.org
Objet : [FRnOG] [TECH] detection VPN SSL

Bonjour à tous,

je me retrouve face à un dilemme. On me demande de proposer une solution pour 
détecter/bloquer les VPN SSL non autorisés mais autant que je sache le traffic 
au travers d'un proxy est identique à un traffic https. il est donc impossible 
de le detecter non ? ou est ce que je fais fausse route ?
Il est techniquement envisageable de casser le https sur les proxys mais ce 
n'est pas une recommandation que j'aime.
la seul solution que je vois est de détecter les connexions SSL "longue" et de 
vérifier ce qu'elles sont (eliminer les faux positives comme par exemple 
gtalk), mais je ne suis meme pas sure que des logs proxy puissent me donner 
cette information.

Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans vos 
entreprises ?

d'avance merci de vos retours

Cordialement,
--
Jocelyn Lagarenne

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

Re: [FRnOG] [TECH] detection VPN SSL

[Denis VINCIGUERRA]

Bonjour,

On peut quand même voir le FQDN contacté dans la requête CONNECT envoyée au
proxy, tu peux te baser la dessus.

Une solution courante consiste à utiliser du filtrage d'URL par catégories:
* tu bloques bien sur la catégorie contenant les VPNs ou proxys distants,
pour les services de VPN connus.
* ensuite il faut bloquer tout ce qui n'est pas catégorisé, ce qui permet
de ne pas autoriser le vpn ssl "maison" qu'un de tes utilisateurs aurait
monté sur son serveur dédié ou à la maison.

Par contre, du coup, ça oblige à gérer les autorisations de sites non
catégorisés. C'est consommateur en temps et cela peut être gênant pour les
utilisateurs.

L'analyse des logs est plus compliquée à faire et il va être difficile de
dissocier un gros téléchargement qui a pris du temps et un tunnel à partir
de la durée de connexion ou du nombre d'octets transférés.


Le 8 mars 2016 à 10:44, Jocelyn Lagarenne  a
écrit :

> Bonjour à tous,
>
> je me retrouve face à un dilemme. On me demande de proposer une solution
> pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le
> traffic au travers d'un proxy est identique à un traffic https. il est donc
> impossible de le detecter non ? ou est ce que je fais fausse route ?
> Il est techniquement envisageable de casser le https sur les proxys mais ce
> n'est pas une recommandation que j'aime.
> la seul solution que je vois est de détecter les connexions SSL "longue" et
> de vérifier ce qu'elles sont (eliminer les faux positives comme par exemple
> gtalk), mais je ne suis meme pas sure que des logs proxy puissent me donner
> cette information.
>
> Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans
> vos entreprises ?
>
> d'avance merci de vos retours
>
> Cordialement,
> --
> Jocelyn Lagarenne
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [MISC] Enquête de toile de fond technologique édition 2016

[Mohsen Souissi]

Bonjour,

Vous avez peut-être eu l’occasion de répondre à l’une des éditions précédentes 
de cette enquête 
(https://www.afnic.fr/fr/expertises/le-conseil-scientifique/realisations/enquete-de-toile-de-fond-technologique.html
 

 ).

Cette enquête faite sur la base de prédictions, met encore plus l’accent dans 
cette édition [1] sur les évolutions prévisibles des infrastructures de 
l’Internet (notamment, routage et DNS).

En vous remerciant par avance de votre temps et de votre contribution (au plus 
tard le 31 mars 2016 SVP), voici un pointeur sur l’enquête :


https://survey.init-web.com/cgi-bin/clusterHE/SF?P=5z30z7z-1z-1z2CCC3F2A9A 
 

Bien cordialement,

Mohsen.

[1] Cf. brève : 
https://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/9711/show/lancement-de-la-4e-edition-de-l-enquete-toile-de-fond-technologique-afnic.html
 

 


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

[FRnOG] [TECH] detection VPN SSL

[Jocelyn Lagarenne]

Bonjour à tous,

je me retrouve face à un dilemme. On me demande de proposer une solution
pour détecter/bloquer les VPN SSL non autorisés mais autant que je sache le
traffic au travers d'un proxy est identique à un traffic https. il est donc
impossible de le detecter non ? ou est ce que je fais fausse route ?
Il est techniquement envisageable de casser le https sur les proxys mais ce
n'est pas une recommandation que j'aime.
la seul solution que je vois est de détecter les connexions SSL "longue" et
de vérifier ce qu'elles sont (eliminer les faux positives comme par exemple
gtalk), mais je ne suis meme pas sure que des logs proxy puissent me donner
cette information.

Auriez vous des idées/suggestions ? avez vous déjà eu ce genre de cas dans
vos entreprises ?

d'avance merci de vos retours

Cordialement,
-- 
Jocelyn Lagarenne

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

Re: [TECH] [FRnOG] Cryptolog et clients mails

[David Ponzone]

Euh, c’est plutôt le client léger qui est le moins vulnérable, à priori.


> Le 8 mars 2016 à 09:54, Carroussel Informatique  a 
> écrit :
> 
> Bonjour,
> 
> Partant du principe que cette saleté se propage -pour le moment- par email, 
> pensez vous que les utilisateurs de clients léger (de type webmail) soient 
> plus vulnérables que ceux utilisant des clients lourds ? (Thunderbird par ex).
> 
> A titre personnel, j'ai modifié le réglage de certains de mes comptes pour 
> que TB ne relève que les en-têtes des mails. Libre à moi de poursuivre le 
> chargement unique ment pour les courriers vraiment intéressant.
> 
> La première conséquence de tout cela, est que suivre une discussion sur FrnOG 
> devient un peu plus contraignant :)
> Et j'imagine que pour un Dupuy-Morizeau, ça doit devenir un cauchemar !
> 
> Pensez vous que cette solution du client lourd pourrait s’avérer être un 
> "filtre" un peu efficace contre ce genre de menaces ?
> J'ai quelques doutes sur la capacité de mes clients à utiliser leur tête 
> avant de cliquer... Je sais que je vais faire un bide auprès de mes 
> trafiquant de .pps
> 
> Merci.
> ES
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [TECH] [FRnOG] Cryptolog et clients mails

[FanThomaS]

Trolling topic detected.

Le 2016-03-08 09:54, Carroussel Informatique a écrit :

Bonjour,

Partant du principe que cette saleté se propage -pour le moment- par
email, pensez vous que les utilisateurs de clients léger (de type
webmail) soient plus vulnérables que ceux utilisant des clients lourds
? (Thunderbird par ex).

A titre personnel, j'ai modifié le réglage de certains de mes comptes
pour que TB ne relève que les en-têtes des mails. Libre à moi de
poursuivre le chargement unique ment pour les courriers vraiment
intéressant.

La première conséquence de tout cela, est que suivre une discussion
sur FrnOG devient un peu plus contraignant :)
Et j'imagine que pour un Dupuy-Morizeau, ça doit devenir un cauchemar !

Pensez vous que cette solution du client lourd pourrait s’avérer être
un "filtre" un peu efficace contre ce genre de menaces ?
J'ai quelques doutes sur la capacité de mes clients à utiliser leur
tête avant de cliquer... Je sais que je vais faire un bide auprès de
mes trafiquant de .pps

Merci.
ES


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



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

[TECH] [FRnOG] Cryptolog et clients mails

[Carroussel Informatique]

Bonjour,

Partant du principe que cette saleté se propage -pour le moment- par 
email, pensez vous que les utilisateurs de clients léger (de type 
webmail) soient plus vulnérables que ceux utilisant des clients lourds ? 
(Thunderbird par ex).


A titre personnel, j'ai modifié le réglage de certains de mes comptes 
pour que TB ne relève que les en-têtes des mails. Libre à moi de 
poursuivre le chargement unique ment pour les courriers vraiment 
intéressant.


La première conséquence de tout cela, est que suivre une discussion sur 
FrnOG devient un peu plus contraignant :)

Et j'imagine que pour un Dupuy-Morizeau, ça doit devenir un cauchemar !

Pensez vous que cette solution du client lourd pourrait s’avérer être un 
"filtre" un peu efficace contre ce genre de menaces ?
J'ai quelques doutes sur la capacité de mes clients à utiliser leur tête 
avant de cliquer... Je sais que je vais faire un bide auprès de mes 
trafiquant de .pps


Merci.
ES


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

Re: [FRnOG] [TECH] Logiciel d'analyse de chargement de page web

[Pierre-Yves Dubreucq]

Bonjour,
Il y a sitespeed.io aussi qui permet d'analyser un site, d'en récolter 
les métriques de performances, les scores sur des régles types YSlow, 
Pagespeed, il peut aussi utiliser webpagetest en support et enfin, il 
peut pousser toutes ces données dans Graphite.
Si ton site est en php, tu peux aussi utiliser Blackfire.io qui fournit 
une version gratuite et une avec licence et là tu auras du profiling 
complet.

Autre possibilité, Newrelic qui est un profiler en Saas
Normalement, tu devrais pouvoir trouver ton bonheur ;)
Bonne journée
Pierre-Yves

Le 07/03/2016 20:35, GIRARDI, Nicolas a écrit :

Neoload de Neotys. (Payant)
Avec les agents côté serveur pour corréler les metrics avec la charge.


Le 7 mars 2016 à 20:33, Raphael Jacquot  a écrit :



Le 07/03/16 19:40, Michel Py a écrit :

Bonjour à tous,

Est-ce que quelqu'un pourrait recommander un logiciel d'analyse de chargement 
d'une page web ?

tu as l'onglet "network" dans le debugger intégré de firefox qui fait ca


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


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


--



*Pierre-Yves* *Dubreucq*
*Directeur Technique*

*Fixe :* 03 20 68 06 84
*Port :* 06 50 30 26 04
*Fax :* 03 20 68 90 81

45 Bvd du Général Leclerc 59100 Roubaix
12 rue Marivaux 75002 Paris

  
 
 



MonSiteEstLent.com  - Blog dédié à la 
webperformance et la gestion de pics de trafic



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

[FRnOG] [MISC] wikipedia

[Philippe Bourcier]

Bonjour,

Si des personnes avec un peu de talent d'écriture veulent bien 
s’atteler à la tâche, il semblerait que l'article wikipedia sur FRnOG 
soit sur le point de disparaître (bon, il n'est pas super bien écrit), 
ce qui serait bien dommage, je trouve :

https://fr.wikipedia.org/wiki/FRnOG

Je pense qu'il manque des références au France-IX et à la participation 
à la poussée des IX en France (via les IX updates lors des réunions)... 
mais bon j'estime que je ne suis pas le mieux placé pour écrire 
l'article (et surtout je suis pas un écrivain né, autant utiliser les 
talents de gens meilleurs que moi :)).


Bonne prose :)


Cordialement,
--
Philippe Bourcier
web : http://sysctl.org/
blog : https://www.linkedin.com/today/author/2298865


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

[FRnOG] [MISC] FRNOG 26.0 - ALPHA

[Philippe Bourcier]

Bonjour,

La prochaine réunion FRNOG aura lieu le 15 Avril prochain.

Je mettrais en ligne la page d'inscription ce weekend.

Si vous avez des suggestions de sujet, merci de me contacter HORS 
LISTE.




Cordialement,
--
Philippe Bourcier
web : http://sysctl.org/
blog : https://www.linkedin.com/today/author/2298865


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