Índice/Index

viernes, 20 de julio de 2012

Configuración básica de red IPv6 en Linux

Hoy escribiré sobre como configurar Linux con IPv6. Ya en un tema anterior hable sobre como formar las direcciones IPv6 y los tipos de dirección que existen. Así que hoy iremos directo sobre la práctica.

El tema es corto pero es que es así de sencillo configurar un equipo con IPv6, a lo mejor muchos ya saben pero también Linux siempre tiene gente nueva que busca estas cosas que para muchos ya son muy "sencillas".


Verificar que el sistema tiene activado IPv6

El módulo de IPv6 ya viene integrado en todos los kernel 2.4.x aunque no siempre se encuentra activado.


Con este comando podemos verificar si lo está o no:







Si nos devuelve el mensaje "Si activado" quiere decir que ya se encuentra activado IPv6. De lo contrario lo activamos con estos comandos.

Para Ubuntu o similares:






Para que el módulo IPv6 cargue automáticamente cuando inicia el sistema se agrega la palabra ipv6 al final del archivo:






Para Fedora o similares:

Se edita este archivo:






Y agregamos esta línea al archivo:






Ya que la agregamos reiniciamos el servicio de red.

También para permitir el reenvío de paquetes IPv6 en nuestro equipo por si se llega a necesitar esta función en el futuro, aplicamos lo siguiente.



Habilitar reenvío de paquetes IPv6

En Ubuntu y similares

Con el siguiente comando se puede activar el reenvío:





Y para activar el reenvío desde el inicio del sistema se edita este archivo:






Agregando la siguiente línea:






Después este archivo se copia a /etc.

Y finalmente se edita este archivo:






Agregando esta línea:







Para activarlo en Fedora y similares:

Se edita el archivo:





Agregando esta línea:






Ahora si pasemos a configurar nuestras interfaces.



Configurar red en Ubuntu y similares

Utilizaremos de ejemplo la IPv6 local de sitio FEC0::A987:211:22FF:FE33:4455 con máscara de subred de 64 bits.

Se edita el archivo:






Con las siguientes líneas:






En esta configuración no establecimos gateway pero también se puede escribiendo así: gateway6 dirección.



Configurar red en Fedora y similares

Se edita el archivo:






Donde eth0 se sustituye por la interfaz que estén utilizando.

Se edita con estas líneas:







También se le puede agregar un gateway de esta forma: IPV6_DEFAULTGW=dirección

Con esto ya tenemos una dirección IPv6 en nuestro equipo.



Como comprobar la conectividad

Para comprobar la conectividad entre equipos que utilizan IPv6 se utiliza el ping6:





Y listo ya tenemos una configuración IPv6 básica. Espero que les sirva a los que no saben y a los que no saben por si querían recordarlo.

martes, 17 de julio de 2012

Install a local DNS in Linux with Bind

How to mount a quick and basic DNS in a local network.

First let's see the types of DNS and DNS records.


Types of DNS

Master: Owns the authoritative records of a zone, answers the requests of name resolution as an authoritative server and delegates copies to the slave servers.

Slave: Answers to the name resolution requests as an authority server, but the information is distributed by the master servers.

Cachingonly: Answers to name resoution requests but it is not an authority server, it saves the answers in memory by a determined period of time.

Forwarding: Forwards the requests to a list of name servers.


DNS Records

A (Address): Defines an IP address and the name assigned to the host.

AAAA: It's the replacement of the A records when the traduction is from name to IPv6 address.

MX (Mail eXchanger): It's used to identify mail servers.

CNAME (Canonical Name): Is an alias that is assigned to a host that has an IP address and answers to different names. You can declare various for a host.

NS (Name Server): Defines the principal name servers of a domain. It most have one at least.

SOA (Start Of Authority): This is the first record of the zone and it can only be one for each zone file and it's only present if the server is authority of the domian.
Specifies the primary DNS of the domain, the administrator mail account and the times of refresh.

PTR (Domain Name Pointer): Indicates to which IP address corresponds a name.


Parameters of the SOA record

Serial: The serial number is used to synchronize the zones between the primary and secondary DNS. If when the secondary DNS consults the primary DNS finds that the serial number is bigger than the one it has it means that the zone file has been updated, so it will ask for a copy of the updated version.

Refresh: Is the time that a secondary DNS has to wait to verify again the record values of a primary DNS.

Retry: Is the time that a secondary DNS has to wait after a failed attempt to retrieve data from a primary DNS.

Expire: Is the time that data will remain in a secondary DNS before they expire.

Negative Cache TTL: Is the time that a DNS cache will remember the negative consults (NXDOMAIN).

Ok now that we saw some theory let's start with the installation and configuration for the Ubuntu and Fedora distros.


Installation and configuration for Ubuntu and similars

Versions in example: Ubuntu 10.04, Bind 9.7.0-P1
If the versions are different to these ones they might be some variations, but if it is a Bind version 9 you shouldn't have problems.

