[FRnOG] [JOBS] Fwd: Recherche de contrat d'alternance pour 2019-2020

2019-07-01 Par sujet randria.nicolas 
Bonjour à tous,

Je vous écris aujourd'hui car inscrit à la formation en alternance ERE
Cybersec de l'AFTI, qui débutera le 30 septembre prochain et durera 15
mois (jusqu'en décembre 2020) au rythme de 3 semaines en entreprise /
1 semaine à l'école, je recherche une entreprise qui pourra
m'accueillir dans le cadre de ce contrat d'alternance.

L'informatique est une de mes passions depuis mes 12 ans, j'ai appris
en autodidacte en complétant/validant par des formations
professionnelles.
J'ai commencé par travailler dans les métiers de support pour des
SSII, institutions publiques ou entreprises, en France et à
l'étranger, puis me suis orienté vers le développement web et souhaite
maintenant évoluer vers le réseau et les télécoms.

Je suis dispo sur toute la région parisienne, transports en commun
seulement pour l'instant, l'école étant dans le 91. CV sur demande.

Cordialement,
Nicolas RANDRIANARISOA


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

Re: [FRnOG] [TECH] Transit et déni de service

2019-07-01 Par sujet Raphael Maunier 
Hello,

Je ne vais repondre que techniquement car bon voila pas de commercial ici :)

Inter-ISP flowspec ce n’est pas aussi simple que ça. Je vous invite a regarder 
la presentation de Century Link et ATT faite par Nimrod Levy, Donald Smith  et 
John Schiel qui a ete faite au nanog 71
https://www.youtube.com/watch?v=Aj8EKYVSTtk 
 ( marrant on me voit sur la video 
en arrière plan lors des questions :) )

Il y a beaucoup de paramètres a prendre en compte et demande beaucoup de 
coordination et de “confiance’. On a regardé de notre coté pour l’implémenter 
avec nos clients et franchement, il y a encore beaucoup de boulot avant de 
penser a l’implémenter.
Nous avons contourné la complexité pour le moment en fournissant plutôt une API 
qui permet au peer/client de bloquer le ingress sur son port.
Nous avons d’autres choses en cours, pour s’approcher d’un meilleur traitement 
de l’attaque directement sur nos ports edge en ingress.

Flowspec seul en inter-isp ça ne suffit pas car des lors que ton bgp flappe ( 
port full par ex ) bah… ça marche plus trop.


Bref, on y est pas encore, mais ça arrivera bien un jour !

Raphael


> On 1 Jul 2019, at 19:21, Alexandre BATON  wrote:
> 
> 
>>> Et pourquoi pas BGP flowspec mais là c'est carrément du rêve pour moi. Mon 
>>> transit principal il a jamais entendu parler des communautés :-(
>> 
>> 
>> J'avoue que je ne l'avais pas envisagé initialement, mais vu que BGP
>> flowspec commence à être proposé, cela me tente pas mal :-).
>> 
> 
> BGP Flowspec me fait aussi de l’oeil mais mes transits actuels n’en font pas… 
> Vous avez une liste de fournisseurs de transit en France qui le propose ? 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Transit et déni de service

2019-07-01 Par sujet Alexandre BATON 


>> Et pourquoi pas BGP flowspec mais là c'est carrément du rêve pour moi. Mon 
>> transit principal il a jamais entendu parler des communautés :-(
> 
> 
> J'avoue que je ne l'avais pas envisagé initialement, mais vu que BGP
> flowspec commence à être proposé, cela me tente pas mal :-).
> 

BGP Flowspec me fait aussi de l’oeil mais mes transits actuels n’en font pas… 
Vous avez une liste de fournisseurs de transit en France qui le propose ? 

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

Re: [FRnOG] [TECH] Poste d'administration multi-niveaux

2019-07-01 Par sujet frnog 
Bonjour

Je ne vais parler ici qu'en mon nom propre, évidemment pas de mes
employeurs passés, présents, futurs.

Mais en tant qu'un des concepteurs de SEDUCS (ce qui n'est pas un titre
de gloire), utilisateur de QubesOS et aillant commencé à travailler sur
le sujet il y a une bonne décennie, je me sens concerné par le thread.

