NFS

Compartir archivos por la red es hoy en dia una tarea trivial; tanto, que incluso en GNU/Linux disponemos de gran variedad de opciones, cada una a medida de las diferentes necesidades.

En esta oportunidad voy a hablar sobre una de ellas NFS, uno de mis tantos pendientes en el Blog y que al fin tengo oportunidad de saldar gracias al día a dia del trabajo. En cualquier caso, de manera sencilla podemos decir que NFS es:

"es un protocolo de nivel de aplicación, según el Modelo OSI. Es utilizado para sistemas de archivos distribuido en un entorno de red de computadoras de área local. Posibilita que distintos sistemas conectados a una misma red accedan a ficheros remotos como si se tratara de locales. Originalmente fue desarrollado en 1984 por Sun Microsystems, con el objetivo de que sea independiente de la máquina, el sistema operativo y el protocolo de transporte, esto fue posible gracias a que está implementado sobre los protocolos XDR (presentación) y ONC RPC (sesión).1 El protocolo NFS está incluido por defecto en los Sistemas Operativos UNIX y la mayoría de distribuciones Linux. "

Wikipedia.

Existen tres versiones de NFS que se utilizan hoy en día:

• NFSv2: Es la versión más antigua y mejor soportada.

• NFSv3: Tiene más características que NFSv2, como el manejo de archivos de tamaño variable y mejores informes de errores. Sólo es parcialmente compatible con los clientes para NFSv2.

• NFSv4: Es la versión más moderna, y, entre otras cosas, incluye soporte para seguridad a través de Kerberos, soporte para ACL y utiliza operaciones con descripción del estado.

En general, hay serias consideraciones que debemos realizar al momento de optar por esta solución, sobre todo en lo relacionado con la seguridad (no voy a entrar en detalles sobre esto en el articulo). En todo caso para aquellos que ya han decidido ir adelante con la solución veamos el proceso de Setup de NFS.

Equipamento Necesario:

En la mayoria de las distribuciones linux, el paquete nfs-utils (el paquete necesario para instalar tanto el cliente como el servidor NFS) viene incluido por default, pero en caso de no ser así simplemente debemos instalarlo con nuestro manejador de paquete. En mi caso:

# yum install nfs-utils

Alternativamente, si son de las personas que prefieren realizar todo por entorno gráfico, seguramente les gustara instalar:

# yum install system-config-nfs

Con esta aplicación pueden ejecutar de manera grafica cada uno de los pasos que voy a comentar aca (la configuración por esta utilidad la dejare fuera del articulo).

Definir los puertos:

En entornos RHEL es necesario definir los puertos que utilizara NFS, debido a que el firewall es incapaz de abrir dinámicamente los puertos aleatorios que de un modo predeterminado utiliza este.

Para esto, lo que debemos es editar el archivo /etc/sysconfig/nfs, habilitando o modificando los siguientes parametros:

RQUOTAD_PORT=875
LOCKD_TCPPORT=32803
LOCKD_UDPPORT=32769
MOUNTD_PORT=892
STATD_PORT=662

* Este paso lo podemos omitir en caso de que vallamos a ejecutar NFS sin Firewall en una red local.

Iniciar NFS:

NFS requiere los servicios rpcbind y nfslock para ejecutarse, por lo tanto estos deben estar activos y funcionando:

# service rpcbind start

# service nfslock start

Para iniciar nfs:

# service nfs start

Para evitar ejecutar estos pasos cada vez que se inicie el equipo y hacer que el sistema autoinicie los servicios ejecutamos:

# chkconfig nfs on

# chkconfig rpcbind on

# chkconfig nfslock on

Modificando host permitidos y denegados:

Con el objeto de hacer el servicio un poco mas seguro, es posible configurar una lista de host permitidos y denegados; de esta manera no todos en la red pueden acceder a nuestro recurso compartido. Para hacer esto es necesario que:

Editar el archivo /etc/hosts.deny y añadir el siguiente contenido:

portmap: ALL
lockd: ALL
mountd: ALL
rquotad: ALL
statd: ALL

Posteriormente, vamos a modificar /etc/hosts.allow para de esta manera indicar cuales hosts tendrán permitida la conexión:

portmap: 192.168.70.0/25, 172.16.1.0/28, 10.0.1.0/29
lockd: 192.168.70.0/25, 172.16.1.0/28, 10.0.1.0/29
mountd: 192.168.70.0/25, 172.16.1.0/28, 10.0.1.0/29
rquotad: 192.168.70.0/25, 172.16.1.0/28, 10.0.1.0/29
statd: 192.168.70.0/25, 172.16.1.0/28, 10.0.1.0/29

* Esto asumiendo que se permitirá acceso a las redes 192.168.70.0/25, 172.16.1.0/28 y 10.0.1.0/29 (se debe personalizar en base a nuestras necesidades).

Modificaciones en el Firewall:

Para servidores de NFSv4, en realidad sólo es necesario abrir en el muro cortafuegos el puerto 2049/TCP (nfs), pues es esta versión dejó de depender del servicio de mapa de puertos (portmap). Sin embargo, para poder trabajar con compatibilidad para NFSv2 y NFSv3, es necesario abrir los puertos 111/UDP, 111/TCP, 662/TCP, 662/UDP, 875/TCP, 875/UDP, 892/TCP, 892/UDP, 2029/TCP, 2049/UDP, 32803/TCP y 32769/UDP. Los puertos que se abran para los servicios lockd, mountd, rquotad y statd deben corresponder con los mismo puertos definidos el archivo /etc/sysconfig/nfs.

Para aplicar estos cambios de forma definitiva modificamos el archivo  /etc/sysconfig/iptables asi:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 2049 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 662 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 662 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 875 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 875 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 892 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 892 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 32803 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 32769 -j ACCEPT

Finalmente, para que todo surja efecto reiniciamos las reglas iptables:

# service iptables restart

Exportando:

NFS funciona simplemente agregando los recursos a compartir y sus reglas en el archivo /etc/exports. Este archivo tiene una estructura simple, pero rigida:

/directorio/a/compartir  EquiposQueConectaranAlRecurso(Reglas)

Podemos obtener un buen listado de ejemplos acá.

Montando el filesystem en el cliente:

Para montar el sistema de archivos NFS se emplea el comando mount:

# mount -t nfs servidor:/directorio /punto/de/montaje/local

Para hacer permanente este punto editamos el /etc/fstab agregando una entrada así:

servidor:/directorio   /punto/montaje   nfs4   opciones  0 0

SELinux

La verdad, no voy a entrar en polemica alguna sobre SELinux, por ahora; solo voy a comentar como saber el estatus de SELinux en nuestro RHEL.

El comando sestatus nos retorna la información básica del SELinux, si esta siendo usado y las politicas:

Adicionalmente, podemos conocer el estado del SELinux, con el comando getenforce, el cual nos retornara el Status/Current Mode.

ssh sin contraseña

Muchas veces en el día a día de un sysadmin, nos es necesario automatizar tareas las cuales implican conexiones remotas, estas situaciones ponen al administrador ante la necesidad de poder hacer login remoto sin tener que el mismo escribir la contraseña de autentificación.

Para solucionar esta necesidad, existe el metodo de autentificación por llaves en el protocolo ssh, el cual permite evitar la necesidad de teclear la contraseña al establecer conexión con los host.

Habilitar este comportamiento es muy sencillo, simplemente es necesario realizar lo siguiente:

Generar las llaves de ssh:

• Para ello ejecutamos: # ssh-keygen -t dsa:

Transferir la llave publicas al remoto:

•  Nos valdremos en este caso de la utilidad  "ssh-copy-id" :
  
  

Probar la conexión:

• Realizamos una conexión con el usuario y el host especificado en el paso anterior:
  
  ssh usuario@equipo

Si todo ha ido bien, debemos podemos ingresar al equipo y no debe habernos solicitado contraseña.

MS Sql en RHEL

Por motivos de trabajo, he tenido al fin la necesidad de conectar desde Linux con una base de datos de MS-Sql y como siempre paso por aca para dejar la receta de como hacerlo. El proceso es bien sencillo y simplemente es necesario bajarnos un par de paquetes, realizar la configuración y listo, ya tendremos nuestra conexión operativa.

El escenario al que aplica este articulo es uno en el que tienes una aplicación que requiere conectarse a un segundo equipo donde se ejecuta el MS-Sql. Para el caso especifico, tenemos un equipo con una aplicación desarrollada en php, el cual ya tiene instalado el servidor apache y el php.

En cualquier caso, y esto sobre todo para aquellos que quieran documentarse un poco mas, es esta solución vamos a emplear la biblioteca Freetds (I,II) y el paquete php-mssql el cual nos permite hacer uso de las funciones Ms-Sql dentro de nuestro código php.

El proceso

Lo que debemos hacer primeramente es instalar los siguientes paquetes:

• Freetds,
• Php-mssql (o el equivalente para el lenguaje en el que tenemos el desarrollo).

Normalmente, el proceso se limitaria a ejecutar:

# yum install  freetds.arch php-mssql.arch

* donde arch hace referencia a la arquitectura de nuestra plataforma.

Luego de realizada la instalación de los paquetes es momento de realizar la configuración del TDS, para ello simplemente debemos modicar el archivo de configuración del tds e indicarle los parámetros de nuestro servidor.