Installation:




Now we have to go to the directory /etc/bind there we'll find our configuration files.

Well, for the example we'll use the rukia.com domain, that will also be our DNS, in the example the server has the IP of 10.9.8.50 (rukia.com) and our client has the IP of 10.9.8.1 to which we'll set the domain name of goku.rukia.com.

The first file we have to edit is where the zones are declared:




For default the file contains this:




In this content the next zones are declared: the root public primary DNS, localhost, reverse localhost, broadcast and reverse broadcast.

For our own zone using as example that we want to add the domain rukia.com and that the name of the zone file is db.rukia, we add the zone like this:





Now we add the reverse zone file. The reverse zone is to resolved from an IP address to a domain name. For the example we'll add the reverse zone to the network 10.9.8.0, that is the network to which our example IPs belong (10.9.8.1 and 10.9.8.50) and with the name of the reverse zone file as db.rukiaRev:




Note that the network address is written backwards, our network is 10.9.8.0, so it was written 8.9.10.
The names for the zone files can be any name we want.
In the end the named.conf.default-zones file has to look like this:





Before we continue with the zones, let's check that the named.conf file includes the file named.conf.default-zones, for this we just have to read the next file:



The file must contain this:





Now let's write our zone file for rukia.com (/etc/bind/db.rukia), we'll also add in it the name goku.rukia.com for the client 10.9.8.1 and also that if we search for the name www.rukia.com it will give us the IP 10.9.8.50.
So the file must look like this:






I'll explain the file line by line (from line 0 to 10, without counting spaces)

0 - The TTL is set, the TTL is the Time To Live that the consults to the cache will persist instead of consulting the server, this means that if a domain has already been consulted, and another consult is done inside the TTL time, the consult will be made to the cache, but if this time has expired the consult will be made to the server. In the example I put 120 seconds, thinking in critic situations where the domain name has to be updated instantly. The default time is 6054800 seconds.

1 - The SOA is set and the email account of the domain administrator. The email is written like this: rukia.rukia.com, the @ is changed for a period, but the real email is rukia@rukia.com.

2 to 6 - The SOA parameters.

7 - The NameServer is set for the domain, in this case is the same server (rukia.com). The @ makes reference to the domain name to which the zone belongs, in this case is rukia.com. This means that for this zone @=rukia.com.

8 - The rukia.com domain is pointed to the IP 10.9.8.50.

9 - The canonical name www.rukia.com is set. This means that if rukia.com or www.rukia.com is resolved the answer will always be 10.9.8.50.

10 - The domain name goku.rukia.com is set to the IP 10.9.8.1.

Now let's create the reverse zone file for our network (/etc/bind/db.rukiaRev):






Again I'll explain the file line by line (0 to 9, without counting spaces)

0 - TTL.

1 - The SOA and the administrator email is set.

2 to 6 - SOA parameters.

7 - The NameServer is set, in this case is the same server.

8 - The IP 10.9.8.50 is pointed to the domain rukia.com. Note that is only written the host address from theIP. The network address is 10.9.8.0, so the host address is 0.0.0.50.

9 - The IP 10.9.8.1 is pointed to the domain goku.rukia.com.

Now we're only missing the named.conf.options file, but for Ubuntu there's no need to edit it, only in case of having problems with the reverse resolution or if we see and error that says that the DNS refuses the connections when we are trying to resolve the domain names from a client. If this happens we have to verify that the next options are added to the /etc/bind/named.conf.options file to avoid this errors:





To start the service we have to execute this command:




And ready, we have a functional and quick DNS for our LAN.



Installation and configuration for Fedora and similars

Versions in the example: Fedora 16 Security Spin, Bind 9.8.3-P1-RedHat-9.8.3-2.P1.fc16
If the versions are different to these ones they might be some variations, but as long as it is a Bind 9 there should not be any problem.

Installation:



Well, for the example we'll use the domain rukia.com, that will also be our DNS, in this example the server has the IP address of 10.9.8.50 (rukia.com) and our client has the IP 10.9.8.1 to which we'll set the domain name of goku.rukia.com.

The first file to edit is named.conf:





In this file the options for our DNS and the zones will be declared, for default the file already has this:





In this file the options we are interested in editing are:

listen-on-port 53 {127.0.0.1; }; - Here is set that the server will be listening in the port 53 for the localhost IP. Here we have to add the IP of our local computer so it can attend requests from the client in the LAN, in this case we'll add the example IP that is 10.9.8.50.

directory "/var/named"; - The directory where the zone files will be stored, it can be other directory as long as the named service has the rights to read. For the example we'll leave the default directory.

allow-query {localhost; }; - Sets who'll be permited to consult the DNS, for default it is only allow to localhost. For the example we just need to allow the localhost and our LAN, so we'll add 10.9.8.0/24. If we want to any client to request our DNS we only have to add the word any in place of localhost or an IP address.

recursion yes; - Allow the reverse request. This means that if we make a request to obtain the domain name from an IP it will be allowed.

The file also has the public primary root DNS declared for default.

Now we'll see how does the option section has to look, in which the IP 127.0.0.1 and the local IP assigned to the server (10.9.8.50) will listen to port 53, the directory /var/named will be set as the file zone directory, the server will allow requests from localhost and the LAN, and will allow reverse requests:





For our own zone using as an example that we want to add the domain rukia.com and that our zone file name is named.rukia, we add the zone like this:





Now we add the reverse zone file. The reverse zone file is to resolve the domain name from an IP. For the example we'll add the reverse zone of the network 10.9.8.0, which is the network where our example IPs belong (10.9.8.1 and 10.9.8.50) and the name of our reverse zone file is named.rukiaRev:





Note that the network address is written backwards, our network is 10.9.8.0, so it was written 8.9.10.
The names for the zone files can be any name we want.
At the end the named.conf file must be like this:





Now let's write our zone file for rukia.com (/var/named/named.rukia), we'll also add in it the name goku.rukia.com for the client 10.9.8.1 and also that if we search for the name www.rukia.com it will give us the IP 10.9.8.50.
So the file must look like this:





I'll explain the file line by line (from line 0 to 10, without counting spaces)

0 - The TTL is set, the TTL is the Time To Live that the consults to the cache will persist instead of consulting the server, this means that if a domain has already been consulted, and another consult is done inside the TTL time, the consult will be made to the cache, but if this time has expired the consult will be made to the server. In the example I put 120 seconds, thinking in critic situations where the domain name has to be updated instantly. The default time is 6054800 seconds.

1 - The SOA is set and the email account of the domain administrator. The email is written like this: rukia.rukia.com, the @ is changed for a period, but the real email is rukia@rukia.com.

2 to 6 - The SOA parameters.

7 - The NameServer is set for the domain, in this case is the same server (rukia.com). The @ makes reference to the domain name to which the zone belongs, in this case is rukia.com. This means that for this zone @=rukia.com.

8 - The rukia.com domain is pointed to the IP 10.9.8.50.

9 - The canonical name www.rukia.com is set. This means that if rukia.com or www.rukia.com is resolved the answer will always be 10.9.8.50.

10 - The domain name goku.rukia.com is set to the IP 10.9.8.1.

Now let's create the reverse zone file for our network (/var/named/named.rukiaRev):





Again I'll explain the file line by line (0 to 9, without counting spaces)

0 - TTL.

1 - The SOA and the administrator email is set.

2 to 6 - SOA parameters.

7 - The NameServer is set, in this case is the same server.

8 - The IP 10.9.8.50 is pointed to the domain rukia.com. Note that is only written the host address from theIP. The network address is 10.9.8.0, so the host address is 0.0.0.50.

9 - The IP 10.9.8.1 is pointed to the domain goku.rukia.com.

To start the service we execute this command:





And ready we have a simple local DNS.



Configuration of the DNS for the clients

To set the DNS in the clients we just have to add the DNS IP to our network configuration. I'll explain how to do it with the console, in graphic mode is with the network manager in the manual configuration section for IPv4.

In console we just have to edit the file:





In it we add the next line where we set that our DNS is the server with the IP 10.9.8.50:




With this our clients can now make requests to our server.



How to check the domain names resolution

We can use the commands nslookup and dig, the difference is that dig sends a bit more information.

Check with nslookup:





Check with dig:





And well that is like you can configure a DNS for a LAN really simple and quick.

Any doubt comment please.

viernes, 13 de julio de 2012

Instalar un DNS local en Linux con Bind

Hola hoy voy a escribir sobre como montar un servidor DNS rápido y básico en una red local.

Primero veremos los tipos que existen de DNS y los registros DNS.

Tipos de DNS

Master (Maestro o Primario): Aloja los registros autoritarios de una zona, responde las peticiones de resolución de nombres como servidor de autoridad y delega copias a los servidores esclavo.

Slave (Esclavo o Secundario): Responde a las peticiones de resolución de nombres como servidor de autoridad, pero la información es distribuida por los servidores primarios.

Caching­only (Sólo de cache): Responde a las peticiones de resolución de nombres pero no es servidor de autoridad, las respuestas las guarda en memoria por un período determinado.

Forwarding (de reenvío): Reenvía las peticiones a una lista de servidores de nombres.



Registros DNS

A (Address): Define una dirección IP y el nombre asignado al host.

AAAA: Son el reemplazo de los registros A cuando la traducción que se lleva acabo es de nombre a dirección IPv6.

MX (Mail eXchanger): Se usa para identificar servidores de correo.

CNAME (Canonical Name): Es un alias que se asigna a un host que tiene una dirección IP valida y que responde a diversos nombres. Pueden declararse varios para un host.

