Gobierno Bolivariano de Venezuela
Abuso

En esta sección, hemos incluído un conjunto de recomendaciones sobre la operación de su red dentro de Internet que le ofrecemos a la comunidad, con la intención de que sirva como ayuda a los administradores de red que recién incursionan en el mundo de Internet.


Configuración de Inversos

Los inversos o reversos son la asociación de un nombre completamente calificado (máquina y dominio) con un número IP. Como todos los recursos de nomenclatura en Internet, se proveen a través de DNS, usando unos registros que típicamente son los IN PTR. Por ejemplo, para saber qué nombre tiene asociado la dirección IP 1.2.3.4, consultaríamos el siguiente registro:

4.3.2.1.IN-ADDR.ARPA

Debe consultar con su PSI o ente que le asigna el espacio IP, dónde configurar estos registros. Es vital que todo su espacio de direcciones cuente con inversos que identifiquen a la organización responsable por su operación. No hacerlo, implica mayores dificultades para quienes necesitan contactar al administrador de una determinada dirección IP.

Si Ud. opera un PSI o asigna espacio IP a sus clientes, tiene esencialmente dos opciones para lograr este objetivo: Administrar los inversos para sus clientes o delegar la resolución al servidor de su cliente. La delegación está explicada muy claramente en RFC-2317/BCP-20.

Lo que sigue, es el fragmento de un hipotético archivo de zona en el que Ud. controla la información del espacio IP que le fué delegado, bajo 3.2.1.IN-ADDR.ARPA, usando BIND.

; Estos son meta-comandos de BIND para controlar parámetros de la
; información de la zona.
$TTL    86400
$ORIGIN 3.2.1.IN-ADDR.ARPA

; Este es el registro SOA tradicional
@       IN      SOA     localhost. hostmaster.domain.  (
                                      1997022700 ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      86400 )    ; Minimum
        IN      NS      su.servidor.domain.
        IN      NS      otro.servidor.domain.

; Asignamos 1.2.3.0/30 a un cliente y nos pidió que le diéramos
; servicio de inversos...

0       IN      PTR     server-0.cliente.
1       IN      PTR     server-1.cliente.
2       IN      PTR     server-2.cliente.
3       IN      PTR     server-3.cliente.

; $GENERATE es un comando de BIND que permit producir nombres
; en forma genérica y sencilla. Esta es otra forma de asignar
; nombres a la red de un cliente, que administra 1.2.3.4/30
; (Ojo que $GENERATE sólo se encuentra en BIND 8 y 9).

$GENERATE 4-8 $ IN PTR  server-$.cliente2.

; Este es un cliente que tiene sus propios servidores de DNS y nos
; pidió que le delegáramos 1.2.3.8/30 para que el administre sus
; propios inversos

8/30    IN      NS      servidor-1.cliente.
8/30    IN      NS      servidor-2.cliente.
8/30.8  IN      CNAME   8.8/30.3.2.1.IN-ADDR.ARPA.
8/30.9  IN      CNAME   9.8/30.3.2.1.IN-ADDR.ARPA.
8/30.10 IN      CNAME   10.8/30.3.2.1.IN-ADDR.ARPA.
8/30.11 IN      CNAME   11.8/30.3.2.1.IN-ADDR.ARPA.

; El resto de nuestro espacio, tiene un nombre genérico. Ojo que
; si define _cualquier_ tipo de registro para una entrada en esta
; zona, deberá también incluir el IN PTR en la definición.

*       IN      PTR     no-asignado.domain.

Una excelente razón para esto, es que cada vez más organizaciones, entre ellas Cantv.net, rechazan correo proveniente de servidores que carecen de un inverso.

De hecho, Cantv.net no sólo revisa la existencia, sino la estructura del nombre que Ud. asigna, para ayudarse a decidir si el espacio IP afectado es asignado en forma estática o dinámica. Un ejemplo de para qué usamos esta información, es nuestra lista para filtrar correo dul.blackhole.cantv.net. Para determinar si sus inversos apuntan o no a espacios dinámicos, puede consultar este servicio.

