Re: [FRnOG] [TECH] iptables me rendra fou

[Yanick Delarbre]

Hello,

Pour ma première contribution, voici quelques pistes:
* Sauf erreurs de ma part, pas vu la règle retour, au cas où, et voir si ça
tombe en marche:
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
* Activer les logs "martians", parfois ça donne des pistes:

sudo sysctl -w 'net.ipv4.conf.all.log_martians=1'

Pour les logs de netfilter, c'est devenu plus compliqué avec systemd
et ne fonctionne pas par défaut, comme avec journaltctl -k. Voici un
lien expliquant comment faire avec ulogd2:
https://blog.sleeplessbeastie.eu/2018/08/01/how-to-log-dropped-connections-from-iptables-firewall-using-netfilter-userspace-logging-daemon/

Cordialement,


Le ven. 25 janv. 2019 à 23:12, Faustin Lammler  a écrit :

>
> Dominique Rousseau ,
> 25/01/2019 - 17:15:30 (+0100):
>
> > Le Fri, Jan 25, 2019 at 05:07:14PM +0100, Kevin Thiou [
> kevinth...@gmail.com] a écrit:
> > > Bonjour, bonsoir,
> > >
> > > depuis quelques temps je me bats avec iptables pour un accès tout con
> mais
> > > que je ne parviens pas à faire fonctionner.
> > >
> > > ce que je souhaite :
> > >
> > > -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour
> >
> > Juste au cas, où... que dit : sysctl net.ipv4.ip_forward
> Oui, faut commencer par là.
>
> Et si tu as la possibilité de nous mettre le contenu de iptables-save
> histoire qu'on voit d'un seul coup d'œil la totalité des règles... Là il
> y a tellement de choses qui peuvent bloquer qu'il est difficile de
> t'aider.
>
> En général ce que je conseille :
> 1/ sysctl
> 2/ routage
> 3/ iptables
> 4/ un petit coup d'œil au schéma de fonctionnement de iptables permet en
> général de se poser les bonnes questions. Par exemple:
> http://www.system-rescue-cd.org/images/dport-routing-02.png
>
> Mes 2 pesos,
> Faust
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] iptables me rendra fou

[Faustin Lammler]

Dominique Rousseau ,
25/01/2019 - 17:15:30 (+0100):

> Le Fri, Jan 25, 2019 at 05:07:14PM +0100, Kevin Thiou [kevinth...@gmail.com] 
> a écrit:
> > Bonjour, bonsoir,
> > 
> > depuis quelques temps je me bats avec iptables pour un accès tout con mais
> > que je ne parviens pas à faire fonctionner.
> > 
> > ce que je souhaite :
> > 
> > -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour
> 
> Juste au cas, où... que dit : sysctl net.ipv4.ip_forward
Oui, faut commencer par là.

Et si tu as la possibilité de nous mettre le contenu de iptables-save
histoire qu'on voit d'un seul coup d'œil la totalité des règles... Là il
y a tellement de choses qui peuvent bloquer qu'il est difficile de
t'aider.

En général ce que je conseille :
1/ sysctl
2/ routage
3/ iptables
4/ un petit coup d'œil au schéma de fonctionnement de iptables permet en
général de se poser les bonnes questions. Par exemple:
http://www.system-rescue-cd.org/images/dport-routing-02.png

Mes 2 pesos,
Faust


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

Re: [FRnOG] [TECH] iptables me rendra fou

[julien soula]

On Fri, Jan 25, 2019 at 05:15:30PM +0100, Dominique Rousseau wrote:
> Le Fri, Jan 25, 2019 at 05:07:14PM +0100, Kevin Thiou [kevinth...@gmail.com] 
> a écrit:
> > Bonjour, bonsoir,
> > 
> > depuis quelques temps je me bats avec iptables pour un accès tout con mais
> > que je ne parviens pas à faire fonctionner.
> > 
> > ce que je souhaite :
> > 
> > -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour
> 
> Juste au cas, où... que dit : sysctl net.ipv4.ip_forward

j'allais poser la meme question !

Sinon, au nx des log, j'ai eu le tour hier : impossible de faire
marcher LOG. Je m'en suis sorti en utilisant NFLOG/ulogd (apres c'etait
un lxc, ceci explique p-e cela).

a+,
-- 
Julien
<< Vous n'avez rien a dire... Parlons-en! >>


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

Re: [FRnOG] [TECH] iptables me rendra fou

[Jugurta Yennek]

Bonsoir,

Les paquets retour ne sont pas source NATé par hasard et ne match donc 
pas ton ACL ?


Cdlt,

Jugurta


On 25/01/2019 17:07, Kevin Thiou wrote:

Bonjour, bonsoir,

depuis quelques temps je me bats avec iptables pour un accès tout con mais
que je ne parviens pas à faire fonctionner.

ce que je souhaite :

-A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour

je vois les paquets arriver sur l'interface de la machine iptables avec un
tcpdump :

tcpdump -i tun4 -n host 172.22.0.101 and host 192.168.0.10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun4, link-type RAW (Raw IP), capture size 65535 bytes
16:50:39.455349 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489719 ecr
0,nop,wscale 7], length 0
16:50:40.456679 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489970 ecr
0,nop,wscale 7], length 0

tous les prerouting (raw, mangle, nat) sont à accept.

  iptables -vL -t mangle -n
Chain PREROUTING (policy ACCEPT 25G packets, 23T bytes)
  pkts bytes target prot opt in out source
  destination
Chain INPUT (policy ACCEPT 8470M packets, 9683G bytes)
  pkts bytes target prot opt in out source
  destination
Chain FORWARD (policy ACCEPT 17G packets, 13T bytes)
  pkts bytes target prot opt in out source
  destination
Chain OUTPUT (policy ACCEPT 4864M packets, 1008G bytes)
  pkts bytes target prot opt in out source
  destination
Chain POSTROUTING (policy ACCEPT 22G packets, 14T bytes)
  pkts bytes target prot opt in out source
  destination

