Feb 14, 2010

Arquitectura de seguridad local

Una vez analizados los principales rasgos de una arquitectura de seguridad perimetral, vamos a abordar las líneas maestras que debería seguir cualquier arquitectura de seguridad local.

En primer lugar vamos a tratar el tema de los servidores; es conveniente tener actualizados los servidores, no sólo a nivel de parches de seguridad, sino también a medida que van surgiendo nuevas actualizaciones de software, ya que de esta forma tendremos acceso a nuevas funcionalidades así como a mejoras en su rendimiento.

En entornos de producción es recomendable aplicar únicamente los parches de seguridad y de corrección de errores en el código (yum update en sistemas RHEL/Cent0S), y posponer las actualizaciones de versión a migraciones globales y planificadas de todos los sistemas.

Si se emplean versiones muy antiguas de los sistemas operativos, puede darse incluso la situación de que nos quedemos sin soporte alguno. Además es conveniente no utilizar ditintas clases de distribuciones y unificar todos los servidores en base a una única distribución, ya que esto facilitará las tareas de futuros administradores de la red.

A día de hoy, mi opinión personal es emplear la versión CentOS 5.4, ya que se trata de una distribución que a nivel binario es un clon de Red Hat Enterprise Linux, uno de los sistemas más estables y utilizados a nivel empresarial.

Con respecto a la seguridad de los servidores Linux, se debe de aprovechar todas las ventajas que ofrece este tipo de sistema operativo: NetFilter, SELinux context, TCP wrappers, Application control y SELinux boolean.

También es conveniente siempre que se pueda, paravirtualizar los distintos servicios a través de las diferentes tecnologías proporcionadas por VMware o Xen.

En la siguiente figura se muestra un ejemplo de paravirtualización de una máquina que realiza labores de FTP, DNS y SMTP. En dicha imagen puede observarse que se dispone de una única máquina física en la cual se encuentran levantados los tres servicios mencionados. Con el proceso de paravirtualización se crearían tres máquinas virtuales independientes en donde cada una de ellas albergaría un único servicio.


La paravirtualización es una generación de tecnología de virtualización que emplea un sistema más moderno y eficaz en la gestión de los recursos hardware. El sistema operativo virtualizado sabe que se ejecuta en un entorno virtualizado y se adapta a ello para aprovechar ese contexto. De esta forma se consigue que ciertas llamadas privilegiadas no tengan que pasar por la capa de virtualización. Con la paravirtualización se obtienen unas pérdidas de rendimiento de entorno a un 5%, en comparación a si se instalara un sistema operativo sin virtualizar directamente en el mismo hardware.

A continuación se exponen las principales ventajas que se consiguen con la virtualización:
  • Si alguno de los servidores es atacado y se consigue acceder al control de la máquina donde reside el servicio, el resto de servicios de la red permanecerán protegidos al estar emplazados en máquinas virtuales independientes.

  • Se puede establecer de una forma más sencilla y práctica, un sistema de Alta Disponibilidad que permita mantener la continuidad del servicio en situación de caída.

  • En caso de tener que restaurar un determinado servidor, al tenerlo virtualizado el proceso de restauración sería mucho más rápido y sencillo.

Una de las tareas más importantes a realizar por parte de cualquier administrador con el objetivo de securizar correctamente sus sistemas, es la de segmentar correctamente las distintas subredes. Es importante distinguir o delimitar las zonas de una red; de este modo se pueden aplicar diferentes directivas de seguridad que aíslen a las máquinas ante posibles ataques o infecciones.

En caso de que sea necesario configurar algún tipo de red privada virtual, se recomienda encarecidamente no utilizar PPTP. Este protocolo ha quedado obsoleto debido a sus numerosos fallos de seguridad; se recomienda la utilización del protocolo SSL a través de la aplicación OpenVPN. Además todo el tráfico que circule por las VPNs y que llegue a las redes internas, debe de pasar siempre por algún sistema de tipo All-In-One, con el objetivo de que sea previamente analizado.

Las VPNs que se utilicen nunca deben de establecerse a través de una clave compartida. Esta clase de autenticación corre el riesgo de ser rota mediante un ataque de fuerza bruta (debido a la longitud de las contraseñas). Por ello se propone también la implantación de una Autoridad de Certificación, encargada de emitir y administrar los certificados digitales empleados posteriormente para establecer los túneles privados. Los certificados digitales permiten recurrir claves de hasta 2048 bits.

