DNS: Bloquear o no bloquear las direcciones IPv6 6to4

Introducción

  El servicio de DNS es sin duda alguna uno de los pilares de Internet, sin DNS el Internet no sería ni remotamente como lo conocemos hoy en día.

  DNS es el servicio que permite -entre otras funciones- convertir nombres de dominios a direcciones IP y viceversa.

Sobre el proyecto IPv6 Open Resolvers:

  Dentro de Lacnic, desde comienzos del año 2018 [1] estamos en la búsqueda de servidores DNS sobre IPv6 que son consideraciones “Open Resolvers” [2]

¿Que tiene que ver 6to4 con Open Resolvers y seguridad?

  Durante el tiempo que tiene este proyecto en funcionamiento hemos tenido la oportunidad de exponer el estudio y sus resultados [3] en sitios como DNS-OARC 28 , LACNIC 29 y NANOG 74. En esta última, recibimos muy buenos comentarios y quizás el más significativo fue el de George Wes donde él indicaba la existencia de muchos servidores DNS con direcciones IP 6to4 [4] las cuales utilizan direcciones IP de túneles automáticos dentro del prefijo 2002::/16.

  En base a lo anterior, decidimos profundizar en este concepto y estudiar con más detalle los resolvers con direcciones IPv6 6to4 y obtuvimos información muy interesante.

  Por ejemplo, el día 2 de Diciembre del 2018 estudiamos: 6248 servidores, de los cuales 61 estaban contenidos en el prefijo 2002::/16, y de aquí tuvimos 20 servidores abiertos, es decir, casi un 33%. Todos ellos potenciales para realizar diferentes ataques de DNS como de amplificación, cache poisoning, DDoS, DNS hijacking, entre otros.

  Aquí tenemos dos gráficos de lo arriba expuesto:

   Conclusión

   Primero, el problema per sé no es el 6to4, son los Open Resolvers. Segundo, como administrador de servidores DNS ustedes deben querer responder a la mayor cantidad de queries posibles de clientes válidos, nuestra recomendación no se ajusta solo a redes 6to4, sino básicamente la implementación de RLL (Response Rate Limit) a los queries según el origen, claro prestarle mayor atención a las provenientes del prefijo 2002::/16 no es mala idea.

Referencias

[1]https://labs.lacnic.net/aportando_un_grano_de_arena_en_la_seguridad_de_la_red/

[2] https://www.bsi.bund.de/EN/Topics/IT-Crisis-Management/CERT-Bund/CERT-Reports/HOWTOs/DNS-Open-Resolver/DNS-Open-Resolver_node.html

[3] https://stats.labs.lacnic.net/IPv6/DNSOpenResolver/

[4] https://en.wikipedia.org/wiki/6to4

vivo v15 pro
beautiful Rohini escorts for you

3 recomendaciones al construir el registro SOA en DNS

Hola, 

  En el presente artículo solo quiero mencionar 3 consejos que al parecer son difíciles de conseguir en Internet pero que son importantes..., hay MUCHOS otros consejos que se pueden dar, repito, voy a mencionar los que quizás no son tan conocidos y a su vez pueden traer problemas operacionales.

Recordando el fomato del registro SOA:

  Un pequeño ejemplo de un registro SOA sería (tomado de una instalación de Bind):

@ IN SOA localhost. root.localhost. (

     1 ; Serial

604800 ; Refresh

 86400 ; Retry

2419200 ; Expire

604800 ) ; Negative Cache TTL

   De manera muy breve y explicándolo de manera muy entendible: 

El serial: se debe incrementar con cada modificación de la zona. Recordemos que este valor será revisado por los servidores DNS secundarios para identificar si existe algún cambio en la zona

