Bring one running server to an operable baseline: access, logs, secrets

The result you are buying

How the work fits together

The project is complete when the required parts pass their own acceptance checks, the optional parts you chose do too, the runbook is accepted and you sign off the finished baseline. You accept the result, not each internal step.

1. Harden one Linux server: key-only SSH, a firewall and automatic security updates Job Included

   One Debian or Ubuntu server gets key-only SSH, a deny-by-default firewall and automatic security updates, each checked from outside. It is not a penetration test or a certification.

   The one named server

   The access, firewall and update baseline comes first, so the later changes can be made safely.

2. Stop logs filling the disk: rotation and size limits on one server Job Included

   Container, journal and application logs on one Linux server get size limits and rotation, so the disk stops filling. A growth test shows the limits working, and nothing outside the logs is deleted.

   The one named server

   Log growth is bounded before supervision changes where output goes.

   After: Linux server baseline

3. Run one process as a systemd service that restarts itself and logs Job Included

   One long-running process starts at boot, restarts after a crash within limits you set, runs as its own user and writes logs you can read, with the unit file tested.

   Up to three processes

   Each listed process is supervised and logs to the journal.

   After: Log rotation for one server

4. Move one app's secrets out of its env file into your platform's secret store Job Included

   One app stops reading secrets from a plain env file and reads them from its platform's secret mechanism. It is tested starting from the new source, and you get a rotation checklist and keep every key.

   One app, up to ten secrets

   The app's secrets are read from protected files, and you rotate the real ones with the checklist.

   After: systemd service for a process

5. Repair automatic certificate renewal on a server you manage yourself Job Optional

   On a server you run, Let's Encrypt renewal is repaired so a dry run passes, the schedule is confirmed, the web server reloads the new certificate, and an expiry alert you own is tested.

   Up to three hostnames

   Used when certificate renewal on the server is found failing.

6. Keep one Linux server patched and reviewed, month after month Standing service Optional

   Each month one Linux server has its automatic updates checked, the rest applied in a window you approve after a snapshot, its services, disk, certificates and logins checked, and a short report.

   Offered afterwards if you want the baseline kept in place.

How an engagement works

The price covers one server and the agreed list of processes and secrets. Items found later are quoted separately and are never absorbed silently.

How it starts

1. You describe the server and what runs on it, with no logins, keys or data. If you want, you also run a few read-only commands that we name and send us the output after you have read it.

2. From that description we write the ordered plan, the list of processes and secrets in scope, a fixed price for that list, and the terms.

3. You agree the scope, the price and the terms in writing. No access to the server is arranged, and nothing starts, before then.

4. After agreement, a secure handoff and a read-only inventory route are agreed, created by you and revocable by you. We inventory the server, reading environment variable names only and never their values, and send back any process or secret that is not on the agreed list, priced before any work on it.

5. You take a provider snapshot, or confirm that a console route works, before the first change set. We work through the plan in the agreed order, sending each change set for your approval and the evidence for acceptance.

6. We hand over the runbook and the findings list.

What is included, and what is not

• The ordered plan, then the changes as reviewable change sets, with the check evidence for each
• The runbook: access, updates, services, logs, secrets and how to go back
• A findings list of what was seen but not changed, with the reason

How we know it’s done

Agreed with you before work starts. Each check produces evidence you keep.

1. Each required and each chosen optional part passes its own acceptance checks on the server.

   Evidence: The check evidence for every part, in the order it was applied.

2. After a reboot, every supervised process is running without anyone logging in and its working check passes.

   Evidence: Boot time, service status and the check results.

3. The effective SSH settings, the outside port check and the update dry run still pass after all parts are applied.

   Evidence: The verification sheet re-run at the end.

4. The runbook lets someone who did not do the work find the logs, restart a process, read the update status and locate where each secret is read, without asking us.

   Evidence: A walkthrough of the runbook by a person you name, and their notes on gaps.

5. You sign off on the finished baseline.

   Evidence: Your written acceptance.

When it fits, and when we stop

What could go wrong

Each change set records the files before and after, so a part can be reverted on its own. Because the order is agreed first, a failed later step does not require undoing earlier accepted ones. The snapshot taken before the first change set and the provider console are the route back if access breaks or a restart goes wrong.

Scroll the table sideways to read it all.

Each change set is reviewed separately from the work that produced it, and you accept every part. No human supervisor is included unless the proposal names one. At launch the work is largely automated, and we say so.

Questions

Related

Send an enquiry