Printer Friendly

Hardening the Linux.

En el articulo anterior se explico de manera general lo que se debe hacer en el endurecimiento (hardening) de un sistema operativo. Ahora, a manera de ejemplificar, se abordara el endurecimiento de un equipo Linux.

Antes de comenzar cabe senalar que el tema es por demas amplio, ya que el endurecimiento se ve a distintos niveles, por lo que no se profundizara tecnicamente y se pasaran por alto algunos temas.

Si el lector desea conocer mas sobre este tema, esta cordialmente invitado a visitar las ligas incluidas al final del presente articulo. En entregas posteriores se veran aspectos concretos y desde la perspectiva tecnica.

El proceso comienza por tener en claro "para que" va a usarse el servidor (Web, archivos, impresion, correo, etcetera). No menos importante es el "diseno" o como estara particionado el servidor (para manejo de cuotas o sistemas de archivo cifrados, etcetera).

El siguiente paso seria realizar la instalacion personalizada (no elegir las opciones por defecto), esto con la finalidad de que se instale solo aquello que realmente se necesitara, quitando los servicios innecesarios; por ejemplo, para una instalacion de servidor no se instalarian herramientas de edicion, juegos, incluso la interfaz grafica no seria recomendable; servicios como el FTP no deberian instalarse dada la inseguridad que implica (transfiere las credenciales en texto claro).

En un servidor de produccion no deberian tenerse soluciones de desarrollo como compiladores, ya que se estarian dando los instrumentos necesarios para que un posible atacante pudiera compilar sus herramientas y afectar.

Una vez que se ha realizado la instalacion es necesario actualizar el sistema base, ya que debe tenerse en claro que cuando se instale el servidor muy probablemente ya ha pasado tiempo desde que la version de la distribucion de Linux que ha sido instalada fue liberada.

Es necesario mencionar que las nuevas versiones de un programa no siempre significan problemas de seguridad, en ocasiones son mejoras en las funcionalidades o incremento de las mismas, por lo que no es recomendable actualizar sin haber realizado un estudio previo de vulnerabilidades reportadas (por ejemplo, sale alguna vulnerabilidad que afecta a una version del servidor Apache en particular, distinta a la que se tenga por lo que no seria afectada).

Aunque se ha realizado una instalacion personalizada, siempre se instalan ciertos servicios por default, por lo que se debe hacer una revision de todo lo que se tiene en ejecucion, servicios que levanten el arranque e ir depurando para dejar los minimos necesarios (un servicio con un puerto a la escucha es una posible puerta por la que un atacante puede entrar).

Es recomendable configurar un firewall (IPTables para Linux) en el que siempre lo mas recomendable es optar por una politica prohibitiva (todo lo que no esta explicitamente permitido esta prohibido) e ir abriendo solo los puertos necesarios para la operacion del servidor.

Es comun que la cuenta de root (administrador) se emplee como cuenta de uso frecuente; esta es una muy mala costumbre, por lo que debe evitarse su uso, forzando a que la cuenta root solo se pueda firmar al equipo desde la consola. Para administrarlo remotamente, debera firmarse con la cuenta personal y de ahi convertirse en root.

Debe forzarse a que solo se empleen protocolos seguros para la comunicacion con el servidor; es decir, utilizar SSH para su administracion. En este punto, es necesario forzar a que el demonio de SSH solo sea compatible con la version 2 del protocolo, ya que las anteriores son vulnerables.

Aqui se debe limitar quienes de los usuarios pueden establecer sesion con el servidor (tengan shell) y de ellos quienes podran convertirse en root.

En la medida de lo posible debe "enjaularse" (chroot) tanto a los usuarios que tengan acceso al shell como a los servicios que se tengan en ejecucion, esto con la finalidad de que en caso de ser explotada una vulnerabilidad o el acceso de un usuario sea comprometido, el impacto sea menor.

Es necesario tener un control estricto en todas las bitacoras, apoyandose en herramientas para su analisis, sobre todo si el servidor tendra un alto trafico. Esto sera de utilidad para saber cuando alguien esta tratando de hacer un ataque de diccionario al SSH.

Como podra comprobar el lector, es grande la tarea de endurecer un equipo, por lo que puede continuar la lista de recomendaciones y mejores practicas. Asimismo, se trato el tema de una manera general, sin apego a una distribucion en particular y sin utilizar comandos, ya que la intencion es dejar en claro las acciones.

Para profundizar en este tema se recomiendan las siguientes direcciones:

* Reforzando la instalacion de Debian GNU/Linux www.arcert.gov.ar/ncursos/material/hardening-v2.pdf

* Asegurando un Linux Fedora Core www.apc.org/apps/img_upload/ 478cd24e3b86bdf5d2fa0c212f473f4d/Asegurando_ FC.pdf

* Asegurando una estacion de trabajo www.nautopia.net/archives/es/linux_varios/asegurando_ estacion_de_trabajo/asegurando_una_estacion_de_ trabajo.php

* Slackware Linux Benchmark checklists.nist.gov/repository/1105.html

* Hardening Slackware pof.eslack.org/hardening-slack/HARDENING_SLACKWARE. txt
COPYRIGHT 2006 Know-How Editores SA de CV
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2006 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Astorga, Agustin
Publication:E Semanal
Date:Nov 13, 2006
Words:893
Previous Article:La necesidad de hoy: segunda parte.
Next Article:De las necesidades creadas a la adiccion.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters