I have a fundamental question which came up in our department and I wanted to gather some insights on how other agencies or companies handle the following use-case. I hope this is a good place for this question. If there is a better place, please let me know.
Our current approach is that editors work on the production environment. The database is then copied from time to time to staging/dev. This is the opposite way of how site packages are synchronised (staging → prod), of course.
Their explanation is like this:
“In the event of an attack, the production server is deleted and the backup from the development server is then reinstalled. The production server is more strictly protected against external access, i.e. direct access should remain blocked, especially for employees of subsidiaries.”
To preface this and inform of potential bias, I work at in2code GmbH, provider of the Content Publisher extension which has been discussed here.
Is TYPO3 supposed to have editors work on production and is working on staging an exception? How are most of the TYPO3 instances configured?
As TYPO3 doesn’t have telemetry we don’t have any definite stats on usage, but it also depends on the scale of websites.
Most websites just have editors work on the production website.
Larger websites are probably using workspaces (the TYPO3 included feature) to have a reviewing process that works on the same instance. So, while editors might only see their specifically assigned workspace, all content and editors are still on production.
Large to very large enterprises are probably either using the two methods above, or are using Content Publisher. Content Publisher is there for very security-conscious customers that want to follow a content reviewing approach as well, with the added benefit that the target system can be completely locked down since it doesn’t need to be accessed to have content delivered to it.
Considering these points, working on staging is more of an exception than just working on the production site.
From a security point of view, is it really necessary to let editors work on staging and block access to the production TYPO3?
It’s not necessary. There are other ways to block access to a TYPO3 backend, but two-instance approaches can allow the production website to be locked down completely (e.g. having backend login be disabled) which is probably one of the most secure “public web” strategies (virtually no way to access TYPO3 to cause damage from the outside)
Apart from DMZ and proxies, what else can be done to secure a production environment server and its TYPO3?
There are quite a few ways to make TYPO3 secure even in a one-instance production environment, the best starting point is probably the Security Guidelines page in the TYPO3 documentation. There especially you can find the page “Global TYPO3 configuration options“ which outlines many options that can be used to improve security of a TYPO3 system, for example IPmaskList which allows to restrict backend access to given IP ranges.
Since TYPO3 v13 you can also configure the Backend entry point, so to access the TYPO3 backend, you could use any other path than /typo3 which also improves security due to automatic scanners/etc. not finding the backend route.
If any change on a staging system could be published easily there is no additional security regarding a malicious editor (a know editor going bad or a takeover of an existing account).
Installing workflows where any change has to be verified by another account can be done in a single installation. Therefore TYPO3 has the workspaces with versioned content.
On the other side you should make sure no editor has more rights than necessary for his work. So any account abuse can temper only a small part. That depends mostly on the size of a website. Having many different areas (pagetree, kind of records, categories, …) it is a good idea to have single backend groups with editing rights only on single areas.
On the other side you have different options to secure the backend access in general. Starting with htaccess (IP-masks or additional login). Requimeent for strong passwords (better than forcing repeating password changes) and two factor authentification. You can use an AD instead of the local database for storing user accounts (alas TYPO3 copies the user to the local database)
The web server at the front is always directly exposed to attacks via HTTPS in the DMZ, e.g. due to errors in the web server or a downstream component (e.g. via SQL injection vulnerability or similar).
This could corrupt the data on this system. Normally, a new, empty TYPO3 instance is simply set up and the data is pushed there from one of the internal systems to get everything back to normal.
If such an attack happens and is successful, would it be enough to just disable/restrict the TYPO3 backend login or is the damage already done because the attacker is inside TYPO3 already.
Would it be enough to grand access to the production TYPO3 backend just via VPN, and maybe disable the /typo3 page entirely from the outside?
The following scenario:
An attacker gains access to the TYPO3 production system. Can he access the data inside TYPO3 or can he go further and gain more access to internal systems?
If you copy the live database to the DEV/staging system at regular intervals, will malware or malicious code be copied along with it? Probably yes.
However, if you only ever copy to the live instance, i.e. from an internal system to the production system, then malicious code would not spread to the DEV system, but the live instance would be deleted and replaced with a clean TYPO3 from the editor system.
If this scenario is a security problem, why do the majority of TYPO3 editors work on a production system and not on an internal editor system? Wouldn’t that be much safer, or is it negligible?
If you want to be absolutely sure, you have to build the website statically without any scripts on the live server. (also possible with TYPO3 if you have no dynamic content)
TYPO3 is well protected against script injection by a normal content editor. Make sure that an editor can’t access kernel features and any kind of script files and he can’t infect your site.
An editor can change/ deface your content. but that can be secured by a workflow where no normal editor can put content live without a control of a supervisor.
two systems (edit instance → live instance) can be done for more security and also for a better performance. But the handling is more complicated than a single instance. those instances need a clean workflow for publishing any changes. You need a access for editors only on the edit instance (how can you make this access more secure than the live instance?), you have to configure two systems which need to communicate to each other.
as mentioned: you even can use TYPO3 to build up static websites which can be synchronized to the live server (e.g. rsync).
Usually it is enough if you have one instance with a workflow, where no editor can push changes live, and good access control (at least 2FA, maybe 3FA: only accounts from an AD and access from internal (IP-range))
And of course you need to stay with a secure version and do every security update for your server (operating system, firewall, proxy, web-server, PHP, TYPO3, extensions, …) immediately.
That needs a good deployment workflow and support for updating your configuration and own extensions depending on the other parts.
Nowadays, software requires continuous support to be secure!
The concern is not the BE editors, but rather that an external attacker gains access to TYPO3 and, from there, changes files/data or gains access to other internal systems.
When editors work on the live system, the live instance must be synchronised with the DEV instance from time to time. This is simply to ensure that the new content elements are available and also for testing purposes.
As a result, compromised files may end up on the DEV system and an attacker may gain access to other servers/computers.
In this context, it is logical that files should never be copied from the live system to the DEV system, for example. This prevents compromised files from entering internal systems.
However, form data or event registrations end up in the live system and are therefore not visible in the editor system, which can be problematic.
So how can you prevent compromised data/files from entering the DEV system when you are working directly in the live system and you don’t know whether data/files have been modified by an external attacker?
Does anyone know how this works for large newspaper portals? Do the editors also work on the live instance, or is there an editor instance that is decoupled from the live instance?
Usually no editor should be able to store a script or executable file on the live system. And of cause no visitor. If visitors can upload files you need a malware check so that no malicious files got stored.
In an up-to-date TYPO3 system no editor is able to modify any scripts from extensions or TYPO3 core.
No editor should need any scripting as this is work for the developer which put the scripts on LIVE by deployment.
On deployment you can set just reading rights for the web-server to any file from TYPO3 or an extension. So no modification can be done to these files. And these files never needed to be transferred back to DEV.
For debugging purpose you only copy data(!) from LIVE to DEV.
To be sure even check them for malicious content.