Refresh: Cada cuando tiempo el servidor DNS secundario debe ir al servidor primario y revisar si hubo cambios (¿el valor de Serial es mayor? 

Retry: En caso de que el servidor secundario intentó comunicarse al primario y NO pudo (por la razón que fuese), cada cuanto lo vuelvo a intentar

Expire: Supongamos que el servidor secundario tiene N cantidad de tiempo "N=Expire" sin haber contactado al primario debería dejar de responder. Esto sale del principio que hace mucho que el secundario no contacta al servidor primario y la información que tenga ya puede haber cambiado, el servidor DNS secundario prefiere no dar respuesta que dar información errónea y/o desactualizada. Es decir, el servidor DEJA DE RESPONDER A LA ZONA

Negative Cache TTL: Hace referencia a cachear respuestas DNS negativas...., por ejemplo NXDOMAIN

Revisando lo anterior, nótese que los valores son casi exclusivamente utilizados por los servidores DNS Secundarios que desean hacer zone-transfer.

Consejo 1:

  El Serial nunca debería ser 0. El RFC 2136 indica en la sección 7: "Design, Implementation, Operation, and Protocol Notes". 

  7.11. A zone's SOA SERIAL should never be set to zero (0) due to

   interoperability" ...............

Consejo 2: 

  El valor de Retry no debería ser mayor a Refresh. La razón es bastante lógica, es casi como no tener valor de Retry.., primero ocurre el refresh. Adicionalmente Retry significa contactar el servidor primario para hacer el zone transfer SI NO se pudo contactar antes, con el Retry se buscar mantener la zona actualizada. RFC 1912 indica: ...... "Retry: If a secondary was unable to contact the primary at the

          last refresh, wait the retry value before trying again.  This
          value isn't as important as others, unless the secondary is on
          a distant network from the primary or the primary is more
          prone to outages.  It's typically some fraction of the refresh
          interval."

Consejo 3:

   El Expire no debe ser menor al Refresh. Similar al consejo 2 pero incluso este lo considero más importante. Si yo tengo un Expire menor que el Refresh significa que el servidor secundario va a dejar de responder la zona antes de que un intento de actualización (Refresh). Obviamente esto no es lo que se quiere. En el RFC 1912 se lee: "Expire: How long a secondary will still treat its copy of the zone

          data as valid if it can't contact the primary.  This value
          should be greater than how long a major outage would typically
          last, and must be greater than the minimum and retry
          intervals"

Referencias:

- https://tools.ietf.org/html/rfc2136
- https://www.ietf.org/rfc/rfc1912.txt

- Libro: Cookbook for IPv6 Renumbering in SOHO and
Backbone Networks "https://hal.inria.fr/inria-00000888/file/D3.6.1.pdf"  página 50 indica:  "retry should be smaller than refresh"
- Guia: "Check Point™ Meta IP User’s Guide" pagina 114 indica: "Slave Refresh must be lower than Slave Data Expire and Zone Default TTL"
- Sobre el serial no debería ser 0:  https://mxtoolbox.com/problem/dns/dns-soa-serial-number-format y https://www.digitalocean.com/community/questions/soa-serial-number-format-is-invalid  (sin embargo algunos software de DNS lo aceptan)

The best Buy vps bitcoin from eldernode.com
Where to order pain Relief without prescription
you can buy bitcoin vps from eldernode

Host your website on the fastest servers in Chicago, USA. Hundreds of features you need. Chicago Shared Hosting Easy On-boarding & Simple Website Transfer to our Platform
카지노사이트

Normas o reglas en Listas de Correo (Netiquette)

En líneas generales a la hora de estar en una lista de correo (mailing-list) uno debe comportarse igual o mejor a como lo haríamos en nuestra vida diaria.
  Aquí dejo una lista de normas que de manera general son convenientes seguir en todas aquellas listas de correo en las que participemos. Muchas a su vez sirven de nuestra vida diaria en el uso del correo electrónico.

1.- Respete las normas (este listado).

2.- Para enviar nuevos correos a la lista:

• No contestar un correo comenzando un nuevo subject
• No contestar un correo y cambiar el subject y el tema
• No contestar un correo, mantener el subject y comenzar un nuevo tema
• Crear un correo completamente nuevo y enviarlo a la dirección de la lista

3.- El correo a enviar a la lista debe ser relacionado con tópico de la misma.

4.- Evitar correos OFF-TOPIC al menos que sean muy esporádicos o pueda considerarse de interés a los participantes de la lista.

5.- Enfrentamientos, malas palabras, groserías son visto con mal gusto por parte del resto de los participantes.

6.- Es una demostración de cortesía ante los integrantes del grupo:

• Si usted comentió un error: reconocerlo
• Ser humilde en sus respuestas a pesar de sus conocimientos
• Enviar respuestas directas a las preguntas
• Suscribirse con una cuenta de correo donde no utilice Auto-Responder
• Ser cordial, decir buenos días, gracias, por favor, me gustaría, entre otros
• Compartir tus conocimientos con los otros
• Respetar la privacidad de los demás
  
  

6.- El correo máximo por línea debe contener 75 caracteres

7.- Se aconseja el uso de emoticones como: :-(, :-) ellos ofrecen cuerpo al mensaje y mejora la intención del mismo expresando mejor chistes, mensajes sarcásticos, etc.

8.- Es una buena práctica contestar dentro del cuerpo del correo anterior, el mismo utilizar el cáracer “ >” como indicador del correo previo

9.- Borrar el final de algunos correos (información de Antivirus y cosas no relevantes de la conversación)

10.- No escribir correos todo en mayúsculas ni todo en minúsculas. Un correo en MAYÚSCULAS indica que estás gritando.

11.- Para destacar argumentos dentro del correo se recomienda usar comillas o raya inferior (_) alrededor de la palabra

12.- Se prohiben mensajes: SPAM y/o cualquier correo relacionado a publicidad de un producto, venta de servicios o productos, políticos, religiosos y otras indoles que puedan considerarse de mal gusto a los participantes.

13.- Se cuidadoso con ciertas palabras (slangs), recuerda que hay personas de diferentes países y nacionalidades que potencialmente pueden leer tu correo. El significado de cierta palabra no es la misma para tí que para el receptor.

14.- Evitar mensajes unilaterales en la lista

15.- Para algunos integrantes puede ser mal visto enviar un correo a muchas listas de correo simultáneamente. Favor crear un correo por cada lista a la que se desea enviar.

16.- Favor incluir -al menos- tu nombre en el correo. Esto es particularmente importante en aquellos participantes que usan direcciones de correo donde no aparece el nombre o cuentas de correo genéricas (noc@... routing@... ventas@)

17.- Favor revisa el correo antes de enviarlo.

18.- Configura la hora correcta de tu cliente de correo electrónico, basado en timezone.

19.- Se tolerante en los debates. Objetivo en las discusiones

20.- Por ultimo: "Se tolerante con lo que recibes, se precavido con lo que envías". Recuerda que un correo tuyo es potencialmente leído por otras personas.

El listado de arriba es un resumen de mi experiencia como participante por muchos años en listas de correo, ser co-fundador de otras listas y moderador actual de una lista de más de 800 participantes.

Espero sea útil,

Arrancar/bootear Mandriva sin X

Mini historia:

  Aunque parezca mentira hacer arrancar Mandriva sin interfaz gráfica (X) ha sido una verdadera pesadilla.

  Quizás algunos de ustedes agradezcan este post :)  en fin solo deseo que sea útil. Allí va:


Objetivo:
  Arrancar Mandriva Linux sin interfaz gráfica (para ahorrar memoria, CPU, seguridad, no lo necesito o sencillamente no quiero X)


Intentos infructuosos:
  Luego de muchos intentos donde se incluye la teoria de colocar Unix en runlevel 3 para multiuser en /etc/inittab, bueno, todo eso no funciona.

  Entre otras cosas también intenté link al estilo:



ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

(tampoco funciona)

Intenté también:

chkconfig --level 234567 dm off

(tampoco funciona)

   Y muchas otras cosas que me hicieron perder el tiempo

Solución definitiva:
  La solución ni siquiera fue por el OS, sino por el GRUB!, la solución es indicar en menu.lst al final de la linea el runlevel con el que deseas arrancar.
  Por ejemplo:

#more /boot/grup/menu.lst



title linux
kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=linux root=UUID=c578d361-dc13-4821-ba42-e
f01abc2c55c  nokmsboot logo.nologo quiet resume=UUID=48a9d362-4b8c-40da-a0a4-775
c6072f2ac splash=silent vga=788 3
initrd (hd0,0)/boot/initrd.img


  Noten el "3" al final de la linea.

  Luego reinician el equipo y listo!!

Importante:
  Es posible que deben utilizar la combinación ALT+F2, ALT+F3, etc para moverse entre los vty, de igual manera recordemos que runleven 3 es multiuser y networking.


Suerte!,

9 Consejos en administracion de routers Cisco

Tip 1. Mas información en la descripción de las interfaces
Colocar en la descripción de la interfaz en el nro de circuito y nombre del proveedor. Por Ejemplo