• Accedemos al archivo /etc/freetds.conf

# vi /etc/freetds.conf

• Ubicamos la linea (A typical Microsoft server) y procedemos a modificarla.
• Agregamos los parametros de configuración en base a nuestro escenario asi:

# A typical Microsoft server
[NombreServidor]
        host = Dirección IP
        port = puerto
        tds version = VersiónDelTDS
  

Es muy importante, que los parámetros estén bien configurados dentro del archivo para que de esta forma nuestra aplicación se pueda conectar de manera correcta, en tal sentido, debemos incluso asegurarnos de tener correctamente seleccionado la versión del TDS (varia en base a la versión de MS-Sql que use nuestro server).

Dentro del /etc/freetds, también podemos habilitar el registro de log, el cual es muy útil a la hora de monitorear y de hacer diagnostico de errores, para ello simplemente debemos descomentar la opción de dump en el log.

Finalmente, podemos probrar que todo este bien ejecutando:

# tsql -S NombreServidor -p Puerto -U UsuarioBaseDatos

Esto nos debería permitir conectarnos al servidor especificado.
 

Sincronización de Carpetas entre Equipos con Rsync

En mi día a día, trabajo indistintamente con diferentes computadoras; cada una de ellas tiene un fin especifico, esto me ha sido muy útil en realidad, pero ha traído consigo la necesidad de tener la misma información en todos los equipos (si, de verdad necesito esa redundancia de datos).

La Solución a este problema ya la conozco desde hace tiempo, sincronizar los contenidos entre equipos.... Ahora, debo decir que por diversas situaciones (mas que todo falta de ponerme las pilas con esto), no la había implementado y mucho menos comentado aquí, pero ya ha llegado el momento...

Opción 1: La nube;

Esta posibilidad siempre me ha resultado muy interesante, sobre todo porque la mayoría de los servicios en la red cuentan con aplicaciones para dispositivos móviles y al tener yo un par de estos equipos (iPod Touch, SmartPhone Android) la solución va como anillo al dedo.

Las posibilidades son muchas y la verdad que es necesario que nos sentemos un buen rato a leer contratos de licencias, pros, contras, opiniones y review sobre este tema ya que de estos servicios siempre hay mucho que hablar. En cualquier caso, ir mas allá con los temas no es la idea de este post, así que solo me limitare a comentar un par de opciones:

• Gdrive: del servicio de almacenamiento en la red de Google mucho se hablo y durante un buen tiempo, las especulaciones sobre la propiedad de los archivos que allí se suban y otros temas mas dan polémica a la elección, pero su integración con los demás servicios han restado importancia a esto. El servicio es muy competitivo al ofrecer 5 Gb, pero al ser nuevo cuenta con aplicaciones para solo algunas plataformas.
• Dropbox: muy conocido en el mundo del almacenamiento en la nube, de este servicio mucho se ha hablado por la temática de sus políticas de seguridad, la forma en la que trata los archivos y en fin, otro montón de cosas, pero en cualquier caso cuenta con un muy envidiable numero de usuarios y app para casi todas las plataformas lo que lo hace una opción nada despreciable.
• owncloud: te gusta hacer las cosas por ti mismo y no depender de los demás..., crees que tu información es muy importante para dejarla en los servidores de otros..., tienes conocimientos, un buen proveedor de internet y la posibilidad de dejar tu equipo encendido y conectado 24/7; si alguno de esos es tu caso pues esta puede llegar a ser una opción para ti, pero documentate bien antes de hacer nada.

En mi caso, yo he instalado en mis equipos y dispositivos móviles la app de dropbox y por ese medio comparto alguna de mi información, no puedo negar en ningún momento su utilidad y beneficios, pero para mi necesidad esto es solo una solución a medias ya que el volumen de datos sobrepasa con creces lo ofrecido por dropbox, no pienso pagar por el servicio y tampoco me confió en colocar cosas importantes que he desarrollado allí (seguro mato a confianza -como dicen en mi país)...

Opción 2: Rsync;

Y en esta me quede.... rsync es una aplicación libre para sistemas de tipo Unix y Microsoft Windows que ofrece transmisión eficiente de datos incrementales, que opera también con datos comprimidos y cifrados.

Mediante una técnica de delta encoding, permite sincronizar archivos y directorios entre dos máquinas de una red o entre dos ubicaciones en una misma máquina, minimizando el volumen de datos transferidos.

Una característica importante de rsync no encontrada en la mayoría de programas o protocolos es que la copia toma lugar con sólo una transmisión en cada dirección. rsync puede copiar o mostrar directorios contenidos y copia de archivos, opcionalmente usando compresión y recursión.

