From TZimmerman at fsu.edu Wed Sep 4 19:22:31 2019 From: TZimmerman at fsu.edu (Travis Zimmerman) Date: Wed, 4 Sep 2019 18:22:31 +0000 Subject: [ZendTo] Yum repo References: <7B3B6AB8-F71B-45C2-993E-96905BBCA732@fsu.edu> Message-ID: I?m getting a 403 Forbidden error when running ?yum update zendto?. Anyone else getting this error? Did the repo move? Looks like yum is trying to access http://zend.to/yum/noarch/zendto-5.21-2.noarch.rpm ------------------------------------------------------ Travis Zimmerman tzimmerman at fsu.edu 850-645-8030 Linux Enterprise Applications & Systems its-linuxadmins at fsu.edu Information Technology Services, Florida State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguel at uhtasi.org Wed Sep 4 20:55:25 2019 From: miguel at uhtasi.org (Miguel Brostrom) Date: Wed, 4 Sep 2019 09:55:25 -1000 (HST) Subject: [ZendTo] Yum repo In-Reply-To: References: <7B3B6AB8-F71B-45C2-993E-96905BBCA732@fsu.edu> <05d201d5635a$909e7d50$b1db77f0$@uhtasi.org> Message-ID: Hi Travis, I?d like to know too! I was getting this error yesterday as well. Seems like only the Ubuntu/Debian package link is working here https://zend.to/downloads.php#packages From: ZendTo On Behalf Of Travis Zimmerman via ZendTo Sent: Wednesday, September 4, 2019 8:23 AM To: ZendTo Users Cc: Travis Zimmerman Subject: [ZendTo] Yum repo I?m getting a 403 Forbidden error when running ?yum update zendto?. Anyone else getting this error? Did the repo move? Looks like yum is trying to access http://zend.to/yum/noarch/zendto-5.21-2.noarch.rpm ------------------------------------------------------ Travis Zimmerman tzimmerman at fsu.edu 850-645-8030 Linux Enterprise Applications & Systems its-linuxadmins at fsu.edu Information Technology Services, Florida State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxsec at gmail.com Mon Sep 9 20:58:50 2019 From: maxsec at gmail.com (Martin Hepworth) Date: Mon, 9 Sep 2019 20:58:50 +0100 Subject: [ZendTo] List and website issues References: Message-ID: All Jules sends his apologies about the recent outage of the list and website. He's currently in hospital quite poorly and was unable to access the hosted site. With the wonderful help from the guys at Blacknight.com who host the site, it's now working again. I'm sure he would appreciate any emails to cheer him up and please don't be offended if you get a response for a while due to his health issues. Martin -- -- Martin Hepworth, CISSP Oxford, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From athacker at grimsby.ca Mon Sep 9 21:39:39 2019 From: athacker at grimsby.ca (Adam Thacker) Date: Mon, 9 Sep 2019 20:39:39 +0000 Subject: [ZendTo] List and website issues In-Reply-To: References: Message-ID: Jules here is a hospital tip: If you need a nurse go to sleep. A nurse will be by shortly to wake you. Take care, From: ZendTo On Behalf Of Martin Hepworth via ZendTo Sent: September 9, 2019 3:59 PM To: zendto at zend.to Cc: Martin Hepworth Subject: [ZendTo] List and website issues CAUTION: Email external to Grimsby! All Jules sends his apologies about the recent outage of the list and website. He's currently in hospital quite poorly and was unable to access the hosted site. With the wonderful help from the guys at Blacknight.com who host the site, it's now working again. I'm sure he would appreciate any emails to cheer him up and please don't be offended if you get a response for a while due to his health issues. Martin -- -- Martin Hepworth, CISSP Oxford, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssilva at sgvwater.com Mon Sep 9 21:48:12 2019 From: ssilva at sgvwater.com (Scott Silva) Date: Mon, 9 Sep 2019 20:48:12 +0000 Subject: [ZendTo] List and website issues In-Reply-To: References: <54D3F6A07E3F2A4AAD4CBA73922025F4206F6DAC@FONEXCH01.sgvwc.local> Message-ID: I feel bad for Jules? I have seen him with health issues for years? A couple years with this project, and several years with Mailscanner? From: ZendTo On Behalf Of Adam Thacker via ZendTo Sent: Monday, September 9, 2019 1:40 PM To: ZendTo Users Cc: Adam Thacker Subject: Re: [ZendTo] List and website issues Jules here is a hospital tip: If you need a nurse go to sleep. A nurse will be by shortly to wake you. Take care, From: ZendTo > On Behalf Of Martin Hepworth via ZendTo Sent: September 9, 2019 3:59 PM To: zendto at zend.to Cc: Martin Hepworth > Subject: [ZendTo] List and website issues CAUTION: Email external to Grimsby! All Jules sends his apologies about the recent outage of the list and website. He's currently in hospital quite poorly and was unable to access the hosted site. With the wonderful help from the guys at Blacknight.com who host the site, it's now working again. I'm sure he would appreciate any emails to cheer him up and please don't be offended if you get a response for a while due to his health issues. Martin -- -- Martin Hepworth, CISSP Oxford, UK - ?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nigel.Kendrick at kineo.com Thu Sep 12 14:12:40 2019 From: Nigel.Kendrick at kineo.com (Nigel Kendrick) Date: Thu, 12 Sep 2019 13:12:40 +0000 Subject: [ZendTo] Zend.To Auth issue In-Reply-To: References: Message-ID: Thanks Dominic. That seems to work. FYI Jules - any kickback or comments? Thanks both. Nigel Kendrick Technical Delivery Manager [cid:image002.png at 01D56974.22633EF0] Office: +44 (0) 1273 764 070 x1078 Email nigel.kendrick at kineo.com www.kineo.com twitter.com/kineo Registered Office: Sovereign House, Church Street, Brighton BN1 1SS | Kineo Limited is registered in England and Wales no. 07150983 | VAT Registration number: GB 788 6564 55. From: Dominic C. DeFiore Sent: 12 September 2019 13:53 To: Nigel Kendrick Subject: Zend.To Auth issue This email originated from outside of our organisation. ________________________________ Nigel, I ran into the same problem as you. I found a fix for it. Zendto\lib\NSSADAuthenticator.php Add after line 457 $uname = preg_replace('/@.*$/', '', $uname); $uname = preg_replace('/^.*\\\/', '', $uname); Looks like this was removed at some point recently and that's what broke the login with full email (because I suppose before it stripped the email anyway) [cid:image003.png at 01D56974.22633EF0] Cheers Thanks, Dominic Dominic DeFiore REISS ENGINEERING, INC. PLANNING DESIGN CONSTRUCTION 1016 Spring Villas Pt. Winter Springs, FL 32708 Tel: 407.679.5358 Fax: 407.679.5003 dcdefiore at reisseng.com http://www.reisseng.com ----------------------------------------------------------------------------------------------------------------------------------------- This email message has been delivered safely and archived online by Mimecast. For more information please visit http://www.mimecast.com ----------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 7670 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 30120 bytes Desc: image003.png URL: From tobias.tafart at nextlayer.at Fri Sep 20 09:49:48 2019 From: tobias.tafart at nextlayer.at (Tobias Tafart) Date: Fri, 20 Sep 2019 08:49:48 +0000 Subject: [ZendTo] Feature Request: Set Encryption as default for Dropoffs, but don't enforce them References: Message-ID: Hi, we would like to be able to set encryption as enabled via default for drop-offs, but we don?t want to enforce it. The other options on the drop-offs page we can control the defaults via changing the templates (by just setting checked="checked"), but for the encryption this won?t work because it won?t ask for the password that way. The idea being that we hope to encourage our users to make use of the functionality. The big red banner on top of the page doesn?t seem to do much. We can?t enforce encryption though. I hope this should be fairly easy to implement and I suspect others also might have a use for such functionality. Regards, Tobias Tafart System Engineer next layer Tele?kommunikations?dienst?leistungs- und Beratungs GmbH 1150 Wien | Mariahilfer G?rtel 37/7 fon: +43 5 1764-894 | fax: +43 5 1764-900 | m: +43 664 2 1764 94 web: www.nextlayer.at FN 257486g | HG Wien -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3755 bytes Desc: not available URL: From kevin.miller at juneau.org Mon Sep 23 23:21:31 2019 From: kevin.miller at juneau.org (Kevin Miller) Date: Mon, 23 Sep 2019 22:21:31 +0000 Subject: [ZendTo] old zendto.po files References: <7dd6433fed5f42328f89ca62e8708785@City-Exch-DB2.cbj.local> Message-ID: I just ran an update and was going through the output. When asked if I wanted to keep an existing conf file I went with the default (keep the existing one). I'm going through the various conf files now, comparing the differences and saw a number of zendto.po.~N~ files in the /opt/zendto/config/locale/ subdirectories. I presume it's safe to delete these, right? ...Kevin -- Kevin Miller Network/email Administrator, CBJ MIS Dept. 155 South Seward Street Juneau, Alaska 99801 Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357 From kevin.miller at juneau.org Tue Sep 24 23:34:44 2019 From: kevin.miller at juneau.org (Kevin Miller) Date: Tue, 24 Sep 2019 22:34:44 +0000 Subject: [ZendTo] Debian Buster, apparmor and clamd References: <71944f2ab15b48449adedd075032ed4d@City-Exch-DB2.cbj.local> Message-ID: I have a zendto installed on Debian Stretch (on a VM) which works fine. I cloned it, updated zendto to 5.21-2 Production, and everything was fine. I then upgraded Stretch to Buster. After that, things went south. I'm seeing an AppArmor issue. The following is from the syslog: Sep 24 13:46:27 fileshare2 kernel: [ 723.420159] audit: type=1400 audit(1569361587.454:13): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/clamd" name="var/zendto/incoming/phpeuAoDV" pid=528 comm="clamd" requested_mask="r" denied_mask="r" fsuid=112 ouid=33 I disabled AppArmor, rebooted, and everything worked as advertised. FWIW, AppArmor isn't running on the host with Debian Stretch. One thing that stands out in the error message is: name="var/zendto/incoming/phpeuAoDV Note the lack of leading / character in the filename. I suspect that's the issue but I don't know what's passing the file path without the leading forward slash. I did add in the /var/zendto tree to the AppArmor configuration as below. root at fileshare2:/etc/apparmor.d/local# cat usr.sbin.clamd # Site-specific additions and overrides for usr.sbin.clamd. # For more details, please see /etc/apparmor.d/local/README. /var/zendto/** r, I know Julian is laid up - hoping someone else here's already solved the problem... ...Kevin -- Kevin Miller Network/email Administrator, CBJ MIS Dept. 155 South Seward Street Juneau, Alaska 99801 Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357 From Guy.Bertrand at exelaonline.com Sat Sep 28 02:18:50 2019 From: Guy.Bertrand at exelaonline.com (Guy Bertrand) Date: Sat, 28 Sep 2019 01:18:50 +0000 Subject: [ZendTo] Http headers - audit requirements References: <00a91b2c294c400aa514aec6d80367c5@exelaonline.com> Message-ID: Hello all Zendto users, Our corporate security and audit department recently asked me to make sure that our Zendto installation sent back a whole bunch of security HTTP headers. I told them that a hacker won?t care about any headers you send back, because they don?t use browsers, but more command-line automated type tools. It fell on deaf ears, and they told me that if I want to pass audit, I had to do this. Sigh. So I?ll share what I was able to configure with the ZendTo distribution list to make the site pass the audit. If you want to skip my verbose description, just go at the bottom of the email for the configs. In your typical ZendTo config/preferences.php file, there should be a section entitled ?// Security HTTP headers?, with 3 paragraphs of comments and possibly only one configuration: ?X-Frame-Options? => ?sameorigin?, That?s nice, but not enough. I?ve been using https://securityheaders.com to test our web site, and obviously? the site failed miserably. So after a whole bunch of reading (https://geekflare.com/http-header-implementation/ was pretty good), tweaking and testing, I?ve come up with a list of HTTP headers that gave me an A score. Yea!! Note that I preferred to do this in my web server's configuration, not ZendTo's preferences.php file. But I did leave the X-Frame-Options in the preferences.php, just to see what would happen the next time I upgrade ZendTo. The really tricky one is Content-Security-Policy. If you don?t configure it just right, some of the ZendTo pages will not work. I finally got it to work. However, when I look at the code, Jules has obviously used some other open source tools, which have references to other sites (ie: URL), which I have found are not used by ZendTo. However, in the config file, I have put them in a comment section. If you are trying to work on Content-Security-Policy (possibly after an upgrade) and you are having issues, do not despair! Instead of Content-Security-Policy, you can actually start with Content-Security-Policy-Report-Only, which will display any warnings or errors in your browser?s development console (if you know how to get to it), while allowing the pages to display properly. At least, that is what I did until I got it to work. You can tweak the config file accordingly and then share it with the rest of us. Same with the public-key-pins and public-key-pins-report-only. I?m using Apache Httpd. If you are using another http server, you will need to adapt the config for your server?s syntax. Hope this helps! And Jules, get better, not soon, but right now!! Regards, Guy Guy Bertrand, M.Ing Directeur informatique / IT Manager EXELA TECHNOLOGIES #################################################################################### # cat /etc/httpd/conf.d/httpheaders.conf #################### # This directive controls whether Server response header field which is sent back to clients includes a description of the generic OS-type of the server as well as information about compiled-in modules. ServerTokens Prod ######################################### # The ServerSignature directive allows the configuration of a trailing footer line under server-generated documents (error messages, mod_proxy ftp directory listings, mod_info output, ...). ServerSignature Off ####################################### # remove header X-Powered-By Header always unset "X-Powered-By" header unset "X-Powered-By" ####################### # X-XSS-Protection sets the configuration for the XSS Auditor built into older browser. The recommended value was "X-XSS-Protection: 1; mode=block" but you should now look at Content Security Policy instead. Header set X-XSS-Protection "1; mode=block" ##################### # HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains" ####################### # X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff". Header set X-Content-Type-Options nosniff ##################### # WARNING! already included in ZendTo preferences.php file. You can remove it from the preferences.php file and put it here. #Header always append X-Frame-Options SAMEORIGIN ############################ # Using Adobe products like PDF, Flash, etc.? You can implement this header to instruct the browser how to handle the requests over a cross-domain. By implementing this header, you restrict loading your site?s assets from other domain to avoid resource abuse. Header set X-Permitted-Cross-Domain-Policies "none" ####################### # Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets. Analyse this policy in more detail. You can sign up for a free account on Report URI to collect reports about problems on your site. # To start, you can use Content-Security-Policy-Report-Only and use the development tools in your browser to investigate the reported warning and errors. All pages will be displayed, even if in error. # NOTE: ZENDTO has references to the following, yet I have not found that I needed to allow them...yet #http://datatables.net #http://cookiesandyou.com #http://zendto.to #mailto:// #https://info.smartmessages.net #https://fonts.googleapis.com #http://www.smarty.net #Header set Content-Security-Policy #Header set Content-Security-Policy-Report-Only Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' https://uploadit.exelatech.com:443; script-src 'self' 'unsafe-inline' https://www.google.com https://www.gstatic.com; connect-src 'self'; img-src 'self' 'unsafe-inline' data: ; font-src 'self' https://fonts.googleapis.com https://fonts.gstatic.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; frame-src 'self' https://www.google.com https://www.gstatic.com" ########################################## # Expect-CT allows a site to determine if they are ready for the upcoming Chrome requirements and/or enforce their CT policy. Header set Expect-CT "max-age=0" ######################### # not configured yet, but we still pass audit ######################### # HTTP Public Key Pinning. Minimize the man-in-the-middle (MITM) attacks risk by pinning certificate. This is possible with HPKP (HTTP Public Key Pinning) header. You can pin the root certificate public key or immediate certificate. At the time of writing, HPKP currently works in Firefox and Chrome and support SHA-256 hash algorithm. # To start, you can use public-key-pins-report-only and use the development tools in your browser to investigate the reported warning and errors. All pages will be displayed, even if in error. #public-key-pins #public-key-pins-report-only # not configured yet ######################## # NEW HEADERS coming soon ######################## # Feature Policy is a new header that allows a site to control which features and APIs can be used in the browser. # Not configured yet. ######################## # referrer-policy is a new header that allows a site to control how much information the browser includes with navigations away from a document and should be set by all sites. # Not configured yet. ######################## # Expect-CT allows a site to determine if they are ready for the upcoming Chrome requirements and/or enforce their CT policy. # Not configured yet. ________________________________ Attention : le pr?sent message et toutes les pi?ces jointes sont confidentiels et ?tablis ? l'attention exclusive du ou des destinataire(s) indiqu?(s). Toute autre diffusion ou utilisation non autoris?e est interdite. Si vous recevez ce message par erreur, veuillez imm?diatement en avertir l'exp?diteur par e-mail en retour, d?truire le message et vous abstenir de toute r?f?rence aux informations qui y figurent afin d'?viter les sanctions attach?es ? la divulgation et ? l'utilisation d'informations confidentielles. Les messages ?lectroniques sont susceptibles d'alt?ration. Exela Technologies et ses filiales d?clinent toute responsabilit? en cas d'alt?ration ou de falsification du pr?sent message. ________________________________ Please consider the environment before printing or forwarding this email. If you do print this email, please recycle the paper. This email message may contain confidential, proprietary and/or privileged information. It is intended only for the use of the intended recipient(s). If you have received it in error, please immediately advise the sender by reply email and then delete this email message. Any disclosure, copying, distribution or use of the information contained in this email message to or by anyone other than the intended recipient is strictly prohibited. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Exela Technologies, Inc. or its subsidiaries. This email does not constitute an agreement to conduct transactions by electronic means and does not create any legally binding contract or enforceable obligation against Exela in the absence of a fully signed written agreement. From zend.to at neilzone.co.uk Sat Sep 28 08:05:36 2019 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Sat, 28 Sep 2019 08:05:36 +0100 Subject: [ZendTo] Http headers - audit requirements In-Reply-To: References: <00a91b2c294c400aa514aec6d80367c5@exelaonline.com> <39A5AF0B-259B-42D2-80C0-71F12B9464BA@neilzone.co.uk> Message-ID: > On 28 Sep 2019, at 02:18, Guy Bertrand via ZendTo wrote: > > I?ll share what I was able to configure with the ZendTo distribution list to make the site pass the audit What an incredibly helpful post. Thank you! Neil __________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Massimo.Forni at turboden.it Sat Sep 28 08:36:20 2019 From: Massimo.Forni at turboden.it (Massimo Forni) Date: Sat, 28 Sep 2019 07:36:20 +0000 Subject: [ZendTo] Http headers - audit requirements In-Reply-To: References: <5CD58A56-FE5D-409D-9FBE-614FD905BBCA@turboden.it> Message-ID: Thank you!! Sent from my iPhone > On 28 Sep 2019, at 03:19, Guy Bertrand via ZendTo wrote: > > ?Hello all Zendto users, > > Our corporate security and audit department recently asked me to make sure that our Zendto installation sent back a whole bunch of security HTTP headers. I told them that a hacker won?t care about any headers you send back, because they don?t use browsers, but more command-line automated type tools. It fell on deaf ears, and they told me that if I want to pass audit, I had to do this. Sigh. > > So I?ll share what I was able to configure with the ZendTo distribution list to make the site pass the audit. If you want to skip my verbose description, just go at the bottom of the email for the configs. > > In your typical ZendTo config/preferences.php file, there should be a section entitled ?// Security HTTP headers?, with 3 paragraphs of comments and possibly only one configuration: > ?X-Frame-Options? => ?sameorigin?, > > That?s nice, but not enough. I?ve been using https://urldefense.com/v3/__https://securityheaders.com__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YDj1xzxmg$ to test our web site, and obviously? the site failed miserably. > > So after a whole bunch of reading (https://urldefense.com/v3/__https://geekflare.com/http-header-implementation/__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YDPam4VXQ$ was pretty good), tweaking and testing, I?ve come up with a list of HTTP headers that gave me an A score. Yea!! > > Note that I preferred to do this in my web server's configuration, not ZendTo's preferences.php file. But I did leave the X-Frame-Options in the preferences.php, just to see what would happen the next time I upgrade ZendTo. > > The really tricky one is Content-Security-Policy. If you don?t configure it just right, some of the ZendTo pages will not work. I finally got it to work. However, when I look at the code, Jules has obviously used some other open source tools, which have references to other sites (ie: URL), which I have found are not used by ZendTo. However, in the config file, I have put them in a comment section. > > If you are trying to work on Content-Security-Policy (possibly after an upgrade) and you are having issues, do not despair! Instead of Content-Security-Policy, you can actually start with Content-Security-Policy-Report-Only, which will display any warnings or errors in your browser?s development console (if you know how to get to it), while allowing the pages to display properly. At least, that is what I did until I got it to work. You can tweak the config file accordingly and then share it with the rest of us. Same with the public-key-pins and public-key-pins-report-only. > > I?m using Apache Httpd. If you are using another http server, you will need to adapt the config for your server?s syntax. > > Hope this helps! And Jules, get better, not soon, but right now!! > > Regards, > > Guy > > Guy Bertrand, M.Ing > Directeur informatique / IT Manager > EXELA TECHNOLOGIES > #################################################################################### > > > # cat /etc/httpd/conf.d/httpheaders.conf > #################### > # This directive controls whether Server response header field which is sent back to clients includes a description of the generic OS-type of the server as well as information about compiled-in modules. > > ServerTokens Prod > > ######################################### > # The ServerSignature directive allows the configuration of a trailing footer line under server-generated documents (error messages, mod_proxy ftp directory listings, mod_info output, ...). > > ServerSignature Off > > ####################################### > # remove header X-Powered-By > > Header always unset "X-Powered-By" > header unset "X-Powered-By" > > ####################### > # X-XSS-Protection sets the configuration for the XSS Auditor built into older browser. The recommended value was "X-XSS-Protection: 1; mode=block" but you should now look at Content Security Policy instead. > > Header set X-XSS-Protection "1; mode=block" > > ##################### > # HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. > > Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains" > > ####################### > # X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff". > > Header set X-Content-Type-Options nosniff > > ##################### > # WARNING! already included in ZendTo preferences.php file. You can remove it from the preferences.php file and put it here. > > #Header always append X-Frame-Options SAMEORIGIN > > ############################ > # Using Adobe products like PDF, Flash, etc.? You can implement this header to instruct the browser how to handle the requests over a cross-domain. By implementing this header, you restrict loading your site?s assets from other domain to avoid resource abuse. > > Header set X-Permitted-Cross-Domain-Policies "none" > > ####################### > # Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets. Analyse this policy in more detail. You can sign up for a free account on Report URI to collect reports about problems on your site. > # To start, you can use Content-Security-Policy-Report-Only and use the development tools in your browser to investigate the reported warning and errors. All pages will be displayed, even if in error. > > # NOTE: ZENDTO has references to the following, yet I have not found that I needed to allow them...yet > #https://urldefense.com/v3/__http://datatables.net__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YDNOAuo3w$ > #https://urldefense.com/v3/__http://cookiesandyou.com__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YB0LuW4fQ$ > #https://urldefense.com/v3/__http://zendto.to__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YBzIOYIMw$ > #mailto:// > #https://urldefense.com/v3/__https://info.smartmessages.net__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YAZxUNl2g$ > #https://urldefense.com/v3/__https://fonts.googleapis.com__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YCdVSzWTQ$ > #https://urldefense.com/v3/__http://www.smarty.net__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YCPWDB5Og$ > > #Header set Content-Security-Policy > #Header set Content-Security-Policy-Report-Only > > Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' https://urldefense.com/v3/__https://uploadit.exelatech.com:443__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YCcLA6JCA$ ; script-src 'self' 'unsafe-inline' https://urldefense.com/v3/__https://www.google.com__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YCeI-LdQg$ https://urldefense.com/v3/__https://www.gstatic.com__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YByC6zijQ$ ; connect-src 'self'; img-src 'self' 'unsafe-inline' data: ; font-src 'self' https://urldefense.com/v3/__https://fonts.googleapis.com__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YCdVSzWTQ$ https://urldefense.com/v3/__https://fonts.gstatic.com__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YDVUHGAhQ$ ; style-src 'self' 'unsafe-inline' https://urldefense.com/v3/__https://fonts.googleapis.com__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YCdVSzWTQ$ ; frame-src 'self' https://urldefense.com/v3/__https://www.google.com__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YCeI-LdQg$ https://urldefense.com/v3/__https://www.gstatic.com__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YByC6zijQ$ " > > ########################################## > # Expect-CT allows a site to determine if they are ready for the upcoming Chrome requirements and/or enforce their CT policy. > > Header set Expect-CT "max-age=0" > > ######################### > # not configured yet, but we still pass audit > ######################### > # HTTP Public Key Pinning. Minimize the man-in-the-middle (MITM) attacks risk by pinning certificate. This is possible with HPKP (HTTP Public Key Pinning) header. You can pin the root certificate public key or immediate certificate. At the time of writing, HPKP currently works in Firefox and Chrome and support SHA-256 hash algorithm. > # To start, you can use public-key-pins-report-only and use the development tools in your browser to investigate the reported warning and errors. All pages will be displayed, even if in error. > > #public-key-pins > #public-key-pins-report-only > > # not configured yet > > ######################## > # NEW HEADERS coming soon > ######################## > # Feature Policy is a new header that allows a site to control which features and APIs can be used in the browser. > > # Not configured yet. > > ######################## > # referrer-policy is a new header that allows a site to control how much information the browser includes with navigations away from a document and should be set by all sites. > > # Not configured yet. > > ######################## > # Expect-CT allows a site to determine if they are ready for the upcoming Chrome requirements and/or enforce their CT policy. > > # Not configured yet. > ________________________________ > Attention : le pr?sent message et toutes les pi?ces jointes sont confidentiels et ?tablis ? l'attention exclusive du ou des destinataire(s) indiqu?(s). Toute autre diffusion ou utilisation non autoris?e est interdite. Si vous recevez ce message par erreur, veuillez imm?diatement en avertir l'exp?diteur par e-mail en retour, d?truire le message et vous abstenir de toute r?f?rence aux informations qui y figurent afin d'?viter les sanctions attach?es ? la divulgation et ? l'utilisation d'informations confidentielles. Les messages ?lectroniques sont susceptibles d'alt?ration. Exela Technologies et ses filiales d?clinent toute responsabilit? en cas d'alt?ration ou de falsification du pr?sent message. > ________________________________ > Please consider the environment before printing or forwarding this email. If you do print this email, please recycle the paper. > > This email message may contain confidential, proprietary and/or privileged information. It is intended only for the use of the intended recipient(s). If you have received it in error, please immediately advise the sender by reply email and then delete this email message. Any disclosure, copying, distribution or use of the information contained in this email message to or by anyone other than the intended recipient is strictly prohibited. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Exela Technologies, Inc. or its subsidiaries. > > This email does not constitute an agreement to conduct transactions by electronic means and does not create any legally binding contract or enforceable obligation against Exela in the absence of a fully signed written agreement. > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > https://urldefense.com/v3/__http://jul.es/mailman/listinfo/zendto__;!Ql7noIEoQAI!iy1LurtpBry_YcHesVvJUt99-z2cMFf09JTPz_YbBQMfWpmR4I1WOaYzS18T4YB4c3j2kw$ -- Massimo Forni ICT Infrastructure Manager Mobile: +393474110278 ________________________________ Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy t. +390303552001 I f. +390303552011 www.turboden.com Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. From stony at stony.com Mon Sep 30 10:47:20 2019 From: stony at stony.com (Viktor Steinmann) Date: Mon, 30 Sep 2019 11:47:20 +0200 Subject: [ZendTo] Http headers - audit requirements In-Reply-To: References: <00a91b2c294c400aa514aec6d80367c5@exelaonline.com> <127a8fb4-ea83-ecc2-db50-f647ed9dfc10@stony.com> Message-ID: Hi Guy This is quite helpful, I have basically the same requirements in terms of compliance and I'm running almost the same headers. One additional headers I would recommend is Header set Server "none-of-your-business" which will hide the fact, that this is an Apache running. Of course you can put "Nginx" or whatever instead of "none-of-your-business" to confuse a potential attacker a little more... ;-) The main issue remains the Content-Security-Policy, which is not yet where it should be. The default-src should in any case be "none" and specific overrides in script-src, style-src etc.. But even then, the "unsafe-inline" parts will give you bad ratings on Mozilla's Observatory (https://observatory.mozilla.org/). I already wrote about this on this mailing list some time ago and asked Jules to put all JavaScript and Styles into separate .js and .css files in order to get rid of the "unsafe-inline" parts. I guess it's just a lot of changes to implement, but that would be really helpful in getting security another notch up. Kind regards, Viktor On 28.09.2019 03:18, Guy Bertrand via ZendTo wrote: > Hello all Zendto users, > > Our corporate security and audit department recently asked me to make sure that our Zendto installation sent back a whole bunch of security HTTP headers. I told them that a hacker won?t care about any headers you send back, because they don?t use browsers, but more command-line automated type tools. It fell on deaf ears, and they told me that if I want to pass audit, I had to do this. Sigh. > > So I?ll share what I was able to configure with the ZendTo distribution list to make the site pass the audit. If you want to skip my verbose description, just go at the bottom of the email for the configs. > > In your typical ZendTo config/preferences.php file, there should be a section entitled ?// Security HTTP headers?, with 3 paragraphs of comments and possibly only one configuration: > ?X-Frame-Options? => ?sameorigin?, > > That?s nice, but not enough. I?ve been using https://securityheaders.com to test our web site, and obviously? the site failed miserably. > > So after a whole bunch of reading (https://geekflare.com/http-header-implementation/ was pretty good), tweaking and testing, I?ve come up with a list of HTTP headers that gave me an A score. Yea!! > > Note that I preferred to do this in my web server's configuration, not ZendTo's preferences.php file. But I did leave the X-Frame-Options in the preferences.php, just to see what would happen the next time I upgrade ZendTo. > > The really tricky one is Content-Security-Policy. If you don?t configure it just right, some of the ZendTo pages will not work. I finally got it to work. However, when I look at the code, Jules has obviously used some other open source tools, which have references to other sites (ie: URL), which I have found are not used by ZendTo. However, in the config file, I have put them in a comment section. > > If you are trying to work on Content-Security-Policy (possibly after an upgrade) and you are having issues, do not despair! Instead of Content-Security-Policy, you can actually start with Content-Security-Policy-Report-Only, which will display any warnings or errors in your browser?s development console (if you know how to get to it), while allowing the pages to display properly. At least, that is what I did until I got it to work. You can tweak the config file accordingly and then share it with the rest of us. Same with the public-key-pins and public-key-pins-report-only. > > I?m using Apache Httpd. If you are using another http server, you will need to adapt the config for your server?s syntax. > > Hope this helps! And Jules, get better, not soon, but right now!! > > Regards, > > Guy > > Guy Bertrand, M.Ing > Directeur informatique / IT Manager > EXELA TECHNOLOGIES > #################################################################################### > > > # cat /etc/httpd/conf.d/httpheaders.conf > #################### > # This directive controls whether Server response header field which is sent back to clients includes a description of the generic OS-type of the server as well as information about compiled-in modules. > > ServerTokens Prod > > ######################################### > # The ServerSignature directive allows the configuration of a trailing footer line under server-generated documents (error messages, mod_proxy ftp directory listings, mod_info output, ...). > > ServerSignature Off > > ####################################### > # remove header X-Powered-By > > Header always unset "X-Powered-By" > header unset "X-Powered-By" > > ####################### > # X-XSS-Protection sets the configuration for the XSS Auditor built into older browser. The recommended value was "X-XSS-Protection: 1; mode=block" but you should now look at Content Security Policy instead. > > Header set X-XSS-Protection "1; mode=block" > > ##################### > # HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. > > Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains" > > ####################### > # X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff". > > Header set X-Content-Type-Options nosniff > > ##################### > # WARNING! already included in ZendTo preferences.php file. You can remove it from the preferences.php file and put it here. > > #Header always append X-Frame-Options SAMEORIGIN > > ############################ > # Using Adobe products like PDF, Flash, etc.? You can implement this header to instruct the browser how to handle the requests over a cross-domain. By implementing this header, you restrict loading your site?s assets from other domain to avoid resource abuse. > > Header set X-Permitted-Cross-Domain-Policies "none" > > ####################### > # Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets. Analyse this policy in more detail. You can sign up for a free account on Report URI to collect reports about problems on your site. > # To start, you can use Content-Security-Policy-Report-Only and use the development tools in your browser to investigate the reported warning and errors. All pages will be displayed, even if in error. > > # NOTE: ZENDTO has references to the following, yet I have not found that I needed to allow them...yet > #http://datatables.net > #http://cookiesandyou.com > #http://zendto.to > #mailto:// > #https://info.smartmessages.net > #https://fonts.googleapis.com > #http://www.smarty.net > > #Header set Content-Security-Policy > #Header set Content-Security-Policy-Report-Only > > Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' https://uploadit.exelatech.com:443; script-src 'self' 'unsafe-inline' https://www.google.com https://www.gstatic.com; connect-src 'self'; img-src 'self' 'unsafe-inline' data: ; font-src 'self' https://fonts.googleapis.com https://fonts.gstatic.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; frame-src 'self' https://www.google.com https://www.gstatic.com" > > ########################################## > # Expect-CT allows a site to determine if they are ready for the upcoming Chrome requirements and/or enforce their CT policy. > > Header set Expect-CT "max-age=0" > > ######################### > # not configured yet, but we still pass audit > ######################### > # HTTP Public Key Pinning. Minimize the man-in-the-middle (MITM) attacks risk by pinning certificate. This is possible with HPKP (HTTP Public Key Pinning) header. You can pin the root certificate public key or immediate certificate. At the time of writing, HPKP currently works in Firefox and Chrome and support SHA-256 hash algorithm. > # To start, you can use public-key-pins-report-only and use the development tools in your browser to investigate the reported warning and errors. All pages will be displayed, even if in error. > > #public-key-pins > #public-key-pins-report-only > > # not configured yet > > ######################## > # NEW HEADERS coming soon > ######################## > # Feature Policy is a new header that allows a site to control which features and APIs can be used in the browser. > > # Not configured yet. > > ######################## > # referrer-policy is a new header that allows a site to control how much information the browser includes with navigations away from a document and should be set by all sites. > > # Not configured yet. > > ######################## > # Expect-CT allows a site to determine if they are ready for the upcoming Chrome requirements and/or enforce their CT policy. > > # Not configured yet. > ________________________________ > Attention : le pr?sent message et toutes les pi?ces jointes sont confidentiels et ?tablis ? l'attention exclusive du ou des destinataire(s) indiqu?(s). Toute autre diffusion ou utilisation non autoris?e est interdite. Si vous recevez ce message par erreur, veuillez imm?diatement en avertir l'exp?diteur par e-mail en retour, d?truire le message et vous abstenir de toute r?f?rence aux informations qui y figurent afin d'?viter les sanctions attach?es ? la divulgation et ? l'utilisation d'informations confidentielles. Les messages ?lectroniques sont susceptibles d'alt?ration. Exela Technologies et ses filiales d?clinent toute responsabilit? en cas d'alt?ration ou de falsification du pr?sent message. > ________________________________ > Please consider the environment before printing or forwarding this email. If you do print this email, please recycle the paper. > > This email message may contain confidential, proprietary and/or privileged information. It is intended only for the use of the intended recipient(s). If you have received it in error, please immediately advise the sender by reply email and then delete this email message. Any disclosure, copying, distribution or use of the information contained in this email message to or by anyone other than the intended recipient is strictly prohibited. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Exela Technologies, Inc. or its subsidiaries. > > This email does not constitute an agreement to conduct transactions by electronic means and does not create any legally binding contract or enforceable obligation against Exela in the absence of a fully signed written agreement. > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto From Guy.Bertrand at exelaonline.com Mon Sep 30 16:48:36 2019 From: Guy.Bertrand at exelaonline.com (Guy Bertrand) Date: Mon, 30 Sep 2019 15:48:36 +0000 Subject: [ZendTo] Http headers - audit requirements References: <75ff68b5f3c54f79bc2b6f6f7681862b@exelaonline.com> Message-ID: Victor, I laughed when I saw your email.... >>> Header set Server "none-of-your-business" However, I would not recommend putting "none-of-your-business" as the actual text. Hackers couldn't care less about your headers, but they might take offense to your "none-of-your-business", or see it as a challenge. It just might make your site a even more of a target. For our Apache HTTPD server, your suggestion " Header set Server" did not work. It seems that it is a Apache Httpd known bug, but I also found a note that "... the Apache devs said it is a won't fix issue". I did not investigate this any further. I did find a way to do it using mod_security and using the SecServerSignature directive, but then mod_security didn't like it when I tried to upload a file larger than 128Mb. And I don't have time to tweak mod_security right now. There is a slight learning curve, so it is a project for later. And you are correct, the Content-Security-Policy I wrote still needs work, so I have updated it accordingly. Any other suggestions?? ********************** Header set Content-Security-Policy "default-src 'none'; script-src 'self' 'unsafe-inline' https://www.google.com https://www.gstatic.com; connect-src 'self' 'unsafe-inline'; img-src 'self' 'unsafe-inline' data: ; font-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://fonts.gstatic.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; frame-src 'self' 'unsafe-inline' https://www.google.com https://www.gstatic.com" ********************** On SecurityHeaders I got an A (not an A+) On MozillaObservatory, I got a B+ (from an original B with my first content-security-policy) Also, as my last footnote on this topic, I found this text on the Apache HTTPD web site: "... Also note that disabling the Server: header does nothing at all to make your server more secure. The idea of "security through obscurity" is a myth and leads to a false sense of safety." But it makes the auditors happy. Regards, Guy Guy Bertrand, M.Ing Directeur informatique / IT Manager EXELA TECHNOLOGIES b: +1.514.392.4999 | m: +1.514.265.9754 1155, boulevard Robert-Bourassa, suite 500 | Montr?al (Qu?bec) CANADA H3B 3A7 www.ExelaTech.com | EXELA LinkedIn Message: 3 Date: Mon, 30 Sep 2019 11:47:20 +0200 From: Viktor Steinmann To: Guy Bertrand via ZendTo Subject: Re: [ZendTo] Http headers - audit requirements Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed Hi Guy This is quite helpful, I have basically the same requirements in terms of compliance and I'm running almost the same headers. One additional headers I would recommend is Header set Server "none-of-your-business" which will hide the fact, that this is an Apache running. Of course you can put "Nginx" or whatever instead of "none-of-your-business" to confuse a potential attacker a little more... ;-) The main issue remains the Content-Security-Policy, which is not yet where it should be. The default-src should in any case be "none" and specific overrides in script-src, style-src etc.. But even then, the "unsafe-inline" parts will give you bad ratings on Mozilla's Observatory (https://observatory.mozilla.org/). I already wrote about this on this mailing list some time ago and asked Jules to put all JavaScript and Styles into separate .js and .css files in order to get rid of the "unsafe-inline" parts. I guess it's just a lot of changes to implement, but that would be really helpful in getting security another notch up. Kind regards, Viktor ________________________________ Attention : le pr?sent message et toutes les pi?ces jointes sont confidentiels et ?tablis ? l'attention exclusive du ou des destinataire(s) indiqu?(s). Toute autre diffusion ou utilisation non autoris?e est interdite. Si vous recevez ce message par erreur, veuillez imm?diatement en avertir l'exp?diteur par e-mail en retour, d?truire le message et vous abstenir de toute r?f?rence aux informations qui y figurent afin d'?viter les sanctions attach?es ? la divulgation et ? l'utilisation d'informations confidentielles. Les messages ?lectroniques sont susceptibles d'alt?ration. Exela Technologies et ses filiales d?clinent toute responsabilit? en cas d'alt?ration ou de falsification du pr?sent message. ________________________________ Please consider the environment before printing or forwarding this email. If you do print this email, please recycle the paper. This email message may contain confidential, proprietary and/or privileged information. It is intended only for the use of the intended recipient(s). If you have received it in error, please immediately advise the sender by reply email and then delete this email message. Any disclosure, copying, distribution or use of the information contained in this email message to or by anyone other than the intended recipient is strictly prohibited. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Exela Technologies, Inc. or its subsidiaries. This email does not constitute an agreement to conduct transactions by electronic means and does not create any legally binding contract or enforceable obligation against Exela in the absence of a fully signed written agreement.