También es recomendable instalar un servidor de monitorización (Zabbix) que se encargue de controlar en todo momento el estado de los servidores, tanto a nivel hardware (niveles de carga de CPU, memoria, disco, etc.) como a nivel software (estado de los distintos servicios, consumo de memoria, etc.).

Además también sería interesante el hecho de poder configurar un servidor de logs remoto, el cual recoja y almacene los logs de todos los servidores, con el objetivo de salvaguardar los eventos acaecidos ante un hipotético ataque.

Por último, decir que sería muy conveniente realizar auditorias periódicas de seguridad (Nessus Vulnerability Scanner) a los distintos sistemas que conforman nuestra infraestructura, ya que aunque una de las tareas de los administradores sea la de permanecer alerta ante cualquier tipo de vulnerabilidad publicada, siempre puede ocurrir que alguna de ellas sea pasada por alto.

Feb 9, 2010

Encriptar disco USB con TrueCrypt

Recientemente me he comprado un disco duro externo USB de 2.5", concretamente un LG XD3 de 500 GB. Se trata de un disco muy ligero y de reducidas dimensiones. El software que te viene para cifrar y hacer backups de los datos, para no variar, funciona exclusivamente bajo Windows, así que queda automáticamente descartado.

Lo que hice en primer lugar fue crear dos particiones en el disco, una pública y otra privada. Para ello emplee la herramienta GParted. Como sistema de archivos utilicé NTFS, con el objetivo de poder acceder a la parte pública tanto desde Windows como desde Linux.

Para cifrar la partición privada utilicé la aplicación de código abierto TrueCrypt, la cual se encuentra disponible para sistemas operativos de tipo Windows, Linux o Mac OS X. En mi caso instalé la versión 6.3a en una Kubuntu 9.10. Realmente no hace falta instalar TrueCrypt sobre el sistema operativo, podemos ejecutarlo como veremos al final del artículo y realizar tareas de encriptación y desencriptación de particiones/volúmenes.


A continuación voy a describir el proceso que hay que seguir para cifrar un disco con TrueCrypt.

En la pantalla principal de la aplicación pulsaremos sobre el botón Create Volume, mediante el cual accederemos a un asistente que nos irá guiando durante todo el proceso de cifrado de la partición. En esta primera pantalla del asistente (TrueCrypt Volume Creation Wizard) seleccionaremos la opción de Create a volume within a partition/drive. En la siguiente pantalla del asistente (Volume Type) escogeremos la opción de Standard TrueCrypt volume.

A continuación (Volume Location) seleccionaremos la partición privada del disco USB y en la pantalla de Encryption Options, el algoritmo de encriptación. Yo he escogido AES, ya que se trata de un algoritmo bastante robusto que ofrece buenas velocidades de encriptación y desencriptación. Como algoritmo hash he seleccionado SHA-512. En la pantalla de Volume Password estableceremos la clave para la partición privada.

La siguiente pantalla que nos mostrará TrueCrypt será Format Options, donde seleccionaremos el sistema de archivos con el que se formateará el volumen privado. Yo he seleccionado ext3, ya que el único sistema de archivos soportado nativamente por Windows y que ofrece TrueCrypt es FAT, el cual está más que obsoleto. Decir también que el ejecutable de TrueCrypt para Windows sí que permite seleccionar en este paso como sistema de archivos NTFS.

Al pulsar sobre el botón Format, TrueCrypt comenzará a darle formato al volumen.


A partir de este momento, cada vez que pinchemos el disco USB en nuestro sistema, se montará automáticamente la partición pública. Para montar la partición privada ejecutaremos TrueCrypt, seleccionaremos un slot libre y escogeremos el dispositivo a montar (Select Device). Por último pulsaremos sobre el botón Mount. En este momento, TrueCrypt nos solicitará la contraseña con la que ciframos el volumen.

Como dije al comienzo del capítulo, no hace falta instalar TrueCrypt en el sistema operativo para poder desencriptar posteriormente una partición. Yo lo que he hecho ha sido bajarme el ejecutable de TrueCrypt para Windows y para Linux y depositarlo en la partición pública.

De esta manera si alguna vez tengo que pinchar mi disco USB en una máquina Windows y tengo la necesidad de desencriptar el volumen privado, ejecutaré el TrueCrypt para Windows desde la partición pública y montaré en un slot libre el volumen privado. Y para Linux viceversa.

