Re: [FRnOG] [TECH] IP Nat sur Cisco

2016-04-13 Par sujet David Ponzone 
Il y a une bidouille avec des Loopback, immonde:

https://supportforums.cisco.com/discussion/12102421/nat-hairpinning

Mais sinon, un autre moyen de régler ton problème avec la conf actuelle serait 
de faire du PBR sur le traffic arrivant de R2 sur ROUTEUR-NAT pour l’envoyer 
directement sur ROUTEUR-TEST avec un set next-hop.
Et de là il va revenir vers 1.1.1.1 et tu as une petite chance que ça marche 
(petit parce que quand ROUTEUR-NAT va faire suivre le paquet retour pour 
1.1.1.2, qui est une autre loopback, ça peut poser des problèmes à la table de 
NAT…ou alors tu fais un PBR similaire pour le trafic de R1 et donc éviter le 
lookup de la RIB par ROUTEUR-NAT).



> Le 13 avr. 2016 à 15:29, Antoine Durant  a écrit :
> 
> J'ai essayé ton idée et cela est beaucoup plus simple. Mais j'ai quand même 
> une question que je n'arrive pas à résoudre/comprendre :
> Comment faire depuis le lan client pour pouvoir utiliser l'ip public depuis 
> mon poste 192.168.1.10 lorsque je veux accéder à l'ip public 1.1.1.1 naté 
> vers 192.168.1.1 ?
> Possible à faire en utilisant ip nat out/in ou pas??
> Merci pour l'explication
> 
>
> Si tu as la main sur R1 et R2 pourquoi ne pas mettre les loopbacks sur ces 
> routeurs ?
> 
> Ensuite ne reste plus que pousser les IP des loopbacks du R-NAT vers R1/R2 
> via un ip route.
> Je pense que cela est plus simple et pas besoin de passer par un Nat NVI, tu 
> conserves ton ip nat outside et ip nat Inside.
> 
> 
> ---
> 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] Proxy cache https (vraiment) transparent ?

2016-04-13 Par sujet David Ponzone 
Tout les jours ?

Effectivement :)

David Ponzone



> Le 13 avr. 2016 à 15:23, Edouard Chamillard  a 
> écrit :
> 
> sur frnog c'est tout les jours trolldi.
> 
> Le 13/04/2016 15:07, Sébastien FOUTREL a écrit :
>> C'est pas trolldi mais je ne peux pas m'en empecher :
>> https://youtu.be/uprjmoSMJ-o
>> 
>> 
>> Le 13 avril 2016 à 14:03, Kavé Salamatian 
>> a écrit :
>> 
 Le 13 avr. 2016 à 13:15, Solarus Lumenor  a
>>> écrit :
 
 
 Le 2016-04-13 12:01, Edouard Chamillard a écrit :
 
> le sujet c'etait les proxy transparents. CONNECT était hors course au
> premier mail.
 Une discussion ça dérive tu sais ? On parlait sécurité des réseaux
 business en général.
>>> Fais gaffes, il existerait des ayatollah inquisiteurs qui peuvent te faire
>>> passer à la question,  et te faire mettre à la vindicte publique, sur tous
>>> les média en simultanée parce que tu as dérogé à la règle !!! :-) … C’est
>>> risqué :-)
>>> 
 Et puis la transparence c'est très subjectif.
 Parler de transparence en voulant insérer des signatures X.509 forgées,
 c'est un contre-sens, c'est plutôt l'opacité totale pour l'utilisateur.
 Bref, CONNECT ça fonctionne.
 
 Solarus
 
 ---
 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] IP Nat sur Cisco

2016-04-13 Par sujet Antoine Durant 
J'ai essayé ton idée et cela est beaucoup plus simple. Mais j'ai quand même une 
question que je n'arrive pas à résoudre/comprendre :
Comment faire depuis le lan client pour pouvoir utiliser l'ip public depuis mon 
poste 192.168.1.10 lorsque je veux accéder à l'ip public 1.1.1.1 naté vers 
192.168.1.1 ?
Possible à faire en utilisant ip nat out/in ou pas??
Merci pour l'explication

    
Si tu as la main sur R1 et R2 pourquoi ne pas mettre les loopbacks sur ces 
routeurs ?

