ULYSSIS security measures
ULYSSIS considers security an important part of its services. While we of course make sure our software is up-to-date, there is also the security of the applications our users use, the emails they receive, and the account they have on our servers. Even though it's obvious our users are responsible for their own software, passwords and emails, we attempt to safeguard them from harm and adhere to good general standards as well as those agreed upon with KU Leuven ICTS when we started.
Web
As the main service of our hosting accounts, most of our security revolves around securing the many applications our users run. The main responsibility for these applications lies of course with the users who should frequently apply updates and make sure the code they write is secure.
General measures
Under normal circumstances, most web applications will not have interaction with non-http(s) third party applications and APIs (if they have any external interaction in the first place), therefore we only allow general outgoing connections from our webworkers to ports 80 and 443. Based on requests from users and ICTS, we do allow specific outgoing connections to the KU Leuven LDAP and KU Leuven Dingnet MQTT server. If you require access to an unusual port on a specific service, preferably of some kind of academic value or offered by KU Leuven, feel free to contact us with a description of what you would like to do and what services, IP addresses and ports are relevant (and why).
As part of our arrangement with KU Leuven ICTS, we pass all our mail through their central email and anti-virus system (CAV). Because of this restriction, it's not possible to connect to external services for email from within our network. You can however easily use local email on our servers, which will be processed as you would expect. To prevent spam and other problems, we do monitor volume and assess spaminess before forwarding emails. More details are available on Sending email from websites and in the section about email on this page.
Most users are aware of Google and Bing, as well as their bots that scan the internet for interesting and useful websites. There are however many other search bots out there, some of which have far from the best reputation. These cause problems with high amounts of traffic due to lack of rate limiting within these bots (which can create problems for resource usage) and almost always collect data for commercial use within products such as SEO services. As these search bots bring no real benefits to our users, bots such as AhrefsBot, Majestic12 and LinkdexBot have been blocked from visiting our webservers in general.
Beyond these measures, we also make sure to follow-up any problematic situation and move to suspend the user or website to prevent further harm. Some of these situations include sudden spikes in resource usage, unexpected large email queues, large email delivery failures, high amounts of attempts to connect to blocked ports, or the use of very insecure/outdated software.
CMSs and other popular software
On CMSs and certain pieces of popular software, security is even more important as they are often attacked. Installing updates frequently is therefore paramount. To make sure updates are taken seriously, we have implemented a Software Version Checker for organisation and kring accounts.
Beyond updates, common or short passwords can also be a big problem with CMSs. With the growing popularity of WordPress, we've noticed more frequent dictionary and brute force attacks on WordPress login forms and XML RPC management interfaces. To protect our users, as well as to prevent problematic increases in traffic and resource usage, we automatically block IPs that attempt to access wp-login.php or xmlrpc.php too often and we've installed extra monitoring systems. This of course doesn't mean we don't expect our users to use strong passwords and perhaps even consider disabling XML RPC.
Email and spam
All emails that are processed by ULYSSIS pass through our spam setup as well as the central anti-virus (CAV) of the KU Leuven. While the KU Leuven focuses specifically on malware, we apply a more broad approach. Every email is given a spam score based on its headers and content. The score and tests are included in every email. If the score surpasses 5.0, the email is marked as spam but still delivered, if it surpasses 7.5 it is no longer delivered. Emails that include executables (even hidden within an archive or a screensaver) are never delivered and our team is notified. As we receive a lot of exotic spam that is often not in English, regular spam rules often don't suffice to prevent spam from being delivered. At ULYSSIS we therefore use a large set of custom spam rules we've written based on samples. Please refer to the spam article on this documentation website for details on how to submit spam samples. If you are having issues with emails that are processed by our servers being marked as spam, keep in mind that as our email has to pass through the CAV, we depend on the KU Leuven to maintain a good reputation with other email providers.
Other
Beyond specific measures on our web and email services, we also take certain security measures on other services or on our entire network.
Shellservers
On our shellservers we implement a simple technique to prevent brute forcing or dictionary attacks through SSH by temporarily blocking IP addresses after several failed login attempts. While this usually goes completely unnoticed by users, in circumstances where a user uses the wrong password many times, they may get hit by this security measure and would have to either wait for a few minutes or try to connect to our other shellserver.
Similar to all of our webservers, connecting to external email servers is not allowed. You can refer to that part of this article or to Sending email from websites for more information.
Blocklists
We maintain automatic as well as manual blocklists to prevent spam and attacks from IP addresses or ranges that are known to commit these kinds of actions. We only block those IP addresses that have been implicated in illegal activities, and try to always prevent undue implications for addresses within the same range that have not necessarily been part of any activity. In case of addresses that may change operator, we may also consider a block to be temporary.
