Study Strengths

Linux siempre ha sido calificado como un sistema operativo confiable en seguridad. Sin embargo, poco a poco se ha empezado a utilizar Linux demasiado, lo cual hace que algunas personas intenten buscar la manera de hacer colapsar el sistema con fines desconocidos. Por esto al instalar un servidor Linux se deben tener en cuenta ciertas medidas para que el servidor

este seguro, pues muchas de las vulnerabilidades en los sistemas

no son debidas únicamente al sistema

operativo, sino a su parametrización, uso y ciertas actualizaciones. Existen algunas precauciones que pueden ser tomadas para optimizar en gran medida la seguridad de Linux. A continuación algunas de las más importantes y relevantes. (Tom Adelstein, 2007)

5.2.1.1. Medios de instalación:

Este componente puede afectar a la velocidad de instalación y recuperación de un equipo. También afectaran la seguridad. Existen varios métodos (Tom Adelstein, 2007):

 FTP – rápida, requiere una tarjeta de red, y un servidor de ftp preferiblemente conocido

 HTTP – también rápida, y algo más segura que hacer una llamada a un FTP público desconocido

 Samba – rápida, un buen método si se dispone de una máquina windows  NFS – no tan rápida, pero dado que NFS está implementado en la

mayoría de las redes UNIX existentes es casi mínima.

 Disco duro – generalmente la más penetrante, las ventanas confunden los nombres de directorio, la instalación desde una partición ext2 suele ser algo menos dolorosa.

5.2.1.2. Actualización de las herramientas del sistema, aplicaciones y kernel:

Una de las causas más comunes en cuanto a ataques hacia un sistema es la incapacidad de los administradores de mantener sus máquinas al día con el tema de actualizaciones. Mantener un diseño de actualización regular del kernel, las herramientas y las utilidades hará que el sistema no esté en riesgo a los atacantes que conocen vulnerabilidades que ya están a su disposición.(Daniel Bovet, 2000)

5.2.1.3. Utilización de shadow password:

Es realmente importante la utilización de esta herramienta en las contraseñas, ya que es una vulnerabilidad conocida del sistema operativo Unix y consiste en que el archivo de usuarios /etc/passwd tiene permisos de lectura para cualquier usuario y sólo de escritura para root. En este archivo hay un campo con el hash del password de cada usuario. Esta información puede ser utilizada por un atacante para descifrar una contraseña por medio de un. Para evitar esta vulnerabilidad se crearon las contraseñas sombra, que consiste en colocar el hash de la contraseña en un archivo /etc/shadow en el que sólo root tiene permisos de lectura. (Michael D. Bauer, 2005)

5.2.1.4. Políticas de acceso:

Es necesario tener políticas de acceso a usuarios. Sobre todo para los usuarios con acceso a los programas ejecutables de la aplicación o del SO. Las contraseñas deben tener un alto grado de complejidad, deben tener cierto lapso de vencimiento de no más de 45 días obligando a que el cambio se realice periódicamente. Cuando no solo es un servidor si no una graja de estos, se debe evitar poner contraseñas iguales la misma contraseña. Se deben crear usuarios con perfiles diferentes a ROOT para las tareas que no lo necesite, ya que en algunas organizaciones tienen como práctica utilizar el usuario ROOT para la ejecución de todas las tareas, esto hace que se pierda trazabilidad sobre la actividad de cada uno de los usuarios en el servidor. Se deben crear usuarios

individuales para cada una de las personas que desee entrar al servidor, no manejar usuarios genéricos a mes de que sea para consultas genéricas y que no revelen información confidencial. Para acceder a comandos con privilegios de ROOT se deben hacer por medio del SUDO. Estas políticas harán que se realice un mejor manejo y control de la infraestructura y en algún caso determinar el comportamiento y actividades de los todos usuarios creados en la máquina.(Hagen & Jones, 2006)

5.2.1.5. Utilizar SHH como método de conexión:

Como buena práctica, se debe restringir el acceso mediante el telnet y abrirlo por SSH por las siguientes razones: en el telnet las sesiones no quedan cifradas, lo que hace que toda la información que se utilice y se consulte quede expuesta en texto legible, desde usuarios, contraseñas e información consultada. También al tener abierto un puerto telnet se puede estar en riesgo ya que es de la primera forma que un atacante busca para poder acceder a los servidores. Mientras que SSH tiene un protocolo de comunicación comprimido e incógnito, logrando un nivel de seguridad más alto en cuanto a las conexiones hacia el server. (Michael D. Bauer, 2005)

5.2.1.6. Utilización de herramientas cortafuegos:

Básicamente son utilizados para controlar las instalaciones de servicios y que no puedan ser accesibles a todos los usuarios creados o para usuarios que entren sin los protocolos correctos. Por lo general se utilizan herramientas que permiten realizar filtros de paquetes según el protocolo y datos de conexión que se esté utilizando. (Michael D. Bauer, 2005)

5.2.1.7. Restricción de acceso a servicios externos:

Normalmente se cometen en las configuraciones de los servidores y uno de los más comunes es permitir el acceso a ejecuciones de servicios externos que por lo general no deben ser utilizados. La mayoría de estos servicios pueden llegar a tener un alto grado de inseguridad uno de estos es el mencionado anteriormente, el telnet. La forma de poder restringir este punto es editando el archivo

/etc/hosts. Desde allí podrá restringir el acceso a estos servicios. (Michael D. Bauer, 2005)

5.2.1.8. Restringir el uso de los comandos “r”