iptables -vL -t raw -n
Chain PREROUTING (policy ACCEPT 3640K packets, 2649M bytes)
  pkts bytes target prot opt in out source
  destination
Chain OUTPUT (policy ACCEPT 86560 packets, 31M bytes)
  pkts bytes target prot opt in out source
  destination

iptables -vL -t raw -n
Chain PREROUTING (policy ACCEPT 3650K packets, 2655M bytes)
  pkts bytes target prot opt in out source
  destination
Chain OUTPUT (policy ACCEPT 86795 packets, 31M bytes)
  pkts bytes target prot opt in out source
  destination

j'ai donc voulu tracer le paquet dans iptables vu que je n'arrive pas à
l'autoriser, j'ai donc mis les lignes suivantes :

iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j LOG --log-prefix HELLO
-A FORWARD -s 192.168.0.0/24 -d 172.22.0.0/24 -j LOG --log-prefix HELLO

et j'ai rien dans les logs.

Où peuvent donc passer ces paquets ?

Merci de votre aide.

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


--
Jugurta Yennek




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [FRnOG] [TECH] iptables me rendra fou

[Nathan Anthonypillai]

Salut,

Est-ce que la table de routage de la machine sur 192.168.0.0/24 est
correcte ?

Ce genre d'oubli m'arrive assez souvent...

Le ven. 25 janv. 2019 à 17:16, Dominique Rousseau  a
écrit :

> Le Fri, Jan 25, 2019 at 05:07:14PM +0100, Kevin Thiou [
> kevinth...@gmail.com] a écrit:
> > Bonjour, bonsoir,
> >
> > depuis quelques temps je me bats avec iptables pour un accès tout con
> mais
> > que je ne parviens pas à faire fonctionner.
> >
> > ce que je souhaite :
> >
> > -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour
>
> Juste au cas, où... que dit : sysctl net.ipv4.ip_forward
>
>
> --
> Dominique Rousseau
> Neuronnexion, Prestataire Internet & Intranet
> 6 rue des Hautes cornes - 8 Amiens
> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] iptables me rendra fou

[Dominique Rousseau]

Le Fri, Jan 25, 2019 at 05:07:14PM +0100, Kevin Thiou [kevinth...@gmail.com] a 
écrit:
> Bonjour, bonsoir,
> 
> depuis quelques temps je me bats avec iptables pour un accès tout con mais
> que je ne parviens pas à faire fonctionner.
> 
> ce que je souhaite :
> 
> -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour

Juste au cas, où... que dit : sysctl net.ipv4.ip_forward


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

Re: [FRnOG] [TECH] iptables me rendra fou

[Gaëtan Duchaussois]

Salut,

as tu vérifié que tu n'avais pas de soucis de paquets malformés ? J'ai
paumé quelques heures sur un problème similaire.

https://mastodon.xyz/@gduchaussois/100990651773639166 pour jouer avec ta
capture et tshark pour vérifier

Hope this helps

Gaëtan