<<


Direcciones administrativas

La práctica operacional en Internet, requiere la existencia de un número de buzones o direcciones electrónicas para la recepción de mensajes relacionados con aspectos del día a día en la red. La guía definitiva acerca de los buzones y sus propósitos, es RFC-2142

Como mínimo, una organización debe definir los siguientes buzones, junto a los que indicamos recomendaciones específicas.

  • abuse@: Esta dirección es frecuentemente utilizada para el reporte de violaciones a los términos de uso aceptables. Debe ser leída con mucha frecuencia por un equipo de personas con habilidades técnicas suficientes como para comprender los reportes de abuso, identificar la fuente y tomar rápidamente las acciones correctivas necesarias para detener la situación que generó el reporte en primer lugar. Un tiempo de respuesta de 24 a 48 horas pareciera ser un excelente registro al momento de redactar este documento.

    También se recomnienda que esta cuenta sea exenta de protecciones anti virus, anti spam o de otra índole, para que los reclamos puedan incluir evidencia de la actividad reportada.

  • postmaster@: Esta dirección debe ser leída con mucha frecuencia por los administradores de su servicio de mensajería.

  • hostmaster@: Esta dirección debe ser leída con frecuencia por los administradores de DNS de su organización.

  • webmaster@: Esta dirección debe ser leída por quienes mantienen su página web.

No mantener o responder adecuadamente a las direcciones abuse@ y postmaster@ tarde o temprano, hará que su organización sea incluída en rfc-ignorant.org por no respetar los estándares y prácticas.

No basta con mantener y operar esas direcciones. Su organización debe anunciarlas públicamente en el registro WHOIS correspondiente. Adicionalmente, puede registrarse en abuse.net para facilitar la consulta y el enrutamiento de quejas o notificaciones.

<<


Configuración de la plataforma de correo

Su plataforma de correo debe ser asegurada de modo que a un tercero no relacionado con Ud. le sea imposible enrutar un mensaje usando su plataforma, hacia otros destinos. Este problema se conoce como Open Relaying.

Si Ud. no corrige este problema con diligencia, se correrá rápidamente la voz de que su servidor es abusable y será abusado. Esto ocurre usualmente antes del primer o segundo día de conexión a la red, de modo que es vital que ponga atención a este detalle.

Igualmente, es recomendable el uso de filtros anti spam y anti virus, tanto en la entrada de correo hacia sus usuarios, como en la salida de mensajes desde sus usuarios. Esto evita que máquinas infectadas puedan abusar de su plataforma para propagar la infección.

Si controla los dispositivos de acceso a la red, también es buena idea que considere bloquear la salida correo que no sea a través de su servidor. Esto minimiza las probabilidades que un equipo abusado en su red le cause problemas.

Un aspecto de la configuración que frecuentemente es omitido, es el nombre que reciben los equipos. Los nombres de los equipos deben ser consistentes con los inversos de sus direcciones IP (registros IN PTR). También es buena idea que el nombre indique que se trata de una parte de su plataforma de correo. Algunos ejemplos de nombres bien conocidos, son estos:

  • mail.<TLD>

  • smtp.<TLD>

  • relay.<TLD>

  • pop.<TLD>

  • imap.<TLD>

  • correo.<TLD>

Si bien la nomenclatura no es un requisito, es un factor que puede ayudarle a mejorar la respuesta de otros administradores. Por ejemplo, Cantv.net usa este criterio para ayudar a decidir si un determinado equipo es parte de la infraestructura de correo, antes de incluir direcciones IP en una de sus listas.

<<


Virus, gusanos y otras amenazas

Hoy en día, hay una estrecha relación entre la infección con virus y gusanos, y formas de abuso como el envío de mensajes masivos no solicitados. Debe asegurarse de que todos los equipos bajo su administración, cuentan con defensas adecuadas contra virus, spyware y otros.

<<