After a flawless year, Symfony unveiled this November 6, 2024 on its blog eight vulnerabilities at once. They affect different versions of the Symfony framework. Here's a summary of these critical vulnerabilities, their potential impact, and the solutions implemented by Symfony. It will help you understand the implications of these vulnerabilities for securing your applications.
Contents
Introduction
Even the most renowned frameworks, such as Symfony, are never immune to security flaws. Whatever application solution you choose, you need to be vigilant. Safeguards such as a ModSecurity application firewall and automatic attacker blocking (fail2ban), combined with a good outsourced backup policy, are essential.
On LRob secure web hosting, our Linux servers support your application security with ModSecurity combined with fail2ban actively blocking attempts to exploit vulnerabilities; full outsourced backups are made daily with a one-year retention period. Choose LRob as your hosting provider, is to benefit from a simple, secure hosting solution while adding a rigorous, available and passionate sysadmin to your team!
Symfony security holes (November 2024)
CVE-2024-51736: Hijacking command execution on Windows with the Process class
Description This flaw enables execution to be diverted on Windows systems when the executable file cmd.exe is in the current working directory. The class Process could then execute this file, paving the way for malicious hijacking.
Resolution Symfony has corrected this problem by forcing the Process to use the absolute path to cmd.exe.
Description Validation using a regular expression could be bypassed by inserting a \n at the end of the input, resulting in an incorrect response from the Validator.
Resolution Symfony now uses the regex modifier D to guarantee validation of the entire input.
Twig CVE-2024-51754: Unprotected calls to __toString() in a sandbox
Versions concerned Twig versions =3.12, <3.14.1.
Description In a sandbox environment, an attacker could call the __toString() of an object, even if this method was not authorized by the security policy, opening the door to a circumvention of sandbox restrictions.
Resolution Sandbox mode now systematically checks the call to __toString() on all objects.
Twig CVE-2024-51755: Unprotected calls to __isset() and Array object accesses in a sandbox
Versions concerned Twig versions =3.12, <3.14.1.
Description In a sandbox environment, array-like objects could expose attributes without security checks. This allowed an attacker to access potentially sensitive properties.
Resolution Sandbox mode now controls the properties of Array objects and the call to __isset() after safety check.
These eight flaws show that even the most robust frameworks like Symfony are not immune to security vulnerabilities. Fortunately, the Symfony team reacted quickly to provide patches. And as it should be, the vulnerabilities were only made public after they had been patched. If you're using Symfony, make sure you update as soon as possible to protect your applications and your users.
Never forget that no software solution is free from security flaws. Your vigilance must be continuous, and regular updates remain the best line of defense against security flaws and cyberthreats.
At LRob, our servers offer optimal security:
No Windows vulnerability : As our servers run on Linux, they are not affected by Windows-specific vulnerabilities.
Server application update Server software is updated daily and monitored 24/7.
ModSecurity firewall : By actively filtering malicious requests, our firewall protects your applications.
Outsourced backups : We have daily outsourced backups to facilitate data recovery in the event of an incident, and you can also make your own backups to the FTP of your choice (e.g. via a VPS Storage Cloud from PulseHeberg) via Plesk.
By default, Plesk uses NGINX as a reverse proxy for Apache. But is this default configuration optimal? What impact does it have on performance? To answer these questions, I carried out load tests on a Hetzner VPS (8 AMD Epyc cores) to measure the impact of enabling NGINX as a reverse proxy on overall performance.
Contents
Context and configuration
As part of this benchmark, I compared server performance with NGINX enabled and disabled. I also tested NGINX cache activation (and that changes everything!).
Load tests were carried out using ApacheBench (ab), sending 5000 requests locally with a concurrency of 200 simultaneous requests. This ensured that the test lasted long enough to limit the margin of error. It should be noted that the test site is very light and high-performing compared with the average, with only 50 to 80ms TTFB (response time).
Here are the main configurations:
Server 8-core Hetzner VPS (AMD Epyc)
Web server Plesk 18.0.65 with Apache + NGINX as reverse proxy
Test site : LRob.fr a WordPress FSE website, Twenty Twenty-Four theme with Breeze cache
Test commands : ab -n 5000 -c 200 https://www.lrob.fr/
With the default configuration (NGINX enabled), the server operates correctly, but a CPU bottleneck was observed. Overall CPU utilization (all cores) did not exceed 85 % in the load test, with the NGINX process also bottlenecked around 85%.
Without NGINX, Apache handles requests directly. The results show a +33% improvement in performance.
But the surprise is when the NGINX cache is activated and manages static files directly. Performance gains of +66%! And that's not all: we've also seen a reduction in CPU core utilization to 30%, leaving plenty of CPU available for other essential uses such as PHP-FPM or MariaDB/MySQL. NGINX, however, is limited to 99% CPU usage (i.e. one core): Perhaps it's possible to extend its use to several CPU cores and boost results even further. At the time of testing, I still had 5 to 6 CPU cores available, enough to potentially multiply this result by 2 or 3. This is worth investigating further.
Other considerations concerning NGINX and Plesk
Plesk favors the use of NGINX with several advantages that may justify its activation:
Enhanced certificate generation For example, Plesk allows you to generate a certificate for webmail only, when NGINX is in place.
Security Functions such as OCSP Stapling are available in 1 click, only with NGINX.
I may be missing other advantages. The disadvantage is, of course, that you then have two web applications, which slightly increase the complexity of the installation.
Conclusion
Using NGINX as a reverse proxy under Plesk can be extremely powerful for static sites, or when combined with a good caching system (see cache comparison for WordPress). But according to my test, it is essential to modify the NGINX settings to obtain a performance gain rather than a reduction compared to Apache alone.
What's more, results can vary greatly depending on your end-applications (your sites) and their caches. If necessary, use my test methodology to make your own measurements and comparisons. I'm interested in your feedback: share your results in the comments!
WordPress updates, whether manual or automatic, always raise questions and even fears among webmasters. These updates are necessary for the security and scalability of your site, but they also entail risks. So should you activate WordPress automatic updates? Let's explore the issues.
Contents
Manual updates
Regardless of whether you update manually or automatically, the risks are there.
All in all, no matter whether the update is automatic or manual, you're bound to run into problems sooner or later.
What are the risks of WordPress updates?
From simple bugs to site inaccessibility, here are the most common problems:
Action required : Sometimes an update requires manual intervention to adjust certain parameters or configurations.
A plugin or theme has a bug : An update can introduce a malfunction, especially if the plugin or theme is no longer maintained by its developers.
Version incompatibility A plugin or addon depends on another plugin and may not be updated as frequently, creating conflicts.
How to reduce risk
To avoid these risks and inconveniences, a staging process is necessary: this consists of trying out every update in a test environment before applying it in production. However, this practice requires considerable time and resources, which is not feasible for smaller sites.
Automatic updates
What are the advantages of WordPress automatic updates?
Switching to automatic updates saves time and increases security.
It's just a few clicks from your Plesk control panel. You have the option of disabling automatic updates for any plugins that cause problems.
1. Safety gain
By activating automatic updates, your site is protected against the latest security vulnerabilities as soon as they are identified. This reduces the risk of hacking and keeps your site safe without systematic manual intervention.
2. Save time and energy
Automatic updates reduce the need for frequent intervention. Instead of manually checking for new versions of plugins or WordPress, you save precious time that can be reinvested in higher value-added tasks.
3. More minor bugs
Thanks to regular updates, the bugs encountered will be more minor overall, simply because the changes are more minor. What's more, diagnosis will be simpler: if one plugin is causing a problem, you'll quickly find which of the few recently modified scripts is causing the problem, whereas if all plugins have received an update, you'll have to test them all one by one.
Requirements for automatic updates
With automatic updates, there are even more important prerequisites than with manual updates.
1. Automated and outsourced backups
Backups are essential in some cases. It is therefore important to have regular, outsourced backups with long retention times. These backups must be selectively and easily restorable.
On the LRob web hostingwe perform a host backup going back 1 year.
2. Site monitoring
You should monitor the response of your sites and check them manually from time to time.
You need to react quickly if necessary, to prevent a problem from affecting your site for too long. And you need to have the right tools to diagnose (access to logs, phpMyAdmin, file explorer, deactivation of plugins from the hosting panel - all available on the LRob web hosting). Your LRob support can help you diagnose and solve your problem, by getting involved in WordPress research and diagnostics.
What should I do if I have a problem with a WordPress update?
If an update causes a problem, you need to react quickly and effectively:
View logs Server logs can quickly reveal the source of the problem.
Deactivate the offending plugin If you can do without it, deactivate the plugin concerned.
Adapt settings : Sometimes a simple setting change is enough to solve the problem.
Developer support Contact support for the plugin or theme concerned to report the problem and get help.
Restore a backup If the problem is critical and has no immediate solution, then a backup restore may be necessary. In this case, it may make sense to temporarily suspend (automatic) updates until a solution is found. If you don't have a backup on your side, your LRob support can restore its host backup.
Contact your LRob support We manage a large number of sites, so it's highly likely that we've already spent hours solving a similar problem, or that our experience will enable us to find your solution very quickly. We're always happy to help you save time!
In short: manual or automatic update?
Manual update
By updating manually, you delay the appearance of problems that you'll have to solve sooner or later, while exposing yourself to more security holes.
This choice may be appropriate for very complex sites, subject to potential bugs and requiring more extensive monitoring.
Automatic update
In auto MAJ you risk a temporary bug, so you have to deal with the (rare) problems as soon as they appear.
The exception: complex sites
The exception being large, complex sites, such as WooCommerce with custom dev, where in this case it's better to staging and testing each update (max. every 3 months, or when a known security flaw appears), for an appropriate maintenance fee.
With a professional hosting service, such as that offered by LRobYou can benefit from technical support and extended backups, up to a year in the past, to secure your site against unforeseen events.
Conclusion
Overall, we feel that automatic updating should be your default choice, as security takes precedence over functionality. If you're "agile", then this shouldn't be a problem. After all, it's better to have a bug to fix than a hacked site and all its consequences to deal with. Small and medium-sized structures will often benefit more from automatic updates, while more complex sites require specific, in-depth maintenance management.
If you're ready to embrace automatic updates, make sure you have backups and a monitoring strategy in place to deal effectively with the rare incidents that might arise.
👉 For simplified management of your WordPress site, discover accommodation offers LRob and benefit from our expertise to avoid or solve technical problems and keep your site online, secure and performing.
Discover WPMasterToolKit the essential plugin to simplify your life and lighten your WordPress sites.
This made-in-France plugin, developed by Webdeclic's talented Ludwig YOU, brings together a host of essential WordPress features, each of which you can activate with a single click. All in a single extension: simplifying your management while speeding up your site! 🚀
A truly different plugin
WPMasterToolKit is simple and flexible. With over 83 free features already activated, this plugin lets you replace countless extensions with just one.
What makes WPMasterToolKit unique, apart from being French, is its ability to activate only the features you need, without unnecessarily burdening your site. Where other extensions are monolithic, loading unnecessary scripts even when you're not using them, WPMasterToolKit is designed to be light and efficient.
If a feature is disabled, the associated program won't load at all. In this way, you reduce your site's resource use and improve its performance, by loading only the features you really need.
Other functionalities are in the pipeline, and some are available as premium features to perpetuate the project.
The developer, Ludwig YOU, is very attentive to suggestions and is actively improving his plugin. This includes the recent addition of a tab that lets you see active features at a glance.
Key features of WPMasterToolKit
WPMasterToolkit: Active modules on the LRob.fr website
Here are some of my favorite features so far:
1. Hide WordPress version
Hiding the WordPress version displayed in the source code is an excellent security measure. It reduces the chances of your site being targeted by automated attacks aimed at specific WordPress versions.
2. Limitation of revisions
Managing content revisions is an often overlooked point that can quickly overload the database. WPMasterToolKit allows you to limit the number of revisions per article, which helps keep the database clean and efficient.
3. Disable emoji support
Emojis are useful for some sites, but most modern browsers already natively support these symbols. Disabling support for emojis in WordPress can reduce page load times.
4. Disable Really Simple Discovery (RSD) tags
By disabling the loading of RSD tags (and scripts like Dashicons for offline visitors), you can reduce the loading time of your public pages, especially if your site doesn't use third-party services that require these elements.
5. Disable jQuery Migrate
If your site uses recent versions of jQuery, the script jQuery Migrate becomes useless and can be disabled to improve page loading speed.
Other interesting features
In addition to these favorite features, WPMasterToolKit also offers a host of tools to make the day-to-day management of your site easier. Among the most popular are :
Self-publishing of missed articles Automatically publish items that have missed their planning date.
SMTP management Connects to a third-party SMTP server to relay your e-mails more reliably.
Disabling REST APIs for unauthenticated users REST: improves security by limiting access to data via the REST API.
Email ban Block the creation of user accounts with temporary or unauthorized email addresses.
Maintenance mode displays a customized maintenance page while you're working, without hindering administrators.
Redirect 404s to home page Enhances the user experience by redirecting non-existent pages to the home page.
And many more besides... The best thing is to explore and test for yourself! Who knows, you could replace dozens of plugins!
An essential WordPress toolkit that needs to be better known
With a host of customizable features, you have everything you need to customize and control your site, improve performance and enhance security.
At the time of writing, this new plugin has over 500 active installations. For me, this plugin is a real game changer, and I'm convinced that it will pass the thousand mark well before the end of the year, and that its popularity will then explode.
Finding the best cache plugin isn't easy. You have to test it, measure its performance, find out about its long-term support...
So what's the fastest cache? What's the best cache plugin? Which are practical and complete, which are efficient? Do I need to pay for a good cache plugin?
Today, we're trying to answer these questions with independent measurements that are as objective as possible. The test is a bit "meta" in that it involves testing on lrob.fra showcase/blog created with FSE (full site editing). A standard, lightweight site.
Contents
Introduction
The objective of a cache plugin: to fall below 200ms response time or "TTFB" (Time To First Byte; 200ms is the maximum time recommended by Google PageSpeed Insights).
But not all caches are created equal, as Yoan De Macedo reminds us in his blog post. Some perform better than others, while others may even degrade performance. So to really choose the best cache, you need to test several on your own site and measure the results precisely. Given the variability of response times, it's important to carry out tests over a period of time and average the results. This can be tedious, however, so you may want to use this comparison test as a starting point.
We also remind you that caching isn't everything. Caching can reduce server resources, but your site must be optimized from the outset. Otherwise, it's called "cache misery". So opt for lightweight, well-optimized plugins and themes to avoid unpleasant surprises. The cache will then be the icing on the cake.
Plugins tested
I have based this list of plugins to test on a "top" list of caching plugins as well as on my experience with plugins actually encountered by various hosted customers:
This LRob test is in no way sponsored by any caching plugin. It is intended to be as objective as possible. However, this test is only a reflection of itself and of our opinion, which cannot be perfectly objective and is therefore not intended to produce general truths. LRob is a independent web host specializing in WordPress.
Website details
The test is performed on https://www.lrob.fr/. The WP-Cron function is deactivated and executed directly by the server every 4 minutes. The site runs under PHP 8.3.12 in dedicated FPM behind Apache 2, with MariaDB 11.4. Redis server is also available on the host server (version 5:6.0.16).
Theme
The site is built with FSE and the Twenty Twenty-Four theme.
Plugins
The site has 17 active plugins at the time of testing (not including the cache plugin tested):
See the list of plugins
How to use Blacklist Updater
Complianz | GDPR/CCPA Cookie Consent
Connect Matomo
Easy WP SMTP
hCaptcha for WP
Insert PHP Code Snippet
Optimize Database after Deleting Revisions
Rank Math SEO
Regenerate Thumbnails
Simple Local Avatars
Site Reviews
Social Sharing Block
TranslatePress - Developer
TranslatePress - Multilingual
Update URLs
WPForms Lite
WPMasterToolKit
Measurements and details
Response time is measured with Uptime Kuma on a server at PulseHeberg in Switzerland (Lausanne), which provides this average. The production server is located at Hetzner in Falkenstein, Germany.
Each plugin is tested successively, with a measurement every 20 seconds for 5 minutes or more (sometimes I went for a coffee in between), i.e. a minimum of 15 measurements to obtain a consistent average.
Between each test, Uptime Kuma's recorded values are erased after an initial measurement once the cache is in place; the cache folder is deleted and it has been verified that the .htaccess and wp-config.php are indeed free of any trace of the previous plugin.
Protocol limitations
The test was carried out on a server in production, generating a slightly higher variability of results than that observed on a server with no activity. However, server usage is very moderate at the time of the test, and the variability is offset by a series of over 15 measurements each time, enabling the results to be averaged. The aim is not to get the value to the nearest millisecond, but to obtain an order of magnitude.
Furthermore, the test was carried out on a specific site and cannot be extrapolated to all sites: every site is different and will respond differently to certain plugins (particularly stores). But if your site is made with the Twenty Twenty-Four theme or another FSE (Full Site Editing) theme, then chances are your results will be similar.
Tests and Benchmarks
Baseline - Test control: Response without cache plugin
Without any caching plugins, the site responds in 379ms on average, with little variability. This is a relatively low base value, since sites made with builders can easily take 2 to 4x this response time.
Response time without cache
Let's take a look at how different caching plugins improve response times.
The response time is identical to the site without cache. And for good reason: Autoptimize's caching function is in fact only available with the paid plugin. In other words, you won't be able to speed up your site with the free version. That's a shame.
However, as the developer points out Simon JANVIERAutoptimize, in its free version, is more useful for intelligent concatenation and minification of scripts. In this respect, it can lighten your site, but will not improve its TTFB (response time).
Breeze
Contrary to what I initially thought, Breeze isn't just for Cloudways or Varnish, it also works on a classic system. I therefore add it to this test and thank Michael GOUT for bringing this plugin to my attention.
Breeze 1 settingsBreeze 2 settings
Breeze response time: 98ms
Average response: 98ms
The result is amazing: under 100ms with very stable response times! I'm just discovering this plugin and I'm falling out of my chair!
I have a minor reservation about the plugin's compatibility with all sites, due to the comments on wordpress.org. From these comments, it seems that its use could cause some problems with the most dynamic or complex sites, such as WooCommerce e-commerce sites.
For the rest, it seems an excellent choice not to be missed.
Cachify
Cachify offers database caching by default, and also supports file and Redis caching. We tested the default cache and Redis. Apart from that, very few other settings are available to us.
The results are similar between the "Database" cache and Redis, within the margin of error. However, the results seem to be more stable with Redis. In all cases, the result exceeds the expected 200ms, which is disappointing. This plugin cannot really be recommended.
LiteSpeed Cache
LiteSpeed Cache has been in the news a lot recently for its security flaws. The plugin also claims to correspond to an Apache server. So how does it fare in practice?
A disappointing result for LiteSpeed cache on our test configuration, since the site is within the margin of error of the site's original response time, without cache.
And for good reason, as Louis ChanceLiteSpeed, as its name suggests, doesn't cache anything on an Apache server! You need an available LiteSpeed server. We can't recommend this plugin if you're running Apache, given the performance it delivers and the many recent security flaws.
W3 Total Cache
W3 Total Cache offers a configuration wizard and numerous settings. It's the most complete free plugin I know. It supports various cache types, including Redis. Here, minification has been activated, which may slightly increase the measured response time but offers better performance for visitors with slower connections (mobile, ADSL, etc.).
Settings W3 Total Cache 1W3 Total Cache 2 settingsW3 settings Total Cache 3W3 settings Total Cache 4Minifcation W3 Total Cache settingsW3 Total Cache response time: 159ms
Average response: 159ms
Finally, a result under 200ms! With Redis, so avoiding thousands of cache files. And great control over settings and options like Lazy Load for images, and disabling certain optional WordPress scripts. Its versatile configuration will enable you to adapt more precisely to each site: you can measure the performance obtained with different settings and choose the most relevant for your specific site.
In addition, the other types of cache available also perform well, although not tested today, the results are fairly similar whatever the type of cache chosen.
In our experience, this plugin has never disappointed, so it's highly recommendable. (It's even LRob.fr)
WP Fastest Cache
This plugin offers some interesting options in its free version. However, some of the options offered free with W3 Total Cache are missing.
But the most important thing today: does this plugin live up to its name, by actually being the fastest?
This plugin lives up to its name, being one of the fastest tested! In our test, however, Breeze came out on top.
At LRob, we've seen many diverse blogs achieve great results with this plugin. It has never disappointed, and we recommend it without hesitation.
WP-Optimize
WP-Optimize offers very few cache settings. In fact, its primary function seems to be database cleansing. So how does it fare when it comes to caching?
Response time variability is too high for our liking, with responses oscillating between 132 and 180ms.
Nevertheless, the average remains very good at 152ms. A pleasant surprise.
We're not at all reassured by this variability, and so don't recommend this plugin as a cache. All the more so as we've already observed sites that were slower with this plugin than without... So use it with caution as a cache.
Solid Performance
As a bonus, I'd like you to try out a new caching plugin, Solid Performance, which looks promising. (thanks to Julien ROUSSEL for recommendation).
Although it provides no adjustment whatsoever, its measured response time is among the best in this test. Enough to potentially satisfy those who don't feel like making the slightest adjustment. As the plugin is young, it hasn't yet been tested, but a cache plugin can easily be changed if necessary in most cases, so there's not much risk in trying it out if you feel like it!
Summary of results and conclusion
Plugin
Average response (ms)
Percentage (lower is better)
Baseline (no cache)
379
100%
Autoptimize
379
100%
Breeze 🥇
98
25.8%
Cachify Database
257
67.8%
Cachify Redis
263
69.4%
LiteSpeed
376
99.2%
W3 Total Cache Redis 🥉
159
41.9%
WP Fastest Cache 🥈
123
32.4%
WP-Optimize
152
40.1%
Solid Performance
155
40.9%
We have no hesitation in recommending Breeze, WP Fastest Cache and W3 Total Cache which are all excellent. They offer very good response times with sufficient settings, even in the free version. It should be noted, however, that Breeze may cause a few problems on some sites. Also, W3 is a little more complete in the free version than WP Fastest Cache, which is why it has been chosen for WP Fastest Cache. LRob.frbut Breeze could potentially replace it in the long term, as it provides almost as many functions while being simpler to use.
In summary, according to our test :
Choose Breeze for maximum performance, rather for showcase sites
Choose W3 Total Cache for the highest level of customization, or if your host supports Redis (as is the case with LRob accommodation)
Choose WP Fastest Cache for excellent performance without configuration
A mention for WP-Optimize, which despite its lack of settings and wide variability in response time, shows a perfectly decent average response time. Mention also to Solid Performance which, as a newcomer, lives up to its name and looks promising without revolutionizing anything, as it stands, due to its lack of settings. Cachify's settings and performance are inferior to those of other plugins. We can't comment on LiteSpeed in our Apache configuration (except to say that its usefulness is very limited in this type of configuration). Autoptimize, finally, offers no improvement in loading times and is therefore totally useless for this purpose, according to our measurements, but could be used in conjunction with a caching plugin to reduce the number of files.
Given the good results obtained with these free plugins, it doesn't seem essential to pay for a cache plugin if you don't need the additional functions offered. We may, however, test the paid versions in a future article, if you're interested.
It goes without saying that high-performance hosting is essential to achieve the best response times. To achieve this LRob accommodation are here to serve you (in every sense of the word)!
Specialized WordPress hosting
Convenient, free, fast and secure
WordPress, Best CMS for 20 years
Much more than traditional hosting: benefit from simplified management and security tools for WordPress. With expert support included!
Like every 6 months, Nextcloud has just released its new major version. Official release notes are quite limited and nobody wants to read the complete changelog... with 2,363 cumulative changes to Nextcloud 30.0.0 and 30.0.1.
Patches, new features, enhancements, dependency updates, and so on. It's all quite complex to analyze and summarize. Fortunately, ChatGPT can summarize it all (over 2,400 lines of text and 172,879 characters).
So to save hours in your life, here's the ChatGPT summary of what to remember from the Nextcloud 30 changelogs :
System and database updates :
PHP 8.0 is no longer supported, while PHP 8.1 is obsolete but still usable.
Support for MariaDB 10.3 and 10.5 and PostgreSQL 9.4 have been removed.
Configuration enhancements :
New parameters in the configuration file have been introduced, and some are deprecated:
The blacklisted_files is replaced by forbidden_filenames.
New options such as forbidden_filename_basenames and forbidden_filename_extensions allow greater control over blocked file names and extensions.
Improved image management WebP in web server configuration.
File and folder management :
Users can now view theoriginal location of deleted files in the recycle garbage can, and certain file/folder attributes are inherited to preserve the shared state.
Improving file previews PDF previews now use the new provider ImaginaryPDF.
Performance and optimization :
Several performance enhancements, including the delayed loading features such as metadata generation and improved task management cron to reduce server load.
Improved sorting and drag & drop in file management, with improved support for hidden files.
Security and user management :
Introduction of a task processing API to manage background tasks more efficiently.
New safety features, such as tighter control of CSRFbetter password management for file shares, and automatic cleaning of application passwords unused.
Improvements for LDAPwith improved synchronization of users and groups, and enhanced logging of LDAP connections.
User interface and customization :
Enhanced user interface, with color separation primary and background for a cleaner header menu, and interface color enhancements.
Introduction of Vue.js for several dialogs, replacing older jQuery UI components for a better user experience.
Updates to dashboard with layout enhancements and APIs for greater customization.
Improved collaboration and sharing :
New options for file requestswhich makes it easier to request files from other users.
Various enhancements to shareincluding improved expiration dates for public shares and password protection options.
Bug fixes and miscellaneous :
Corrections related to session managementerror management and integration LDAP.
Improvements in the management of certain file types, synchronization of calendarsand user notifications.
These changes focus on performance, security and improved user experience, both in administration settings and in day-to-day file management.
Update for Nextcloud customers at LRob
Version 30 of Nextcloud is entering the testing phase on our side, with a view to wider roll-out to all customers.
The conflict between Matt Mullenwegfounder of WordPress and WP Engine continues to shake up the WordPress community. The latest development in this affair concerns a major plugin in the ecosystem: Advanced Custom Fields (ACF). Since October 12, 2024, ACF has been completely replaced on the official WordPress.org directory by Secure Custom Fields (SCF).a fork set up by the WordPress security team.
This dispute over ACF is just one of the many steps in the growing tension between Matt Mullenweg and WP Engine. The relationship between these two major players in the WordPress ecosystem degenerated due to differences over the management of the WordPress brand, project governance, and certain WP Engine business practices. These tensions intensified when Mullenweg openly criticized WP Engine, accusing it of harming the ecosystem by disabling certain crucial features (such as revision history), and of muddying the waters with the use of the "WP" brand.
This conflict raises questions about WordPress governance and open source management in an environment where commercial interests are at stake.
In a post published on October 12, 2024, Matt Mullenweg announced the creation of Secure Custom Fields as a fork of ACF to meet a specific critical security flaw discovered in the original plugin.
Secure Custom Fields replaces ACF on WordPress.org and all sites that used to use ACF via this repository will automatically switch to SCF on upgrade.
We can't help but think that the tensions between the two companies have a lot to do with this decision. But we're not in Matt Mullenweg's shoes, who, as an intelligent and committed member of the WordPress project, probably has good reasons for making this choice.
ACF team reaction
Faced with this change, the ACF team expressed its disappointment and concern in an article published on their official blog. They are denouncing a decision which they consider to be unilateral and which, in their view, is in the interests of the company, goes against open source principles. Since joining WP Engine, they have worked continuously on the development of ACF, with over 200,000 lines of code and numerous improvements, both in terms of functionality and security.
Here's what they say in their post:
"We are appalled by the actions of Matt Mullenweg, who has unilaterally and without our consent taken control of the Advanced Custom Fields plugin, a tool we have been actively developing for the WordPress community since 2011."
The ACF team advises that users of ACF Pro or those hosted on WP Engine and Flywheel are not affected by this change and will continue to receive updates directly via WP Engine. On the other hand, those using the free version of ACF on other hostings must manually download version 6.3.8 of ACF from their site to continue to benefit from updates on their side.
ACF indicates how to continue using its own version of the plugin if you are using the free version of ACF on a host other than your own (WP Engine).
Finally, it is playing the loyalty card on its site with a special insert on the home page:
Insert on ACF home page
"You've trusted ACF for more than a decade. The experts who maintain ACF will continue to support and enhance the features our users value and trust."
However, these plugins are less essential than ACF and can be replaced by Update URLs and Query Monitor to name but a few.
Impact on users
Differences between ACF and SCF
For the time being, the two free plugins are functionally identical, as the fork is very recent. We'll have to follow their respective developments to see if one of them stands out for its stability, security or functionality.
It's conceivable that ACF will eventually be integrated into the WordPress core. We'll just have to wait and see.
Pay version of ACF
For the paid version of ACF and WP Engine clients, there are no changes to be expected.
Free version of ACF
If you are using the free version of ACF on the original WordPress.org, at a independent host like LRob :
When your plugins are updated, ACF will be transformed into SCF, then maintained by the WordPress community.
If you're using other WP Engine plugins, consider finding a replacement if their access to WordPress.org isn't restored.
Conclusion
Although this conflict may raise concerns, it is important to remember that Matt Mullenweg has always been committed to maintaining the integrity and security of the WordPress ecosystem. Secure Custom Fields was introduced in this spirit, and despite criticism, Mullenweg remains a respected figure in the community.
While we wait for the situation to become clearer, let's remain cautious about our opinions and keep an eye out for updates and news on this subject.
Seeing an IP blacklisted is part and parcel of life as a web host, a daily occurrence for the biggest and most permissive ones. Nevertheless, this is a first for LRob in its 10 years of existence!
The more positive among you will say that this is the ransom of glory... Inevitably, as the volume increases, so does the risk of unauthorized activity on a site. The most critical will cause a scandal. Whatever the case, at LRob we're committed to transparency. So we're here to answer all your questions.
What happened, and what solutions are we implementing? Here are the answers.
Discover blacklisting on AbuseIPDB
On Sunday October 13, I was alerted by my client Weather Centre that its site was blocked by the MalwareBytes paid antivirus (thanks to them for this alert).
Faced with this anomaly, LRob was in a hurry. Whether it was Sunday or Christmas Day, I immediately checked his site, which had no problems whatsoever, then investigated with MalwareBytes. The cause of the blockage was given in just 1 hour (well done MalwareBytes support): the IPv4 of the server hosting this site is blacklisted on AbuseIPDB for malicious requests. But obviously, the problem originates from another site.
Favorite AbuseIPDB
Not all blacklists are created equal (CF: SPFBL), nonetheless, AbuseIPDB is a real project, well done and serious.
In the midst of all this bad news, the discovery of this community blacklist was a stroke of genius: not only had it enabled me to detect an anomaly on my server, but it was also easy to contribute. That's why I LRob immediately joined AbuseIPDB to help report attacking IPs and help the global sysadmin community in return.
But the most important thing was to stop the source of the malicious requests. So where were they coming from?
An unexpected cause
Of course, I immediately looked for the cause of these requests emanating from one of my servers. If it's a customer, it's not tolerated. If it's a hacked site, it has to be shut down and repaired immediately... If it's a server intrusion, it's very serious. So I started investigating, and what I found was both harmless and unusual.
But recently, a newly repaired site played a nasty trick on me: a recurrence. A repaired site was hacked again, something I've never had happen to any of my hostings before.
This fell within the 90-day warranty, so I repaired the site again at no charge. But the attacks, though less frequent, continued to arrive on AbuseIPDB.
After 3 days of fruitless log searches during the day and evening, I finally analyzed all the network traffic on the server (a titanic task), until I traced one of the abnormal processes (programs) launched as the system user of this site. Eureka! I've found the root cause of the problem.
How is this possible?
I now know that, as soon as it arrived, this site actually contained malicious programs (not just PHP scripts, but actually programs), which managed to run as soon as the site was imported. This meant that even when deleted, and even with the site deactivated, the malware continued to run. Hackers were therefore able to use this as an attack vector even after the site had been repaired. They were also able to rewrite malicious files, generating visible recurrence.
As these programs were not running directly via the usual web server, but independently of it, it was impossible to detect their activity via the web server logs, making detection more difficult (which is why network traffic had to be analyzed as a last resort, which is unusual). What's more, this type of program isn't even supposed to be able to run, and for good reason: the "PHP exec()" function that launches them is supposed to be disabled... But it wasn't for this client, due to a specific configuration (since corrected). I'd already seen this problem on other servers, and if it hadn't been mine, I'd have looked directly at the processes launched and found the problem in 30 minutes... But here, as it wasn't supposed to happen, it took me 3 days. The joys of the job!
The immediate solution
All suspicious processes (running programs) were of course saved for investigation, then stopped. A complete site checkup was redone, and a manual check 3x a day was set up to ensure that no recurrences took place.
Current situation
At the time of writing, no more attacks have been reported on AbuseIPDB, but the blacklist has not yet been lifted.
Delisting
The delisting request was made on the day the problem was discovered, and can take between 7 and 10 days to be lifted. This is slow, and would be AbuseIPDB's only flaw. Fortunately, the impact of this blacklisting is fairly low until the request is lifted.
No other sites affected
Thanks to the excellent website isolation applied to my hosting, the hacked site was confined to itself and had no impact on other hosted sites.
Additional long-term solutions
The impact of this blacklisting is very minimal, as evidenced by the fact that only Weather Centre alerted me to this concern, as this is probably the most popular site I host, which means they can quickly be notified of this type of information. Thanks again to them and to MalwareBytes for their responsiveness in reporting relevant information.
Nevertheless, some customers may one day wish to avoid having their site hosted on a blacklisted IP because of a third-party website. The solution is a dedicated IP address.
That's why I'll soon be launching a dedicated IP option available to all LRob web hosting.
This requires some preparation, as adding multiple IPs to a dedicated server is not trivial. I also need to estimate and define the price of the option. When the option is launched, each LRob customer will be able to benefit from a dedicated IPv4 and IPv6 if they wish.
With a little imagination, this could also enable server migrations without IP changes, thanks to "IP Failover" (more expensive but more flexible, they can be transported from one server to another, as long as the server provider remains unchanged). This should please my resellers who don't have control over all their customers' DNS zones...!
The importance of transparency
There's no such thing as a trouble-free service. Of course, I could have hidden this minor problem and only one customer would have noticed. But at LRob, we choose to show our commitment to handling any anomaly with rigor and devotion.
Transparency is the basis of trust. And I thank you for your trust.
Replacing a wiki with WordPress: a simpler solution for documentation
At LRobDocumentation management is essential, but until recently was handled by MediaWiki. Although this tool is effective for collaborative projects, it becomes cumbersome and complicated to manage when you're the only one writing and maintaining documentation.
Working on a site WordPress websites to the numerous pages used as categories that the idea came to me: why not use WordPress to manage documentation, without the need for an additional plugin?
Why switch to WordPress?
WordPress websiteswhich runs www.lrob.fr, already offers all the basic functionality needed to organize documentation, without having to install any additional plugins. Here are some of the native advantages that prompted me to make the switch:
Page hierarchy Creating pages and sub-pages, as in a wiki, is very simple thanks to WordPress' native structure.
Gutenberg block for tree structure A block is available to display the sub-page tree of a parent page, making it easier to navigate through the documentation.
To complete this configuration, I used RankMath SEOalready present on lrob.fr, who helped me integrate two key features for a documentation site:
Breadcrumbs A breadcrumb trail to improve navigation and referencing.
Automatic summary An index of headings and subheadings, ideal for well-structured pages such as a wiki.
As a bonus, the wiki can be automatically translated into English thanks to TranslatePress and the DeepL API, which works wonders.
The transition to WordPress
On the evening of October 17th, I transferred the documentation to WordPress. The block editor Gutenberg made the process easy, preserving titles, lists and links when copying and pasting from MediaWiki. Next, I set up 301 redirects from the wiki to the new WordPress documentation pages, then deactivated the old wiki.
This morning, I took advantage of the migration to reorganize and improve part of the documentation, with a clearer, more modern layout, while adding internal links for better navigation.
Simpler, more efficient results
The switch to WordPress websites simplifies documentation management. Not only has this enabled me to eliminate the cumbersome maintenance of MediaWiki, it's also a more flexible and easy-to-use solution for me, while offering more accessible content to my customers.
Thanks to RankMath SEOThe documentation is better structured and more optimized for SEO, which should improve its online visibility.
For a long time, I've been looking for a way to effectively exploit the hacking data blocked by my servers. Intrusion attempts are constant, but thanks to security systems such as Fail2ban, attacks are stopped before they cause any damage. However, beyond simply protecting my systems and customers, I wanted to go further: share this information and make the Internet a safer place for everyone.
Over 2,000 malicious IPs reported in just 48 hours!
With this in mind LRob has started contributing to attacker reporting via AbuseIPDBa platform that allows anyone to report malicious IPs. In just 48 hoursover 2000 IP have already been reported, showing just how significant the impact of this initiative can be.
Why report malicious IPs?
Hackers attack everything, all the time. Whether you're a small business, an individual or a large organization, you're a target. However, while these attacks are relentless, the resources of cybercriminals are limited. By identifying them, we have a chance of combating them more effectively and limiting their scope for action.
There are two main reasons why reporting malicious IPs is crucial:
Identify and block attackers By reporting these IPs, you contribute to the creation of a database accessible to all, making it easier to block potential threats before they reach other infrastructures.
Informing legitimate guests Some legitimate hosts can be infected or hijacked without their knowledge, serving as relays for attacks. By reporting these IPs, you give them a chance to react and correct the situation.
Sharing information via platforms such asAbuseIPDB makes the web safer, not just for you, but for the whole community.
A simple API for efficient reporting
One of AbuseIPDB's great strengths is its ease of use. Via a API accessible to all, it's easy to contribute to the reporting of malicious IPs. By validating your identity, you can even increase the reporting limit to 5000 IP per daywhich covers a wider spectrum of attacks.
So I decided to set up a system for automate these postponements, so that the community can benefit from my data on blocked hacks. A banner is now visible at the bottom of my LRob.fr site, linking directly to my AbuseIPDB profile, where anyone can see the IPs I've reported (see my profile here).
Automated reporting with Plesk and Fail2ban
For those who, like LRob, use Plesk to manage their servers, I developed a script to automatically report malicious IPs via the AbuseIPDB API using the Fail2ban.
This script is freely available on GitHub and can be used by any sysadmin wishing to automate this process. Simply configure your API key and you're ready to get started!
We all have a role to play in building a healthier, more secure Internet. Every IP reported is one less potential attack on our infrastructures, one less threat to businesses and individuals. Thanks to the combined efforts of contributors and platforms such as AbuseIPDBwe can reduce the impact of cyber attacks and make the web safer for everyone. 🌐
So, whether you're an experienced sysadmin or an individual user wishing to contribute, I encourage you to join this initiative. Together, we can make a real difference and make the web more secure. 👊
It's time to denounce an organization - SPFBL.net - which, although it claims to fight spam, actually seems to adopt practices contrary to this objective. Instead of fulfilling its role, this provider seems to be taking advantage of its position to engage in absolutely scandalous and unacceptable practices.
Not all RBLs are managed ethically. Today's example is SPFBL.net, a Brazilian RBL born in 2015(source MXToolbox)which is increasingly coming under the spotlight for its highly questionable practices.
Info: What is RBL?
An RBL (Real-time Blackhole List) is a list of IP addresses suspected of sending spam or other malicious content. Mail servers use these lists to block or filter potentially dangerous e-mails.
In this article, we'll take a look at this situation and explain why this company's practices are not only dubious, but potentially harmful to the entire Internet ecosystem if administrators decide to use this RBL. We'll also look at how to combat these practices.
Users' and service providers' views on the SPFBL blacklist
Let's start by showing the general opinion emerging from this blacklist. A quick search on the search engines shows that the forums (in English) are full of people crying foul about SPFBL.net.
Having contacted their support (I'll tell you more about it later), I'd tend to agree with them... Judge for yourself.
"I contacted the operator of this spfbl.net and he threatened me with getting my IP's blocked throughout the internet, how can something like this be allowed to happen."
"We got flagged because we don't have a contact email in our whois record (we have privacy turned on for it). Given that google.com also has that, I conclude that these guys are just a scam who want to be paid to have your domain unrestricted."
The infrastructure server LRob is a perfect example of a system that has been carefully configured and managed for many years. As system administrator of this server, I can say with certainty that no spam has ever been sent from this machine. What's more, all the essential settings are correctly in place: Hostname, rDNS, MX, SPF, DKIMand DMARC.
Despite these exemplary compliance measures, the server's IPv6 ended up on the blacklist of SPFBL.net.
A domain is considered non-compliant when the WHOIS search result for that domain does not contain the email address of the domain owner. Update the registration data and remove privacy protection for this domain in WHOIS and wait one hour for the cached result of this WHOIS query to expire.
This IP was flagged due to misconfiguration of the e-mail service or the suspicion that there is no MTA at it.
For the delist key can be sent, select the e-mail address responsible for this IP:
add a PayPal user's email for 2.00 USD.
The rDNS must be registered under your own domain. We do not accept rDNS with third-party domains.
Summary of exchanges with SPFBL.net support
Naturally, I contacted the RBL to check whether I'd understood their policy correctly and whether it was possible to discuss things with them in a spirit of good understanding. Result: yes, I had understood correctly, and no, I don't think it's possible to discuss matters with them as they stand.
Here is a ChatGPT summary of the e-mail exchanges:
Initial request (Robin) Robin, system administrator, contacted SPFBL to ask for help with the removal of his IPv6 address from their DNS blacklist. He wanted clarification on the reasons for the listing and advice on how to correct any misconfigurations, suspecting a link to WHOIS privacy protection.
Answer (Leandro) In response, SPFBL's Leandro asked Robin to temporarily remove the WHOIS privacy protection so that the IP could be removed via their online removal tool.
Concerns (Robin) In a statement, Mr. Robin expressed concern about the requirement to remove WHOIS privacy protection, citing RGPD regulations. He questioned the need to expose personal data, pointing out that no reports of abuse had been issued on his domain.
Explanation (Leandro) Leandro explained that their system used domain owner data to predict spam and associate domains under the same owner. No further justification for this policy was given.
Objection (Robin) Robin disputed the usefulness of WHOIS information for assessing IP behavior, calling SPFBL's policy counterproductive. He reiterated that his IP posed no risk and requested its removal from the blacklist.
Options (Leandro) Leandro offered two options for removal: temporarily remove WHOIS protection or pay a fee.
Firm response (Robin) Robin firmly rejected both options, describing the practice as dishonest and tantamount to a scam. He stressed that his IP was compliant and threatened to take legal action if the problem was not resolved.
Final answer (Leandro) Leandro rejected Robin's legal threats, stating that SPFBL respects American law and inviting him to pursue any legal action he deems appropriate.
Last warning (Robin) Robin recalled that the Internet is a global system, and that no location justifies harming legitimate businesses through dubious ethical practices. He confirmed his intention to take the necessary measures, specifying that his contacts would identify the relevant local authorities if necessary.
These exchanges took place between September 8 and 9, 2024.
In addition, I have a log showing that they tried to send an e-mail to a non-existent address for testing purposes, so that they could check for themselves that the server was correctly configured and rejected the e-mail:
Oct 9 14:55:13 ds postfix/smtpd[899530]: connect from matrix.spfbl.net[54.233.253.229]
Oct 9 14:55:14 ds postfix/smtpd[899530]: NOQUEUE: reject: RCPT from matrix.spfbl.net[54.233.253.229]: 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table; from= to= proto=ESMTP helo=
Oct 9 14:55:14 ds postfix/smtpd[899530]: disconnect from matrix.spfbl.net[54.233.253.229] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4
Oct 9 14:55:14 ds psa-pc-remote[2023328]: Message aborted.
The SPFBL.net case: an abusive practice
The case of SPFBL.net highlights alarming practices that run counter to the data protection and ethical standards respected by many other RBLs.
In particular, this RBL blacklists IPs according to abusive criteria, and then imposes highly problematic conditions for untracking IP addresses.
Let's unpack the "rules for free de-listing" according to the policy posted on their site on September 9, 2024, which also informs us about possible reasons for the initial blacklisting:
Only IP with rDNS pointing to the same mail server IP will be accepted, with FCrDNS for your convenience;
❌ This criterion is certainly standard, but this check should be carried out by the server receiving the e-mail, not by an RBL, which here adds no value.
The rDNS must be in the domain of the MTA administrator, so third-party domains such as the generic rDNS of the data-center or ISP will not be accepted, and its TLD cannot be free and must have a public and accessible WHOIS without privacy obfuscation;
❌ The administrator can very well infomanage the mails of a third party, as in my case where the MTA is "lrob.net" and the administration is done via "lrob.fr". This should not justify blocking. ❌ Blocking generic rDNS can be good practice, but that's up to the receiving server, not an RBL. ❌ Requiring a public WHOIS contravenes the RGPD in Europe. The right to send emails should not depend on the visibility of personal information in the WHOIS.
The postmaster account must be configured for the domain registered on the rDNS and the account must be active and responding;
❌ rDNS are often technical subdomains, like "ds.lrob.net". Having an e-mail address like "postmaster (at) ds.lrob.net" makes no sense. The postmaster can be contacted via other, more appropriate channels, such as a contact form or a main address.
If you are using an IPv6 with SLAAC flag, you must keep port 25 opened to proof the existence of an active SMTP service and
❌ While the server does need to listen on port 25 to ensure proper SMTP operation, again it's up to the receiving server to check this, not a blacklist to control it.
Reputation of IP should be below 25% of negative points per total send volume
✅ This criterion is consistent with the very principle of an RBL, which assesses the reputation of an IP address based on its actual behavior.
Let's also take a look at the paid delisting conditions:
Only static IPs with configured mail server reverseeven if FCrDNS is invalid;
❌ Under the pretext of paying, one would allow an invalid rDNS, which is contrary to e-mail configuration standards. This is a circumvention of good practice, which could allow misconfigured mails to be sent.
A PayPal account is required for the email address of this account to be assigned to the IP, as responsible for the abuse;
❌ Forcing PayPal to assign an IP address to an account is an unjustified restriction. It limits users' options and has no legitimate reason in a technical framework.
The PayPal user must agree to have their email address shown publicly on this platform as responsible for the abuses of that IP and
❌ Publicly exposing the email address associated with the PayPal account is an invasion of privacy and can lead to risks of harassment or abuse. This clearly goes against the principles of confidentiality.
Reputation of IP should be below 25% of negative points per total send volume.
✅ This criterion is acceptable and aligns with the principle of assessing the reputation of an IP address on the basis of its actual behavior, as expected of an RBL.
In short, this blacklist seems to me to be an attempt to reinvent the wheel with blocking rules that make absolutely no sense from a technical point of view.
As for delisting's conditions, even in its paid version, they remain abusive. From my point of view, this should have dissuaded any sysadmin from using this RBL by now.
Their aim, of course, seems to be to make a profit on the backs of users while recovering personal data.
Summary of problems with SPFBL.net
Several major issues call into question the wisdom of their practices and their negative impact on legitimate businesses.
Here are the main points to remember:
WHOIS private data exposure SPFBL.net requires administrators to remove their WHOIS protection in order to be removed from their blacklist. This means that personal and sensitive information, such as the domain owner's email address, must be publicly accessible for the IP address to no longer be blacklisted. In Europe, this request is in total contradiction with the RGPD (General Data Protection Regulation), which guarantees the protection of users' private data. WHOIS information has been private by default for many years. This requirement would expose system administrators and companies to the risk of abuse or targeted spam, which is contrary to good security and privacy practice.
Payment for delisting In addition to removing WHOIS protection, SPFBL.net also offers an alternative : pay $2 to remove an IP address from the blacklist. This practice is perceived by many as a form of blackmail. Demanding payment to restore the legitimacy of an IP address, when there is no evidence of suspicious or malicious activity, calls into question the transparency of their operations. This approach is likely to drive many legitimate companies to pay simply to avoid the inconvenience of blacklisting.
An inefficient detection model Grouping domains according to WHOIS information ignores the realities of the modern web, where many legitimate businesses use shared infrastructures, hosted by providers such as Google or OVH. As a result, IP addresses could be unfairly blacklisted simply because they share a domain owner with other users, regardless of their actual behavior.
A very serious potential impact
The consequences of these practices are numerous and serious for the Internet ecosystem:
Impact on companies : When an IP address is wrongly blocked, it can affect a company's ability to communicate by e-mail with its customers, partners or service providers. Detection errors or abusive demands can disrupt the smooth running of a business.
Blackmail and extortion : Asking for money to remove an IP address from a blacklist without proof of malicious activity is tantamount to extortion. This approach seriously undermines trust between ISPs and their customers.
Breach of confidentiality : By requesting the removal of WHOIS protection, SPFBL.net is violating the fundamental principles of personal data protection, particularly in Europe, where the RGPD (General Data Protection Regulation) protects users' private information. By exposing this data, SPFBL.net exposes system administrators and companies to the risk of misuse.
What can I do as an Internet service provider?
1. Stop using this RBL immediately
We must all urge our relations at the major service providers NOT to use this RBL.
It is absolutely essential that Internet service providers stop using SPFBL.net and other RBLs that fail to meet ethical standards. Another such RBL is UCEPROTECT, which blacklists entire IP blocks and then demands money from each of the IP users to unblock them.
Using a dubious RBL can have harmful consequences for end-users, businesses and the entire digital ecosystem.
There are many respectable alternatives that focus on detecting malicious activity based on actual behavior, not private information or arbitrary domain groupings. System administrators must remain vigilant and choose solutions that respect privacy and follow fair and transparent practices.
2. Don't give in
If, like me, you are a victim of this RBL and feel that these practices are abusive, please don't give in to the outrageous demands of this RBL. On the contrary, fight alongside me.
3. Report these practices to the appropriate authorities
Use your connections to get the word out to the French CSIRT (Computer Security Incident Response Team), at the_ANSSI but also to the CNIL for non-compliance with RGPD. If you have contacts at European level, pass on the information. If you're outside France or Europe, contact the organizations you can reach, and don't hesitate to use this article to explain the problem.
If you don't have a contact but understand what's at stake, pass on the info to people in the hosting and web sysadmin fields.
Conclusion
The case SPFBL.net is a blatant example of the dangers of the dubious practices of certain RBLs.
We understand that those who claim to fight the "bad guys" are not always "good guys" themselves.
To protect the integrity of the Internet and the respect of users, it is imperative that Internet service providers stop using this RBL and favor more respectful solutions available.
Fellow sysadmins: don't give in to the grotesque requirements of this RBL.
LRob will not give in, and this article marks the beginning of a fight which will only stop once the community has won its case. It can be done, by contacting the right people. And you can help.
If you are confronted with the abusive practices of SPFBL.net, join us in denouncing these actions and protecting the integrity of the Internet ecosystem. Contact the relevant authorities, share this information with your professional networks, and refuse to give in to these unfair practices.
The world of WordPress websiteswhich powers more than 40 % of the world's websites, is in turmoil. At the center of the conflict are two major players in the ecosystem: Matt Mullenwegfounder of WordPress and CEO of Automattic, and WP Engineone of the leading hosting companies for WordPress.
This confrontation, which has taken on legal proportions, raises crucial questions about control of the WordPress brand, open source, and the governance of one of the web's most influential projects. Here's a detailed analysis of the case and what's at stake.
Background: WordPress and WP Engine
WordPress and Automattic: a complex relationship
WordPress websiteslaunched in 2003 by Matt Mullenweg and Mike Little, is open source software for creating and managing websites. It's free to use, and enjoys the support of a large community of developers who contribute to its continuous improvement. However, the project's governance relies heavily on Automatticthe company founded by Mullenweg. Automattic manages WordPress.com and other popular products such as WooCommerce and Jetpack.
Although WordPress is open source, Automattic owns a exclusive license for the use of the WordPress websitesThis gives the company a central role in the ecosystem. This includes protecting the brand against perceived misuse or deception.
WP Engine: a major player in WordPress hosting
On his side, WP Engine is one of the largest hosting services specializing in WordPress. The company offers hosting solutions optimized for WordPress, making it easy for millions of users to manage their websites. It has experienced rapid growth, attracting leading investors such as Silver Lake.
However, WP Engine is not directly affiliated with Automattic nor to the WordPress Foundationeven though its name and business model are closely linked to WordPress.
The Beginning of the Conflict: Mullenweg vs WP Engine
In September 2024, Matt Mullenweg published a blog post in which he openly criticized WP Engine, calling the company a "cancer for WordPress. It criticized WP Engine for disabling the article revision history feature by default, a practice which, in its view, compromised the user data protection.
Mullenweg also denounced WP Engine's use of the "WP"We felt that this was confusing users, leading them to believe that WP Engine was part of WordPress or had an official link with the WordPress Foundation.
WP Engine's reaction
In response to these accusations, WP Engine sent out a cease and desist letter to Mullenweg and Automattic, demanding that they withdraw their statements. WP Engine defended its use of the "WP" trademark, claiming that it was a matter of fair use of the name, in accordance with trademark law. The company also accused Mullenweg of threatening to adopt a "nuclear approach against WP Engine unless it agrees to pay a substantial royalty for the use of the WordPress trademark.
Legal escalation: cease-fires and counter-attacks
In response to WP Engine's letter, Automattic issued its own cease and desist letter, claiming that WP Engine violated the rules for use of the WordPress and WooCommerce trademarks.
The conflict reached a new climax when Mullenweg has taken the radical decision to ban WP Engine from WordPress.org resources. This ban blocked WP Engine-hosted sites from accessing plugin and theme updates, exposing many sites to security risks. This measure has been widely criticized within the WordPress community, as it has left small businesses and independent sites without a viable solution.
WP Engine denounced this decision, accusing Mullenweg ofabuse of power and endanger the entire WordPress ecosystem.
Matt Mullenweg, CEO of Automattic, has misused his control of WordPress to interfere with WP Engine customers' access to https://t.co/ZpKb9q4jPhasserting that he did so because WP Engine filed litigation against https://t.co/erlNmkIol2. This simply is not true. Our Cease &...
The interruption of WP Engine services has had a major impact on many users. Although WordPress plugins and themes are licensed open source, hosting providers like WP Engine have to manage infrastructures so that their customers can use them. The temporary ban revealed the fragility of certain technical dependencies and highlighted the importance of a balanced management of open source resources.
However, Mullenweg asserted that conflict was strictly linked to trademark issues and not to the overall management of WordPress. The ban was temporarily lifted at the end of September, but the incident sowed doubts in the community.
Automattic too dominant?
More and more voices are being raised to question Automattic's dominant position in WordPress management. John O'Nolanfounder of the open source CMS Ghostcriticized the excessive centralization around Matt Mullenweg, asserting that "40 % of the web should not be controlled by one person".
On his side, David Heinemeier Hanssoncreator of Ruby on Railshas accused Automattic of betraying the principles of open source by requiring WP Engine to return 8 % of its revenues. For him, this practice could have repercussions far beyond WordPress, threatening the entire open source community.
Legal and commercial implications
On October 3, 2024, WP Engine decided to go on the offensive by filing a complaint against Automattic and Mullenweg for abuse of power and anti-competitive practices. WP Engine accuses Automattic of failing to respect its commitments to open source and of harming the interests of developers and users.
This case is still ongoing, but it could have far-reaching far-reaching consequences on how open source brands and projects like WordPress will be managed in the future.
A special message when you log on to WordPress.org
When logging in to the WordPress.org forums, a new checkbox appears:
✅ I am not affiliated with WP Engine in any way, financially or otherwise.
Unusual message that prompted me to look this up and discover this case.
Questions raised for WordPress
This mainly affects two large American companies that are exploiting WordPress commercially (in models that are, in my opinion, too modified from the original version of WordPress). The original version of WP is truly free, and you can host it wherever you like (and hopefully, you'll choose a host that's as free as possible). LRob hosting).
For the time being, independent web hosts such as LRob are totally unaffected by this conflict. There are no alarm bells ringing for us, even if we remain vigilant.
In any case, this conflict underlines tensions possible when managing a large-scale open source project. While WordPress remains an essential technology for millions of sites, the debate surrounding the brand ownershipthe governance and theopen source ethicsraises a number of questions.
In particular: how far can open source remain free when it is closely linked to massive commercial interests?
A quadruple critical security flaw has just been discovered in CUPS for all GNU/Linux systems. This article will be updated with the new information, to provide you with a simple and effective summary of what you need to know and do.
UPDATE 09/29/2024: These flaws only concern CUPS, so very few servers are affected, unless you have printers in your datacenter...! This article has been rewritten accordingly.
A critical flaw: what do we know?
The security researcher Simone Margaritellidiscovered this set of faults in early September.
This concerns CUPS, the Linux printing service. The researcher highlights a possible Remote Code Execution (RCE). without authentication. This means that attackers could potentially execute commands on remote machines without having to identify themselves, making the flaw particularly dangerous. The CVSS score assigned to these vulnerabilities is between 8.3 and 9.0/10 (after being rated at 9.9).
On September 26, Naïm Aouaichia, cybersecurity engineer, alerted us and told us before anyone else that this could affect CUPS :
"Some rumors suggest that this flaw is linked to vulnerabilities in CUPS, the printing service. Yes, your printers may be at the heart of it all. To be confirmed.
According to some hypotheses, the problem could be linked to a buffer overflow or a race condition."
This does not apply to dedicated servers under firewall and/or with a print service not running. For local administrators using CUPS, stay tuned.
A long-standing problem
This vulnerability has a long history, having been present in GNU/Linux systems for many years. over a decade. It affects all Linux distributions, including Debian, Ubuntu, RedHat and others.
Despite the importance of this flaw, there are currently no no correction available. Developers are still debating which aspects of the flaw really affect security, which is delaying the release of a patch.
Disclosure process
Researcher Margaritelli, who made the discovery, worked tirelessly for three weeks to alert the open source community and help coordinate patching efforts. However, it met with a great deal of resistance from developersSome are reluctant to accept the existence of this flaw in their code. This underlines the challenges facing vulnerability management in the open source world.
Some accuse him of trying to boost his popularity. But let's face it: the researcher has indeed discovered a major flaw that everyone has been ignoring for over 10 years.
Canonical (Ubuntu) and RedHat have confirmed the seriousness of the situation and are actively working on a solution. Full disclosure of the technical details of the flaw is planned. October 6This increases the pressure for a rapid patch release.
The roadmap is as follows:
September 30: Initial disclosure to the Openwall security mailing list
October 6: Public revelation with all the elements of vulnerability
Why is it complicated to correct the flaw?
Margaritelli indicated from the outset that it would probably be necessary to at least three to six CVE identifiers (Common Vulnerabilities and Exposures) to cover all aspects of the problem. This means that there are several potential attack vectors, each requiring specific analysis and resolution.
What are the risks for you?
As we now know, you must absolutely avoid exposing your IPP services to the Internet (port 631 should be blocked on firewalls).
Although this flaw is critical, it is not so easily exploited. It requires a high level of technical expertise, which means that, for the time being, only highly skilled attackers could make use of it. The details of the flaw are not yet public, limiting its impact. But this should not make you complacent. You need to remain vigilant, because once full disclosure has been made, exploitation attempts will multiply.
What to do in the meantime?
Pending an official patch, here are some best practices to limit the risks:
Watch for official announcements Stay informed about security updates released by your Linux distribution. These announcements will let you know when a patch is available.
Reinforce your firewall configuration Make sure your servers are not unnecessarily exposed to the Internet. Restrict access to essential ports and, above all, do not expose port 631!
Limit service exposure Reduce the number of services listening publicly to a minimum by switching off unnecessary services or having them listen on 127.0.0.1.
Get ready for rapid deployment As soon as a patch is released, be ready to install it immediately to protect your machines.
This RCE flaw is undoubtedly one of the most serious to be discovered in the GNU/Linux ecosystem in a long time. However, it's important not to panic. No system is free of flaws, and Linux remains the most reliable and secure operating system. It's worth remembering that most servers don't have a CUPS service running, but if they do, then take extra care. By adopting the recommended security measures and keeping an eye on official announcements, you can minimize the risks. The open source world is generally quick to react and will certainly be able to overcome this ordeal effectively, despite the internal divergences inherent in collaborative work.
Keep an eye on upcoming patches and make sure your systems are ready for them. IT security is an ongoing challenge, but staying proactive will ensure that your WordPress servers and clients stay protected.
LRob is keeping a very close eye on this, and if the servers aren't affected, I guarantee that we'll fix this global flaw as soon as the patch is available.
Finally, for those who will argue that "Linux isn't secure", here's a little comparison Linux VS Microsoft.
1-year comparison of Linux VS Microsoft security vulnerabilities11-year comparison of Linux VS Microsoft security vulnerabilities
The truth is: there's no such thing as 100% safety, and anyone who claims otherwise is either lying or ignorant! So leave dogmatism aside. No one is spared from vulnerabilities, so it's a question of doing our best and remaining vigilant to make intrusions as difficult as possible.
Imagine the drama: only 1 chance in 10 that your requests will reach you!
Contact forms are essential for acquiring customers. Yet a number of these forms are poorly configured and fail to forward prospect requests...
What's more, forms are supposed to be designed to save you time... And a few tricks can help you do just that... For example, by not receiving spam or by being able to reply more quickly.
Today, LRob saves you time and leads!
1. Do not set the customer's email address as From
The most frequent error when configuring contact forms is to consider the customer as the sender of the e-mail.
It may seem logical to put your email address in the "From" field, but this causes a major problem: mail spoofingor identity theft.
In this way, your website pretends to be your customer's email address (for example : john.doe@microsoft.com). If your customer's domain is secure (which is often the case), it will refuse to let your server send an e-mail on its behalf. The message will then be silently blocked by your email provider, or considered spam... 9 chances out of 10 that you'll be considered a spammer.
The solution is very simple: the e-mail sender must always be an address linked to your own domain. For example, use an address such as : site@votredomaine.fr. This ensures that emails sent from your form will not be rejected or classified as spam.
2. Protect your forms with a Captcha
Don't forget to add a Captcha to avoid spam.
Captcha isn't there just to annoy people: it's a simple, effective solution for filtering robots and preserving the quality of messages received.
Without this protection, you'll receive dozens or even hundreds of unsolicited messages a day, wasting time sorting through them and missing out on genuine requests.
To respect the privacy of your users, I recommend hCaptcha.
3. Configure SMTP on your site
Your website should have a dedicated e-mail address with a real SMTP login for your mailings. As a reminder, SMTP is the standard protocol for sending e-mail.
If your mail is with Gmail or Microsoft, this will be more complicated to apply because you pay for each mailbox and SMTP is disabled by default... But if it's with your preferred host so don't worry!
Default mailings via the php mail() function are sometimes disabled to prevent involuntary mailings and preserve server reputation (blocked by default at LRob, authorized on a case-by-case basis).
This ensures that the email is sent from a real email server, rather than from the website server when these two servers are separate.
SMTP will improve email deliverability thanks to email headers (meta-information) that are generally cleaner than php mail().
In the event of problems with the form (e.g. massive spam mailings), SMTP can be used to limit mailings to an hourly quota.
In the event of deliverability problems of any kind, if your host provides support for this (as is the case with LRob), SMTP dispatches are much easier to trace in the logs, which simplifies diagnosis.
In short, using SMTP is bound to improve your deliverability and avoid problems. So use it!
4. Check the deliverability of your form emails
Make sure your messages are well received by testing them with tools such as mail-tester.com.
Mail-Tester lets you measure the quality of your mailings.
Enter the e-mail address that appears when you visit mail-tester.com as the recipient of the form, take the test, then check the score.
A score of 9/10 or higher is recommended to ensure that requests are received correctly. This score should also be achieved for your regular email dispatches. If this is not the case, contact your email host for more information (or come and see us!). host at LRob !).
5. Run your tests in private browsing mode
When you test your contact forms, do so by private browsing.
If you're logged into your site, certain features such as Captcha can be disabled, to name but a few. This could distort your tests and give you the wrong impression of the quality of your form.
6. Use a recipient address linked to your domain
Make sure the receiving address (form recipient) belongs to your domain (vous@votredomaine.fr) and is not redirected to another address.
In the event of a problem with your form, for example if you receive spam via the form and the recipient is a major e-mail provider (Gmail, Orange, Yahoo, etc.), you could be considered a spammer.
Using your own domain as a form recipient means you can protect your e-reputation and reduce the risk of emails being blocked or mishandled by email providers.
7. Avoid confirmation emails
Sending a confirmation email may seem like a good idea, but beware.
If this message contains the text submitted by the user, then your form can be exploited by malicious people to send spam to any e-mail address via your site. Even if the text is not included, this can still generate unsolicited mail to third parties, which is never good.
This can tarnish your domain's reputation and expose you to penalties. It's best to avoid this practice.
8. Use the "Reply-To" field to facilitate your answers
Even if you don't have to put the customer's email address in the "From" field, you can still add it in the "From" field. "Reply-To.
In this way, you can reply directly to the e-mail form: your prospect's e-mail address will automatically be the recipient of your e-mail.
A simple, time-saving solution!
9. Save requests on the
Consider saving form requests in the site database.
WordPress plugins like " Contact Form 7 Database Addon "These services are available free of charge. You can then check from time to time that you haven't missed a request.
To find out more...
If you have any doubts about the configuration of your forms, or would like a personalized audit, please don't hesitate to contact me. contact.
So the advice on email deliverability is included in LRob support for all customers.
I just have to wish you every success with your new top forms! 💪
💥New offers & up to -30% in September 💥 A great way to get back to school! All the details 👇
September is also back-to-school time for adults!
And it's been exactly 1 year since I left my permanent job to focus totally on the LRob business. So it's time to mark the occasion.
September's schedule is busy, so let's get straight to the point.
⭐ New products ⭐
🟢 The migration to LRob can now be ordered from the LRob portal! With 3 levels of service available from €120 to €499 (the latter allows the migration of 50 overnight mailboxes!). 😎
🟢 The webmastering jobs have evolved for greater flexibility. Now choose your hosting and webmastering separately. In some cases, this can save you a lot of money. 🔀
🟢 The offer WP ArticlePro AI simplifies, at a reduced rate for September! Proofreading, enhancement, layout of your articles, now with 2 images included, multilingual options: from €30/article (instead of €40)! 🤖
A decree of May 30, 2024 fixes since July 1 the increase in contributions for 2025 for BNC (and Cipav). For better social protection. Auto-entrepreneurs (and EI): get ready.
As indicated in this first news item :
This concerns auto-entrepreneurs affiliated to the general Social Security scheme and declaring their sales in the BNC category. The aim is to guarantee their supplementary pension rights.
An e-mail from URSSAF on August 28 informs us of changes in the overall contribution rate.
Scroll down to see the mail
Hello,
You are an auto-entrepreneur in the crafts, trades or unregulated liberal professions, and you declare your sales as non-commercial profits (BNC).
Each month or quarter, you pay social security contributions calculated according to a global contribution rate applied to your sales.
Please note that from July 1, 2024, this overall contribution rate of 21.1 % will increase progressively over three years, as shown in this table (excluding Acre beneficiaries and auto-entrepreneurs working in overseas France), according to the following schedule:
Year
Period
Overall rate
2024
from July 1 to December 31, 2024
23.1 %
2025
from January 1 to December 31, 2025
24.6 %
2026
from January 1, 2026
26.1 %
Why does your rate increase??
Your rate increases to enable you to acquire rights to the supplementary pension for self-employed workers, and thus benefit from enhanced social protection.
Qu'is the supplementary pension for self-employed workers?
The supplementary pension for the self-employed is an essential complement to your basic pension. By paying monthly or quarterly contributions, you accumulate points, which will be converted into pension rights when the time comes.
You benefit from'Acre or you do business overseas?
For your supplementary pension entitlements prior to July 1, 2024, the public authorities are in the process of defining a system that will enable you to make retroactive contributions and acquire entitlements if you so wish.
🟢 2024, from July 1 to December 31, 2024: 23.1 % 📈 2025, from January 1 to December 31, 2025: 24.6 % 📈 2026, from January 1, 2026: 26.1 %
Why is the rate increasing?
URSSAF explains in the e-mail:
"Your rate increases to enable you to acquire supplementary pension rights for self-employed workers and thus benefit from enhanced social protection."
And on the website :
"The supplementary pension is an essential complement to the basic pension. Thanks to the contributions they pay, auto-entrepreneurs will now be able to accumulate points that will be converted into pension rights when the time comes, ensuring greater long-term financial security."
Adapt
💡 Remember to :
Adapt your contribution calculation grids
If necessary, adapt your pricing structure
Re-evaluate the relevance of a change to SARL/EURL and derivatives
Don't be fooled by any phishing campaigns (fake e-mails asking for personal information or redirecting you to fake sites) that may follow this announcement.
Conclusion
Not necessarily the best news for back-to-school...
But let's look on the bright side: There's still a chance we'll get a pension. 🤞 (yes, yes, we believe it...)
———–
I'm Robin Labadie, web host and WordPress specialist.
On August 19, 2024, a critical vulnerability was identified in the LiteSpeed Cache plugin, used by over 5 million WordPress sites. This flaw allows an unauthenticated attacker to impersonate an administrator, compromising the site's full integrity.
It affects all versions of the LiteSpeed Cache plugin up to version 6.3.0.1. By exploiting a bug in the role simulation function, an attacker can use a hash to impersonate an administrator. Once this hash has been obtained, he can create an administrator account via the WordPress REST API, enabling him to take control of the site.
The hash used is only six characters long, making it vulnerable to brute-force attacks. What's more, if debugging logs can be accessed, this hash can be easily recovered by an attacker.
What to do?
Don't underestimate this vulnerability. Threats of this type can quickly turn into disasters if not dealt with in time.
The solution is simple: update LiteSpeed Cache to version 6.4.1 or higher. This update corrects the flaw.
If you use Wordfence Premium, Care or Response, a firewall rule was deployed on August 20, 2024 to protect you. Users of the free version will receive this protection from September 19, 2024.
How do you stay protected?
With the WordPress Toolkit on LRob accommodationyou would have been automatically alerted by e-mail of the vulnerability and the update could have been automatic 😎. Backup is complete and daily at LRob, with a full 1-year retention! A good way to stay one step ahead of security threats.
I wanted to host it myself on Linux servers. Because everyone knows that a server worthy of the name is necessarily Linux-based!
I was unknowingly entering my true vocation: sysadmin 🌱
📷 Photo by Manon Laterza - 2012 - I manage my servers, my friends play pétanque next door. 😂
The beginning
In 2012, we needed: a website (initially a forum), a voice server and game servers.
Having been a computer enthusiast for 10 years, I was the only one of the 25 people behind the project who dared to stick his neck out for the technical side, becoming de facto the community's main system administrator.
So you had to learn a lot at once, from scratch:
choose a dedicated server provider (at the time: online.net / Dedibox)
install and manage a Linux server (ESXI + Debian) via a headless terminal (SSH)
manage multiple IPs (failover)
choosing a registrar to register and manage a domain name
manage a DNS zone
manage a firewall
install a web server (LAMP)
create MySQL databases by hand, install and use phpMyAdmin
manage system and CMS configuration files
manage rights and permissions on a phpBB forum
And I'm sure I'm forgetting
In this discovery, my curiosity was insatiable. 😋
I worked day and night until everything worked! It took me 5 to 7 days 🌛
I learned a lot more in that short time than I did in a year of computer science college (which I stopped to start my own business in 2010 because I was bored with courses that I found irrelevant).
And that was just the beginning...
In the end, I had a VM (virtual machine) for the web server, a VM for the voice server, and a VM for the game servers. I could have grouped the last two together, but I was learning and I thought at first that it was better to keep everything as separate as possible, which in the end isn't a bad thing when you're just starting out.
For years, I've been exploring the many facets of servers. including BASH programming, becoming second contributor from LinuxGSM by getting deeply involved in the open-source project.
Discovering WordPress
In 2014 I discovered WordPress! 😍
Little did I know, but WordPress was to become a central part of my professional life.
I first transitioned the community site from a phpBB forum to a WordPress site.
Having discovered this great CMS, I was inspired to make my LRob personal site in the same breath, still in 2014. I started hosting and making sites for friends. Without even realizing that, in fact, it was a real job of sysadmin, webmaster and web host.
Accelerating
In 2016, I put a huge boost into web server management.
After increasingly clean server migrations, the creation of my own tools and processes, the manual installation of SSL/TLS certificates (for HTTPS) and a fair amount of time managing WordPress, I've tackled the missing link!
I set about building my first email servers by hand, respecting all possible standards (rDNS, HELO, SPF, DKIM, DMARC). And discovering deliverability issues with Microsoft, which are difficult the first time you deploy a server.
I even created a Linux server tutorial seriesthe one I would have dreamed of having when I started out. This is a great help for aspiring Linux and Web system administrators.
2017: from enthusiast to professional
Until 2017, let's face it: my professional situation was chaotic.
Very rewarding, but chaotic.
I oscillated between working as a sound engineer, freelance computer troubleshooting, video shooting and editing, telecommuting support (I was ahead of my time 😎 ) and temping' to fill in the gaps. But at 27, I had my student loan to pay off, I wanted to improve my standard of living and so I needed to stabilize my income.
I said to myself that I was beginning to have computer skills that could be put to good use in a company... There must be a company we can help each other with!
And then, I think I had the stroke of luck of my life.
As soon as I started looking for a job, I discovered a web host in Orléans: HaiSoft.
What a bargain! 🤩
He's the only one I sent my CV to. The only one I interviewed with. And it was, I think, mutual professional love at first sight.
They recognized in me the passionate self-taught person that I was. They invited me to join the team. This marked the start of a brilliant adventure lasting almost 6 years. 🤝
During these years, I have professionalized while bringing my fresh ideas and energies to perfect every aspect of the services. 👌
HaiSoft set the bar very high, but nothing is ever perfect. 🏋️♂️
In an exemplary synergy, we solved recurring problems, improved documentation, boosted performance, security and updates. We enriched the offering and improved communication. I even had the latitude to manage the server racks! 🎯
HaiSoft is a superb IT business model, the best in my opinion. 🤩
Everyone's voice is heard, and the hierarchy is friendly, transparent and accessible. Anyone can suggest and implement improvements. Employee involvement and commitment become natural.
It's thanks to this openness that, at the time, as the most fervent WordPress user, I naturally became the WordPress support referent. I was able to push forward specific services for WordPress and train the whole team in these tasks.
The humans behind it are awesome! 🤗
I would like to take this opportunity to thank the members of the team, who are still dear to me to this day:
Frédéric, for being an exceptionally upright and concerned boss
Damien, for your always pertinent overview
Benoît, for being an eternal mentor, with your curiosity, rigor and consistent uprightness
Dylan, for further improving the ideal of customer relations
Arthur, listening and responding to development challenges
Jérôme, for the discovery of another universe and good discussions
Thanks for everything! 💖
👉 HaiSoft continues to shine with quality thanks to all this little world, and the new ones. Every time I hear from them, I learn of the introduction ofdevelopments and ingenious solutions.
So if my WordPress expertise isn't of use to you : go to them ! You can thank us later 😉
🌐 Web agency
As the years went by, I still wanted to evolve and re-enter the business. I started making more websites, first for friends, then for pros... Offering WordPress webmastering.
At the end of 2022, I took a calculated risk: leaving HaiSoft to join a web agency and overhaul their hosting park. 🪛
You know what you lose, but never what you gain. So I prepared for my future as an independent.
In the short transition between the two jobs, at lightning speed, I deployed my own web hosting infrastructure. ⚡
Then, in the space of a few months, I renovated the servers at the agency that hired me: improving performance, security, backups, simplifying management, while drastically reducing server costs. 🔒
⏩ Freelance Turnaround
In early 2023, a big surprise: my new bosses are retiring!
The web agency where I was implementing my long-term plans was sold.
At first, I was enthusiastic about this change, it opened up fabulous doors. Except... The new hierarchy blocked all budgets for planned developments. I thought it was temporary, but when I spoke to the hierarchy directly, I realized that it wouldn't work. 😅
The team felt abandoned, wronged. Some were talking about leaving. The atmosphere was extremely negative and heavy. I could no longer do my job properly, and certain emergencies couldn't be dealt with. If before I'd been proud of the work I'd done and was on my way, now I just didn't want to put my name to the disaster I could see unfolding before us.
My time deserved better! ⌚
At the same time, my freelance business was starting to take off, even though I was doing nothing more than talking about it to those around me. Throwing myself wholeheartedly into this task was bound to work!
So I took the plunge:
First to resign (others followed)
Go 100% freelance! 🚀
Probably the best decision of my life!
Not only do I manage to make a comfortable living from it, but I also get a level of satisfaction I'd never have dared imagine!
I have the perfect hosting infrastructure: the most beautiful, reliable and secure.
And above all, I'm happy to accompany exceptional customers every day. 💘
This site uses cookies for functional and statistical purposes. All statistics are anonymized and self-hosted on a private Matomo server in Europe. This helps us to understand what you like to find on this site and to perpetuate the professional activity proposed. Non-acceptance may break certain functionalities. For a better experience, please accept cookies.
Features
Always active
Some cookies are required for the basic functionality of this site.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
Allow this site to collect anonymized and preserved statistical data from third parties such as Google.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
