Securing-a-server.md

+Assuming such points:  
+- Ssh must be reachable from the outside on all machines, as admins need to log as root  
+- All non-root users are assumed "public access", either for public missions or for open-source scripts  
+- All files restricted to root are assumed "critical data" by default  
+- Local libraries are considered unable to be secured against root elevation  
+- No server is added to an existing LAN until it is deemed secured, as such machine would provide an entrypoint into the LAN  
+
 Threats against a rented service server:  
 
-Threat 0 : Usability over security  
-0a) Ssh must be reachable from the outside on all machines, as admins need to log as root  
-Ergo : As all different services may be required in normal circumstances, most machines will have two or more services reachable from the outside  
-(In the future, there could be one ssh-only port forwarded machine on the LAN to act as an admin proxy, with other ssh services only available on the LAN)  
-0b) All non-root users are assumed "public access", either for missions or for open-source scripts  
-Ergo : close-sourced scripts should use root access  
-0c) All files restricted to root are assumed "critical data" by default  
-Ergo : open-sourced scripts should call a closed-source script, stored on the server, who then will use root privileges to access critical data  
+Threat 0 : Exploit requirements
+
+0a) "X active user" is assumed *always* fulfilled, as this requirement is expected to evolve under normal conditions  
+0b) "minimum N registered users" is assumed fulfilled except exceptional circumstances, as a server is meant to provide more and more services over its lifetime  
+0c) "in the same LAN" is assumed always blocking, as an inter-LAN exploit assumes another machine got breached first  
+0d) "specific X version" can be easily blocked forever, as patching local libraries is pointless  
 
 Threat 1 : Root access  
 1a) Any service can allow to log or lock root with the good vulnerability