Actuando como un daemon de servidor, rsync escucha por defecto el puerto TCP 873, sirviendo archivos en el protocolo nativo rsync o via un terminal remoto como RSH o SSH. En el último caso, el ejecutable del cliente rsync debe ser instalado en el host local y remoto.

rsync se distribuye bajo la licencia GNU General Public License.

Sincronizando con Rsync:

Caso 1, Sincronizando medios extraibles: En este ejemplo el directorio origen es /home/usuario y vamos a sincronizarlo con un directorio destino (/media/disco/copia_usuario ) que puede estar en otra partición del disco duro, o en otro disco duro externo, o en un pendrive de suficiente capacidad. Ejecutar en una terminal el comando siguiente:

rsync -avrz /home/usuario/  /media/disco/copia_usuario

Breve explicación de las opciones:

opción -a preserva las propiedades del fichero (permisos, timestamps…)
opción -v verbose (para poder ver lo que hace)
opción -r recursivo, para sincronizar los subdirectorios
opción -z, lo que activaría la compresión en destino.
opción –delete elimina en destino los ficheros que no están en el origen

Caso 2, Sincronizando entre equipos: En este otro ejemplo el directorio origen es /home/usuario y vamos a sincronizarlo con ese mismo directorio, pero en otro maquina (10.0.0.200/home/usuario) que puede estar en otra partición del disco duro, o en otro disco duro externo, o en un pendrive de suficiente capacidad. Ejecutar en una terminal el comando siguiente:

rsync -avrz /home/usuario/  10.0.0.200:/home/usuario

En cualquier caso, es posible que creemos una serie de scripts que nos hagan la tarea mucho mas sencilla y automatizada, pero de ello hablare en un próximo post... (aun debo hacer los scripts y probarlos).

Grsync:

Esta aplicación hecha en Perl, se puede usar para sincronizar desde el entorno grafico. Puede ser utilizado eficazmente para sincronizar directorios locales y remotos. Por ejemplo, algunas personas usan grsync para sincronizar su colección de música con un dispositivo extraible o una copia de seguridad de archivos personales a una unidad de red.

Tiene una única “ventana”, en la que se selecciona el nombre de la sesión, la carpeta de origen (la que se va a copiar/sincronizar) y la carpeta de destino (con la que se va a sincronizar)

Evitar la Modificación del /etc/resolv.conf

Tal como comente hace tiempo, en casa tengo instalado un equipo que hace las veces de servidor y que me permite compartir mi conexión a Internet, tanto por red cableada como por WiFi. Este equipo tiene instalado -entre otras cosas- bind9 y dhcp y se conecta a la red mediante un dispositivo PPP, el cual usa NetworkManager o Wvdial para realizar la conexión....

La cosa es que evidentemente, el archivo resolv.com (donde se indica la IP para la resolución DNS), esta configurado para mirar al LoopBack (127.0.0.1), pero se modifica con las DNS del proveedor cada vez que realizo el marcado y eso deja sin efecto en mi server la resolución de nombres de forma local.

Para evitar tal situación, he decidido modificar el archivo manualmente y posteriormente setear el atributo de Inmutabilidad en el, asi:

# chattr +i /etc/resolv.conf

Para comprobar los atributos del archivo, ejecuto:

# lsattr /etc/resolv.conf

Finalmente, si por alguna razón quiere desactivar el atributo, ejecuto:

# chattr -i /etc/resolv.conf

Network File System (NFS)

Instalación del Servidor y el Cliente NFS

Como siempre, vamos a la teoría y como siempre wikipedia:

El Network File System (Sistema de archivos de red), o NFS, es un protocolo de nivel de aplicación, según el Modelo OSI. Es utilizado para sistemas de archivos distribuido en un entorno de red de computadoras de área local. Posibilita que distintos sistemas conectados a una misma red accedan a ficheros remotos como si se tratara de locales. Originalmente fue desarrollado en 1984 por Sun Microsystems, con el objetivo de que sea independiente de la máquina, el sistema operativo y el protocolo de transporte, esto fue posible gracias a que está implementado sobre los protocolos XDR (presentación) y ONC RPC (sesión) . El protocolo NFS está incluido por defecto en los Sistemas Operativos UNIX y la mayoría de distribuciones Linux.

En palabras sencillas, NFS nos permite compartir una partición o dispositivo en nuestra red local, de esta manera podemos montarlo como si de una unidad mas se tratase en un cliente remoto, cosa que en muchos casos viene muy bien...

Características:

• El sistema NFS está dividido al menos en dos partes principales: un servidor y uno o más clientes. Los clientes acceden de forma remota a los datos que se encuentran almacenados en el servidor.
• Las estaciones de trabajo locales utilizan menos espacio de disco debido a que los datos se encuentran centralizados en un único lugar pero pueden ser accedidos y modificados por varios usuarios, de tal forma que no es necesario replicar la información.
• Los usuarios no necesitan disponer de un directorio “home” en cada una de las máquinas de la organización. Los directorios “home” pueden crearse en el servidor de NFS para posteriormente poder acceder a ellos desde cualquier máquina a través de la infraestructura de red.
• También se pueden compartir a través de la red dispositivos de almacenamiento como disqueteras, CD-ROM y unidades ZIP. Esto puede reducir la inversión en dichos dispositivos y mejorar el aprovechamiento del hardware existente en la organización.

Instalando:

Servidor:

En el servidor es importante tener instalado los servicios , para ello simplemente ejecutamos:

# aptitude install portmap nfs-server nfswatch

Posterior a la instalación, verificamos que los servicios están corriendo, para ello ejecutamos:

# rpcinfo -p

La salida de este comando debería lucir algo así:

Clientes:

Del lado del cliente la cosa es mucho mas sencilla, solo debemos instalar nfs-common:

# aptitude install nfs-common

Configurando y Montando:

Exportando:

NFS va a exportar en la red todos los dispositivos o carpetas que se le indiquen en el /etc/exports, este es el archivo maestro de exportación y en el también podemos especificar detalles como con que maquinas vamos a exportar el dispositivo, que permisos daremos y así.

Obviamente, lo primero que debemos hacer es determinar las carpetas o dipositivos a ser exportados y posteriormente agregamos las lineas al /etc/exports basados en la siguiente estructura:

RutaACompartir IpsPermitidas/MascaraSubRed (Permisos)

Todo quedaría algo así:

Ahora para los cambios tengan efecto es necesario reiniciar el servicio:

# /etc/init.d//nfs-kernel-server restart

Montando en el cliente:

Aquí la cosa también es sencilla, pero tenemos dos opciones, podemos hacer que la partición se monte desde el arranque del sistema o podemos montar la carpeta o dispositivo cuando lo necesitemos.

Montado Permanente:

Si estamos seguros que el equipo cliente siempre va a poder conectarse con el servidor nfs desde el arranque siempre, esta es la mejor opción, para hacerlo simplemente hay que agregar un nuevo punto de montaje en el archivo /etc/fstab; el formato es:

IpServidor:/RutaCompartida   /PuntoMontajeLocal   TipoPartición   Opciones   Dump   Pass

Nos quedaría algo así:

Hecho el cambio, lo que debemos hacer es remontar todos los puntos conocidos ejecutando:

# mount -a

Y listo, ya debemos tener nuestro sistema compartido accesible desde el cliente.

Comando de Montado:

Alternativamente, es posible que no queramos que el cliente monte el dispositivo o carpeta remoto desde el inicio, entonces la alternativa es indicarle el montaje de forma manual, para ello ejecutamos:

# mount -t nfs IpServidor:/RutaCompartida  /PuntoMontajeLocal

USB en Virtual Box

Debido a una fiebre que me dio por volver a hacer el jailbreak de mi iPod Touch, en estos días me he visto en la necesidad de algo que nunca antes había estado en el panorama, Usar seriamente una Maquina Virtual... Anteriormente, había hecho instalaciones de maquinas virtuales pero en general no las empleaba realmente, se puede decir que las instalaba por perder espacio, pero esta situación ha cambiado y uno de los primeros problemas que me encontré fueron los puertos USB.

En general, a casi todos los dispositivos, se tiene acceso de forma inmediata en la maquina virtual, el sonido, la red no son realmente un problema, incluso, cosas como la captura del ratón o mejores resoluciones se logran simplemente con la instalación de las guest additions.

Ahora bien, resulta que los puertos USB son una cosa diferente, no complicados, pero si diferente... Basicamente, solo debemos hacer un par de cambios y tendremos habilitados nuestros dispositivos USB.... 

El procedimiento:

• Descargar e instalar el extension Pack de virtual box (disponible en su pagina web)
• Modificar el archivo /etc/fstab, agregando la linea:

          none /proc/bus/usb  usb  usbfs  devgid=46,devmode=664  0  0

• Guardamos, Cerramos y ejecutamos "mount -a" para que el cambio surta efecto
• Nos vamos a virtualBox, seleccionar nuestra maquina virtual, click en propiedades, USB y agregar nuevo filtro vació.

Servidor DNS cache (simple)

Continuando con la documentación de lo hecho en el curso, y quitando elementos de mi lista de articulos pendientes por publicar, ahora es el momento del servidor DNS...