Feb 1, 2010

Arquitectura de seguridad perimetral

Uno de los mayores problemas de seguridad existentes en los tiempos modernos es la gran cantidad de amenazas que pueden encontrase, así como el número de dispositivos que se conectan a las distintas redes corporativas. Por esta razón, es prácticamente imposible encontrar lo que se conoce como una red "limpia" o inmune a contenido malicioso.

En la mayoría de las corporaciones, la arquitectura de seguridad perimetral está basada en un único elemento delimitador entre las redes internas y las redes externas (susceptibles de aportar contenidos dañinos) es un firewall que opera a nivel de red.

Un firewall es el modelo más básico que se tiene para proteger una red mediante el bloqueo de puertos. El principal problema de los firewalls es que sólo saben detener el tráfico destinado a un puerto o transportado mediante un protocolo concreto en base a unas determinadas reglas previamente establecidas. El problema viene cuando se tiene que permitir que circulen paquetes a través de un determinado puerto.

Un firewall examina el tráfico entrante por esos puertos abiertos, pero ese análisis se realiza a nivel de enlace o a nivel de red, es decir, en función de ciertos campos del paquete TCP/IP como por ejemplo las direcciones IP o puertos. Pero el área de datos proveniente del nivel de aplicación en ningún caso se considera, y ésta es la parte del paquete que presenta mayor riesgo de cara a la seguridad interna de una red. Además estos dispositivos tampoco disponen de la inteligencia suficiente como para poder detectar anomalías basándose en patrones de tráfico.

Por lo tanto, dichos puertos accesibles desde el exterior están sometidos a un cúmulo de importantes amenazas externas, como por ejemplo malware (virus, gusanos, troyanos, spyware) y ataques hacking (malformación de protocolos, escaneos de puertos, ataques DOS y SYN, avalanchas de tráfico, exploits, etc.). Es un error muy grave el hecho de delegar en los dispositivos finales las medidas de seguridad. Esta situación debe ser siempre una acción complementaria sumada a una correcta política de seguridad perimetral.

En la mayoría de los casos, los responsables de la seguridad informática de las compañías argumentan que es suficiente con tener un firewall a la entrada de la red, un antivirus en cada uno de los equipos y una sonda que rastree los eventos internos. En los párrafos anteriores se han expuesto los motivos por los que un simple firewall no es una medida lo adecuadamente disuasoria.

Con respecto a los antivirus, estas aplicaciones en teoría nos protegen de la mayoría de los virus existentes, basando su reconocimiento en una serie de firmas o patrones. Pero hoy en día los virus son capaces de mutar al poco tiempo de infectar la máquina, con lo que dificultan su identificación por parte de los antivirus.

En este sentido juegan un papel muy importante los sistemas IDS (Intrusion Detection System) como por ejemplo Snort, ya que son capaces de detectar cadenas anómalas dentro de los paquetes que circulan por una red, como por ejemplo virus cuyas firmas aún no han sido incorporadas al motor del antivirus.

Pero como bien ilustra el acrónimo IDS, estamos ante un sistema detector o pasivo, es decir, capaz de descubrir alguna situación que se salga fuera del marco habitual de comportamiento e informar a continuación al administrador. Pero en la mayoría de los casos, ese periodo de tiempo que transcurre desde que un ataque es detectado hasta que realmente se toman las medidas pertinentes, puede ser nefasto para los intereses de una organización. En este ámbito de riesgo expuesto toma especial relevancia el concepto de IPS (Intrusion Prevention System), que tecnológicamente viene a ser un IDS pero con la capacidad de prevención o bloqueo (sistema activo).


Por todo ello se recomienda establecer siempre una solución completa a la entrada de cualquier red corporativa (sistema All-In-One), la cual frene o mitigue la mayoría de las amenazas externas. Existen multitud de alternativas en el mercado que proveen soluciones de estas características, pero como mínimo deben cumplir siempre con las siguientes características técnicas: firewall, servidor VPN, IPS, anti-malware, anti-spam, filtrado web y filtrado de contenidos.

Por último, decir también que esta solución debe de situarse siempre en Alta Disponibilidad.

Jan 24, 2010

Creación y aplicación de parches con diff y patch

Patch es una herramienta Linux que permite aplicar un parche a un determinado fichero o directorio.

