1.- ¿Qué aplicación consume más ancho de banda?

Este artìculo nos muestra cómo saber que aplicación en nuestro ordenador está consumiendo más ancho de banda.Para lograr esto tenemos que instalar una aplicación llamada Nethogs. El funcionamiento de nethogs es sencillo, lo único que tenemos que hacer es ejecutarlo con privilegios de root y especificar la red a monitorizar.

2.- Cómo instalar y configurar Fail2ban en Debian.

Fail2ban es una aplicación escrita en Python para la prevención de intrusos en un sistema, que se basa en la penalización de conexión (bloquear conexión) a los orígenes que intentan accesos por fuerza bruta. Se distribuye bajo la licencia GNU y típicamente funciona en todos los sistemas POSIX que tengan interfaz con un sistema de control de paquetes o un firewall local.

3.- Cómo agregar el nuevo Google Keep a tu Unity.

Hace unos días Google lanzo su aplicación oficial para Chrome para su novedoso servicio de notas Keep. Keep para Chrome no se ejecuta como una pestaña en el navegador, ni como una extensión desplegable ya que se trata de una 'aplicación empaquetada', sino que al ser una aplicación semi-nativa se pude usar sin la necesidad del navegador (Chrome no se necesita ejecutar para usarlo) y aparte se puede usar estando offline.

