Hardening Plone

A Military-Strength CMS

2

Hardening Plone

A Military-Strength CMS

Hardening the Plone stack

A Military-Strength CMS and its infrastructure

3

Class rules

● Feel free to ask questions

4

About us

● Kees Hink● Plone developer since

January 2008

● Kim Chee Leong● Plone developer since

May 2007

5

Introduction

● This talk is about:● Making the Plone stack even more secure● Not much about Plone itself● How to get others to acknowledge that it's secure

● For who?● New to Plone● Marketing● Developers

6

Overview of sections

● Why security?● Our use case● Plone● Infrastructure● Audits (and feedback)

7

The internet is evil

● :Have to protect against

● Cross site scripting

● Unencrypted connections

● Spoofing

● Password cracking

● Mail interception

● Server hacking

● SQL injection

8

SQL Injection

Comic by XKCD: http://xkcd.com/327/

9

Our use case

● Two portals:● Plone as a DMS for online collaboration

– Largely standard Plone– Alternative to Sharepoint– Sensitive data

● Plone as a user friendly file upload system– Document upload by suppliers– User friendly upload

10

Security of default Plone

● Plone (Zope) is pretty secure by default● Quantitative comparison:

– Track number of hits on Google – See nr. of vulnerabilities in the National Vulnerability

Database● Qualititative comparison:

– See article “security overview of plone” on plone.org

11

Small Plone modifications

● Disable self-registration

● Workflow + permissions

● Additional Products– Aagje (activity log)– LoginLockout

12

How to protect?

● Let's start with a secure location

13

Infrastructure

● Secure hosting● Trusted hosting partner● Secure hosting● Dedicated servers

● Operating system● Security updates

● Company procedures● Who has access?

14

● Only HTTPS port is opened to the internet

● VPN-only access for all except HTTPS

15

Infrastructure: OS

● Modifications on Debian Linux to enhance security– Different system user

for each Zope instance– Regular security

update– Tighten filesystem

permissions

16

Infrastructure: Web server

● Apache– HTTPS– Get an SSL certificate

(Thawte, VeriSign) – No rewrite rule for

Zope root– Keep log files

17

SSL certificate

18

Just to keep your attention

http://xkcd.com

19

Audits

● Document your procedures● We are using parts of

ITIL

● Get audits● Technical audit● Process audit

20

Technical security audit

● Done by 3rd party● They have a checklist● They report back in a structured way

● Black box audit● From outside, on Plone portal

● Crystal box audit● On server, with root access● Check user permissions, etc.

21

Recommendations for Plone

● Plone itself is pretty secure● Modifications:

● Quota (file upload limit)● Cookie settings (HTTPOnly, Secure), fixed with

Apache

● And, of course:● disable self-registration, check workflow,

permissions, use LoginLockout

22

Recommendations outside Plone

● Modifications:● Use HTTPS only (no redirects from HTTP)● Paranoid user permission restrictions● Caching header control

● And, of course:● secure hosting, VPN, security updates, etc.

23

Technical audit final result

● We implemented these recommendations for the next audit, which was tested again and approved:

24

Process security audit

● Done by our client's accountants● Check processes:

● Talk about our server management documents (esp. security-related)

● Talk about certification of hosting partner● Talk to technical auditing party● Talk to us, again...

25

Recommendations for Plone

● Confidentiality and user agreement

26

Process audit final result

● We passed!

Image by Getty images

27

Wrapping up

● Done:● Think about how to secure our existing setup even

more● Have specialists check our setup + procedures● Implement their recommendations

● Result: Plone is officially 100% secure.

28

Remaining questions?