On 6/29/19 2:51 PM, Florent CARRÉ wrote:
> Bonjour tout le monde,
...
> 
> Incroyable, l'ANSSI aurait enfin compris que c'était stupide d'interdire la
> virtualisation pour le poste d'administration.
> Ils auraient pu éviter d'attendre aussi longtemps.
De mémoire, le premier document public de l'ANSSI décrivant le concept
de poste admin avec virtualisation doit dater de 2015. Ce n'est plus si
récent.
Si je lis bien, le principe décrit dans le guide est juste:
- avoir un hyperviseur comme socle non géré par l'utilisateur qui ne
sert qu'a gérer les VM et leurs échanges
- et avoir des VM cloisonnées par usage, plus ou moins autonomes selon
leur sensibilité.
C'est assez faisable avec Xen, KVM, HyperV...
Microsoft propose d'ailleurs une architecture de stations d'admin
(Privileged Access Workstation ou PAW) basée sur ce principe
https://blogs.technet.microsoft.com/datacentersecurity/2018/04/30/paw-deployment-guide/
C'est une question de configuration pas d'intégration complexe.

> ...
> Concernant Clip OS, ça fait depuis 2006 qu'ils sont dessus la chose et puis
> leur plus gros concurrent (qui est en production), c'est SEDUCS (
> http://www.c-s.fr/file/174062) de C (Communications & Systèmes).
SEDUCS c'est un socle multi-compartiment pour des applications
sensibles. C'est très loin d'un OS généraliste. Il existe des tonnes de
socles de ce genre développés pour les besoins du monde gouvernemental
de chaque grand pays et de chaque industriel de défense.
Par exemple
https://www.businesswire.com/news/home/20120227006690/en/BAE-Systems-STOP-OS%E2%84%A2-Secure-Application-Platform

En fait, à l'époque ou le DoD demandait des TrustedOS (Trusted Solaris
par exemple), faire des compartiments de niveau de classification séparé
était assez commun dans ce cadre.
Voir
https://en.wikipedia.org/wiki/Multilevel_security#Trusted_operating_systems

> ...
> Peut être qu'un jour il y aura une release stable de Clip OS, quand il aura
> 18 ans (on s'en approche rapidement).
En fait, ClipOS 4 est utilisé en production depuis des années. C'est
ClipOS 5, une mise à jour majeure et libre qui est en cours de maturation.
Par contre, aujourd'hui Clip 4 est pensé comme un poste bureautique et
messagerie sécurisé. Il n'est pas pensé pour développer ou scripter ce
qui le rend peu apte à servir de poste d'admin en 2019.
Si je comprends bien, élargir les cas d'usage devrait être possible avec
la v5.

>...
> Pourquoi ne pas envisager Qubes (https://www.qubes-os.org) ?
J'utilise Qubes sur la plupart de mes machines. C'est initialement conçu
dans l'idée que l'utilisateur est autonome et son propre administrateur.
A noter que si le fonctionnement des VM Linux est complètement
transparent, coté Windows il ne faut pas trop rêver.
Dans la version 4, Qubes a introduit un framework de gestion proche des
concepts de ClipOS basé sur Salt
https://www.qubes-os.org/news/2015/12/14/mgmt-stack/ Je n'ai pas testé,
je ne sais pas à quel point c'est pratique de déploiement, mais l'idée
est de gérer les postes sans accès à leur contenu.

Il existe en fait plein d'usages basé sur de la simple config et des GPO
dans le monde Windows, des déploiement d'images Linux, voire des
intégrations dédiées avec de hyperviseurs durcis (par exemple Polyxène
de Bertin).
Mais l'important au final, c'est de se débarrasser des usages à risque
dans le monde privilégié (socle de l'hyperviseur, ou VM d'admin).

A ma connaissance, il n'existe pas aujourd'hui de solution d'OS
multi-compartiment disponible sur l'étagère qui soit qualifiée par
l'ANSSI, ClipOS inclus. Mais ce n'est pas nécessaire dans la plupart des
cas.

Bref, ce n'est ni infaisable, ni même aussi dur à faire qu'on croit
souvent de prime abord.

-- 
Christophe Renard
https://ww.goupilland.net


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

Re: [FRnOG] [TECH] Poste d'administration multi-niveaux

2019-07-01 Par sujet Youssef Ghorbal 
En effet, il n'y a pas de bonnes solutions, l'administrateur va
"souffir" (en comparaison a un setup moins secure selon le ref ANSSI)
Dans tt les versions il y'a deux systemes 1 d'admin, 1 de bureatique.
Le poste d'admin est forcement physique, le poste bureautique est soit
physique soit une VM. L'acces est uniquement autorise depuis le poste
d'admin vers le poste bureautique.
La version la moins penible, je trouve, est un bureau distant depuis
le poste d'admin vers le poste bureautique qui autorise le
copier/coller, mais il faut accepter la perte de qq fonctionnalites
"attendu" d'un poste bureautique (la video avec son dans le cadre de
visioconf par exemple) Il faudra dans ce cas fournir un poste nomade
pr la visio pr les admins en question.
Dans tous les cas, il reste a traiter les problemes de teletravail ds
ce contexte ainsi que la telemaintenance :)

