If you can migrate to a maintained service, you could use feeds or migrate
to move your content. You could also take that approach on your own
new site. Obviously, none of your entities — nodes, menus, users, blocks,
taxonomies, etc. — should contain executable code.
I suggest that you do not migrate users or menus, unless you have the
ability to validate your data.
I love the internets, but I have learned that nobody should be
running public facing services — open-source or other — unless they are
prepared to maintain them, including managing a disaster recovery plan and
vigilantly monitoring and acting on security notices. If this is not
doable, use a service provider to manage it. The days of running services
from a computer under a desk are gone.
Cary
On Sunday, November 2, 2014, Hickner, Andrew <[log in to unmask]>
wrote:
> I'd be curious to hear how others are proceeding. We had already planned
> to migrate our D7 sites to a centralized Drupal instance offered here at
> Yale and this has just accelerated the timetable. I imagine there are a
> lot of libraries running Drupal though who don't have this kind of option
> and might not have pre-October 15 backups to revert to (we don't!)
>
>
>
> Andy Hickner
> Web Services Librarian
> Yale University
> Cushing/Whitney Medical Library
> http://library.medicine.yale.edu/
>
> ________________________________________
> From: Code for Libraries [[log in to unmask] <javascript:;>] on
> behalf of Lin, Kun [[log in to unmask] <javascript:;>]
> Sent: Friday, October 31, 2014 2:10 PM
> To: [log in to unmask] <javascript:;>
> Subject: Re: [CODE4LIB] Terrible Drupal vulnerability
>
> I think so. However, Cloudflare in their blog post claim they have develop
> a way to block the attack immediately when the vulnerability was announced.
> Whether or not they know the exploit ahead of time or not, it would be good
> to know someone is watching out for you for $20 a month. And you will be
> mad if you took Oct 15th off without it. I just check, I patched my
> instance on Oct 16th. Not sure what's going to happened.
>
> Kun
>
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask] <javascript:;>]
> On Behalf Of Cary Gordon
> Sent: Friday, October 31, 2014 1:44 PM
> To: [log in to unmask] <javascript:;>
> Subject: Re: [CODE4LIB] Terrible Drupal vulnerability
>
> The vulnerability was discovered in the course of an audit by SektionEins,
> a German security firm, and immediately reported to the Drupal Security
> Team. Because this was a pretty obscure vulnerability with no reported
> exploits, the team decided to wait until the first scheduled release date
> after DrupalCon Amsterdam to put out the notice and patch. Obviously, they
> knew that once word of the vulnerability was announced, there would
> immediately be a wave of exploits, so they imposed a blackout on any
> mention of it before October 15th. I think that they stuck to their word.
>
> Of course, attacks started a few hours after the announcement.
>
> Cary
>
> > On Oct 31, 2014, at 9:38 AM, Joe Hourcle <[log in to unmask]
> <javascript:;>> wrote:
> >
> > On Oct 31, 2014, at 11:46 AM, Lin, Kun wrote:
> >
> >> Hi Cary,
> >>
> >> I don't know from whom. But for the heartbeat vulnerability earlier
> this year, they as well as some other big providers like Google and Amazon
> were notified and patched before it was announced.
> >
> > If they have an employee who contributes to the project, it's possible
> > that this was discussed on development lists before it was sent down
> > to user level mailing lists.
> >
> > Odds are, there's also some network of people who are willing to give
> > things a cursory review / beta test in a more controlled manner before
> > they're officially released (and might break thousands of websites).
> > It would make sense that companies who derive a good deal of their
> > profits in supporting software would participate in those programs, as
> well.
> >
> > I could see categorizing either of those as 'ahead of the *general*
> > public', which was Kun's assertion.
> >
> > -Joe
> >
> >
> >
> >> -----Original Message-----
> >> From: Code for Libraries [mailto:[log in to unmask]
> <javascript:;>] On Behalf
> >> Of Cary Gordon
> >> Sent: Friday, October 31, 2014 11:10 AM
> >> To: [log in to unmask] <javascript:;>
> >> Subject: Re: [CODE4LIB] Terrible Drupal vulnerability
> >>
> >> How do they receive vulnerability report ahead of general public? From
> whom?
> >>
> >> Cary
> >>
> >> On Friday, October 31, 2014, Lin, Kun <[log in to unmask] <javascript:;>>
> wrote:
> >>
> >>> If you are using drupal as main website, consider using Cloudflare Pro.
> >>> It's just $20 a month and worth it. They'll help block most attacks.
> >>> And they usually receive vulnerability report ahead of general public.
> >>>
> >>> Kun
> >>>
> >>> -----Original Message-----
> >>> From: Code for Libraries [mailto:[log in to unmask]
> <javascript:;>
> >>> <javascript:;>] On Behalf Of Cary Gordon
> >>> Sent: Friday, October 31, 2014 9:59 AM
> >>> To: [log in to unmask] <javascript:;> <javascript:;>
> >>> Subject: Re: [CODE4LIB] Terrible Drupal vulnerability
> >>>
> >>> This is what I posted to the Drupal4Lib list:
> >>>
> >>> --------------------
> >>>
> >>> By now, you should have seen https://www.drupal.org/PSA-2014-003 and
> >>> heard about the "Drupageddon" exploits. and you may be wondering if
> >>> you were vulnerable or iff you were hit by this, how you can tell
> >>> and what you should do. Drupageddon affects Drupal 7, Drupal 8 and,
> >>> if you use the DBTNG module, Drupal 6.
> >>>
> >>> The general recommendation is that if you do not know or are unsure
> >>> of your server's security and you did not either update to Drupal
> >>> 7.32 or apply the patch within a few hours of the notice, you should
> >>> assume that your site (and server) was hacked and you should restore
> >>> everything to a backup from before October 15th or earlier. If your
> >>> manage your server and you have any doubts about your file security,
> >>> you should restore that to a pre 10/15 image, as well or do a
> reinstall of your server software.
> >>>
> >>> I know this sounds drastic, and I know that not everyone will do that.
> >>> There are some tests you can run on your server, but they can only
> >>> verify the hacks that have been identified.
> >>>
> >>> At MPOW, we enforce file security on our production servers. Our
> >>> deployments are scripted in our continuous integration system, and
> >>> only that system can write files outside of the temporal file
> directory (e.g.
> >>> /sites/site-name/files). We also forbid executables in the temporal
> >>> file system. This prevents many exploits related to this issue.
> >>>
> >>> Of course, the attack itself is on the database, so even if the file
> >>> system is not compromised, the attacker could, for example, get
> >>> admin access to the site by creating an account, making it an admin,
> >>> and sending themselves a password. While they need a valid email
> >>> address to set the password, they would likely change that as soon as
> they were in.
> >>>
> >>> Some resources:
> >>> https://www.drupal.org/PSA-2014-003
> >>>
> >>> https://www.acquia.com/blog/learning-hackers-week-after-drupal-sql-i
> >>> nj
> >>> ection-announcement
> >>>
> >>> http://drupal.stackexchange.com/questions/133996/drupal-sa-core-2014
> >>> -0 05-how-to-tell-if-my-server-sites-were-compromised
> >>>
> >>> I won't attempt to outline every audit technique here, but if you
> >>> have any questions, please ask them.
> >>>
> >>> The takeaway from this incident, is that while Drupal has a great
> >>> security team and community, it is incumbent upon site owners and
> >>> admins to pay attention. Most Drupal security issues are only
> >>> exploitable by privileged users, and admins need to be careful and
> >>> read every security notice. If a vulnerability is publicly
> exploitable, you must take action immediately.
> >>>
> >>> Thanks,
> >>>
> >>> Cary
> >>>
> >>> On Thu, Oct 30, 2014 at 5:24 PM, Dan Scott <[log in to unmask]
> <javascript:;>
> >>> <javascript:;>> wrote:
> >>>
> >>>> Via lwn.net, I came across https://www.drupal.org/PSA-2014-003 and
> >>>> my heart
> >>>> sank:
> >>>>
> >>>> """
> >>>> Automated attacks began compromising Drupal 7 websites that were
> >>>> not patched or updated to Drupal 7.32 within hours of the
> >>>> announcement of
> >>>> SA-CORE-2014-005
> >>>> - <https://www.drupal.org/SA-CORE-2014-005>Drupal
> >>>> <https://www.drupal.org/SA-CORE-2014-005> core - SQL injection
> >>>> <https://www.drupal.org/SA-CORE-2014-005>. You should proceed under
> >>>> the assumption that every Drupal 7 website was compromised unless
> >>>> updated or patched before Oct 15th, 11pm UTC, that is 7 hours after
> >>>> the
> >>> announcement.
> >>>> """
> >>>>
> >>>> That's about as bad as it gets, folks.
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Cary Gordon
> >>> The Cherry Hill Company
> >>> http://chillco.com
> >>>
> >>
> >>
> >> --
> >> Cary Gordon
> >> The Cherry Hill Company
> >> http://chillco.com
>
--
Cary Gordon
The Cherry Hill Company
http://chillco.com
|