Ensuite ne reste plus que pousser les IP des loopbacks du R-NAT vers R1/R2 via 
un ip route.
Je pense que cela est plus simple et pas besoin de passer par un Nat NVI, tu 
conserves ton ip nat outside et ip nat Inside.


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

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

Re: [FRnOG] [TECH] Proxy cache https (vraiment) transparent ?

2016-04-13 Par sujet Edouard Chamillard 
sur frnog c'est tout les jours trolldi.

Le 13/04/2016 15:07, Sébastien FOUTREL a écrit :
> C'est pas trolldi mais je ne peux pas m'en empecher :
> https://youtu.be/uprjmoSMJ-o
>
>
> Le 13 avril 2016 à 14:03, Kavé Salamatian 
> a écrit :
>
>>> Le 13 avr. 2016 à 13:15, Solarus Lumenor  a
>> écrit :
>>>
>>>
>>> Le 2016-04-13 12:01, Edouard Chamillard a écrit :
>>>
 le sujet c'etait les proxy transparents. CONNECT était hors course au
 premier mail.
>>> Une discussion ça dérive tu sais ? On parlait sécurité des réseaux
>>> business en général.
>> Fais gaffes, il existerait des ayatollah inquisiteurs qui peuvent te faire
>> passer à la question,  et te faire mettre à la vindicte publique, sur tous
>> les média en simultanée parce que tu as dérogé à la règle !!! :-) … C’est
>> risqué :-)
>>
>>> Et puis la transparence c'est très subjectif.
>>> Parler de transparence en voulant insérer des signatures X.509 forgées,
>>> c'est un contre-sens, c'est plutôt l'opacité totale pour l'utilisateur.
>>> Bref, CONNECT ça fonctionne.
>>>
>>> Solarus
>>>
>>> ---
>>> 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/




signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] Proxy cache https (vraiment) transparent ?

2016-04-13 Par sujet Sébastien FOUTREL 
C'est pas trolldi mais je ne peux pas m'en empecher :
https://youtu.be/uprjmoSMJ-o


Le 13 avril 2016 à 14:03, Kavé Salamatian 
a écrit :

>
> > Le 13 avr. 2016 à 13:15, Solarus Lumenor  a
> écrit :
> >
> >
> >
> > Le 2016-04-13 12:01, Edouard Chamillard a écrit :
> >
> >> le sujet c'etait les proxy transparents. CONNECT était hors course au
> >> premier mail.
> >
> > Une discussion ça dérive tu sais ? On parlait sécurité des réseaux
> > business en général.
>
> Fais gaffes, il existerait des ayatollah inquisiteurs qui peuvent te faire
> passer à la question,  et te faire mettre à la vindicte publique, sur tous
> les média en simultanée parce que tu as dérogé à la règle !!! :-) … C’est
> risqué :-)
>
> >
> > Et puis la transparence c'est très subjectif.
> > Parler de transparence en voulant insérer des signatures X.509 forgées,
> > c'est un contre-sens, c'est plutôt l'opacité totale pour l'utilisateur.
> > Bref, CONNECT ça fonctionne.
> >
> > Solarus
> >
> > ---
> > 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] Proxy cache https (vraiment) transparent ?

2016-04-13 Par sujet Kavé Salamatian 

> Le 13 avr. 2016 à 13:15, Solarus Lumenor  a écrit :
> 
> 
> 
> Le 2016-04-13 12:01, Edouard Chamillard a écrit : 
> 
>> le sujet c'etait les proxy transparents. CONNECT était hors course au
>> premier mail.
> 
> Une discussion ça dérive tu sais ? On parlait sécurité des réseaux
> business en général.

Fais gaffes, il existerait des ayatollah inquisiteurs qui peuvent te faire 
passer à la question,  et te faire mettre à la vindicte publique, sur tous les 
média en simultanée parce que tu as dérogé à la règle !!! :-) … C’est risqué :-)
 
> 
> Et puis la transparence c'est très subjectif.
> Parler de transparence en voulant insérer des signatures X.509 forgées,
> c'est un contre-sens, c'est plutôt l'opacité totale pour l'utilisateur.
> Bref, CONNECT ça fonctionne. 
> 
> Solarus 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

2016-04-13 Par sujet Solarus Lumenor 
 

Le 2016-04-13 12:01, Edouard Chamillard a écrit : 