Normalmente las personas que ya tienen experiencia en el mundo Linux, realizan ejecuciones de comandos desde equipos remotas. Esta necesidad se satisfacía con los comandos "r", es decir: rlogin, rsh y rcp. Pero los comandos r utilizan autenticación básica de usuario y password, siendo esto una conexión en texto claro, es decir, estos comandos pueden ser inseguros y fácil de interceptar por canales de red desconocidos para el usuario ejecutor. La restricción de estos comandos se puede manejar desde los siguientes archivos de configuración (Hagen & Jones, 2006):

 /etc/hosts.equiv: en cuanto al sistema, es decir, la conexión en tre otros servidores.

 $HOME/.rhosts: en cuanto a los usuarios, desde este archivo se pueden controlar los accesos y las ejecuciones para de manera remota sin utilizar contraseña.

5.2.1.9. Control y revisión de permisos de propiedad de los archivos de configuración del sistema y los servicios.

 /etc/passwd

Si lugar a dudas es quizá uno de los archivos más importantes a nivel de seguridad de SO ya que tiene la estructura de los usuarios y todos los datos relevantes en cuanto a grupo, permisos, etc. Como se recomendó anteriormente es necesario que se utilicen las contraseñas shadow y así lograr que el archivo y la información que contiene no pueda ser vista por todos los usuarios y así lograr que funcionen los comandos básicos del sistema. El único usuario que puede tener permisos de escritura y ejecución es el usuario administrados ROOT. (Hagen & Jones, 2006)  /etc/shadow

El archivo de shadow tiene la información de usuarios y su respectiva contraseña y cada uno de los datos relevantes para la caducidad del user,

contraseña, etc. Por esto, es recomendable que este archivo sea protegido de todos los usuarios, el único usuario que podrá acceder ser el usuario administrador ROOT.(Michael D. Bauer, 2005)

 /etc/groups

Este archivo tiene toda la información que corresponde a los grupos creados a nivel de SO, a veces tiene información como la contraseña del grupo. Este archivo es necesario que tenga permisos de lectura para todos los usuarios para que el sistema funcione sin novedad. El formato en el que debe estar es el siguiente (Michael D. Bauer, 2005):

nombregrupo: contraseña_cifrada:miembro1,miembro2,miembro3  /etc/gshadow

Este archivo es muy parecido a archivo shadow de password. Allí se encuentra información de los grupos, contraseñas y en usuarios integrantes. Y es otro archivo que debe ser protegido si o si, sólo el usuario administrador ROOT podrá acceder a este. (Tom Adelstein, 2007)  /etc/login.defs

Este archivo permite delimitar algunos valores por defecto para diferentes programas como useradd y expiración de contraseñas. Por lo general varía levemente según versiones, pero normalmente tiene bastantes comentarios y generalmente a contener los valores por defecto poco son cambiados.(Michael D. Bauer, 2005)

 /etc/shells

El directorio de shells la mayoría de shells válidos para el SO en cuanto al logueo de los usuarios, si por algún motivo el shell de algún usuario no aparece en este directorio, no se podrá hacer login en el servidor.

 /etc/securetty

Este directorio tiene el listado de tty’s desde donde los usuarios root pueden hacer un login. Los tty’s del servidor en modo consola van de /dev/tty1 a /dev/tty6. Normalmente sólo se debe permitir conectar al

usuario ROOT desde /dev/tty1, y es recomendable deshabilitar la cuenta de root, pero para esto es necesario realizar la instalación del sudo para poder acceder a comandos a comandos privilegiados.(Hagen & Jones, 2006)

5.2.1.10. Realizar auditorías:

Es de bastante importancia estar pendiente de los que se haga en el servidor, para esto se recomienda hacer auditorías fortuitas a diferentes aspectos de los servidores, servicios y ejecuciones de usuarios. No son auditorias complejas, simplemente puede ser revisiones a los archivos de log del sistema y de los usuarios.

5.2.1.11. Conservar un chek de revisión de los archivos de sistema mediante aplicaciones de detección y prevención de intrusos: Es importante considerar el uso de programas que permitan la detección de intrusos o usuarios extraños con el fin de estar prevenido. Los archivos de sistema pueden entregar información muy relevante en cuanto a intentos de ingresos desde sitios desconocidos hacia su máquina. Una buena práctica que se usa generalmente es realizar el envió de mails desde el sistema en donde reporte las actividades diarias de la máquina y las peticiones de conexión que ha tenido a lo largo del día.

5.2.1.12. ACTUALIZACIONES EN LINUX 5.2.1.12.1. Actualización del kernel

Siempre se recomienda hacer la actualización del kernel de Linux. El fin de esta tarea es poder lograr acceder a nuevas funcionalidades que propone el sistema y así corregir cualquier tipo de fragilidad que se encuentre en versiones anteriores. Casi siempre el kernel no se actualiza por que se cree que se pueden presentar dificultades y riesgos más adelante, pero con un buen plan de trabajo esto no sucederá. Ahora veamos qué puede pasar si no actualizamos el Kernel. Estar con el kernel desactualizado puede ser de mayor riesgo ya que las aplicaciones que tengamos allí si van a ser actualizadas constantemente y pueden llegar a presentar

incompatibilidad en algún momento. En el momento de realizar la actualización de suma importancia saber qué tipo de maquina se está utilizando para estar seguro de la actualización que se debe realizar. Es recomendable hacerlo antes en un ambiente de pruebas o de test para estar más seguro de la actividad que se desarrollara en el ambiente productivo. (Daniel Bovet, 2000)

5.2.2. ESTRATEGIAS PARA EL USO DE MOTOR DE DB MYSQL Y SU