Sistema de copias de seguridad para Confederac.io


#1

Una de las prioridades actuales de Confederac.io es

La idea es imaginar situaciones extremas y ver cómo podríamos restablecer Confederac.io. Este es un problema que muchas otras webs se habrán planteado, incluso en entornos sociales / activistas / sin ánimo de lucro.

Especifiquemos esto de manera más detallada (esbozo negociable).

Objetivo

Restablecer Confederac.io después de un ataque, habiendo perdido como mucho los datos correspondientes a los últimos 7 días previos al ataque.

Requerimientos

  • Copias de seguridad diarias para WordPress y Discourse.
  • Copias de seguridad semanal extraordinarias, en caso de que las copias diarias no estén disponibles.
  • Localización de las copias de seguridad en diversos servidores y soportes no relacionados entre si.
  • Acceso a las copias de seguridad por parte de dos personas u organizaciones o más, de absoluta confianza.
  • Protección de los datos personales de lxs usuarixs de Confederac.io.
  • Documentación para restablecer Confederac.io disponiendo sólo de las copias de seguridad.

¿Tiene sentido todo esto? Podríamos pensar en pasos para llegar hasta ahí, de manera que a cada paso mejoremos la seguridad y solidez del proceso.

¿Debería existir en algún sitio una buena receta o recopilación de buenas prácticas para proyectos activistas?


Objetivo: Confederac.ió beta
#2

Interesantísimo post, puede parecer algo conspiranoico pero visto lo visto con el retroceso de libertades en España y como esto parece ser tendencia a nivel mundial no es ninguna locura trazar un plan, de hecho dicen que “una persona prevenida vale por dos”.

De entrada esto genera una primera pregunta, ¿De qué tipo de ataque estamos hablando?, cuando se trata de una acción gubernamental el movimiento lógico esperado es un cierre del dominio intervenido por la policia judicial del estado.

Posible solución, levantar una copia del sitio rápidamente, a poder ser de una forma que sea esta vez imposible o muy difícil de tumbar, red Tor, Freenet, i2p u otros sistemas peer to peer.

Otro tipo de ataques, los más comunes perpetrados por grupos opositores suelen ser los ataques DDoS o DoS que son simplemente ataques que producen grandes cantidades de solicitudes al servidor y este al no poder dar el servicio se pierde la conectividad.

Este tipo de ataques no provocan perdida de datos así que quedan fuera de momento del tema copias de seguridad.

Ahora bién ataques de mayor calado que puedan obtener privilegios y acceso a la base de datos si que requieren del uso de esas copias de seguridad, en este caso yo recomendaría que desarrollaramos un script en bash que pueda correr un hosting (suponiendo por supuesto que es un servidor Linux) mediante un cronjob a horas intempestivas generando un backup de la base de datos y de los directorios susceptibles de sufrir cambios como los de imágenes. De esta forma nos aseguramos de disponer de una copia diaria.

Hasta aquí es relativamente sencillo, pero ¿Cómo distribuir esas copias en otros lugares fuera del propio servidor para que cierto número de personas con la receta adecuada puedan obrar con ellas en consecuencia? ¿un sistema cloud compartido?

Sigamos con el debate que es de sumo interés para un sitio como Surt del Cercle por ejemplo.


#3

La propuesta del script bash es por una sencilla razón, creo que esta receta que nos disponemos a crear debería servir para cualquier sitio web que deseé utilizarlo y no cerrrarnos a sistemas WordPress u otros cms que seguro tienen sus plugins de backup ya desasrrollados pero que poco sentido tienen si otro sitio web utiliza algun cms distinto o bien esta desarollada artesanalmente como es el caso de Surt del Cercle.


#4

Muchas gracias por la rápida respuesta.

Antes de seguir, si no lo has visto ya échale un vistazo a Infraestructura técnica.

Y sí, estoy de acuerdo en dar con un plan genérico que podamos utilizar aquí pero que otras puedan adaptar a sus sistemas. Al fin y al cabo, de los pasos de la cadena sólo el primero es particular y es el más sencillo. El resto son genéricos:

  1. Realizar copias regulares, tanto de los contenidos de cada aplicación como del servidor entero.

  2. Distribuir esas copias a otros servidores y soportes de manera regular, para evitar que un ataque a un punto sea fatal.

  3. Tener a diversas personas de confianza con acceso a estas copias, asegurando un bus factor decente.

  4. Tener instrucciones publicadas que permitan a alguien con acceso a la copia restaurar el sistema.

  5. Disponer de un canal de comunicación alternativo para ir informando.

  • Cierre del dominio
  • Intromisión al servidor y pérdida de acceso.
  • Destrucción de datos y copias de seguridad en el servidor intervenido.
  • Toc toc, la policía llama a la puerta de un sysadmin y se lo llevan de excursión a la Audiencia Nacional.

Cosas de este estilo que impliquen pérdida de acceso o control del servidor, destrucción de datos… DDos es otra historia. Robo de datos es más relacionado, pero también es otra historia.

Bueno, esto es lo que pienso que alguien experto en el tema debe haber pensado ya. Lo que he pensado (sin tener mucha idea) es que hay dos factores antepuestos: la distribución de las copias de seguridad y la privacidad de datos de lxs usuarxs en esas copias de seguridad. Cuanta más gente tenga acceso a esas copias más alta es la posibilidad de que alguien se deje vencer por la tentación del diablo…

