Debian and Ubuntu Hardening Guide - Securing

The Debian and Ubuntu Server Hardening guide that I wrote a few years ago link on Secure Network website seems to be broken (http://www.securenetwork.it/ricerca/whitepaper/download/Debian-Ubuntu_hardening_guide.pdf)

Here is a copy of the document :
https://docs.google.com/open?id=0B-U_7aPIGgPdM1VxLXlmV1N2Vmc

I was asked by several persons if I made a new version of the Debian & Ubuntu Hardening Guide. Unfortunately I don't have enough time to update it, but I think that most of the points in the guide can be used with newer version of the distribution.

If I had to update it, I would add some chapters :

- A chapter on limiting bouncing through the infrastructure, confining and post reacting to an attack (one day or the other the system will be pwnd, so it is better to be prepared by taking in consideration this as a paradigm)
For example : do not reuse the same admin passwords, do not leave SSH keys which may allow an attacker to bounce on other servers, be carefull when centralized auth systems are activated not to have an omnipotent account valid on every server).
Prepare emergency procedure, forensics procedure, work on counterintelligence and threat mitigation (at the information level rather than on the infrastructure level).

  - Maybe something on centralizing and logging admin access (like Wallix admin bastion ; even if it may be a SPOF).

- a chapter on hardening iLO/DRAC /Intel AMT/etc.
This is not linked directly to the operating system, but still a very powerfull entry point.

- a special attention on strong auth (if possible)

- a chapter on forensics analysis of a compromise system and intrusion
detection/response (generate a maximum of logs, log correlation,
monitoring)

- adapt DISA Red Hat Checklist http://iase.disa.mil/stigs/os/unix/red_hat.html

- globally for the security approach I'd go more on a security by isolation than configuration/correctness (a bit like Joanna's Qubes) and a lot of logging.
At least from what I see in audits/pentests, configuration correctness is very difficult to maintain trough time (especially with non always qualified staff or legacy applications) and isolation is easier to maintain (network +VM).

- for big installation it is important to know that it is very difficult to maintain a high level of security on all the infrastructure. It is better to classify assets and really harden the most critical ones.

- and of course integrate all new security features that came out during those 2.5 years ^^

Errata :
P29
"password required pam_passwdqc.so min=disabled,12,8,6,5 max=40" is not correct and should be "password required pam_passwdqc.so min=disabled,24,14,12,12 max=40" at least to avoid weak password (as the keyspace generated by the two last parameters of min is too small)