[support] Subject: Re: Site Hacked

[Earnie Boyd]

On Sat, Oct 27, 2012 at 8:12 PM, Roger wrote:
>> Pl go to drupal support and give your details and report them about
>> hacking better change admin password
> No point in doing that. It's a whole of Drupal design thing, including
> engine and modules. It is  not a small problem.
> The inherent problems, for us, with Drupal 7 are:
>
> - The engine is part of the site and can be played with/altered while
> live. Convenient but potentially damaging.
>

Not if you give the correct permissions on the files.

> - There is no way to not have admin on a live site. In fact there should
> be no admin at all on a live site or as a minimum, a disabling switch.
> Without admin access a live site is less vulnerable. It can be hidden
> but not disabled.

Impossible.  You always must have an administrator to get the site
configuration correct and to run updates.

> Live should be just display of data with limited data input and change
> thereof. This requires another mindset for Drupal as a whole.
>

That depends on the nature of the site.  If you don't want to have
users inputting data then don't allow the data to be input.  That is
done via the permissions the administrator would set up.  Drupal is
designed more to present dynamic data and not static but that doesn't
mean the dynamic data cannot be static, it surely can.  In fact those
sites that use Drupal for the dynamic data also have static data that
is displayed.

> - For us, some components, that we needed, like say Work bench,
> taxonomy, and several others need admin permissions for the user to
> enter/change data. This opens a pandora's box of risk.

Do they need "admin permissions" or just "permissions"?  Drupal is
designed to allow the site development to provide hooks to modify the
workflow of the system.  You can even add permissions that are not
available by default.  This is done via alter hook implementations
that modify the form data and even the form submission routines.

> Alternatively we write work around code or find and install yet another
> set of "work around" modules to overcome the problem. This in turn
> introduces potential threats, risks, more maintenance, etc. To date we
> have several work around modules.

I wouldn't call any module a "work around", it is the way Drupal works
to provide flexibility to the design.  If you use the Drupal set of
standards for coding then you should not have introduced potential
threats but of course there is always the possibility.

> Creating modules or rewriting is not an option for me. I do not like
> PHP, it's boring, cumbersome and repetitive.
>

Then hire someone who likes it.  There are many.

> - Configurations are stored in the database, there is no way to dev or
> test without entirely separate installs which require copies of the live
> database updated into the dev/test areas. We can't work on updated data
> without potentially wrecking d/t changes and vice versa.

Drupal 7 has the thing called sites/sites.php which can map a site to
the configuration data and can be used to map 'dev.example.com' to
'example.com/settings.php'.  Settings.php can also be used to create
the configuration data.  If the data required is already mapped in the
global variable $conf then it will not be pulled from the DB.

E.G. sites/sites.php
$sites['dev.example.com'] = 'example.com';

>   Ideally configurations could be separate from data. Dev/test could
> instead  be a subset of live data with just the config and display
> changes worked upon.
> We don't have the expertise to go through every table to find which is
> linked to which.
>

There are contrib modules created to help with this.  You'll be
excited to know that configuration management improvement is one of
the goals for D8.

> - There is no clean, obvious way to move a small change from dev/test to
> live site without overwriting the database or part thereof which means
> that latest data may be changed or some field content no longer relates
> to changes. Unless yet another set of protocols is introduced with more
> complication.
>

Modifying the database always requires the site be in maintenance
mode.  Development cycles that code for 3 or 4 months then deploy
always require coordination especially when the database data is
involved.  However, this is normal workflow and nothing new nor unique
to Drupal.  It is expected to have to manage the production deployment
in such a manner as to not break the production site and to deploy in
as fast as possible haste to minimize the downtime.  There are contrib
modules to help with moving the configuration from development to
production.  They do not need to remain active during production mode.

> - Introducing changes as above, for us, have wrecked parts of the live
> system because it seems, virtually every table is referred to by every
> other table in some way.
>

What tables would you be changing?  Yes the data dependencies are
interwoven between tables; again nothing unique to Drupal but is
standard database construction.

> - When Admin, on a static IP, is locked out there is no way, apart from
> waiting many hours, for the ip lockout to be dropped. Unless there are 2
> or 3 admins and one or those resets the lockout, not easy!
>

Is this Drupal related or site host management related?  You might
need to take a look at the banned sites file in the /etc folder and
add an IP address to the allowed sites file in the /etc folder.

> - We routinely use extremely convoluted very long passwords, changed
> regularly. The password is the only hidden part of a log in.
> User names are displayed to all and sundry. For us, hiding actual user
> names and displaying preferred user names unrelated to login would be
> more secure.

The authentication can be modified and can be configured to be
something else besides the standard authentication.  It might require
PHP coding or understanding of authentication configuration.

> Barriers to hacking Drupal core are the password and the 5 tries and
> you're out. Hidden user name and display of preferred, but different
> name could add another level of security.
>

So use the alter hooks to add another field.  You can do it even
though you hate to code in PHP because it's boring.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd