One place for hosting & domains

      Cómo engañar a una red neural en Phyton 3


      El autor seleccionó a Dev Color para recibir una donación como parte del programa Write for DOnations.

      ¿Sería posible engañar a una red neural para la clasificación de animales? Engañar a un clasificador de animales puede tener algunas consecuencias, ¿pero si pudiésemos engañar a nuestro autenticador facial? ¿O al software del prototipo de un vehículo autónomo? Afortunadamente, legiones de ingenieros e investigaciones están entre un modelo de visión computarizada de un prototipo y los modelos de calidad de producción, en nuestros dispositivos móviles o en nuestros vehículos. Aun así, estos riesgos tienen implicaciones significativas y es importante tenerlos en cuenta como profesional del aprendizaje automático.

      En este tutorial, intentará “engañar” a un clasificador de animales. A medida que avanza en este tutorial, usará OpenCV, una biblioteca de visión de computadora, y PyTorch, una biblioteca de aprendizaje profundo. Cubrirá los siguientes temas en el campo asociado de aprendizaje automático contradictorio:

      • Cree un ejemplo contradictorio objetivo. Seleccione una imagen, digamos un perro. Seleccione una clase objetivo, por ejemplo un gato. Su objetivo es engañar a la red neural para que crea que el perro de la imagen es un gato.
      • Cree una defensa contradictoria. En resumen, proteja su red neural contra estas imágenes engañosas, sin que sepa cuál es el truco.

      Al final de este tutorial, tendrá una herramienta para engañar a las redes neurales y comprenderá cómo defenderse contra los trucos.

      Requisitos previos

      Para completar este tutorial, necesitará lo siguiente:

      Paso 1: Clonar su proyecto e instalar las dependencias

      Vamos a crear un espacio de trabajo para este proyecto e instalaremos las dependencias que va a necesitar. Llamará a su espacio de trabajo AdversarialML:

      Diríjase al directorio AdversarialML:

      Cree un directorio para albergar sus activos:

      • mkdir ~/AdversarialML/assets

      Luego, cree un nuevo entorno virtual para el proyecto:

      • python3 -m venv adversarialml

      Active su entorno:

      • source adversarialml/bin/activate

      A continuación, instale PyTorch, un marco de trabajo de aprendizaje profundo para Python que utilizaremos en este tutorial.

      En macOS, instale Pytorch con el siguiente comando:

      • python -m pip install torch==1.2.0 torchvision==0.4.0

      En Linux y Windows, utilice los siguientes comandos para una compilación solo de CPU:

      • pip install torch==1.2.0+cpu torchvision==0.4.0+cpu -f https://download.pytorch.org/whl/torch_stable.html
      • pip install torchvision

      Ahora instale los binarios empaquetados previamente para OpenCV y numpy, que son bibliotecas para la visión computarizada y el álgebra lineal, respectivamente. OpenCV ofrece utilidades como las rotaciones de imágenes y numpy ofrece utilidades de álgebra lineal, como la inversión de una matriz:

      • python -m pip install opencv-python==3.4.3.18 numpy==1.14.5

      En las distribuciones de Linux, deberá instalar libSM.so:

      • sudo apt-get install libsm6 libxext6 libxrender-dev

      Con las dependencias instaladas, vamos a ejecutar y clasificador de animales llamado ResNet18, que describiremos a continuación.

      Paso 2: Ejecutar un clasificador de animales preentrenado

      La biblioteca torchvision, la biblioteca de visión computarizada oficial para PyTorch, contiene versiones preentrenadas de redes neurales de visión computarizada usadas comúnmente. Estas redes neurales están entrenadas sobre ImageNet 2012, un conjunto de datos de 1,2 millones de imágenes de entrenamiento con 1000 clases. Estas clases incluyen vehículos, lugares y, sobre todo, animales. En este paso, ejecutará una de estas redes neurales preentrenadas, llamada ResNet18. Nos referiremos a ResNet18 entrenado en ImageNet como un “clasificador de animales”.

      ¿Qué es ResNet18? ResNet18 es la red neural más pequeña en una familia de redes neurales llamada redes neurales residuales, desarrollada por MSR (He et al.). En resumen, He descubrió que una red neural (denominada como una función f, con entrada x, y salida f(x) funcionaría mejor con una “conexión residual” x + f(x). Esta conexión residual se utiliza prolíficamente en redes neurales de última generación, incluso hoy en día. Por ejemplo, FBNetV2, FBNetV3.

      Descargue esta imagen de un perro con el siguiente comando:

      • wget -O assets/dog.jpg https://xpresservers.com/wp-content/uploads/2020/06/How-To-Trick-a-Neural-Network-in-Python-3.png

      Imagen de un corgi corriendo cerca de un estanque

      A continuación, descargue un archivo JSON para convertir el resultado de la red neural a un nombre de clase legible por el ser humano:

      • wget -O assets/imagenet_idx_to_label.json https://raw.githubusercontent.com/do-community/tricking-neural-networks/master/utils/imagenet_idx_to_label.json

      A continuación, cree una secuencia de comandos para ejecutar su modelo preentrenado sobre la imagen del perro. Cree un nuevo archivo llamado step_2_pretrained.py:

      • nano step_2_pretrained.py

      Primero, añada el texto estándar de Python importando los paquetes necesarios y declarando una función main:

      step_2_pretrained.py

      from PIL import Image
      import json
      import torchvision.models as models
      import torchvision.transforms as transforms
      import torch
      import sys
      
      def main():
          pass
      
      if __name__ == '__main__':
          main()
      

      A continuación, cargue la asignación desde el resultado de la red neural a nombres de clase legibles por el ser humano. Añada esto directamente tras sus declaraciones de importación y antes de su función main:

      step_2_pretrained.py

      . . .
      def get_idx_to_label():
          with open("assets/imagenet_idx_to_label.json") as f:
              return json.load(f)
      . . .
      

      Cree una función de transformación de imagen que garantizará que primero su imagen de entrada tenga las dimensiones correctas, y segundo que se haya normalizado correctamente. Añada la siguiente función directamente tras la última:

      step_2_pretrained.py

      . . .
      def get_image_transform():
          transform = transforms.Compose([
            transforms.Resize(224),
            transforms.CenterCrop(224),
            transforms.ToTensor(),
            transforms.Normalize(mean=[0.485, 0.456, 0.406],
                                 std=[0.229, 0.224, 0.225])
          ])
          return transform
      . . .
      

      En get_image_transform, define un número de diferentes transformaciones que aplicar a las imágenes que se pasan a su red neural.

      • transforms.Resize(224): cambia el tamaño del lado más pequeño de la imagen a 224. Por ejemplo, si su imagen es 448 x 672, esta operación reduciría la imagen a 224 x 336.
      • transforms.CenterCrop(224): hace un recorte desde el centro de la imagen, de un tamaño de 224 x 224.
      • transforms.ToTensor(): convierte la imagen a un tensor PyTorch. Todos los modelos requieren tensores PyTorch como entrada.
      • transforms.Normalize(mean=..., std=...): normaliza su entrada sustrayendo la media y, luego, dividiendo la desviación estándar. Esto se describe de forma más precisa en la documentación de torchvision.

      Añada una utilidad para predecir la clase animal, dada la imagen. Este método usa las utilidades anteriores para realizar la clasificación de animales:

      step_2_pretrained.py

      . . .
      def predict(image):
          model = models.resnet18(pretrained=True)
          model.eval()
      
          out = model(image)
      
          _, pred = torch.max(out, 1)  
          idx_to_label = get_idx_to_label()  
          cls = idx_to_label[str(int(pred))]  
          return cls
      . . .
      

      Aquí la función predict clasifica la imagen proporcionada usando una red neural preentrenada:

      • models.resnet18(pretrained=True): carga una red neural preentrenada llamada ResNet18.
      • model.eval(): modifica el modelo implementado para que se ejecute en modo “evaluación”. El único otro modo es el modo “entrenamiento”, pero el modo de entrenamiento no es necesario, ya que no está entrenando el modelo (es decir, actualizando los parámetros del modelo) en este tutorial.
      • out = model(image): ejecuta la red neural sobre la imagen transformada que se proporciona.
      • _, pred = torch.max(out, 1): la red neural da como resultado una probabilidad para cada clase posible. Este paso calcula el índice de la clase con la más alta probabilidad. Por ejemplo, si out = [0.4, 0.1, 0.2], entonces pred = 0.
      • idx_to_label = get_idx_to_label(): obtiene una asignación desde el índice de clase a nombres de clase legibles por el ser humano. Por ejemplo, la asignación podría ser {0: cat, 1: dog, 2: fish}.
      • cls = idx_to_label[str(int(pred))]: convierte el índice de clase predicho a un nombre de clase. Los ejemplos proporcionados en los últimos dos puntos arrojarían cls = idx_to_label[0] = 'cat.

      A continuación, tras la última función, añada una utilidad para cargar imágenes:

      step_2_pretrained.py

      . . .
      def load_image():
          assert len(sys.argv) > 1, 'Need to pass path to image'
          image = Image.open(sys.argv[1])
      
          transform = get_image_transform()
          image = transform(image)[None]
          return image
      . . .
      

      Esto cargará una imagen desde la ruta proporcionada en el primer argumento a la secuencia de comandos. transform(image)[None] aplica la secuencia de las transformaciones de la imagen definidas en las líneas anteriores.

      Finalmente, complete su función main con lo siguiente para cargar su imagen y clasificar el animal de la imagen:

      step_2_pretrained.py

      def main():
          x = load_image()
          print(f'Prediction: {predict(x)}')
      

      Compruebe que su archivo coincida con la secuencia de comandos final del paso 2 en step_2_pretrained.py en GitHub. Guarde y salga de su secuencia de comandos, y ejecute el clasificador de animales.

      • python step_2_pretrained.py assets/dog.jpg

      Esto producirá el siguiente resultado, lo que muestra que su clasificador de animales funciona como se espera:

      Output

      Prediction: Pembroke, Pembroke Welsh corgi

      Eso concluye ejecutar la interferencia con su modelo preentrenado. A continuación, verá un ejemplo contradictorio en acción engañando a una red neural con diferencias imperceptibles en la imagen.

      Paso 3: Probar un ejemplo contradictorio

      Ahora, sintetizará un ejemplo contradictorio, y probará la red neural en ese ejemplo. Para este tutorial, creará ejemplos contradictorios en formato x + r, donde x es la imagen original y r es cierta “perturbación”. Eventualmente creará la perturbación r usted mismo, pero, en este paso, descargará una que hemos creado de antemano. Comience descargando la perturbación r:

      • wget -O assets/adversarial_r.npy https://github.com/do-community/tricking-neural-networks/blob/master/outputs/adversarial_r.npy?raw=true

      Ahora componga la imagen con la perturbación. Cree un nuevo archivo llamado step_3_adversarial.py:

      • nano step_3_adversarial.py

      En este archivo, realizará el siguiente proceso de tres pasos para producir un ejemplo contradictorio:

      1. Transformar una imagen
      2. Aplicar la perturbación r
      3. Transformar a la inversa la imagen perturbada

      Al final del paso 3, tendrá una imagen contradictoria. Primero, importe los paquetes necesarios y declare una función main:

      step_3_adversarial.py

      from PIL import Image
      import torchvision.transforms as transforms
      import torch
      import numpy as np
      import os
      import sys
      
      from step_2_pretrained import get_idx_to_label, get_image_transform, predict, load_image
      
      
      def main():
          pass
      
      
      if __name__ == '__main__':
          main()
      

      A continuación, cree una “transformación de imagen” que invierta la transformación de la imagen anterior. Ponga esto tras sus importaciones, antes de la función main:

      step_3_adversarial.py

      . . .
      def get_inverse_transform():
          return transforms.Normalize(
              mean=[-0.485/0.229, -0.456/0.224, -0.406/0.255],  # INVERSE normalize images, according to https://pytorch.org/docs/stable/torchvision/models.html
              std=[1/0.229, 1/0.224, 1/0.255])
      . . .
      

      Como antes, la operación transforms.Normalize sustrae la media y divide por la desviación estándar (es decir, para la imagen original x, y = transforms.Normalize(mean=u, std=o) = (x - u) / o). Haga algo de álgebra y defina una nueva operación que invierta esta función normalizar (transforms.Normalize(mean=-u/o, std=1/o) = (y - -u/o) / 1/o = (y + u/o) o = yo + u = x).

      Como parte de la transformación inversa, añada un método que transforme un tensor PyTorch de vuelta a una imagen PIL. Añada esto tras la última función:

      step_3_adversarial.py

      . . .
      def tensor_to_image(tensor):
          x = tensor.data.numpy().transpose(1, 2, 0) * 255.  
          x = np.clip(x, 0, 255)
          return Image.fromarray(x.astype(np.uint8))
      . . .
      
      • tensor.data.numpy() convierte el tensor PyTorch en una matriz NumPy. .transpose(1, 2, 0) reordena (channels, width, height)en (height, width, channels). Esta matriz NumPy está aproximadamente en el intervalo (0, 1). Finalmente, multiplique por 255 para garantizar que la imagen está ahora en el intervalo (0, 255).
      • np.clip garantiza que todos los valores de la imagen están entre (0, 255).
      • x.asype(np.uint8) garantiza que todos los valores de la imagen sean enteros. Finalmente, Image.fromarray(...) crea un objeto de imagen PIL desde la matriz NumPy.

      A continuación, use estas utilidades para crear el ejemplo contradictorio con lo siguiente:

      step_3_adversarial.py

      . . .
      def get_adversarial_example(x, r):
          y = x + r
          y = get_inverse_transform()(y[0])
          image = tensor_to_image(y)
          return image
      . . .
      

      Esta función genera el ejemplo contradictorio descrito al inicio de la sección:

      1. y = x + r. Tome su perturbación r y añádala a la imagen original x.
      2. get_inverse_transform: obtenga y aplique la transformación de imagen inversa que definió hace varias líneas.
      3. tensor_to_image: por último, convierta el tensor PyTorch de vuelta a un objeto de imagen.

      Finalmente, modifique su función main para cargar la imagen, cargue la perturbación contradictoria r, aplique la perturbación, guarde el ejemplo contradictorio en el disco y ejecute la predicción sobre el ejemplo contradictorio:

      step_3_adversarial.py

      def main():
          x = load_image()
          r = torch.Tensor(np.load('assets/adversarial_r.npy'))
      
          # save perturbed image
          os.makedirs('outputs', exist_ok=True)
          adversarial = get_adversarial_example(x, r)
          adversarial.save('outputs/adversarial.png')
      
          # check prediction is new class
          print(f'Old prediction: {predict(x)}')
          print(f'New prediction: {predict(x + r)}')
      

      Su archivo completado debería coincidir con step_3_adversarial.py en GitHub. Guarde el archivo, salga del editor e inicie su secuencia de comandos con:

      • python step_3_adversarial.py assets/dog.jpg

      Verá este resultado:

      Output

      Old prediction: Pembroke, Pembroke Welsh corgi New prediction: goldfish, Carassius auratus

      Ahora ha creado un ejemplo contradictorio: engañar a la red neural para que crea que un corgi es un pez dorado. En el siguiente paso, creará la perturbación r que utilizó aquí.

      Paso 4: Comprender un ejemplo contradictorio

      Para obtener una preparación sobre la clasificación, consulte “Cómo crear un filtro de perro basado en emociones”.

      Dando un paso atrás, recuerde que su modelo de clasificación produce una probabilidad para cada clase. Durante la inferencia, el modelo predice la clase con la mayor probabilidad. Durante el entrenamiento, actualiza los parámetros del modelo t para maximizar la probabilidad de la clase correcta y, según sus datos x.

      argmax_y P(y|x,t)
      

      Sin embargo, para generar ejemplos contradictorios, ahora modifica su objetivo. En vez de encontrar una clase, su objetivo ahora es encontrar una nueva imagen, x. Tome cualquier clase distinta a la correcta. Vamos a llamar a esta nueva clase w. Su nuevo objetivo es maximizar la probabilidad de tener una clase equivocada.

      argmax_x P(w|x)
      

      Observe que las ponderaciones t de la red neural faltan de la expresión anterior. Esto es porque ahora asume la función de la contradicción: alguien más ha entrenado e implementado un modelo. Solo se le permite crear entradas contradictorias y no se le permite modificar el modelo implementado. Para generar el ejemplo contradictorio x, puede ejecutar “entrenamiento”, excepto que en vez de actualizar las ponderaciones de la red neural, actualiza la imagen de entrada con el nuevo objetivo.

      Como recordatorio, para este tutorial, asume que el ejemplo contradictorio es una transformación afín de x. En otras palabras, su ejemplo contradictorio toma la forma x + r para algunos r. En el siguiente paso, escribirá secuencia de comandos para generar este r.

      Paso 5: Crear un ejemplo contradictorio

      En este paso, aprenderá una perturbación r, de forma que su corgi esté mal clasificado como un pez dorado. Cree un nuevo archivo llamado step_5_adversarial.py:

      Importe los paquetes necesarios y declare una función main:

      step_5_perturb.py

      from torch.autograd import Variable
      import torchvision.models as models
      import torch.nn as nn
      import torch.optim as optim
      import numpy as np
      import torch
      import os
      
      from step_2_pretrained import get_idx_to_label, get_image_transform, predict, load_image
      from step_3_adversarial import get_adversarial_example
      
      
      def main():
          pass
      
      
      if __name__ == '__main__':
          main()
      

      Directamente tras sus importaciones y antes de la función main, defina dos constantes:

      step_5_perturb.py

      . . .
      TARGET_LABEL = 1
      EPSILON = 10 / 255.
      . . .
      

      La primera constante TARGET_LABEL es la clase para clasificar erróneamente al corgi. En este caso, el índice 1 corresponde a “pez dorado”. La segunda constante EPSILON es la cantidad máxima de perturbación permitida para cada valor de imagen. Este límite se introduce de manera que la imagen se altere de forma imperceptible.

      Tras sus dos constantes, añada una función helper para definir una red neural y el parámetro perturbación r:

      step_5_perturb.py

      . . .
      def get_model():
          net = models.resnet18(pretrained=True).eval()
          r = nn.Parameter(data=torch.zeros(1, 3, 224, 224), requires_grad=True)
          return net, r
      . . .
      
      • model.resnet18(pretrained=True) carga una red neural preentrenada, llamada ResNet18, como antes. También como antes, establece el modelo para el modo de evaluación usando .eval.
      • nn.Parameter(...) define una nueva perturbación r, el tamaño de la imagen de entrada. La imagen de entrada también es de tamaño (1, 3, 224, 224). El argumento de palabra clave requires_grad=True garantiza que puede actualizar esta perturbación en líneas posteriores, en este archivo.

      A continuación, comience a modificar su función main. Comience cargando la red del modelo, cargando las entradas x y definiendo la etiqueta label:

      step_5_perturb.py

      . . .
      def main():
          print(f'Target class: {get_idx_to_label()[str(TARGET_LABEL)]}')
          net, r = get_model()
          x = load_image()
          labels = Variable(torch.Tensor([TARGET_LABEL])).long()
        . . .
      

      A continuación, defina tanto el criterio como el optimizador de su función main. El primero le indica a PyTorch cuál es el objetivo: es decir, qué pérdida minimizar. Este último le indica a PyTorch cómo entrenar su parámetro r:

      step_5_perturb.py

      . . .
          criterion = nn.CrossEntropyLoss()
          optimizer = optim.SGD([r], lr=0.1, momentum=0.1)
      . . .
      

      Justo después, añada el bucle de entrenamiento principal para su parámetro r:

      step_5_perturb.py

      . . .
          for i in range(30):
              r.data.clamp_(-EPSILON, EPSILON)
              optimizer.zero_grad()
      
              outputs = net(x + r)
              loss = criterion(outputs, labels)
              loss.backward()
              optimizer.step()
      
              _, pred = torch.max(outputs, 1)
              if i % 5 == 0:
                  print(f'Loss: {loss.item():.2f} / Class: {get_idx_to_label()[str(int(pred))]}')
      . . .
      

      En cada iteración de este bucle de entrenamiento, usted:

      • r.data.clamp_(...): asegúrese de que el parámetro r es pequeño, dentro de EPSILON de 0.
      • optimizer.zero_grad(): borre cualquier gradiente que haya calculado en la iteración anterior.
      • model(x + r): ejecute la inferencia sobre la imagen modificada x + r.
      • Calcule la pérdida.
      • Calcule el gradiente loss.backward.
      • Tome un paso de descenso de gradiente optimizer.step.
      • Calcule la predicción pred.
      • Finalmente, informe de la pérdida y la clase predicha print(...).

      A continuación, guarde la perturbación final r:

      step_5_perturb.py

      def main():
          . . .
          for i in range(30):
              . . .
          . . .
          np.save('outputs/adversarial_r.npy', r.data.numpy())
      

      Justo después, aún en la función main, guarde la imagen perturbada:

      step_5_perturb.py

      . . .
          os.makedirs('outputs', exist_ok=True)
          adversarial = get_adversarial_example(x, r)
      

      Finalmente, ejecute la predicción tanto sobre la imagen original como sobre el ejemplo contradictorio:

      step_5_perturb.py

          print(f'Old prediction: {predict(x)}')
          print(f'New prediction: {predict(x + r)}')
      

      Compruebe que su secuencia de comandos coincide con step_5_perturb.py en GitHub. Guarde, salga y ejecute la secuencia de comandos.

      • python step_5_perturb.py assets/dog.jpg

      El resultado de su secuencia de comandos será la siguiente.

      Output

      Target class: goldfish, Carassius auratus Loss: 17.03 / Class: Pembroke, Pembroke Welsh corgi Loss: 8.19 / Class: Pembroke, Pembroke Welsh corgi Loss: 5.56 / Class: Pembroke, Pembroke Welsh corgi Loss: 3.53 / Class: Pembroke, Pembroke Welsh corgi Loss: 1.99 / Class: Pembroke, Pembroke Welsh corgi Loss: 1.00 / Class: goldfish, Carassius auratus Old prediction: Pembroke, Pembroke Welsh corgi New prediction: goldfish, Carassius auratus

      Las últimas dos líneas indican que ahora ha completado la construcción de un ejemplo contradictorio desde cero. Su red neural ahora clasifica una imagen de corgi perfectamente razonable como un pez dorado.

      Ahora ha demostrado que las redes neurales pueden ser engañadas fácilmente; además, la falta de robustez para los ejemplos contradictorios tiene consecuencias significativas. Una pregunta natural es esta: ¿cómo puede combatir los ejemplos contradictorios? Varias organizaciones han llevado a cabo extensas investigaciones, incluyendo OpenAI. En la siguiente sección, ejecutará una defensa para frustrar este ejemplo contradictorio.

      Paso 6: Defenderse contra ejemplos contradictorios

      En este paso, implementará una defensa contra ejemplos contradictorios. La idea es la siguiente: ahora es el propietario del clasificador de animales implementado a producción. No sabe qué ejemplos contradictorios pueden generarse, pero puede modificar la imagen o el modelo para protegerse contra ataques.

      Antes de defender, debería ver por sí que la manipulación de imágenes es imperceptible. Abra las dos imágenes siguientes:

      1. assets/dog.jpg
      2. outputs/adversarial.png

      Aquí, muestra ambas juntas. Su imagen original tendrá una relación de aspecto diferente. ¿Sabe cuál es el ejemplo contradictorio?

      (izquierda) Corgi como pez dorado, contradictoria; (derecha) Corgi como sí mismo, no contradictoria

      Observe que la nueva imagen parece idéntica a la original. En realidad, la imagen izquierda es su imagen contradictoria. Para estar seguro, descargue la imagen y ejecute su secuencia de comandos de evaluación:

      • wget -O assets/adversarial.png https://github.com/alvinwan/fooling-neural-network/blob/master/outputs/adversarial.png?raw=true
      • python step_2_pretrained.py assets/adversarial.png

      Esto dará como resultado la clase goldfish para demostrar su naturaleza contradictoria:

      Output

      Prediction: goldfish, Carassius auratus

      Ejecutará una defensa bastante ingenua, pero eficaz: comprima la imagen escribiendo a un formato JPEG. Abra la instrucción interactiva Python:

      A continuación, cargue la imagen contradictoria como PNG y guárdela como JPEG.

      • from PIL import Image
      • image = Image.open('assets/adversarial.png')
      • image.save('outputs/adversarial.jpg')

      Escriba CTRL + D para dejar la instrucción interactiva Python. A continuación, ejecute la inferencia con su modelo en el ejemplo contradictorio comprimido:

      • python step_2_pretrained.py outputs/adversarial.jpg

      Ahora dará como resultado la clase corgi, demostrando la eficacia de su defensa ingenua.

      Output

      Prediction: Pembroke, Pembroke Welsh corgi

      Ahora ha completado su primera defensa contradictoria. Observe que esta defensa no requiere saber cómo se generó el ejemplo contradictorio. Esto es lo que hace que una defensa sea efectiva. Existen también muchas otras formas de defensa, muchas de las cuales implican volver a entrenar la red neural. Sin embargo, estos procedimientos de entrenamiento son un tema en sí mismos y están más allá del ámbito de este tutorial. Con esto, concluye su guía sobre el aprendizaje automático contradictorio.

      Conclusión

      Para comprender las implicaciones de su trabajo en este tutorial, vuelva a ver las dos imágenes lado a lado: la original y el ejemplo contradictorio.

      (izquierda) Corgi como pez dorado, contradictoria, (derecha) Corgi como sí mismo, no contradictoria

      A pesar de que ambas imágenes parecen idénticas al ojo humano, la primera ha sido manipulada para engañar a su modelo. Ambas imágenes claramente muestran un corgi, y aun así el modelo tiene total confianza de que el segundo modelo contiene un pez dorado. Esto debería preocuparle y, a medida que finaliza este tutorial, tenga en cuenta la fragilidad de su modelo. Solo aplicando una transformación simple, puede engañarlo. Estos son peligros reales y plausibles que evaden incluso con investigación de vanguardia. La investigación más allá de la seguridad del aprendizaje automático es igual de susceptible a estos defectos, como profesional, depende de usted aplicar el aprendizaje automático de forma segura. Para obtener más información, eche un vistazo a los siguientes enlaces:

      Para obtener más contenido sobre el aprendizaje automático, puede visitar nuestra página Tema de aprendizaje automático.



      Source link

      Cómo instalar y usar Radamsa para probar programas y servicios de red con fuzzing en Ubuntu 18.04


      El autor seleccionó la Electronic Frontier Foundation Inc para recibir una donación como parte del programa Write for DOnations.

      Introducción

      Las amenazas de seguridad son cada vez más complejas, por lo que los desarrolladores y los administradores de sistemas deben adoptar un enfoque proactivo para defender y probar la seguridad de sus aplicaciones.

      Un método frecuente para probar la seguridad de aplicaciones o servicios de red de clientes es el fuzzing, que implica enviar datos no válidos o con formato incorrecto a la aplicación en cuestión y analizar su respuesta. Es útil para ayudar a probar cuán resistente y sólida es una aplicación ante entradas inesperadas, como datos corruptos o ataques reales.

      Radamsa es una herramienta de fuzzing de código abierto que puede generar casos de prueba basados en datos de entrada especificados por el usuario. Se puede programar mediante scripts por completo y se utiliza para detectar vulnerabilidades en aplicaciones reales, como Gzip, de forma exitosa.

      A través de este tutorial, instalará y utilizará Radamsa para probar aplicaciones de línea de comandos y de red con fuzzing usando sus propios casos de prueba.

      Advertencia: Radamsa es una herramienta de pruebas de penetración que le permite identificar vulnerabilidades o deficiencias en sistemas o aplicaciones determinados. No debe usar las vulnerabilidades que detecte Radamsa para ninguna forma de comportamiento imprudente, daño o explotación malintencionada. Las vulnerabilidades se deben informar de manera ética a la persona encargada del mantenimiento de la aplicación afectada y no se deben divulgar públicamente sin permiso explícito.

      Requisitos previos

      Para completar esta guía, necesitará lo siguiente:

      Advertencia: Radamsa puede hacer que aplicaciones o sistemas se ejecuten de forma inestable o se bloqueen, por lo que debe ejecutarlo únicamente en un entorno en el que esté preparado para esto, como un servidor dedicado. Asegúrese también de contar con el permiso explícito por escrito del propietario del sistema que probará con fuzzing antes proceder.

      Una vez que tenga todo esto listo, inicie sesión en su servidor como usuario no root.

      Paso 1: Instalar Radamsa

      Primero, descargará y compilará Radamsa para comenzar a utilizarlo en su sistema. El código fuente de Radamsa está disponible en el repositorio oficial de GitLab.

      Comience actualizando el índice de paquetes locales de modo que se refleje cualquier cambio anterior:

      Luego, instalará los paquetes gcc, git, make y wget necesarios para compilar el código fuente en un binario ejecutable:

      • sudo apt install gcc git make wget

      Después de confirmar la instalación, apt descargará e instalará los paquetes específicos y todas sus dependencias necesarias.

      A continuación, descargará una copia del código fuente de Radamsa clonándolo del repositorio alojado en GitLab:

      • git clone https://gitlab.com/akihe/radamsa.git

      Al hacerlo, se creará un directorio llamado radamsa que contendrá el código fuente de la aplicación. Diríjase al directorio para comenzar a compilar el código:

      Luego, puede iniciar el proceso de compilación usando make:

      Por último, puede instalar el binario de Radamsa compilado en su $PATH:

      Una vez completado esto, puede verificar la versión instalada para asegurar que todo funcione:

      El resultado debe tener un aspecto similar al siguiente:

      Output

      Radamsa 0.6

      Si ve el error radamsa: command not found, verifique que todas las dependencias necesarias se hayan instalado y que no se haya habido errores durante la compilación.

      Ahora que instaló Radamsa, puede comenzar a generar algunos casos de prueba de muestra para comprender el funcionamiento de Radamsa y sus aplicaciones.

      Paso 2: Generar casos de prueba con fuzzing

      Ahora que instaló Radamsa, puede usarlo para generar casos de pruebas con fuzzing.

      Un caso de prueba es información que se utilizará como entrada para el programa que someta a prueba. Por ejemplo, si prueba con fuzzing un programa de archivo, como Gzip, un caso de prueba puede ser un archivo de almacenamiento que intente descomprimir.

      Nota: Radamsa manipula los datos de entrada de una gran variedad de formas inesperadas, como la repetición extrema, la inversión de bits y la inserción de caracteres de control, entre otras. Antes de proceder, tenga en cuenta que esto puede hacer que su sesión de terminal se interrumpa o se vuelva inestable.

      Primero, pase un texto sencillo a Radamsa para ver lo que sucede:

      • echo "Hello, world!" | radamsa

      Con esto, se manipularán (o expondrán a fuzzing) los datos ingresados y se generará un caso de prueba, como el siguiente:

      Output

      Hello,, world!

      En este caso, Radamsa agregó una coma adicional entre Hello y world. A pesar de que no parezca un cambio significativo, en algunas aplicaciones, esto puede hacer que los datos se interpreten de forma incorrecta.

      Hagamos un nuevo intento ejecutando el mismo comando. Obtendrá un resultado distinto:

      Output

      Hello, '''''''wor'd!

      Esta vez, se insertaron varias comillas simples (') en la cadena, entre ellas, una que sobrescribió la l en world. Las posibilidades de que este caso de prueba en particular genere problemas en aplicaciones son más altas, dado que se suelen utilizar comillas simples y dobles para separar diferentes porciones de datos de una lista.

      Probemos una vez más:

      Output

      Hello, $+$PATHu0000`xcalc`world!

      En este caso, Radamsa insertó una cadena de inserción de shell, que será útil para realizar pruebas en busca de vulnerabilidades de inserción de comandos en la aplicación que pruebe.

      Usó Radamsa para someter a fuzzing una cadena de entrada y producir una serie de casos de prueba. A continuación, utilizará Radamsa para someter a fuzzing una aplicación de línea de comandos.

      Paso 3: Someter a fuzzing una aplicación de línea de comandos

      En este paso, utilizará Radamsa para aplicar fuzzing a una aplicación de línea de comandos e informar los bloqueos que se produzcan.

      La técnica exacta para hacer pruebas con fuzzing varía en gran medida de un programa a otro, así como la eficacia de cada método. Sin embargo, en este tutorial usaremos jq como ejemplo, que es un programa de línea de comandos para procesar datos de JSON.

      Puede usar cualquier otro programa similar siempre y cuando aplique el principio general de tomar algún tipo de datos estructurados o no estructurados, hacer algo con ellos y luego producir un resultado. Por ejemplo, este caso también funcionaría con Gzip, Grep, bc y tr, entre otros.

      Si aún no instaló jq, puede hacerlo usando apt:

      De esta manera, jq quedará instalado.

      Para comenzar la prueba con fuzzing, cree un archivo JSON de ejemplo que utilizará como entrada para Radamsa:

      Luego, añada los siguientes datos de JSON de ejemplo al archivo:

      test.json

      {
        "test": "test",
        "array": [
          "item1: foo",
          "item2: bar"
        ]
      }
      

      Puede analizar este archivo usando jq si desea verificar que la sintaxis de JSON sea válida:

      Si el JSON es válido, jq mostrará el archivo. De lo contrario, mostrará un error que puede usar para corregir la sintaxis cuando sea necesario.

      A continuación, aplique fuzzing al archivo JSON de prueba usando Radamsa y, luego, páselo a jq. Esto hará que jq lea el caso de prueba sometido a fuzzing o manipulado en lugar de los datos JSON originales válidos.

      Si Radamsa muestra los datos de JSON de una forma que siga siendo válida desde el punto de vista sintáctico, jq mostrará los datos, pero con los cambios que le haya realizado Radamsa.

      Alternativamente, si Radamsa hace que los datos de JSON no sean válidos, jq mostrará un error que corresponda. Por ejemplo:

      Output

      parse error: Expected separator between values at line 5, column 16

      El resultado alternativo sería que jq no pudiera manejar los datos sometidos a fuzzing de forma correcta, lo cual haría que se bloqueara o no funcionara de forma adecuada. Esto es lo que realmente se busca con el método de fuzzing, ya que podría indicar una vulnerabilidad de seguridad, como un desbordamiento de búfer o una inserción de comandos.

      Para realizar pruebas de detección de vulnerabilidades como estas de forma más eficiente, se puede usar una secuencia de comandos de Bash a fin de automatizar el proceso de fuzzing, incluidos los procesos de generar casos de prueba, pasarlos al programa de destino y detectar cualquier resultado pertinente.

      Cree un archivo llamado jq-fuzz.sh:

      El contenido exacto de la secuencia de comandos variará según el tipo de programa que someta a fuzzing y los datos de entrada. Sin embargo, en el caso de jq y otros programas similares, la secuencia de comandos siguiente será suficiente.

      Copie la secuencia de comandos a su archivo jq-fuzz.sh:

      jq-fuzz.sh

      #!/bin/bash
      while true; do
        radamsa test.json > input.txt
        jq . input.txt > /dev/null 2>&1
        if [ $? -gt 127 ]; then
          cp input.txt crash-`date +s%.%N`.txt
          echo "Crash found!"
        fi
      done
      

      Esta secuencia de comandos contiene while para hacer que el contenido se repita reiteradamente. Cada vez que se repita la secuencia de comandos, Radamsa generará un caso de prueba basado en test.json y lo guardará en input.txt.

      Luego, el caso de prueba input.txt se ejecutará en jq y todo el resultado estándar y de error se reenviará a /dev/null para evitar saturar la pantalla del terminal.

      Por último, se verifica el valor de salida de jq. Si el valor de salida es superior a 127, esto indica una interrupción irrecuperable (un bloqueo), por lo que los datos de entrada se guardan para su análisis posterior en un archivo llamado crash- seguido de la fecha actual en segundos y nanosegundos de Unix.

      Marque la secuencia de comandos como ejecutable y ejecútela para comenzar a probar jq con fuzzing de forma automática:

      • chmod +x jq-fuzz.sh
      • ./jq-fuzz.sh

      Puede pulsar CTRL+C en cualquier momento para finalizar la secuencia de comandos. Luego, puede verificar si se encontraron errores utilizando ls para mostrar una lista de directorios en la que se encuentran los archivos de bloqueos que se hayan creado.

      Se recomienda mejorar los datos de JSON de entrada, dado que probablemente el uso de un archivo de entrada más complejo mejore la calidad de los resultados de la aplicación de fuzzing. Evite usar un archivo grande o uno que contenga muchos datos repetidos; lo ideal es usar un archivo de entrada que sea pequeño y, no obstante, tenga la mayor cantidad de elementos “complejos” posible. Por ejemplo, un buen archivo de entrada debe contener muestras de datos almacenados en todos los formatos, incluso cadenas, enteros, booleanos, listas, objetos y datos anidados si es posible.

      Utilizó Radamsa para probar una aplicación de línea de comandos con fuzzing. A continuación, utilizará Radamsa para probar solicitudes a servicios de red.

      Paso 4: Probar solicitudes a servicios de red con fuzzing

      Radamsa también se puede utilizar para probar servicios de red, ya sea como cliente o servidor de red. En este paso, utilizará Radamsa para probar un servicio de red con fuzzing y Radamsa funcionará como cliente.

      El propósito de probar servicios de red con fuzzing es determinar cuán resistente es un servicio de red en particular ante el envío de datos maliciosos o con formato incorrecto. Muchos servicios de red, como los servidores web o DNS, suelen estar expuestos a Internet, lo cual los convierte en un objetivo común para los atacantes. Un servicio de red que no sea suficientemente resistente a la recepción de datos con formato incorrecto puede bloquearse o, lo que sería peor aún, fallar en estado abierto. Esto podría permitir a los atacantes leer datos confidenciales, como claves de cifrado o datos de usuarios.

      Si bien la técnica específica para probar servicios de red con fuzzing varía en gran medida según el servicio de red, en este ejemplo usaremos Radamsa para probar un servidor web básico que proporciona contenido HTML estático.

      Primero, debe configurar el servidor web para su uso en pruebas. Puede hacerlo usando el servidor de desarrollo incorporado que viene con el paquete php-cli. También necesitará curl para probar su servidor web.

      Si no tiene php-cli ni curl instalados, puede instalarlos usando apt:

      • sudo apt install php-cli curl

      A continuación, cree un directorio para almacenar los archivos de su servidor web y posiciónese en él:

      Luego, cree un archivo HTML que contenga texto de ejemplo:

      Añada lo siguiente al archivo:

      index.html

      <h1>Hello, world!</h1>
      

      Ahora, podrá ejecutar su servidor web de PHP. Tendrá que poder ver el registro del servidor web mientras siga utilizando otra sesión de terminal. Por ello, abra otra sesión y aplique SSH al servidor para lo siguiente:

      • cd ~/www
      • php -S localhost:8080

      Con esto, se mostrará algo similar a lo siguiente:

      Output

      PHP 7.2.24-0ubuntu0.18.04.1 Development Server started at Wed Jan 1 16:06:41 2020 Listening on http://localhost:8080 Document root is /home/user/www Press Ctrl-C to quit.

      Ahora, podrá regresar a su sesión de terminal original y verificar que el servidor web esté funcionando mediante curl:

      Con esto, se mostrará el archivo de ejemplo index.html que creó anteriormente:

      Output

      <h1>Hello, world!</h1>

      Solo se debe poder acceder a su servidor web de forma local, por lo que no debe abrir ningún puerto en su firewall para él.

      Ahora que configuró su servidor web de prueba, podrá comenzar a realizar pruebas con fuzzing utilizando Radamsa.

      Primero, deberá crear una solicitud HTTP de ejemplo a fin de usarla como información de entrada para Radamsa. Cree un archivo nuevo para almacenar esto en la siguiente ubicación:

      Luego, copie la siguiente solicitud HTTP de ejemplo al archivo:

      http-request.txt

      GET / HTTP/1.1
      Host: localhost:8080
      User-Agent: test
      Accept: */*
      

      A continuación, puede usar Radamsa para enviar esta solicitud HTTP a su servidor web local. Para hacerlo, deberá usar Radamsa como cliente TCP, lo que se puede hacer especificando una dirección IP y un puerto para establecer conexión:

      • radamsa -o 127.0.0.1:8080 http-request.txt

      Nota: Tenga en cuenta que usar Radamsa como cliente TCP, puede hacer que se transmitan datos maliciosos o con formato incorrecto a través de la red. Esto puede provocar errores; por ello, debe asegurarse de acceder únicamente a las redes que tenga permitido probar o, preferentemente, aténgase a utilizar la dirección de host local (127.0.0.1).

      Por último, si ve los registros de salida de su servidor web local observará que recibió las solicitudes, pero probablemente no las haya procesado porque no eran válidas o tenían un formato incorrecto.

      Los registros de salida se mostrarán en su segunda ventana de terminal:

      Output

      [Wed Jan 1 16:26:49 2020] 127.0.0.1:49334 Invalid request (Unexpected EOF) [Wed Jan 1 16:28:04 2020] 127.0.0.1:49336 Invalid request (Malformed HTTP request) [Wed Jan 1 16:28:05 2020] 127.0.0.1:49338 Invalid request (Malformed HTTP request) [Wed Jan 1 16:28:07 2020] 127.0.0.1:49340 Invalid request (Unexpected EOF) [Wed Jan 1 16:28:08 2020] 127.0.0.1:49342 Invalid request (Malformed HTTP request)

      Para obtener resultados óptimos y asegurarse de que los bloqueos se registren, es conveniente escribir una secuencia de comandos de automatización similar a la que se utilizó en el paso 3. También debe considerar la posibilidad de usar un archivo de entrada más complejo, que puede contener elementos añadidos, como encabezados HTTP adicionales.

      De esta manera, probó un servicio de red con fuzzing usando Radamsa como cliente TCP. A continuación, probará a un cliente de red utilizando Radamsa como servidor.

      Paso 5: Probar aplicaciones clientes de red con fuzzing

      En este paso, utilizará Radamsa para probar una aplicación cliente de red con fuzzing. Esto se logra interceptando respuestas de un servicio de red y sometiéndolas a fuzzing antes de que las reciba el cliente.

      El propósito de este tipo de fuzzing es probar la resistencia de las aplicaciones clientes de red a la recepción de datos maliciosos o de formato incorrecto de servicios de red. Por ejemplo, probará un navegador web (cliente) que recibirá HTML con formato incorrecto de un servidor web (servicio de red) o un cliente DNS que recibirá respuestas DNS con formato incorrecto de un servidor DNS.

      Al igual que en el caso de aplicaciones de línea de comandos o servicios de red, la técnica exacta para probar con fuzzing cada aplicación cliente de red varía considerablemente. Sin embargo, en este ejemplo utilizará whois, una aplicación de envío y recepción simple basada en TCP.

      La aplicación whois se utiliza para enviar solicitudes a servidores WHOIS y recibir registros WHOIS como respuesta. WHOIS funciona a través del puerto TCP 43 con texto no cifrado, por lo que es ideal para realizar pruebas con fuzzing en redes.

      Si aún no cuenta con whois, puede instalarlo usando apt:

      Primero, deberá adquirir una respuesta whois de muestra para usarla como dato de entrada. Puede hacerlo enviando una solicitud whois y guardando el resultado en un archivo. Puede usar cualquier dominio que desee, dado que probará el programa whois de forma local con datos de muestra:

      • whois example.com > whois.txt

      A continuación, deberá configurar Radamsa como un servidor que proporcione versiones distorsionadas de esta respuesta whois. Deberá poder continuar usando su terminal una vez que Radamsa esté en ejecución en el modo de servidor, por lo que se recomienda abrir otra sesión de terminal y conexión SSH con su servidor para lo siguiente:

      • radamsa -o :4343 whois.txt -n inf

      Con esto, Radamsa se ejecutará en el modo de servidor TCP y enviará una versión de whois.txt sometida a fuzzing cada vez que se establezca una conexión con el servidor, independientemente de los datos de solicitud que se reciban.

      Ahora, puede proceder con la prueba de la aplicación cliente whois. Deberá realizar una solicitud whois normal para cualquier dominio que prefiera (no es necesario que sea el mismo al que se aplican los datos de muestra), pero con whois apuntando a su servidor de Radamsa local:

      • whois -h localhost:4343 example.com

      Recibirá como respuesta sus datos de muestra, aunque distorsionados por Radamsa. Puede continuar realizando solicitudes al servidor local mientras Radamsa esté en ejecución. Este enviará una respuesta diferente en cada ocasión.

      Al igual que con los servicios de red, para mejorar la eficacia de estas pruebas del cliente de red con fuzzing y asegurarse de que se registren los bloqueos, es conveniente escribir una secuencia de comandos de automatización similar a la que se utilizó en el paso 3.

      En este paso final, utilizó Radamsa para probar una aplicación cliente de red con fuzzing.

      Conclusión

      A través de este artículo, configuró Radamsa y lo utilizó para probar una aplicación de línea de comandos, un servicio de red y un cliente de red. Ahora tiene los conocimientos básicos necesarios para probar sus propias aplicaciones con fuzzing y mejorar su solidez y resistencia contra ataques.

      Si desea explorar Radamsa en mayor profundidad, puede revisar el archivo README de Radamsa de forma detallada; contiene más información técnica y ejemplos relacionados con los usos posibles de la herramienta:

      También puede probar otras herramientas de fuzzing como American Fuzzy Lop (AFL), una herramienta de fuzzing avanzada diseñada para probar aplicaciones binarias con una velocidad y una precisión sumamente altas:



      Source link

      Cómo configurar BIND como servidor DNS de red privada en Ubuntu 18.04


      Introducción

      Una parte importante de la administración de la configuración e infraestructura de servidores incluye el uso sostenido de un método sencillo para buscar las interfaces de red y direcciones IP por nombre mediante la configuración de un sistema de nombres de dominio (DNS) adecuado. El empleo de nombres de dominio completos (FQDN), en vez de direcciones IP, para especificar las direcciones de red puede facilitar la configuración de servicios y aplicaciones, y aumenta la capacidad de mantenimiento de los archivos de configuración. Configurar su propio DNS para su red privada es una excelente opción para mejorar la administración de sus servidores.

      En este tutorial, veremos la manera de configurar un servidor DNS interno usando el software de servidor de nombres BIND (BIND9) en Ubuntu 18.04, que sus servidores pueden usar para resolver direcciones IP y nombres de hosts privados. Esto ofrece una alternativa centralizada para administrar sus nombres de hosts internos y direcciones IP privadas, lo cual es indispensable cuando su entorno abarca más de unos pocos hosts.

      Puede encontrar la versión de CentOS de este tutorial aquí.

      Requisitos previos

      Para completar este tutorial, necesitará la infraestructura siguiente. Cree cada servidor en el mismo centro de datos con red privada habilitada:

      • Un servidor de Ubuntu 18.04 nuevo que servirá como el servidor DNS primario, ns1.
      • (Recomendado) Un segundo servidor Ubuntu 18.04 que servirá como servidor DNS secundario, ns2.
      • Servidores adicionales en el mismo centro de datos que usarán sus servidores DNS.

      En cada uno de estos servidores, configure un acceso administrativo mediante un usuario sudo y un firewall siguiendo nuestra guía de configuración inicial para servidores de Ubuntu 18.04.

      Si no está familiarizado con los conceptos de DNS, se recomienda que lea al menos las tres primeras partes de nuestra Introducción a la administración de DNS.

      Ejemplo e infraestructura y objetivos

      A efectos de este artículo, supondremos lo siguiente:

      • Tenemos dos servidores que se designarán como nuestros servidores de nombres DNS. En esta guía, nos referiremos a estos como ns1 y ns2.
      • Disponemos de dos servidores clientes adicionales que usarán la infraestructura DNS que creemos. En esta guía, los llamaremos host1 y host2. Puede añadir tantos como desee en su infraestructura.
      • Todos estos servidores existen en el mismo centro de datos. Supondremos que este es el centro de datos nyc3.
      • Todos estos servidores tienen habilitada una red privada y están en la subred 10.128.0.0/16. Probablemente deba ajustar esto para sus servidores.
      • Todos los servidores se conectan a un proyecto que se ejecuta en “example.com”. Ya que nuestro sistema DNS será totalmente interno y privado, no es necesario que compre un nombre de dominio. Sin embargo, el uso de un dominio propio puede evitar conflictos con dominios públicos enrutables.

      Con estas suposiciones, decidimos que tiene sentido usar un esquema de nomenclatura que emplee “nyc3.example.com” para hacer referencia a nuestra subred o zona privada. Por tanto, el nombre de dominio completo (FQDN) privado de host1, será host1.ny3.example.com. Consulte la siguiente tabla que contiene la información pertinente:

      hostRolFQDN privadaDirección IP privada
      ns1Servidor DNS primarions1.nyc3.example.com10.128.10.11
      ns2Servidor DNS secundarions2.nyc3.example.com10.128.20.12
      host1Host genérico 1host1.nyc3.example.com10.128.100.101
      host2Host genérico 2host2.nyc3.example.com10.128.200.102

      Nota: Su configuración existente será diferente, pero los nombres de ejemplo y las direcciones IP se utilizarán para demostrar la forma de configurar un servidor DNS para que proporcione un DNS interno funcional. Debería poder adaptar fácilmente esta configuración para su propio entorno sustituyendo los nombres de hosts y direcciones IP privadas por los suyos. No es necesario usar el nombre de la región del centro de datos en su esquema de nomenclatura, pero lo utilizaremos aquí para denotar que estos hosts pertenecen a la red privada de un centro de datos concreto. Si utiliza varios centros de datos, puede configurar un DNS interno con cada centro de datos respectivo.

      Al final de este tutorial, dispondremos de un servidor DNS primario, ns1, y de forma opcional uno secundario, ns2, que servirá como respaldo.

      Comenzaremos instalando nuestro servidor DNS primario, ns1.

      Instalar BIND en servidores DNS

      Nota: El texto resaltado en rojo es importante. A menudo se usará para indicar algo que debe sustituirse por sus propios ajustes o que debería modificarse o añadirse a un archivo de configuración. Por ejemplo, si ve algo similar a host1.nyc3.example.com, sustitúyalo por el FQDN de su servidor. Asimismo, si ve host1_private_IP, sustitúyalo por la dirección IP privada de su propio servidor.

      En ambos servidores DNS, ns1 y ns2, actualice la caché del paquete apt escribiendo lo siguiente:

      Ahora instale BIND:

      • sudo apt-get install bind9 bind9utils bind9-doc

      Configurar Bind para el modo IPv4

      Antes de continuar, configuraremos BIND para el modo IPv4, ya que nuestra red privada utiliza IPv4 exclusivamente. En ambos servidores, edite la configuración predeterminada de bind9 escribiendo lo siguiente:

      • sudo nano /etc/default/bind9

      Añada “-4” al final del parámetro OPTIONS. Debería tener el siguiente aspecto:

      /etc/default/bind9

      . . .
      OPTIONS="-u bind -4"
      

      Guarde y cierre el archivo cuando haya terminado.

      Reinicie BIND para implementar los cambios:

      • sudo systemctl restart bind9

      Ahora que BIND está instalado, configuraremos el servidor DNS primario.

      Configurar el servidor DNS primario

      La configuración de BIND consta de varios archivos que se incluyen desde el archivo de configuración principal, named.conf. Estos nombres de archivos comienzan con named porque ese es el nombre del proceso que BIND ejecuta (abreviatura de “domain name daemon”). Comenzaremos configurando el archivo de opciones.

      Configurar el archivo de opciones

      En ns1, abra el archivo named.conf.options para editarlo:

      • sudo nano /etc/bind/named.conf.options

      Sobre el bloque options existente, cree un nuevo bloque ACL (lista de control de acceso) llamado “trusted”. Aquí definiremos una lista de clientes desde los que permitiremos consultas de DNS recurrentes (es decir, sus servidores que están en el mismo centro de datos que ns1). Usando nuestras direcciones IP privadas de ejemplo, añadiremos ns1, ns2, host1 y host2 a nuestra lista de clientes de confianza:

      /etc/bind/named.conf.options — 1 of 3

      acl "trusted" {
              10.128.10.11;    # ns1 - can be set to localhost
              10.128.20.12;    # ns2
              10.128.100.101;  # host1
              10.128.200.102;  # host2
      };
      
      options {
      
              . . .
      

      Ahora que tenemos nuestra lista de clientes DNS de confianza, nos convendrá editar el bloque options. En este momento, el inicio del bloque tiene el siguiente aspecto:

      /etc/bind/named.conf.options — 2 of 3

              . . .
      };
      
      options {
              directory "/var/cache/bind";
              . . .
      }
      

      Debajo de la directiva directory, añada las líneas de configuración resaltadas (y realice la sustitución en la dirección IP adecuada de ns1) para que tenga un aspecto similar a este:

      /etc/bind/named.conf.options — 3 of 3

              . . .
      
      };
      
      options {
              directory "/var/cache/bind";
      
              recursion yes;                 # enables resursive queries
              allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
              listen-on { 10.128.10.11; };   # ns1 private IP address - listen on private network only
              allow-transfer { none; };      # disable zone transfers by default
      
              forwarders {
                      8.8.8.8;
                      8.8.4.4;
              };
      
              . . .
      };
      

      Cuando termine, guarde y cierre el archivo named.conf.options. En la configuración anterior se especifica que solo sus propios servidores (los “trusted”) podrán consultar su servidor DNS en busca de dominios externos.

      A continuación, configuraremos el archivo local para especificar nuestras zonas de DNS.

      Configurar el archivo local

      En ns1, abra el archivo named.conf.options para editarlo:

      • sudo nano /etc/bind/named.conf.local

      Aparte de algunos contener algunos comentarios, el archivo debería estar vacío. Aquí especificaremos nuestras zonas de reenvío e inversas. Las zonas DNS designan un alcance específico para administrar y definir registros DNS. Debido a que todos nuestros dominios estarán en el subdominio “nyc3.example.com”, usaremos eso como nuestra zona de reenvío. Debido a que las direcciones IP privadas de nuestros servidores están en el espacio IP 10.128.0.0/16, configuraremos una zona inversa para poder definir búsquedas inversas en ese intervalo.

      Añada la zona de reenvío con las siguientes líneas, sustituyendo el nombre de la zona por el suyo y la dirección IP privada del servidor DNS secundario en la directiva allow-transfer:

      /etc/bind/named.conf.local — 1 of 2

      zone "nyc3.example.com" {
          type master;
          file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
          allow-transfer { 10.128.20.12; };           # ns2 private IP address - secondary
      };
      

      Suponiendo que nuestra subred privada es 10.128.0.0/16, agregue la zona inversa con las siguientes líneas (tenga en cuenta que el nombre de nuestra zona inversa comienza con “128.10”, que es el octeto inverso de “10.128”):

      /etc/bind/named.conf.local — 2 of 2

          . . .
      };
      
      zone "128.10.in-addr.arpa" {
          type master;
          file "/etc/bind/zones/db.10.128";  # 10.128.0.0/16 subnet
          allow-transfer { 10.128.20.12; };  # ns2 private IP address - secondary
      };
      

      Si sus servidores abarcan varias subredes privadas, pero están en el mismo centro de datos, asegúrese de especificar una zona adicional y un archivo de zona para cada subred distinta. Cuando termine de añadir todas las zonas deseadas, guarde el archivo named.conf.local y ciérrelo.

      Ahora que nuestras zonas están especificadas en BIND, debemos crear los archivos correspondientes de la zona de reenvío e inversa.

      Crear el archivo de la zona de reenvío

      El archivo de la zona de reenvío representa el punto en el que definimos los registros DNS para reenviar búsquedas DNS. Es decir, cuando el DNS reciba una consulta de nombre, “host1.nyc3.example.com”, por ejemplo, realizará en el archivo de la zona de reenvío para resolver la dirección IP privada correspondiente de host1.

      Crearemos el directorio en el que se alojarán nuestros archivos de zona. Según nuestra configuración de named.conf.local, esa ubicación debería ser /etc/bind/zones:

      • sudo mkdir /etc/bind/zones

      Basaremos nuestro archivo de la zona de reenvío en el archivo de zona db.local de muestra. Cópielo a la ubicación adecuada con los siguientes comandos:

      • sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com

      Ahora, editaremos nuestro archivo de la zona de reenvío:

      • sudo nano /etc/bind/zones/db.nyc3.example.com

      Inicialmente, tendrá un aspecto similar al siguiente:

      /etc/bind/zones/db.nyc3.example.com — original

      $TTL    604800
      @       IN      SOA     localhost. root.localhost. (
                                    2         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ;
      @       IN      NS      localhost.      ; delete this line
      @       IN      A       127.0.0.1       ; delete this line
      @       IN      AAAA    ::1             ; delete this line
      

      Primero, deberá editar el registro SOA. Sustituya el primer “localhost” por el FQDN de ns1 y luego “root.localhost” por “admin.nyc3.example.com”. Cada vez que edite un archivo de zona, deberá incrementar el valor serial antes de reiniciar el proceso named. Lo incrementaremos a “3”. Ahora debería tener un aspecto similar a este:

      /etc/bind/zones/db.nyc3.example.com — updated 1 of 3

      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
      
                                    . . .
      

      A continuación, elimine los tres registros al final del archivo (después del registro SOA). Si no está seguro de las líneas que debe eliminar, estas se marcan con un comentario “delete this line” (eliminar esta línea) encima.

      Al final del archivo, añada los registros de su servidor de nombres con las siguientes líneas (sustituya los nombres por los suyos). Observe que en la segunda columna se especifica que estos son registros “NS”:

      /etc/bind/zones/db.nyc3.example.com — updated 2 of 3

      . . .
      
      ; name servers - NS records
          IN      NS      ns1.nyc3.example.com.
          IN      NS      ns2.nyc3.example.com.
      

      Ahora, añada los registros A para sus hosts que pertenecen a esta zona. Esto incluye cualquier servidor cuyo nombre deseemos que termine con “.nyc3.example.com” (sustituya los nombres y las direcciones IP privadas). Usando nuestros nombres de ejemplo y las direcciones IP privadas, añadiremos registros A para ns1, ns2, host1 y host2:

      /etc/bind/zones/db.nyc3.example.com — updated 3 of 3

      . . .
      
      ; name servers - A records
      ns1.nyc3.example.com.          IN      A       10.128.10.11
      ns2.nyc3.example.com.          IN      A       10.128.20.12
      
      ; 10.128.0.0/16 - A records
      host1.nyc3.example.com.        IN      A      10.128.100.101
      host2.nyc3.example.com.        IN      A      10.128.200.102
      

      Guarde y cierre el archivo db.nyc3.example.com.

      Nuestra zona de reenvío de ejemplo final tendrá el siguiente aspecto:

      /etc/bind/zones/db.nyc3.example.com — updated

      $TTL    604800
      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                        3     ; Serial
                   604800     ; Refresh
                    86400     ; Retry
                  2419200     ; Expire
                   604800 )   ; Negative Cache TTL
      ;
      ; name servers - NS records
           IN      NS      ns1.nyc3.example.com.
           IN      NS      ns2.nyc3.example.com.
      
      ; name servers - A records
      ns1.nyc3.example.com.          IN      A       10.128.10.11
      ns2.nyc3.example.com.          IN      A       10.128.20.12
      
      ; 10.128.0.0/16 - A records
      host1.nyc3.example.com.        IN      A      10.128.100.101
      host2.nyc3.example.com.        IN      A      10.128.200.102
      

      Ahora, prosigamos con los archivos de la zona inversa.

      Crear los archivos de la zona inversa

      En los archivos de la zona inversa definimos los registros DNS PTR para las búsquedas de DNS inversas. Es decir, cuando el DNS reciba una consulta por dirección IP, “10.128.100.101”, por ejemplo, buscará el los archivos de la zona inversa para resolver el FQDN corespondiente, “host1.nyc3.example.com” en este caso.

      En ns1, para cada zona inversa especificada en el archivo named.conf.local, cree un archivo de zona inversa. Basaremos nuestros archivos de zona inversa en el archivo de zona db.127 de muestra. Cópielo en la ubicación adecuada con los siguientes comandos (sustituyendo el nombre de archivo de destino para que coincida con la definición de su zona inversa):

      • sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128

      Edite el archivo de la zona inversa que se corresponda con la zona o las zonas inversas definidas en named.conf.local:

      • sudo nano /etc/bind/zones/db.10.128

      Inicialmente, tendrá un aspecto similar al siguiente:

      /etc/bind/zones/db.10.128 — original

      $TTL    604800
      @       IN      SOA     localhost. root.localhost. (
                                    1         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ;
      @       IN      NS      localhost.      ; delete this line
      1.0.0   IN      PTR     localhost.      ; delete this line
      

      Como en el caso del archivo de la zona de reenvío, deberá editar el registro SOA e incrementar el valor serial. Debería tener un aspecto similar a esto:

      /etc/bind/zones/db.10.128 — updated 1 of 3

      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
      
                                    . . .
      

      A continuación, elimine los dos registros al final del archivo (después del registro SOA). Si no está seguro de las líneas que eliminará, se marcan con un comentario “delete this line” (elimine esta línea) encima.

      Al final del archivo, añada los registros de su servidor de nombres con las siguientes líneas (sustituya los nombres por los suyos). Observe que en la segunda columna se especifica que estos son registros “NS”:

      /etc/bind/zones/db.10.128 — updated 2 of 3

      . . .
      
      ; name servers - NS records
            IN      NS      ns1.nyc3.example.com.
            IN      NS      ns2.nyc3.example.com.
      

      Luego añada registros PTR para todos sus servidores cuyas direcciones IP estén en la subred del archivo de zona que está editando. En nuestro ejemplo, esto incluye todos nuestros hosts, porque todos están en la subred 10.128.0.0/16. Tenga en cuenta que la primera columna consiste en los dos últimos octetos de las direcciones IP privadas de sus servidores en orden inverso. Asegúrese de sustituir los nombres y las direcciones IP privadas para que coincidan con sus servidores:

      /etc/bind/zones/db.10.128 — updated 3 of 3

      . . .
      
      ; PTR Records
      11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
      12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
      101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
      102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102
      

      Guarde y cierre el archivo de la zona inversa (repita los pasos de esta sección si debe añadir más archivos de zona inversa).

      Nuestro archivo de zona inversa de ejemplo tiene el siguiente aspecto:

      /etc/bind/zones/db.10.128 — updated

      $TTL    604800
      @       IN      SOA     nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ; name servers
            IN      NS      ns1.nyc3.example.com.
            IN      NS      ns2.nyc3.example.com.
      
      ; PTR Records
      11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
      12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
      101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
      102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102
      

      Terminamos de editar nuestros archivos. Ahora podemos comprobar si hay errores en nuestros archivos.

      Comprobar la sintaxis de la configuración BIND

      Ejecute el siguiente comando para comprobar la sintaxis de los archivos named.conf*:

      Si sus archivos de configuración named no tienen errores de sintaxis, volverá a su intérprete de comandos de shell y no verá mensajes de error. Si existen problemas en sus archivos de configuración, revise los mensajes de error y la sección “Configurar un servidor DNS primario”, y luego pruebe named-checkconf una vez más.

      El comando named-checkzone se puede utilizar para verificar que sus archivos de zona sean correctos. En el primer argumento de este se especifica el nombre de la zona y en el segundo el archivo de zona correspondiente, que están definidos en named.conf.local.

      Por ejemplo, para comprobar la configuración de la zona de reenvío “nyc3.example.com”, ejecute el siguiente comando (cambie los nombres para que coincidan con su zona y archivo de reenvío).

      • sudo named-checkzone nyc3.example.com db.nyc3.example.com

      Para omprobar la configuración de la zona inversa “128.10.in-addr.arpa”, ejecute el siguiente comando (cambie los números para que coincidan con su zona y archivo inversos):

      • sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

      Cuando no haya errores en sus archivos de configuración y zona, debería estar listo para reiniciar el servicio BIND.

      Reiniciar BIND

      Reinicie BIND:

      • sudo systemctl restart bind9

      Si configuró el firewall UFW, abra el acceso a BIND escribiendo lo siguiente:

      Con esto, servidor DNS primario quedará configurado y listo para responder a las consultas DNS. Ahora, crearemos el servidor DNS secundario.

      Configurar el servidor DNS secundario

      En la mayoría de los entornos, se recomienda configurar un servidor DNS secundario que responda a las solicitudes si el primario deja de estar disponible. Afortunadamente, el servidor DNS secundario se puede configurar de una manera mucho más sencilla.

      En ns2, edite el archivo named.conf.options:

      • sudo nano /etc/bind/named.conf.options

      En la parte superior del archivo, añada el ACL con las direcciones IP privadas de todos sus servidores de confianza:

      /etc/bind/named.conf.options — updated 1 of 2 (secondary)

      acl "trusted" {
              10.128.10.11;   # ns1
              10.128.20.12;   # ns2 - can be set to localhost
              10.128.100.101;  # host1
              10.128.200.102;  # host2
      };
      
      options {
      
              . . .
      

      Debajo de la directiva directory, añada las siguientes líneas:

      /etc/bind/named.conf.options — updated 2 of 2 (secondary)

              recursion yes;
              allow-recursion { trusted; };
              listen-on { 10.128.20.12; };      # ns2 private IP address
              allow-transfer { none; };          # disable zone transfers by default
      
              forwarders {
                      8.8.8.8;
                      8.8.4.4;
              };
      

      Guarde y cierre el archivo named.conf.options. El archivo debería ser exactamente igual al archivo named.conf.options de ns1, excepto porque debería estar configurado para escuchar en la dirección IP privada de ns2.

      Ahora, edite el archivo named.conf.local:

      • sudo nano /etc/bind/named.conf.local

      Defina las zonas esclavas que se corresponden con las zonas maestras en el servidor DNS primario. Observe que el tipo es “slave”, el archivo no contiene una ruta y hay una directiva masters que debería fijarse en la dirección IP privada del servidor DNS primario. Si definió varias zonas inversas en el servidor DNS primario, asegúrese de añadirlas en su totalidad aquí:

      /etc/bind/named.conf.local — updated (secondary)

      zone "nyc3.example.com" {
          type slave;
          file "db.nyc3.example.com";
          masters { 10.128.10.11; };  # ns1 private IP
      };
      
      zone "128.10.in-addr.arpa" {
          type slave;
          file "db.10.128";
          masters { 10.128.10.11; };  # ns1 private IP
      };
      

      Ahora, guarde y cierre el archivo named.conf.local.

      Ejecute el siguiente comando para comprobar la validez de sus archivos de configuración:

      Una vez comprobado esto, reinicie BIND:

      • sudo systemctl restart bind9

      Permita conexiones DNS al servidor alterando las reglas del firewall UFW:

      Ahora, tiene servidores DNS primario y secundario para la resolución de nombres y direcciones IP de la red privada. Ahora debe configurar sus servidores clientes para usar sus servidores DNS privados.

      Configurar clientes DNS

      A fin de que todos sus servidores en el ACL “trusted” puedan consultar sus servidores DNS, debe configurar cada uno de ellos para que utilicen ns1 y ns2 como servidores de nombres. Este proceso varía dependiendo de su sistema operativo, pero para la mayoría de distribuciones Linux implica añadir sus servidores de nombres al archivo /etc/resolv.conf.

      Clientes de Ubuntu 18.04

      En Ubuntu 18.04, la red se configura con Netplan, una abstracción que le permite escribir una configuración de red estandarizada y aplicarla a software de redes de backend no compatible. Para configurar el DNS, debemos escribir un archivo de configuración de Netplan.

      Primero, encuentre el dispositivo asociado con su red privada consultando la subred privada con el comando ip address:

      • ip address show to 10.128.0.0/16

      Output

      3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1 valid_lft forever preferred_lft forever

      En este ejemplo, la interfaz privada es eth1.

      A continuación, cree un nuevo archivo en /etc/netplan llamado 00-private-nameservers.yaml:

      • sudo nano /etc/netplan/00-private-nameservers.yaml

      Dentro de este, pegue el contenido siguiente. Deberá modificar la interfaz de la red privada, las direcciones de sus servidores DNS ns1 y ns2, y la zona DNS.

      Nota: Netplan usa el formato de serialización de datos YAML para sus archivos de configuración. Debido a que YAML utiliza sangría y espacios en blanco para definir la estructura de sus datos, asegúrese de que en su definición se utilice una sangría uniforme para evitar errores.

      /etc/netplan 00-private-nameservers.yaml

      network:
          version: 2
          ethernets:
              eth1:                                 # Private network interface
                  nameservers:
                      addresses:
                      - 10.128.10.11                # Private IP for ns1
                      - 10.132.20.12                # Private IP for ns2
                      search: [ nyc3.example.com ]  # DNS zone
      
      

      Guarde y cierre el archivo cuando haya terminado.

      A continuación, indique a Netplan que intente usar el nuevo archivo de configuración con netplan try. Si existen problemas que ocasionen una pérdida de redes, Netplan cancelará los cambios tras un tiempo de espera:

      Output

      Warning: Stopping systemd-networkd.service, but it can still be activated by: systemd-networkd.socket Do you want to keep these settings? Press ENTER before the timeout to accept the new configuration Changes will revert in 120 seconds

      Si la cuenta regresiva se actualiza correctamente en la parte inferior, la nueva configuración es al menos suficientemente funcional como para no interrumpir su conexión SSH. Pulse ENTER para aceptar la nueva configuración.

      Ahora, verifique la resolución DNS del sistema para determinar si se plicó su configuración de DNS:

      • sudo systemd-resolve --status

      Desplácese hasta ver la sección de la interfaz de su red privada. Debería ver las direcciones IP privadas de sus servidores DNS enumeradas primero, seguidas de algunos valores alternativos. Su dominio debería figurar en “DNS Domain”:

      Output

      . . . Link 3 (eth1) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.2 67.207.67.3 DNS Domain: nyc3.example.com . . .

      Con esto, su cliente debería quedar configurado para usar sus servidores DNS internos.

      Clientes de Ubuntu 16.04 y Debian

      En servidores de Ubuntu 16.04 y Debian Linux, puede editar el archivo /etc/network/interfaces:

      • sudo nano /etc/network/interfaces

      En su interior, encuentre la línea dns-nameservers y anteponga sus propios servidores de nombres a la lista que se encuentra allí. Debajo de esa línea, añada una opción dns-search orientada al dominio base de su infraestructura. En nuestro caso, esto sería “nyc3.example.com”:

      /etc/network/interfaces

          . . .
      
          dns-nameservers 10.128.10.11 10.128.20.12 8.8.8.8
          dns-search nyc3.example.com
      
          . . .
      

      Guarde y cierre el archivo cuando haya terminado.

      Ahora, reinicie sus servicios de red y aplique los nuevos cambios con los comandos siguientes. Asegúrese de sustituir eth0 por el nombre de su interfaz de red:

      • sudo ifdown --force eth0 && sudo ip addr flush dev eth0 && sudo ifup --force eth0

      Con esto debería reiniciarse su red sin que se desactive su conexión actual. Si funcionó correctamente, debería ver algo como esto:

      Output

      RTNETLINK answers: No such process Waiting for DAD... Done

      Compruebe que sus ajustes se hayan aplicado escribiendo lo siguiente:

      Debería ver sus servidores de nombres en el archivo /etc/resolv.conf, además de su dominio de búsqueda:

      Output

      # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.128.10.11 nameserver 10.128.20.12 nameserver 8.8.8.8 search nyc3.example.com

      Con esto, su cliente quedará configurado para usar sus servidores DNS.

      Clientes CentOS

      En CentOS, RedHat y Fedora Linux, edite el archivo /etc/sysconfig/network-scripts/ifcfg-eth0. Es posible que deba sustituir eth0 por el nombre de su interfaz de red primaria:

      • sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

      Busque las opciones DNS1 y DNS2, y fije para ellas las direcciones IP privadas de sus servidores de nombres primario y secundario. Añada un parámetro DOMAIN que será el dominio básico de su infraestructura. En esta guía, sería “nyc3.example.com”:

      /etc/sysconfig/network-scripts/ifcfg-eth0

      . . .
      DNS1=10.128.10.11
      DNS2=10.128.20.12
      DOMAIN='nyc3.example.com'
      . . .
      

      Guarde y cierre el archivo cuando haya terminado.

      Ahora, reinicie el servicio de red escribiendo lo siguiente:

      • sudo systemctl restart network

      El comando puede demorarse unos segundos, pero debería hacer que regrese a la línea de comandos pronto.

      Compruebe que sus cambios se hayan aplicado escribiendo lo siguiente:

      Debería ver sus servidores de nombres y el dominio de búsqueda en la lista:

      /etc/resolv.conf

      nameserver 10.128.10.11
      nameserver 10.128.20.12
      search nyc3.example.com
      

      Su cliente ahora debería poder conectarse a sus servidores DNS y usarlos.

      Probar clientes

      Utilice nslookup para comprobar si sus clientes pueden enviar consultas a sus servidores de nombres. Debería poder hacer esto en todos los clientes que haya configurado y estén en el ACL “trusted”.

      Para los clientes de CentOS, es posible que deba instalar la utilidad con lo siguiente:

      • sudo yum install bind-utils

      Podemos comenzar realizando una búsqueda directa.

      Búsqueda directa

      Por ejemplo, podemos realizar una búsqueda directa para obtener la dirección IP de host1.nyc3.example.com ejecutando el siguiente comando:

      La consulta de “host1” se expande a “host1.nyc3.example.com” porque la opción search se fijó en su subdominio privado y las consultas de DNS intentarán realizar búsquedas en ese subdominio antes de buscar el host en otra parte. El resultado del comando anterior debería tener este aspecto:

      Output

      Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: host1.nyc3.example.com Address: 10.128.100.101

      A continuación, podemos comprobar búsquedas inversas.

      Búsqueda inversa

      Para probar la búsqueda inversa, consulte el servidor DNS con la dirección IP privada de host1:

      El resultado debería tener el siguiente aspecto:

      Output

      11.10.128.10.in-addr.arpa name = host1.nyc3.example.com. Authoritative answers can be found from:

      Si los nombres y las direcciones IP se resuelven a los valores correctos, eso significa que sus archivos de zona se configuraron correctamente. Si recibe valores inesperados, asegúrese de revisar los archivos de zona en su servidor DNS primario (por ejemplo, db.nyc3.example.com y db.10.128).

      ¡Felicitaciones! Sus servidores DNS internos ahora estarán correctamente configurados. A continuación, abordaremos el mantenimiento de sus registros de zona.

      Mantener registros DNS

      Ahora que dispone de un DNS interno activo, deberá mantener sus registros DNS para que se reflejen de forma precisa en su entorno de servidor.

      Añadir un host a un DNS

      Siempre que añada un host a su entorno (en el mismo centro de datos), le convendrá añadirlo al DNS. A continuación, se ofrece una lista de los pasos que debe seguir:

      Servidor de nombres primario

      • Archivo de zona de reenvío: añada un registro “A” para el nuevo host e incremente el valor de “Serial”.
      • Archivo de zona inversa: añada un registro “PTR” para el nuevo host e incremente el valor de “Serial”.
      • Añada la dirección IP privada del nuevo host al ACL “trusted” (named.conf.options).

      Pruebe sus archivos de configuración:

      • sudo named-checkconf
      • sudo named-checkzone nyc3.example.com db.nyc3.example.com
      • sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

      A continuación, vuelva a cargar BIND:

      • sudo systemctl reload bind9

      Con esto, su servidor primario debería estar configurado para el nuevo host.

      Servidor de nombres secundarios

      • Añada la dirección IP privada del nuevo host al ACL “trusted” (named.conf.options).

      Compruebe la sintaxis de la configuración:

      A continuación, vuelva a cargar BIND:

      • sudo systemctl reload bind9

      Su servidor secundario ahora aceptará conexiones del nuevo host.

      Configure el nuevo host para que use su DNS

      • Configure /etc/resolv.conf para que use sus servidores DNS.
      • Realice una prueba usando nslookup.

      Eliminar el host del DNS

      Si elimina un host de su entorno, o quiere quitarlo del DNS, simplemente quite todo lo que se añadió cuando agregó el servidor al DNS (es decir, el procedimiento inverso de los pasos anteriores).

      Conclusión

      Ahora puede consultar las interfaces de red privada de sus servidores por nombre, en lugar de hacerlo por dirección IP. Esto hace que la configuración de los servicios y aplicaciones sea más fácil porque ya no tendrá que recordar las direcciones IP privadas, y será más fácil leer y comprender los archivos. Además, ahora podrá cambiar sus configuraciones para que apunten a un nuevo servidor en un único lugar, su servidor DNS primario, en vez de tener que editar una variedad de archivos de configuración distribuidos, lo cual facilita el mantenimiento.

      Una vez que complete su configuración de DNS interna, y que sus archivos de configuración usen FQDN privados para especificar las conexiones de red, será esencial que se realice un mantenimiento correcto de sus servidores DNS. Si los dos dejan de estar disponibles, aquellos de sus servicios y aplicaciones que dependan de ellos dejarán de funcionar correctamente. Por ello, se recomienda configurar su DNS con al menos un servidor secundario y realizar copias de seguridad funcionales de todos ellos.



      Source link