Jafo
Active member
As I am still working on this with my VB installs this suggestion may be a little incomplete.
All software eventually has security flaws. With add-ons, this becomes even more of an issue. For example, vbseo is constantly patching holes. I administer almost 40 forums and when they start getting hacked, it creates a lot of work and costs my clients serious money. I have begun working on proactive solutions to limit attack vectors. One that we are working on now is showing promise: Create two mysql users and limit the privis of the default mysql user (default user), and give more permissive privis to the second mysql user (let's call it the admin user).
The default user cannot write to certain tables, such as templates, plugins, settings, etc.. If the user tries, mysql throws a permissions error. So even if there is an exploit they cannot insert any code into these tables (providing they are not in the admincp). As we see with many of these hacks, one of the first things they try to do is spread their malware to the audience via the templates or plugins. If I didn't have to rely on hook locations, I could eliminate more tables (i.e. datastore).
In my model, the admin user only connects to the database when in the admincp, or in a cron job.
I know I am speaking in terms of vBulletin, but that is all any of us here except the staff have to illustrate this kind of suggestion.
All software eventually has security flaws. With add-ons, this becomes even more of an issue. For example, vbseo is constantly patching holes. I administer almost 40 forums and when they start getting hacked, it creates a lot of work and costs my clients serious money. I have begun working on proactive solutions to limit attack vectors. One that we are working on now is showing promise: Create two mysql users and limit the privis of the default mysql user (default user), and give more permissive privis to the second mysql user (let's call it the admin user).
The default user cannot write to certain tables, such as templates, plugins, settings, etc.. If the user tries, mysql throws a permissions error. So even if there is an exploit they cannot insert any code into these tables (providing they are not in the admincp). As we see with many of these hacks, one of the first things they try to do is spread their malware to the audience via the templates or plugins. If I didn't have to rely on hook locations, I could eliminate more tables (i.e. datastore).
In my model, the admin user only connects to the database when in the admincp, or in a cron job.
I know I am speaking in terms of vBulletin, but that is all any of us here except the staff have to illustrate this kind of suggestion.
Upvote
1