Youssef

On Mon, Jul 1, 2019 at 1:16 PM Thierry Del-Monte  wrote:
>
> Bonjour,
>
> Merci à tous pour vos échanges et vos idées.
> Comme je m'y attendais, le sujet est loin d'être simple.
>
> La R9-- propose l'utilisation d'un VDI pour accéder à l'internet mais le 
> déconseille pour administrer des Hyperviseurs et des Annuaires.
> La R9- est a solution la plus sexy (utilisation de poste multi-niveaux) mais 
> peu de solutions sur le marché, l'ANSSI développe Clip-OS depuis 2006 mais en 
> 2019 toujours pas de version utilisable en production et SEDUCS en lisant le 
> PDF je n'ai pas compris ce que cela faisait exactement.
> La R9 demande d'avoir deux PC physiques différents (là je vais perdre tous 
> mes ingénieurs ...)
>
> S'il y a des personnes de l'ANSSI sur la liste, il serait intéressant qu'ils 
> puissent partager dans les grandes lignes la solution mise en place chez eux.
>
> Thierry
>
>
>
>
> Le 29/06/2019 à 17:22, Stéphane Rivière a écrit :
>
> Le 29/06/2019 à 16:51, Florent CARRÉ a écrit :
>
> Bonjour tout le monde,
>
> Je plussoie ton approche, y compris l'excellent saltstack. Xen a une
> empreinte bien plus faible qu'un nux. Enfin, on va pas détailler, suffit
> d'aller voir sur le site de Qubes ou mater leurs ML...
>
> Maintenant, comme tu dis, bon courage... (et n'oublions pas la "cape de
> zorro" pour taper les credentials, de boucher/briquer tous les ports
> pour la "femme de chambre", etc...).
>
> Sans compter le hardware. Un PC sans hardware certifié, il sert à quoi
> l'OS ultra sécurisé ? À rester bien au chaud dans un intranet blindé.
>
>


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

Re: [FRnOG] [TECH] solution WAF

2019-07-01 Par sujet Laurent-Charles Fabre 
Bonjour,

nous pour les clients Denyall qui a fusionné avec beware et qui maintenant ça 
s’appelle Rohde 

Directeur technique disponible pour causer
appliance ou vm
modèle commercial adaptable pour les hébergeurs.
Accessoirement, c’est béni par l'ANSSI

Laurent-Charles Fabre



> Le 1 juil. 2019 à 08:32, Ludovic RAMOSFILIPE  a écrit 
> :
> 
> Salut,
> 
> Sinon il y a aussi fortinet fortiweb
> 
> Le dim. 30 juin 2019 à 18:30, Alexandre DERUMIER  a
> écrit :
> 
>> Wallarm ca marche pas mal en effet, par contre c'est hors de prix.
>> 
>> et pour avoir négocier avec leur commerciaux, c'est vraiment pas le genre
>> de démarche commerciale que j'aime.
>> (tarif non public, à la tete du client, tu fais le mort , bam t'as une
>> ristourne de 50%)
>> 
>> Enfin bref...
>> 
>> 
>> 
>> 
>> Perso, j'utilise pour mes clients
>> 
>> https://bitninja.io/   (entre 10-40€ par mois/par serveur. ca dépend du
>> nombre d'utilisateur sur le serveur. (uid>1000)
>> 
>> 
>> ca fait en autre waf (basé sur modsecurity), mais le plus interessant
>> c'est la réputation d'ip collaborative (whitelist/greylist + captcha).
>> 
>> j'avais testé justement avec wallarm derriere, il me restait quelques
>> injections sql qui passait encore derrière, on va dire 1% avec dedans pas
>> mal de faux positif.
>> 
>> 
>> 
>> sinon j'attend avec impatience la sortie de darwin du projet vulture, qui
>> sera un waf machine learning intégré à haproxy.
>> https://2018.pass-the-salt.org/files/talks/13-vulture.pdf
>> 
>> 
>> 
>> - Mail original -
>> De: "Wallace" 
>> À: "frnog-tech" 
>> Envoyé: Jeudi 27 Juin 2019 13:00:40
>> Objet: [FRnOG] [TECH] solution WAF
>> 
>> 
>> 
>> Bonjour à tous,
>> 
>> On exploite du WAF en amont de certains clients, on est passé par les
>> étapes Naxsi, IngenSec (qui a fermé), Wallarm.
>> 
>> On est assez content de Wallarm même s'il reste des améliorations à faire
>> et que techniquement on est pas fan d'une partie on premise avec une
>> dépendance dans le cloud que l'on ne maitrise pas. Par contre leur modèle
>> commercial n'est pas adapté à ce que l'on désire mettre en place se basant
>> sur un coût par host au lieu d'un coût par domaine / site ou hits.
>> 
>> Du coup qu'avez-vous testé et éprouvé en solutions WAF on premise tournant
>> sous Linux?
>> 
>> 
>> Merci par avance.
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> -- 
> 
> 
> 
> 
> 
> 
> 
> Ludovic Ramos | Responsable VOIP
> 
> | *SCT TELECOM *| La plaine saint denis
> | phone: 0 <892020220>892020220
> | email: l.ra...@sct-telecom.fr
> | site:  www.sct-telecom.fr
> | skype: ludovic.ramos95
> | address:  17-19 avenue de la metallurgie
>  
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Transit et déni de service

