¿Cuáles serían los pasos de alta prioridad para asegurar una aplicación pequeña (en la nube)?

No hay duda de que hay mucha información buena en este enlace para fortalecer un servidor Linux y en el niño se enlaza con eso. Y en este enlace a herramientas relevantes parece que todavía no existe una herramienta de seguridad popular que los escritores de wiki no estén entusiasmados con . Leerlo y entenderlo todo tomaría una cantidad de tiempo considerable dependiendo del nivel de conocimiento con el que está comenzando y luego más tiempo en la parte superior para instalar, evaluar y aprender a usar un subconjunto de las 15 o más herramientas e implementar seguridad mejorada. Sin embargo, el volumen y la naturaleza de los consejos me hacen pensar que los asesores pueden tener en cuenta la seguridad de sitios conocidos con múltiples inicios de sesión (y usuarios), personal de seguridad de TI dedicado y una reputación de presencia en la web y reputación corporativa. proteger.

¿Qué pasos de alta prioridad debo tomar en mucho menos tiempo del que tomaría investigar la seguridad en stackexchange y ubuntu.com (por ejemplo, 30 minutos o menos) para mejorar la seguridad de mi servidor ciertamente no conocido? Detalles sobre mi implementación y necesidades:

• una instancia (en la nube de linodo) que ejecuta la versión de escritorio de ubuntu 10.10 (Maverick) y no tiene intención de tener más de una instancia
• necesidades de disponibilidad: una interrupción de varias horas por mes es aceptable. Si y cuando hay un ataque de DOS, será un inconveniente descubrir cómo evitar que vuelva a suceder, pero probablemente no sea más que un inconveniente.
• necesidad de privacidad: sí, por favor
• un administrador, iniciando sesión actualmente como root con SSH
• cero usuarios, en el sentido tradicional. El administrador sería el único 'usuario' que inicia sesión para evolucionar el sistema y, cuando se active, el administrador será VNCing para ver los resultados una o dos veces por día
• SSH, aunque no hice nada en el servidor para forzar al cliente a hacer esto
• VNC. En el cliente siempre uso SSH para VNC, aunque no hice nada en el servidor para obligar al cliente a hacer esto
• La mayoría del sistema está en funcionamiento, pero ocasionalmente necesitaré apt-get install , remove o purge a medida que evolucione el sistema que estoy desarrollando
• Filezilla para evolucionar el sistema (por ejemplo, envíele una nueva versión de la aplicación). Siempre especifico el puerto 22, pero no hice nada en el servidor para requerir esto
• el servidor ejecuta exactamente una aplicación en Java (y un poco de scripts bash) desarrollada por una persona de confianza, aunque esa aplicación vinculará bibliotecas populares (por ejemplo, Joda de Java) o invocará utilidades populares (por ejemplo: gnome-terminal, pitido de Linux) utilidad 1 ). La aplicación utiliza una biblioteca de confianza para hablar en Internet y el número de puerto me es conocido.
• el administrador está usando una contraseña segura

[1] Sé que no es necesario instalar la utilidad de pitido de Linux en un servidor en la nube, pero a veces ejecuto esta aplicación en mi computadora de escritorio donde es bueno tener sonidos. Es más simple para mí tener solo una versión de la aplicación en lugar de una versión sonada y una versión silenciosa.