Un claro ejemplo de la necesidad de emplear esta herramienta puede ser el siguiente: imaginemos que anualmente actualizamos la versión de una determinada aplicación a través del código fuente. El fichero de configuración puede cambiar ligeramente de una versión a otra, pero puede haber ciertos parámetros de configuración que siempre sean los mismos para nosotros y no nos interese modificarlos.

Lo que podemos hacer ante esta situación es generar un parche el cual posteriormente podremos utilizar para parchear las futuras actualizaciones de dicho fichero de configuración.

Vamos a ver todo esto con un sencillo ejemplo. Tenemos dos ficheros, file1 (archivo original) y file2 (archivo modificado) con el siguiente contenido:

[root@centos ~]# cat file1
Hoy es Lunes

[root@centos ~]# cat file2
Hoy es Martes

Para generar el parche ejecutaríamos el comando diff con la opción -u:

[root@centos ~]# diff -u file1 file2 > file.patch

[root@centos ~]# cat file.patch
--- file1 2010-01-21 15:14:08.000000000 +0100
+++ file2 2010-01-21 15:14:42.000000000 +0100
@@ -1 +1 @@
-Hoy es Lunes
+Hoy es Martes

Ahora vamos a suponer que tenemos un tercer fichero con el siguiente contenido:

[root@centos ~]# cat file3
Hoy es Lunes

No me gustan los Lunes

Y queremos parchearlo con el archivo que hemos creado previamente. El resultado sería el siguiente:

[root@centos ~]# patch file3 < file.patch
patching file file3

[root@centos ~]# cat file3
Hoy es Martes

No me gustan los Lunes

Por último, decir que si queremos anular un parche previamente aplicado emplearemos la opción -R.

[root@centos ~]# patch -R file3 < file.patch
patching file file3

[root@centos ~]# cat file3
Hoy es Lunes

No me gustan los Lunes

Utilizando el man pueden verse las múltiples opciones de los comandos diff y patch.

Jan 18, 2010

Subsistemas de seguridad en Linux

Muchas veces cuando a un administrador de sistemas le dicen que debe securizar una determinada máquina Linux, se limita a habilitar el control por aplicación (Application control), o como mucho, a levantar el firewall a través de iptables.

Los sistemas operativos pertenecientes a la familia GNU/Linux permiten configurar distintos subsistemas de protección a parte de los dos que se acaban de mencionar.


En la figura anterior se reflejan todas las capas de protección (a nivel de arquitectura operativa) que pueden llegar a atravesar los datos una vez que llegan a la máquina.
  • Netfilter: framework de desarrollo disponible en el kernel de Linux el cual permite interceptar y manipular paquetes a nivel de red. Iptables emplea las funciones de Netfilter para realizar las tareas de firewall.

  • SELinux context: arquitectura de seguridad integrada en el propio núcleo de Linux que controla los contextos, entornos o directorios sobre los que se ejecutan las aplicaciones.

  • TCP wrappers: filtra el acceso a determinados servicios en base a distintas reglas.

  • Application control: medidas de seguridad integradas y tomadas desde las propias aplicaciones que operan a nivel de usuario.

  • SELinux boolean: arquitectura de seguridad integrada en el propio núcleo de Linux que controla la mayoría de las funciones permitidas en el sistema y que conllevan ciertos riesgos de seguridad.

Jan 10, 2010

Backups en VMware ESXi

VMware ESXi 4.0 sólo nos permite hacer un backup de la configuración del servidor (usuarios, servidores NTP, parámetros del sistema, etc.) y no de las máquinas virtuales. Esta tarea se puede realizar a través del VMware vSphere CLI:

VMware vSphere CLI> vicfg-cfgbackup --server 192.168.1.11 --username root --password xxxxxx -s ESXi20091211.backup

Únicamente tendremos que indicar la dirección IP del ESXi, la password para el usuario root y un nombre para el fichero de backup.

Para restaurar el backup de configuración, ejecutaremos la siguiente orden:

VMware vSphere CLI> vicfg-cfgbackup --server 192.168.1.11 --username root --password xxxxxx -l ESXi20091211.backup

Para hacer un backup de una máquina virtual, tenemos la opción de exportarla a través de la herramienta VMware vSphere Client. Para ello tendremos que apagarla en primer lugar y a continuación pulsar sobre File, Export, Export OVF Template. Esta opción nos permitirá guardar en nuestro disco duro local una imagen en formato OVF de la máquina virtual.

