¿Es incluso una idea razonable tener un servidor en casa para obtener copias de seguridad de todos los sitios web de mis clientes periódicamente?
Sí, siempre que siga algunas precauciones.
¿Existe alguna amenaza de seguridad para mis computadoras conectadas en la misma red / enrutador que el servidor que tendrá acceso FTP?
Sí, si no sigue algunas precauciones.
- ¿Qué pasa si mi servidor en la nube se ve comprometido? Entonces es probable que mi PC de respaldo en el hogar también se vea comprometida porque el servidor de la nube puede conectarse a ella.
- ¿Qué sucede si mi PC de respaldo en el hogar está comprometida? ¿A qué tiene acceso?
Por lo tanto, básicamente desea reducir el riesgo de compromiso de cualquiera de los sistemas, al tiempo que limita el acceso que tendría un atacante en caso de que logre comprometer uno o ambos.
Precauciones
- No use FTP ya que las credenciales se pueden transmitir sin cifrar, ejecute un servidor SSH en una caja de Linux y conecte / transfiera archivos usando
scp. Alternativa: busque un servidor de tipo SFTP o SCP que se ejecute en Linux, Mac o Windows.
- Use una cuenta SSH limitada que solo tenga acceso scp al directorio de respaldo, y solo acceso suficiente para enviar el respaldo.
- Use una clave privada para la autenticación
- Con los pasos anteriores, si su servidor remoto en la nube es forzado y le roban la clave privada, ¡un atacante solo tendrá acceso a una copia de seguridad de un servidor al que ya tiene acceso!
- Ejecute un firewall que tenga características de reenvío de puertos / NAT y DMZ (incluso podría ser el enrutador WiFi de su ISP si tiene un firmware actualizado sin vulnerabilidades conocidas; verifique esto dos veces: los enrutadores ISP más antiguos están plagados de errores)
- Coloque su computadora de respaldo en el hogar en una DMZ. De esta manera, no obtiene acceso fácilmente a ninguna de sus otras computadoras y, por lo tanto, reduce drásticamente la amenaza si se ve comprometida. Puede reenviar el puerto 22 desde su red doméstica interna a la DMZ e iniciar sesión con mayores privilegios para fines de administración / scp.
- Utilice el reenvío NAT / puerto para reenviar un puerto TCP alto aleatorio (por ejemplo, 55134) desde su IP pública a su servicio SSH; esto hará que el servicio sea menos fácil de detectar
- Restrinja el acceso en el firewall para que el puerto reenviado solo sea visible para su servidor remoto en la nube
- No coloque datos confidenciales, claves privadas SSH, contraseñas, etc., etc. en su computadora de respaldo. De esta manera, si se ve comprometido, reducirá aún más a qué tiene acceso un atacante.
- Mantenga todos los sistemas / servicios actualizados, especialmente en el servidor de la nube y la PC de respaldo. Siempre se están descubriendo vulnerabilidades y los atacantes a menudo pueden explotarlas fácilmente, por ejemplo, para convertir el acceso básico en acceso a nivel raíz. (por ejemplo, https://dirtycow.ninja/ )
Esta lista es el escenario ideal y debería ayudarlo a pensar en los riesgos. Si el enrutador de su ISP no tiene una función DMZ y no desea invertir en la configuración de un firewall alternativo, entonces podría estar contento con un compromiso (personalmente no estaría contento con él), en ese caso yo garantizaría que los firewalls basados en host estén activos en todas las PC de su red interna, y las contraseñas seguras, requieren autenticación para todos los recursos compartidos / servicios, etc.
Una alternativa, como lo sugirió otro usuario (aquí hay un poco más de detalle), sería hacer un script en su servidor de la nube para producir las copias de seguridad y ponerlas a disposición, y escribir su PC de respaldo para conectarse a través de SFTP o SCP (SSH) para extraer las copias de seguridad .
Esto podría funcionar bien, pero bloquee el puerto SSH / SFTP para que solo su PC de respaldo pueda acceder a él, use una cuenta de acceso limitado y piense en algunas de las mismas precauciones. Por ejemplo, ¿qué pasa si su PC de respaldo está comprometida? Entonces su servidor en la nube también se ve comprometido, etc.