How I Secure My Website and My Server IP

When I manage a website, I do not think about security as a single setting I can turn on and forget. I think about it as a layered process. My goal is to protect the site itself, reduce the chance that my server IP gets exposed, and make it much harder for an attacker to do anything useful even if they find one weak point.

Security matters to me because one mistake can lead to a lot of damage. A compromised website can mean broken trust, lost traffic, SEO problems, bad redirects, malware warnings, or even a full server takeover. If my origin IP is exposed, an attacker may try to bypass my CDN, target open ports directly, or scan for vulnerable services. That is why I focus on prevention first.

What I secure first

When I start hardening a website, I look at the highest-risk areas first. I want to reduce the easy wins for attackers before I worry about advanced tuning. In practice, that means keeping software updated, locking down logins, filtering traffic, and making sure my origin server is not more visible than it needs to be.

That table reflects the core areas I keep coming back to. If I stay disciplined in those five areas, I eliminate a large percentage of common attacks without making my setup overly complicated.

My basic hardening routine

I like to keep my routine simple enough that I will actually follow it. I do not rely on a single tool or plugin to save me. Instead, I use a checklist-based process and repeat it whenever I launch a new site or review an existing one.

That sequence covers the major things I do in the right order. I update first, then I protect access, then I reduce the exposed surface, and finally I make recovery possible with backups and monitoring.

How I secure the website itself

The first thing I do is make sure the site runs on HTTPS everywhere. I force redirects from HTTP to HTTPS so visitors never land on the insecure version by accident. I also watch for mixed content issues because a page that loads some assets over HTTP can leak trust and create browser warnings.

Next, I focus on the software stack. I keep the CMS core, themes, plugins, and server runtime updated. Outdated components are one of the easiest ways for an attacker to get in, especially if they are public and widely used. I remove anything I am not actively using. If a plugin or theme is installed just in case, that usually means it is a liability, not an asset.

I also protect the login area aggressively. Most websites attract brute-force attempts, credential stuffing, and bot traffic. To reduce that risk, I use strong passwords, unique credentials, and two-factor authentication whenever possible. I limit login attempts, and I review any alerts tied to authentication failures. If the site has an admin dashboard, I make sure only the right people can reach it.

File permissions matter too. I do not leave writable files and directories open any more than necessary. The fewer places an attacker can modify, the better. I treat permissions as part of my security model, not just a technical detail.

How I reduce server IP exposure

Protecting the website is only half of the job. I also need to think about the server IP itself. The origin IP is the real address of my host, and if that leaks, an attacker may skip the CDN or reverse proxy and attack the source directly.

One of the best things I can do is place the website behind a CDN or reverse proxy. That gives me a filtering layer in front of the server and helps hide the origin from casual discovery. It can also improve performance and reduce the impact of DDoS attacks.

But I never assume the CDN alone is enough. I also restrict direct access at the server level. If possible, I make sure only trusted IP ranges can reach the web ports. I close anything that does not need to be public, and I make SSH as private as I can. If I can use a VPN or a trusted admin IP instead of exposing SSH broadly, I prefer that.

I also disable unused services. Every running service is another possible attack surface. If I do not need a mail daemon, database port, admin panel, or monitoring endpoint exposed publicly, I keep it private.

A simple firewall setup

A firewall is one of the most practical protections I use because it gives me control close to the machine. Even if something is misconfigured elsewhere, the firewall still helps reduce exposure.

# Example: allow only SSH and web traffic
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

That example is intentionally simple, but the idea behind it is important: start from deny-by-default, then allow only what the site actually needs. I want the server to accept traffic only on the ports I expect, and I want everything else blocked unless I have a specific reason to allow it.

How I think about leaks

Even when I hide the origin IP, I still assume it can leak somewhere. That is why I regularly review DNS records, old subdomains, email routing, configuration files, and source code references. It is very easy to leave an old A record or forgotten subdomain pointing straight to the origin server.

I also check third-party tools. Sometimes analytics, uptime services, or external scanners can reveal details I did not mean to expose. If I use outside services, I make sure they do not accidentally publish my server address.

Another thing I pay attention to is staging environments. A staging site can become a back door into production if it is not protected properly. I do not expose staging unless I have a good reason, and when I do expose it, I add authentication or IP restrictions.

What I monitor regularly

I do not wait for a breach before I look at the logs. I review signs of trouble often, especially when a site starts getting more traffic or installing new features.

The main things I watch are:

• repeated login failures
• suspicious admin creation events
• unexpected file changes
• strange outbound connections
• traffic spikes from unusual sources
• new DNS records or changes I did not authorize

If I catch odd behavior early, I usually save myself a lot of recovery work.

My backup and recovery approach

Backups are a core part of security for me. I do not think of backups as separate from protection. They are what let me recover if something goes wrong anyway.

I back up:

• website files
• the database
• configuration files
• any custom scripts or deployment assets

I store backups somewhere separate from the live server. If the server is compromised, I do not want my only backup sitting in the same place. I also test restores occasionally, because a backup that cannot be restored is not a backup I can trust.

My practical rule for staying safe

The rule I follow is simple: if something does not need to be public, I do not make it public.

That applies to ports, services, dashboards, databases, subdomains, and even temporary tools I install during development. I try to reduce exposure everywhere I can, because every unnecessary opening is another path an attacker can try.

Security is never perfect, but I have found that a consistent layered approach works very well. If I keep my software updated, protect logins, hide the origin IP, lock down ports, and maintain backups, I dramatically improve my chances of staying safe.

That is the system I rely on for both my website and my server IP: fewer exposed services, stronger access control, better monitoring, and a fast recovery plan if something ever gets through.