El formato OVF (Open Virtualization Format) es un estándar abierto para empaquetar y distribuir máquinas virtuales. Su principal ventaja es que el tamaño de las exportaciones suele ser bastante más pequeño que el original, ya que no empaqueta las secciones del disco duro virtual que están sin utilizar. Por contra, este proceso tiene la principal desventaja de que hay que hacerlo con la máquina virtual apagada y de forma manual.

Si tenemos acceso a la service console del ESXi, vamos a tener la posibilidad de poder realizar backups de las máquinas virtuales de manera automática y en caliente, es decir, sin apagar el sistema operativo de la máquina virtual.

La idea es la siguiente: en primer lugar habría que hacer una copia del fichero VMK de la máquina virtual. A continuación habría que hacer un snapshot, de esta forma y a partir de este momento, cualquier cambio no se escribiría en el disco virtual, sino en el snapshot. Después ya podríamos copiar el disco virtual VMDK, y por último, eliminaríamos el snapshot.

Para hacer todo esto existe un script llamado ghettoVCB.sh, el cual sigue una metodología similar a la herramienta de pago de VMware para tal fin: VCB (VMware Consolidated Backup). Este script lo depositaremos en el datastore local del ESXi y le asignaremos permisos de ejecución.

~ # chmod +x /vmfs/volumes/datastore1/ghettoVCB.sh

La razón por la que se guarda en el datastore local es debido a que cualquier fichero o directorio que creemos fuera de este espacio, será automáticamente eliminado al volver a arrancar el ESXi.

El backup que creemos a partir de la máquina virtual lo podremos almacenar en el propio datastore local o montar una unidad de almacenamiento por NFS o iSCSI. Para el presente caso de estudio vamos a emplear un datastore remoto accedido por NFS y ubicado en la máquina con dirección IP 192.168.1.100.

Para dicho datastore se tiene la opción de dejarlo montado de forma permanente a través del cliente vSphere, o bien configurar las variables del script para que monte y desmonte la unidad remota cuando la vaya a emplear. Utilizaremos la segunda opción.

A continuación vamos a editar el script y modificar el valor de alguna de sus variables.

~ # cat /vmfs/volumes/datastore1/ghettoVCB.sh
...
# Formato del backup de la VM
DISK_BACKUP_FORMAT=zeroedthick

# Número de backups que serán rotados
VM_BACKUP_ROTATION_COUNT=1

# Habilitar el backup a través de NFS
ENABLE_NON_PERSISTENT_NFS=1

# Desmontar la unidad remota cuando el backup se haya completado
UNMOUNT_NFS=1

# Dirección IP del servidor NFS
NFS_SERVER=192.168.1.100

# Directorio que exportará el servidor NFS
NFS_MOUNT=/export

# Nombre con el que se mostrará el datastore importado
NFS_LOCAL_NAME=nfs_storage_backup

# Nombre del directorio donde se almacenarán los backups
NFS_VM_BACKUP_DIR=backups
...

Si en lugar de almacenar el backup en la máquina remota a través de NFS hubiéramos empleado el propio datastore local del ESXi, tendríamos que haber definido a través de la variable VM_BACKUP_VOLUME el path donde depositar el backup.

Los distintos formatos que soporta el backup (variable DISK_BACKUP_FORMAT) son los siguientes:

  • zeroedthick: éste es el tipo de disco utilizado por defecto al crear una VM en un ESXi y todo el espacio de almacenamiento es reservado previamente. Además, sus bloques son borrados (puestos a cero) la primera vez que se escribe sobre ellos.

  • eagerzeroedthick: durante el momento de su creación, todo el espacio es reservado y puesto a cero. Este tipo de discos son los más seguros, ya que los bloques han sido previamente borrados de cualquier dato previo, ofreciendo además un rendimiento ligeramente superior durante la primera operación de escritura.

  • thin: este tipo de disco tiene la peculiaridad de que crece bajo demanda, es decir, se puede definir un disco thin con un tamaño máximo de 100 GB, y nada más instalar el sistema operativo ocupar sólo 4 GB. Esos 4 GB serán el tamaño real del disco y podrá crecer hasta los 100 GB. El rendimiento ofrecido por este tipo de formato es muy pobre y no se recomienda para entornos de producción.

  • 2gbsparse: divide un disco en varios discos de un tamaño máximo de 2 GB. Este tipo de formato no se puede utilizar directamente en un ESX/ESXi, por lo que hay que transformarlo previamente a un formato thin o thick.