interface Serial0/0/0
description Mi cliente-A. CKT ID: A-1000123. Proveedor. Sprint
bandwidth 2048
ip address 10.0.0.61 255.255.255.252
ip load-sharing per-packet
no ip mroute-cache
load-interval 30
no fair-queue
crc4
ts16
no cdp enable

Tip 2. Prevencion del uso de debug
Al momento de realizar un debug recomiendo realizar ejecutar el comando undebug all, de esta manera luego eliminar el debug es tan rapido con darle dos veces a la flecha hacia arriba y luego enter.


Tip 3. Utilizar Reload at y reload in
En repetidas oportunidades nos vemos en la necesidad de ejecutar comandos que probablemente nos dejen sin adminitración del equipo remoto (pe. cambiar una dirección IP, configurar un trunking, etc). Dentro de un mismo datacenter no existe mucha preocupación, pero si el equipo a modificar se encuentra a 500KM es muy riesgoso. En esta oportunidad recomiendo tomar ventaja del comando "reload at" o del comando "reload in".
Por ejemplo, digamos que vamos a modificar la dirección IP del equipo remoto y luego comprobaremos que seguimos con administración del mismo. ¿Cuanto tiempo toma esto?, ¿8 minutos?.
Hariamos lo siguiente:

a) Telnet/SSH al router remoto
b) #reload in 8
Reload scheduled for 14:31:22 CARACAS Mon Jan 11 2010 (in 8 minutes)
Proceed with reload? [confirm]
c) Luego de lo anterior tenemos 8 minutos para configurar todo lo que sea necesario (IP, ACLs, etc).
d) Si los resultados son satisfactorios cancelamos el reload con el comando "reload cancel":
#reload cancel

***
*** --- SHUTDOWN ABORTED ---
***


e) Si los cambios no son satisfactorios (por ejemplo perdimos la administración del equipo remoto) el equipo se reiniciará en 8 minutos y podremos seguir trabajando debido a que no hemos hecho write mem

Tip 4. Asociar subinterfaces
Al momento de crear subinterfaces (por ejemplo Dot1Q o FrameRelay) recomiendo asociar el nunero de subinterfaz con el numero de DLCI o VLAN. Por ejemplo:

interface FastEthernet1/1/0.6
description Red 10.0.0.0/29
encapsulation dot1Q 6
ip address 10.0.0.1 255.255.255.248
no cdp enable

Tip 5. Uso de atajos de teclados
Cisco ofrece gran variedad de atajos con el teclado al momento de manipular comandos. Por ejemplo podemos borrar el comando (la linea), ir al comienzo del comando o al final de manera muy rápida, todo esto se traduce en ahorro de tiempo. Aquí te dejo los más utilizados:

Flecha hacia arriba: Muestra el comando previo
Flecha hacia abajo: Muestra comandos mas recientes referentes a la posición actual
Ctrl+P = Flecha hacia arriba
Ctrl+N = Flecha hacia abajo
Ctrl+A: Mueve el cursos al comienzo de la linea
Ctrl+E: Mueve el cursos al final de la linea
Esc+F: Salta una palabra hacia adelante
Esc+B: Salta una palabra hacia atras
Ctrl+U: Borra la linea de comando
Ctrl+W: Borra una palabra
Tab: Completa el comando
Ctrl+Z: Sale del modo de configuracion, regresa a modo privilegiado

Tip 6. Manipulación de salida de comandos
Parecido al Tip 5, el IOS de Cisco ofrece cierta facilidad para manipular las salidas de los comandos. Por ejemplo, uno puede buscar cierto string luego de ejecutar un comando. Por ejemplo una salida de show arp puede ser muy larga.
Digamos que queremos buscar la mac-address del equipo con la dirección ip 10.0.1.26, hariamos lo siguiente:

#sh arp | include 10.0.1.26
Internet 10.0.1.26 234 001c.9020.d01b ARPA FastEthernet1/1/0.14

Similar a include podemos conseguir: include, exclude y begin

Tip 7. Syslog Server
Cisco tiene la desventaja que luego de reiniciar el router/switch se pierden los logs del mismo, esto trae como consecuencia perdida de información por ejemplo de cuando levanta/cae una sesión eigrp, bgp, estado de las interfaces, etc. Por ello recomiendo tener un syslog server externo (tal como syslog server ng en Linux) compilar los logs de tus equipos. El comando en Cisco puede ser tan sencillo como:
MiSwitch(config)#logging 10.0.0.76