La teoría de DNS, la podemos encontrar completa en sitios como Wikipedia, por lo cual no tocare ese tema. Debo aclarar, que lo que acá escribo, esta probado en Fedora 15 y aplica a cualquier distro RHEL (se uso en Centos v. 6)

El primer paso, como siempre es ejecutar la instalación:

# yum -y install bind bind-utils

Ya instalado, poner a andar el servidor, es tan sencillo como modificar el archivo de configuración del servicio /etc/named.conf, aca lo que se debe es agregar un par de parametros y listo:

• query-source    port 53; query-source-v6 port 53; nos indican por que puerto nuestro servidore escuchará solicitudes.
•  forwarders { 200.44.32.12; 200.11.248.12; }; Indica los DNS de nivel superior, desde el cual nuestro servidor ira aprendiendo.
• forward only; indica a nuestro DNS que solo pida al principal lo que no conozca.

Al final, nuestro archivo queda algo asi:

//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
    listen-on port 53 { 127.0.0.1; 192.168.2.1;};
    listen-on-v6 port 53 { ::1; };
    directory     "/var/named";
    dump-file     "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query     { localhost; any;};
    recursion yes;

    dnssec-enable yes;
    dnssec-validation yes;
    dnssec-lookaside auto;
    query-source    port 53;
    query-source-v6 port 53;
    forwarders { 200.44.32.12; 200.11.248.12; };
    forward only;

    /* Path to ISC DLV key */
    bindkeys-file "/etc/named.iscdlv.key";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
    type hint;
    file "named.ca";
};

include "/etc/named.rfc1912.zones";

 

Ahora toca hacer que nuestro equipo y los demás de la red empleen nuestro DNS, para ello simplemente editamos el /etc/resolv.conf, comentando lo que pueda tener y dejando:

nameserver 127.0.0.1

Hay que aclarar, que en lo anterior es para el servidor, en los clientes de la red, lo que debemos hacer es cambiar el 127.0.0.1 (direccion de localhost) por la dirección IP del servidor DNS

Hecho esto ya podemos reiniciar el servicio y listo... A disfrutar nuestro DNS

Iptables + Ipalias

GNU/Linux es sinónimo de un mundo de posibilidades y en materia de administración de sistemas y servidores la ventaja con respecto a otros sistemas es muy significativa. Las distribuciones linux nos abren a los administradores, fanáticos y geeck un mundo de posibilidades limitado -casi únicamente- por nuestras habilidades....

Iptables + Ipalias es una de esas soluciones que engrosa la lista de lo antes comentado... Por qué ? ... Pues veamos.

Ya en una entrada anterior comente sobre iptables y sus bondades (aquí el articulo) pero ahora propongo ir un poco mas allá mostrando su uso con Ipalias...

En palabras muy sencillas se puede decir que ipalias es una implementación que nos permite configurar múltiples direcciones ip para una sola interfaz, de esta manera podemos hacer una suerte de virtualización (o simulación) de contar con mas interfaces de red.

Esta es una idea útil -en redes caseras o pequeñas- para realizar la implementación de un firewall y aumentar la seguridad, incluso la podemos utilizar para levantar maquinas virtuales que se conecten a internet.

Como ????

La verdad es que es un procedimiento sencillo, lo que debemos hacer primera mente es verificar haciendo uso de un ifconfig las interfaces disponibles y su nomenclatura ante el sistema...

# ifconfig

El resultado en un entorno de trabajo normal seria semejante al que muestro a continuación:

eth0    Link encap:Ethernet  HWaddr 08:00:46:16:BA:D0
          inet addr:192.168.0.103  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:46ff:fe16:bad0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11889 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11310 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8460330 (8.0 MiB)  TX bytes:1362059 (1.2 MiB)
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:141 errors:0 dropped:0 overruns:0 frame:0
          TX packets:141 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:13091 (12.7 KiB)  TX bytes:13091 (12.7 KiB)

Aquí podemos ver que nuestro sistema cuenta con una tarjeta de red (eth0) y el loopback (lo) configurados - Configuración que lo normal -

Habilitar el ipalias es muy sencillo basta con ir al archivo de configuración de las interfaces en nuestra distro (/etc/network/interfaces) y agregar una interfaz con la misma nomenclatura de la que tenemos pero seguida de dos puntos (:) y un identificador.... Así:

auto eth0:1

Los demás detalles de como configurar la interfaz para recibir DHCP o Ip estática los podemos encontrar aquí

Una vez configurada la segunda dirección ip para la interfaz lo que debemos hacer es habilitar el ruteo de paquetes, para ello, cambiamos el valor del archivo que confirgura esta acción en el Kernel:

echo 1 > /proc/sys/net/ipv4/ip_forward