Decir también que el formato seleccionado (zeroedthick) crea una imagen idéntica (bit a bit) a la de la máquina virtual. Después ya por último, crearemos un fichero con la lista de las máquinas virtuales sobre las que queramos aplicar el backup (por ejemplo y para el presente caso de estudio, dos máquinas virtuales denominadas centos01.local y centos02.local).

~ # cat /vmfs/volumes/datastore1/vms_to_backup
centos01.local
centos02.local

Para ejecutar el script lanzaremos la siguiente orden:

/vmfs/volumes/4a65032c-09446b90-9d40-00237d337b62 # ./ghettoVCB.sh -f vms_to_backup -l log_backup

Para automatizar este proceso de backups podemos añadir una tarea al cron del sistema operativo. En el siguiente ejemplo se va a configurar un backup automático que se ejecute todos los Sábados por la noche a las 02:30h.

En primer lugar vamos a definir esta tarea en el cron del usuario root:

~ # cat /var/spool/cron/crontabs/root
...
30 02 * * 6 /vmfs/volumes/datastore1/ghettoVCB.sh -f /vmfs/volumes/datastore1/vms_to_backup -l /vmfs/volumes/datastore1/log_backup

Para que los cambios tomen efecto, vamos a reiniciar el proceso crond. Para ello primero lo mataremos y luego lo volveremos a arrancar a través de busybox (binario que contiene pequeñas versiones de los comandos más básicos de Linux).

~ # kill $(cat /var/run/crond.pid)

~ # busybox crond

El problema de este método es que si en un momento dado hay que reiniciar el ESXi, el sistema operativo restaurará el cron de root por su original. Por lo tanto lo que habrá que hacer será editar el fichero /etc/rc.local y definir este proceso dentro de dicho archivo.

~ # cat /etc/rc.local
...
/bin/kill $(cat /var/run/crond.pid)
/bin/echo "30 02 * * 6 /vmfs/volumes/datastore1/ghettoVCB.sh -f /vmfs/volumes/datastore1/vms_to_backup -l /vmfs/volumes/datastore1/log_backup" >> /var/spool/cron/crontabs/root
/bin/busybox crond

Y por último, para asegurarnos que los cambios en el fichero /etc/rc.local serán guardados para futuros reinicios, ejecutaremos el siguiente comando:

~ # /sbin/auto-backup.sh

Para restaurar un backup de una VM, primero copiaremos el directorio que contiene el backup al datastore local de la máquina, bien a través de una conexión iSCSI o NFS hacia la máquina que contiene los backups, o por ejemplo subiendo dicho directorio al datastore desde el ordenador con el que nos conectemos al ESXi a través del cliente vSphere.

A continuación, ejecutaremos un Browse sobre el datastore, accederemos al directorio que contiene todos los ficheros de la VM y pincharemos con el botón derecho del ratón sobre el archivo con extensión VMK. Para restaurar la máquina ejecutaremos la orden Add to Inventory.

Jan 4, 2010

VMware ESXi: Acceso a la shell de root por SSH

Una de las limitaciones que trae la versión gratuita de VMware ESX (vSphere), más conocido como ESXi, es que no tiene la Service Console (acceso SSH a la shell del sistema).

Para activar este servicio hay que acceder físicamente a la máquina donde se encuentre instalado el ESXi (conectada previamente a un teclado y un monitor) y abrir un terminal pulsando la combinación de reclas Alt+F1.

Una vez tengamos abierto el terminal, escribiremos la palabra unsupported. A continuación nos saldrá la palabra "Password :", con lo que tendremos que teclear la contraseña del usuario root del ESXi. A partir de este momento tendremos una shell con la que podremos ejecutar bastantes comandos Linux (otros muchos han sido quitados), con lo que sólo nos quedará que activar el servicio SSH.

Para ello editaremos con vi el fichero /etc/inetd.conf y descomentaremos la línea "#ssh stream tcp...". Reiniciaremos a continuación el administrador de servicios, eliminaremos todos los procesos inetd y por último, volveremos a lanzar el demonio inetd.

~ # /sbin/services.sh restart

~ # kill `ps | grep inetd | cut -f2 -d" "‘

~ # inetd