Le 25/01/2019 à 17:07, Kevin Thiou a écrit :
> Bonjour, bonsoir,
>
> depuis quelques temps je me bats avec iptables pour un accès tout con mais
> que je ne parviens pas à faire fonctionner.
>
> ce que je souhaite :
>
> -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour
>
> je vois les paquets arriver sur l'interface de la machine iptables avec un
> tcpdump :
>
> tcpdump -i tun4 -n host 172.22.0.101 and host 192.168.0.10
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on tun4, link-type RAW (Raw IP), capture size 65535 bytes
> 16:50:39.455349 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
> 3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489719 ecr
> 0,nop,wscale 7], length 0
> 16:50:40.456679 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
> 3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489970 ecr
> 0,nop,wscale 7], length 0
>
> tous les prerouting (raw, mangle, nat) sont à accept.
>
>  iptables -vL -t mangle -n
> Chain PREROUTING (policy ACCEPT 25G packets, 23T bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain INPUT (policy ACCEPT 8470M packets, 9683G bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain FORWARD (policy ACCEPT 17G packets, 13T bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain OUTPUT (policy ACCEPT 4864M packets, 1008G bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain POSTROUTING (policy ACCEPT 22G packets, 14T bytes)
>  pkts bytes target prot opt in out source
>  destination
>
> iptables -vL -t raw -n
> Chain PREROUTING (policy ACCEPT 3640K packets, 2649M bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain OUTPUT (policy ACCEPT 86560 packets, 31M bytes)
>  pkts bytes target prot opt in out source
>  destination
>
> iptables -vL -t raw -n
> Chain PREROUTING (policy ACCEPT 3650K packets, 2655M bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain OUTPUT (policy ACCEPT 86795 packets, 31M bytes)
>  pkts bytes target prot opt in out source
>  destination
>
> j'ai donc voulu tracer le paquet dans iptables vu que je n'arrive pas à
> l'autoriser, j'ai donc mis les lignes suivantes :
>
> iptables -S FORWARD
> -P FORWARD DROP
> -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j LOG --log-prefix HELLO
> -A FORWARD -s 192.168.0.0/24 -d 172.22.0.0/24 -j LOG --log-prefix HELLO
>
> et j'ai rien dans les logs.
>
> Où peuvent donc passer ces paquets ?
>
> Merci de votre aide.
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] Re: iptables me rendra fou

[Kevin Thiou]

Au niveau routage on est bien aussi :

172.22.0.0/24 via 172.31.254.1 dev tun4
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.254

Le ven. 25 janv. 2019 à 17:07, Kevin Thiou  a écrit :

> Bonjour, bonsoir,
>
> depuis quelques temps je me bats avec iptables pour un accès tout con mais
> que je ne parviens pas à faire fonctionner.
>
> ce que je souhaite :
>
> -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour
>
> je vois les paquets arriver sur l'interface de la machine iptables avec un
> tcpdump :
>
> tcpdump -i tun4 -n host 172.22.0.101 and host 192.168.0.10
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on tun4, link-type RAW (Raw IP), capture size 65535 bytes
> 16:50:39.455349 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
> 3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489719 ecr
> 0,nop,wscale 7], length 0
> 16:50:40.456679 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
> 3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489970 ecr
> 0,nop,wscale 7], length 0
>
> tous les prerouting (raw, mangle, nat) sont à accept.
>
>  iptables -vL -t mangle -n
> Chain PREROUTING (policy ACCEPT 25G packets, 23T bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain INPUT (policy ACCEPT 8470M packets, 9683G bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain FORWARD (policy ACCEPT 17G packets, 13T bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain OUTPUT (policy ACCEPT 4864M packets, 1008G bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain POSTROUTING (policy ACCEPT 22G packets, 14T bytes)
>  pkts bytes target prot opt in out source
>  destination
>
> iptables -vL -t raw -n
> Chain PREROUTING (policy ACCEPT 3640K packets, 2649M bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain OUTPUT (policy ACCEPT 86560 packets, 31M bytes)
>  pkts bytes target prot opt in out source
>  destination
>
> iptables -vL -t raw -n
> Chain PREROUTING (policy ACCEPT 3650K packets, 2655M bytes)
>  pkts bytes target prot opt in out source
>  destination
> Chain OUTPUT (policy ACCEPT 86795 packets, 31M bytes)
>  pkts bytes target prot opt in out source
>  destination
>
> j'ai donc voulu tracer le paquet dans iptables vu que je n'arrive pas à
> l'autoriser, j'ai donc mis les lignes suivantes :
>
> iptables -S FORWARD
> -P FORWARD DROP
> -A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j LOG --log-prefix HELLO
> -A FORWARD -s 192.168.0.0/24 -d 172.22.0.0/24 -j LOG --log-prefix HELLO
>
> et j'ai rien dans les logs.
>
> Où peuvent donc passer ces paquets ?
>
> Merci de votre aide.
>

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

[FRnOG] [TECH] iptables me rendra fou

[Kevin Thiou]

Bonjour, bonsoir,

depuis quelques temps je me bats avec iptables pour un accès tout con mais
que je ne parviens pas à faire fonctionner.

ce que je souhaite :

-A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour

je vois les paquets arriver sur l'interface de la machine iptables avec un
tcpdump :

tcpdump -i tun4 -n host 172.22.0.101 and host 192.168.0.10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun4, link-type RAW (Raw IP), capture size 65535 bytes
16:50:39.455349 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489719 ecr
0,nop,wscale 7], length 0
16:50:40.456679 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489970 ecr
0,nop,wscale 7], length 0

tous les prerouting (raw, mangle, nat) sont à accept.

 iptables -vL -t mangle -n
Chain PREROUTING (policy ACCEPT 25G packets, 23T bytes)
 pkts bytes target prot opt in out source
 destination
Chain INPUT (policy ACCEPT 8470M packets, 9683G bytes)
 pkts bytes target prot opt in out source
 destination
Chain FORWARD (policy ACCEPT 17G packets, 13T bytes)
 pkts bytes target prot opt in out source
 destination
Chain OUTPUT (policy ACCEPT 4864M packets, 1008G bytes)
 pkts bytes target prot opt in out source
 destination
Chain POSTROUTING (policy ACCEPT 22G packets, 14T bytes)
 pkts bytes target prot opt in out source
 destination

iptables -vL -t raw -n
Chain PREROUTING (policy ACCEPT 3640K packets, 2649M bytes)
 pkts bytes target prot opt in out source
 destination
Chain OUTPUT (policy ACCEPT 86560 packets, 31M bytes)
 pkts bytes target prot opt in out source
 destination

iptables -vL -t raw -n
Chain PREROUTING (policy ACCEPT 3650K packets, 2655M bytes)
 pkts bytes target prot opt in out source
 destination
Chain OUTPUT (policy ACCEPT 86795 packets, 31M bytes)
 pkts bytes target prot opt in out source
 destination

j'ai donc voulu tracer le paquet dans iptables vu que je n'arrive pas à
l'autoriser, j'ai donc mis les lignes suivantes :

iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j LOG --log-prefix HELLO
-A FORWARD -s 192.168.0.0/24 -d 172.22.0.0/24 -j LOG --log-prefix HELLO

et j'ai rien dans les logs.

Où peuvent donc passer ces paquets ?

Merci de votre aide.

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

[FRnOG] [BIZ] Re: Don serveurs occasion

[Francois Prems]

Bonjour à tous,

j'ai reçu de très, très nombreuses réponses, je n'ai pas pu répondre à tout
le monde, je m'en excuse ici.

A part les premiers chanceux qui ont eu quelques équipements souhaités,
l'un d'entre vous m'a proposé de prendre le lot, j'ai sauté sur l'occasion.

Bonne fin de Dredi

François



Le jeu. 24 janv. 2019 à 15:03, Francois Prems  a
écrit :

> Bonjour à tous,
>
> Suite à un gros ménage en DC et stocks, on cherche à se débarrasser de pas
> mal de matériel qui peut peut-être intéresser du monde.
>
> C'est cadeau, faut juste venir chercher. Préférence pour qqun qui veut
> tout d'un coup.
>
> J'ai une liste exhaustive que je peux fournir en MP, voici un résumé
> représentatif :
>
> - ~50 Serveurs (sans hdd et souvent sans RAM) Dell PE
> 1950/1850/2850/860/R200
> - ~10 Cisco Catalyst 2950/3500/3750, quelques Dell Power Connect
> - Cisco 806/877/892/1721
> - Foundry networks BigIron RX-4
> - Quelques petits FW:  NetAsk NA-F25 / Fortigate 110C, Juniper SSG5
> et plein d'autre petits trucs toujours autour du réseau.
>
> Espérant que ça intéresse quelqu'un utilement...
>
> François
>
>

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

RE: [FRnOG] [MISC] Livre blanc sur le traitement des contenus pedo/terro et protection des professionnels

[Benjamin BILLON]

Tiens bah j'ai justement le nez dans le code des postes et des communications 
électroniques (elle est pas belle ma vie ?), notamment section 3, "Protection 
de la vie privée des utilisateurs de réseaux et services de communications 
électroniques", article L34-1, alinéa 3, et ça dit "il peut être différé pour 
une durée maximale d'un an aux opérations tendant à effacer ou à rendre 
anonymes certaines catégories de données techniques"
https://www.legifrance.gouv.fr/affichCode.do;jsessionid=86E5E8E1B6FD646EB8BFE6941296B8BF.tplgfr35s_2?idSectionTA=LEGISCTA06165910=LEGITEXT06070987=20190125

Du coup ma compréhension c'est que pour pouvoir répondre à ces demandes  ("Pour 
les besoins de la recherche, de la constatation et de la poursuite des 
infractions pénales" etc. voir passage en question), les opérateurs peuvent / 
feraient bien de garder ces données un an de plus que ce dont ils ont besoin 
pour leurs propres besoins.

Je ne suis pas juriste et pas vraiment sur ce secteur, seulement curieux.

> Si j'ai bien compris, tout opérateur réseau (qu'il soit FAI ou hébergeur) 
> doit mettre en place ce type de cellule. Mais c'est très lourd pour certaines 
> structures, je pense à des hébergeur en EURL / SASU, et sans employés.
"ce type" de cellule c'est avoir un service abuse qui soit également formé / 
sache suivre un process pour que la remontée parviennent aux autorités 
compétentes.
Tout opérateur réseau est déjà avoir un service abuse, ne serait-ce que 
quelqu'un qui traite les mails envoyés à abuse@ (exemple repris dans le 
document), donc la marche ne devrait pas être super haute.

Ca fait partie du métier de savoir que ça existe, et ce qui est demandé là est 
de savoir comment réagir.


--
Benjamin

From: frnog-requ...@frnog.org  On Behalf Of Wallace
Sent: vendredi 25 janvier 2019 15:29
To: frnog@frnog.org
Subject: Re: [FRnOG] [MISC] Livre blanc sur le traitement des contenus 
pedo/terro et protection des professionnels


Salut,

De mon point de vue, c'est ton client qui est responsable de ses données et des 
usages faits par ses applications y compris en cas d'utilisation illicite. Ton 
rôle c'est de rapidement bloquer la diffusion des éléments reprochés dans ton 
service d'infogérance.

Lui sur ses applications doit avoir des mentions légales à jour avec notamment 
le responsable "éditorial" du site ou de l'application. Il doit aussi préciser 
l'hébergeur. S'il met un hosteur en hébergeur, la requête qui va arriver va 
consister en une suspension du service par le dit hosteur car il n'a pas la 
main sur le système. S'il te met toi c'est toi qui va recevoir la requête et tu 
prendras les dispositions pour bloquer la propagation du contenu illicite sans 
couper sa production si c'est possible, garder toutes les traces nécessaires 
pour une expertise pour collaborer avec la justice.

Des requêtes judiciaires j'ai du en recevoir une quinzaine dans toute ma 
carrière, à chaque fois c'était un gars qui s'est suicidé ou homicide, les 
enquêteurs vont chez lui voient qu'il a un tartanpionbox, demande à l'opérateur 
quelles sont les IP auxquelles il s'est connecté depuis 1, 2, 3 mois. Et ils 
vont demander à chaque hébergeur qui possèdent ces IP de fournir les logs de 
consultation des sites / application / mail / ...
Y a celles qui arrivent en toquant à la porte avec uniformes (là ok c'est 
carré), y a celles qui arrivent par téléphone (j'envoie balader ça peut être du 
social engineering), à une époque par fax (pareil on attendait une meilleure 
authentification de la demande), on a reçu une fois un mail mais les headers 
étaient louches et pas de dkim ( pas de réponse et on attend un autre moyen de 
communication) et une fois c'était un ordre de référé du tribunal donc là ça 
sonne aussi à la porte.

D'expérience les délais peuvent être long et il est souvent arriver qu'on nous 
demande par exemple aujourd'hui les connexions pour telle IP pour les mois de 
décembre 2017, janvier, février 2018. Légalement et techniquement beaucoup 
configurent les logs sur 365j mais dans leur idée c'est pas glissant, c'est un 
an en arrière. Donc considérant 25 janvier 2019 la demande, ils trouvent pas 
normal que tu n'es pas de log du 1er au 24 janvier 2018. Et supplierons pour 
que tu donnes aussi décembre 2017.

C'est pour cela que dans les faits vu que ça te coûte du temps et que t'as pas 
envie d'être embêté pour ça, on garde 2 ans de logs glissants. On l'a déclaré 
comme tel dans les données stockées pour le RGPD. Tout le monde est content et 
si ça peut aider...
Le 24/01/2019 à 14:33, Richard DEMONGEOT a écrit :
Hello Alexandre,

Si j'ai bien compris, tout opérateur réseau (qu'il soit FAI ou hébergeur) doit 
mettre en place ce type de cellule. Mais c'est très lourd pour certaines 
structures, je pense à des hébergeur en EURL / SASU, et sans employés.

Quelles sont tes préconisation concernant cela?


Par ailleurs, dans mon cas précis, j'ai quelques 

Re: [FRnOG] [MISC] Livre blanc sur le traitement des contenus pedo/terro et protection des professionnels

[Wallace]

Salut,

De mon point de vue, c'est ton client qui est responsable de ses données
et des usages faits par ses applications y compris en cas d'utilisation
illicite. Ton rôle c'est de rapidement bloquer la diffusion des éléments
reprochés dans ton service d'infogérance.

Lui sur ses applications doit avoir des mentions légales à jour avec
notamment le responsable "éditorial" du site ou de l'application. Il
doit aussi préciser l'hébergeur. S'il met un hosteur en hébergeur, la
requête qui va arriver va consister en une suspension du service par le
dit hosteur car il n'a pas la main sur le système. S'il te met toi c'est
toi qui va recevoir la requête et tu prendras les dispositions pour
bloquer la propagation du contenu illicite sans couper sa production si
c'est possible, garder toutes les traces nécessaires pour une expertise
pour collaborer avec la justice.

Des requêtes judiciaires j'ai du en recevoir une quinzaine dans toute ma
carrière, à chaque fois c'était un gars qui s'est suicidé ou homicide,
les enquêteurs vont chez lui voient qu'il a un tartanpionbox, demande à
l'opérateur quelles sont les IP auxquelles il s'est connecté depuis 1,
2, 3 mois. Et ils vont demander à chaque hébergeur qui possèdent ces IP
de fournir les logs de consultation des sites / application / mail / ...
Y a celles qui arrivent en toquant à la porte avec uniformes (là ok
c'est carré), y a celles qui arrivent par téléphone (j'envoie balader ça
peut être du social engineering), à une époque par fax (pareil on
attendait une meilleure authentification de la demande), on a reçu une
fois un mail mais les headers étaient louches et pas de dkim ( pas de
réponse et on attend un autre moyen de communication) et une fois
c'était un ordre de référé du tribunal donc là ça sonne aussi à la porte.

D'expérience les délais peuvent être long et il est souvent arriver
qu'on nous demande par exemple aujourd'hui les connexions pour telle IP
pour les mois de décembre 2017, janvier, février 2018. Légalement et
techniquement beaucoup configurent les logs sur 365j mais dans leur idée
c'est pas glissant, c'est un an en arrière. Donc considérant 25 janvier
2019 la demande, ils trouvent pas normal que tu n'es pas de log du 1er
au 24 janvier 2018. Et supplierons pour que tu donnes aussi décembre 2017.

C'est pour cela que dans les faits vu que ça te coûte du temps et que
t'as pas envie d'être embêté pour ça, on garde 2 ans de logs glissants.
On l'a déclaré comme tel dans les données stockées pour le RGPD. Tout le
monde est content et si ça peut aider...

Le 24/01/2019 à 14:33, Richard DEMONGEOT a écrit :
> Hello Alexandre,
>
> Si j'ai bien compris, tout opérateur réseau (qu'il soit FAI ou
> hébergeur) doit mettre en place ce type de cellule. Mais c'est très
> lourd pour certaines structures, je pense à des hébergeur en EURL /
> SASU, et sans employés.
>
> Quelles sont tes préconisation concernant cela?
>
>
> Par ailleurs, dans mon cas précis, j'ai quelques clients en
> infogérance. Je ne gère pas le hosting, mais je gère le serveur. Ai-je
> à leur demander de mettre un lien pour signaler le traitement douteux
> / illicite? Est-ce à moi de le traiter? au client? ou à l'hébergeur
> (online, ovh, 1&1, ou autre) ?
>
> Cordialement,
>
> Le 2019-01-23 18:17, Alexandre Archambault a écrit :
>> A l'occasion de l'édition 2019 du FIC, le guide de lutte contre les
>> contenus pédos a été mis à jour, pour devenir un livre blanc élargi à la
>> problématique des contenus terros et du nécessaire accompagnement des
>> professionnels, qu'ils soient FAIs, hébergeurs, registrars, fournisseurs
>> de services (plateformes, espaces communautaires, réseaux sociaux…)
>>
>> Outre le rappel de quelques points de droit, l’objectif est de définir
>> un socle commun de bonnes pratiques professionnelles en matière de
>> traitement opérationnel des contenus choquants et potentiellement
>> illicites qui mettent en jeu la sécurité physique et l'équilibre
>> psychologique des professionnels.
>>
>> C'est consultable ici =>
>> .
>>
>>
>> Toutes remarques (constructives hein, on est pas #dredi) bienvenues !
>>
>> Alec,
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] [MISC] Proxy + interception SSL = RGPD?

[Thierry Chich]

Le 25/01/2019 à 09:26, Maxime Jouveaux a écrit :

Avant de poser cette question déjà consulter les documents de la CNIL et de
l'ANSSI, et aucun ne parle de l'implication RGPD.

C'est pour cela que l'a RGPD rend la situation très ambigu.


Pour moi, la RGPD ne change pas fondamentalement les principes de 
protection de la vie privée, par rapport à la loi informatique et 
liberté. Elle change le montant des sanctions et elle supprime le 
dispositif de déclaration pour le remplacer par le maintien de listes.


Sur ce problème particulier, je serais surpris que la RGPD change 
radicalement les choses.


Thierry


Pour les droits du travail, en tant de pause, un utilisateur accédant a
internet peux l'utiliser a des fin personnelles du moment que c'est "bon
enfant".
L'entreprise se réserve le droit de bloquer en cas d’abus.
Mais je ne suis pas la pour interdire l’accès a l'information, je préfère
juste le contrôler.

MJX

Le ven. 25 janv. 2019 à 09:18, Thierry Chich 
a écrit :


La réponse de la CNIL (qui ne concerne pas la RGPD, mais les principes
n'ont pas tant changé que ça):

https://www.cnil.fr/fr/analyse-de-flux-https-bonnes-pratiques-et-questions

J'adore, à la fin,  la question en suspens. La CNIL ne peut pas
s'engager sur le fait qu'il y ait un risque juridique à le faire.

Cette page pointe aussi sur une doc de l'ANSSI qui indique un bon nombre
de précaution à prendre si on s'y lance. En attendant qu'on ne puisse
plus le faire du tout.

Thierry

Le 25/01/2019 à 08:55, Maxime Jouveaux a écrit :

Bonjour la liste,


Petite question RGPD, je gère actuellement un proxy squid et pour

renforcer

la sécurité je regardais pour faire de l'interception SSL(HTTPS).

Actuellement, il logue tout le HTTP et que la première demande en HTTPS,
mais sans collecter de données.


Mais je sais que l’interception SSL (HTTPS) peut être illégale vis-à-vis
des droits et liberté de chacun, car le proxy verra toutes les

informations

HTTPS en clair, ce qui représente une attaque informatique appelée « Man

on

the middle ».

Étant donné que l’accès de chaque utilisateur d’internet n’est pas

limité,

il peut donc aller sur le site de sa banque ou sur un site médical et
consulter des informations personnelles durant sa pause (Autorisée par le
code du travail).

Le hic de l’interception SSL(HTTPS) est que le proxy trace tout en clair
(exemple : les codes personnels, code carte bancaire etc…).

Ce qui est *une violation du RGPD *de l’employé.



Est-ce que je me trompe?


Note: j'ai une charte informatique en place qui informe les employés que
j'ai un proxy.


Merci à vous.


Maxime JOUVEAUX

---
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] Proxy + interception SSL = RGPD?

[Dominique Rousseau]

Le Fri, Jan 25, 2019 at 10:01:19AM +0100, David Ponzone 
[david.ponz...@gmail.com] a écrit:
> Et le moindre site de e-Commerce qui demande un numéro de CB pour payer non ?
> 

Il y a relativement peu de sites de e-commerce où tu donnes ton numéro
de CB directement chez eux (bon, y'a Amazon qui représente 50% du
business ;-), la plupart t'envoient sur un site correspondant à leur
banque.

-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

Re: [FRnOG] [MISC] Proxy + interception SSL = RGPD?

[Kavé Salamatian]

J’aime beaucoup c’est avis envoyé d’un mail ProtonMail :-). 

Kv

> Le 25 janv. 2019 à 10:10, EdenloGey  a écrit :
> 
> Hello,
> 
> Étant en plein projet sur ce type de problématique, l'interception en soi est 
> toléré par la GDPR si tu maintiens une liste de non déchiffrement de 
> certaines catégories "à fort risque de présence de données personnelles" 
> (santé, bancaire, étatique ...)
> 
> C'est assez "facile" si tu as un filtrage proxy fin. Si ton proxy est ouvert 
> de maniere large, c'est assez fastidieux à maintenir.
> 
> Après il y a toujours la proportionnalité difficile à doser d'un usage 
> "correct" et "proportionné" d'un utilisateur de son accès internet 
> professionnel.
> Ça se regule plus ou moins en interne : période blanche (style pause du 
> midi), PC sandbox pour la navigation privée ...
> 
> Envoyé depuis ProtonMail mobile
> 
> Envoyé depuis ProtonMail mobile
> 
>  Message d'origine 
> On 25 janv. 2019 à 08:55, Maxime Jouveaux a écrit :
> 
>> Bonjour la liste,
>> 
>> Petite question RGPD, je gère actuellement un proxy squid et pour renforcer
>> la sécurité je regardais pour faire de l'interception SSL(HTTPS).
>> 
>> Actuellement, il logue tout le HTTP et que la première demande en HTTPS,
>> mais sans collecter de données.
>> 
>> Mais je sais que l’interception SSL (HTTPS) peut être illégale vis-à-vis
>> des droits et liberté de chacun, car le proxy verra toutes les informations
>> HTTPS en clair, ce qui représente une attaque informatique appelée « Man on
>> the middle ».
>> 
>> Étant donné que l’accès de chaque utilisateur d’internet n’est pas limité,
>> il peut donc aller sur le site de sa banque ou sur un site médical et
>> consulter des informations personnelles durant sa pause (Autorisée par le
>> code du travail).
>> 
>> Le hic de l’interception SSL(HTTPS) est que le proxy trace tout en clair
>> (exemple : les codes personnels, code carte bancaire etc…).
>> 
>> Ce qui est *une violation du RGPD *de l’employé.
>> 
>> Est-ce que je me trompe?
>> 
>> Note: j'ai une charte informatique en place qui informe les employés que
>> j'ai un proxy.
>> 
>> Merci à vous.
>> 
>> Maxime JOUVEAUX
>> 
>> ---
>> 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] Proxy + interception SSL = RGPD?

