Protect your TYPO3 website from attacks
Many universities and colleges are currently facing increased attacks, hacks or complete failures of their infrastructure. In individual cases the entire operation is considerably disturbed or even completely paralyzed. Possible gateways such as insecure e-mail attachments, too simple authentication methods or even your website and its editorial users play a critical role.
However, a security plan must not only be developed technically, but it must also be clear from a communication point of view what has to be done and by whom in the event of an incident. It is also important how you can communicate with your target groups despite - in the worst case - a complete shutdown.
Do you know possible gates of entry
Every infrastructure has security holes and at some point someone will find and exploit them - and it's hard to prevent that. However, it is important to learn from the latest hacks and to close known doors.
Typical attacks of the last few years run via insecure e-mail attachments or website hacks such as SQL injection, Cross Site Request Forgery (CSRF) or XSS Cross Site Scripting. Also secure other insecure areas and prohibit e.g. FTP, restrict server privileges as much as possible, block unused ports and allow only pubkey authentication instead of insecure passwords. Also make sure that your SSL certificates are always up to date (in this case, monitoring with Icinga or similar tools is recommended) and do not show detailed error messages in the production context so as not to give potential clues to attackers.
Technical security concept
In the event of an emergency, a rapid response is required at all levels, and in order to be able to achieve this, it must be clear in advance who has to do what and when, and how responsibilities are coordinated. To this end, a concrete emergency plan should be drawn up, in which all steps with responsible persons and parties (such as external service providers) are holistically recorded. This plan must be accessible to everyone and, above all, must be known and communicated. In the worst case, assume that all normal communication channels are disrupted and you will have to act and coordinate completely offline.
As a precautionary measure, you should first carry out a security audit of the systems in use. You should evaluate the entire server landscape and, ideally, also perform a detailed evaluation of individual critical systems. We also recommend that you then define an emergency plan with various expansion stages. Do you ask yourself what happens if individual systems fail and how can they or even the complete server architecture be reconstructed? Of course, this depends on the individual software and hardware used and the implemented functionalities. Also important is a separate prioritization according to alarm levels and individual systems. So ask yourself how long you could do without a system in the worst case. For example, the protection of students' personal data will clearly take priority over the standard functions of your own website.
A mature, cross-site backup concept with disaster recovery scenarios protects you from the worst. Version and provision each of your steps with a secure and central storage location so that you can rebuild the software at any time. Tip: Provide a blackpage (upstream emergency website) for your website, which should provide information about the status quo in a transition period between failure and recovery. If necessary, this can be deliberately planned with an external partner and delivered through them.
Are you currently designing your infrastructure or would you like to secure it for emergencies? Here you can find out everything you need to know with sample downloads - from planning, provisioning and scalability to monitoring.
SELFHOSTED-WEBSERVER - SECURE IN YOUR OWN HAND
Your Checklist
- Concrete emergency plan developed
- Responsible persons defined and informed
- Security audit performed
- Infrastructure versioned and provisioned
- Backup concept implemented
TYPO3 Security Optimizations
According to the BSI security study on various CMS (Content Management Systems), TYPO3 doesn't score badly, and above all the infrastructure around TYPO3, with security bulletins, TYPO3 Security Guidelines and an official and very active security team, receives great praise.
However, the system can be further optimised and secured by various measures. We particularly recommend the use of the Helmut Hummel Secure Web Package for further security. With this, PHP can only be executed in a few, defined places via Apache, which makes hacks via web shells almost impossible. Furthermore, HTTP Secure Headers and Cookie Domains should be configured so that the execution of foreign scripts is blocked. Also make sure to assign user rights as recessive as possible. Do all editors really need to be able to set HTML and iFrame content elements in TYPO3? In order to further protect the live system, tools such as the Content Publisher for TYPO3 can be used to completely do without editor users on the live TYPO3.
In addition, we recommend continuous monitoring of the TYPO3 core and any additional extensions used, including checking for security updates. Here, the use of a Caretaker server together with the Caretaker Extension for TYPO3 is recommended. On server level, tools such as ICINGA or Sentry should also be used.
Communicative emergency plan
A technical emergency plan is important! But in the worst case, one thing is particularly crucial: communication! And this on different levels. You now have the responsibility to communicate control and safety, even if at first you are understandably as insecure as everyone else.
Think about communication channels in advance, with which you can reach your target group even outside your infrastructure. Students, for example, can be addressed via social media channels, while employees should have private emergency contact data stored decentrally. You should also consider whether you would like to issue a press release in an emergency and define general content in advance.
A lot can also be made known in advance and the various parties can be sensitized. Deal openly with the topic "potential hacks" and proactively address the dangers and challenges openly. Employees should be sensitized, e.g. not to open unknown or dubious e-mail attachments or to use secure passwords - for example, whole sentences that are easier to remember should not be used by a password manager.
At a glance
- All parties sensitized in advance
- Emergency contact information collected
- Necessary offices like BKA switched on
- Alternative communication channels of the target groups identified
- Informing the public
Would you like advice or support in securing your web landscape?
As experts for TYPO3 and server infrastructure for web applications, we are happy to help you.
Starting with consulting with security audits up to the concrete planning and implementation of necessary measures.