Thread

[Mod edit: split from the thread ExpressionEngine & Best Security Practices]

I don’t want to draw this thread of course. If there’s traction on the following point, a new thread is probably warranted.

We need to protect our clients from being hacked. But we also need to protect our own companies. We all have some clients who host their sites, and prefer to do so, with providers who are not very serious about security. They choose these providers for different reasons. As well, many of us work on large sites where many people have access to sensitive areas in order to be able to collaborate on development.

We need to adopt business rules that not only protect our clients but also protect ourselves. Do you and 10 other people login via SFTP to a big important site using the same username and password? If that site has a security compromise, are all 10 people subject to accusation? Are there many super admins on a client site? Can any super admin change the password of another super admin and login as them to do something nefarious? Doesn’t this open the door to accusation as well?

We need to also talk about ways to remove ourselves from the line of people considered or accused when security is compromised. Separate FTP login accounts, other security measures, etc. I would very much appreciate input.

mk

I went ahead and split it, Mitchell, as it’s a very compelling point of discussion, one that I’d like to hear the community discuss if for no other reason that some of these problems may have a technological solution.

Solspace,

Excellent idea! I recently began a fine tune of my security practices! I just started using separate FTP accounts using SSH.

Derek,

I have no idea how you would implement this but here is a “different” idea. What about having FTP users integrated into ExpressionEngine. For useful things like:

1. Knowing Who Edited “Template Name” Last (for using the flat file method)

2. Setting Up Permissions using those FTP accounts for Editing Templates

I know the work that would go behind it would be difficult but it was just a crazy idea, not sure if it’s actually worthwhile.

Unfortunately, real SFTP is not available to PHP unless libssh2 has been compiled with it, which is rather uncommon.

One thing that we did was develop a little module that tracked CP activity in a bit more detail than is native to EE. I have no complaints about how EE logs CP activity. When we have higher profile clients and we want to be able to track activity in a more detailed manner, we use this module. To be sure, it’s all DB based. Tracking can be easily deleted if you know where to look. But one would have to know that the module is running and know what to delete. Honestly, it doesn’t amount to much.

I’ve found that if someone wants to get into your site, they will get in. So I am considering an approach to policy and security that seeks to eliminate myself and my team as suspects in the line-up that is inevitable when a site is hacked. I haven’t made much progress to be honest.

Another question: how do other developers transmit username and password data? When your hosting provider sends you your access info, do they send it through email? And if so, can that method be made more secure?

mk

Of course to add to complexities for security a few things to consider:

a) Do any of your staff or your clients use public access networks, ie: wifi in a coffee shop, or the airport?  If yes then non-SSL login to EE (or any web applications) is vulnerable to interception.

b) Do your staff and your clients, mostly in the case of Windows users, run full up-to-date AV/Malware scanners?  Even if all of your access to a site is over sFTP/SSH, or httpS/SSL protected web pages, a keylogger installed on one of their systems via malware will pick up the URL and keys typed before the encryption happens between the client OS and the server.

c) on the same note as b) are any of your staff or your clients computers used by people other than your staff or clients?  Have a friend that constantly was trying to figure out why malware and viruses were being found on his Windows XP test system in his office, turned out his wife was using that system for playing online flash games and a number of those sites constantly were installing over and over the same infections on the system.  So do their wife/husband, kids/teenagers, or whatever use that computer at times?

d) Does the server/hosting provider/etc. keep detailed logs on all logins at the sFTP level for association of login vs. what was uploaded/deleted/downloaded from the site?  If the server is self run by you or your clients (self-managed VPS/dedicated servers at a hosting provider, or even fully in-house), if so, are logs accessible to the people who have login access? or are logs collected on central/secure syslog servers keeping log data secure off the main server(s)?

e) Even if your hosting provider (like we do, and have without issue for over a decade) provide your initial login information via e-mail, how would you distribute that information to your staff and client? Do you do it by e-mail? unencrypted and/or free IM client traffic/services?

