CMS Requirements
Permalink
I'm taking over a preexisting website and rebuilding it in Concrete5. The original developer may continue hosting though, and they manage all of their own server hardware and systems.
They provided the following list as requirements for the CMS; can asume C5 has this ciovered (I'n used to looking at these items as server items, but note their intro statement):
"This is CMS specific (need to be included within the concrete 5 install, these are not server side but CMS related) All of these are currently active on the website now."
- monitor the file system and quarantine any new or modified files immediately.
- monitor all url queries and prevent suspicious url exploits
- perform regularly scheduled scans of all files for malicious code
- protect .htaccess and other configuration files
- detect intrusions into the database
- throttle login and url query attempts
- lock out suspicious login attempts
- force SSL admin login and backend
- automatically block ip addresses that display suspicious activity
- provide idle session logouts
- provide extensive activity logging and reporting
- sends automatic email alerts for suspicious activity, file quarantines, etc.
They provided the following list as requirements for the CMS; can asume C5 has this ciovered (I'n used to looking at these items as server items, but note their intro statement):
"This is CMS specific (need to be included within the concrete 5 install, these are not server side but CMS related) All of these are currently active on the website now."
- monitor the file system and quarantine any new or modified files immediately.
- monitor all url queries and prevent suspicious url exploits
- perform regularly scheduled scans of all files for malicious code
- protect .htaccess and other configuration files
- detect intrusions into the database
- throttle login and url query attempts
- lock out suspicious login attempts
- force SSL admin login and backend
- automatically block ip addresses that display suspicious activity
- provide idle session logouts
- provide extensive activity logging and reporting
- sends automatic email alerts for suspicious activity, file quarantines, etc.
It's funny someone would put server side specs as requirements to a a CMS itself. Like Mnkras said, monitoring file integrity and md5sums is something done by a system admin. You need to hire a web developer + server administrator. Most of what you need is done on the server.
Now I'm not a pro at this, but I can give a little insight on how to do it:
1.) monitor file systems and quarantine new/modified files immediately
- get unique file identifiers by running md5sum on the file
- use clamscan to scan for bad files
2.) monitor url queries, prevent suspicious exploits
- depends on the server, but apache logs all connections to /var/log: you can see whos accessing your site via what URLS
3.) perform reg scan ( clamav )
4.) protected .htaccess and configs
- htaccess is for apache, if your going for security, dont use .htaccess at all, but put those setings in the apache vhost file itself, then disable .htaccess
5.) db intrusion - I dono, your best bet is daily backups, so you'll need some hardware, maybe a dedicated server
6.) throttle requests - not sure, but I would think the web server is better protected for this, blocking connections before the cms is even called upon
7.) lock suspicous logins
- c5 already does this, but on a side note, if u ever look at an apache access log for something like a wordpress site, its full of brute force attemps, your best bet here is strong password (wolframalpha has the best generator I know of)
8.) block ips that do suspicous stuff
- you would need to define what you think is suspicous and daily your environment
provide extensive activity logging and reporting - need to decide what you want logged... but by default, if your using apache, it already has extensive logging built in (it would be fun to build something like this in node though )
MY conclusion is that if your current service provider claims your CMS must do all of the above, they have either mispoke or are misleading, as like we've discussed, most of these things is done by the host, not the cms.
Very good list of features to up someones security though, I've copy and pasted it for my own reference!
One last point, say if you did want your CMS to do all of this work, it would be like a hack job, because: the cms and the server it runs on are not one. They are separate.
So let's change scenarios, say you where building a website from scratch and wanted to use node.js.... node differs from apache in that apache is a web server and you add things like php ontop of it to get an environment to build a CMS like concrete5. In node.js, the web server is node.js, and the code that runs the CMS is also node.js. Therefore the web server IS the web site. And when the web server and the web site are married, they can do everything together, including all that you list as a need for a CMS only. BUT, keep it mind, that in this scenario, the SERVER is still what does the work, the CMS has a different job, they simply run together as one ( in a node.js server/cms scenario ).
Now I'm not a pro at this, but I can give a little insight on how to do it:
1.) monitor file systems and quarantine new/modified files immediately
- get unique file identifiers by running md5sum on the file
- use clamscan to scan for bad files
2.) monitor url queries, prevent suspicious exploits
- depends on the server, but apache logs all connections to /var/log: you can see whos accessing your site via what URLS
3.) perform reg scan ( clamav )
4.) protected .htaccess and configs
- htaccess is for apache, if your going for security, dont use .htaccess at all, but put those setings in the apache vhost file itself, then disable .htaccess
5.) db intrusion - I dono, your best bet is daily backups, so you'll need some hardware, maybe a dedicated server
6.) throttle requests - not sure, but I would think the web server is better protected for this, blocking connections before the cms is even called upon
7.) lock suspicous logins
- c5 already does this, but on a side note, if u ever look at an apache access log for something like a wordpress site, its full of brute force attemps, your best bet here is strong password (wolframalpha has the best generator I know of)
8.) block ips that do suspicous stuff
- you would need to define what you think is suspicous and daily your environment
provide extensive activity logging and reporting - need to decide what you want logged... but by default, if your using apache, it already has extensive logging built in (it would be fun to build something like this in node though )
MY conclusion is that if your current service provider claims your CMS must do all of the above, they have either mispoke or are misleading, as like we've discussed, most of these things is done by the host, not the cms.
Very good list of features to up someones security though, I've copy and pasted it for my own reference!
One last point, say if you did want your CMS to do all of this work, it would be like a hack job, because: the cms and the server it runs on are not one. They are separate.
So let's change scenarios, say you where building a website from scratch and wanted to use node.js.... node differs from apache in that apache is a web server and you add things like php ontop of it to get an environment to build a CMS like concrete5. In node.js, the web server is node.js, and the code that runs the CMS is also node.js. Therefore the web server IS the web site. And when the web server and the web site are married, they can do everything together, including all that you list as a need for a CMS only. BUT, keep it mind, that in this scenario, the SERVER is still what does the work, the CMS has a different job, they simply run together as one ( in a node.js server/cms scenario ).
Thank you both for your input. Also, thanks for deciphering my typos.
I felt these were fairly ridiculous requests. I've built over 20 Concrete5 sites (pre 7.0 & 8.0) and have really never had any issues on the hosting platforms my clients use. Even a few sites with 100's of members with all sorts of editing and uploading capabilities.
I feel this other developer may be trying some subtle psychological intimidation. I will give them credit in that they manage all of their own servers so they may be hyper-vigilant. That said, most of these requests have never struck me as CMS variables.
As you intimated ob7dev, this developer is a WordPress man...and they've told me web development isn't really their specialty. They are local SEO and hosting specialists in Eugene, Oregon.
I'm really not sure what his concerns are as the site of topic
(http://www.priorityoneheating.com... ) isn't highly vulnerable...though I will be adding a few external forms.
My inclination is to move the site to a different host, and let them carry on with their SEO support in the new environment. I really don't see how any of their requests would effect SEO.
Again, I thank you both for reassuring me of what I already suspected. It struck me as odd enough to inquire.
I felt these were fairly ridiculous requests. I've built over 20 Concrete5 sites (pre 7.0 & 8.0) and have really never had any issues on the hosting platforms my clients use. Even a few sites with 100's of members with all sorts of editing and uploading capabilities.
I feel this other developer may be trying some subtle psychological intimidation. I will give them credit in that they manage all of their own servers so they may be hyper-vigilant. That said, most of these requests have never struck me as CMS variables.
As you intimated ob7dev, this developer is a WordPress man...and they've told me web development isn't really their specialty. They are local SEO and hosting specialists in Eugene, Oregon.
I'm really not sure what his concerns are as the site of topic
(http://www.priorityoneheating.com... ) isn't highly vulnerable...though I will be adding a few external forms.
My inclination is to move the site to a different host, and let them carry on with their SEO support in the new environment. I really don't see how any of their requests would effect SEO.
Again, I thank you both for reassuring me of what I already suspected. It struck me as odd enough to inquire.
Whatever the answers you give, the SEO specialist will no-doubt recommend a new site in Wordpress as the solution to all the client's needs, and, by the way, they just happen to be able to do all that for them.
Worpress has many sprawling extensions. I wouldn't be at all surprised if there were Worpress extensions available to interface from the cms back-end to all sorts of operating system and environment tools that would be better left outside the cms, and in the process open up many more vulnerabilities than they purport to solve.
Worpress has many sprawling extensions. I wouldn't be at all surprised if there were Worpress extensions available to interface from the cms back-end to all sorts of operating system and environment tools that would be better left outside the cms, and in the process open up many more vulnerabilities than they purport to solve.
What John mentioned about plugins is important, because it's a major reason I believe c5 trumps wp in security :: The add-on marketplace for c5 is controlled by the c5 community ( real people! ).
In c5, people with 20+ years in web development must give the OK before the add-on goes live to the public, this is after being reviewed by knuckleheads like me with less experience who still offer valuable insight. But in the end, its no amateur pressing the OK button.
We manually check everything for security vulnerabilities.
This keeps 99.7% of vulnerable code out of the marketplace to begin with.
Since the most common way of hacking a CMS is to hack its plugins, this makes c5 a secure platform for end users looking for such.
If someone wants to argue CMS security, and chose wp as their promotion, you will notice they rely on third party software (patches or specialized wp hosting), whereas c5 is secured at the core by c5 devs.
So security for the c5 team seems top priority.
Security for wp, seems a lucrative market?
But again, I'm no pro, just someone with opinions.
I'll end by saying this: The gatekeepers of websites are the servers that run them.
In c5, people with 20+ years in web development must give the OK before the add-on goes live to the public, this is after being reviewed by knuckleheads like me with less experience who still offer valuable insight. But in the end, its no amateur pressing the OK button.
We manually check everything for security vulnerabilities.
This keeps 99.7% of vulnerable code out of the marketplace to begin with.
Since the most common way of hacking a CMS is to hack its plugins, this makes c5 a secure platform for end users looking for such.
If someone wants to argue CMS security, and chose wp as their promotion, you will notice they rely on third party software (patches or specialized wp hosting), whereas c5 is secured at the core by c5 devs.
So security for the c5 team seems top priority.
Security for wp, seems a lucrative market?
But again, I'm no pro, just someone with opinions.
I'll end by saying this: The gatekeepers of websites are the servers that run them.
I can also confirm what John said is correct, Wordpress has plugins for all those tasks.
I can also tell you that when you have so much monitoring performed by the CMS itself, your site sloooooooooowwwwwwwws down
I can also tell you that when you have so much monitoring performed by the CMS itself, your site sloooooooooowwwwwwwws down
No, this should be done on the server, not as part of a CMS
- monitor all url queries and prevent suspicious url exploits
concrete5 does not monitor queries, but we do a great job at preventing things such as XSS
- perform regularly scheduled scans of all files for malicious code
No, this should be done on the server, not as part of a CMS
- protect .htaccess and other configuration files
No, this should be done on the server, not as part of a CMS
- detect intrusions into the database
No, this should be done on the server, not as part of a CMS
- throttle login and url query attempts
we do throttle login
- lock out suspicious login attempts
we support IP blocking
- force SSL admin login and backend
Thats server configuration again,
- automatically block ip addresses that display suspicious activity
No, this should be done on the server, not as part of a CMS
- provide idle session logouts
you can change the default session time, and there is an addon to auto-logout people
- provide extensive activity logging and reporting
define extensive
- sends automatic email alerts for suspicious activity, file quarantines, etc.
No, this should be done on the server, not as part of a CMS
Mike