> le sujet c'etait les proxy transparents. CONNECT était hors course au
> premier mail.

Une discussion ça dérive tu sais ? On parlait sécurité des réseaux
business en général.

Et puis la transparence c'est très subjectif.
Parler de transparence en voulant insérer des signatures X.509 forgées,
c'est un contre-sens, c'est plutôt l'opacité totale pour l'utilisateur.
Bref, CONNECT ça fonctionne. 

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

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

2016-04-13 Par sujet Edouard Chamillard 
Le 13/04/2016 12:53, Solarus Lumenor a écrit :
>  
>
> Le 2016-04-13 10:56, Edouard Chamillard a écrit : 
>
>> donc la plupart des boites serieuses ont un proxy en MITM, capable de
>> lire un en tete SNI ou un champ Server: (et pas un FQDN, a part si ton
>> proxy fait aussi la résolution dns (ce que certains font)).
>> effectivement ça méritait de parler de deux types d'équipement.
> Pourquoi faire si compliqué ?
>
> La RFC 2817 (qui date de 2000) prévoit que seul le CONNECT doit passer
> en HTTP/1.1. Là le proxy peut accepter ou refuser la connexion en
> fonction du domaine demandé dans le CONNECT.
> En cas d'acceptation le client peut demander un upgrade (passage en
> HTTPS) et établir un tunnel TLS directement avec le serveur distant,
> tunnel qui n'est pas intercepté et qui permet de conserver
> authentification X.509 légitime. 
>
> https://tools.ietf.org/rfc/rfc2817 
>
le sujet c'etait les proxy transparents. CONNECT était hors course au
premier mail.



signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

2016-04-13 Par sujet Solarus Lumenor 
 

Le 2016-04-13 10:56, Edouard Chamillard a écrit : 

> donc la plupart des boites serieuses ont un proxy en MITM, capable de
> lire un en tete SNI ou un champ Server: (et pas un FQDN, a part si ton
> proxy fait aussi la résolution dns (ce que certains font)).
> effectivement ça méritait de parler de deux types d'équipement.

Pourquoi faire si compliqué ?

La RFC 2817 (qui date de 2000) prévoit que seul le CONNECT doit passer
en HTTP/1.1. Là le proxy peut accepter ou refuser la connexion en
fonction du domaine demandé dans le CONNECT.
En cas d'acceptation le client peut demander un upgrade (passage en
HTTPS) et établir un tunnel TLS directement avec le serveur distant,
tunnel qui n'est pas intercepté et qui permet de conserver
authentification X.509 légitime. 

https://tools.ietf.org/rfc/rfc2817 

5. Upgrade across Proxies

 As a hop-by-hop header, Upgrade is negotiated between each pair of
 HTTP counterparties. If a User Agent sends a request with an Upgrade
 header to a proxy, it is requesting a change to the protocol between
 itself and the proxy, not an end-to-end change.

 Since TLS, in particular, requires end-to-end connectivity to provide
 authentication and prevent man-in-the-middle attacks, this memo
 specifies the CONNECT method to establish a tunnel across proxies.

 Once a tunnel is established, any of the operations in Section 3 can
 be used to establish a TLS connection.

5.2 Requesting a Tunnel with CONNECT

 A CONNECT method requests that a proxy establish a tunnel connection
 on its behalf. The Request-URI portion of the Request-Line is always
 an 'authority' as defined by URI Generic Syntax [2], which is to say
 the host name and port number destination of the requested connection
 separated by a colon:

 CONNECT server.example.com:80 HTTP/1.1
 Host: server.example.com:80

 Other HTTP mechanisms can be used normally with the CONNECT method --
 except end-to-end protocol Upgrade requests, of course, since the
 tunnel must be established first.

 For example, proxy authentication might be used to establish the
 authority to create a tunnel:

 CONNECT server.example.com:80 HTTP/1.1
 Host: server.example.com:80
 Proxy-Authorization: basic aGVsbG86d29ybGQ=

 Like any other pipelined HTTP/1.1 request, data to be tunneled may be
 sent immediately after the blank line. The usual caveats also apply:
 data may be discarded if the eventual response is negative, and the
 connection may be reset with no response if more than one TCP segment
 is outstanding.

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

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