Donde 10.0.0.76 es el Syslog Server

Tip 8. Uso de NTP Server.
Es muy ventajoso tener todos los equipos de la red con la misma hora y el mismo huso horario, esto trae como ventaja ofrecer un troubleshooting más sencillo y conseguir errores más rápido. Al momento de un inconveniente si todos los equipos tienen horas diferentes es muy complicado hacer seguimiento de los errores y determinar si los mismos estan relacionados uno con otros.
En Cisco para configuar un NTP y el timezone se realiza de la siguiente manera:

clock timezone CARACAS -4 30
ntp server 128.250.36.2 prefer
ntp server 128.250.36.3
ntp server 136.159.2.254

En el ejemplo anterior CARACAS es el timezone, -4 30 correnponde al huso horario de Caracas y los siguientes comandos son servidor NTP publicos. También puedes utilizar servidor NTP internos si tus equipos Cisco no cuentan con acceso a Internet

Tip 9. Ajustar el log y el timestamp
Otro ajuste que me agrada hacer en la configuración de los equipos Cisco es ajustar el log interno y la manera como marca los mismos. Luego de tener el NTP, ajusto el tamaño de los logs y quiero que me indique hora y fecha de los mismos del lado izquierdo, para ello los comandos son los siguientes:

service timestamps debug uptime
service timestamps log datetime localtime
logging buffered 32000 debugging

Un ejemplo de lo anterior sería lo siguiente:

Jan 13 07:03:49: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEther
net1/0/10 (not half duplex), with Torondoy-NOC Ethernet0 (half duplex).

Notese que me aprece la fecha y hora al comienzo del registro del log



Eso es todo, espero estos tips sean de utilidad,

Tips de Seguridad para Linux

A la hora de instalar un Servidor en Linux, el paso del tiempo me ha dado ciertas experiencia a la hora de ajustar politicas de seguridad. Muchas de ellas van a ayudar a que nuestro servidor se encuentre mas seguro.

A continuacion, comparto varias de las politicas que siempre mantengo en mente a la hora de configurar un servidor.

Siempre despues de instalar un servidor, aprovecho para hacer estos cambios.

1) Con el comando chkconfig, elimino los siguientes daemons:
ppp, bind9 ( a menos que sea un servidor DNS), lwresd, portmap, exim4, netatalk, samba, fam, nfs-common, atd, apache2.

E inclusive, sino son necesarios, los elimino

2) Me aseguro de que el siguiente parametro este en el archivo /etc/security/limits.conf

* hard core 0

3) Asegurarse tambien de que las siguientes lineas esten en el archivo /etc/pam.d/login

session required /lib/security/pam_limits.so

4) Comento la siguiente linea en el archivo /etc/inittab

ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

ejm:

#ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

5) Las claves deben de expirar cada 90 dias, esto se hace editando el siguiente parametro en /etc/logins.def

MASS_MAX_DAYS 90

6) Elimino las siguientes cuentas (/etc/passwd, /etc/shadow)

games, lp, news, uucp, proxy, irc, gnats, list


7)Cambio el shell por defecto de los siguientes usuarios a /bin/false
bin, daemon, mail, nobody, sync, sys

8) Elimino cualquier informacion que contengan los archivos

/etc/issue
/etc/issue.net

9)Todo los ejecutables que tenga el setuid y setgid, por defecto, ninguno puede ser escrito por el grupo "others"

find / -perm -4000 -exec ls -l {} \;
find / -perm -2000 -exec ls -l {} \;

Ejm
-rwsr-xr-x 1 root root 31640 2008-11-22 11:01 /usr/bin/passwd
||



9) Modifico el parametro a continuacion en el archivo /etc/login.defs:

LOGIN_RETRIES 3

( crear el archivo /var/log/faillog para grabar todo los intentos de acceso)

10) Editamos el archivo /etc/pam.d/common-password y nos aseguramos de que la opcion min=8 este en la configuracion de pam_unix


Estos tips van a ayudar de cierta manera a asegurar el servidor, mas adelante, colocare unas herramientas que van a ayudarnos a realizar tareas sobre el sistema y verificar la integridad del mismo.