2019-07-01 Par sujet Emmanuel DECAEN 
Bonjour,

Le 28/06/2019 à 04:52, Michel Py a écrit :
>> Emmanuel DECAEN a écrit :
>> Comme beaucoup d'entre vous, je fais évoluer régulièrement nos liens de 
>> transit BGP
>> (quelques 10G). Cette année, j'ai le souhait de demander à chaque opérateur 
>> de transit
>> de prendre la charge d'un éventuel DDoS directement au niveau de son 
>> backbone.
> Beaucoup dépend de ce que tu vois arriver comme DDOS. Si tu te prends des 
> DDOS térabit tous les jours, Arbor c'est très cher mais pas forcément trop 
> cher, çà dépend de l'épaisseur de ton portefeuille et de combien le DDOS te 
> coute vraiment. Si tes DDOS se font principalement sur une IP, avec les 
> communautés tu t'en sors très bien. Si tu as un truc qui attaque l'ensemble 
> de tes adresses, c'est pas glop.
> Ca dépend qui est attaqué : toi, ou quelqu'un que tu héberges.
>
> Et beaucoup dépend aussi de ce que tes transits font déjà (communautés ? sans 
> une solution commerciale)
> Et pourquoi pas BGP flowspec mais là c'est carrément du rêve pour moi. Mon 
> transit principal il a jamais entendu parler des communautés :-(


J'avoue que je ne l'avais pas envisagé initialement, mais vu que BGP
flowspec commence à être proposé, cela me tente pas mal :-).

> Et est-ce qu'ils souscrivent à quelque chose comme çà : 
> http://www.team-cymru.com/utrs.html


Je ne sais pas, mais ça semble pas mal, je suis très intéressé par un
retour d'expérience.


> C'est pas évident de faire soi-même, mais t'as 5 ingés. Achète une bouteille 
> de Stroh à Xavier :P


Bonne idée ;-)


-- 
*Emmanuel DECAEN*


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

Re: [FRnOG] [TECH] Transit et déni de service

2019-07-01 Par sujet Emmanuel DECAEN 
Salut Xavier,

Le 27/06/2019 à 20:28, Xavier Beaudouin a écrit :
>> Avez-vous des retours d'expérience sur les solutions anti-DDoS (Arbor,
>> etc.) proposées par les opérateurs de transit et surtout leur efficacité
>> en conditions réelles ?
> Retours d'expérience: cher et autant le faire soit même avec les bonnes 
> communautés BGP,
> tel a été le choix d'un de mes précédents jobs. Surtout quand on peux écraser 
> la merde
> sur les routers border avec soit des ACL soit du BGP Flowspec :)

Effectivement :-)
Je vais laisser la porte ouverte pour une solution BGP Flowspec en plus
d'une solution anti-DDoS

J'ai eu quelques retours d'expérience, mais surtout plusieurs réponses
commerciales en privé, voici un petit résumé des "solutions" autres
qu'un équivalent Arbor :

1> prendre du gros tuyaux et nettoyer à l'entrée 

Le raisonnement de l'opérateur est que le prix d'une 10G est
relativement raisonnable maintenant.
Donc on peut nettoyer à l'entrée (ACL), et se contenter du point 2 en
cas extrême (ci-dessous).

2> utiliser du BGP blackhole

Quasiment tous les opérateurs semblent offrir un service de ce type.
Le problème est que tu blacklistes toi même les adresses IP concernées,
donc le déni de service est réussi au final.

3> Utiliser du BGP Flowspec

Cette solution semble moins proposée de prime abord.
Je ne sais pas encore si c'est par absence d'offre ou par méconnaissance
du catalogue pour ceux qui ne l'ont pas proposé.

J'aime bien le principe général, c'est très granulaire, et s'il
s'applique sur tout le réseau de l'opérateur (via les PE ?), l'attaque
n'entre même pas sur le réseau.
Tout le monde y gagne.


> En général le prix étant tellement plus élevé que prendre du tuyaux et négo 
> des commits
> que pour cette expérience le résultat a été celui là. 


