Launching a new server, whether it is a VPS or a dedicated host, is an important step for any website, application, SaaS platform, ecommerce store, or business infrastructure. But a new server without proper security configuration is not “clean and safe” by default. In reality, fresh servers are often scanned by bots within minutes of going online.

Attackers look for weak SSH settings, outdated packages, exposed databases, poor firewall rules, insecure PHP configurations, and unprotected services. This risk becomes even higher when the server is used for public-facing workloads, high-traffic websites, game servers, APIs, or platforms hosted on a dedicated server Europe environment.

Security must start from day one. If you are running VPS hosting, you also need to think about VPS DDoS exposure, brute force attempts, malware injection, and traffic abuse. If you operate critical workloads, using DDoS protected dedicated servers or adding remote DDoS protection can help reduce downtime during large traffic attacks.

This guide outlines essential server security configurations you should apply immediately after provisioning a new server.

1. Keep Your System Up to Date

The first and most fundamental rule of server security is to keep your operating system, packages, and installed software updated. Many attacks succeed not because hackers are advanced, but because server owners leave old vulnerabilities unpatched for months.

On Debian or Ubuntu systems, run:

• apt update && apt upgrade -y
• apt install unattended-upgrades

Automatic updates help patch known vulnerabilities without waiting for manual intervention. This is especially important for public-facing servers because attackers constantly scan for outdated versions of OpenSSL, Apache, Nginx, PHP, MySQL, MariaDB, and Linux kernel packages.

If your server hosts business-critical applications, schedule maintenance windows and review update logs regularly. Blindly ignoring updates is a bad habit. But blindly updating without checking compatibility can also break production applications. The smart approach is to keep security patches automated while testing major version upgrades before deployment.

For hosting environments such as a VPS or dedicated server Europe setup, keeping the system updated also protects against automated botnets that target common Linux vulnerabilities. Updates alone will not stop every attack, but they remove the easiest entry points.

Deploy Secure Hosting in Minutes

DDoS Protected Servers

2. Secure SSH Access

SSH is the most common way to access servers remotely. By default, many servers allow password login and root access. That is risky because attackers can continuously attempt brute force logins against the root user.

Recommended SSH settings in:

• /etc/ssh/sshd_config

Use:

• PermitRootLogin no
• PasswordAuthentication no
• PubkeyAuthentication yes

After editing the configuration, restart SSH:

systemctl restart ssh

Benefits:

• Disabling root login reduces the risk of attackers targeting the highest-privilege account.
• Key-based authentication eliminates weak password attacks.
• SSH access becomes harder to compromise through automated brute force attempts.

You should also create a separate sudo user before disabling root login. Never lock yourself out by changing SSH settings without testing a second active session.

For stronger protection, consider changing the default SSH port, using allowlists for trusted IPs, and enabling two-factor authentication where possible. If your server is exposed to frequent attacks, combine SSH hardening with firewall rules and remote DDoS protection. SSH hardening protects authentication, while DDoS protection helps defend the network layer from traffic floods.

3. Configure a Firewall

A firewall is your first line of defense. It controls which traffic can enter your server and blocks anything unnecessary. Without a firewall, every exposed service becomes a potential attack surface.

Using UFW:

• ufw default deny incoming
• ufw default allow outgoing

# Allow essential services

• ufw allow 22/tcp   # SSH
• ufw allow 80/tcp   # HTTP
• ufw allow 443/tcp  # HTTPS

ufw enable

This configuration:

• Blocks all inbound connections by default.
• Allows only essential services such as SSH, HTTP, and HTTPS.
• Reduces exposure from unused ports and forgotten services.

Be careful with port 22. If you changed your SSH port, allow the new port before enabling the firewall. Otherwise, you can lock yourself out.

For production servers, firewall rules should be more specific. For example, database ports should not be open publicly. Admin panels should be IP restricted. Internal services should only communicate over private networks where possible.

If your business depends on uptime, firewall configuration should work together with VPS DDoS mitigation or DDoS protected dedicated servers. A firewall can block unwanted ports, but it cannot absorb massive traffic floods on its own. That is where network-level DDoS protection becomes important.

4. Protect Against Brute Force Attacks

Brute force attacks happen when bots repeatedly try usernames and passwords until they find a working combination. SSH, FTP, admin panels, web login pages, and mail servers are common targets.

Install Fail2Ban:

• apt install fail2ban -y

Fail2Ban monitors logs and blocks IP addresses that repeatedly fail login attempts. It can protect SSH, web login pages, FTP, mail services, and more.

A basic Fail2Ban setup is useful, but you should not treat it as complete protection. Attackers often rotate IP addresses, use botnets, and distribute login attempts across multiple locations. That means you should combine Fail2Ban with key-based SSH access, strong passwords, IP restrictions, and firewall rules.