2016-04-13 Par sujet Edouard Chamillard 


Le 13/04/2016 09:25, Solarus Lumenor a écrit :
>  
>
> Le 2016-04-12 17:07, Edouard Chamillard a écrit : 
>
>> sérieux compromettent carrément la session complète sur tout internet au
>> lieu de la compromettre en interne sur un seul équipement, et pire,
>> rendent impossible la connexion aux sites qui utilisent HSTS ? ce genre
>> de gens sérieux ? on est déja trolldi ?
> Va falloir m'expliquer comment compromettre une «session complète sur
> tout internet» avec simplement un proxy d'entreprise, parce que ça à
> l'air intéressant comme faille.

on interdit une connexion sur le port 443 tout en autorisant une
connexion sur le port 80 quelque part sur le trajet entre le client et
le reste des tuyaux du monde ? effectivement c'est passionant...
> Oui, la plupart des boites sérieuses ont un proxy avec un filtrage sur
> les FQDN. 
>
> -Demande de connexion HTTPS au site d'une banque : OK
> -Demande de connexion HTTPS à Facebook : KO
donc la plupart des boites serieuses ont un proxy en MITM, capable de
lire un en tete SNI ou un champ Server: (et pas un FQDN, a part si ton
proxy fait aussi la résolution dns (ce que certains font)).
effectivement ça méritait de parler de deux types d'équipement.
>  
>
> Si tu a le droit d'accéder au site, tu y accède, si le site n'a pas
> d'intérêt professionnel ou présente un danger (webmail, fishing etc) ben
> tu reçois un joli code HTTP 403 t'interdisant d'y accéder. 
> C'est aussi simple que ça et ça permet de protéger le réseau
> d'entreprise sans mettre en œuvre de solutions qui ELLES seraient
> dangereuses pour la confiance que peuvent avoir les utilisateurs envers
> le modèle X.509/TLS au niveau global.
donc. dans une session https. tu peux injecter un 403. ok. ou alors
encore mieux. le client se connecte en http sur ton proxy (et le reste
du réseau qui est manifestement ~de confiance~ voit le contenu en clair)
et le proxy fait le handshake.

non parce que y'a littéralement aucun moyen de faire ce que tu viens de
dire faire sans etre en MITM, et vu que tu es en MITM...

aucun commentaire sur l'argument bloquer/lire le flux. c'est une pure
question de PSSI qui doit etre prise par des gens mieux payés que moi.
>  
>
> Au delà de l'aspect technique, je considère à titre personnel et éthique
> que toute volonté d'interception (contrairement au blocage) n'a pour but
> que d'espionner les salariés et les utilisateurs de manière
> disproportionnée.
> Et j'attends encore la preuve du contraire. 
>
> Solarus 
>  
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/




signature.asc
Description: OpenPGP digital signature

[FRnOG] [JOBS] Demande de stage - BTS

2016-04-13 Par sujet Maxime Lenoir 
Bonjour,

J'ai effectivement oublié de préciser le lieu de mon stage, je voudrais
donc l'effectuer en région parisienne,

Bonne journée,


 Lenoir Maxime

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

Re: [FRnOG] [TECH] pfSense 2.3-RELEASE Now Available!

2016-04-13 Par sujet David Ponzone 
A priori, pfSense semble avoir l'uRPF strict par défaut, qui vient de PF 
d'OpenBSD.
Quelqu'un a un pfSense en BGP multi-homed pour confirmer ?


David Ponzone



> Le 13 avr. 2016 à 09:55, David Ponzone  a écrit :
> 
> Au passage, j'ai pas réussi à trouver une confirmation que pfSense supporte 
> l'uRPF avec les modes strict et loose comme Cisco, VyOS ou RouterOS.
> 
> 
> David Ponzone
> 
> 
> 
>> Le 13 avr. 2016 à 09:48, Thomas B.  a écrit :
>> 
>> 2016-04-12 23:18 GMT+02:00 David Ponzone :
>>> Quelqu’un l’a essayé ?
>> 
>> On en met un prod dans quelques jours...
>> J'ai testé la RC sur une VM, le refresh de l'UI fait pas de mal par contre 
>> pas pu regarder si elle entraînait des régressions.
>> 
>> Br,
>> Thomas
>> 

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