C'est effectivement le raisonnement de plusieurs opérateurs m'ayant
contacté en privé.


>
> Surtout que les IX commencent a donner les moyen de null router les ips 
> cibles (ou mieux
> shut la connection sur l'IX et attendre via flowspec / arbor / whatever que 
> ca se calme).


Il faut que je vois avec Grenoblix Lyonix si BGP flowspec est supporté ;-)

>> Ou avez-vous plutôt privilégié des solutions BGP de pure player (Qrator,
>> etc.) ?
> Jamais testé, elles n'existaient pas (ou débutais à l'époque). Pour certains 
> trucs un CDN
> a été utilisé pour limiter l'impact de l'appeau a DDoS. :)


J'ai eu plusieurs réponses de fournisseurs anti-DDoS utilisant BGP.
Le principe est assez simple: en cas d'attaque, on coupe tous les autres
transits, la totalité du trafic bascule alors sur le fournisseur anti-DDoS.
Finalement, on prend des tuyaux raisonnables chez quelques transitaires
classiques, et un chez le fournisseur anti-DDoS;

Cerise sur le gâteau, si le fournisseur anti-DDoS est présent sur ton
point d'échange favori, ta liaison avec lui ne te coute quasiment rien,
tu rétribues juste le service.


> Après ça fait quelques temps et donc le paysage a peut-être changé...  (eg je 
> sais pas si 
> des transitaires sont BGP Flowspec compatibles par exemple).

Oui, je te confirme que c'est supporté, mais je n'ai pas l'impression
que c'est la grande majorité.

> Ne pas oublier, certains traffic pourris viennent AUSSI des IX, et si tu as 
> donc des IX a 
> gérer, et bien les protection des transitaires peuvent être useless. Ah aussi 
> tu leur donne
> confiance car tu dois ajouter une route de tes prefix dans leur AS... A toi 
> de voir jusqu'où
> vas ta confiance en eux :)

Aujourd'hui, la partie IX représente une faible partie de mon trafic, en
cas d'attaque, je pense raisonnable de couper ;-)


Je vais rester ouvert sur l'aspect DDoS, je pense que  je vais prendre
quelques transits 10 G en privilégiant au moins un supportant BGP flowspec.
Et un prestataire anti-DDoS, qu'il soit opérateur de transit ou non.


Merci de ta réponse.

PS: Je ne suis pas opposé aux propositions de transit ou anti-DDoS BGP
par mail privé mais pas d'appels téléphoniques SVP.

-- 
*Emmanuel DECAEN*


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

Re: [FRnOG] [TECH] [IT SECURITY] Virtualisation de firewall, pentest, compromissions

2019-07-01 Par sujet Alexandre DERUMIER 
Salut,

Perso je ne suis vraiment pas fan des firewall VM, principalement à cause des 
flood et petits paquets. (quoi que avec dpdk why not, mais bon si la vm plante 
...).

Par contre, faire du firewalling sur l'hyperviseur au niveau des bridges des 
vms (iptables FORWARD), je ne vois pas soucis en terme de performance. (comme 
sur proxmox ou openstack par exemple).

Comme cela le firewall est "distribué" sur l'ensemble des hyperviseurs.

Maitenant niveau securité, comme les ip destinations ne sont pas porté par 
l'hyperviseur (en tout cas si pas de nat 1:1), je ne pense pas qu'on puisse 
remonter dans le host avec une faille netfilter.
(mais je ne suis pas assez expert pour l'affirmer)


Si je ne dis pas de bétise,le firewalling chez google cloud fonctionne comme ca



- Mail original -
De: "Jean-Christophe Janczak" 
À: "frnog-tech" 
Envoyé: Lundi 1 Juillet 2019 08:17:45
Objet: [FRnOG] [TECH] [IT SECURITY] Virtualisation de firewall, pentest, 
compromissions

Bonjour la liste. 

Toujours un plaisir de lire assidûment vos nombreux et savoureux échanges. :-) 

Aujourd’hui je me lance pour une question qui me taraude depuis pal mal de 
temps à propos de la { possible | réelle } compromission d'architectures à base 
de " firewalls virtuels " 

Je lance donc une bouteille à la mer sur le sujet à tous les volontaires { 
étudiants IT Sec | hard core hackers | pen testers | IT Sec Officers | RSSI | 
net admin | sys admin | autres etc } de la liste afin d’avoir et partager 
vos avis éclairés et retours d’expériences en prod, et bonnes pratiques sur le 
sujet. :-) 


1) Autrefois au temps jadis, en mode old school, on mettait un firewall 
“physique” en coupure de réseau entre deux interfaces électroniques distinctes. 
Mais ça s’était avant ... 


