Services / Security and hardening
ProtectionWe design and operate infrastructure protection for your systems
We design, deploy and operate infrastructure protection. We start from your systems: what faces the internet, who has access, and where copies live. Then we set a filter at the entry, detection on servers, a regular scan of known gaps, and two independent copies. After go-live we stay on-call for alerts and regularly check restore.
The service
Infrastructure protection we deploy and operate
We deploy protection in your environment and stay with its operation. We agree who handles an alert, what the procedure is, and how we test restore.
What we do
We deploy a filter at the entry, detection on servers, a scan of gaps, a view of traffic, and backups. We stay on-call for alerts and regularly check that restore works.
What we work with
Wazuh collects alerts from servers. OpenVAS finds known gaps. Cloudflare protects the application from the internet side. Traffic analysis shows what happens on the network. Two independent copies keep data nearby and off-site.
Who it is for
For companies where infrastructure is part of the product: fintech, software houses, shops, cloud and on-prem environments. Where an outage, a leak or a lost copy has a business effect and often an audit requirement.
How it fits together
From systems to layers, copies and on-call
First we understand what is exposed and where copies live. On that basis we put together the filter, detection, scan and two independent copies. Wazuh, OpenVAS and Cloudflare are what we use for that work every day. Copies sit on separate accounts and on a separate network.
- The scan feeds the remediation queue and rules that catch an attempt to use a gap.
- A failed backup or a delete lock turned off goes to the same on-call as a host alert.
We deploy Wazuh and stay on-call for alerts from machines
We deploy Wazuh, set the rules and stay on-call for alerts. Logs from servers, containers and the firewall land in one console. Each alert has a priority and an agreed procedure.
Logs
We collect logs from servers, the firewall, VPN and Cloudflare. An attack on the application and an attack on the host show up in one place.
Detection
We detect a change to an important file, password guessing and an unusual permission.
Response
When needed, we block or isolate the machine. On-call has an agreed response time.
Trail
We record who saw the alert and what was done. That record also goes to audit.
We scan known gaps and run a remediation queue
We scan servers and services for known gaps on a standing rhythm. The result is a queue: who closes it, by when, and in which window. After the fix we scan again.
Scope
We scan production, staging, panels and databases. Separate rules for what faces the internet and for the internal network.
Rhythm
A standing scan, plus a scan after change. After closing the ticket we check that the gap is gone.
Order
We close gaps in the public application and where customer data lives first. A host with no internet traffic waits further down the queue.
With Wazuh
If a gap stays open, we add a Wazuh rule for it so on-call can see an attempt to use it.
We set a filter between the internet and your application
We put Cloudflare between the internet and the application. It filters malicious traffic, limits bots and hides the server address. Admin panels enter through a login, not through an open port.
Surface
Only what should be reachable from the internet stays public. Remote desktop and SSH are available through VPN or another agreed path, not publicly.
Filter
We match rules to the application. A limit on login attempts and API calls, so unnecessary traffic does not reach the server.
Flood
We cut attack traffic at the Cloudflare edge before it reaches your network. We have a procedure to switch DNS when the attacked address has to be left.
Panels
Access to Grafana, cloud panels and staging through one identity. The admin panel is not exposed on a public port.
We build a picture of ordinary traffic on the network
We check what ordinary traffic looks like on the network. Cloudflare shows traffic from the internet, Wazuh shows processes on the server. Between them remains traffic between machines and to addresses the application does not call. When something departs from the norm, on-call gets an alert with who connects, where, and how much.
Source
We take traffic samples. On alert we keep a short window so there is something to analyse.
Signal
We watch for network scanning, a connection to an unknown address and a large outbound transfer.
Alert
On-call sees who connects to whom and whether it is a known service.
Operation
We tune the traffic profile as part of on-call, so alerts concern real deviations.
We keep two independent copies and check that restore works
We keep two independent copies. One sits close by, so work can resume quickly. The other is off-site, on separate accounts and keys, so it cannot be deleted together with production. We regularly check that restore actually works.
Copy A
In the same location
The copy sits in the same location or region. Work resumes from it in a short time. We practise restoring a single system and the whole application.
Copy B
Off-site
The second copy sits with another provider or on a second account. It has a different key and a different network, with a delete lock. It does not use the same accounts as production and copy A.
Scope
We copy databases, disks, configuration and files where that is part of the service. Passwords and keys live separately, outside the application backup.
Restore
We write per system how old a backup is still acceptable and how long a restore may take. The test report goes to you and to audit.
Alert
A failed job, shortened retention or a delete lock turned off is an alert in Wazuh.
Procedure
System order, DNS and secrets are in a procedure available offline. A backup index on the same network may be unavailable together with production.
How we work
From the client systems to on-call
We start from your systems. Then we deploy the layers and agree which alerts need a response. We stay for a review of alerts, scans and restore tests.
- Systems We check systems, public addresses, panels, backup accounts and who has the key. That gives the scope: layers, scan, on-call and a restore test.
- Deploy We tidy configuration, stand up Cloudflare, Wazuh agents and a first full copy in both locations.
- Tune We set rules and priorities. We link OpenVAS scans with Wazuh and traffic analysis.
- On-call We agree response time, procedures and a weekly report. We regularly test restore and leave a report for you and for audit.
Questions
Tools and who does what
How is Wazuh different from ordinary log collection?
Log collection stores events. Wazuh matches them against rules, watches files and assigns a priority. We deploy it, set the rules and stay on-call for alerts that need a response.
Does an OpenVAS scan replace a penetration test?
No. OpenVAS finds known gaps on a standing rhythm and gives a daily remediation queue. A penetration test is a separate, rarer exercise. It shows how several gaps can be composed into one scenario.
Do we already need Cloudflare, Wazuh and OpenVAS?
No. We can deploy this set or work with what already runs, if it gives the same outcome: detection, a scan, protection from the internet and recovery. The scope is layers, scan rhythm, on-call and a restore test.
What stays with our team?
Decisions on the change window, risk acceptance and the application owner stay with you. We hold the protection layers, on-call and restore. We write down the split of duties at the start.
Talk
We will discuss what faces the internet, how incidents are detected and how systems are restored
On that basis we will prepare a scope of work: layers, scan, on-call and a restore test.
Contact us