How to Set Up a Cloudflare-Backed DigitalOcean Subdomain for Sensitive Litigation (DNS, Droplet Hardening, Access Controls, and Logging)

By [Name], [Role]

High-profile matters attract attention, and the easiest failures are rarely “zero-days” — they’re misconfigured DNS, exposed origin IPs, and weak administrative access paths. For litigation work, those mistakes can create confidentiality and privilege problems, break your audit trail, or cause downtime during filing deadlines. This practical checklist walks you through building a dedicated subdomain (for example, case-portal.firm.com) that terminates at Cloudflare and routes to a hardened DigitalOcean droplet as the origin. It’s designed for law firms hosting client portals, internal case-team tools, sealed-case workspaces, or evidence review environments. For broader subdomain strategy, see Subdomains for Law Firms: Building Client Portals, AI Tools, and Internal Systems.

Quick architecture (text)

User → Cloudflare (DNS/proxy/WAF/Access) → DigitalOcean droplet (origin)

What this guide assumes

• You control the domain in Cloudflare and have a DigitalOcean account.
• You can run basic SSH/terminal commands.
• Scope: infrastructure and security posture, not application code.

Decide what you're protecting (and choose the right Cloudflare mode)

Before you touch DNS, write down the asset and the threat model. A client portal for productions has different failure modes than an internal-only workspace or an evidence staging/review environment. In litigation, assume adversarial attention: credential stuffing against logins, DDoS or traffic floods near deadlines, OSINT-based origin discovery (finding your droplet IP and bypassing Cloudflare), plus phishing and insider risk. If you want a quick refresher on attack types that commonly target firms, see types of cyberattacks to watch out for.

• DNS-only (gray cloud): exposes the origin IP and skips Cloudflare WAF/ratelimiting. Use only when you must (some non-HTTP services). Compensate with strict origin firewalling, IP allowlists/VPN, and service-specific hardening.
• Proxied (orange cloud): preferred for web apps. You get Cloudflare edge protections and can hide the origin behind the proxy.

Finally, choose an access pattern: a public app with a separately locked-down /admin, or (recommended for sensitive matters) a private app behind Cloudflare Access so users authenticate before any request hits your server.

Example (TRO week): sudden interest drives spikes and opportunistic scanning. A proxied record plus WAF and rate limiting can be the difference between staying online and missing a filing window.

Create the subdomain in Cloudflare without exposing your origin

Step 1 (DNS): In Cloudflare DNS, create an A record for your subdomain (for example, case-portal) pointing to the droplet’s public IPv4. If you are using IPv6, add an AAAA record only if the droplet is actually configured and firewalled for IPv6; otherwise, omit/disable AAAA so you don’t accidentally create an alternate path attackers can probe. Set Proxy status to Proxied (orange cloud) and leave TTL on Auto.

Step 2 (SSL/TLS): Set your target end-state to Full (strict), which requires a valid origin certificate (public CA or Cloudflare Origin CA) and hostname match. Configure a modern minimum TLS version and turn on Always Use HTTPS to redirect HTTP to HTTPS at the edge. Enable HSTS only after you are sure HTTPS will stay enabled; Cloudflare warns that removing HTTPS (or unproxying/pausing Cloudflare) while HSTS is active can make the site inaccessible for the HSTS max-age window.

Step 3 (baseline edge protections): enable managed WAF rules (OWASP baseline), add rate limiting for login/admin paths, and turn on bot protections (Bot Fight Mode / Super Bot Fight Mode where available).

• Verification: DNS resolves; responses include Cloudflare headers; the origin IP is not obvious in page source/headers.

Example: when journalists or third parties circulate a link, edge caching plus rate limiting helps prevent a surprise traffic burst from turning into downtime during critical filings.

Provision the DigitalOcean droplet for least privilege from day one

Step 1 (image + sizing): choose a mainstream Linux distro with predictable security patching (for most teams: Ubuntu LTS or Debian). Start with a small droplet that meets baseline CPU/RAM needs and plan to scale vertically only after you measure load; overprovisioning often leads to “set and forget” servers that don’t get the same disciplined attention.

Step 2 (SSH keys, no passwords): add SSH keys at droplet creation and make “no password logins” the plan from day one. Avoid shared root credentials. Use unique keys per admin (and remove keys immediately when someone leaves the matter/team).

Step 3 (DigitalOcean Firewall): apply a DO Firewall to the droplet before you deploy anything.

• Inbound HTTP/HTTPS: allow 80/443 from the internet for public apps, or restrict to Cloudflare/Access-only patterns if applicable.
• Inbound SSH: allow only from office IPs/VPN (or disable direct SSH and require a bastion/jump host).
• Outbound: keep broad access only if you must; otherwise restrict to updates and logging/backup endpoints.

Step 4 (non-root admin): create a named admin user per person, add to sudo, and use separate accounts for accountability.

• Verification: you can SSH with a key; the firewall is enforced and only required ports are open.

Example: when a contractor rolls off after a filing sprint, individual SSH keys + separate accounts make offboarding a 5-minute task instead of a risky “rotate everything and hope” event. If you’re hosting workflow automation on a droplet, see Setting up n8n for your law firm for deployment context.

Put TLS in the right place (Cloudflare edge + origin) and eliminate downgrade paths

You want encryption on both hops: browser→Cloudflare and Cloudflare→your droplet. For the origin certificate, you generally have two choices: Cloudflare Origin CA (recommended with Full (strict); trusted by Cloudflare, not by browsers) or Let’s Encrypt on the droplet (publicly trusted, but adds renewal automation and more moving parts).

Enable Full (strict) (checklist):