2) depuis, "on" a inventé les firewalls « virtuels » et le « *SDN* / *SD 
Everything* » est passé par là avec un détour par les nuages. 
(Comme chacun sait, ca fuit, les nuages... mais aussi, un firmware (binaire de 
bas niveau) ou une vm (binaire de haut niveau) c’est toujours un peu “virtuel” 
;-) ) 


3) la question qui me préoccupe ici c’est le mode hybride, dans un contexte 
small/branch Office en LAB/TPE/PME/PMI/datacenter/... : 
un ou plusieurs firewall (vm) qui tournent sur un hyperviseur du marché { 
VMware | hyperV | KVM | XEN | oVIRT | ... } 
- avec une patte de la vm fw bridgée cote Wan, 
- et l’autre bridgée côté Lan, dmz, iot, wifi,  
Dans cette configuration l’hyperviseur : 
- opère et n’as pas d’IP sur la couche ISO/L2 côté WAN, 
- et il a une ip d'administration côté interne. 

WAN xdsl/cable/fibre <==> BOX FAI <==> Hypervisor_WAN_IF_bridge_noIP <==> 
Hypervisor_CPU_RAM ( host n x VM_FW ) <==> Hypervisor_LAN_IP_admin <==> reste 
du réseau interne 

Exemple de config graphique ici, mais SANS IP coté WAN : 
https://blog.zwindler.fr/wp-content/uploads/2017/07/proxmox-install_simple-infra-map.jpg
 
https://blog.zwindler.fr/wp-content/uploads/2017/07/proxmox-install_full-infra-diag.jpg
 


3.a) le point positif c’est qu’on peut se faciliter l’administration (snapshot, 
souplesse etc ) et *densifier* le rendement/ratio puissance de calcul/coût au 
watt dans ce mode de fonctionnement. 


3.b) *SAUF QUE* : avant, en mode old school c’était les firewalls « physiques » 
qui protégeaient l’infra, les hyperviseurs et le reste, et PAS l'inverse : 
l'hyperviseur qui protège le FW !!! 


3.c) ma crainte est donc : 
- quelle confiance relative peut on raisonnablement accorder aux architectures 
de firewall virtuelles ? 
- *Jusqu'à quel point pouvons nous être sur ou pas* de la compromission d'une 
machine hôte qui héberge des FW virtuels ? 
- jusqu'à quel point nos hyperviseurs préférés sont-il "béton" ?? 

Nous savons tous que l’informatique n’est pas toujours une science "exacte" et 
je m’attends à ce qu’un jour ou l’autre une attaque soit réussie contre un 
hyperviseur côté WAN en couche 2 / bridge : 
- via { DDOS | flooding | magic packet | os fingerprint | faille, bug, etc ... 
} 
- et au détriment de la vm fw qui ne verra rien passer (par définition) de ce 
qui se passe à l’étage en dessous sur la couche hôte ! 


3.d) D'après ce que j'ai pu comprendre également si j'en crois la description 
officielle, et faute d'avoir mis les doigts jusqu'à présent dans des solutions 
Fortinet, le mode VDOM de Fortinet ressemble peu ou prou à de la virtualisation 
de Firewall ? => VRAI / FAUX ? jusqu'à quel point et à quel niveau, sur quel 
périmètre ? 
https://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-virtual-domains-54/1-VDOM-overview/1-Introduction.htm
 


3.e) je n’ai principalement pas/plus le temps, pour faire des pentests massifs 
et approfondis sur le sujet, et suivre en veille permanente la sécurité IT 
comme dans les temps anciens, d'où ma question ici présente pour partager les 
avis et retours d'expérience 


3.f) dans la bien nommée revue MISC MAG il me semble avoir vu passer, il y a 
fort longtemps, des articles sur le crack d’un

Re: [FRnOG] [TECH] Poste d'administration multi-niveaux

2019-07-01 Par sujet Thierry Del-Monte 

Bonjour,

Merci à tous pour vos échanges et vos idées.
Comme je m'y attendais, le sujet est loin d'être simple.

La R9-- propose l'utilisation d'un VDI pour accéder à l'internet mais le 
déconseille pour administrer des Hyperviseurs et des Annuaires.
La R9- est a solution la plus sexy (utilisation de poste multi-niveaux) 
mais peu de solutions sur le marché, l'ANSSI développe Clip-OS depuis 
2006 mais en 2019 toujours pas de version utilisable en production et 
SEDUCS en lisant le PDF je n'ai pas compris ce que cela faisait exactement.
La R9 demande d'avoir deux PC physiques différents (/là je vais perdre 
tous mes ingénieurs .../)


