Server security
Most attacks never reach your site.
We put the layers in front of your server, keep them up to date, and have a person look when something gets close - on our servers or on yours.
Get a quoteA quiet night, on the record
Every server is attacked every day. What matters is that each attempt is stopped, written down, and seen by someone when it needs to be.
Six layers, outside in
An attacker has to get through every one of them. Each is set up for your server, not copied from a default.
Firewall
Only the ports your services need are open; everything else is closed at the edge.
Automatic bans
Repeated failed logins and scanning ban the address on its own, before it gets lucky.
Web application firewall
Requests carrying injection, file probing and known exploits are dropped before your code sees them.
Hardened access
Key-only SSH, no root logins, separate users per site and strong TLS settings.
Patching
Security updates applied on a schedule, and urgent ones the day they are published.
Backups that are tested
Copies kept off the server and restored on a test machine, so the last line of defence actually works.
How the layers surround your data
The same defences, drawn as rings around what you are protecting. If one ring is passed the next is still there, and someone is watching the whole picture.
Network
Only the ports your services need are open; everything else is closed at the edge.
Firewall and WAF
Repeated failed logins ban the address on their own, and requests carrying injection or file probing are dropped before your code sees them.
Host hardening
Key-only SSH, no root logins, separate users per site, strong TLS settings and security updates on a schedule.
Application
Your site or application runs under its own user, behind the filtering of the rings around it.
Data and backups
Copies kept off the server and restored on a test machine, so the last line of defence actually works.
Monitoring
A person watches the whole picture. Routine blocks stay in the log, and you are told when something needs a decision.
Which control answers which threat
Every server on the internet meets the same six threats. Each row says how the threat shows up, what answers it and which rings it belongs to.
| Threat | How it shows up | What answers it | Rings |
|---|---|---|---|
| Brute force | Thousands of password guesses against SSH or a login page. | The address is banned automatically after repeated failed logins, key-only SSH leaves a password guess nothing to hit, and each ban is written to the log. |
|
| Injection | SQL or command fragments sent in a form, a URL or a header. | The web application firewall drops known injection patterns before your code sees them. It is a shield, not a cure: the lasting fix is in the application code. |
|
| Malware | A vulnerable plugin or an outdated service lets an attacker plant code on the server. | Patching closes the known hole, separate users per site keep one infected site away from the others, and a tested backup is a clean copy to return to. If it has already happened, we find the way in and clean up. |
|
| DDoS | A flood of traffic meant to make the service unreachable. | Closed ports leave less to flood. A flood bigger than the link into the server can only be absorbed upstream, at the network edge of the provider. |
|
| Misconfiguration | A forgotten open port, a default password or an old service still running. | The audit comes first: a written list of what is open, old or weak before anything changes. After it, only the ports your services need stay open. |
|
| Credential theft | A leaked, reused or phished password is used to log in as you. | Key-only SSH and no root logins mean a stolen password alone does not open the server, separate users per site limit what one stolen login can reach, and strong TLS settings protect logins on the way. |
|
The threat categories come from the OWASP Top 10:2025 and NIST SP 800-53, and the practices are the ones the CIS Critical Security Controls describe. OWASP · NIST · CIS
On the hosting we run, DDoS mitigation at the network edge is part of the infrastructure described in the SLA. Read the SLA
And a person behind it
An audit first
We look at the server as it is and give you a written list of what is open, old or weak, before changing anything.
Alerts that mean something
Routine blocks stay in the log. You are told only when something needs a decision.
Any server
Ours, a cloud provider's, or a machine in your office - Linux servers running your sites and applications.
A clean-up when it is too late
Already hacked? We find how they got in, remove what they left, close the door and bring the site back.
Tell us what you are protecting
How many servers, where they run, and what is on them. Every engagement starts with the audit and is quoted after it.
Get a quoteQuestions and answers
Where does a security engagement start?
With an audit. We look at the server as it is and give you a written list of what is open, old or weak before changing anything, and the work is quoted after it.
How quickly are security updates applied?
On a schedule, and urgent ones the day they are published.
Will I be told about every blocked attack?
No. Routine blocks stay in the log; you are told only when something needs a decision.
My site was hacked. Can you help?
Yes. We find how they got in, remove what they left, close the door and bring the site back.