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 <andrew.hick...@yale.edu> 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 [CODE4LIB@LISTSERV.ND.EDU <javascript:;>] on > behalf of Lin, Kun [l...@cua.edu <javascript:;>] > Sent: Friday, October 31, 2014 2:10 PM > To: CODE4LIB@LISTSERV.ND.EDU <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:CODE4LIB@LISTSERV.ND.EDU <javascript:;>] > On Behalf Of Cary Gordon > Sent: Friday, October 31, 2014 1:44 PM > To: CODE4LIB@LISTSERV.ND.EDU <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 <onei...@grace.nascom.nasa.gov > <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:CODE4LIB@LISTSERV.ND.EDU > <javascript:;>] On Behalf > >> Of Cary Gordon > >> Sent: Friday, October 31, 2014 11:10 AM > >> To: CODE4LIB@LISTSERV.ND.EDU <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 <l...@cua.edu <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:CODE4LIB@LISTSERV.ND.EDU > <javascript:;> > >>> <javascript:;>] On Behalf Of Cary Gordon > >>> Sent: Friday, October 31, 2014 9:59 AM > >>> To: CODE4LIB@LISTSERV.ND.EDU <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 <deni...@gmail.com > <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