S'il y a des personnes de l'ANSSI sur la liste, il serait intéressant 
qu'ils puissent partager dans les grandes lignes la solution mise en 
place chez eux.


Thierry




Le 29/06/2019 à 17:22, Stéphane Rivière a écrit :

Le 29/06/2019 à 16:51, Florent CARRÉ a écrit :

Bonjour tout le monde,

Je plussoie ton approche, y compris l'excellent saltstack. Xen a une
empreinte bien plus faible qu'un nux. Enfin, on va pas détailler, suffit
d'aller voir sur le site de Qubes ou mater leurs ML...

Maintenant, comme tu dis, bon courage... (et n'oublions pas la "cape de
zorro" pour taper les credentials, de boucher/briquer tous les ports
pour la "femme de chambre", etc...).

Sans compter le hardware. Un PC sans hardware certifié, il sert à quoi
l'OS ultra sécurisé ? À rester bien au chaud dans un intranet blindé.





smime.p7s
Description: Signature cryptographique S/MIME

Re: [FRnOG] [TECH] solution WAF

2019-07-01 Par sujet Ludovic RAMOSFILIPE 
Salut,

Sinon il y a aussi fortinet fortiweb

Le dim. 30 juin 2019 à 18:30, Alexandre DERUMIER  a
écrit :

> Wallarm ca marche pas mal en effet, par contre c'est hors de prix.
>
> et pour avoir négocier avec leur commerciaux, c'est vraiment pas le genre
> de démarche commerciale que j'aime.
> (tarif non public, à la tete du client, tu fais le mort , bam t'as une
> ristourne de 50%)
>
> Enfin bref...
>
>
>
>
> Perso, j'utilise pour mes clients
>
> https://bitninja.io/   (entre 10-40€ par mois/par serveur. ca dépend du
> nombre d'utilisateur sur le serveur. (uid>1000)
>
>
> ca fait en autre waf (basé sur modsecurity), mais le plus interessant
> c'est la réputation d'ip collaborative (whitelist/greylist + captcha).
>
> j'avais testé justement avec wallarm derriere, il me restait quelques
> injections sql qui passait encore derrière, on va dire 1% avec dedans pas
> mal de faux positif.
>
>
>
> sinon j'attend avec impatience la sortie de darwin du projet vulture, qui
> sera un waf machine learning intégré à haproxy.
> https://2018.pass-the-salt.org/files/talks/13-vulture.pdf
>
>
>
> - Mail original -
> De: "Wallace" 
> À: "frnog-tech" 
> Envoyé: Jeudi 27 Juin 2019 13:00:40
> Objet: [FRnOG] [TECH] solution WAF
>
>
>
> Bonjour à tous,
>
> On exploite du WAF en amont de certains clients, on est passé par les
> étapes Naxsi, IngenSec (qui a fermé), Wallarm.
>
> On est assez content de Wallarm même s'il reste des améliorations à faire
> et que techniquement on est pas fan d'une partie on premise avec une
> dépendance dans le cloud que l'on ne maitrise pas. Par contre leur modèle
> commercial n'est pas adapté à ce que l'on désire mettre en place se basant
> sur un coût par host au lieu d'un coût par domaine / site ou hits.
>
> Du coup qu'avez-vous testé et éprouvé en solutions WAF on premise tournant
> sous Linux?
>
>
> Merci par avance.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
-- 







Ludovic Ramos | Responsable VOIP

| *SCT TELECOM *| La plaine saint denis
| phone: 0 <892020220>892020220
| email: l.ra...@sct-telecom.fr
| site:  www.sct-telecom.fr
| skype: ludovic.ramos95
| address:  17-19 avenue de la metallurgie
 



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

[FRnOG] [TECH] [IT SECURITY] Virtualisation de firewall, pentest, compromissions

2019-07-01 Par sujet Jean-Christophe Janczak 
Bonjour la liste.

Toujours un plaisir de lire assidûment vos nombreux et savoureux échanges. :-)

Aujourd’hui je me lance pour une question qui me taraude depuis pal mal de 
temps à propos de la { possible | réelle } compromission d'architectures à base 
de " firewalls virtuels "

Je lance donc une bouteille à la mer sur le sujet à tous les volontaires { 
étudiants IT Sec | hard core hackers | pen testers | IT Sec Officers | RSSI | 
net admin | sys admin | autres etc } de la liste afin d’avoir et partager 
vos avis éclairés et retours d’expériences en prod, et bonnes pratiques sur le 
sujet. :-)


1) Autrefois au temps jadis, en mode old school, on mettait un firewall 
“physique” en coupure de réseau entre deux interfaces électroniques distinctes. 
Mais ça s’était avant ...  