Re: [FRnOG] [TECH] pfSense 2.3-RELEASE Now Available!

2016-04-13 Par sujet David Ponzone 
Au passage, j'ai pas réussi à trouver une confirmation que pfSense supporte 
l'uRPF avec les modes strict et loose comme Cisco, VyOS ou RouterOS.


David Ponzone



> Le 13 avr. 2016 à 09:48, Thomas B.  a écrit :
> 
> 2016-04-12 23:18 GMT+02:00 David Ponzone :
>> Quelqu’un l’a essayé ?
> 
> On en met un prod dans quelques jours...
> J'ai testé la RC sur une VM, le refresh de l'UI fait pas de mal par contre 
> pas pu regarder si elle entraînait des régressions.
> 
> Br,
> Thomas
> 

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

Re: [FRnOG] [TECH] pfSense 2.3-RELEASE Now Available!

2016-04-13 Par sujet Thomas Barandon 
2016-04-12 23:18 GMT+02:00 David Ponzone :

> Quelqu’un l’a essayé ?
>

On en met un prod dans quelques jours...
J'ai testé la RC sur une VM, le refresh de l'UI fait pas de mal par contre
pas pu regarder si elle entraînait des régressions.

Br,
Thomas

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

Re: [FRnOG] [JOBS] Demande de stage - BTS

2016-04-13 Par sujet r...@fkgm.fr 

Bonjour,

Dans ce cas il est intéressant de rajouter la localisation géographique 
de votre recherche.



Bonne journée et bonne recherche.

Le 13/04/2016 01:07, Maxime Lenoir a écrit :

Madame, Monsieur,

Dans le cadre de ma formation en BTS SIO (Services Informatique aux
Organisations) options réseaux, j'ai le devoir d'effectuer un stage
pratique, qui me permettrait de valider cette première année. Cette
expérience de cinq semaines qui se déroulera du du 30 mai au 1er juillet
doit me permettre d'observer et de participer au fonctionnement d'un
service informatique, dans le but de compléter la formation théorique.
Je me permet donc de vous contactez afin d'envisager un recrutement de
votre part.
Les pièces jointes sont interdites, je vous ferai donc parvenir mon c.v
ainsi que ma lettre de motivation à votre demande.

Etant quotidiennement disponible à cet email je vous laisse également mon
numéro de téléphone auquel vous pouvez me contacter le mercredi et le
week-end toute la journée ou bien en semaine à partir de 18 heures :
06.33.03.03.82.

Merci d'avance,


  Lenoir Maxime

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


--

Ronan Bianic

-
Abuse: ab...@fkgm.fr
-
Mail : rb@@fkgm.fr
-


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

Re: [FRnOG] Re: [TECH] Proxy cache https (vraiment) transparent ?

2016-04-13 Par sujet Solarus Lumenor 
 

Le 2016-04-12 17:07, Edouard Chamillard a écrit : 

> sérieux compromettent carrément la session complète sur tout internet au
> lieu de la compromettre en interne sur un seul équipement, et pire,
> rendent impossible la connexion aux sites qui utilisent HSTS ? ce genre
> de gens sérieux ? on est déja trolldi ?

Va falloir m'expliquer comment compromettre une «session complète sur
tout internet» avec simplement un proxy d'entreprise, parce que ça à
l'air intéressant comme faille.
Oui, la plupart des boites sérieuses ont un proxy avec un filtrage sur
les FQDN. 

-Demande de connexion HTTPS au site d'une banque : OK
-Demande de connexion HTTPS à Facebook : KO 

Si tu a le droit d'accéder au site, tu y accède, si le site n'a pas
d'intérêt professionnel ou présente un danger (webmail, fishing etc) ben
tu reçois un joli code HTTP 403 t'interdisant d'y accéder. 
C'est aussi simple que ça et ça permet de protéger le réseau
d'entreprise sans mettre en œuvre de solutions qui ELLES seraient
dangereuses pour la confiance que peuvent avoir les utilisateurs envers
le modèle X.509/TLS au niveau global. 

Au delà de l'aspect technique, je considère à titre personnel et éthique
que toute volonté d'interception (contrairement au blocage) n'a pour but
que d'espionner les salariés et les utilisateurs de manière
disproportionnée.
Et j'attends encore la preuve du contraire. 

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