NS (Name Server): Define los servidores de nombre principales de un dominio. Debe haber al menos uno.

SOA (Start Of Authority): Este es el primer registro de la zona y sólo puede haber uno en cada archivo de la zona y sólo está presente si el servidor es autoritario del dominio. Especifica el servidor DNS primario del dominio, la cuenta de correo del administrador y tiempos de refresco.

PTR (Domain Name Pointer): Indica a que dirección IP corresponde un nombre.



Parámetros del registro SOA

Serial: El número serial se utiliza para sincronizar las zonas entre los DNS primarios y secundarios. Si el DNS secundario al consultar el primario encuentra que el número serial es mayor al que tiene actualmente quiere decir que se ha actualizado el archivo de zona, por lo que solicitará una copia de la versión actualizada.

Refresh: Es el tiempo que un DNS secundario debe esperar para comprobar nuevamente los valores de registro de un DNS primario.

Retry: Es el tiempo que un DNS secundario debe esperar después de un intento fallido en recuperar datos de un DNS primario.

Expire: Es el tiempo que durarán los datos en un DNS secundario antes de que expiren.

Negative Cache TTL: Es el tiempo que el caché del DNS recordará las consultas negativas (NXDOMAIN)

Bueno ya que vimos algo de teoría empezemos con la instalación y configuración para distribuciones Ubuntu y Fedora.



Instalación y configuración para Ubuntu y similares

Versiones en el ejemplo: Ubuntu 10.04, Bind 9.7.0-P1
Si las versiones son distintas a estas puede haber algunas variaciones, pero siempre y cuando sea un Bind 9 no debe haber problema.

Instalación:






Ahora hay que ir a la carpeta /etc/bind ahí encontraremos nuestros archivos de configuración.

Bueno, para el ejemplo utilizaremos el dominio rukia.com, que será también nuestro DNS, en el ejemplo el servidor tiene la IP 10.9.8.50 (rukia.com) y nuestro cliente de ejemplo es la IP 10.9.8.1 a la cual le pondremos de nombre de dominio goku.rukia.com.

El primer archivo a editar es donde se declaran las zonas:






El archivo por default tiene el siguiente contenido:





En este contenido se declaran las siguientes zonas: los DNS raíz principales públicos, localhost, inversa de localhost, broadcast e inversa de broadcast

Para nuestra propia zona utilizando de ejemplo que queremos agregar el dominio rukia.com y que el nombre de arhivo de zona es db.rukia, agregamos la zona de la siguiente forma:







Ahora agregamos el archivo de zona inversa. La zona inversa es para resolver a partir de una IP para que devuelva el nombre de dominio. Para el ejemplo agregamos la zona inversa de la red 10.9.8.0, que es la red a la cual pertenecen nuestras IP de ejemplo (10.9.8.1 y 10.9.8.50) y de nombre para el archivo de zona inversa como db.rukiaRev:






Noten que la dirección de red se escribe al revés, nuestra red es 10.9.8.0, así que se escribió 8.9.10.
Los nombres para los archivo de zona pueden ser los que queramos.
Al final el archivo named.conf.default-zones debe quedar de la siguiente forma:






Antes de seguir con las zonas revisemos que el archivo named.conf incluya al archivo named.conf.default-zones, para esto sólo hay que leer el siguiente archivo para ver que incluya lo que necesitamos:







El archivo debe contener lo siguiente:







Ahora hagamos nuestro archivo de zona para rukia.com (/etc/bind/db.rukia), en el también agregaremos el nombre goku.rukia.com para el cliente 10.9.8.1 y también que si buscamos el nombre www.rukia.com pueda responder a la IP 10.9.8.50.
Entonces el archivo debe verse así:





Explicaré el archivo por líneas (de la 0 hasta la 10, sin contar espacios)

0 - Se establece el tiempo del TTL, el TTL es el tiempo de vida que durarán las consultas a caché en lugar del servidor , esto quiere decir que si ya se hizo una consulta a un dominio, y se hace otra consulta dentro del tiempo de TTL, la consulta se realizará al caché, de lo contrario si ya expiró el tiempo se hará nuevamente al servidor. En el ejemplo puse solamente 120 segundos, pensando en situaciones critícas en que se necesita actualizar un nombre de dominio y el cambio debe verse al instante. El tiempo de default es 604800 segundos.

1 - Se establece el SOA y la cuenta de correo del administrador del dominio. El correo se escribió de esta forma: rukia.rukia.com, se sustituye el @ por un punto, en realidad el correo es rukia@rukia.com.

2 al 6 - Parámetros del SOA.

7 - Se establece el NameServer para el dominio, en este caso es el mismo servidor (rukia.com). La @ hace referencia al nombre de dominio al que pertenece la zona, en este caso es rukia.com. Esto quiere decir que para esta zona @=rukia.com.

8 - Se apunta el dominio rukia.com a la IP 10.9.8.50.

9 - Se establece el nombre canonico www rukia.com. Esto quiere decir que si se resuelve rukia.com o www.rukia.com la respuesta siempre será 10.9.8.50.

10 - Se le establece el nombre de dominio goku.rukia.com a la IP 10.9.8.1.

Ahora vamos a crear el archivo de zona inversa para nuestra red (/etc/bind/db.rukiaRev):







Nuevamente explicaré el archivo por líneas (0 a 9, sin contar espacios)

0 - TTL.

1 - Establece SOA y cuenta de correo del administrador .

2 al 6 - Parámetros del SOA.

7 - Se establece el NameServer, en este caso es el mismo servidor.

8 - Se apunta la IP 10.9.8.50 al dominio rukia.com. Noten que sólo se escribe la dirección de host de la IP. La dirección de red es 10.9.8.0, así que la de host es 0.0.0.50.

9 - se apunta la IP 10.9.8.1 al dominio goku.rukia.com.

Ahora sólo falta el archivo named.conf.options, pero para Ubuntu no se necesita editar, sólo en caso de presentar problemas en la resolución inversa o que se muestre un error que diga que el DNS rechaza las conexiones al momento de intentar resolver los nombres de dominio desde un cliente, verifiquen que se agreguen las siguientes opciones al archivo /etc/bind/named.conf.options para evitar esos errores:






Para iniciar el servicio ejecutamos el siguiente comando:




Y listo ya tenemos un DNS rápido y funcional para nuestra LAN.



Instalación y configuración para  Fedora y similares

Versiones en el ejemplo: Fedora 16 Security Spin, Bind 9.8.3-P1-RedHat-9.8.3-2.P1.fc16
Si las versiones son distintas a estas puede haber algunas variaciones, pero siempre y cuando sea un Bind 9 no debe haber problema.


Instalación:





Bueno, para el ejemplo utilizaremos el dominio rukia.com, que será también nuestro DNS, en el ejemplo el servidor tiene la IP 10.9.8.50 (rukia.com) y nuestro cliente de ejemplo es la IP 10.9.8.1 a la cual le pondremos de nombre de dominio goku.rukia.com.

El primer archivo a editar es el archivo named.conf:






En este archivo se declarán las opciones para nuestro DNS y las zonas, por default el archivo ya contiene lo siguiente:





En este archivo, las opciones que nos interesan editar son:

listen-on-port 53 { 127.0.0.1; }; - Aquí se establece que el servidor estará escuchando en el puerto 53 para la IP del localhost. Aquí hay que agregar la IP local de nuestro equipo para que pueda atender peticiones de los clientes en la LAN, en este caso agregaremos la IP del ejemplo que es 10.9.8.50.

directory "/var/named"; - Se establece el directorio donde se van a encontrar los archivos de zona, puede ser otro directorio siempre y cuando el servicio named tenga permisos para leer. Para el ejemplo dejaremos este directorio default.

allow-query { localhost; }; - Se establece a quienes se les va a permitir hacer consultas nuestro DNS, por default sólo se le permite a localhost como se puede observar. Para el ejemplo sólo permitiremos a localhost y nuestra red local, por lo que agregaremos 10.9.8.0/24. Si queremos que cualquier cliente haga consultas a nuestro DNS sólo agregamos la palabra any en lugar de localhost o una dirección de red.

recursion yes; - Permitir la consulta inversa. Quiere decir que si hacemos una consulta para obtener el nombre de dominio a través de una IP sea permitido.

También viene ya declarado por default los DNS raíz principales públicos.

A continuación se ve como debe quedar nuestra sección de opciones, en la que además de escuchar el puerto 53 en la IP 127.0.0.1, también lo hará en la IP local asignada al servidor (10.9.8.50), se establecerá el directorio /var/named como el directorio de archivos de zona, que tambíen permitirá consultas a localhost y la red de la LAN y permitirá consultas inversas:




Para nuestra propia zona utilizando de ejemplo que queremos agregar el dominio rukia.com y que el nombre de arhivo de zona es named.rukia, agregamos la zona de la siguiente forma:






Ahora agregamos el archivo de zona inversa. La zona inversa es para resolver a partir de una IP para que devuelva el nombre de dominio. Para el ejemplo agregamos la zona inversa de la red 10.9.8.0, que es la red a la cual pertenecen nuestras IP de ejemplo (10.9.8.1 y 10.9.8.50) y de nombre para el archivo de zona inversa como named.rukiaRev:




 
 

Noten que la dirección de red se escribe al revés, nuestra red es 10.9.8.0, así que se escribió 8.9.10.
Los nombres para los archivo de zona pueden ser los que queramos.
Al final el archivo named.conf debe quedar de la siguiente forma:






Ahora hagamos nuestro archivo de zona para rukia.com (/var/named/named.rukia), en el también agregaremos el nombre goku.rukia.com para el cliente 10.9.8.1 y también que si buscamos el nombre www.rukia.com pueda responder a la IP 10.9.8.50.
Entonces el archivo debe verse así:





Explicaré el archivo por líneas (de la 0 hasta la 10, sin contar espacios)

0 - Se establece el tiempo del TTL, el TTL es el tiempo de vida que durarán las consultas a caché en lugar del servidor , esto quiere decir que si ya se hizo una consulta a un dominio, y se hace otra consulta dentro del tiempo de TTL, la consulta se realizará al caché, de lo contrario si ya expiró el tiempo se hará nuevamente al servidor. En el ejemplo puse solamente 120 segundos, pensando en situaciones critícas en que se necesita actualizar un nombre de dominio y el cambio debe verse al instante. El tiempo de default es 604800 segundos.

1 - Se establece el SOA y la cuenta de correo del administrador del dominio. El correo se escribió de esta forma: rukia.rukia.com, se sustituye el @ por un punto, en realidad el correo es rukia@rukia.com.

2 al 6 - Parámetros del SOA.

7 - Se establece el NameServer para el dominio, en este caso es el mismo servidor (rukia.com). La @ hace referencia al nombre de dominio al que pertenece la zona, en este caso es rukia.com. Esto quiere decir que para esta zona @=rukia.com.

8 - Se apunta el dominio rukia.com a la IP 10.9.8.50.

9 - Se establece el nombre canonico www rukia.com. Esto quiere decir que si se resuelve rukia.com o www.rukia.com la respuesta siempre será 10.9.8.50.

10 - Se le establece el nombre de dominio goku.rukia.com a la IP 10.9.8.1.

 Ahora vamos a crear el archivo de zona inversa para nuestra red (/var/named/named.rukiaRev):






Nuevamente explicaré el archivo por líneas (0 a 9, sin contar espacios)

0 - TTL.

1 - Establece SOA y cuenta de correo del administrador .

2 al 6 - Parámetros del SOA.

7 - Se establece el NameServer, en este caso es el mismo servidor.

8 - Se apunta la IP 10.9.8.50 al dominio rukia.com. Noten que sólo se escribe la dirección de host de la IP. La dirección de red es 10.9.8.0, así que la de host es 0.0.0.50.

9 - se apunta la IP 10.9.8.1 al dominio goku.rukia.com.


Para iniciar el servicio ejecutamos el siguiente comando:






Y listo ya tenemos un DNS sencillo para nuestra LAN.



Configuración del DNS en los clientes

Para establecer el DNS en los clientes sólo hay que agregar la IP del servidor de nombres de dominio o DNS a nuestra configuración de red. Voy a explicar como se haría en modo consola, en modo gráfico es con el editor de conexiones de red en configuración manual para IPv4.

En consola sólo hay que editar el archivo:






En el agregamos la siguiente línea en donde establecemos que nuestro DNS es el servidor con la IP 10.9.8.50:




Ya con esto nuestroa clientes podrán consultar a nuestro DNS.



Como comprobar la resolución de nombres de dominio

Se pueden utilizar los comandos nslookup y dig, la diferencia es que dig nos manda un poco más de información.

Comprobar con nslookup:






Comprobar con dig:






Y bueno así es como se puede configurar un DNS para una LAN de forma rápida y sencilla.

Cualquier duda comenten. Saludos!

lunes, 9 de julio de 2012

Synchronize network directories with Linux

Today I'll write about how to have a network synchronized folder using SSHFS.

SSHFS is a filesystem that is mounted as a client of a remote folder. It uses the SFTP protocol.
With SSHFS if you make a change in a file it will be reflected immediately in the other computer. If we edit a file in the client that has mounted the remote folder, the change will be reflected in the remote computer and the same if we do it the other way.

You only need to install SSHFS in the client, you don't need it in the server, the only service you need at the server is the SSH service installed and running.

Installation

For Fedora and similars:




For Ubuntu and similars:





Configuration

The first thing we have to do is choose the folder we want to synchronize, so the computer where that folder is would be the server.
In the example I'll use the directory /home/rukia/foo in which the owner and group is rukia.

In the client we create a folder. In the example I'll use the directory /home/goku/fooG in which the owner and group is goku and the UID and GID is 1000. I put a different name to the folder to avoid confussions but it can have the same name.

Let's create the folder /home/goku/fooG:




Now we mount the remote folder in fooG.
Before doing this I'll explain an option that we can apply to the SSHFS command.
With this option we established if we want the directory and files of the client to have the same owner of the folder at the server or if we want that each folder has it's own owner and group.



User and group options for SSHFS

The option for establishing the user and group is idmap=Type

Where type can be:

none: The UID and GID won't be changed, SSHFS will use the owner and group of the remote directory (default option).
user: It only changes the server UID for the client UID at the client.
file: Takes the UID and GID written at a file (I still don't know how is the format of this file).

For our examples will use the user type but we will also specify the GID.

Mount the remote directory establishing the UID an GID of the client:




And now we have a synchronized folder. If we make a ls in the client directory we'll see that the owner and group is our user, while in the server it still has it's own user and group.
And the best part is that if rukia or goku write, the permissions won't change, in the client goku will still be the owner and in the server will still be rukia.

But if we had chosen none in the idmap option then the owner and group for both parts will be the owner and group of the server. But even though the client can still write in the directory and the permissions won't change.


How to synchronized the folder at startup

Now we just have to make our folder available from the startup, fot this we add the next line at /etc/rc.local on top of exit 0:






Mount the directory without a password

If we want the before explanation to work and our directory can be mounted at system boot, we have to avoid the remote computer to ask for a SSH password. We can solve this creating public keys.

We create the key for the client user:




For default the key is savedd in the .ssh home directory of the user that generated it, in our example is goku, so the key is:




Now we have to copy this key to the server, we can do it with scp, the key has to be inside the file authorized_keys that is in the .ssh home directory of the ssh user that we'll use to log in, in this case is rukia. So we have to apply the next commands:

Copy the key to the server:




Add it to the authorized_keys file (this is done in the server side):




And finally for security reasons we just give permissions to the owner of the file:



And we have our synchronized folder. This can be done in more computers not just with one, you can have more clients using the same folder applying all this steps.
I hope this tutorial is useful, any doubt or complaint just comment.

viernes, 6 de julio de 2012

Sincronizar carpetas en red con Linux

Hola hoy escribiré sobre como tener una carpeta sincronizada en red utilizando SSHFS.

SSHFS es un sistema de archivos que se monta como cliente de un directorio remoto. Utiliza el protocolo SFTP.
Con SSHFS el cambio que se realice en un archivo se reflejará inmediatamente en el otro sitio. Si editamos un archivo en el cliente que tiene montada la carpeta remota se reflejará al momento el cambio en la ubicación remota y lo mismo pasa si hacemos esto en viceversa.

La instalación, esta sólo se realiza en el equipo cliente, no se necesita en el equipo servidor, lo único que debe tener el equipo servidor es el servicio de SSH instalado y corriendo.

Instalación

Para Fedora y similares:



Para Ubuntu y similares:



Configuración

Lo primero que hay que hacer es elegir el directorio que queremos sincronizar, este será entonces el equipo servidor. Debemos darle los permisos necesarios.
En el ejemplo utilizaré el directorio /home/rukia/foo del cual es dueño rukia y pertenece al grupo rukia.

En el equipo cliente creamos una carpeta en un directorio en el cual podemos escribir. En el ejemplo utilizaré el directorio /home/goku/fooG del cual es dueño goku y pertenece al grupo goku y su UID y GID es 1000. Le puse un nombre distinto al directorio para diferenciarlos pero se le puede poner el mismo también, no hay ningún problema.

Creamos la carpeta /home/goku/fooG:




Ahora montamos la carpeta remota en fooG.
Antes de hacerlo les explicaré unas opciones que se pueden aplicar al comando SSHFS. Con está opción establecemos si queremos que el directorio y archivos del cliente tenga el mismo dueño que en el servidor o si queremos que cada carpeta tenga su propio dueño y grupo.


Opciones de usuario y grupo para SSHFS

La opción para establecer usuario y grupo es idmap=Tipo

Donde tipo puede ser:

none: No se cambiará el UID y GID, se utilizarán los del dueño del directorio en el servidor (es la opción de default)
user:  Sólo se cambia el UID del servidor por el del cliente.
file: Toma el UID Y GID de un archivo donde se establecen. (Aún no se como hacer este archivo).

Para nuestros ejemplos utilizaremos el tipo user pero ademas le vamos a especificar el GID.

Montar el directorio remoto estableciendo el UID y GID del cliente:





Y listo ya tenemos una carpeta sincronizada. Si damos un ls en el directorio cliente veremos que el dueño y grupo es nuestro usuario, mientras que en el servidor sigue siendo el usuario y grupo establecidos en el.
Y lo mejor es que si rukia o goku escriben, los permisos no cambian, en el cliente goku seguirá siendo el dueño y en el servidor lo seguirá siendo rukia.

Pero si hubieramos elegido none en idmap entonces el dueño y grupo sería el del servidor para ambas partes. Pero aún así el cliente puede escribir en el directorio y los permisos no cambian.


Tener la carpeta sincronizada al iniciar el sistema

Ahora sólo falta que nuestra carpeta se encuentre montada al iniciar el sistema, para eso agregamos la siguiente línea a /etc/rc.local arriba de exit 0





Montar el directorio sin que pida contraseña

Para que funcione lo anterior y nuestro directorio se encuentre montado al iniciar el sistema hay que evitar que pregunte por contraseña. Esto se soluciona creando unas llaves publicas.

Creamos la llave para el usuario cliente:




Por default la llave se guarda en el directorio .ssh del home del usuario que la generó, en nuestro ejemplo es goku asi que la llave sería:





Ahora hay que copiar esta llave al servidor, lo podemos hacer con scp, la llave debe ir en el archivo authorized_keys que se encuentra en .ssh en el home del usuario ssh con el que nos loguearemos, en este caso es rukia. Así que debemos aplicar los siguientes comandos:

Copiar la llave al servidor:




Agregarla al archivo authorized_keys (esto se hace del lado del servidor):





Y finalmente por seguridad le damos sólo permisos al dueño del archivo:





Y listo tenemos una carpeta sincronizada. Esto se puede hacer en varios equipos no sólo con uno, pueden tener más clientes utilizando la carpeta compartida aplicando todos estos pasos.
Espero les sirva este tutorial, cualquier cosa comenten. Saludos!

martes, 3 de julio de 2012

Unix permissions: The sticky, SUID and SGID bits

Hello, today I'll write about more permissions, this time it will be about the Sticky, SUID and SGID bits.
I'll write about them because one of my readers told me that it would be a good idea to write about these bits.

Sticky bit

What the sticky bit does is that when you execute an application it will be residing in the memory, so if other user (thinking in a multiuser environment) executes that same application it will run faster because it's already active in memory.
So this permission fastens the executions if multiple users are using the same application.

SUID bit

If we apply the SUID bit to an application, it will run with the UID of the owner even if you are logged in as another user. For example if all the users need to execute fdisk without using sudo or escalate to root we just have to apply this bit to fdisk.

SGID bit

The same as SUID but it applies to the group owner of the application.


The SUID bit to execute bash scripts as root

Even if we can apply SGID to execute applications with a different user as the one we are logged in, there are things we can't do even if the owner of the script is root.

First of all, for a script to execute as root we have to apply the SUID bit to the shell we use to execute scripts, because the application in this case is the shell, the script is just a file that will be interpreted by the shell.

Special commandas like adduser can't be executed by any other user even if it has the SUID bit of root. So it won't work a script that executes the adduser command even if the shell has the SUID bit. If you don't believe me tray it ;) I even set the SUID bit for root to my shell, to adduser, to my script that executes adduser and the system didn't permit it.


The SUID bit and GTK+

GTK doesn't support the use of SUID or SGID. So if you try to run a GTK based application with one of these birs the execution will send and alert and it will not start.


Then how can we use these bits?

It can be used to create scripts that write files inside directories in which other users don't have permissions. For example, that any user can create a file inside the root home directory.
Or like I said it before, is possible to use some applications with SUID and SGID like fdisk.

And now you may be asking, well a script to write file in /root, but hadn't you said that to make this work you have to apply the SUID bit to the shell? OK, do this can be risky, to let the shell execute always as root with any user, but there is a trick to make it work without making all your shell root.

We just have to copy our shell to other directory and in that copy apply the SUID bit so the original shell doesn't have to be executed always by root. Then we point our sh to this shell.
Even though this is not a good practice because it isn't secure to allow scripts to be executed as root, but SGID can make easy a lot of things if the server or computer where it is going to be apply is managed only by the right people or SysAdmins.


The commands to apply the SUID bit to a copy of the shell:

First we find where is our shell:






This will show us if we are using dash or bash, now let's find it's real location with the result of the last command, let's use as example that it is bash and let's search as root or with sudo so we don't have errors y our search:





Now that we know where it is let's copy it to other place, in this example will be to rukia's home from /bin/bash:






And finally we just apply SUID or SGID to the shell copy.



The commands to apply these bits are:

SUID:





Remove SUID:





SGID:




Remove SGID:






Apply sticky bit:





Remove sticky bit:






How permissions are visualized

How permissions will be visualized for SUID if the owner doesn't have execute permissions for the application, in this example the owner only has reading and writing permissions, group reading permissions, other users reading permissions. Applying SUID:






Visualization with SUID if the owner has execute permissions, in this example the owner has reading, writing and execute permissions, group reading permissions, other  users reading permissions. Applying SUID:






Visualization with SGID if the group doesn't have execute permissions, in this example the owner has reading permissions, group reading and writing permissions, other users reading permissions. Applying SGID:






Visualization with SGID if the group has execute permissions, in this example the owner has reading permissions, group reading and execute permissions, other users reading permissions. Applying SGID:







Visualization of the sticky bit if other users doesn't have execute permissions, in this example the owner and group have all permissions, other users only reading and writing permissions. Applying sticky bit:






Visualization of the sticky bit if other users have execute permissions, in this example the owner, group and other users have all permissions. Applying sticky bit:






And that is all I know right now about these bits, hope it helps and if something is wrong please tell me as I'm new to these bits too.