Production server security guide for companies in Romania (2026)

All questions

• Why not leave node_modules and npm on a production server?
• How do I protect a WordPress site from attacks?
• What is a DDoS attack and how do I protect my server from it?
• How do I secure SSH access to a Linux server?
• How do I set up a VPS firewall and which ports should stay open?
• How do I back up a server and test restores (the 3-2-1 rule)?
• How do I install free HTTPS with Let's Encrypt and enable HSTS?
• What is a WAF (Web Application Firewall) and when do I need one?
• How do I keep .env files and API keys out of git in production?
• How do I secure Docker containers in production?
• How do I apply Linux security patches without downtime?
• How do I secure PostgreSQL or MySQL in production?
• How do I monitor a production server: logs and alerts?
• What should I do if my server has been compromised?
• How do I secure a mail server with SPF, DKIM and DMARC?
• Which HTTP security headers should I configure in nginx?
• How do I set up a WireGuard VPN for server admin access?
• How do I manage users and sudo with least privilege?
• What are my legal cybersecurity obligations in Romania?
• How do I secure a cPanel account on shared hosting?

How to secure a server, step by step

1. Lock down administrative access

   Move SSH to ed25519 keys, ban root and passwords, narrow the accounts with AllowUsers and add fail2ban. The provider's console stays the fallback path, never a password.

2. Shrink the exposed surface

   Use a default-deny firewall, with only ports 22, 80 and 443 towards the internet, plus HTTPS with Let's Encrypt and HSTS. Databases and internal panels listen on localhost or the private network, reached through a VPN.

3. Ship the application from CI, not from the server

   Build reproducibly from the lockfile, scan dependencies in the pipeline, use multi-stage Docker images with no npm or compilers at runtime, and keep secrets out of the code and the image.

4. Harden the application and the containers

   Keep updates current, put a WAF with OWASP rules in front of the application, and run containers as non-root with capabilities dropped and a read-only filesystem, checked against the CIS Docker Benchmark.

5. Back up what you have actually restored

   Follow 3-2-1 plus an immutable copy, encrypt at the source, store the key separately and run a monthly test restore on a clean machine, measuring RPO and RTO.

6. Monitor, and know what to do in an incident

   Collect logs centrally, alert on logins, traffic and certificate expiry, and keep a written response plan with named owners and the notification deadlines towards the DNSC and ANSPDCP.

Identity and access

Nearly every server compromise starts with legitimate access used the wrong way: a guessed password, a shared key, a forgotten account. Access control is the first layer.

• SSH with ed25519 keys only: PasswordAuthentication no and PermitRootLogin no in sshd_config
• One account per person, escalation through sudo, and the key removed on the day someone leaves
• Internal services reached through a WireGuard VPN, not through public ports

Network and exposure

Anything listening on a public interface will be found by scanners within minutes. The rule is simple: deny by default, allow explicitly and check with ss -tulpn what is actually listening.

• ufw default deny incoming; allow only 22 with rate limiting, plus 80 and 443
• Database on 127.0.0.1 or the private network; remote access through an SSH tunnel
• Docker ports published on 127.0.0.1, because -p without an address bypasses the firewall
• L3/L4 DDoS protection at the provider, since a local firewall cannot absorb volumetric traffic

Application and supply chain

Your code is a fraction of what runs on the server; the rest is dependencies, plugins and base images written by others. You control what gets in, and when.

• Security updates applied the day they are published, after a backup
• Build in CI from package-lock.json; the server receives artefacts only, with no npm and no devDependencies
• npm ci --omit=dev --ignore-scripts if you do install on the server, with install scripts allowed one by one
• Minimal Docker images pinned by digest and scanned with Trivy before the push

Data, backups and encryption

A backup counts as a security measure only after you have restored it on a clean machine. Ransomware hunts for the backup server first, so one copy must live outside your network.

• The 3-2-1-1-0 rule: three copies, two media, one offsite, one immutable, zero errors in the test
• Encryption at the source with restic or borg, with the key kept somewhere other than the copies
• Secrets kept out of code and images: .gitignore, CI variables, Docker secrets

Monitoring and incident response

You cannot respond to what you cannot see. Centralised logs and a few well-chosen alerts tell you about an incident before your customers do.

• Authentication, web server and application logs shipped to a central system outside the server
• Alerts on logins from unusual locations, a new key in authorized_keys, traffic spikes, failed backup jobs and certificates close to expiry
• A written response plan: who isolates the machine, who tells the provider, who talks to customers
• A monthly restore test, so the plan is rehearsed and not just written

Compliance in Romania: DNSC, NIS2 and GDPR

The measures above are not only good practice: for many Romanian companies they are legal obligations, checked by the DNSC and ANSPDCP.

• OUG 155/2024 transposes NIS2, has applied since 31 December 2024 and was approved by Law 124/2025; the competent authority is the DNSC
• DNSC Orders 1/2025 and 2/2025 set out entity registration and the risk-assessment methodology; digital infrastructure, including hosting, DNS and cloud, is listed in the annexes
• Significant incidents: early warning within 24 hours, notification within 72 hours, final report within one month
• Article 32 GDPR requires appropriate technical measures and the ability to restore data; Article 33 requires notifying ANSPDCP within 72 hours of a breach
• e-Factura: invoices sent to ANAF must be kept for the legal archiving period, so backing up the XML archive is a tax obligation

Common mistakes

• Believing that a changed SSH port, an SSL certificate or a local firewall means security, when each one covers a single layer.
• Having a backup that you have never restored and that sits in the same network as production.
• Installing dependencies straight on the server with npm install and letting install scripts run on production.
• Running containers as root, with --privileged or with the Docker socket mounted, and calling them isolated.
• Keeping no logs outside the server and learning about an incident from customers or from the payment provider.

How 4hosting helps

Related questions

• Where do I start if I have a single VPS and little time?

  In this order: SSH keys with no root and no passwords, a default-deny firewall, automatic security updates, an encrypted offsite backup with one test restore, and HTTPS with automatic renewal. It is a few hours of one-off work and covers most automated attacks.

• Does NIS2 apply to a small company?

  It depends on sector and size. OUG 155/2024 targets the essential and important entities listed in its annexes, including digital infrastructure and managed IT services, with size thresholds. An SME in an unlisted sector is not directly in scope, but its customers may be, and they can ask it for proof by contract. The size criteria and the disruption thresholds are in the annexes of OUG 155/2024 and in DNSC Order 2/2025.

• Who is responsible for security: the hosting provider or me?

  The provider is responsible for the physical infrastructure, the network and network-level DDoS protection, and on cPanel for the operating system as well. On VPS and dedicated servers, the operating system, the application, the data and the backups are yours. The hours included in your plan exist so that you are not left alone with your side of it.