Re: [FRnOG] [ALERT] Nouvelle faille openssl
Bonsoir, 2014-04-10T01:20:11+02:00, Simon Morvan wrote: > Le 09/04/2014 23:40, jehan procaccia INT a écrit : > > serait-il capable de trouver une vulnérabilité dans openssh > un ldd de /usr/bin/ssh et /usr/sbin/sshd sur une debian wheezy ne liste > pas libssl. > > je ne sais pas si openssl se cache sous un autre nom dans ce cas mais il > semble qu'on soit tranquille pour le coup non ? Effectivement, concernant OpenSSH, nous pouvons être relativement tranquille, pas parce que OpenSSH n'utilise pas OpenSSL, mais parce qu'OpenSSH n'utilise mais pas TLS pour le transport (au niveau de la couche Application du modèle TCP/IP) ; ce qu'OpenSSH utilise d'OpenSSL concerne les algorithmes de chiffrement. Donc, pas de HeartBeat en vue pour SSH ; par contre, nginx, postfix, et des logiciels XMPP peuvent être concernés. Voilà pour mes 2 centimes. Salutations, -- Thibaud CANALE thican [at] thican [dot] net http://thican.net/ GPG: 4096R/50733A18 signature.asc Description: Digital signature
Re: [FRnOG] Re: [ALERT] Nouvelle faille openssl
Des fois, une librairie est statique ... mgc@infra:~$ strings /usr/sbin/sshd | grep -i ssl SSLeay OPENSSL_config OPENSSL_add_all_algorithms_noconf SSLeay_version OPENSSL_1.0.0 OpenSSL version mismatch. Built against %lx, you have %lx $ uname -a Linux infra 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux On Wed, Apr 9, 2014 at 6:20 PM, Simon Morvan wrote: > Le 09/04/2014 23:40, jehan procaccia INT a écrit : > > serait-il capable de trouver une vulnérabilité dans openssh > un ldd de /usr/bin/ssh et /usr/sbin/sshd sur une debian wheezy ne liste > pas libssl. > > je ne sais pas si openssl se cache sous un autre nom dans ce cas mais il > semble qu'on soit tranquille pour le coup non ? > > # ldd /usr/sbin/sshd > linux-gate.so.1 => (0xb7753000) > libwrap.so.0 => /lib/i386-linux-gnu/libwrap.so.0 (0xb76b2000) > libpam.so.0 => /lib/i386-linux-gnu/libpam.so.0 (0xb76a3000) > libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb7682000) > libcrypto.so.1.0.0 => > /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 (0xb74c3000) > libutil.so.1 => /lib/i386-linux-gnu/i686/cmov/libutil.so.1 > (0xb74bf000) > libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb74a6000) > libcrypt.so.1 => /lib/i386-linux-gnu/i686/cmov/libcrypt.so.1 > (0xb7474000) > libgssapi_krb5.so.2 => > /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2 (0xb7435000) > libkrb5.so.3 => /usr/lib/i386-linux-gnu/libkrb5.so.3 (0xb7363000) > libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xb735e000) > libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb71fa000) > libnsl.so.1 => /lib/i386-linux-gnu/i686/cmov/libnsl.so.1 > (0xb71e3000) > libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb71de000) > /lib/ld-linux.so.2 (0xb7754000) > libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3 > (0xb71b4000) > libkrb5support.so.0 => > /usr/lib/i386-linux-gnu/libkrb5support.so.0 (0xb71ab000) > libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 > (0xb71a6000) > libresolv.so.2 => /lib/i386-linux-gnu/i686/cmov/libresolv.so.2 > (0xb7192000) > libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 > (0xb7178000) > > > # ldd /usr/bin/ssh > linux-gate.so.1 => (0xb7743000) > libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb76a4000) > libresolv.so.2 => /lib/i386-linux-gnu/i686/cmov/libresolv.so.2 > (0xb769) > libcrypto.so.1.0.0 => > /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 (0xb74d) > libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb74cc000) > libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb74b3000) > libgssapi_krb5.so.2 => > /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2 (0xb7475000) > libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7311000) > /lib/ld-linux.so.2 (0xb7744000) > libkrb5.so.3 => /usr/lib/i386-linux-gnu/libkrb5.so.3 (0xb723e000) > libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3 > (0xb7214000) > libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xb720f000) > libkrb5support.so.0 => > /usr/lib/i386-linux-gnu/libkrb5support.so.0 (0xb7206000) > libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 > (0xb7201000) > libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 > (0xb71e7000) > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Gaël Martinez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] Nouvelle faille openssl
Le 09/04/2014 23:40, jehan procaccia INT a écrit : > serait-il capable de trouver une vulnérabilité dans openssh un ldd de /usr/bin/ssh et /usr/sbin/sshd sur une debian wheezy ne liste pas libssl. je ne sais pas si openssl se cache sous un autre nom dans ce cas mais il semble qu'on soit tranquille pour le coup non ? # ldd /usr/sbin/sshd linux-gate.so.1 => (0xb7753000) libwrap.so.0 => /lib/i386-linux-gnu/libwrap.so.0 (0xb76b2000) libpam.so.0 => /lib/i386-linux-gnu/libpam.so.0 (0xb76a3000) libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb7682000) libcrypto.so.1.0.0 => /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 (0xb74c3000) libutil.so.1 => /lib/i386-linux-gnu/i686/cmov/libutil.so.1 (0xb74bf000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb74a6000) libcrypt.so.1 => /lib/i386-linux-gnu/i686/cmov/libcrypt.so.1 (0xb7474000) libgssapi_krb5.so.2 => /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2 (0xb7435000) libkrb5.so.3 => /usr/lib/i386-linux-gnu/libkrb5.so.3 (0xb7363000) libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xb735e000) libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb71fa000) libnsl.so.1 => /lib/i386-linux-gnu/i686/cmov/libnsl.so.1 (0xb71e3000) libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb71de000) /lib/ld-linux.so.2 (0xb7754000) libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3 (0xb71b4000) libkrb5support.so.0 => /usr/lib/i386-linux-gnu/libkrb5support.so.0 (0xb71ab000) libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 (0xb71a6000) libresolv.so.2 => /lib/i386-linux-gnu/i686/cmov/libresolv.so.2 (0xb7192000) libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb7178000) # ldd /usr/bin/ssh linux-gate.so.1 => (0xb7743000) libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb76a4000) libresolv.so.2 => /lib/i386-linux-gnu/i686/cmov/libresolv.so.2 (0xb769) libcrypto.so.1.0.0 => /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 (0xb74d) libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb74cc000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb74b3000) libgssapi_krb5.so.2 => /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2 (0xb7475000) libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7311000) /lib/ld-linux.so.2 (0xb7744000) libkrb5.so.3 => /usr/lib/i386-linux-gnu/libkrb5.so.3 (0xb723e000) libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3 (0xb7214000) libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xb720f000) libkrb5support.so.0 => /usr/lib/i386-linux-gnu/libkrb5support.so.0 (0xb7206000) libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 (0xb7201000) libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb71e7000) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] Nouvelle faille openssl
Bonsoir, le script nmap fonctionne tres bien et est tres efficace pour scanner en masse , merci , maintenant je m'interroge sur sa capacité a tester d'autres services ssl/tls que https/443 ? serait-il capable de trouver une vulnérabilité dans openssh (22) imaps (993), smtps (465) , ldaps (636) ? des scan 443 ont révélés la faille sur des serveurs non encore updatés, mais sur les ports 22,993,465 et 636 je n'ai encore rien trouvé sur de tels serveurs. soit le script n'est pas adapté, soit ces autres services utilisent une autre librairie ? Jehan . Le 09/04/2014 17:02, Nicolas GOLLET a écrit : Bonjour à tous, pour scanner rapidement si vous avez des équipements/serveurs vulnérable il existe un script nmap pour ça sur leur svn :) https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse exemple : nmap -p 443 --script ssl-heartbleed.nse 192.168.1.0/24 Un service en ligne a aussi ouvert : http://filippo.io/Heartbleed/ (source dispo en python sur github) Nicolas 2014-04-09 16:52 GMT+02:00 Stephane Bortzmeyer : On Tue, Apr 08, 2014 at 09:56:41PM +0200, Stephane Bortzmeyer wrote a message of 13 lines which said: Et n'oubliez pas que vos routeurs Juniper ont OpenSSL... Pour Cisco : http://blogs.cisco.com/security/openssl-heartbleed-vulnerability-cve-2014-0160-cisco-products-and-mitigations/ --- 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] calcul du temps d'émission adsl vs fibre
C'est vrai... ça en provoque bien plus quand le tripatouillage des paquets ne se fait pas correctement et que les machines du lan continuent à envoyer des paquets de 1500 qui se font fragmenter... :) Le 09/04/2014 22:27, David Ponzone a écrit : > Certes, mais je pense pas que l'encapsulation PPPoE provoque une perte de 20% > de bande passante. > > Le 9 avr. 2014 à 22:21, Simon Morvan a écrit : > >> Bah, meme en Fibre Livebox (dite) Pro, il y a une couche de pppoe qui >> truande la mtu. >> On a pas mal de saloperies historiques encore sur le dos. >> >> Le 09/04/2014 21:54, David Ponzone a écrit : >>> Oui c'est vrai, j'ai du mal à penser CE2O quand on me parle de fibre. >>> En plus, l'offre n'est plus commercialisé je crois, sauf cas particuliers. >>> >>> Le 9 avr. 2014 à 20:16, said.sa...@gmail.com a écrit : >>> Bonjour, Il me semble aussi que sur la fibre Orange CE2O il y a bien une couche ATM . Cdlt, SAS Ce message a été envoyé depuis un terminal BlackBerry de Bouygues Telecom -Original Message- From: Antoine Durant Sender: frnog-requ...@frnog.org Date: Wed, 9 Apr 2014 18:59:19 To: frnog-t...@frnog.org Reply-To: Antoine Durant Subject: [FRnOG] [TECH] calcul du temps d'émission adsl vs fibre Bonjour, Pour calculer le temps d'émission d'un fichier sur une ligne ADSL par exemple je me sers de la formule suivante : délai = poids fichier / bande passante du lien Etant donné que les connexions ADSL sont annoncées avec leur débit ATM, il faut donc sortir 20% sur le débit ATM pour se rapprocher du débit réel IP... Débit adsl descendant ATM : 28 Mbit/s => 22,4 Mbit/s IP Débit adsl montant ATM : 1 Mbit/s ATM => 800 kbit/s IP Pour l'ADSL2+ et VDSL2 j'applique aussi le 20% est-ce que je suis dans le vrai ?? Maintenant est-ce que cela est la même chose sur une connexion fibre optique ? Quel facteur est à appliquer afin d'avoir un calcul de débit réel ? Merci ! --- 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/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] calcul du temps d'émission adsl vs fibre
Bah, meme en Fibre Livebox (dite) Pro, il y a une couche de pppoe qui truande la mtu. On a pas mal de saloperies historiques encore sur le dos. Le 09/04/2014 21:54, David Ponzone a écrit : > Oui c'est vrai, j'ai du mal à penser CE2O quand on me parle de fibre. > En plus, l'offre n'est plus commercialisé je crois, sauf cas particuliers. > > Le 9 avr. 2014 à 20:16, said.sa...@gmail.com a écrit : > >> Bonjour, >> >> Il me semble aussi que sur la fibre Orange CE2O il y a bien une couche ATM . >> >> Cdlt, >> >> SAS >> Ce message a été envoyé depuis un terminal BlackBerry de Bouygues Telecom >> >> -Original Message- >> From: Antoine Durant >> Sender: frnog-requ...@frnog.org >> Date: Wed, 9 Apr 2014 18:59:19 >> To: frnog-t...@frnog.org >> Reply-To: Antoine Durant >> Subject: [FRnOG] [TECH] calcul du temps d'émission adsl vs fibre >> >> Bonjour, >> >> Pour calculer le temps d'émission d'un fichier sur une ligne ADSL par >> exemple je me sers de la formule suivante : >> >> délai = poids fichier / bande passante du lien >> >> Etant donné que les connexions ADSL sont annoncées avec leur débit ATM, il >> faut donc sortir 20% sur le débit ATM pour se rapprocher du débit réel IP... >> >> Débit adsl descendant ATM : 28 Mbit/s => 22,4 Mbit/s IP >> Débit adsl montant ATM : 1 Mbit/s ATM => 800 kbit/s IP >> >> Pour l'ADSL2+ et VDSL2 j'applique aussi le 20% est-ce que je suis dans le >> vrai ?? >> >> Maintenant est-ce que cela est la même chose sur une connexion fibre optique >> ? >> >> Quel facteur est à appliquer afin d'avoir un calcul de débit réel ? >> >> Merci ! >> --- >> 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] [JOBS] [LEXSI] Recrutement admin sénior
Salut, C'est quand même moche de poster 2 fois la même offre d'emploi pour un job d'admin systèmes, 1 - Sur la liste frnog avec un lien qui pointe vers une offre qui n'existe pas et un put*** de mot de Franglish dans l'objet. 2 - Sur frsag avec une faute en plus (mais la dites offre cette fois-ci, bravo :). Merde, Quand MEME ! Le 2014-04-09 17:14, Fried Wil a écrit : > Hello la liste :) > > LEXSI recrute un admin système Linux en IDF. > > Plus d'infos sur la fiche de poste : > http://www.lexsi.fr/carrieres/offres-emplois/0914-admin-idf [1] > > Me contacter si intéressé Links: -- [1] http://www.lexsi.fr/carrieres/offres-emplois/0914-admin-idf --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] calcul du temps d'émission adsl vs fibre
Oui c'est vrai, j'ai du mal à penser CE2O quand on me parle de fibre. En plus, l'offre n'est plus commercialisé je crois, sauf cas particuliers. Le 9 avr. 2014 à 20:16, said.sa...@gmail.com a écrit : > Bonjour, > > Il me semble aussi que sur la fibre Orange CE2O il y a bien une couche ATM . > > Cdlt, > > SAS > Ce message a été envoyé depuis un terminal BlackBerry de Bouygues Telecom > > -Original Message- > From: Antoine Durant > Sender: frnog-requ...@frnog.org > Date: Wed, 9 Apr 2014 18:59:19 > To: frnog-t...@frnog.org > Reply-To: Antoine Durant > Subject: [FRnOG] [TECH] calcul du temps d'émission adsl vs fibre > > Bonjour, > > Pour calculer le temps d'émission d'un fichier sur une ligne ADSL par exemple > je me sers de la formule suivante : > > délai = poids fichier / bande passante du lien > > Etant donné que les connexions ADSL sont annoncées avec leur débit ATM, il > faut donc sortir 20% sur le débit ATM pour se rapprocher du débit réel IP... > > Débit adsl descendant ATM : 28 Mbit/s => 22,4 Mbit/s IP > Débit adsl montant ATM : 1 Mbit/s ATM => 800 kbit/s IP > > Pour l'ADSL2+ et VDSL2 j'applique aussi le 20% est-ce que je suis dans le > vrai ?? > > Maintenant est-ce que cela est la même chose sur une connexion fibre optique ? > > Quel facteur est à appliquer afin d'avoir un calcul de débit réel ? > > Merci ! > --- > 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] calcul du temps d'émission adsl vs fibre
Bonjour, Il me semble aussi que sur la fibre Orange CE2O il y a bien une couche ATM . Cdlt, SAS Ce message a été envoyé depuis un terminal BlackBerry de Bouygues Telecom -Original Message- From: Antoine Durant Sender: frnog-requ...@frnog.org Date: Wed, 9 Apr 2014 18:59:19 To: frnog-t...@frnog.org Reply-To: Antoine Durant Subject: [FRnOG] [TECH] calcul du temps d'émission adsl vs fibre Bonjour, Pour calculer le temps d'émission d'un fichier sur une ligne ADSL par exemple je me sers de la formule suivante : délai = poids fichier / bande passante du lien Etant donné que les connexions ADSL sont annoncées avec leur débit ATM, il faut donc sortir 20% sur le débit ATM pour se rapprocher du débit réel IP... Débit adsl descendant ATM : 28 Mbit/s => 22,4 Mbit/s IP Débit adsl montant ATM : 1 Mbit/s ATM => 800 kbit/s IP Pour l'ADSL2+ et VDSL2 j'applique aussi le 20% est-ce que je suis dans le vrai ?? Maintenant est-ce que cela est la même chose sur une connexion fibre optique ? Quel facteur est à appliquer afin d'avoir un calcul de débit réel ? Merci ! --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] calcul du temps d'émission adsl vs fibre
Pour l'ADSL/VDSL, ça dépend si le fournisseur a une couche ATM. C'est le cas pour Orange et SFR en ADSL, c'est pas le cas pour les VDSL OVH. En fibre optique en tout cas, il n'y a pas d'ATM bien entendu donc le débit est presque 100% utile. Le 9 avr. 2014 à 19:59, Antoine Durant a écrit : > Bonjour, > > Pour calculer le temps d'émission d'un fichier sur une ligne ADSL par exemple > je me sers de la formule suivante : > > délai = poids fichier / bande passante du lien > > Etant donné que les connexions ADSL sont annoncées avec leur débit ATM, il > faut donc sortir 20% sur le débit ATM pour se rapprocher du débit réel IP... > > Débit adsl descendant ATM : 28 Mbit/s => 22,4 Mbit/s IP > Débit adsl montant ATM : 1 Mbit/s ATM => 800 kbit/s IP > > Pour l'ADSL2+ et VDSL2 j'applique aussi le 20% est-ce que je suis dans le > vrai ?? > > Maintenant est-ce que cela est la même chose sur une connexion fibre optique ? > > Quel facteur est à appliquer afin d'avoir un calcul de débit réel ? > > Merci ! > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] calcul du temps d'émission adsl vs fibre
Bonjour, Pour calculer le temps d'émission d'un fichier sur une ligne ADSL par exemple je me sers de la formule suivante : délai = poids fichier / bande passante du lien Etant donné que les connexions ADSL sont annoncées avec leur débit ATM, il faut donc sortir 20% sur le débit ATM pour se rapprocher du débit réel IP... Débit adsl descendant ATM : 28 Mbit/s => 22,4 Mbit/s IP Débit adsl montant ATM : 1 Mbit/s ATM => 800 kbit/s IP Pour l'ADSL2+ et VDSL2 j'applique aussi le 20% est-ce que je suis dans le vrai ?? Maintenant est-ce que cela est la même chose sur une connexion fibre optique ? Quel facteur est à appliquer afin d'avoir un calcul de débit réel ? Merci ! --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] [LEXSI] Recrutement admin sénior
Hello la liste :) LEXSI recrute un admin système Linux en IDF. Plus d'infos sur la fiche de poste : http://www.lexsi.fr/carrieres/offres-emplois/0914-admin-idf Me contacter si intéressé -- Wilfried Pascault wilfried.pasca...@gmail.com --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] Nouvelle faille openssl
Bonjour à tous, pour scanner rapidement si vous avez des équipements/serveurs vulnérable il existe un script nmap pour ça sur leur svn :) https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse exemple : nmap -p 443 --script ssl-heartbleed.nse 192.168.1.0/24 Un service en ligne a aussi ouvert : http://filippo.io/Heartbleed/ (source dispo en python sur github) Nicolas 2014-04-09 16:52 GMT+02:00 Stephane Bortzmeyer : > On Tue, Apr 08, 2014 at 09:56:41PM +0200, > Stephane Bortzmeyer wrote > a message of 13 lines which said: > > > Et n'oubliez pas que vos routeurs Juniper ont OpenSSL... > > Pour Cisco : > > > http://blogs.cisco.com/security/openssl-heartbleed-vulnerability-cve-2014-0160-cisco-products-and-mitigations/ > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [ALERT] Nouvelle faille openssl
On Tue, Apr 08, 2014 at 09:56:41PM +0200, Stephane Bortzmeyer wrote a message of 13 lines which said: > Et n'oubliez pas que vos routeurs Juniper ont OpenSSL... Pour Cisco : http://blogs.cisco.com/security/openssl-heartbleed-vulnerability-cve-2014-0160-cisco-products-and-mitigations/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [ALERT] Nouvelle faille openssl
On Wed, Apr 09, 2014 at 03:33:43PM +0100, Fabien Bourdaire wrote a message of 42 lines which said: > iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 Faut juste se rappeler que Heartbleed n'affecte pas que HTTPS. Et je suis sceptique sur ces règles u32. TLS hérite d'ASN1 la possibilité d'avoir plusieurs encodages pour la même info. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] Nouvelle faille openssl
Le traffic peut etre blocker grace a iptables & u32 en upstream: # Log rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=0x1803:0x1803" -j LOG --log-prefix "BLOCKED: HEARTBEAT" # Block rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=0x1803:0x1803" -j DROP # Wireshark rules $ tshark -i interface port 443 -R 'frame[68:1] == 18' $ tshark -i interface port 443 -R 'ssl.record.content_type == 24' http://www.securityfocus.com/archive/1/531779/30/0/threaded 2014-04-09 15:04 GMT+01:00 Stephane Bortzmeyer : > On Wed, Apr 09, 2014 at 09:47:30AM +0200, > Sylvain Busson wrote > a message of 25 lines which said: > > > Et n'oublié pas les Secure Acces game SA en CO... largement deployés... > > Sur une autre liste, quelqu'un témoignait avoir réussi à dumper l'info > (par exemple les ACL) d'un pare-feu Fortigate. Donc, il n'y a pas que > les serveurs Linux avec Apache qu'il faut surveiller. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [ALERT] Nouvelle faille openssl
On Wed, Apr 09, 2014 at 09:47:30AM +0200, Sylvain Busson wrote a message of 25 lines which said: > Et n'oublié pas les Secure Acces game SA en CO... largement deployés... Sur une autre liste, quelqu'un témoignait avoir réussi à dumper l'info (par exemple les ACL) d'un pare-feu Fortigate. Donc, il n'y a pas que les serveurs Linux avec Apache qu'il faut surveiller. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] [Clim] Ce qui s'est vraiment passé à TH2
"Les aurores générèrent ensuite des courants électriques dans le sol qui affectèrent les circuits électriques existants, notamment les réseaux de télégraphie électrique. De nombreux cas de télégraphistes victimes de violentes décharges électriques furent rapportés, ainsi que plusieurs incendies de station de télégraphie causés par les courants très intenses qui furent induits dans le sol." Le problème, c'est surtout qu'on considérait le neutre comme la terre à l'époque, ça depuis longtemps plus le cas et on a des différentielles 300mAobligatoire, voir 30mA pour les prises et la protection humaine. -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de technicien hahd Envoyé : mercredi 9 avril 2014 14:20 À : frnog@frnog.org Objet : Re: [FRnOG] [TECH] [Clim] Ce qui s'est vraiment passé à TH2 On Tuesday 08 April 2014 15:18:37 Pierre Col - p...@9online.fr wrote: > > > On Tue, Apr 8, 2014, at 11:40, David Ponzone wrote: > > >> Sans parler des points d'arrivée des fibres sous-marines, si on > > >> voulait juste isoler la France du reste du monde. > > > > > > La France n'etant pas une ile, il faut couper du cable pendant > > > bien longtemps avant de l'isoler le pays. Et pas que du sous-marin. > > > En effet, si tous les cables sous-marins arrivant en France etait > > > coupes, l'impact serait plus grand pour d'autres (Asie, Moyen > > > Orient), et la France sera minimalement impacte (tout comme la Grande-Bretagne). > > > Il y a BEAUCOUP de capacite terrestre qui relie la France au monde > > > exterieur. > > > > Je suis d'accord, il ne faut pas exagérer le fantasme sur le chaos > > Internet en France lié à TH2 ou aux liens sur Paris. Sinon c'est que > > beaucoup de gens font mal leur métier. Quand je prends un lien vers > > d'autres pays, je fais comme tout opérateur "normal" dans le monde > > d'Internet : Je prends 2 chemins distincts, je m'assure que les > > chemins de fibre ne passent pas par le même PoP (TH2, SFR, Gardinoux > > ou autre points connus). Ca passe en général par Londres, par > > Francfort, par Bruxelles pour le Nord de l'Europe typiquement. > > > > Pour la fibre noire dans Paris c'est pareil, beaucoup de sites ont > > plusieurs arrivées distinctes qui permettent de faire en sorte que > > les fibres ne se croisent jamais. A moins d'une erreur humaine et > > d'un manque de sérieux dans l'étude du projet, il est facile en > > France de s'assurer des chemins diversifiés en redondance. D'autant > > que les gens dont c'est le métier de passer de la fibre ont déjà > > prévu ça (et que les fournisseurs donne même régulièrement le kmz > > qui va bien). > > > > En se renseignant un peu aussi, on évite de prendre un opérateur de > > transit IP qui remonte sur le même PoP que les autres, beaucoup de > > Tier1 sont présents sur des sites différents de TH2 en coeur de > > réseau également (Level 3 remonte tout sur Nanterre, d'autres sont > > sur SFR Netcenter ou en propre et maintenant plusieurs vont mettre > > un coeur sur Iliad DC3). > > > > Les points de peering sont en général un "bonus" qualité, c'est > > "acceptable" > > de les perdre et à ma connaissance sur Paris il suffit d'être chez > > Equinix, InterXion ou Telecity pour avoir une alternative à TH2 pour > > les IX parisiens. > > > > Et il ne faut pas chercher longtemps pour trouver des pays où la > > situation est bien plus compliquée qu'en France. Hong Kong par > > exemple où il est difficile de se faire livrer un circuit > > international ailleurs que chez Mega IAdvantage (enfin on peut, mais > > ça passe par ce PoP quand même). A New York les PoPs historiques 60 > > Hudson Street et 111 8th sont quasi incontournables aussi et > > franchement TH2 a l'air ultra moderne à côté (surtout pour Hudson > > Street). > > > > Tout le monde est à TH2 mais beaucoup ont aussi une redondance > > ailleurs (hormis peut-être sur de la collecte), du coup ça impacte > > du monde, mais la résilience est souvent là pour éviter le drame. > > > > Les serveurs de données sont souvent ailleurs (au prix de la baie > > sur TH2...), du coup c'est pas le plus compliqué à sécuriser qui se > > trouve sur TH2. Je me souviens de la panne de Redbus, c'était plus > > un problème de données sur site que de réseau au final qui avait impacté le web français. > > > > Du coup, qui faut-il blâmer si ça tombe ? Pour moi pas le > > datacenter, pas celui qui fournit les liens (qui sait présenter des > > chemins distincts et livrer sur d'autres PoP), pas non plus les > > grands opérateurs de transit qui ne se concentrent pas sur TH2 > > uniquement. Par contre peut-être l'opérateur final qui fait des > > économies et se permet quelques SPOF sur son réseau en concentrant > > trop son coeur sur uniquement TH2. > > > > De là à dire que la France dépend trop de TH2, on n'y est pas je trouve. > > Qui > > ici craint pour son activité globale si TH2 tombe ? Et pourquoi ? > > Parce que le four
Re: [FRnOG] [TECH] [Clim] Ce qui s'est vraiment passé à TH2
On Tuesday 08 April 2014 15:18:37 Pierre Col - p...@9online.fr wrote: > > > On Tue, Apr 8, 2014, at 11:40, David Ponzone wrote: > > >> Sans parler des points d'arrivée des fibres sous-marines, si on voulait > > >> juste isoler la France du reste du monde. > > > > > > La France n'etant pas une ile, il faut couper du cable pendant bien > > > longtemps avant de l'isoler le pays. Et pas que du sous-marin. > > > En effet, si tous les cables sous-marins arrivant en France etait > > > coupes, l'impact serait plus grand pour d'autres (Asie, Moyen Orient), > > > et la France sera minimalement impacte (tout comme la Grande-Bretagne). > > > Il y a BEAUCOUP de capacite terrestre qui relie la France au monde > > > exterieur. > > > > Je suis d'accord, il ne faut pas exagérer le fantasme sur le chaos > > Internet > > en France lié à TH2 ou aux liens sur Paris. Sinon c'est que beaucoup de > > gens font mal leur métier. Quand je prends un lien vers d'autres pays, je > > fais comme tout opérateur "normal" dans le monde d'Internet : Je prends 2 > > chemins distincts, je m'assure que les chemins de fibre ne passent pas par > > le même PoP (TH2, SFR, Gardinoux ou autre points connus). Ca passe en > > général par Londres, par Francfort, par Bruxelles pour le Nord de l'Europe > > typiquement. > > > > Pour la fibre noire dans Paris c'est pareil, beaucoup de sites ont > > plusieurs > > arrivées distinctes qui permettent de faire en sorte que les fibres ne se > > croisent jamais. A moins d'une erreur humaine et d'un manque de sérieux > > dans l'étude du projet, il est facile en France de s'assurer des chemins > > diversifiés en redondance. D'autant que les gens dont c'est le métier de > > passer de la fibre ont déjà prévu ça (et que les fournisseurs donne même > > régulièrement le kmz qui va bien). > > > > En se renseignant un peu aussi, on évite de prendre un opérateur de > > transit > > IP qui remonte sur le même PoP que les autres, beaucoup de Tier1 sont > > présents sur des sites différents de TH2 en coeur de réseau également > > (Level 3 remonte tout sur Nanterre, d'autres sont sur SFR Netcenter ou en > > propre et maintenant plusieurs vont mettre un coeur sur Iliad DC3). > > > > Les points de peering sont en général un "bonus" qualité, c'est > > "acceptable" > > de les perdre et à ma connaissance sur Paris il suffit d'être chez > > Equinix, > > InterXion ou Telecity pour avoir une alternative à TH2 pour les IX > > parisiens. > > > > Et il ne faut pas chercher longtemps pour trouver des pays où la situation > > est bien plus compliquée qu'en France. Hong Kong par exemple où il est > > difficile de se faire livrer un circuit international ailleurs que chez > > Mega IAdvantage (enfin on peut, mais ça passe par ce PoP quand même). A > > New > > York les PoPs historiques 60 Hudson Street et 111 8th sont quasi > > incontournables aussi et franchement TH2 a l'air ultra moderne à côté > > (surtout pour Hudson Street). > > > > Tout le monde est à TH2 mais beaucoup ont aussi une redondance ailleurs > > (hormis peut-être sur de la collecte), du coup ça impacte du monde, mais > > la > > résilience est souvent là pour éviter le drame. > > > > Les serveurs de données sont souvent ailleurs (au prix de la baie sur > > TH2...), du coup c'est pas le plus compliqué à sécuriser qui se trouve sur > > TH2. Je me souviens de la panne de Redbus, c'était plus un problème de > > données sur site que de réseau au final qui avait impacté le web français. > > > > Du coup, qui faut-il blâmer si ça tombe ? Pour moi pas le datacenter, pas > > celui qui fournit les liens (qui sait présenter des chemins distincts et > > livrer sur d'autres PoP), pas non plus les grands opérateurs de transit > > qui > > ne se concentrent pas sur TH2 uniquement. Par contre peut-être l'opérateur > > final qui fait des économies et se permet quelques SPOF sur son réseau en > > concentrant trop son coeur sur uniquement TH2. > > > > De là à dire que la France dépend trop de TH2, on n'y est pas je trouve. > > Qui > > ici craint pour son activité globale si TH2 tombe ? Et pourquoi ? Parce > > que > > le fournisseur (pas cher et unique ?) n'est pas présent ailleurs ? Parce > > que ça coûte plus cher d'avoir un autre point de raccordement ailleurs ? > > La > > question n'est-elle pas plus économique que technique au final ? Les > > infrastructures permettent de faire les choses bien, on a ce qu'il faut > > techniquement en France et personnellement j'ai jamais été bloqué > > techniquement pour redonder une infra sur Paris. > > > > My 2 cents, > > Frederic > > Et si Lyon <-> Paris direct est coupé par une météorite, on peut faire Lyon > <-> Toulouse <-> Paris et <-> Strasbourg <-> Paris via les GIX existants > :-) L'improbable et imprévisible météorite n'aurait donc que peu d'impact ;) Par contre il existe une véritable menace venue du ciel, probable et d'ampleur considérable celle-ci, qui fait fi de la redondance de lien des opérateurs et des mesures de sécurité à l'entr
Re: [FRnOG] [TECH] [Clim] Ce qui s'est vraiment passé à TH2
Pour la peine si il est passé sur le chauffage urbain, il a déjà les capacité pour ;) Laurent Le 08/04/2014 11:31, Pierre Col - p...@9online.fr a écrit : Il a probablement été transféré dans une autre branche de Dalkia : chauffage urbain etc... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [Clim] Ce qui s'est vraiment passé à TH2
On Tuesday 08 April 2014 11:05:04 Raphael Maunier wrote: > Tu peux nous donner ton experience sur les datacenters en France et AUSSI et > surtout à l’etranger ? Ton experience sur des audits à l’international pour > notre grande patrie ou encore des grosses banques ? Ta connaissance du > monde PCI ? > > Rien, Ah ok, je comprends mieux ton ignorance sur le sujet et que tu ne > cesses de vouloir essayer de contrer des gens qui pour le coup , eux > connaissent le sujet ! > > Bref toujours à faire de belles phrases pour raconter de la merde :) > > Raphael Ah l'ultime stratagème de la Dialectique éristique! « (...) il faut tenir des propos désobligeants, blessants et grossiers. Être désobligeant, cela consiste à quitter l’objet de la querelle (puisqu’on a perdu la partie) pour passer à l’adversaire, et à l’attaquer d’une manière ou d’une autre dans ce qu’il est : on pourrait appeler cela argumentum ad personam pour faire la différence avec l’argumentum ad hominem. Ce dernier s’écarte de l’objet purement objectif pour s’attacher à ce que l’adversaire en a dit ou concédé. Mais quand on passe aux attaques personnelles, on délaisse complètement l’objet et on dirige ses attaques sur la personne de l’adversaire. On devient donc vexant, méchant, blessant, grossier. C’est un appel des facultés de l’esprit à celles du corps ou à l’animalité. Cette règle est très appréciée car chacun est capable de l’appliquer, et elle est donc souvent utilisée. (...) » C'est vrai qu'en s'attaquant à mon experience personnelle en audit de grosses banques, ça démontre clairement qu'il y a régulièrement des attentats à l'explosif dans les data centers et qu'il est urgent de copier la TSA pour l'entrée dans les datacenter français. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [Clim] Ce qui s'est vraiment passé à TH2
Finalement, on en revient à ce que je disais: si un petit malin fait sauter les landing stations françaises, on pourra encore communiquer avec l'Europe de l'Ouest. Et il y a un facteur qui est rarement pris en compte: quel est le niveau d'occupation actuel des liens allumés en IP, et quel serait le niveau d'engorgement si la moitié de la capa sous-marine était HS. Il faudrait juste faire une simulation grandeur nature. C'est généralement ce qu'on fait dans d'autres domaines (backup, sécurité physique, évacuation, etc…). Le 8 avr. 2014 à 15:30, Radu-Adrian Feurdean a écrit : > On Tue, Apr 8, 2014, at 13:31, Frédéric Perrod wrote: > >> Tu es sûr de ça? >> Je vois bien des câbles qui traversent l'Europe et des câbles qui >> traversent les Etats-Unis, par contre je vois rien sur les cartes pour >> une traversée Europe-Asie par voie terrestre. > > Ca existe quand-meme. Il n'y a pas beaucoup (je pense a deux), c'est > hyepr-cher, mais ca existe. Et en raison du prix, c'est plutot utilise > pour des reseaux prives, pas beaucoup pour du internet "classique". > >> Un lien vers une carte? > > Si ce n'est pas publique, ca ne veut pas dire que ca n'existe pas. > >> dont Marseille qui concentre toutes les communications directes vers >> l'Asie. > > Nope. SMW-3 ne passe pas par "l'autre cote" (UK-PT-Mediteranee), et pas > mal de traffic Internet vers l'asie passe via US (en traversant les deux > oceans). > Donc une coupure de cable sous-marin vers l'asie aura certainement un > impact vers un certain nombre de societes, mais pas beaucoup pour le > trafic internet europeen. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] Nouvelle faille openssl
Et n'oublié pas les Secure Acces game SA en CO... largement deployés... SBU - Original Message - From: "Stephane Bortzmeyer" To: "Arthur Fernandez - Liazo" Cc: Sent: Tuesday, April 08, 2014 9:56 PM Subject: [FRnOG] Re: [ALERT] Nouvelle faille openssl On Tue, Apr 08, 2014 at 12:12:53AM +0200, Arthur Fernandez - Liazo wrote a message of 20 lines which said: il semblerait qu'une faille inquiétante vient d'être découverte dans openssl... Et n'oubliez pas que vos routeurs Juniper ont OpenSSL... --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