• Generate an origin certificate for your hostname (e.g., case-portal.firm.com) and install it on the droplet.
• Configure Nginx/Apache to present that cert on port 443 and to serve the correct server_name.
• In Cloudflare, switch SSL/TLS mode to Full (strict) and confirm there are no edge errors (common causes: wrong hostname, expired cert, incomplete chain, wrong port).

At the web server/app layer, set cookie flags so sessions don’t leak: Secure (HTTPS only), HttpOnly (not readable by JavaScript), and a sensible SameSite value (often Lax by default; None requires Secure). Add a starter Content-Security-Policy that’s non-breaking (begin with reporting or a conservative default-src 'self' and iterate).

Example: in an evidence review workspace, strict TLS to the origin plus Secure/HttpOnly cookies reduces the chance that a captured session token becomes a usable log-in.

Harden the droplet OS and services (copy/paste checklist)

• Patch management: run updates immediately after provisioning (apt update && apt -y upgrade), enable unattended-upgrades, and decide who owns reboots (e.g., weekly maintenance window + “reboot-required” alerting).
• SSH hardening: set PermitRootLogin no, PasswordAuthentication no, and limit AllowUsers to named accounts. Changing the SSH port can reduce noise, but treat it as minor friction — not a control.
• Host firewall (defense in depth): mirror your DigitalOcean Firewall with UFW (e.g., allow 80/443, allow SSH only from trusted IPs, deny everything else).
• Brute-force protections: install fail2ban for SSH; add jails for web auth endpoints where it fits your stack (or rely on Cloudflare rate limiting/WAF at the edge).
• Service minimization: uninstall unused packages, disable unused services, and confirm only intended ports are listening. Run the app as a non-root user and tighten file permissions on uploads, configs, and keys.
• Secrets handling: store credentials in a password manager or secret store; inject via environment variables or managed secrets. Never commit secrets to repos, and rotate them on staffing changes.
• Verification: an external scan shows only expected ports; SSH rejects passwords and accepts keys only.

Example: when credential stuffing hits law firm domains, key-only SSH plus edge rate limits/WAF reduces the chance a single guessed password becomes full server access. For threat context, see common cyberattacks targeting law firms.

Add strong access controls for high-profile matters (Cloudflare Access + least privilege)

For sensitive litigation tools, the safest default is to make the subdomain private by design: put Cloudflare Access in front of everything so users must authenticate (and satisfy policy) before any request reaches your droplet. Require MFA and, if your firm has it, integrate an SSO/IdP so access is tied to HR offboarding and centralized identity controls. Where feasible, add device posture checks (managed device, updated OS, disk encryption) to reduce risk from compromised personal machines.

Split Access policies by role and necessity, not convenience:

• Partners/case team: broad access, MFA, managed device requirement.
• Vendors/experts: narrow paths only (e.g., /review), time-bounded access, stricter re-auth.
• Clients: least privilege, strong session controls, no admin routes.

Even if the main app must be public, protect /admin (and similar endpoints) behind Access, and consider IP allowlisting for administrative paths as an additional layer.

Operational governance: require written access approval per matter, keep an offboarding checklist (revoke SSH keys, disable IdP users, rotate tokens), and maintain a monitored break-glass account for emergencies only.

Example: co-counsel needs weekend-only access for an emergency filing. Create an Access policy with an expiration date and capture the audit trail of who accessed what and when.

Logging, monitoring, and retention that stands up in discovery and incident response

In sensitive matters, logging is part security control and part defensible operations: you need enough telemetry to reconstruct events without drowning in noise.

Minimum viable logs:

• Cloudflare: Access authentication events, WAF events, and firewall/rate-limit actions (what was blocked/challenged and why).
• Origin (droplet): SSH auth logs, sudo/admin actions, web server access/error logs, and any application audit trail (logins, downloads, permission changes).

Centralize and protect: ship logs off the droplet (syslog/SIEM/object storage) so an attacker can’t erase local evidence. Set a written retention period aligned to the matter and your incident-response needs, and lock storage down with least-privilege bucket policies (ideally write-once/immutability where practical).

Monitoring + alerting: add uptime checks, TLS expiration monitoring, and CPU/disk alerts. Create high-signal alerts for repeated auth failures, unexpected new admin users/SSH keys, and configuration changes (firewall, web server, Access policy changes).

Backups: enable encrypted backups and test restores. Define RPO/RTO that match litigation deadlines (e.g., “can we restore within hours before a hearing?”).

Example: if you see a suspicious login the night before a hearing, Cloudflare Access/WAF logs plus SSH and web logs let you quickly determine whether it was a blocked probe, a compromised account, or real data access.

Ethical and compliance best practices for hosted litigation environments (practical, non-jurisdiction-specific)

This setup only helps if it maps to professional obligations in a way you can explain later. Operationalize three themes: confidentiality (reasonable safeguards, least privilege, encryption in transit/at rest), technology competence (patching, monitoring, documenting security decisions), and supervision (vendor and staff due diligence, access reviews, training).

Vendor management (Cloudflare/DigitalOcean): confirm account ownership (firm-controlled), turn on MFA, and define admin roles and billing contacts. Review the basics in your terms: who is responsible for what security controls, breach notice expectations, subcontractors, and data location requirements when relevant. Maintain a one-page “hosting dossier” per matter/system: subdomain, origin location, who has Access/SSH, logging destination, retention period, and backup/restore owner.

Client communications: set expectations in your engagement letter or portal terms (permitted use, MFA, how to report a suspected compromise). Be explicit about when clients should not email materials and should use the portal instead.

Data handling: segregate matters, avoid commingling, minimize stored data, and document a purge/archival plan at close.

• Next steps: proxy the subdomain; enable Full (strict); restrict origin + key-only SSH; put Cloudflare Access + MFA in front; centralize logs with written retention; test restores and run a short tabletop IR drill; document approvals/offboarding and rotate credentials on team changes.