Una manera de abordar este problema sería disponiendo de copias sanitizadas de las bases de datos, pero esto es bastante complicado de crear, mantener y restablecer. Igual garantizaría poder recrear una copia estática de la web o un volcado de datos, pero la misma web funcional que había antes… complicado.

Otra manera sería encriptando las copias de seguridad, lo que permitiría (por ejemplo) su distribución P2P en BitTorrent etc a la vez que sólo un reducido grupo de personas podrían hacer algo con ellas… si es que esto de la encriptación realmente funciona. Pero bueno, los únicos datos realmente de valor serían los correos electrónicos de lxs usuarixs y sus mensajes privados (que ya advertimos que no son realmente privados puesto que no están encriptados). El resto es información pública que alguien podría escanear silenciosamente.


#5

La primera parte estamos de acuerdo en que los tipos de ataque que esperamos de tipo gubernamental se solucionan con la puesta en marcha de una copia de la web bajo ciertas condiciones de seguridad que no impliquen un rápido cierre de la nueva copia y que para ese efecto las copias no pueden estar en ese mismo servidor.

Ahí tenemos un primer problema identificado en espera de su solución técnica.

El segundo grupo de ataques que impiden el acceso al servidor por parte de hackers solo pueden ser solucionados con ayuda del proveedor de servicios ya que segun el link que nos muestras sobre infraestructura técnica no disponemos de servidor propio. Poco podemos hacer ahí creo con los privilegios sobre el servidor compartido.

Sobre la distribución y la privacidad.

El propio hecho de nombrar a cierto número de personas administradores por el riesgo del bus factor ya implica cierto compromiso con la privacidad de los datos de los usuarios al igual que se entiende que lo tiene el administrador actual no creo que sea un problema en si mismo.

Una distribución segura seria un cronjob que a ser posible comprima con contraseña la copia de seguridad y la envie a los correos electrónicos de los administradores elegidos, los cuales dispondrán de la receta punto por punto sobre como actuar en cada caso.

Esto es un punto de partida: https://voragine.net/weblogs/usando-bash-y-cron-para-automatizar-la-copia-de-seguridad-de-una-base-de-datos


#6

Seguramente un punto crítico en cuanto a la distribución de una copia de seguridad es el peso de la misma, una base de datos no es problema pero un directorio de imágenes es más preocupante como archivo adjunto de un correo electrónico…


#7

Si te refieres a que no tengo una torre bajo la mesa de mi oficina, es cierto, no la tengo. Pero tengo acceso root a una instancia. Bueno, dos, porque WordPress y Discourse están separados.

De hecho ambos servidores tienen backups semanales automáticos del sistema entero, que son guardados en un hardware aparte. Y de hecho crear una instancia nueva con un backup parece ser tan sencillo como seleccionar una opción en el menú y pagar una suma modesta.


#8

Propongo que a la vez que se identifican los puntos clave y sus posibles soluciones pasemos a la acción y se vayan plasmando en un documento online, yo uso https://cryptpad.fr/ que permite la edición online por un grupo de usuarios a la vez usando markdown por ejemplo.

Algo así (versión no editable): CryptPad


#9

Discourse permite la conversión a wiki del primer mensaje de un wiki. Puedes ver cómo funciona aquí mismo, arriba. ¿Empezamos así por simplicidad y ya veremos si necesitamos algo más sofisticado?

Distribuir copias por correo electrónico no es la manera ideal, efectivamente. SSH, FTP, P2P, XMPP… ¿Hay alguna alternativa libre a Dropbox?

Por otro lado, he dado de alta nuestras webs en archive.org. No va estar de más. Habrá que mirar en unos días si han sido bien escaneadas.


#10

Hay un pequeño problema que veo con eso del envío remoto y es que en el caso de intervención del dominio los informáticos de la policia judicial encontraran las cuentas de ftp o lo que sea en el proceso de backup y ese será el nexo de la web cerrada con los siguientes administradores. Igual esto ya es rizar el rizo pero como esto es una especie de brainstorming inicial ahí lo dejo.

Las alternativas libres a Dropbox hasta donde yo se son:


#11

Bueno, yo diría que escondernos de la policía u otros escenarios “dark net” ya se escapa de los objetivos de esta tarea. Si queremos una web que entre de nuevo en funcionamiento y avise a sus usuarixs, siempre va a ser trivial ver dónde está la nueva web y quién la administra.

Un factor a tener en cuenta es la dispersión de servidores y administradorxs en diferentes jurisdicciones legales / estados.


#12

Más que de la policia en si que suena un poco ‘dark’ como dices es esconderse de la censura y las consecuencias que acarrea entrar en su lista negra… Como digo solo son ideas arrojadas a la discusión que siempre pueden despertar nuevas ideas en otros usuarios :wink:


#13

Separar la distribución de las copias encriptadas (por ejemplo a FTPs públicos o redes P2P) de la distribución de los passwords para desencriptar las copias (que se podría realizar de manera muy privada) complicaría el trabajo de identificar quién puede hacer algo con esas copias.


#14

Acabo de descubrir que Plesk tiene la opción de programar las copias de seguridad y enviarlas a un ftp remoto y este servicio se programa como un cronjob. No se si Cpanel tiene también esa opción.

Además protege el backup con contraseña.

Ahí lo dejo por si a alguien le puede servir.


#15

Por si sirve (no lo he leído entero):


Confederada 4: Procesando el Kaos
#16

Más por si sirve:


#17

Bueno, o igual no:

(vía Xan)