IPServerSec

Your server is running. That is not a statement about its security.

IPServerSec is a hardening and early-warning system I wrote myself for Linux servers. It was never a product I bought. It grew, year by year, out of real attacks on real servers, and it runs on every machine in my own server fleet before it runs on yours. This page describes exactly what it does.

A compromised server looks exactly like a healthy one

The site loads. Mail goes out. The database answers in 4 milliseconds. And in the background, a process that is not yours has been running for weeks.

14 days. That is how long an attacker stayed undetected, at the global median, across incidents in 2025. The number comes from Mandiant’s M-Trends 2026. Mandiant is Google’s forensics arm, and it analyzes its own engagements every year. That is the generous number, because it only counts the cases that surfaced at all. Nobody keeps statistics on the others. Those are still running.

A good attacker breaks nothing. He keeps your server alive, because a working server is worth more to him than a broken one.

Your server is rarely the target. It is the resource.

When people hear the word “breach”, they think of stolen data. That happens. The more common case is different: your server gets conscripted and put to work.

It serves malware to visitors to your website. A phishing page sits in a directory you never open. Spam goes out under your name, by the thousand. It joins attacks on other companies, as one of many, and at night it mines cryptocurrency, when nothing else is going on anyway.

Your bill for that arrives long before anyone says the word “attack”. Your server’s IP address lands on international blocklists, and suddenly your proposals stop reaching customers. Google flags your domain as harmful. Abuse reports pile up at your hosting provider, and it pulls the plug without discussing it with you. Then everything stops, and your customers call you, not your host.

What IPServerSec does

14 layers that work together. The initial assessment shows which of them belong on your server, and how tightly to set them.

Defense at the perimeter. Behavior-based detection continuously evaluates the logs and blocks automatically, fed by a worldwide network in which servers warn each other about new attackers. In front of your application sits a web application firewall built on the OWASP Core Rule Set, catching the known patterns of SQL injection, cross-site scripting, remote code execution, and path traversal including local file inclusion. Add to that traps on paths no legitimate visitor ever requests, network-wide blocks for repeat offenders, and country blocks that clear out the background noise from cheap data centers. Enforcement happens on 2 levels: in the web server and in the operating system’s packet filter.

Detection on the inside. Every 12 hours your server checks the monitored system paths using cryptographic checksums, with the reference database held off the server so an attacker with full privileges cannot quietly alter it along with the files he changed. For web applications there is a second layer: comparison against the vendor’s official checksums and a search for obfuscated malicious code. Because the damage you are liable for happens on the way out, outbound traffic is watched too: unusual mail volume, connections to destinations the server has never talked to, load at hours when nobody is working.

Alerting and evidence. A structured report by email whenever a scan finds something, plus an SMS when there is an actual incident. Routine findings never trigger an SMS, the system does not report the same incident twice within 12 hours, and empty findings get discarded before they reach your inbox. An alarm that goes off 20 times for nothing gets ignored the 21st time. That is not a technical problem. That is a human one.

Foundation. Every domain runs under its own system account with minimal privileges, so a break-in at one point does not cost you the whole server. Below it runs a hardened operating system: automatic security updates from defined sources, kernel livepatching where technically possible, monitored certificate renewal, a complete set of security headers, enforced mail authentication, and backups on separate storage.

Why origin tells you almost nothing

People sell a lot of nonsense about country blocks, so here is the uncomfortable version.

What country blocks can do: they clear out the background noise. The overwhelming majority of what hits a server every day is blunt automated scanning from cheap data centers. Remove it and your logs become readable again, which means behavior-based detection works on a clean signal instead of being buried in noise.

As protection, they are worthless. A serious attacker’s traffic does not come from the country he operates from. He chains several VPN services. He rents a German server for 6 euros a month. On top of that comes access to networks made up of more than 10,000 genuine residential connections harvested through trojanized phone apps, plus hijacked routers in German living rooms and compromised security cameras. The attack then looks like the evening browsing of a father of two in Dortmund.

Real protection therefore does not ask where a request came from. It asks what the request is doing. Origin is a weak signal. Behavior is a strong one.

3 weeks, because 2 hours would be a lie

First, I touch nothing. I record the current state, completely and strictly read-only. System, services, open ports, certificates, databases, existing backups, security software already in place. You get a findings report telling you where you actually stand. This part hurts. It is supposed to.

The hardening follows. Detection, rule set, firewall, integrity monitoring, alerting, isolation, backups, operating system. Old, contradictory security tools do not get stacked on top of each other. They get replaced. 4 systems blocking one another protect you less than one system somebody stands behind.

Now the slow part starts. Roughly 2 weeks of pure tuning against your real traffic. False positives out, exceptions in, every rule tested against your application. 3 weeks instead of 2 hours, because a filter that locks out your customers is worse than no filter at all.

Sign-off closes it out. Every domain checked individually, every service verified, documented, and handed over, while the system stays in production. The standard is simple: the changeover is planned and signed off step by step so your production systems keep running. Any brief interruption is scheduled with you in advance.

A hardened server rots like any other

It gets new domains, new applications, new dependencies. Software ages. Rules that fit today will, 8 months from now, block a service nobody has installed yet.

If you want, I stay on it: reading the findings from each scan, applying the updates that must not run automatically because they touch your application, bringing new domains properly under protection, keeping an eye on disk space, load, and certificate lifetimes before any of it turns into a Sunday phone call. You get a quarterly report you sign off on. It documents the checks and measures carried out and serves as evidence for insurers, clients, and authorities. What weight it carries in a given case is for the relevant body to decide.

Without ongoing care, the installed components keep working. Their protective value simply degrades over time, as new applications and new attack patterns go unaddressed.

What I do not promise

There is no such thing as 100 percent security. Anyone who promises it is promising something no one can technically deliver.

Every server reachable from the internet carries residual risk. There are vulnerabilities nobody knows about yet, attackers with patience, money, and time, and the Monday morning when an employee clicks something he should not have.

So the question shifts. It is not whether your server is absolutely secure, because it cannot be. It is whether you did what was technically possible and reasonable. That is the standard everyone will measure you against when it counts: the insurer looking for gross negligence, the supervisory authority asking about appropriate measures, and, in a dispute, a court.

How it starts

It begins with an initial assessment in 6 stages: clarifying authorization, passive reconnaissance without touching anything, active external testing, internal review with read access, a search for traces of a compromise already in progress, and, where needed, a review of the surrounding environment: network, workstations, and line-of-business software. I confirm with you which stages you need before anything starts.

There is no price on this page, and there is a practical reason for that. Take a medical practice: the server at one provider, mail at a second, the website at a third, and a network that has grown over 15 years. That is 1 week of work, 2 days of it on site. A cleanly built dedicated server with 3 domains is documented in a day. Offering both at the same price would be either dishonest or a loss.

The second reason is less comfortable. If you wait until something is burning, you will be competing with everyone else who is calling at the same time, and you pay the price of haste. Come earlier and you pay the price of the work.

You get in touch and briefly describe what you run. After that you get a fixed-price quote for the assessment. Accept it and we start. Decline it and it was just a conversation. Nobody lost anything. The conversation costs nothing. The assessment itself is paid work, and I do not invoice anything you have not commissioned in writing.

Your server is running. You know that. Find out who else knows.

Nothing on this page is a binding offer within the meaning of section 145 BGB and not an offer within the meaning of section 145 BGB. Which protective layers are set up, which assessment stages are run, and how much work is involved all follow from the written quote after the initial assessment. The legal statements are general information and not legal advice.