2) depuis, "on" a inventé les firewalls « virtuels » et le « *SDN* / *SD 
Everything* » est passé par là avec un détour par les nuages.
    (Comme chacun sait, ca fuit, les nuages... mais aussi, un firmware (binaire 
de bas niveau) ou une vm (binaire de haut niveau) c’est toujours un peu 
“virtuel” ;-) )


3) la question qui me préoccupe ici c’est le mode hybride, dans un contexte 
small/branch Office en LAB/TPE/PME/PMI/datacenter/... :
    un ou plusieurs firewall (vm) qui tournent sur un hyperviseur du marché { 
VMware | hyperV | KVM | XEN | oVIRT | ... }
    - avec une patte de la vm fw bridgée cote Wan,
    - et l’autre bridgée côté Lan, dmz, iot, wifi, 
    Dans cette configuration l’hyperviseur :
    - opère et n’as pas d’IP sur la couche ISO/L2 côté WAN,
    - et il a une ip d'administration côté interne.
    
    WAN xdsl/cable/fibre <==> BOX FAI <==> Hypervisor_WAN_IF_bridge_noIP <==> 
Hypervisor_CPU_RAM ( host n x VM_FW ) <==> Hypervisor_LAN_IP_admin <==> reste 
du réseau interne
    
    Exemple de config graphique ici, mais SANS IP coté WAN :
    
https://blog.zwindler.fr/wp-content/uploads/2017/07/proxmox-install_simple-infra-map.jpg
    
https://blog.zwindler.fr/wp-content/uploads/2017/07/proxmox-install_full-infra-diag.jpg
    

3.a) le point positif c’est qu’on peut se faciliter l’administration (snapshot, 
souplesse etc ) et *densifier* le rendement/ratio puissance de calcul/coût au 
watt dans ce mode de fonctionnement.


3.b) *SAUF QUE* : avant, en mode old school c’était les firewalls « physiques » 
qui protégeaient l’infra, les hyperviseurs et le reste, et PAS l'inverse : 
l'hyperviseur qui protège le FW !!!


3.c) ma crainte est donc :
    - quelle confiance relative peut on raisonnablement accorder aux 
architectures de firewall virtuelles ?
    - *Jusqu'à quel point pouvons nous être sur ou pas* de la compromission 
d'une machine hôte qui héberge des FW virtuels ?
    - jusqu'à quel point nos hyperviseurs préférés sont-il "béton" ??
    
    Nous savons tous que l’informatique n’est pas toujours une science "exacte" 
et je m’attends à ce qu’un jour ou l’autre une attaque soit réussie contre un 
hyperviseur côté WAN en couche 2 / bridge :
    - via { DDOS | flooding | magic packet | os fingerprint | faille, bug, etc 
... }
    - et au détriment de la vm fw qui ne verra rien passer (par définition) de 
ce qui se passe à l’étage en dessous sur la couche hôte !


3.d) D'après ce que j'ai pu comprendre également si j'en crois la description 
officielle, et faute d'avoir mis les doigts jusqu'à présent dans des solutions 
Fortinet, le mode VDOM de Fortinet ressemble peu ou prou à de la virtualisation 
de Firewall ? => VRAI / FAUX ? jusqu'à quel point et à quel niveau, sur quel 
périmètre ?
    
https://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-virtual-domains-54/1-VDOM-overview/1-Introduction.htm


3.e) je n’ai principalement pas/plus le temps, pour faire des pentests massifs 
et approfondis sur le sujet, et suivre en veille permanente la sécurité IT 
comme dans les temps anciens, d'où ma question ici présente pour partager les 
avis et retours d'expérience


3.f) dans la bien nommée revue MISC MAG il me semble avoir vu passer, il y a 
fort longtemps, des articles sur le crack d’un hyperviseur et la compromission 
et l’évasion de données des vm et / ou rebond sur la couche hôte sans que les 
vm n’y voient que du feu.
    Est ce toujours vrai / possible ? étant donné que les éditeurs corrigent / 
durcissent dans une lutte sans fin leur produits, et que sauf erreur de ma 
part, nos hyperViseurs favoris ne sont pas développés en langage ADA ou avec 
des techniques de programmation par preuve logicielle et mathématique, mais 
plus par du patching au fil de l’eau et des découvertes de bug, failles etc. Me 
trompe-je ?


3.g) faute de mieux et/ou d'outils et de suite firewall opensource disponible, 
je n'ai pas encore trouvé le moyen ni le temps d'activer BHYVE de façon secure 
et industrielle sur une distrib firewall comme PFSense ou OPNSense, Untanglle, 
Endian, ...
    https://forum.netgate.com/topic/105832/bhyve-package-100usd ==> au point 
mort ?