[Stéphane Rivière]

Petite question RGPD, je gère actuellement un proxy squid et pour renforcer
la sécurité je regardais pour faire de l'interception SSL(HTTPS).


Pas juriste mais quelque expérience à faire confirmer par un homme de 
l'art. Tout est question de proportionnalité et de justification du procédé.


Si t'es dans le SD, une règle peut être qu'aucun poste n'a internet sauf 
celui qui est dans la pièce contrôlée. C'est proportionnel et inattaquable.


Si t'es dans le CD, une règle peut être que l'internet disponible soit 
surveillé. C'est proportionnel et inattaquable.


Si t'es dans la vente de rouleaux sopalin, ça sera considéré comme 
disproportionné, compte tenu que le seul secret envisageable (et donc 
justifiant la surveillance) serait d'ordre commercial (concurrence 
déloyale interne, etc...). La proportionnalité (entre les moyens et le 
risque) n'est pas respectée, ce n'est donc pas justifié, c'est un abus 
sanctionnable.


Si t'es entre les deux et que ce contrôle est proportionnel et donc 
justifiable, après consultation d'un juriste, ce dernier te conseillera 
peut-être, par exemple, pour lever toute ambiguïté, d'obtenir un accord 
d'entreprise, signé par tous les salariés concernés :


- Informant précisément les salariés des traitements de surveillance 
exercés sur les stations de travail (et les risques encourus en termes 
de divulgation des données personnelles en cas de non respect de 
l'accord) - avec référence cnil, anssi, rgpd, duschmoll et tuttiquanti ;


- Mettant en libre service des stations non surveillées en nombre 
suffisant pour les besoins des salariés en pause ;


- Restreignant de façon stricte (c'est plus joli que interdisant) tout 
usage personnel des stations de travail pour éviter toute divulgation de 
données personnelles ;


- Il devrait même y avoir un article 'sanctions' pour les contrevenants, 
avec aggravation si récidive, histoire de border le truc face à un 
tribunal. Une interdiction sans sanction n'est pas crédible.


L'objectif et le dispositif sont proportionnels et justifiés, le 
personnel est précisément informé des droits, obligations et sanctions, 
il dispose de solutions pour la pause, il a signé. Avec un juriste 
spécialisé, ça devrait prévenir pas mal de risques.


Je serais toi, je regarderais déjà la jurisprudence, ça donne de 
nombreuses idées...


PS

Exercer un contrôle avec non déchiffrement des sites "à données 
personnelles" peut être fastidieux, consommateur de ressources et/ou 
forcément laisser des trous dans le fromage, donc présenter un risque 
juridique. Ca peut (va) craindre financièrement en cas de conflit.


--
Stéphane Rivière
Ile d'Oléron - France


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

Re: [FRnOG] [MISC] Proxy + interception SSL = RGPD?

[EdenloGey]

Hello,

Étant en plein projet sur ce type de problématique, l'interception en soi est 
toléré par la GDPR si tu maintiens une liste de non déchiffrement de certaines 
catégories "à fort risque de présence de données personnelles" (santé, 
bancaire, étatique ...)

C'est assez "facile" si tu as un filtrage proxy fin. Si ton proxy est ouvert de 
maniere large, c'est assez fastidieux à maintenir.

Après il y a toujours la proportionnalité difficile à doser d'un usage 
"correct" et "proportionné" d'un utilisateur de son accès internet 
professionnel.
Ça se regule plus ou moins en interne : période blanche (style pause du midi), 
PC sandbox pour la navigation privée ...

Envoyé depuis ProtonMail mobile

Envoyé depuis ProtonMail mobile

 Message d'origine 
On 25 janv. 2019 à 08:55, Maxime Jouveaux a écrit :

> Bonjour la liste,
>
> Petite question RGPD, je gère actuellement un proxy squid et pour renforcer
> la sécurité je regardais pour faire de l'interception SSL(HTTPS).
>
> Actuellement, il logue tout le HTTP et que la première demande en HTTPS,
> mais sans collecter de données.
>
> Mais je sais que l’interception SSL (HTTPS) peut être illégale vis-à-vis
> des droits et liberté de chacun, car le proxy verra toutes les informations
> HTTPS en clair, ce qui représente une attaque informatique appelée « Man on
> the middle ».
>
> Étant donné que l’accès de chaque utilisateur d’internet n’est pas limité,
> il peut donc aller sur le site de sa banque ou sur un site médical et
> consulter des informations personnelles durant sa pause (Autorisée par le
> code du travail).
>
> Le hic de l’interception SSL(HTTPS) est que le proxy trace tout en clair
> (exemple : les codes personnels, code carte bancaire etc…).
>
> Ce qui est *une violation du RGPD *de l’employé.
>
> Est-ce que je me trompe?
>
> Note: j'ai une charte informatique en place qui informe les employés que
> j'ai un proxy.
>
> Merci à vous.
>
> Maxime JOUVEAUX
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Proxy + interception SSL = RGPD?

[David Ponzone]

Et le moindre site de e-Commerce qui demande un numéro de CB pour payer non ?

> Le 25 janv. 2019 à 09:57, Dominique Rousseau  a écrit :
> 
> Le Fri, Jan 25, 2019 at 08:55:13AM +0100, Maxime Jouveaux 
> [maxime.jouve...@gmail.com] a écrit:
> [...]
>> 
>> Le hic de l???interception SSL(HTTPS) est que le proxy trace tout en clair
>> (exemple : les codes personnels, code carte bancaire etc???).
> 
> Je ne connais pas precisement les implications au niveau RGPD, mais les
> recommandations de l'ANSSI sont de ne pas déchiffrer certaines
> catégories de contenus ( page 15 ) :
> 
> https://www.ssi.gouv.fr/administration/guide/recommandations-de-securite-concernant-lanalyse-des-flux-https/
> 
> La liste en sera forcément ch*ante à maintenir, mais tout ce qui est
> bancaire, assurance, santé est au minimum à exclure, je pense.
> 
> 
> -- 
> Dominique Rousseau 
> Neuronnexion, Prestataire Internet & Intranet
> 6 rue des Hautes cornes - 8 Amiens
> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] Proxy + interception SSL = RGPD?

[Dominique Rousseau]

Le Fri, Jan 25, 2019 at 08:55:13AM +0100, Maxime Jouveaux 
[maxime.jouve...@gmail.com] a écrit:
[...]
> 
> Le hic de l???interception SSL(HTTPS) est que le proxy trace tout en clair
> (exemple : les codes personnels, code carte bancaire etc???).

Je ne connais pas precisement les implications au niveau RGPD, mais les
recommandations de l'ANSSI sont de ne pas déchiffrer certaines
catégories de contenus ( page 15 ) :

https://www.ssi.gouv.fr/administration/guide/recommandations-de-securite-concernant-lanalyse-des-flux-https/

La liste en sera forcément ch*ante à maintenir, mais tout ce qui est
bancaire, assurance, santé est au minimum à exclure, je pense.


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

Re: [FRnOG] [MISC] Proxy + interception SSL = RGPD?

[Maxime Jouveaux]

Avant de poser cette question déjà consulter les documents de la CNIL et de
l'ANSSI, et aucun ne parle de l'implication RGPD.

C'est pour cela que l'a RGPD rend la situation très ambigu.

Pour les droits du travail, en tant de pause, un utilisateur accédant a
internet peux l'utiliser a des fin personnelles du moment que c'est "bon
enfant".
L'entreprise se réserve le droit de bloquer en cas d’abus.
Mais je ne suis pas la pour interdire l’accès a l'information, je préfère
juste le contrôler.

MJX

Le ven. 25 janv. 2019 à 09:18, Thierry Chich 
a écrit :

> La réponse de la CNIL (qui ne concerne pas la RGPD, mais les principes
> n'ont pas tant changé que ça):
>
> https://www.cnil.fr/fr/analyse-de-flux-https-bonnes-pratiques-et-questions
>
> J'adore, à la fin,  la question en suspens. La CNIL ne peut pas
> s'engager sur le fait qu'il y ait un risque juridique à le faire.
>
> Cette page pointe aussi sur une doc de l'ANSSI qui indique un bon nombre
> de précaution à prendre si on s'y lance. En attendant qu'on ne puisse
> plus le faire du tout.
>
> Thierry
>
> Le 25/01/2019 à 08:55, Maxime Jouveaux a écrit :
> > Bonjour la liste,
> >
> >
> > Petite question RGPD, je gère actuellement un proxy squid et pour
> renforcer
> > la sécurité je regardais pour faire de l'interception SSL(HTTPS).
> >
> > Actuellement, il logue tout le HTTP et que la première demande en HTTPS,
> > mais sans collecter de données.
> >
> >
> > Mais je sais que l’interception SSL (HTTPS) peut être illégale vis-à-vis
> > des droits et liberté de chacun, car le proxy verra toutes les
> informations
> > HTTPS en clair, ce qui représente une attaque informatique appelée « Man
> on
> > the middle ».
> >
> > Étant donné que l’accès de chaque utilisateur d’internet n’est pas
> limité,
> > il peut donc aller sur le site de sa banque ou sur un site médical et
> > consulter des informations personnelles durant sa pause (Autorisée par le
> > code du travail).
> >
> > Le hic de l’interception SSL(HTTPS) est que le proxy trace tout en clair
> > (exemple : les codes personnels, code carte bancaire etc…).
> >
> > Ce qui est *une violation du RGPD *de l’employé.
> >
> >
> >
> > Est-ce que je me trompe?
> >
> >
> > Note: j'ai une charte informatique en place qui informe les employés que
> > j'ai un proxy.
> >
> >
> > Merci à vous.
> >
> >
> > Maxime JOUVEAUX
> >
> > ---
> > 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] Proxy + interception SSL = RGPD?

[Thierry Chich]

La réponse de la CNIL (qui ne concerne pas la RGPD, mais les principes 
n'ont pas tant changé que ça):


https://www.cnil.fr/fr/analyse-de-flux-https-bonnes-pratiques-et-questions

J'adore, à la fin,  la question en suspens. La CNIL ne peut pas 
s'engager sur le fait qu'il y ait un risque juridique à le faire.


Cette page pointe aussi sur une doc de l'ANSSI qui indique un bon nombre 
de précaution à prendre si on s'y lance. En attendant qu'on ne puisse 
plus le faire du tout.


Thierry

Le 25/01/2019 à 08:55, Maxime Jouveaux a écrit :

Bonjour la liste,


Petite question RGPD, je gère actuellement un proxy squid et pour renforcer
la sécurité je regardais pour faire de l'interception SSL(HTTPS).

Actuellement, il logue tout le HTTP et que la première demande en HTTPS,
mais sans collecter de données.


Mais je sais que l’interception SSL (HTTPS) peut être illégale vis-à-vis
des droits et liberté de chacun, car le proxy verra toutes les informations
HTTPS en clair, ce qui représente une attaque informatique appelée « Man on
the middle ».

Étant donné que l’accès de chaque utilisateur d’internet n’est pas limité,
il peut donc aller sur le site de sa banque ou sur un site médical et
consulter des informations personnelles durant sa pause (Autorisée par le
code du travail).

Le hic de l’interception SSL(HTTPS) est que le proxy trace tout en clair
(exemple : les codes personnels, code carte bancaire etc…).

Ce qui est *une violation du RGPD *de l’employé.



Est-ce que je me trompe?


Note: j'ai une charte informatique en place qui informe les employés que
j'ai un proxy.


Merci à vous.


Maxime JOUVEAUX

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

--




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

Re: [FRnOG] [MISC] Proxy + interception SSL = RGPD?

[David Ponzone]

A part désactiver ton interception pendant les heures de pause, je ne vois pas 
trop ce que tu peux faire d’autre.

Quand tu dis que l’usage à fin personnel pendant la pause de l’accès Internet 
de l’employeur est autorisé par le Code du Travail, c’est un truc que tu as 
vérifié ou c’est un truc que tu imagines ?
Parce que je vois mal comment le Code du Travail pourrait imposer ça.
L’employeur peut de toute façon très bien s’ en sortir en mettant à disposition 
un PC sur lequel l’usage privé est autorisé pendant les pauses.

Par contre, si tu interceptes avec un proxy, tu as une obligation de 
déclaration CNIL à priori.

https://www.juritravail.com/Actualite/internet-travail/Id/1240 

https://www.journaldunet.fr/management/guide-du-management/1201587-internet-au-travail-ce-qu-il-faut-savoir/
 

Et surtout:
https://www.murielle-cahen.com/publications/internet-travail.asp 


Ca m’a l’air délicat comme problème, mais il y a un juriste de haut niveau sur 
la liste, il aura peut-être un moment pour nous éclairer.


> Le 25 janv. 2019 à 08:55, Maxime Jouveaux  a écrit 
> :
> 
> Bonjour la liste,
> 
> 
> Petite question RGPD, je gère actuellement un proxy squid et pour renforcer
> la sécurité je regardais pour faire de l'interception SSL(HTTPS).
> 
> Actuellement, il logue tout le HTTP et que la première demande en HTTPS,
> mais sans collecter de données.
> 
> 
> Mais je sais que l’interception SSL (HTTPS) peut être illégale vis-à-vis
> des droits et liberté de chacun, car le proxy verra toutes les informations
> HTTPS en clair, ce qui représente une attaque informatique appelée « Man on
> the middle ».
> 
> Étant donné que l’accès de chaque utilisateur d’internet n’est pas limité,
> il peut donc aller sur le site de sa banque ou sur un site médical et
> consulter des informations personnelles durant sa pause (Autorisée par le
> code du travail).
> 
> Le hic de l’interception SSL(HTTPS) est que le proxy trace tout en clair
> (exemple : les codes personnels, code carte bancaire etc…).
> 
> Ce qui est *une violation du RGPD *de l’employé.
> 
> 
> 
> Est-ce que je me trompe?
> 
> 
> Note: j'ai une charte informatique en place qui informe les employés que
> j'ai un proxy.
> 
> 
> Merci à vous.
> 
> 
> Maxime JOUVEAUX
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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