For high-risk infrastructure, brute force protection should also include application-level rate limiting. If you run WordPress, ecommerce, SaaS dashboards, or client portals, add rate limits to login endpoints and block suspicious user agents.

If your server receives abnormal request spikes or malicious bot traffic, remote DDoS protection can help filter attack traffic before it reaches your origin server. This is especially useful when your backend server must remain hidden and stable.

5. Lock Down Your Database

Databases like MySQL and MariaDB are high-value targets because they store customer records, login credentials, orders, invoices, financial data, and application content. A poorly configured database can turn a simple server issue into a serious data breach.

Install MariaDB:

• apt install mariadb-server

Then run secure installation:

• mysql_secure_installation

After installation, ensure:

• The database only binds to localhost.
• There are no anonymous accounts.
• Remote root access is disabled.
• Strong passwords are used.
• Unused test databases are removed.
• Application users have only the permissions they actually need.

Your database should not be publicly exposed unless there is a very specific reason. In most cases, web applications and databases should communicate internally on the same server or through a private network.

Also, do not use the root database user inside your application configuration. Create a dedicated database user with limited privileges. If the application is compromised, limited permissions can reduce damage.

For businesses using dedicated server Europe infrastructure for compliance, latency, or customer data hosting, database hardening is non-negotiable. Security is not just about blocking attackers. It is also about reducing the impact if one layer fails.

6. Harden Your Web Server

If your server runs Apache or Nginx, you should reduce unnecessary information exposure. Attackers often scan headers and error pages to identify software versions and known vulnerabilities.

Apache hardening:

ServerTokens Prod

ServerSignature Off

These settings:

• Hide server version information from visitors.
• Reduce visibility into your stack for automated scanners.
• Make it harder for attackers to quickly match your server to known exploits.

For Nginx, disable version exposure:

• server_tokens off;

You should also remove default pages, disable unused modules, configure secure headers, and use HTTPS with strong TLS settings.

Important headers include:

• X-Frame-Options
• X-Content-Type-Options
• Content-Security-Policy
• Strict-Transport-Security
• Referrer-Policy

Web server hardening will not make your server invincible, but it closes common gaps that attackers rely on. It also improves trust for users and search engines because a secure website is less likely to be flagged for malware, phishing, or unsafe behavior.

For websites hosted on DDoS protected dedicated servers, web server hardening should still be applied. DDoS protection handles traffic attacks, but it does not fix weak headers, exposed versions, or insecure application behavior.

7. Configure PHP Safely

If your server uses PHP, poor configuration can expose sensitive information or allow dangerous functions to execute. PHP is widely used, especially for WordPress, Magento, Laravel, OpenCart, and custom web applications. That also makes it a frequent target.

Recommended PHP settings:

• expose_php = Off
• display_errors = Off
• disable_functions = exec,passthru,shell_exec,system

These settings help prevent PHP from revealing system information or executing unsafe routines.

You should also configure:

• upload_max_filesize
• post_max_size
• memory_limit
• max_execution_time

Do not allow unlimited uploads or execution time. Attackers often abuse file upload features to upload shells, oversized files, or malicious scripts.

For production websites, errors should be logged privately, not displayed publicly. Public errors can reveal file paths, database names, plugin information, and framework details.

If your application receives unpredictable traffic, especially on a VPS, consider VPS DDoS protection and request filtering. PHP applications can become resource-heavy under attack because repeated requests can consume CPU, RAM, and database connections quickly.

8. Secure File Permissions

Proper file permissions prevent web applications from overwriting system files, exposing sensitive data, or escalating privileges. Bad permissions are one of the most common server security mistakes.

Example:

• chown -R www-data:www-data /var/www
• find /var/www -type d -exec chmod 755 {} \;
• find /var/www -type f -exec chmod 644 {} \;

Directories should generally use 755 permissions, and files should use 644 permissions. Avoid 777 permissions unless you fully understand the risk. In most cases, 777 is lazy configuration and creates unnecessary exposure.

Sensitive files such as environment files, database configuration files, SSH keys, backups, and private certificates should not be publicly readable.

For example:

• chmod 600 .env
• chmod 600 private.key

Also, separate application users where possible. Do not run everything under root. The web server should only have access to the files and directories it actually needs.

If your server hosts multiple websites, isolate each site properly. A compromise on one website should not automatically expose every other hosted project.

9. Set Up Monitoring and Alerts

Security is not only about prevention. It is also about visibility. If you do not monitor your server, you will not know when CPU usage spikes, disk space runs out, processes behave strangely, or attackers start probing your services.

Install basic utilities:

apt install htop iotop

They help you monitor:

• CPU usage
• RAM consumption
• Disk I/O
• Running processes
• Resource-heavy services
• Abnormal server behavior

You should also monitor logs:

• /var/log/auth.log
• /var/log/syslog
• /var/log/nginx/access.log
• /var/log/nginx/error.log
• /var/log/apache2/access.log
• /var/log/apache2/error.log

