VPSs y mas.

Mostrando entradas con la etiqueta consejos. Mostrar todas las entradas
Mostrando entradas con la etiqueta consejos. Mostrar todas las entradas

lunes, 30 de enero de 2017

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:
- 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)

viernes, 19 de octubre de 2012

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,



lunes, 11 de enero de 2010

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,

viernes, 5 de junio de 2009

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.