4.- Como hacer un servidor SSH protocolo de comunicación para controlar un ordenador en remoto.
SSH (acrónimo del inglés Secure SHell, cuya traducción sería intérprete de comandos seguro) es un protocolo de comunicación para controlar un ordenador en remoto a través de una CLI (Command Line Interface -Interfaz de Línea de Comandos- también llamada: "shell".

5.- Guía PHP: como crear una calculadora básica.

PHP es un lenguaje de programación de uso general de código del lado del servidor originalmente diseñado para el desarrollo web de contenido dinámico. Fue uno de los primeros lenguajes de programación del lado del servidor que se podían incorporar directamente en el documento HTML en lugar de llamar a un archivo externo que procese los datos.

6.- Bugtroid herramienta innovadora para auditorías en dispositivos móviles.

Bugtroid es una herramienta innovadora desarrollada por el equipo de Bugtraq-Team. Las principales características de esta apk, es que cuenta con más de 200 herramientas de Android y Linux (PRO) para pentesting y forense a través de su Smarthphone o tableta. Tiene un menú categorizado de acuerdo con la naturaleza de la herramienta puede encontrar:

7.- Guía de GHex editor hexadecimal de GNOME: preferencias.

Editar.Número máximo de niveles de deshacer Use esta casilla de selección para especificar el número máximo de acciones que puede deshacer. Mostrar el desplazamiento del cursor en la barra de estado como Use esta lista desplegable para seleccionar el formato en el que se mostrará el desplazamiento del cursor. El formato puede ser decimal, hexadecimal o una cadena de estilo de impresión personalizado que sólo contenga los especificadores de formato x, o y s.

8.- Guía de GHex editor hexadecimal de GNOME: editar un archivo

Para editar un archivo, ejecute los siguientes pasos:

1. Pulse en la vista hexadecimal o ASCII del archivo. La vista en la que el cursor está activo muestra un cursor completo. La vista en la que el cursor no está activo muestra el contorno del cursor.
   
2. Use cualquiera de los siguientes métodos para mover el cursor por el archivo:
   

9.- Colección de iconos para Tux, el simpático pinguino de Linux.

10.- 4Pane navegador de archivos para Linux con cuatro paneles

4Pane es un explorador de carpetas con el que no perdernos entre la enorme cantidad de ficheros del directorio raíz. Su interfaz se divide en cuatro partes, para facilitar la navegación y poder mover ficheros de una carpeta a otra rápidamente, recordando al mítico Midnight Commander pero en versión gráfica.
A sus funciones como gestor de archivos incorpora otras, como enlaces a Firefox, Openoffice y el editor de texto, montaje de discos, particiones e ISOs, extracción de archivos comprimidos e incluso una lista de las carpetas que más solemos abrir y acceso al terminal.

Si te ha gustado el artículo inscribete al feed clicando en la imagen más abajo para tenerte siempre actualizado sobre los nuevos contenidos del blog:

SSH (acrónimo del inglés Secure SHell, cuya traducción sería intérprete de comandos seguro) es un protocolo de comunicación para controlar un ordenador en remoto a través de una CLI (Command Line Interface -Interfaz de Línea de Comandos- también llamada: "shell".

Sirve para conectarnos con un ordenador ante el cual no estamos físicamente, bien porque está en una sala de servidores refrigerada, bien porque no tiene teclado ni pantalla, por ejemplo los que están apilados en un rack (un armario donde se guardan ordenadores como los servidores web, de correo electrónico, firewalls, etc...).

Es parecido a Telnet, con la gran diferencia de que en el caso de ssh, la información viaja codificada con lo cual es muchísimo más segura, en el caso de conectarnos a un ordenador que esté en nuestra LAN no es tan importante, pero si nos conectamos a través de Internet es fundamental, casi diría que imprescindible, usar un protocolo seguro como SSH. .

Conectarnos a un servidor ssh.
Para conectarnos con un servidor SSH remoto desde Ubuntu tenemos un cliente por defecto. En Windows no, hay que descargar un cliente (por ejemplo, el programa putty(Putty)). Usar el cliente es muy sencillo: basta con teclear desde una consola o terminal lo siguiente:

$ ssh host_remoto

Donde host_remoto es la IP del servidor SSH o el nombre de este. Eso hará que nos conectemos con nuestro nombre de usuario. Si queremos conectar como un usuario remoto teclearemos:

$ ssh usuario_remoto@host_remoto

Luego nos pide la contraseña del usuario. La primera vez que nos conectemos a un servidor tarda un poco más y nos pide confirmación tecleando "yes" con todas sus letras, las subsiguientes ya no. Sabemos que estamos conectados porque el prompt cambia y aparece en lugar del nombre de nuestro host el nombre del host remoto.

Los comandos, programas y scripts que lancemos tras conectarnos se ejecutarán en la máquina a las que nos hayamos conectado, utilizando los recursos del host remoto (CPU, memoria, disco, etc.).

Esta arquitectura puede utilizarse, por ejemplo, para tener un servidor más potente y varios clientes que ejecutan aplicaciones en dicha máquina.

Para ejecutar aplicaciones gráficas en la máquina a la que nos conectamos tenemos dos opciones. La primera consiste en definir la variable $DISPLAY apuntando a la máquina desde la que nos conectamos.

$ export DISPLAY=host_local:0.0

Este mecanismo no se recomienda por motivos de seguridad (el protocolo X11 no se encuentra cifrado) y, además, pueden encontrarse problemas porque cortafuegos intermedios bloqueen ese tráfico (puertos 600x TCP).

Una solución mejor es utilizar un túnel SSH para encapsular el protocolo X11, lo que transmite la información de manera segura y, además, no suele dar problemas con los cortafuegos intermedios.

Para poder ejecutar aplicaciones gráficas en el host remoto de forma segura, necesitamos dos cosas. La primera, que en la configuración del servidor SSH del host remoto (/etc/ssh/sshd_config) se encuentre activada la siguiente opción:

X11Forwarding yes

Para aprovechar esta característica, hemos de conectarnos usando el parámetro -X, lo que exportará la configuración de la variable $DISPLAY con lo que podremos ejecutar aplicaciones gráficas de forma remota:

$ ssh -X usuario_remoto@host_remoto

Ahora si ejecutas el programa xclock verás que la ventana sale en tu escritorio:

$ xclock

Tipo de ataque man-in-the-middle.

Imaginemos que la IP de nuestro servidor es 192.168.2.3. Nos conectamos via SSH desde otro equipo, la primera vez tarda un poco más porque tiene que escribir en el archivo /home/[nuestro_usuario]/.ssh/known_host una entrada para esa IP.

Las subsiguientes veces que nos conectemos compara la clave gpg de la IP con la que tiene guardada en el archivo known_host, en caso de variar supone que el ordenador es distinto -por ejemplo, porque el ordenador servidor ssh ha sido formateado o porque se ha apagado y sustituido por otro al que se le ha asignado la misma IP-. Ese es el error man-in-the-middle y significa: "el ordenador cuya IP es esa, no es el mismo que yo conocía. Puede ser que alguien se esté haciendo pasar por él" y no nos deja volvernos a conectar salvo que borremos la entrada de esa IP en el archivo known_host.

Evitar que nos pida el password cada vez.

Siempre que conectemos a un ordenador remoto con SSH nos va a pedir el password de acceso para asegurarse de que tenemos permisos. Hay una forma de evitar que nos pida el password siempre haciendo que el ordenador remoto confíe en nosotros. Para ello hemos de generar un par de claves DSA que se usarán en la relación de confianza:

$ ssh-keygen -t dsa

se generara esto:

Generating public/private dsa key pair.
Enter file in which to save the key (/home/usuario/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/usuario/.ssh/id_dsa.
Your public key has been saved in /home/usuario/.ssh/id_dsa.pub.
The key fingerprint is:
81:a1:d3:96:fa:a2:73:4d:3a:76:c1:fd:3f:6a:6f:1e usuario@localhost

Una vez generada la copiamos al usuario del ordenador remoto con el que queremos mantener la relación de confianza usando el comando ssh-copy-id.

Este es un ejemplo del uso con la salida del programa: $ ssh-copy-id usuario_remoto@192.168.0.1

Now try logging into the machine, with "ssh 'usuario_remoto@192.168.0.1'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

Si te da el error No identities found prueba a indicarle la ruta de la clave pública con -i
Para que funcione correctamente el comando ssh-copy-id el agente tiene que estar activo para la sesión. Si no lo has puesto que lo arranque al inicio como se explica un poco más abajo, tendrás que arrancarlo desde la consola ejecutando ssh-add.

Ahora solo hay que arrancar el agente SSH para que recuerde nuestra contraseña. Nos pregunta la contraseña y ahora ya podemos acceder al ordenador remoto sin tener que escribir el password cada vez.

$ ssh-add

El agente sólo dura mientras esté activa nuestra consola. O sea que si la cerramos y la volvemos a abrir ya no está activo el agente y nos volverá a pedir el password cada vez. Para evitar esto lo que podemos hacer es añadir el agente a la sesión para que se ejecute cada vez que se inicie GNOME. Al iniciar saldrá un diálogo que nos preguntará por la contraseña.

Copia de seguridad .

Si vas a migrar la configuración de tu usuario a otra máquina tienes que conservar el directorio $HOME/.ssh. Ahí es donde se guarda los ficheros de la clave pública y privada generadas en el punto anterior:

$ tar czf ssh.tgz $HOME/.ssh

SSHFS o montar directorio remoto con SSH
Algunas veces necesitamos trabajar durante bastante tiempo con un sistema remoto, copiando y editando ficheros. Existe la posibilidad de usar Nautilus que se puede conectar remotamente al servidor usando el protocolo 'sftp://, pero suele ser lento y muchas veces es más práctico usar la línea de comandos. La solución sería montar un recurso remoto al estilo de NFS y encima sin tener que se root. Pues si, se puede

Fuse es un módulo del kenel que permite montar distintos sistemas de ficheros con un usuario normal sin privilegios. SSHFS es un programa creado por el autor de fuse que permite montar un directorio remoto usando SSH.

Accederemos localmente como si estuviera en nuestra propia máquina. Hay que instalar el programa sshfs. El usuario que puede montar el sistema de ficheros tiene que pertenecer al grupo fuse.

$ sudo usermod -G fuse -a usuario_local

Tenemos que salir y volver a entrar en el sistema para que se haga efectivo el cambio de grupo. Antes de empezar a usar fuse tienes que cargar el módulo en memoria:

$ sudo modprobe fuse

Ahora vamos a hacer una prueba:

$ mkdir ~/directorio_remoto
$ sshfs usuario_remoto@servidor_remoto:/tmp ~/directorio_remoto

Este comando monta el directorio /tmp del servidor remoto en el directorio local ~/directorio_remoto. Ahora podemos trabajar en el directorio montado como si de un directorio local se tratase. Para desmontar el directorio:

$ fusermount -u ~/directorio_remoto

Si vamos a trabajar a diario con este directorio remoto, quizás es buena idea añadirlo al fichero /etc/fstab. De esta forma se montará automáticamente al iniciar nuestro ordenador o manualmente (si elegimos la opción noauto) sin necesidad de especificar la localización remota cada vez. Este es un ejemplo de configuración:

$ sshfs#usuario_remoto@remote_server:/tmp /home/usuario_local/directorio_remoto fuse defaults,auto 0 0

Si vamos a usar fuse y sshfs regularmente, tendrías que editar el fichero /etc/modules y añadir el módulo fuse. De otra forma tendrás que cargar el módulo manualmente cada vez que lo quieras usar:

$ sudo sh -c "echo fuse >> /etc/modules"

Ejecutar comandos en un host remoto.

Ahora que ya sabemos como entrar en un ordenador remoto sin el password, por qué no ejecutar comandos remotamente? Se abre un nuevo mundo de posibilidades muy útiles como tareas que se pueden ejecutar de forma automática.

$ ssh usuario_remoto@host_remoto "find /tmp -name *.txt"

Este comando buscará los ficheros de texto del directorio temporal que hay en el ordenador remoto. Si bien es un ejemplo poc útil, en la vida de un administrador de sistema hay muchos buenos ejemplos.
Y vamos a dar una nueva vuelta de rosca: si estamos administrando sistemas Unix/Linux es muy posible que necesitemos ejecutar el mismo programa en varios servidores a la vez. Este sencillo script e suna gran ayuda en esos casos:

#!/usr/bin/perl
@hosts=(
"usuario1\@maquina1.guay.es",
"usuario2\@maquina2.guay.es"
);
die "Uso: runonall \'command\'\n" unless $ARGV[0];
foreach(@hosts){
print "$_ -> $ARGV[0]:\n";
print `ssh $_ $ARGV[0]`;
}

Enviar u obtener archivos y carpetas con scp

En una consola o terminal tecleamos:

$ scp -r usuario@maquina:/home/carpeta .

luego ponemos la password del usuario y nos copiará la carpeta "/home/carpeta" remota en el directorio actual "." naturalmente siempre que usuario tenga permisos sobre la carpeta y su cuenta esté entre las de los que pueden hacer ssh. La opción "-r" significa recursivo, es decir, copia la carpeta y todo su contenido, incluidas las subcarpetas y el contenido de éstas. Si no lo ponemos la orden para copiar todos los archivos de una carpeta sería:

$ scp usuario@maquina:/home/carpeta/* .

Si lo que queremos es enviar una carpeta con su contenido, utilizaremos la orden:

$ scp /home/carpeta/* usuario@maquina:/carpeta/

Hacer todo esto en modo gráfico.

Silo que que queremos es conectarnos a un ordenador por ssh en modo grafico también lo podremos hacer. Es mas simple pero tambien tienes menos posibilidades, o para hacer ciertas cosas tardas mas incluso que haciendolo por consola pero para las operaciones faciles como administrar, editar un fichero tambien es posible hacerlo de esta manera.

Entraremos en Lugares -> Conectarse al servidor...

Elegiremos en el combbo de arriba en lugar de FTP publico, SSH y pondremos la IP o el nombre (en caso de anteriormente ya hallamos editado el fichero hosts) y asi despues de teclear la contraseña y aceptar estaremos ya dentro del mismo.

Instalación del servidor SSH.
El cliente ya viene instalado por defecto, de modo que para instalar el servidor de SSH en nuestro sistema lo único que necesitas es instalar el paquete openssh-server.

Restringir el acceso SSH
Para evitar que todos los usarios de la máquina estén accesibles por SSH tendremos que editar como root el fichero /etc/ssh/sshd_conf, y añadir la línea AllowUsers y a continuación los usuarios que deseamos que se puedan conectar remotamente via SSH:

$ sudo gedit /etc/ssh/sshd_conf

Y añadimos la línea:

AllowUsers usuario1 usuario2 usuario3

Para que los cambios surtan efectos habrá que reiniciar el servidor:

$ sudo /etc/init.d/ssh restart

* Restarting OpenBSD Secure Shell server...

Si te ha gustado el artículo inscribete al feed clicando en la imagen más abajo para tenerte siempre actualizado sobre los nuevos contenidos del blog:

SSH (Secure SHell) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. Permite manejar por completo la computadora mediante un intérprete de comandos, y también puede redirigir el tráfico de X para poder ejecutar programas gráficos si tenemos un Servidor X (en sistemas Unix y Windows) corriendo.

Además de la conexión a otros dispositivos, SSH nos permite copiar datos de forma segura (tanto ficheros sueltos como simular sesiones FTP cifradas), gestionar claves RSA para no escribir claves al conectar a los dispositivos y pasar los datos de cualquier otra aplicación por un canal seguro tunelizado mediante SSH.

SSH trabaja de forma similar a como se hace con telnet. La diferencia principal es que SSH usa técnicas de cifrado que hacen que la información que viaja por el medio de comunicación vaya de manera no legible y ninguna tercera persona pueda descubrir el usuario y contraseña de la conexión ni lo que se escribe durante toda la sesión; aunque es posible atacar este tipo de sistemas por medio de ataques de REPLAY y manipular así la información entre destinos.

Al principio sólo existían los r-commands, que eran los basados en el programa rlogin, el cual funciona de una forma similar a telnet.

La primera versión del protocolo y el programa eran libres y los creó un finlandés llamado Tatu Ylönen, pero su licencia fue cambiando y terminó apareciendo la compañía SSH Communications Security, que lo ofrecía gratuitamente para uso doméstico y académico, pero exigía el pago a otras empresas. En el año 1997 (dos años después de que se creara la primera versión) se propuso como borrador en la IETF.

A principios de 1999 se empezó a escribir una versión que se convertiría en la implementación libre por excelencia, la de OpenBSD, llamada OpenSSH.

Conexión a un servidor remoto.

Para conectarnos con un servidor SSH remoto desde Ubuntu tenemos un cliente por defecto.  Usar el cliente es muy sencillo: basta con teclear desde una consola o terminal lo siguiente:

$ ssh host_remoto

Donde host_remoto es la IP del servidor SSH o el nombre de este. Eso hará que nos conectemos con nuestro nombre de usuario. Si queremos conectar como un usuario remoto teclearemos:

$ ssh usuario_remoto@host_remoto

Luego nos pide la contraseña del usuario. La primera vez que nos conectemos a un servidor tarda un poco más y nos pide confirmación tecleando "yes" con todas sus letras, las subsiguientes ya no. Sabemos que estamos conectados porque el prompt cambia y aparece en lugar del nombre de nuestro host el nombre del host remoto.

Los comandos, programas y scripts que lancemos tras conectarnos se ejecutarán en la máquina a las que nos hayamos conectado, utilizando los recursos del host remoto (CPU, memoria, disco, etc.). Esta arquitectura puede utilizarse, por ejemplo, para tener un servidor más potente y varios clientes que ejecutan aplicaciones en dicha máquina.

Para ejecutar aplicaciones gráficas en la máquina a la que nos conectamos tenemos dos opciones. La primera consiste en definir la variable $DISPLAY apuntando a la máquina desde la que nos conectamos.

$ export DISPLAY=host_local:0.0

Este mecanismo no se recomienda por motivos de seguridad (el protocolo X11 no se encuentra cifrado) y, además, pueden encontrarse problemas porque cortafuegos intermedios bloqueen ese tráfico (puertos 600x TCP).

Una solución mejor es utilizar un túnel SSH para encapsular el protocolo X11, lo que transmite la información de manera segura y, además, no suele dar problemas con los cortafuegos intermedios.

Para poder ejecutar aplicaciones gráficas en el host remoto de forma segura, necesitamos dos cosas. La primera, que en la configuración del servidor SSH del host remoto (/etc/ssh/sshd_config) se encuentre activada la siguiente opción:

X11Forwarding yes

Para aprovechar esta característica, hemos de conectarnos usando el parámetro -X, lo que exportará la configuración de la variable $DISPLAY con lo que podremos ejecutar aplicaciones gráficas de forma remota:

$ ssh -X usuario_remoto@host_remoto

Ahora si ejecutas el programa xclock verás que la ventana sale en tu escritorio:

$ xclock

Tipo de ataque man-in-the-middle.

Imaginemos que la IP de nuestro servidor es 192.168.2.3. Nos conectamos via SSH desde otro equipo, la primera vez tarda un poco más porque tiene que escribir en el archivo /home/[nuestro_usuario]/.ssh/known_host una entrada para esa IP.

Las subsiguientes veces que nos conectemos compara la clave gpg de la IP con la que tiene guardada en el archivo known_host, en caso de variar supone que el ordenador es distinto -por ejemplo, porque el ordenador servidor ssh ha sido formateado o porque se ha apagado y sustituido por otro al que se le ha asignado la misma IP-. Ese es el error man-in-the-middle y significa: "el ordenador cuya IP es esa, no es el mismo que yo conocía. Puede ser que alguien se esté haciendo pasar por él" y no nos deja volvernos a conectar salvo que borremos la entrada de esa IP en el archivo known_host. Tienes más información al respecto en el artículo de la Wikipedia Ataque Man-in-the-middle.

Evitar que nos pida el password cada vez.

Siempre que conectemos a un ordenador remoto con SSH nos va a pedir el password de acceso para asegurarse de que tenemos permisos. Hay una forma de evitar que nos pida el password siempre haciendo que el ordenador remoto confíe en nosotros. Para ello hemos de generar un par de claves DSA que se usarán en la relación de confianza:

$ ssh-keygen -t rsa

Generating public/private dsa key pair.
Enter file in which to save the key (/home/usuario/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/usuario/.ssh/id_dsa.
Your public key has been saved in /home/usuario/.ssh/id_dsa.pub.
The key fingerprint is:
81:a1:d3:96:fa:a2:73:4d:3a:76:c1:fd:3f:6a:6f:1e usuario@localhost

Una vez generada la copiamos al usuario del ordenador remoto con el que queremos mantener la relación de confianza usando el comando ssh-copy-id. Este es un ejemplo del uso con la salida del programa:

$ ssh-copy-id usuario_remoto@192.168.0.1

Now try logging into the machine, with "ssh 'usuario_remoto@192.168.0.1'", and check in:


.ssh/authorized_keys


to make sure we haven't added extra keys that you weren't expecting.

Si te da el error No identities found prueba a indicarle la ruta de la clave pública con -i

Para que funcione correctamente el comando ssh-copy-id el agente tiene que estar activo para la sesión. Si no lo has puesto que lo arranque al inicio como se explica un poco más abajo, tendrás que arrancarlo desde la consola ejecutando ssh-add.

Ahora solo hay que arrancar el agente SSH para que recuerde nuestra contraseña. Nos pregunta la contraseña y ahora ya podemos acceder al ordenador remoto sin tener que escribir el password cada vez.

$ ssh-add

El agente sólo dura mientras esté activa nuestra consola. O sea que si la cerramos y la volvemos a abrir ya no está activo el agente y nos volverá a pedir el password cada vez. Para evitar esto lo que podemos hacer es añadir el agente a la sesión para que se ejecute cada vez que se inicie GNOME. Al iniciar saldrá un diálogo que nos preguntará por la contraseña.

Copia de seguridad.

Si vas a migrar la configuración de tu usuario a otra máquina tienes que conservar el directorio $HOME/.ssh. Ahí es donde se guarda los ficheros de la clave pública y privada generadas en el punto anterior:

$ tar czf ssh.tgz $HOME/.ssh

SSHFS o montar directorio remoto con SSH.

Algunas veces necesitamos trabajar durante bastante tiempo con un sistema remoto, copiando y editando ficheros. Existe la posibilidad de usar Nautilus que se puede conectar remotamente al servidor usando el protocolo 'sftp://, pero suele ser lento y muchas veces es más práctico usar la línea de comandos. La solución sería montar un recurso remoto al estilo de NFS y encima sin tener que se root. Pues si, se puede :)

Fuse es un módulo del kenel que permite montar distintos sistemas de ficheros con un usuario normal sin privilegios. SSHFS es un programa creado por el autor de fuse que permite montar un directorio remoto usando SSH. Accederemos localmente como si estuviera en nuestra propia máquina. Hay que instalar el programa sshfs. El usuario que puede montar el sistema de ficheros tiene que pertenecer al grupo fuse.

$ sudo usermod -G fuse -a usuario_local

Tenemos que salir y volver a entrar en el sistema para que se haga efectivo el cambio de grupo. Antes de empezar a usar fuse tienes que cargar el módulo en memoria:

$ sudo modprobe fuse

Ahora vamos a hacer una prueba:

$ mkdir ~/directorio_remoto

$ sshfs usuario_remoto@servidor_remoto:/tmp ~/directorio_remoto

Este comando monta el directorio /tmp del servidor remoto en el directorio local ~/directorio_remoto.

Ahora podemos trabajar en el directorio montado como si de un directorio local se tratase. Para desmontar el directorio:

$ fusermount -u ~/directorio_remoto

Si vamos a trabajar a diario con este directorio remoto, quizás es buena idea añadirlo al fichero /etc/fstab.

De esta forma se montará automáticamente al iniciar nuestro ordenador o manualmente (si elegimos la opción noauto) sin necesidad de especificar la localización remota cada vez. Este es un ejemplo de configuración:

$ sshfs#usuario_remoto@remote_server:/tmp /home/usuario_local/directorio_remoto fuse defaults,auto 0 0

Si vamos a usar fuse y sshfs regularmente, tendrías que editar el fichero /etc/modules y añadir el módulo fuse. De otra forma tendrás que cargar el módulo manualmente cada vez que lo quieras usar:

$ sudo sh -c "echo fuse >> /etc/modules"

Ejecutar comandos en un host remoto.

Ahora que ya sabemos como entrar en un ordenador remoto sin el password, por qué no ejecutar comandos remotamente? Se abre un nuevo mundo de posibilidades muy útiles como tareas que se pueden ejecutar de forma automática.

$ ssh usuario_remoto@host_remoto "find /tmp -name *.txt"

Este comando buscará los ficheros de texto del directorio temporal que hay en el ordenador remoto. Si bien es un ejemplo poc útil, en la vida de un administrador de sistema hay muchos buenos ejemplos.

Y vamos a dar una nueva vuelta de rosca: si estamos administrando sistemas Unix/Linux es muy posible que necesitemos ejecutar el mismo programa en varios servidores a la vez. Este sencillo script e suna gran ayuda en esos casos:

#!/usr/bin/perl


@hosts=(
"usuario1\@maquina1.guay.es",
"usuario2\@maquina2.guay.es"
);


die "Uso: runonall \'command\'\n" unless $ARGV[0];


foreach(@hosts){
print "$_ -> $ARGV[0]:\n";
print `ssh $_ $ARGV[0]`;
}

Enviar u obtener archivos y carpetas con scp.

En una consola o terminal tecleamos:

$ scp -r usuario@maquina:/home/carpeta .

luego ponemos la password del usuario y nos copiará la carpeta "/home/carpeta" remota en el directorio actual "." naturalmente siempre que usuario tenga permisos sobre la carpeta y su cuenta esté entre las de los que pueden hacer ssh. La opción "-r" significa recursivo, es decir, copia la carpeta y todo su contenido, incluidas las subcarpetas y el contenido de éstas. Si no lo ponemos la orden para copiar todos los archivos de una carpeta sería:

$ scp usuario@maquina:/home/carpeta/* .

Si lo que queremos es enviar una carpeta con su contenido, utilizaremos la orden:

$ scp /home/carpeta/* usuario@maquina:/carpeta/

Hacer todo esto en modo gráfico.

Si lo que que queremos es conectarnos a un ordenador por ssh en modo gráfico también lo podremos hacer. Es más simple pero también tienes menos posibilidades, o para hacer ciertas cosas tardas más incluso que haciéndolo por consola pero para las operaciones fáciles como administrar, editar un fichero también es posible hacerlo de esta manera.

Entraremos en Lugares -> Conectarse al servidor...

Elegiremos en el combo de arriba en lugar de FTP público, SSH y pondremos la IP o el nombre (en caso de anteriormente ya hayamos editado el fichero hosts) y así despues de teclear la contraseña y aceptar estaremos ya dentro del mismo.

Instalación del servidor SSH.

El cliente ya viene instalado por defecto, de modo que para instalar el servidor de SSH en nuestro sistema lo único que necesitas es instalar el paquete openssh-server. Puedes leer Añadir aplicaciones si no sabes como hacerlo.

Restringir el acceso SSH.

Para evitar que todos los usarios de la máquina estén accesibles por SSH tendremos que editar como root el fichero /etc/ssh/sshd_conf (o /etc/ssh/sshd_config), y añadir la línea AllowUsers y a continuación los usuarios que deseamos que se puedan conectar remotamente via SSH:

$ sudo gedit /etc/ssh/sshd_conf

o

$ sudo gedit /etc/ssh/sshd_config

Y añadimos la línea:

AllowUsers usuario1 usuario2 usuario3

Para que los cambios surtan efectos habrá que reiniciar el servidor:

$ sudo /etc/init.d/ssh restart

* Restarting OpenBSD Secure Shell server...

Si te ha gustado el artículo inscribete al feed clicando en la imagen más abajo para tenerte siempre actualizado sobre los nuevos contenidos del blog:

[homes] - directorios personales

Esta sección permite la compartición del directorio home de los usuarios, de forma que, dependiendo que usuario se haya autentificado en el sistema, Samba compartirá su directorio personal únicamente a él.

Los parámetros de esta sección se muestran a continuación:

#======================= Share Definitions =======================
# Un-comment the following (and tweak the other settings below to suit)
# to enable the default home directory shares. This will share each
# user's home directory as \\server\username
;[homes]
; comment = Home Directories
; browseable = no

Indica si este recurso aparecerá en la lista de recursos compartidos o no. En este caso, si se mostrará.

# By default, \\server\username shares can be connected to by anyone

# with access to the samba server. Un-comment the following parameter
# to make sure that only "username" can connect to \\server\username
; valid users = %S
# By default, the home directories are exported read-only. Change next
# parameter to 'yes' if you want to be able to write to them.
; writable = no

Esta opción permite escribir datos en los directorios home, si su valor fuese "no", los directorios home se compartirían como sólo lectura.

# File creation mask is set to 0600 for security reasons. If you want to
# create files with group=rw permissions, set next parameter to 0664.
; create mask = 0600

Máscara de creación de archivos, el valor de este parámetro indicará los permisos que tendrán los archivos de nueva creación.

# Directory creation mask is set to 0700 for security reasons. If you want to
# create dirs. with group=rw permissions, set next parameter to 0775.
; directory mask = 0700

Máscara de creación de directorios, el valor de este parámetro indicará los permisos que tendrán los directorios de nueva creación.

Los cambios que haremos será retirar el “;” de las instrucciones que se detallan y activar los atributos que listo
con los valores que indico:

[homes]

comment = Home Directories.
browseable = yes
writeable = yes
create mask = 0755
directory mask = 0755

Yo tengo preferencia por poner el atributo 755 ya que es el mas habitual para no tener problemas
el primer 7 = permitida la lectura, escritura, ejecución al dueño del archivo/fichero
el segundo valor 5 = permitida la lectura, ejecución al anónimos del archivo/fichero
el tercer valor 5 = permitida la lectura, ejecución al grupo del archivo/fichero.
Reiniciamos Samba y el pc windows y volvemos a acceder a la red esta vez veremos los siguientes iconos

Ahora hemos entrado como usuario tele podemos navegar por ftp homes y tele homes y tele son las carpetas que se han creado al realizar los cambios en los homes de usuario si intentamos acceder a home y www nos pedirá una nueva autentificación.

Buscando en internet información para realizar esta receta de Samba encontré una referencia a un entorno gráfico de configuración a través de un navegador Web paso a describir su instalación aunque tal como he dejado la configuración a mi me es suficiente, con lo cual, instale este interfaz pero no me he preocupado de estudiar sus posibilidades.

SWAT (Samba Web Administration Tool) es una herramienta que permite la configuración gráfica de . Samba

Para instalar Swat desde Synaptic debemos instalar 2 paquetes lanzamos el instalador de Synaptic y pinchado en el icono de buscar tecleamos 1º swat lo seleccionamos y luego netkit y lo seleccionamos en caso de querer hacerlo desde comandos sería sudo aptitude install samba swat netkit-inetd una vez tengamos instalado los 2 paquetes es necesario arrancar el demonio y establecer la contraseña de acceso ya que es una aplicación administrativa del sistema.

para arrancar la aplicación pasamos a modo consola y:

sudo update-inetd --enable 'swat'

para establecer la contraseña hay que ejecutar 2 comandos con el 1º no notaremos nada con el segundo ya nos pedirá la contraseña 2 veces, yo metí la misma contraseña que tengo asignada al usuario root.

sudo -s
passwd
Ya esta tenemos instalada la aplicación para acceder a SWAT vamos al navegador
y escribimos lo siguiente en la barra de direcciones http://localhost:901, SWAT pide un nombre de usuario y contraseña,
tecleamos root y nuestra contraseña habitual.

Llegados a este punto como ya he comentado antes ya tengo configurado Samba tal como lo necesito, por lo cual instale Swat como curiosidad pero no se si lo llegaré a usar, también si lo deseamos podemos instalar la aplicación Webmin es un programa que también a traves del navegador Web es capaz de gestionar todos los recursos Apache, Samba, Vsftp, DCHP, usuarios, etc. Webmin no se haya en los repositorios de Ubuntu.

Aspecto de la aplicación Swat

Como hemos visto el recurso Samba no esta de todo logrado en el aspecto de interface hay que realizar ciertas cosas a mano y es un sistema complejo de entender aquí doy lo básico para una red de unas pocas personas Samba también puede trabajar como dominio principal, creando grupos listas de usuarios cambio de contraseña automática y etc.. para mas información de Samba lo mejor recurrir ha Internet pero Ojo no he encontrado una receta que realmente aclaré todos los conceptos de una manera fácil de entender para los profanos.

Verificando el servidor FTP:

Vamos ha verificar el servidor FTP -->VSFTPD una vez instalado podemos verificar poniendo ftp://localhost o nuestra ip del equipo o bien el nombre de la computadora en el navegador WEB pero ojo no ponemos HTTP:// si no que esta vez tecleamos FTP:// vemos un directorio vació. ¿Que directorio? pues abrimos el Nautilus y vamos a //home/ftp este es el directorio que nos esta mostrando el navegador FTP, probemos a dejar un fichero que tengamos en nuestro directorio home de usuario, no podemos, ya que no tenemos permisos como Root. OJO no editemos los permisos de la carpeta ya que cambiaría el comportamiento del navegador con lo cual como root dejamos un fichero cualquiera MP3, imagen, y damos a refrescar al navegador para actualizar la conexión ahora veremos el fichero que hemos dejado como Root, y lo podemos abrir. Yo en principio revise los permisos de la carpeta y los deje como RWX para el usuario FTP R-X para grupo y otros con esto nos permite entrar y visualizar el contenido de las carpetas es importante el permiso X que nos permite abrir carpetas ya que si no nos daría error 550 failed to change directory.

VsFTPd es un servidor de archivos por FTP muy ligero y seguro. Es el recomendado por Debian y Ubuntu, tiene una configuración muy sencilla en un sólo fichero y se adapta muy bien a un servidor multihosting.

Por defecto la configuración en la distribución de Ubuntu es la siguiente:

Acceso de sólo lectura a los usuarios anónimos.

Los usuarios anónimos acceden a la carpeta /home/ftp

Los usuarios del sistema no pueden acceder a sus carpetas privadas.

El usuario anónimo podría -si no administramos bien los permisos del sistema- acceder a otras carpetas.

Vamos a proceder a modificar la configuración para que los usuarios del sistema puedan acceder al servidor autentificandose. Lo primero es estar trabajando en el sistema como root.

Lo segundo es poner a salvo la configuración por defecto de vsftpd que es este momento está correctamente instalado y lo mas seguro funcione, para ello en modo root navegamos a la carpeta /etc/ y buscamos el fichero vsftpd.conf y lo copiamos en la misma carpeta lo dejará con el nombre vsftp(copia).conf podemos renombrarlo y dejarlo como vsftpd(original).conf con lo cual dispondremos de una copia de seguridad original.

Seguidamente vamos a modificar el fichero vsftpd.conf para deshabilitar el usuario anónimo y habilitar los usuarios del sistema

Para ello realizar los siguientes cambios:

Poner write_enable en Yes descomentado la línea o sea quitando el símbolo #Poner local_enable en Yes descomentado la línea o sea quitando el símbolo #Poner local_umask en 022 descomentado la línea o sea quitando el símbolo #Poner anonymous_enable en NO añadiendo el símbolo #

Ahora siempre después de editar el archivo vsftpd.conf hay que realizar lo siguiente abrimos una consola en modo root y tecleamos cd //etc/init.d con lo cual nos situamos en el directorio init.d y teclemos la orden para rearrancar el servidor vsftpd con ./vsftpd restart esto hará un stop / start al servidor suponemos que ha respondido OK si no es así hemos metido la pata con lo cual toca reparar el archivo vsftpd.conf bién usando la copia integra que tenemos o bien editando y buscando el error ojo ya no sirve poner ftp://localhost ya que por defecto iniciaríamos una conexión anónima hay que poner ftp://nomberusuario:contraseña@localhost o bien usar un cliente ftp como filezilla.

Mas cosas tal como hemos visto al entrar como usuarios del sistema tendremos acceso a otros directorios del sistema fuera de nuestro directorio personal. Si se deseamos recluir a los usuarios a poder utilizar su propio directorio personal, puede hacerse fácilmente con el parámetro chroot_local_user que habilitará la función de chroot() opcionalmente podemos usar los parámetros chroot_list_enable y chroot_list_file para establecer la lista de usuarios que quedarán excluidos de la función chroot().

Descomentamos la opción chroot_local_user=YES

Reiniciamos nuevamente el servidor VSFTPD ahora cuando nos conectemos veremos que no podemos salir del directorio home del usuario con el cual nos hemos conectado.

Reiniciamos nuevamente el servidor VSFTPD ahora cuando nos conectemos veremos que no podemos salir del directorio home del usuario con el cual nos hemos conectado

Con esta configuración es suficiente para funcionar en un pequeño grupo de personas, de todos modos tal como he comentado antes si aún te quedan ganas de experimentar muestro un copiar pegar de un foro de Suse linux en el cual un tal Alejandro Lopez hernandez explica bastante bien lo de los ficheros Chroot .

Recorte del Manual de Alejandro Lopez hernandez 20/03/2005 yo no lo he probado ya que la configuración que anteriormente hemos realizado me es suficiente.

chroot_list_enable=NO/YES
chroot_list_file=/etc/vsftpd.chroot_list Esta directiva habilita la función “chroot” o jaulas de vsftpd. Con “chroot_list_enable” establecida a “YES”, vsftpd entonces busca un archivo “chroot_list_file”, del cual su ubicación es espeficicada en la siguiente línea. Cualquier usuario que este listado en el archivo /etc/vsftpd.chroot_list es automaticamente “enjaulado” a su directorio home. Esto prohibe al usuario ir a un directorio fuera de su directorio home FTP. Esto es muy útil en entornos FTP compartidos o como una politica de privacidad y seguridad.

userlist_enable=NO/YES
userlist_deny=NO/YES La opción “userlist_enable” le indica a vsftpd si consultará o no consultará 2 archivos: vsftpd.ftpusers y vsftpd.user_list. Si está opción es establecida a “YES”, los 2 archivos funcionan como una lista de usuarios que estan autorizados a conectarse al servidor FTP. Sin embargo, cuando es usada en combinación con la opción “userlist_deny=YES”, los 2 archivos funcionan como una lista de usuarios que NO están autorizados a conectarse al servidor FTP. Esta opción es muy útil para negar completamente el acceso FTP a usuarios criticos del sistema como “root”, “apache” o “www”. Una muy buena capa de seguridad para tu servidor FTP.

5) Los archivos de configuración vsftpd.ftpusers y vsftpd.user_list

Estos dos archivos se enlazan dentro de las opciones “userlist_enable” y “userlist_deny” en el archivo de configuración /etc/vsftpd/vsftpd.conf. Cuando la opción “userlist_enable” es establecida a “YES”, estos 2 archivos funcionan como una lista de usuarios que estan autorizados a conectarse al servidor FTP. Sin embargo, cuando se combina con la opción “userlist_deny=YES” estos 2 archivos funcionan como una lista de usuarios que NO están autorizados a conectarse al servidor FTP. Cuando la opción “userlist_deny” es utilizada, la naturaleza de la denegacion de servicio FTP que un usuario prohibido recibe difiere dependiendo de en cual de los 2 archivos este listado.

Si un usuario esta listado en el archivo “vsftpd.user_list” y la opción “userlist_deny” está activada, a los usuarios ni siquiera se les preguntará por una contraseña cuando intenten conectarse al servidor FTP. Son rechazados desde el principio.

Si un usuario es listado dentro de el archivo “vsftpd.ftpusers” y la opción “userlist_deny” esta activada, a los usuarios se les preguntará por una contraseña, pero nunca podrán iniciar sesión.

Verificando el servidor Mysql:

Seguramente si hemos seguido los pasos de la instalación ye tendremos instalado Mysql client y Mysql server de todos modos por curiosidad vamos a describir como se realizaría en modo terminal.

Para instalar MySQL, ejecute el siguiente comando en un terminal teniendo el CD de la distribución Ubuntu en el lector de CD:

sudo apt-get install mysql-server mysql-client

Cuando se complete la instalación, el servidor MySQL deberá iniciarse automáticamente. Puede ejecutar la siguiente orden en la línea de órdenes de una terminal para comprobar si se está funcionando el servidor MySQL:

sudo netstat -tap | grep mysql.

Sudo es el prefijo que hay que añadir cuando no estamos en modo Root para poder realizar tareas administrativas SU=superusuario nos pedira la contraseña Root cada 1 orden su introducida si estamos en modo Root no es necesario.

Cuando ejecute este comando, deberá ver la siguiente línea o algo similar:

tcp 0 0 localhost.localdomain:mysql *:* LISTEN -

Si el servidor no se está ejecutando correctamente, puede teclear la siguiente orden para arrancarlo:

sudo /etc/init.d/mysql restart

La contraseña del administrador no está establecida de forma predeterminada. Una vez que haya instalado MySQL, lo primero que debe hacer es establecer la contraseña del administrador de MySQL. Para ello, ejecute las siguientes órdenes:

sudo mysqladmin -u root -h localhost password “contraseñadeseada” nota: la palabra password debe estar precedida de la contraseña que vamos ha introducir yo la primera vez pensé que había que sustituir la palabra password por la contraseña pero no.

para ingresar en modo Shell de Mysql hay que teclear posteriormente: mysql -u root -p teclear enter y nos pedirá el password de Mysql tecleamos el passwor y entraremos en la shell mostrada por el texto mysql> ahora ya estamos en modo comando para salir pulsar exit.

para crear una base de datos tecleamos en la shell mysqladmind -u root -p create “Nombre de la base de datos”

Anotaciones varias

Puede cambiar el archivo /etc/mysql/my.cnf para configurar las opciones básicas — archivo de registro, número de puerto, etc. Diríjase al archivo /etc/mysql/my.cnf para más detalles.

Notas finales:

Si este documento os ha sido de utilidad y en este momento tenéis conexión a Internet agradecería que bien por Mail a gestor@z84.es o bien usando el formulario_comentario on line me hagáis llegar vuestra dirección y si incluis vuestro correo cada vez que este documento sufra una modificación se os comunicará por Mail.

Seria un favor aunque sea manera telegráfica, tosca, anónima uséis el formulario_comentario aunque sea para decir “me llamo Pedro lo encuentro útil, muy útil, cutre, muy cutre etc…….”

Verificando el servidor de Windows:

Desde un ordenador remoto Windows o linux con Samba-client podemos ver nuestro dominio Samba que hemos creado al instalar el paquete Samba, y con el, compartir carpetas y impresoras.

Antes de comenzar ha verificar Samba vamos ha crear unos recursos compartidos y algún usuario.

lo primero vamos al menú de Ubuntu sistema>configuración>gestión de usuarios y creamos un usuario por ejemplo tele, le asignamos una contraseña y listo ya tendremos los siguientes usuarios minimamente: el root que es el usuario por defecto del sistema y ya hemos habilitado al inicio de este documento , el que dimos al instalar Ubuntu por ejem administrador y el usuario tele que es el que acabamos de crear para mi Samba es un poco complejo por lo cual voy ha ir dando información a trozos para no colapsarnos con conceptos extraños y aplicarlos uno a uno.

Regla: Los usuarios Linux(Ubuntu) no son los mismos que los usuarios de Samba pero al parecer están relacionados de algún modo con lo cual para tener creado un usuario que pueda acceder a las carpetas compartidas en nuestro servidor hemos de crear un usuario Samba que coincida en nombre y contraseña con el usuario Linux por lo cual si en Linux tenemos : root, admistrador y tele como usuarios del sistema Linux en para Samba crearemos los mismos usuarios con las mismas contraseñas.

Para crear un usuario Samba en una consola como Root tecleamos:

smbpasswd -a root

nos pedirá la contraseña del usuario Root la tecleamos 2 veces

smbpasswd -a administrador

nos pedirá la contraseña del usuario administrador la tecleamos 2 veces

smbpasswd -a tele

nos pedirá la contraseña del usuario tele la tecleamos 2 veces

listo ya tenemos los tres usuarios de Samba que coinciden en nombre y contraseña con los usuarios de Linux.

Siguiente paso: con el nautilus nos situamos en el sistema de ficheros y marcamos la carpeta /var / “www”con el botón derecho seleccionamos compartir con Samba y le asignamos la propiedad de lectura, luego realizamos lo mismo con la carpeta / “home” y la carpeta /home/ “administrador”

ya tenemos 3 carpetas compartidas ahora podemos pasar a verificar Samba para reiniciar Samba en la carpeta:

en modo consola hay que realizar lo siguiente.

/etc/init.d tecleamos como root “./samba restart” listo veremos como se reinicia el servicio Samba no olvidar el “./” ya que es un scrip.

Ahora desde un ordenador en red vamos ha entorno de red y examinamos la red microsof veremos nuestro servidor Samba, lo cliqueamos y nos pedirá usuario y contraseña introducimos el nombre y contraseña de cualquier usuario y deberíamos poder acceder a los 3 recursos compartidos que hemos creado. En caso de no ver nuestro servidor usar la opción buscar usuarios o máquinas y teclear el nombre de nuestro servidor.

Veremos que al navegar por el contenido de las carpetas compartidas se producen a veces algunos retardos. no tengo ni idea de por que se producen.

Ahora examinemos como root el fichero de texto smb.conf ya que vamos a realizar cambios y para poder gravar las modificaciones hay que estar como Root, ya que es un archivo de sistema situado en /etc/samba/ al final del fichero veremos la lista de parámetros por recursos compartidos.

Antes de examinar el fichero smb.conf doy una lista de posibles parámetros y sus consecuencias:

guest ok = define si se permitirá el acceso a invitados valores yes o no

Public = es un equivalente a guest valores yes o no

browseable = Da permiso o no a mostrar el recurso en las listas de recursos. valores yes o no

writable = permiso de escritura en el directorio valores yes o no

valid users = Define quien puede acceder al recurso ejem usuario1, usuario2 o bien grupos @grupo1, @grupo2.

write list = define quien puede escribir en el directorio ejem usuario1, usuario2 o bien grupos @grupo1, @grupo2

admin users = Define quien accede como super usuario ejem usuario1, usuario2 o bien grupos @grupo1, @grupo2

directory mask = Define que permisos tendrán los subdirectorios que creemos en ese recurso.

create mask = Define que permisos tendrán los ficheros que creemos en ese recurso.

Ahora muestro en el cuadro de la derecha la parte del fichero donde se muestran los recursos compartidos y sus parámetros y el la lista de la izquierda como los vamos ha dejar configurados.

Fichero original aún sin modificar

[www]

path = /var/www

comment = carpeta web

available = yes

browseable = yes

public = yes

writable = yes

[home]

path = /home

comment = carpeta home del sistema

available = yes

browseable = yes

public = yes

writable = yes

[ftp]

path = /home/ftp

comment = carpeta ftp

available = yes

browseable = yes

public = yes

writable = yes

Fichero ya modificado

[www]

path = /var/www

comment = carpeta web

valid users = administrador, root <--Línea añadida

available = yes

browseable = yes

public = yes

writable = yes

directory mask = 0755 <--Línea añadida

create mask = 0755 <--Línea añadida

[home]

path = /home

comment = carpeta home del sistema

valid users = administrador, root <--Línea añadida

available = yes

browseable = yes

public = yes

writable = yes

directory mask = 0777 <--Línea añadida

create mask = 0777 <--Línea añadida

[ftp]

path = /home/ftp

comment = carpeta ftp

guest ok =yes <--Línea añadida

available = yes

browseable = yes

public = yes

writable = yes

ipod32_336x280_es.gif

Examinemos la lista de la dcha modificada; en [www] hemos añadido que solo puedan acceder al recurso los usuarios Samba administrador y root y que todo fichero que dejemos tenga los permisos de lectura y ejecución. Para la carpeta [home] lo mismo pero tendrán los permisos de lectura ejecución y escritura. Y en la carpeta [ftp] hemos aplicado la opción de acceso a los anónimos.

después de los cambios reiniciamos Samba /etc/init.d tecleamos como root “./samba restart”.listo volvemos a comprobar a los recursos despues de reiniciar nuestro pc en Windows para comenzar desde cero y procedemos ha verificar los recursos nuevamente.

Instalando los paquetes y servicios del servidor.

1º paso habilitar el usuario Root, del sistema, que por defecto en la distribución Ubuntu viene deshabilitado para que los usuarios noveles no realicen un estropicio. Para ello vamos ha Sistema>Administración>Usuarios y grupos, nos pedirá la contraseña del usuario que creamos en la instalación que es con el que actualmente estamos trabajando, la introducimos y nos mostrará la ventana “Usuarios y grupos” y veremos solo nuestro usuario creado.

Para mostrar los usuarios del sistema activamos la casilla de verificación [X]Mostrar todos los usuarios y grupos la ventana de usuarios se llenará, buscamos el usuario Root, lo seleccionamos y pulsamos en el botón propiedades nos mostrará las propiedades del usuario y la posibilidad de cambiar la contraseña, la tecleamos en las 2 cajas de texto y cerramos, listo ya tenemos controlada la contraseña del Root, pero aún falta una cosa el usuario Root tiene desactivado la opción de ejecutar entorno gráfico vamos ha solucionarlo.

Sistema>Administración>Ventana de entrada y nos mostrará la ventana de “preferencias de entrada” pulsamos en la ventana Seguridad y marcamos la casilla “permitir entrada local al administrador del sistema”

Con esto ya tenemos todo resuelto en cuanto al root.

2º Paso cargar las aplicaciones de servidor Apache+PHP+Mysql server+Mysql client, FTP y Samba para ello introducimos el CD de la instalación Ubuntu y vamos al menú Sistema>Administración>Gestor de paquetes Synaptic, se cargará la ventana del gestor de paquetes Synaptic y en la caja de texto con la barra de desplazamiento vertical seleccionamos:

World Wide Web la caja de la derecha nos mostrará los paquetes disponibles marcamos Apache2, libapache2-mod-php5, PHP5 nos dará mensajes de instalación de paquetes adicionales para completar las dependencias.

seguidamente seleccionamos Documentación y en la ventana de paquetes seleccionamos apache2-doc.

Y por ultimo en Varios-basados en texto seleccionamos los paquetes de samba y vsftpd también Mysql-server y Mysql-client y listo.

Si quisiéramos instalar un paquete del cual no sabemos el nombre exacto hay 2 maneras seleccionando Todo en la ventana de la izquierda y buscando por orden alfabético en la ventana de la Dcha el paquete o bien dando al botón buscar y introducir al menos 3 letras de la descripción del paquete nos hará una búsqueda de los paquete que contengan esas 3 letras anidadas en su nombre o descripción.

Pulsamos el botón aplicar y listo, comienza la instalación de los paquetes, después de la instalación nos mostrará una ventana informando que los cambios se han aplicado con éxito y procedemos a ver que los servidores están corriendo. vamos al menú: Sistema>Administración>Servicios

Veremos los servicios Apache2, FTP(vsftpd) y el servicio compartición de carpetas Samba que esta Ok, tal como muestra la imagen de la Izda

Verificando el servidor HTTP:

Ahora pasaremos a comprobar y realizar alguna configuración mínima en cada uno de los 3 servicios. Durante la instalación yo asigne una ip determinada al equipo y un nombre, la IP es 192.168.100.10 lo podemos ver en: Sistema>Administración>Red

veremos los interfaces de red seleccionamos y pulsamos propiedades veremos lo siguiente.

Vamos ha proceder a verificar el servidor Apache en el navegador local, abrimos el navegador Firefox en: Aplicaciones>Internet>Navegador

Web Firefox nos mostrará el documento local de inicio de Ubuntu nos ponemos en la barra de dirección y tecleamos http://localhost <--|

Nos mostrará la carpeta que por defecto se ha instalado conteniendo la documentación Apache ya tenemos verificado el servidor Web probemos ha introducir el nombre de nuestra máquina y debería funcionar, probemos ahora nuestra IP y el resultado será el mismo.

Si estamos conectados en red con otro ordenador como es mi caso compre un cable cruzado rj45 de varios metros y conecte ambas tarjetas de red y en mi caso el ordenador con el cual me conecto al servidor tiene una conexión Wifi a un router + la conexión que he realizado a través del rj45, o sea 2 conexiones de red, para ello tengo el Explorer 5 configurado de la siguiente manera en Herramientas > opciones de Internet > Conexiones > configuración lan tengo seleccionado “detectar la configuración automáticamente” y la opción de servidor proxi sin rellenar. y me funciona.

Ahora probamos desde el ordenador remoto en red con el nuestro tecleamos en el navegador http://192.168.100.10 que es la ip de nuestro servidor Web tambien probar con el nombre del dominio y nos debería mostrar lo mismo. Ya tenemos completamente verificado el servidor Apache2.

Nota de novato 1: Localhost y la dirección IP 127.1.1.1 son propias del ordenador que contiene el servidor no podemos usar estos enlaces desde un ordenador externo

Ficheros de configuración y permitir a los usuarios su WebSite.

¿Donde se encuentra el directorio que Apache nos muestra? pues vamos a verlo, abrimos el navegador de carpetas local Nautilus, y mediante el menú Lugares>Carpeta personal seleccionamos sistema de archivos en la ventana derecha y en la izquierda buscamos la carpeta var y luego WWW esta es la carpeta de inicio del navegador Apache2, todo lo que añadamos en la misma se mostrará a través del navegador HTTP, probemos a crear una carpeta ¡no podemos!, ¿por que? porque solo el root tiene acceso a las carpetas del sistema pero como lo hemos habilitado cambiemos de usuario, damos al botón de apagado o bien Sistema>Salir y seleccionamos la opción cambiar de usuario iniciamos una sesión como root y la contraseña que hayamos elegido, Ojo al realizar este paso tenemos la sesión anterior abierta.

Nota de novato 2: Linux es multi usuario podemos tener varias sesiones abiertas y conmutar entre ellas pulsando Alt+F7 es la 1º sesión que iniciemos Alt+F8 la segunda y así sucesivamente por debajo de Alt+F1 a Alt+F6 tenemos la posibilidad de abrir sesiones en modo texto muy utiles para trabajar en linea de comandos.

En la sesión de root probamos ha cambiar los permisos del directorio WWW pulsando el botón izquierdo del ratón y asignamos propiedades de lectura escritura y ejecución a usuarios y grupos, ahora si podemos crear carpetas todo lo que introduzcamos será visto a través del navegador.

Ficheros de configuración de apache cambian según la distribución de Linux normalmente suele ser httpd.conf en Ubuntu el fichero principal de configuración es apache2.conf es un poco lioso esto de los cambios de nombre según distribución y tambien la configuración de los parametros dista mucho de ser igual en todas las distribuciones.

en la de Unbuntu aunque el fichero principal es apache2.conf este llama a otros ficheros con la instrucción include. Ver listado de los includes sacado de apache2.conf

# Include module configuration:
Include /etc/apache2/mods-enabled/*.load
Include /etc/apache2/mods-enabled/*.conf
# Include all the user configurations:
Include /etc/apache2/httpd.conf
# Include ports listing
Include /etc/apache2/ports.conf
# Include generic snippets of statements
Include /etc/apache2/conf.d/[^.#]*

La parte que nos interesa es la siguiente:

# UserDir is now a module
#UserDir public_html
#UserDir disabled root

Nota de novato 3: siempre hay que salvar los ficheros de configuración que están correctamente instalados y funcionan, para ello en modo root navegamos a la carpeta /etc/ y buscamos el fichero apache2.conf y lo copiamos en la misma carpeta lo dejará con el nombre apache2(copia).conf podemos renombrarlo y dejarlo como apache2(original).conf con lo cual dispondremos de una copia de seguridad original.

Vamos a ir paso a paso si Apache ya esta funcionando ¿que pretendemos? pues a parte de la ruta /var/www que es la ruta general del dominio, permitir a los usuarios del sistema tener su propia Web Site esto se consigue con UserDir, hay varios parámetros para conseguir tener su propio directorio Web yo me decanto por el parametro que esta ya predefinido en Apache2.cof que es

“UserDir public_html” que quiere decir que si en el navegador tecleamos http://localhost/~usuariolinux Apache traducirá esta ruta por /home/usuariolinux/public_html con lo cual hemos de crear un directorio public_html dentro del directorio home del usuario. ¿como coño escribimos el símbolo “~”? pues tecleando Alt-Gr + la tecla 4 del teclado alfanumérico no pasará nada pero en el siguiente carácter tecleado ya aparecerá con el símbolo ~ por detrás, es un poco retorcido tener que emplear este caracter pero que le vamos a hacer, con lo cual descomentamos la línea quitando el simbolo # guardamos el documento y reiniciamos apache usando una consola o terminal.

Nota de novato 4: Ha partir de este momento tenemos que abrir una consola / terminal en modo texto para introducir comandos en modo texto hay 2 sistemas, uno abrir una consola en modo root iniciando una sesión como Root y otra empleando una consola de un usuario si privilegios añadiendo el prefijo sudo que indica que la instrucciónes que queremos ejecutar son como Root con lo cual teclearemos sudo comandoaejecutar y antes de lanzar el comando al sistema nos pedirá que nos indentifiquemos introduciendo la contraseña del Root.

Nos situamos en la ruta /etc/init.d que es donde normalmente están los scrip de arranque y tecleamos como root “./apache2 restart” listo veremos como se reinicia el servicio Apache no olvidar el “./” ya que es un scrip.

Nota de novato 5: si nunca nos hemos movido entre directorios en modo consola hay va el modo: con cd /etc/init.d nos situamos en el directorio init.d también podemos hacerlo en 2 veces cd /etc, cd init.d, vemos que el el 1º cd hemos puesto la “/” y en el segundo no la barra se pone para indicar que partimos de la raíz o para separar directorios y con cd .. retrocedemos un directorio ojo dejar un espacio siempre después de cd no como en MSDOS que no se dejaba.

En UserDir disabled podemos introducir una lista a continuación del comando con los usuarios a los cuales queremos negar que tengan Web Site, por mi parte lo dejo como esta.

ya podemos probar la nueva configuración:

Ahora vamos a avanzar un paso mas hablando de htaccess el fichero mágico del servidor apache, con el, en los servidores de internet podemos conseguir tener carpetas navegables como si estuviésemos inspeccionando un disco duro incluso proteger determinadas carpeta con contraseña esto se consigue poniendo un fichero llamado .htaccess característico del servidor Apache que es invisible para el navegante. En este caso desde el principio podemos observar que ya el Apache de Ubuntu viene configurado de este modo por defecto.

De todos modos las líneas que determinan en apache el comportamiento de los directorios de los usuarios y el acceso a los ficheros htaccess son las siguientes líneas:

#
# AllowOverride FileInfo AuthConfig Limit
# Options Indexes SymLinksIfOwnerMatch IncludesNoExec
#
AccessFileName .htaccess

Order allow,deny
Deny from all

Pienso que de momento no es necesario configurar con lo que hemos configurado es suficiente. Lo de Htaccess os lo dejo por si o queréis investigar.

Pues no he consegido un tutorial de uso de htaccess ver http://web.z84.es/publicaciones/tutorial_htaccess/tutorial_htaccess.html

Tam,biém podeís ver un tutorial de VirtualHost en esta Web ¿Que es Virtual Host? pues para los que no conozcan es la asignación de un nombre propio por ejemplo migoogle.micasa y que esl servidor sea capaz de contestar a esta instancia mostrando un directorio determinado. mas de Virtual Host en http://web.z84.es/publicaciones/virtual_host/receta_virtual_host.html .

TCP Wrapper ("Envolvedor de TCP") es un sistema de red ACL que trabaja en terminales y que se usa para filtrar el acceso de red a servicios de protocolos de Internet que corren en sistemas operativos (tipo UNIX), como ser Linux o BSD. Permite que las direcciones IP, los nombres de terminales y/o respuestas de consultas ident de las terminales o subredes sean usadas como tokens sobre los cuales filtrar para propósitos de control de acceso.

El código original fue escrito por Wietse Venema de la Universidad Tecnológica de Eindhoven, Países Bajos, entre los años 1990 y 1995. Desde el 1ro de junio de 2001, el programa es lanzado bajo su propia licencia tipo BSD.

El tarball incluye una biblioteca llamada libwrap que implementa la funcionalidad en sí. Inicialmente, solo aquellos servicios que se creaban a partir de cada conexión a un super servidor (como inetd) eran envueltos (de ahí su nombre) utilizando el programa 'tcpd'. Sin embargo, los demonios de servicio de red más comunes de hoy en día pueden ser enlazados contra libwrap en forma directa. Los demonios que operan sin crear descendientes de un super servidor usan esto, o un proceso único maneja conexiones múltiples. Caso contrario, solo el primer intento de conexión se chequearía contra sus ACLs.

Al compararse con las directivas de control de acceso de una terminal, que comúnmente se encuentran en los archivos de configuración de los demonios, TCP Wrappers tienen el beneficio de una reconfiguración de ACL en tiempo de ejecución (es decir, los servicios no necesitan ser cargados nuevamente o reiniciados) y de una aproximación genérica a la administración de redes.

Si bien fue escrito para proteger servicios de aceptación de TCP y UDP, también existen ejemplos de uso para filtrado de ciertos paquetes ICMP (tales como 'pingd' – el contestador de pedidos de pings del espacio de usuario).

En el punto 13.4 hablábamos de los servicios ofrecidos desde nuestra máquina; allí comentamos que cualquiera de ellos es una potencial puerta de entrada para un atacante, por lo que es muy recomendable cerrar todos los que no necesitemos; vimos un esquema todo o nada: u ofrecíamos un servicio a toda la red o lo denegábamos, pero no había término medio.

Hay una serie de servicios como telnet o ftp que habitualmente no vamos a poder cerrar, ya que los usuarios necesitarán conectar al servidor para trabajar en él o para transferir ficheros; en estos casos es peligroso permitir que cualquier máquina de Internet tenga la posibilidad de acceder a nuestros recursos, por lo que se suele utilizar un programa denominado TCP Wrappers ([Ven92]) para definir una serie de redes o máquinas autorizados a conectar con nosotros. Aquí veremos como instalar este software - en su versión 7.6 - y su configuración básica para que no todo el mundo pueda contactar con nosotros. Actualmente, cualquier administrador que desee un mínimo de seguridad ha de instalar TCP Wrappers en sus equipos; incluso algunos Unices como Linux o BSDI lo ofrecen por defecto al instalar el operativo. Cabe decir que la configuración del programa puede ser muy elaborada y con muchas opciones; aquí veremos la forma más básica, que suele ser automática mediante make install 22.2. Para configuraciones más avanzadas se recomienda consultar los ficheros de ayuda.

En nuestro caso vamos a instalar TCP Wrappers sobre una máquina Silicon Graphics corriendo IRIX 6.2:

llegona_(/) # uname -a
IRIX64 llegona 6.2 06101031 IP28
llegona_(/) #

No vamos a entrar aquí en como compilar el software (para ello se puede consultar el fichero README); asumiremos que ya lo tenemos compilado y el resultado está, por ejemplo, en el directorio /tmp/tcp_wrappers_7.6/. Tras compilar el software se habrán generado una serie de ficheros ejecutables que hemos de copiar a un destino definitivo, por ejemplo a /etc/usr/sbin/:

llegona_(/tmp/tcp_wrappers_7.6) # cp `find . -type f -perm -700` /usr/sbin/
llegona_(/tmp/tcp_wrappers_7.6) #

Una vez en su destino definitivo, hemos de modificar el fichero /etc/inetd.conf para indicarle a inetd que ha de utilizar el demonio tcpd (la parte más importante de TCP Wrappers) a la hora de servir peticiones; para ello, una entrada de la forma

telnet stream tcp nowait root /usr/etc/telnetd

se convertirá en una como

telnet stream tcp nowait root /usr/sbin/tcpd /usr/etc/telnetd

Como vemos, en lugar de que inetd ejecute directamente el demonio correspondiente a cada servicio, ejecuta el wrapper, y es éste el encargado de controlar la ejecución del demonio real.

Tras haber modificado convenientemente /etc/inetd.conf hemos de configurar los servicios que vamos a ofrecer a diferentes máquinas o redes; seguiremos una política restrictiva: todo lo no explícitamente permitido, está negado. Para ello, en el archivo /etc/hosts.allow indicamos que servicios ofrecemos y a dónde lo hacemos22.3, de la siguiente forma:
demonio: maquinas
Donde `demonio' es el nombre del demonio encargado de atender el servicio correspondiente
(sendmail, telnetd, fingerd...), y `maquinas' es la especificación de los hosts a los que les está permitida la conexión a cada servicio; se trata de una lista separada por espacios donde podemos incluir desde nombres de sistemas o direcciones IP hasta subdominios, pasando por palabras reservadas como ALL. Así, si por ejemplo queremos ofrecer todo a las máquinas .dsic.upv.es, telnet a andercheran.aiind.upv.es y luisvive.euiti.upv.es, y ftp a toda la UPV, tendremos un /etc/hosts.allow de la forma siguiente:

llegona_(/) # cat /etc/hosts.allow
ALL: .dsic.upv.es
telnetd: andercheran.aiind.upv.es luisvive.euiti.upv.es
ftpd: .upv.es
llegona_(/) #

Acabamos de configurar los sistemas con acceso a ciertos demonios; para indicar a TCP Wrappers que nuestros servicios no van a ser ofertados a nadie más, creamos el fichero /etc/hosts.deny y denegamos todo a todos:

llegona_(/) # cat /etc/hosts.deny
ALL: ALL
llegona_(/) #

Run with -[Ff] option to fix

Una vez hemos configurado todo, hemos de hacer que inetd relea su fichero de configuración enviándole la señal SIGHUP, por ejemplo con la orden killall -HUP inetd22.4. A partir de ese momento los cambios han tenido efecto; en función de nuestro /etc/syslog.conf, pero generalmente en archivos como /var/adm/SYSLOG o /var/adm/messages vamos a poder ver las conexiones aceptadas y las rehusadas:

Dec 2 02:16:47 llegona ftpd[18234]: refused connect from bill.microsoft.com
Dec 2 02:45:23 llegona telnetd[18234]: connect from corbella.dsic.upv.es

Cuando alguien desde una máquina que tiene permiso para acceder a cierto servicio conecte a él no notará nada raro, pero si lo hace desde un equipo no autorizado, la conexión se cerrará:

anita:~# telnet llegona.dsic.upv.es
Trying 158.42.49.37...
Connected to llegona.dsic.upv.es
Escape character is '^]'.
llegona login: Connection closed by foreign host.
anita:~#

Para corroborar la inseguridad de los sistemas Unix instalados tal y como se distribuyen, o mínimamente configurados, hemos hecho la prueba con uno de los sistemas considerados más seguros: Solaris, de la empresa Sun Microsystems, Inc.. Hemos instalado Solaris 7 sobre un PC, cerrado la mayoría de servicios ofrecidos (en /etc/inetd.conf), y controlado el acceso a otros (telnet, finger, ftp...) mediante TCP Wrappers: justo lo que la mayor parte de administradores harían antes de poner el sistema a funcionar. Tras estos pasos, hemos ejecutado el programa de auditoría automática Titan, que detecta problemas de seguridad en la máquina local (para más información sobre este software se puede consultar [FPA98]).

Instalación de Titan

Hemos elegido Titan justamente por ser uno de los programas más fácilmente instalables sobre SunOS o Solaris: al tratarse de un conjunto de shellscripts, el administrador no ha de preocuparse por ningún proceso de compilación (con los posibles errores que éste puede causar), ni conocer técnicas avanzadas de seguridad para poder utilizarlo (como otros programas que presentan una multitud de opciones diferentes que se pueden combinar entre ellas, de forma que quien los quiera utilizar debe conocer bastante bien ciertos términos de Unix y de la seguridad, que no suelen ser triviales). Tanto la instalación de Titan como su ejecución son muy sencillos.
Para instalar Titan, una vez desempaquetado el fichero, hemos de ejecutar simplemente
Titan-Config, con la opción -i (la opción -d desinstala el software. El programa de instalación nos preguntará si deseamos hacer copias de seguridad de los ficheros que se modifiquen al ejecutar Titan; por nuestra seguridad, podemos decirle que sí (y):

anita:/export/home/toni/Security/Tools# gzip -d Titan,v3.0.FCS.tar.gz
anita:/export/home/toni/Security/Tools# tar xvf Titan,v3.0.FCS.tar
anita:/export/home/toni/Security/Tools# cd Titan,v3.0.FCS
anita:/export/home/toni/Security/Tools/Titan,v3.0.FCS# ./Titan-Config -i
checking for dependencies...
finding out where we are...
we are in '/export/home/toni/Security/Tools/Titan,v3.0.FCS'

checking out your system...
this system runs: SunOS-5.7-i86pc
we will be using: sol2x86

setting up links...
removing old links...
linking bin into path...
linking lib into path...
linking logs into path...
linking src into path...
linking tmp into path...
linking done.
cleaning up is_root, sanity_check, Titan...
pulling in local Titan script...
Run Titan utilites with 'Titan -[v,f,i]' after reading the Docs...
OR
Run Titan using a config file. (Titan -c sample.Server) after reading the Docs
Titan can backup all of the files it modifies; This is recommended
proceed? y/n: y
Okay... Checking for backup program...
Found backtit.sh - Backing up system files now... This might take a while..
Creating backup dir in : /export/home/toni/Security/Tools/Titan,v3.0.FCS/\
arch/sol2sun4/bin/Backup//1013990418
Generating listings.....
Calculating and backing up files now...................................\
............ Done!!
...
...
Saved off 44 files to: /export/home/toni/Security/Tools/Titan,v3.0.FCS/\
arch/sol2sun4/bin/Backup//1013990418
See details in savelist: /export/home/toni/Security/Tools/Titan,v3.0.FCS/\
arch/sol2sun4/bin/Backup//1013990418/../SaveList.1013990418
Restore by running /export/home/toni/Security/Tools/Titan,v3.0.FCS/\
arch/sol2sun4/bin/lib/untit.sh -[g,r]
anita:/export/home/toni/Security/Tools/Titan,v3.0.FCS#

Una vez instalado Titan (todo a partir del directorio actual, no genera ficheros en ningún otro lugar de nuestros sistemas de archivos) podemos ejecutar ya el programa de auditoría, con la opción -v para que no realice ningún cambio en nuestro sistema, sino que simplemente se limite a informarnos de los posibles problemas de seguridad que podemos tener; si deseamos ver el funcionamiento de cada uno de los shellscripts invocados por Titan, podemos utilizar la opción -i, y si lo que queremos es solucionar los problemas detectados, la opción -f (cuidado si hacemos esto, la política de seguridad de Titan es tan estricta que podemos dejar al sistema sólamente utilizable por el root).

Ejecución de Titan
En nuestro caso, queremos que Titan nos informe de los problemas de seguridad que detecte, pero que no los solucione él:

anita:/export/home/toni/Security/Tools/Titan,v3.0.FCS# ./Titan –v _____________________________________________________
*=*=*=*=* Running modules/add-umask.sh now.....
Output to ../logs/modules/add-umask.sh.V.042506
-----------------------------------------------------
No umask file /etc/init.d/umask.sh found

_____________________________________________________
*=*=*=*=* Running modules/adjust-arp-timers.sh now.....
Output to ../logs/modules/adjust-arp-timers.sh.V.042506
-----------------------------------------------------

Checking for ARP timers in /etc/rc2.d/S69inet

ARP timers are not set - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/adjust.syn-timeout.sh now.....
Output to ../logs/modules/adjust.syn-timeout.sh.V.042506
-----------------------------------------------------
ERROR - This script is Only needed on Solaris 2.4 and older
please see Sun's patch (Patch 103582-11 currently) for a better fix

_____________________________________________________
*=*=*=*=* Running modules/automount.sh now.....
Output to ../logs/modules/automount.sh.V.042506
-----------------------------------------------------
File /etc/rc2.d/S74autofs exists...
Automounter =
/usr/lib/autofs/automountd /usr/sbin/automount /usr/bin/pkill - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/create-issue.sh now.....
Output to ../logs/modules/create-issue.sh.V.042506
-----------------------------------------------------
Cannot read /etc/issue - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/decode.sh now.....
Output to ../logs/modules/decode.sh.V.042506
-----------------------------------------------------
Decode disabled - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/disable-L1-A.sh now.....
Output to ../logs/modules/disable-L1-A.sh.V.042506
-----------------------------------------------------
./modules/disable-L1-A.sh: ./sanity_check: No such file or directory

_____________________________________________________
*=*=*=*=* Running modules/disable-NFS.bind.sh now.....
Output to ../logs/modules/disable-NFS.bind.sh.V.042506
-----------------------------------------------------
Verifying port settings using ndd
privileged port definition is currently set to 1024

You should run disable-NFS.bind.sh with the -F option (port=1024)

_____________________________________________________
*=*=*=*=* Running modules/disable-accounts.sh now.....
Output to ../logs/modules/disable-accounts.sh.V.042506
-----------------------------------------------------
Checking 11 Users....
Checking that shell set to noshell for:
daemon bin adm lp uucp nuucp listen nobody noaccess nobody4 ppp
Verify shell status....

daemon shell = - FAILS CHECK
bin shell = - FAILS CHECK
adm shell = - FAILS CHECK
lp shell = - FAILS CHECK
uucp shell = - FAILS CHECK
nuucp shell = /usr/lib/uucp/uucico - FAILS CHECK
listen shell = - FAILS CHECK
nobody shell = - FAILS CHECK
noaccess shell = - FAILS CHECK
nobody4 shell = - FAILS CHECK
ppp shell = /usr/sbin/pppls - FAILS CHECK

11 Users Not Secured Out Of 11

_____________________________________________________
*=*=*=*=* Running modules/disable-core.sh now.....
Output to ../logs/modules/disable-core.sh.V.042506
-----------------------------------------------------
Core dump size has not been set: FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/disable-ping-echo.sh now.....
Output to ../logs/modules/disable-ping-echo.sh.V.042506
-----------------------------------------------------
Ping echo response allowed - FAILED CHECK
Run ./modules/disable-ping-echo.sh with -[Ff] to fix...

_____________________________________________________
*=*=*=*=* Running modules/disable_ip_holes.sh now.....
Output to ../logs/modules/disable_ip_holes.sh.V.042506
-----------------------------------------------------
Checking ip_forwarding...
ip_forwarding disabled - PASSES CHECK
Checking ip_forward_src_routed...
ip_forward_src_routed disabled - PASSES CHECK
Checking ip_forward_directed_broadcasts...
ip_forward_directed_broadcasts disabled - PASSES CHECK
Checking ip_ignore_redirect...
ip_ignore_redirect enabled - PASSES CHECK
Checking ip_strict_dst_multihoming...
ip_strict_dst_multihoming enabled - PASSES CHECK
System configured as 'notrouter' - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/dmi-2.6.sh now.....
Output to ../logs/modules/dmi-2.6.sh.V.042506
-----------------------------------------------------
ERROR - This script is Only supported on Solaris 2.6 and newer,
please use one of the other scripts for your OS

_____________________________________________________
*=*=*=*=* Running modules/eeprom.sh now.....
Output to ../logs/modules/eeprom.sh.V.042506
-----------------------------------------------------
Architecture = i86pc
Eeprom security-mode not supported on this host

_____________________________________________________
*=*=*=*=* Running modules/file-own.sh now.....
Output to ../logs/modules/file-own.sh.V.042506
-----------------------------------------------------
Checking /usr file ownership
Found 25345 files in /usr that should be root owned
Checking /sbin file ownership
Found 13 files in /sbin that should be root owned
Checking /usr group permissions
Found 0 files in /usr that should be set group g-w
Checking /sbin group permissions
Found 0 files in /sbin that should be set group g-w
Checking /etc group permissions
Found 0 files in /etc that should be set group g-w
Checking /opt group permissions
Found 0 files in /opt that should be set group g-w

_____________________________________________________
*=*=*=*=* Running modules/fix-cronpath.sh now.....
Output to ../logs/modules/fix-cronpath.sh.V.042506
-----------------------------------------------------
File /var/spool/cron/crontabs/root exists; continuing
/etc is not writable by world - PASSES CHECK.
/etc is not writeable by group - PASSES CHECK.
/etc/cron.d is not writable by world - PASSES CHECK.
/etc/cron.d is not writeable by group - PASSES CHECK.
/usr is not writable by world - PASSES CHECK.
drwxrwxr-x 32 root 1024 Oct 8 00:58 /usr
/usr is writeable by group - FAILS CHECK
/usr/sbin is not writable by world - PASSES CHECK.
drwxrwxr-x 5 root 4608 Sep 24 01:32 /usr/sbin
/usr/sbin is writeable by group - FAILS CHECK
/usr/lib is not writable by world - PASSES CHECK.
drwxrwxr-x 42 root 10240 Oct 8 00:55 /usr/lib
/usr/lib is writeable by group - FAILS CHECK
/usr/lib/fs is not writable by world - PASSES CHECK.
drwxrwxr-x 13 root 512 Sep 23 18:33 /usr/lib/fs
/usr/lib/fs is writeable by group - FAILS CHECK
/usr/lib/fs/nfs is not writable by world - PASSES CHECK.
/usr/lib/fs/nfs is not writeable by group - PASSES CHECK.
/usr/bin is not writable by world - PASSES CHECK.
drwxrwxr-x 3 root 7680 Oct 8 00:52 /usr/bin
/usr/bin is writeable by group - FAILS CHECK
/etc/cron.d/logchecker ownership should be changed to root
/usr/lib/newsyslog ownership should be changed to root
/usr/bin/rdate ownership should be changed to root
/usr/sbin/rtc ownership should be changed to root
No cron.allow file - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/fix-modes.sh now.....
Output to ../logs/modules/fix-modes.sh.V.042506
-----------------------------------------------------
Only supported on Solaris 2.2 thru 2.6

_____________________________________________________
*=*=*=*=* Running modules/fix-stack.sh now.....
Output to ../logs/modules/fix-stack.sh.V.042506
-----------------------------------------------------
ERROR - This script is Only known to work on Solaris 2.5.[0-5]

_____________________________________________________
*=*=*=*=* Running modules/fix-stack.sol2.6.sh now.....
Output to ../logs/modules/fix-stack.sol2.6.sh.V.042506
-----------------------------------------------------
Stack Protection not currently set - Run fix-stack.sol2.6.sh -F

_____________________________________________________
*=*=*=*=* Running modules/ftpusers.sh now.....
Output to ../logs/modules/ftpusers.sh.V.042506
-----------------------------------------------------
No /etc/ftpusers file in place...
Should contain at least:

root
daemon
sys
bin
adm
lp
smtp
uucp
nuucp
listen
nobody
noaccess
news
ingres
audit
admin
sync
nobody4

Please Run with '-F/f' to Fix - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/hosts.equiv.sh now.....
Output to ../logs/modules/hosts.equiv.sh.V.042506
-----------------------------------------------------
No /etc/hosts.equiv - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/inetd.sh now.....
Output to ../logs/modules/inetd.sh.V.042506
-----------------------------------------------------
File /etc/inet/inetd.conf exists - Checking...
name Closed - PASSES CHECK
exec Closed - PASSES CHECK
comsat Closed - PASSES CHECK
talk Open - FAILS CHECK
uucp Closed - PASSES CHECK
smtp Closed - PASSES CHECK
tftp Closed - PASSES CHECK
finger Open - FAILS CHECK
systat Closed - PASSES CHECK
netstat Closed - PASSES CHECK
rquotad Closed - PASSES CHECK
rusersd Closed - PASSES CHECK
sprayd Closed - PASSES CHECK
walld Closed - PASSES CHECK
rexd Closed - PASSES CHECK
shell Closed - PASSES CHECK
login Closed - PASSES CHECK
exec Closed - PASSES CHECK
comsat Closed - PASSES CHECK
time Closed - PASSES CHECK
echo Closed - PASSES CHECK
discard Closed - PASSES CHECK
daytime Closed - PASSES CHECK
chargen Closed - PASSES CHECK
100087 Closed - PASSES CHECK
rwalld Closed - PASSES CHECK
rstatd Closed - PASSES CHECK
100068 Closed - PASSES CHECK
100083 Closed - PASSES CHECK
100221 Closed - PASSES CHECK
fs Closed - PASSES CHECK
ufsd Closed - PASSES CHECK
100232 Closed - PASSES CHECK
100235 Closed - PASSES CHECK
536870916 Closed - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/keyserv.sh now.....
Output to ../logs/modules/keyserv.sh.V.042506
-----------------------------------------------------
In /etc/rc2.d/S71rpc keyserv ; user nobody enabled - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/log-tcp.sh now.....
Output to ../logs/modules/log-tcp.sh.V.042506
-----------------------------------------------------

_____________________________________________________
*=*=*=*=* Running modules/loginlog.sh now.....
Output to ../logs/modules/loginlog.sh.V.042506
-----------------------------------------------------
No /var/adm/loginlog file - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/lpsched.sh now.....
Output to ../logs/modules/lpsched.sh.V.042506
-----------------------------------------------------
In /etc/rc2.d/S80lp lpsched is enabled - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/nfs-portmon.sh now.....
Output to ../logs/modules/nfs-portmon.sh.V.042506
-----------------------------------------------------
NFS port monitor disabled - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/nsswitch.sh now.....
Output to ../logs/modules/nsswitch.sh.V.042506
-----------------------------------------------------
passwd -> files - PASSES CHECK
group -> files - PASSES CHECK
hosts -> files - PASSES CHECK
networks -> files - PASSES CHECK
protocols -> files - PASSES CHECK
rpc -> files - PASSES CHECK
ethers -> files - PASSES CHECK
netmasks -> files - PASSES CHECK
bootparams -> files - PASSES CHECK
publickey -> files - PASSES CHECK
netgroup -> files - PASSES CHECK
automount -> files - PASSES CHECK
aliases -> files - PASSES CHECK
services -> files - PASSES CHECK
sendmailvars -> files - PASSES CHECK
15 of 15 entries set to files as default - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/nuke-sendmail.sh now.....
Output to ../logs/modules/nuke-sendmail.sh.V.042506
-----------------------------------------------------
Sendmail is enabled in /etc/rc2.d/S88sendmail - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/pam-rhosts-2.6.sh now.....
Output to ../logs/modules/pam-rhosts-2.6.sh.V.042506
-----------------------------------------------------
PAM allows rhosts for rlogin : FAILS CHECK
PAM allows rhosts for rsh : FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/passwd.sh now.....
Output to ../logs/modules/passwd.sh.V.042506
-----------------------------------------------------
All accounts have passwords - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/powerd.sh now.....
Output to ../logs/modules/powerd.sh.V.042506
-----------------------------------------------------
Power management not set to be run by root - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/psfix.sh now.....
Output to ../logs/modules/psfix.sh.V.042506
-----------------------------------------------------
Could not find /etc/rc3.d/S79tmpfix - FAILS CHECK
Run with -[Ff] option to fix

_____________________________________________________
*=*=*=*=* Running modules/rhosts.sh now.....
Output to ../logs/modules/rhosts.sh.V.042506
-----------------------------------------------------
Running against /etc/passwd...

_____________________________________________________
*=*=*=*=* Running modules/rootchk.sh now.....
Output to ../logs/modules/rootchk.sh.V.042506
-----------------------------------------------------
/.login - Clean of . - PASSES CHECK
/etc/.login - Clean of . - PASSES CHECK
/etc/default/login - Clean of . - PASSES CHECK
/.cshrc - Clean of . - PASSES CHECK
/etc/skel/local.cshrc - Contains . - FAILS CHECK
set path=(/bin /usr/bin /usr/ucb /etc .)
/etc/skel/local.login - Clean of . - PASSES CHECK
/etc/skel/local.profile - Clean of . - PASSES CHECK
/.profile - Clean of . - PASSES CHECK
/etc/profile - Clean of . - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/routed.sh now.....
Output to ../logs/modules/routed.sh.V.042506
-----------------------------------------------------

The route daemon advertises routes - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/sendmail.sh now.....
Output to ../logs/modules/sendmail.sh.V.042506
-----------------------------------------------------
No sendmail.cf.titan2 exists - FAILS CHECK
Run with -[Ff] option to fix.
Checking for smrsh
smrsh not found in /sbin - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/smtp-banner.sh now.....
Output to ../logs/modules/smtp-banner.sh.V.042506
-----------------------------------------------------
No /etc/mail/sendmail.cf exists - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/smtpbanner-8.8.sh now.....
Output to ../logs/modules/smtpbanner-8.8.sh.V.042506
-----------------------------------------------------
ERROR - This script is Only supported on patched Solaris 2.6 and newer,
please use one of the other scripts for your OS

_____________________________________________________
*=*=*=*=* Running modules/snmpdx-2.6.sh now.....
Output to ../logs/modules/snmpdx-2.6.sh.V.042506
-----------------------------------------------------
ERROR - This script is Only supported on Solaris 2.6 and newer,
please use one of the other scripts for your OS

_____________________________________________________
*=*=*=*=* Running modules/syslog.sh now.....
Output to ../logs/modules/syslog.sh.V.042506
-----------------------------------------------------
File /etc/syslog.conf exists checking contents....
Syslog auth notice messages disabled - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/tcp-sequence.sh now.....
Output to ../logs/modules/tcp-sequence.sh.V.042506
-----------------------------------------------------
TCP_STRONG_ISS=1
/etc/default/inetinit - has the system default . - FAILS CHECK

_____________________________________________________
*=*=*=*=* Running modules/userumask.sh now.....
Output to ../logs/modules/userumask.sh.V.042506
-----------------------------------------------------
Checking for umask 022 in
/etc/.login
/etc/default/login
/etc/profile
/etc/skel/local.cshrc
/etc/skel/local.login
/etc/skel/local.profile

Umask value other than 022 in /etc/.login - FAILS CHECK
Umask value other than 022 in /etc/.login - FAILS CHECK
Umask value 022 in /etc/profile - PASSES CHECK
Umask value 022 in /etc/skel/local.cshrc - PASSES CHECK
Umask value other than 022 in /etc/skel/local.login - FAILS CHECK
Umask value other than 022 in /etc/skel/local.profile - FAILS CHECK

UMASK value 022 in /etc/default/login - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/utmp.sh now.....
Output to ../logs/modules/utmp.sh.V.042506
-----------------------------------------------------
File utmp permissions o-w - PASSES CHECK
File utmp permissions o-w - PASSES CHECK

_____________________________________________________
*=*=*=*=* Running modules/vold.sh now.....
Output to ../logs/modules/vold.sh.V.042506
-----------------------------------------------------

File /etc/rc2.d/S92volmgt and /usr/sbin/vold exists - FAILS CHECK

Run with -[Ff] option to fix

_____________________________________________________
*=*=*=*=* Running modules/ziplock.sh now.....
Output to ../logs/modules/ziplock.sh.V.042506
-----------------------------------------------------

Unfortunately this is a FIX ONLY utility.....
As noted in the Introduction statement it may break functionality
for all non-root users if run -F

The list of files is as follows and may be manually modified
by editing this script and inserting/commenting out as you
like. Just make sure you know what it is you are changing:

The list of binaries that would be modified is:

/usr/bin/at
/usr/kvm/eeprom
/sbin/su
/usr/bin/atq
/usr/bin/atrm
/usr/bin/chkey
/usr/bin/crontab
/usr/bin/eject
/usr/bin/fdformat
/usr/bin/newgrp
/usr/bin/ps
/usr/bin/rcp
/usr/bin/rdist
/usr/bin/rlogin
/sbin/sulogin
/usr/bin/login
/usr/bin/rsh
/usr/bin/su
/usr/bin/tip
/usr/bin/uptime
/usr/bin/yppasswd
/usr/bin/w
/usr/bin/ct
/usr/bin/cu
/usr/bin/uucp
/usr/bin/uuglist
/usr/bin/uuname
/usr/bin/uustat
/usr/bin/uux
/usr/lib/exrecover
/usr/lib/fs/ufs/ufsdump
/usr/lib/fs/ufs/ufsrestore
/usr/lib/pt_chmod
/usr/lib/sendmail.mx
/usr/lib/acct/accton
/usr/sbin/allocate
/usr/sbin/mkdevalloc
/usr/sbin/mkdevmaps
/usr/sbin/ping
/usr/sbin/sacadm
/usr/sbin/static/rcp
/usr/sbin/whodo
/usr/sbin/deallocate
/usr/sbin/list_devices
/usr/openwin/bin/xlock
/usr/openwin/bin/xdm
/usr/openwin/lib/mkcookie
/usr/ucb/ps
/usr/vmsys/bin/chkperm
/usr/bin/passwd
/usr/bin/csh
/etc/lp/alerts/printer
/usr/kvm/crash
/usr/kvm/eeprom
/usr/bin/netstat
/usr/bin/nfsstat
/usr/bin/write
/usr/bin/ipcs
/usr/sbin/arp
/usr/sbin/prtconf
/usr/sbin/swap
/usr/sbin/sysdef
/usr/sbin/wall
/usr/sbin/dmesg
/usr/openwin/bin/Xsun
/usr/openwin/bin/wsinfo
/usr/openwin/bin/mailtool
/usr/openwin/bin/xload
/usr/openwin/bin/kcms_calibrate
/usr/openwin/bin/kcms_configure
/usr/openwin/bin/kcms_server
/var/adm/messages
/var/log/syslog
/var/adm/pacct
anita:/export/home/toni/Security/Tools/Titan,v3.0.FCS#

Mirando por encima el resultado ofrecido por Titan, vemos que ha detectado <casi 50 posibles problemas! (cada mensaje FAILS CHECK denota una alarma, mientras que cada mensaje PASSES CHECK denota un test satisfactorio).

A la vista de estos resultados, y teniendo en cuenta que hemos utilizado una versión más o menos moderna de Solaris (la versión 7 10/98, si hubiéramos comprobado una versión de Solaris o SunOS más antigua habríamos detectado seguramente muchos más problemas), parece claro que un sistema Unix instalado tal y como se distribuye, o con una configuración de seguridad mínima -nuestro caso-, representa un grave problema ya no sólo para la máquina en cuestión, sino para toda la red en la que trabaja. Por tanto, el uso de cualquier herramienta que nos ayude a solucionar, o al menos a localizar problemas, va a ser útil.