For production environments, basic tools are not enough. Set up alerts for downtime, high CPU usage, high memory usage, low disk space, failed login attempts, traffic spikes, and service failures.

Monitoring is especially important if you use remote DDoS protection or host on DDoS protected dedicated servers. During an attack, you need to understand whether the issue is network traffic, application overload, database saturation, or disk I/O pressure. Without monitoring, you are guessing.

10. Always Have Backups

No security strategy is complete without reliable backups. Even if you follow every best practice, things can still go wrong. Servers can fail. Applications can break. Files can be deleted. Databases can become corrupted. Attackers can compromise websites.

A proper backup plan includes:

• Daily database dumps
• Periodic file system backups
• Remote storage
• Off-site backup copies
• Backup retention rules
• Regular restore testing

The last point is critical. A backup you have never tested is not a backup. It is just a hope.

Store backups away from the main server. If attackers gain access to your server and your backups are stored on the same machine, they can delete or encrypt them. Remote backups give you a recovery path after compromise, hardware failure, or accidental deletion.

For business-critical websites hosted on a dedicated server Europe environment, backups should be part of your operating procedure, not an afterthought. Combine backups with strong access controls, monitoring, firewall rules, and remote DDoS protection for a more complete security posture.

Deploy Secure Hosting in Minutes

DDoS Protected Servers

Build Security Before Attackers Find the Gaps

Server security is not a one-time setup. It is an ongoing process that starts with strong updates, SSH hardening, firewall rules, brute force protection, database security, safe PHP settings, proper permissions, monitoring, and reliable backups.

But basic hardening alone is not enough for public, high-traffic, or revenue-critical infrastructure. If your server faces heavy traffic, bot activity, or attack attempts, you also need network-level protection such as remote DDoS protection, VPS DDoS mitigation, or DDoS protected dedicated servers.

For businesses that need secure hosting infrastructure in Europe, NexonHost provides performance-focused dedicated server Europe solutions with DDoS protection options designed to keep workloads stable, protected, and online. A secure server starts with good configuration, but a resilient server needs the right hosting foundation behind it.

Frequently Asked Questions

1. Why is initial server configuration important after launching a VPS or dedicated server?

Initial server configuration is important because a fresh VPS or dedicated server is exposed to bots, scanners, brute force attacks, outdated package risks, and misconfigured services almost immediately. Basic steps like system updates, SSH hardening, firewall setup, database lockdown, monitoring, and backups reduce avoidable security gaps before attackers can exploit them.

2. How does a firewall improve server security?

A firewall improves server security by controlling which connections are allowed to reach your server. Instead of leaving every service exposed, you can block all incoming traffic by default and allow only required ports such as SSH, HTTP, and HTTPS. This reduces attack surfaces and limits access to unnecessary or sensitive services.

3. Why should root login and password authentication be disabled for SSH?

Root login and password authentication are risky because attackers commonly target the root account using automated brute force attempts. Disabling root login forces access through a separate user account, while key-based authentication removes weak password risks. Together, these settings make unauthorized SSH access much harder and improve overall server protection.

4. What is the role of DDoS protection in server security?

DDoS protection helps defend servers against traffic floods designed to overwhelm bandwidth, CPU, memory, or application resources. While firewalls and hardening protect system access, they cannot absorb large-scale attacks alone. Solutions like remote DDoS protection, VPS DDoS mitigation, and DDoS protected dedicated servers help maintain uptime during malicious traffic spikes.

5. How often should server backups be created?

Server backups should be created based on how often your data changes. For most business websites and applications, daily database backups and periodic file backups are a sensible baseline. Critical systems may need more frequent backups. The real test is restoration. If you never test backups, you cannot trust them during failure.

6. Why is database hardening necessary for server security?

Database hardening is necessary because databases often store sensitive business, customer, transaction, and application data. Exposed database ports, anonymous users, weak passwords, and excessive permissions can lead to serious breaches. Restricting database access to localhost, removing unused users, and creating limited application accounts significantly reduces the risk of data compromise.

7. Is VPS security different from dedicated server security?

The core security principles are similar for both VPS and dedicated servers, including updates, SSH hardening, firewall rules, monitoring, and backups. However, VPS environments may face shared infrastructure limitations, while dedicated servers offer greater control and isolation. For public workloads, both should include strong VPS DDoS or dedicated server DDoS protection.

8. Why choose NexonHost for secure server hosting in Europe?

NexonHost provides secure hosting infrastructure for businesses that need reliable VPS and dedicated server Europe solutions. With performance-focused servers, scalable hosting options, and DDoS protection support, NexonHost helps businesses reduce downtime risks and strengthen infrastructure stability. It is a practical choice for websites, applications, platforms, and high-traffic workloads needing European hosting.