From micro‑companies to the titans of the industry—everyone uses the open‑source software these days. Many choose self‑hosting over managed solutions but only a few of them actually take care of the security properly. According to Synopsys, 9 out of 10 (!) company systems contain open‑source components that are either outdated or no longer maintained. Such systems are often full of vulnerabilities.
Who should look after the security of OTRS instances and other open‑source applications? What are the possible consequences of a security breach? What are recommended countermeasures to protect against them? Wojciech Siewierski—a cybersecurity expert, Senior Perl Developer and IT administrator at Centuran Consulting—will discuss all of these topics.
Open-source software is everywhere. Up to 99% systems used in the industry contain at least a single open‑source component (OSSRA, 2020, Synopsys). Even the largest companies have found open‑source indispensable. This includes Microsoft, SAP, or Oracle, up until now solely associated with proprietary solutions. Where does this rising popularity of open‑source come from?
The open‑source solutions are infinitely more flexible than their proprietary counterparts. Their open nature allows to introduce custom changes and extensions specific for each industry, organization or even a single department. Such tailored features can be introduced internally, without involving the vendors.
Additionally open‑source is usually much cheaper up front and has higher code quality, constantly maintained by the community. It shouldn’t be a surprise the open software became common also in the enterprise sector (The State of Enterprise Open Source, 2020, Red Hat).
Does that mean OTRS and other open‑source applications became just as secure as the proprietary counterparts?
They always were so. It’s a myth the easy availability of the source code impairs the application’s security. It does happen, though, that the open‑source solutions are deployed by companies not ready to support them. It cannot be stressed enough that whenever one’s hosting and managing software on their own, maintaining a high security standard (for instance reacting to newly detected vulnerabilities) is now their job too. It’s especially important in the case of externally accessible systems, often used via a web browser, such as OTRS and other software facing the end‑user.
Of course one doesn’t need to possess the know‑how and maintain their OTRS instance on their own. It all can be outsourced: from the security audits, to the maintenance of the IT systems and servers.
So it’s not enough to just install the software and expect it to stay secure?
It’s unbelievable how many companies operate this way, exposing their systems to attacks. 9 out of 10 systems used commercially contain open‑source components that are either outdated or no longer maintained (OSSRA, 2020, Synopsys). It’s to be expected they will get compromised sooner or later.
If you’re using OTRS version 4 or 5, it’s high time to migrate to a newer version.
What can be the consequences of such a breach?
For example loss of important data or leak of sensitive data, often resulting in a GDPR violation these days. It’s also not uncommon for the attacker to modify the company systems to sabotage them, to facilitate corporate espionage or even just for ransom.
I’m assuming such targets are usually big companies. Should a smaller company, for example a small e‑commerce company handling tickets using OTRS, be worried?
In the Internet no one is small or insignificant enough to be safe. Lots of attacks are fully automated, with no human directly involved. A software scanning the Internet is looking for targets with known vulnerabilities exposed. Millions of such scanners are running as we speak.
How should we protect against them? Is keeping OTRS up to date be enough?
It’s one of the ways. If you’re using OTRS version 4 or 5, it’s high time to migrate to a newer version. In 2019 the OTRS vendor stopped supporting OTRS below version 6. If somebody discovers a new vulnerability in an older version it won’t get patched by OTRS AG. It shouldn’t surprise that the developers focus their efforts on perfecting the current version (including the commercial one) instead of supporting legacy versions phased out years ago.
One also cannot neglect updating the applications used along with OTRS.
How can I get information about the newly discovered vulnerabilities?
The social media such as Reddit can be very helpful, additionally Zero Day Initiative and similar websites. Tools such as Shodan can also help in the hands of an expert. But tracking the news is only the first step. The second—and crucial!—one is reacting to these new vulnerabilities.
Creating a permanent position for a specialist responsible solely for the IT security isn’t always viable. Vulnerability monitoring and emergency intervention can be outsourced to an external company that specializes in the technologies used internally.
What are some other ways to strengthen the security of OTRS?
One of the simplest—and the most effective!—ways is to isolate the application from the Internet. If one’s using OTRS to handle only internal tickets, there is no need to expose OTRS to the Internet.
It’s more complex when external users also need to access such a system. If one needs to support only a well known group of users, VPN (Virtual Private Network) is a good solution. It allows to create networks that behave like the internal ones regardless of the actual network topology. An OTRS instance running in such a network is inaccessible to anyone not connected to such VPN.
Of course the other countermeasures and keeping the software up to date is still highly recommended as it takes only one compromised user, for example with a malware on their workstation, for the VPN to stop being impenetrable.
Tracking the news is only the first step. The second—and crucial!—one is reacting to these new vulnerabilities.
Wouldn’t it be enough to create a list of addresses allowed to connect to our application?
I strongly recommend against using such lists. It’s a common half-measure that gives an illusion of security. An attacker can spoof their source address, pretending to originate from one of the allowed IP addresses. They won’t get a response (which will be sent to the real allowed client) from the server but in many cases they will still be able to at least disrupt the systems. If it’s feasible to use a VPN, always prefer it over such lists.
Is it possible to increase the security of an OTRS instance that needs to be publicly accessible?
Yes. If OTRS needs to be exposed to the Internet, one should consider disabling any not used features and services. Each and every enabled admin panel or means of remote access is a potential vulnerability.
What other security measures may be worthwhile?
You can use mandatory access control (MAC). Systems such as SELinux or AppArmor allow to limit and minimize the damage the attacker can cause in case of a successful security breach.
Intrusion detection systems—such as AIDE, Tripwire or Snort—can detect modifications introduced by the attacker, which in turn allow to estimate what else should be considered compromised. Some of these systems, including the mentioned Snort, can also block suspicious activity of a presumed attacker.
On the other hand thanks to a web application firewall (WAF) it’s possible to block the known attack types long before they reach the application itself.
Sum‑up: a Checklist for OTRS Security
Take advantage of a ready‑to‑use checklist and secure your OTRS effectively.
Need additional support? Schedule a free consultation and tell us about your needs.