Ya teniendo el reenvio de paquetes, lo que nos queda simplemente es indicar al kernel como debe realizar el reenvio y para esto usamos Iptables....

# iptables -t nat --flush
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

La primera de las instrucciones hace un flush para limpiar posibles reglas anteriores de enmascaramiento .... y la segunda por su parte enmascara todos los paquetes que entren y salgan de eth0.

Listo, ahora lo que tenemos que hacer es configurar los host que queremos estén detrás del firewall, para ello podemos seguir este post.

Hay que tener ya que debemos asignar a los host tras el firewall una ip del rango de eth0:0 (interfaz virtual), además, tenemos que configurar que el gateway de estos apunte a la ip de la interfaz eth0:0

Introducción a las Iptables -Entendiendo las Reglas-

iptables permite al administrador del sistema definir reglas acerca de qué hacer con los paquetes de red. Las reglas se agrupan en cadenas: cada cadena es una lista ordenada de reglas. 

 

Las cadenas se agrupan en tablas: donde cada tabla está asociada con un tipo diferente de procesamiento de paquetes.

 

Cada regla especifica qué paquetes la cumplen (match) y un destino que indica qué hacer con el paquete si éste cumple la regla. Cada paquete de red que llega a una computadora o que se envía desde una computadora recorre por lo menos una cadena y cada regla de esa cadena se comprueba con el paquete. Si la regla cumple con el datagrama, el recorrido se detiene y el destino de la regla dicta lo que se debe hacer con el paquete. Si el paquete alcanza el fin de una cadena predefinida sin haberse correspondido con ninguna regla de la cadena, la política de destino de la cadena dicta qué hacer con el paquete. Si el paquete alcanza el fin de una cadena definida por el usuario sin haber cumplido ninguna regla de la cadena o si la cadena definida por el usuario está vacía, el recorrido continúa en la cadena que hizo la llamada (lo que se denomina implicit target RETURN o RETORNO de destino implícito). Solo las cadenas predefinidas tienen políticas.

Bueno, ya tenemos las bases, ahora vamos a la practica....

Primero lo primero....

veamos como esta configurado nuestro iptales...

# iptables -L

El parametro -L lista las reglas que actualemente tenemos

Bien, ya sabemos nuestras reglas, hagamos un cambio sencillo, convirtamos nuestro equipo en un agujero negro algo asi como /dev/null

# iptables -P OUTPUT DROP

Con esto lo que hemos hecho es modificar la politica por defecto de todo el trafico saliente, y esto incluye aquel que no avandona la maquina por eso se afecta nuestro localhost... podemos probar esta regla simplemente haciendo un ping al localhost y/u otra dirección

Ahora, esto no es lo mas optimo... lo que hemos hecho, es incluso superior a desconectar nuestro cable de red.... asi que mejor coloquemos todo como estaba si....

# iptables -P OUTPUT ACCEPT

-P = nos permite modificar las politicas por defecto, estas pueden ser ACCEPT o DROP, con este especificamos si vamos a tener un firewall abierto o cerrado.

Creando nuestras primeras reglas...

Primero que nada una prueba, has ping al localhost.... hay trafico ???? bien vamos a cerrarlos, para ello simplemente ejecutamos:

# iptables -A input -i lo -j drop

Listo, ahora nuevamente un ping a localhost.... No funciona... Hummm probemos con un ping a otra pag... google.com funciona ?????

Ahora bien, Localhost es un lugar de pruebas útil, por lo que tenerlo cerrado no es la mejor de las ideas, vamos a restaurar todo, para ello ejecutemos:

# iptables -D input -i lo -j DROP

-A = Agregar una regla a la Iptables
-D = Eliminar una regla de la Iptables
-i = identifica el dispositivo objeto de la regla
-j = identificamos que vamos a hacer con el trafico que coincida con la regla

Pero esto es solo una pequeña muestra de lo que es posible hacer con iptables, en lugar de especificar un dispositivo, podemos ser mas detallados y aplios (por contradictorio que suene si es asi) al indicar protocolos y puertos como targets, pero mejor veamos una prueba...

Primero que nada ubiquemos otra maquina y probemos que podemos conectarnos vía ssh con ella:

$ ssh usuario@equipo

indicamos la contraseña para el usuario cuando el sistema nos lo solicite y listo, si todo va bien estamos dentro del otro equipo si.... bueno dejemos esa session alli..

ahora si, a lo que vamos, apliquemos una regla de iptables para el ssh:

# iptables -A INPUT -p tcp --sport 22 -j DROP

listo, bien.... Regresemos a nuestra consola con el ssh y probemos ejecutar cualquier comando, listemos archivos por ejemplo (ls)...