If that data was provided to you via a one-time secure web page access, how would you turn around and provide those details to everyone else?  Would it again still be by the same email or non-secure IM conversation? 

You would not want those details forever available on a web page as that leaves even our systems open to compromise allowing the normally one way hashed passwords to be visible in some context on a public web site, and even if it was you would need to distribute that URL or access method to the real sFTP/Site login data, in turn compromising the possible security of that data indirectly.

f) If the issue is a persistent issue, ie: you are not sure if its a hack via public access, or a malicious deed by someone on staff (ie: inside job), security products (if you are running on self managed systems) like http://www.tripwire.com/products/servers/ can take a base-line of all files on the system, details are stored in a secure database (or off server in a central server), and you can run periodic (daily) runs through specific data to see if changes took place.  Which if you do research into security concerns for corporations, inside attacks are much more common and costly then external forms of hacking attempts at systems.  Keep in mind on active web site projects this can be daunting, and separate products would need to be used to track database changes vs. file system level changes.  These take a lot of management/monitoring on busy setups as you will find things like directories for caching/captchas/locations that allow image/file uploads will modify the base-line and will require likely daily review and tracking.  All in all this works great for things like overall server/OS configuration files, not so well on groups of files that again change rapidly and normally through daily usage.

g) In the event an issue does happen, do you have contact with either the hosting provider, or in-house people that have the expertise to handle security concerns, exploit investigation, etc. to assist in the detailed diagnostics that maybe needed?

and last on my list for now, are scripts and files used in the site monitored with the given authors web site and updated timely any time major bugs or security fixes are released, and in general any time updates themselves are released.  Usually the farther behind you are in keeping all web applications updated, the harder it becomes to both know about issues, get support, and upgrade quickly if there is an issue.

You can get incredibly detailed on the security side of things to the point it can actually get counter productive to a degree that it becomes less secure, or almost completely non-functional.

Sorry for the quickly done, but long ramble, probably will need to go back and clean this up a little once I am done with my current project tonight.

One thing that we did was develop a little module that tracked CP activity in a bit more detail than is native to EE. I have no complaints about how EE logs CP activity. When we have higher profile clients and we want to be able to track activity in a more detailed manner, we use this module. To be sure, it’s all DB based. Tracking can be easily deleted if you know where to look. But one would have to know that the module is running and know what to delete. Honestly, it doesn’t amount to much.

I’ve found that if someone wants to get into your site, they will get in. So I am considering an approach to policy and security that seeks to eliminate myself and my team as suspects in the line-up that is inevitable when a site is hacked. I haven’t made much progress to be honest.

Another question: how do other developers transmit username and password data? When your hosting provider sends you your access info, do they send it through email? And if so, can that method be made more secure?

mk

That sounds great! I need something like that because I feel that the logs are a little bare. Also, I would like the ability to set a “change password on next login” feature for when super admins create new members in the CP. This to me seems more secure than setting one for them by hand because you know they don’t change it.

That sounds great! I need something like that because I feel that the logs are a little bare. Also, I would like the ability to set a “change password on next login” feature for when super admins create new members in the CP. This to me seems more secure than setting one for them by hand because you know they don’t change it.

You can create their account, assigning a strong gibberish password, giving them no details at all, but instructing them to use the Forgot Password feature prior to their first login.  This gives a little buffer for yourself as well, as they never tell you (nor you them) their password.

Derek,

That’s the method that I use right now but I was thinking it could be implemented a little more like Active Directory. So in 7 months or whatever you can go through and force one, or all, to change their passwords.

Indeed, I was just giving a suggestion for starting things out.  And you can of course run an UPDATE on the exp_members table setting the password field for everyone to random hashes, which would force them to use the Forgot Password again.  I recognize that it’s not elegant by any means, but that the benefit of such a feature can be mimicked to an extent without a lot of effort.

I understand what you mean, I just wanted to give the guru the idea! 😉