 |
 |
Hi Andy, Oliver, all, I totally understand the concerns about encrypting the DNs. What about considering a deployment scheme where the UDP packets remain in the site and just the collected information is forwarded to brokers through secure channels? One of the points that may be improved in the current scheme is the fact that UDP packets have to be sent to distant servers. The fact that very few get lost in the WAN was just a nice surprise. As far as I can remember, also the original XrdMon scheme was keeping them in the site. This would require a more careful deployment of GLED as a service, which in my view is a desirable thing. Cheers Fabrizio On 09/02/2014 09:08 AM, Andrew Hanushevsky wrote: > Hi Oliver, > > Totally understandable. Encrypting the dDN would require a substantial infrastructure addition to maintain encryption keys. So, > it's easier to just not transmit the DN (a config option). The dashboard doesn't care but other people would like to know who is > causing problems (if any). Typical case of conflicting requirements. As an aside, wouldn't unencrypted DN's be available via the > public key portion of the infrastructure anyway? I suppose that doesn't matter if this is a specific privacy issue but then we > shouldn't be transmitting DN's in an operational context in the first place (encrypted or not). > > Andy > > On Mon, 1 Sep 2014, Oliver Keeble wrote: > >> From my discussion with Romain, transmission of the DN is fine as long as it's encrypted. >> >> Oliver. >> >> On 01/09/14 15:20, Julia Andreeva wrote: >>> >>> We do need user DN for monitoring and popularity applications. >>> >>> Cheers >>> >>> Julia >>> >>> >>> On Mon, 1 Sep 2014, Lukasz Janyst wrote: >>> >>>> AFAIK, most of dCache sites use xrootd proxies, so they are likely >>>> affected, so is EOS, but fstreams have not been configured for Castor. >>>> >>>> Is it sufficient that we encrypt the fstreams or do you want us not >>>> to send the DNs at all? >>>> >>>> Cheers, >>>> Lukasz >>>> >>>> On 09/01/2014 03:04 PM, Oliver Keeble wrote: >>>>> >>>>> This is not a DPM issue - it's the xrootd fstream which sends out this >>>>> information so standard xrootd installations will also be affected. >>>>> dCache may be different, I don't know if they implemented this >>>>> themselves or not. >>>>> >>>>> On 01/09/14 13:48, Andrea Manzi wrote: >>>>>> Hi Romain, >>>>>> do you know if the problem affects only DPM-xrootd or all xrootd >>>>>> deployments are affected ? >>>>>> thanks >>>>>> Andrea >>>>>> >>>>>> On 01 Sep 2014, at 11:41, Romain Wartel <[log in to unmask] >>>>>> <mailto:[log in to unmask]>> wrote: >>>>>> >>>>>>> Domenico, Matevz, >>>>>>> >>>>>>> Just to close the loop; Please find the information below. The EGI >>>>>>> CSIRT, as well as WLCG operations coordination are coordinating this >>>>>>> issue. >>>>>>> I expect you will be contacted "officially" by the EGI security >>>>>>> vulnerability group (SVG) with an advisory before wednesday with all >>>>>>> the details. >>>>>>> >>>>>>> Then we would need you to look into this asap and report back on what >>>>>>> corrective actions can be taken. >>>>>>> >>>>>>> Cheers, >>>>>>> Romain. >>>>>>> >>>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>>> *From: *Romain Wartel <[log in to unmask] >>>>>>>> <mailto:[log in to unmask]>> >>>>>>>> *Subject: **xrootd - user DN information* >>>>>>>> *Date: *1 Sep 2014 10:46:21 GMT+2 >>>>>>>> *To: *Maria Alandes Pradillo <[log in to unmask] >>>>>>>> <mailto:[log in to unmask]>>, Oliver Keeble >>>>>>>> <[log in to unmask] <mailto:[log in to unmask]>> >>>>>>>> >>>>>>>> Maria, Oliver, >>>>>>>> >>>>>>>> Here is the information I have regarding the user DN usage for >>>>>>>> monitoring in xrootd. >>>>>>>> >>>>>>>> I think the correct Indico link is >>>>>>>> https://indico.cern.ch/event/197803/session/0/contribution/10/material/slides/0.pdf >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Our policy on this topic is at >>>>>>>> https://edms.cern.ch/file/855382/5/JobAccountingDataPolicy-v1.0.pdf >>>>>>>> >>>>>>>> "Each site is responsible for sending its accounting records on a >>>>>>>> regular basis, e.g. daily, with at >>>>>>>> least user DNs encrypted in transport, to a central data base defined >>>>>>>> by the Grid. This database is >>>>>>>> located at an Accounting Data Centre (ADC). The location of the ADC >>>>>>>> needs to be chosen >>>>>>>> carefully according to data privacy laws. " >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Romain. >>>>>>>> >>>>>>>> Begin forwarded message: >>>>>>>> >>>>>>>>> *From: *Sven Gabriel <[log in to unmask] <mailto:[log in to unmask]>> >>>>>>>>> *Subject: **[Irtf] more atlas fun* >>>>>>>>> *Date: *1 Sep 2014 08:14:12 GMT+2 >>>>>>>>> *To: *IRTF <[log in to unmask] <mailto:[log in to unmask]>>, David >>>>>>>>> Groep <[log in to unmask] <mailto:[log in to unmask]>> >>>>>>>>> *Reply-To: *Incident Response Task Force <[log in to unmask] >>>>>>>>> <mailto:[log in to unmask]>> >>>>>>>>> >>>>>>>>> This is easy, .. here we have an violation of a couple of our >>>>>>>>> policies on how >>>>>>>>> th handle user privacy data. >>>>>>>>> >>>>>>>>> "....The xrootd monitoring infrastructure sends user DN information >>>>>>>>> and >>>>>>>>> all user actions in cleartext over UDP packets across to SLAC in the >>>>>>>>> US for monitoring. They are even open about it: .." >>>>>>>>> >>>>>>>>> https://indico.cern.ch/event/197803/session/0/material/slides/0 >>>>>>>>> >>>>>>>>> ... Mitigation can be done by blocking OUTBOUND UDP apckets on each >>>>>>>>> DPM xrootd host, in particular the headnode, but this is >>>>>>>>> obviously not >>>>>>>>> done by default. >>>>>>>>> >>>>>>>>> DROP udp -- anywhere anywhere udp spt:53193 >>>>>>>>> DROP udp -- anywhere anywhere udp spt:55721 >>>>>>>>> DROP udp -- anywhere atl-prod05.slac.stanford.edu >>>>>>>>> <http://atl-prod05.slac.stanford.edu/> >>>>>>>>> ...." >>>>>>>>> >>>>>>>>> Does IRTF wants to send out an advisory to all sites to apply the >>>>>>>>> same FW >>>>>>>>> rules? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Sven >>>>>>>>> -- >>>>>>>>> ======== >>>>>>>>> Sven Gabriel >>>>>>>>> >>>>>>>>> Nikhef, Dutch National Institute for Sub-atomic Physics >>>>>>>>> Group Computer Technology / Room: H1.59 >>>>>>>>> Phone: +31 20 5925103 >>>>>>>>> Science Park 105 / 1098 XG Amsterdam / The >>>>>>>>> Netherlands_______________________________________________ >>>>>>>>> Irtf mailing list >>>>>>>>> [log in to unmask] <mailto:[log in to unmask]> >>>>>>>>> https://mailman.egi.eu/mailman/listinfo/irtf >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Romain Wartel >>>>>>> Security Officer >>>>>>> Worldwide LHC Computing Grid >>>>>>> CERN, IT Department >>>>>>> CH-1211 Geneva 23, Switzerland >>>>>>> >>>>>>> http://www.cern.ch/LCG >>>>>>> http://cern.ch/security >>>>>>> <[log in to unmask] <mailto:[log in to unmask]>> >>>>>>> <[log in to unmask] <mailto:[log in to unmask]>> >>>>>>> >>>>>> >>>>> >>>> >>>> >> >> -- >> Oliver Keeble Information Technology Department >> [log in to unmask] CERN >> +41 76 487 5965 CH-1211 Geneva 23 >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-DEV list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 >> > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the XROOTD-DEV list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1