Novedades Drupal 7
Después de 3 años de desarrollo, la versión final de Drupal 7 vió la luz el pasado 5 de enero de 2011 (menudo regalo de reyes más bueno, jeje).
Ha nacido un CMS robusto, fiable, versátil y escalable con aspiración a Framework...
Me explico: en mi opinión los CMSs (gestores de contenidos) antiguos (ej. phpnuke, mambo, etc...) eran más cerrados y aunque te permitían publicar tus contenidos en Internet de forma fácil pero te limitaban la versatilidad y escalabilidad de tu proyecto on-line, sin embargo hoy tanto Drupal como Joomla como Wordpress te permiten desarrollar casi cualquier proyecto web, por eso podríamos afirmar que aspiran a Framework (marco de trabajo que te facilita el desarrollo minimizando la programación debido al uso de librerías contribuidas).
Una vez hecha la introducción pasemos a repasar algunas de las novedades de Drupal 7 con respecto a Drupal 6:
- Perfiles de instalación integrados en el proceso de instalación
- Cada idioma se distribuye en 1 sólo archivo facilitando la instalación
- El instalador te pregunta por tu país, zona horaria y recepción de actualizaciones
- El instalador no pregunta si quieres URLs limpias, si puede las activa
- Ya incluye las carpetas sites/all/modules y ./themes por defecto
- El archivo de configuración settings.php es ahora más completo
- Funcionalidad CCK para tipos de campos en contenidos personalizados incluida
- Incluye gestión de cron desde backend sin necesidad de tocar el servidor
- Incluye capa de FTP para instalar o actualizar módulos contribuidos
- Incluye capa de FTP para instalar o actualizar temas contribuidos
- Uso de tipos de datos ImnoDB en lugar de MyISAM, más potencia y seguridad
- Abstracción total de la base de datos que permite usar BB.DD. noSQL
- Integración nativa de la librería jQuery para efectos con JavaScript
- Mejoras en la usabilidad del panel de control back-end
- El tipo article incluye por defecto un campo imagen para ilustrar los posts
- La instalación, configuración y permisos de módulos está ahora unificada
- Drupal 7 incluye ahora un panel de control similar al de Joomla y Wordpress
Hay muchas más novedades pero se salen del propósito de este post introductorio.
Cosas que, en mi opinión, se podrían haber incluido pero no se ha hecho:
- Actualización del core semi-automatizada desde la capa FTP
- Posibilidad de añadir meta tags a cada nodo integrado en el core
- Editor wysiwyg para crear contenidos integrado en el core
Otros sitios en Internet donde hablan de las novedades de Drupal 7:
- http://cambrico.net/drupal/novedades-de-drupal-7
- http://cuencodigital.com/articulos/un_vistazo_a_las_novedades_de_drupal_...
- http://indexante.com/post/drupalcon-novedades-con-drupal-7
- http://carlos.rinconsanchez.com/novedades-en-drupal-7
- http://reyero.net/en/feliz_drupal7
No podemos hablar de drupal (uno de los CMS más extendidos) sin mencionar algo sobre la seguridad, al ser todo el código fuente de dominio público eso facilita la búsqueda y explotación de agujeros de seguridad por parte de los hackers, para evitar eso yo recomiendo seguir al menos las siguientes reglas básicas (basadas en mi sentido común):
- Usar prefijos de tablas para que los nombres de tus tablas no sean iguales a los de la mayoría
- El nombre del usuario super administrador no debería ser admin ni nada obvio
- Por defecto drupal muestra en pantalla todos los mensajes de error con información útil para su depuración, una vez el sitio está en producción hay que desactivar esa opción
- No dar permisos a archivos y carpetas que no sean estrictamente necesarios
- Mantener el código actualizado, ahora en drupal 7 es más fácil que antes
Hay muchos más consejos de seguridad que se me ocurren pero se salen del propósito de este post introductorio.
Cualquier petición de información adicional, aclaración, corrección o ampliación en la zona de comentarios, gracias.
Versión para impresora
Enviar a un amigo
Versión en PDF
Comentarios
Respecto a los puntos de seguridad
Corrigeme si ando errado Andy, pero tras leer el post. Me ha surgido la duda del porque de la importancia del nombre de usuario God, ya que si no ando errado este siempre es el 1. Con lo que usando el link sin alias http://www.andymalaga.com/user/1 das con el nombre del usuario dios en cualquier site Drupal q permita consultar perfiles de usuario. Así pues da igual poner admin, siteadmin o amo.
Veo mas seguro, bloquear al usuario 1 por defecto y solo desbloquearon cuando sea realmente necesario usando de Admin normalmente a otro usuario con los privilegios marcados, sin ser God.
Para nada te equivocas, al contrario...
Con respecto al usuario que tú llamas GOD y yo llamo SuperAdmin (ambas cosas quieren decir lo mismo, es decir es un usuario que no necesita que le asignes permisos para nada ya que los tiene para todo, lo explico para los que no lo sepan).
Tu idea de bloquear al usuario que se crea durante la instalación (user/1) y acto seguido crear un usuario nuevo (user/2) y darle a él todos los permisos me parece más segura pero más engorrosa ya que requiere andar activando permisos manualmente pero en drupal 7 se crea automáticamente un rol de admin que por defecto va adquiriendo los permisos que le indiques automáticamente asi que usando Drupal 7 puedes obtener más seguridad con menos esfuerzo.
Gracias por el comentario, cualquier otra idea para la seguridad será bien recibida.
De hecho es mucho menos molesto de lo q comentas ;)
La funcionalidad que comentas de Drupal 7 llevo haciendola a mano desde Drupal 4.6. Solo hay que crear un rol Admin y darle todos los privilegios una sola vez. De hecho el usuario 1 (En SAP llamamos Dios a ese usuario ;) solo te es imprescindible cuando vas a hacer un update.php, teniendo acceso via SSH (El ftp por cuestiones de seguridad no lo uso en algunos casos) al settings.php puedes llegar a efectuar el update con otro usuario distinto al 1 poniendo la variable $update_free_access en verdadero.
En Scenebeta llevamos 5 años mezclando niños con Drupal, puedes imaginar lo peligroso que puede llegar a resultar efectuar esa mezcla sin tener un buen control sobre los privilegios que puede tener cada rol. El control de privilegios fue uno de los motivos por lo que nos decantamos por Drupal en ese proyecto. Si ojeas veras q hay Superadmins y Admins normales, Editores, Programadores, Moderadores, Aprendices y seguro q me dejo algun q otro rol por el camino. Si le sumas el hecho de trabajar en modo multisite compartiendo ciertas tablas realmente si que se vuelve complicado, pero vaya solo llegas a tales extremos en proyectos muy especificos.
Ya habras visto que soy un poco escurupuloso en algunos casos, pero creo q cuando haces algo es importante hacerlo bien y usar al usuario 1 para tareas del dia a dia seria el equivalente a usar por defecto el usuario root para el uso de un sistema unix, es mas comodo? si, obviamente. Pero no es lo mas recomendable.
Niños con drupal, interesante combinación... jaja
Todos tus consejos por la seguridad yo los veo muy sabios aunque con una única excepción, una web con 1 único usuario con privilegios. :-)
La verdad es que han gustado
La verdad es que han gustado bastante las mejoras que han introducido, aunque tal y como indicas, podría mejorar las actualizaciones y el editor.
Para seguridad adicional, además de realizar ciertas medidas de seguridad e ir manteniendo el sistema actualizado, no está mal suscribirse al feed de alguna base de datos pública en la que pueden ir apareciendo los fallos que se encuentran en cada software como en http://www.exploit-db.com , así que se puede estar atento a lo que aparece sobre Drupal o cualquier otro CMS ;) http://www.exploit-db.com/search/?action=search&filter_description=drupal
Saludos!
Hola amigo Yo estoy recien
Hola amigo
Yo estoy recien empezando en el mundo de drupal.. y me parece una excelente herramienta.. de lo mejor.. y quisiera preguntarte unas cosas interesantes que e visto en esta pagina:
Tu barra de compartir en diferentes redes sociales.
Tu barra de voto con estrellas
Si no es mucha molestia indicarme los nombre de los modulos para probarlos.. muchas gracias.. y arriba drupal!!
Saludos
Cuando puse en marcha el blog
Cuando puse en marcha el blog redacté un post explicando como lo había hecho incluyendo los módulos utilizados:
http://www.andymalaga.com/como-se-hizo-www-andymalaga-com
Posteriormente he añadido alguno nuevo y quitado alguno que dejó de gustarme, concretamente el de marcadores sociales que me preguntas se llama "SexyBookmarks"
Muy buenos los comentarios,
Muy buenos los comentarios, tienen toda la parte lógica que cabe de esperar sobre seguridad en Drupal, pero os olvidáis de una cosa, he desarrollado muchos módulos para Drupal 6 y ahora con Drupal 7, he visto muchas veces que en los códigos contrib (incluso en el core) se usa mucho if ($user->uid == 1) por ejemplo:
./modules/user/user.module: if ($account->uid == 1) {
./modules/user/user.module: if ($account->uid == 1) {
./update.php: if (!empty($update_free_access) || $user->uid == 1) {
Cosa que me parece muy mal pero que tiene su sentido, si tienes un usuario God, root, SuperAdmin, SuperMan o como lo queráis llamar... que mas da el nombre que tenga si cualquiera con unos mínimos conocimientos de Drupal puede obtener el nombre del uid 1 simplemente mirando los nodos del 2 al 100 que suelen '$node->type = page' (páginas) con enlaces a menús que seguramente en muchos casos tengan la información de autoría, hasta que Drupal 7 no coja color y funcione 100% bien con el rol ese de admin (por que esta muy muy muy muy verde y me hace mucha gracia los sitios que promociona en Drupal.org que usan Drupal 7 que muy probablemente serán páginas estáticas con un WYSIWYG por que 'petar peta por todas partes' en cuanto metes un par de módulos que hagan algo medio normal), solo hasta entonces no sera buena solución usar un usuario distinto a uid 1.
Mi recomendación es sin duda usar el usuario uid 1 y poner el nombre que le queráis poner, usar el módulo rules para que no entren los anónimos al URL user/1 o incluso a todos los perfiles según el caso y listo.
También podéis proteger esto simplemente con un .htaccess que es mas sencillo y mas eficaz.
Hay muchas maneras de evitar que vayan al uid 1 pero no merece la pena ni mucho menos, reventar un sistema Drupal no es tan sencillo como antes con Joomla! y el famoso option,com_user/view,reset/layout,confirm que muchos conocen...
Saludos.
Muchas gracias por tu
Muchas gracias por tu contribución sobre seguridad drupal, resulta interesante.
También quiero añadir una cosa: los archivos en mayusculas, por ejemplo CHANGELOG.txt deberían ser borrados o limitado su acceso ya que pueden servir para averiguar ejemplo la versión exacta del core o de los módulos y buscar vulnerabilidades para esa versión concreta.
Con lo escrito en esta entrada y otras ya va dando para una entrada dedicada a seguridad en drupal, jeje.
Pingback
[...] » noticia original Esta entrada fue publicada en Joomla. Guarda el enlace permanente. ← VIDEO: Presentación de Guillermo Peñalosa, Presidente de 8-80cities.org Montar un servidor web y un sitio web en Windows 7 con AppServ y Joomla! → [...]
Enviar un comentario nuevo