Que ocurrio ???? Tienes alguna idea ????

retornemos a la segunda consola (la que manejamos para iptables) y ejecutemos ahora:

# iptables -A INPUT -p tcp --sport 22 -j DROP

vamos a la consola con la sesion ssh y ejecutemos otro comando... que ocurre ????

Nota: el resultado puede verse afectado si hemos tardado mas de 1 minuto para ejecutar los pasos...

Entendamos la cosa: En este ejemplo hemos cerrado el trafico entrante (INPUT) del protocolo ssh, especificado el target de la regla con el -p (protocolo) + el --sport (puerto Origen), de esta misma forma, también es posible aplicar reglas para el trafico saliente (OUTPUT) y para cualquier otro servicio...

Con iptables, tambien es posible crear reglas que atiendan las direcciones de los paquetes, como ??? veamoslo de la manera mas sencilla... Un ejemplo:

Abramos un navegador y vallamos a la pagina mas usada en la actualidad google.com Si tenemos habilitadas las políticas por default's seguro tendremos acceso y nuestra pagina cargara.

Ahora, vamos a la terminal y cerremos el trafico a google:

# iptables -A OUTPUT -p tcp -d google.com --dport 80 -j DROP

Bien, regresa al navegador e intenta nuevamente acceder a google.com, funciona ????

Lo que hemos hecho es especificar una regla que descarta el trafico tcp saliente (OUTPUT) destinado (-d) al servidor google.com específicamente al puerto 80 (--dport 80), pero ocurre que esta regla no afecta a otro trafico similar destinado a otro servidor...

Es importante recordar, que estas reglas se van a mantener mientras dure la sesion actual salvo que elimines la regla, algo que ya hemos hecho antes y que estoy seguro puedes hacer tu solo verdad....

Con Iptables no solo es posible especificar reglas para descartar paquetes, podemos tambien llevar registros sobre el sistema los cuales se almacenaran en el /var/log/messages. Para habilitar reglas que habiliten la escritura en el registro lo que debemos hacer es especificar el -j LOG en la regla.

Veamos estas reglas en un ejemplo... Supongamos que queremos llevar un registro de conexiones a nuestro ssh, para ello ejecutamos:

# iptables -A INPUT -p tcp --dport 22 -j LOG

bien, ahora vamos a otra maquina y realicemos una una conexión ssh al sistema al cual le aplicamos la regla.... y listo, nuestro acceso ha quedado registrado...

Podemos aplicar esta regla a cualquier servicio o dispositivo, solo tenemos que tomar en cuenta que por cada transaccion que se este ejecutando al aplicar la regla de esta forma varias lineas se estan agregando en el log del sistema y esto puede no ser lo mas optimo, por ello, vamos a mejorar esta regla.

Veamos el registro en LOG para el servicio FTP...

# iptables -A INPUT -p tcp --dport 21 -j LOG

Una linea igual a la que ya habíamos introducido antes pero que nos registra los accesos a FTP, al igual que el caso anterior, nos generaría muchas lineas en el log por cada conexión... y además nos da la oportunidad de ir mas allá si no tenemos un FTP montado en nuestro sistema....

Si no contamos con un servidor ftp en nuestro sistema ejecutemos dmesg y veamos la ultima linea, la entienden.... El servicio de ftp también nos permite ver lo que ocurre si no somos lo suficientemente específicos al crear una regla de almacenamiento en log, una linea como la especificada en un acceso generaría cantidad de lineas que no son para nada útiles en un log (lo hacen muy largo y tortuoso de leer y no es la idea).

Lo ideal es que se registre el cliente una sola vez y no cada vez que este gestione un paquete, para lograr esto, lo que tenemos que hacer es considerar el comienzo del segmento de la conexion ya que este tiene activo el Flag SYN.

Al hacer esto, la linea queda así:

# iptables -­A INPUT -­p tcp --­­dport 21 --­­tcp-­flags ALL SYN -­j LOG

Nota: se debe eliminar la linea anterior.... (# iptables -D INPUT -p tcp --dport 21 -j LOG)

Pero como no tenemos un FPT activo en nuestra maquina no veremos nada.... salvo la misma alerta en nuestro dmseg y esta no es la idea... para poder ver como funciona la linea, vamos a quitarla y a cambiarla por una que nos registre cada vez que nos conectamos a ftp...

# iptables -A OUTPUT -p tcp --dport 21 --tcp-flag ALL SYN -j LOG

Lo primero que tenemos que notar es que cambiamos la regla para crear una entrada en log para la salida de paquetes... Ahora probamos la linea conectandonos a un ftp (ftp://debian.org -p.e-) y luego mirando el log de iptables.... Mejor verdad...