Sonntag, 3. April 2011

Incident Response with Server- and Config-Management

Hi,
i m working on finding best-practices in webserver-security (for my servers).
as this is an in-dev-process, i would really appreciate some criticisms, hints, ...

sample-server:
grsecurity (hard) patched server with active least-priv-policy (RBAC)
apache with mod_rails (one user per webapp)
logs external on a server with splunk

brJ

11 Kommentare:

  1. Splitting the logs onto a separate Splunk host stands out in your sample-server list, since it keeps the audit trail off the machine that would be compromised first. The grsecurity hardening with an active least-privilege RBAC policy and the per-webapp users under mod_rails also read as two layers that would have to be checked separately during an incident. It would be interesting to see how you tie a single Apache user back to an entry in that external log. This is from the team behind Jev AI Tools.

    AntwortenLöschen
  2. Your post asks for criticism of an in-dev setup, and the gap I notice is that every item in the sample-server list is preventive, with nothing on what happens after a host is already compromised. grsecurity hard patching plus an active RBAC policy narrows the attack surface, but without a written escalation path and a defined order for capturing evidence, the first responder still improvises on the box itself. Even a rough runbook would make the configuration easier to judge. This comes from the team behind Bulin 47 AI.

    AntwortenLöschen
  3. The grsecurity hardening and the active least-privilege RBAC policy in the sample-server list defend against different threats, but the post never says who you expect to attack the box. Stating that adversary, and what a successful compromise would look like, would give readers a baseline for the criticism you are asking for. Commenting as the team behind BlessPage.

    AntwortenLöschen