The Security Skeptic

Procedimientos recomendados para firewall - Egreso Filtrado de tráfico

en inglés

Muchos administradores de red piensan sólo en proteger los recursos privados de ataques externos en la evaluación de amenazas de seguridad. El panorama de hoy está lleno de amenazas que emanan de los equipos dispositivos infectados con malware. Los atacantes pueden utilizar éstos para recoger y transmitir información sensible de su red, para atacar o para enviar spam a otras redes. Las organizaciones están mejor protegidas cuando los administradores de red están también preocupados por las amenazas que están asociadas con las conexiones de salida. En esta columna, se discuten alternativas que pueden mejorar su perfil de riesgo mediante “la aplicación de filtrado de tráfico de salida”.

Protéjase: Filtre el tráfico de egreso

Si ustedes no restringen los servicios que los equipos en su red pueden usar, es posible que un pirata informático pueda usar malware para exfiltrar dato a un equipo que los controla; por ejemplo, vía equipos infectados con una amenaza persistente y avanzada (APT).  La filtración de datos puede ser involuntaria; por ejemplo, un usuario puede transmitir información sensible en un adjunto de correo electrónico, o puede ser un error de configuración que causa la fuga de NetBIOS, DNS, u otro tráfico de servicio. La misma, también puede ser maliciosa.

Independientemente de la causa, Usted no puede mitigar la exfiltración de datos si no usa filtros de egreso para distinguir tráfico malicioso del válido. Y usted no podrá uedan detectar ataques si no graban eventos o no examinan trafico.

Filtrar el tráfico egreso y no hacer daño

En las configuraciones mas laxas (y tristemente, en las configuraciones por defecto), un firewall puede tratar el tráfico de salida como válido sin controlar la dirección IP de orígen. Fred Avolio llama a esto "The Nefarious Any". Estas configuraciones son posibles campos de ataques de IP forjadas (IP spoofing). Equipos comprometidos o equipos no autorizados que tienen acceso a sus redes locales pueden utilizar IP spoofing para atacar otras redes (DDoS), para almacenar abuso infantil u otro material ilegal, o para llevar a cabo campañas de spam o phishing. Es un problema serio para cualquier red, pero es especialmente malo si su red tiene múltiples conexiones de acceso a Internet, su red puede ser utilizada como una red de tránsito para el tráfico malicioso que sale desde otras organizaciones.

Un pirata informático pueda usar equipos comprometidos o equipos no autorizados que tienen direcciones válidas también, para transmitir spam, para ejecutar malware, o para alojar sitios de phishing. En un DNS comprometido, un pirata puede alojar "zone data" de nombres de dominios maliciosos. Es posible que un pirata puede usar equipos comprometidos para alojar cualquier servicio que usa UDP (chargen, NTP, SNMP) para acciones criminales.

Los filtros de egreso protejen a nuestras redes y pueden protejer el mundo de ataques que salen desde nuestras propias redes.

Paso # 1: Crear una política de tráfico de egreso

Empiecen por consultar su Política de Seguridad o su Política de Uso Aceptable. Si no tienen estas políticas, ustedes deben invitar a las partes interesadas a crearlas inmediatamente. ¿Quién es responsable de la redacción de estas políticas? Cualquier persona que tiene responsabilidades de seguridad de la red, administración de riesgos o asuntos legales. Si no tienen políticas, la configuración del firewall será ad hoc, un conjunto de reglas para satisfacer cualquier deseo de los usuarios: no es una política, es un caos. Empiecen por hacer una lista de los servicios necesarios, y la lista de políticas que lo permitan. Típicamente este lista incluye DNS, POP/IMAP, SMTP, NTP, and HTTP/HTTPS. Piensan en los destinos maliciosos y direcciones de Internet, y cómo se puede bloquear estos.

Si su organización opera DNS, correo electrónico, o otros servicios en sus propios servidores, creen una lista de los servicios, direcciones Internet y nombres de dominio de estos servicios internos. Hagan una lista de cada sitio Internet que los servidores internos necesiten contactar. Por ejemplo, si opera "split-DNS" incluya cualquier servidor DNS públicos que su servidor interno deba comunicarse para transferencia de zona. Si opera SMTP, incluya cualquier servidor que su servidor deba comunicarse para transferir correo electrónico (típicamente su ISP). Si usted tiene la intención de bloquear contenido web en un proxy o firewall, haga una lista de los tipos de contenido a permitir o bloquear. Puede ser necesario crear diferentes grupos de usuarios si usted tiene varias políticas de contenido web.

Paso # 2 : Matar al nefasto CUALQUIERA

El mejor método para configurar filtros de egreso empieza con una regla firewall: bloquear o negar todo trafico egreso. A partir de "ningún tráfico puede salir sin mi permiso explícito”, crear reglas para permitir cada tráfico autorizado según indique la política de seguridad. Si la política permite, añada reglas en forma granular y restrictiva. Reglas que permitan comunicaciones entre los servidores internos y servidores Internet que figuren en la lista de su política.

Muchos firewalls tienen un regla predeterminada que permiten tráfico de cualquier dirección origen en las redes internas. Esta política es peligrosa.

Entonces restrinja el tráfico a destinos de Internet con estas reglas:

• Enumere los direcciones válidas (o mascaras de subred) para sus redes y cree una regla en el firewall de acuerdo a ella.

• Bloquear IP spoofing. Solamente permita tráfico de salida desde direcciones internas válidas. Aplique esta regla a todas sus subredes.

• Solamente permita tráfico desde el espacio de direcciones que usted utiliza. Aplica máscaras de subred adecuadas a las redes internas; por ejemplo, máscaras que son suficientemente largas para identificar sólo ese fragmento del número de red IP que está utilizando .

• Bloquear tráfico de salida desde direcciones reservadas para redes privadas (RFC 1918/6761 o RFC 4193).

• Bloquear tráfico de salida desde grupos VLAN.

• Bloquear tráfico de salida desde redes internas que no tienen ninguna razón para comunicarse a Internet.

• Si su firewall no opera capa tres, es necesario bloquear el tráfico de difusión (capa dos firewall).

• Bloquear tráfico de salida desde servidores internos que intentan establecer conexiones a equipos externos. Por ejemplo, si tiene un servidor intranet que solamente usa DNS, correo electrónico, o otros servicios internos, este servidor no debe comunicarse con servicios externo.

• Bloquear tráfico de salida a destinos que son enumerados en DROP (Don't Route Or Peer) o listas de filtros BGP. Por ejemplo, Spamhaus, mantiene listas de red secuestradas por spammers, phishers, o botnets. Los centros de datos, de universidades y redes empresariales deben bloquear DROP cuando sus ISPs no bloquean.

Paso #3: Crear reglas para restringir servicios o destinos Internet

Muchos firewalls tienen un regla predeterminada que permiten tráfico de salida a cualquier servicio de Internet. Esta política es peligrosa, es necesario matar "el nefasto cualquiera" otra vez:

• Enumere los servicios Internet que son permitidos y cree unas reglas de firewall que solamente permite el tráfico a estos servicios externos.

• Si es posible, solamente permitan usuarios conectar a servicios válidos desde servidores externos autorizados. Por ejemplo, si sus usuarios usan su ISP para correo electrónico, cree unas reglas de firewall que solamente permitan conexiones a los servidores POP y SMTP de su ISP.

• Solamente permitan usuarios consultar a servidores DNS ("resolvers") que usted opera o servidores DNS externos autorizadas. Si permite a sus usuarios consultar servidores DNS externos, solamente autoricen servidores "abierto" y seguro. Es muy importante proteger y actualizar sus servidores DNS contra ataques como DDoS.

• Si opera proxies HTTP o usted opera cualquier sistema proxy que filtra contenido, solamente permita conexiones a Internet desde estos proxies.

• Si sus servidores internos se comunican con servidores externos, cree reglas que solamente permitan acceso a servicios necesarios y bloquee todo otro servicio. Si opera servidores de correo electrónico, cree reglas que permita conexiones de salida pero bloquee conexiones de ingreso.

• Si usan servidores DNS internos o usan "split-DNS", debe usar DNS resolver internos para reenviar consultas DNS desde su red interna. Si usan nombres de dominios privados, tome medidas para realizar consultas a sus DNS privados dentro su red interna.

• Si su firewall no participa en el enrutamiento, es importante que cree reglas para bloquear los protocolos de enrutamiento de Internet desde todas direcciones (ingreso y egreso) a su firewall. Si su firewall participa en enrutamiento, cree las reglas que permita solamente los protocolos que se usan.

• Si su organización utiliza aplicaciones Internet para escritorio remoto, administración remoto, parches de software, etc., cree reglas que permitan acceso a estos puertos únicamente.

Paso #4 (final): Comprobar sus reglas, monitorear agresivamente

Habilitar el registro del tráfico de salida en el firewall, a continuación, analizar su red interna para comprobar que sus normas de tráfico de egreso satisfacen sus políticas. (Considere nmap, Nessus, o algunos de los programas informáticos comerciales que aparece en Security Wizardy.) El resultado del registro/escaneo revelará si sus “permitir / denegar” es lo que se desea.

Registrar de forma rigurosa las conexiones de salida denegadas para ayudar a identificar anomalías en el tráfico, que puede ser el tráfico de una nueva aplicación o una advertencia de las actividades maliciosas o no autorizados.

Gracias a Graciella Martinez por su ayuda en la traducción de este artículo.

How to Protect Your Privacy When You Register a GTLD Domain Name

Recent efforts to introduce or revise policies governing Whois for ICANN generic Top Level Domains have come under intense criticisms of the policy regarding public display of point of contact information associated with a domain name registration  (1, 2, 3).  In this post I provide some explanation of a domain name registrant’s obligation to provide complete and accurate point of contact information and also explain how to register a domain name without disclosing personal data.

What the RAA says

The 2013 ICANN Registrar Accreditation Agreement RAA says the following about public display of registration data: 

“The Registered Name Holder with whom Registrar enters into a registration agreement must be a person or legal entity other than the Registrar” (4)                                                   

The phrase “Legal entity other than the Registrar” is included in the RAA to make clear that submitting the name of a natural person is a choice not an obligation.  The obligation is that you submit contact data – legal name, postal address, voice telephone number, email address – that will allow parties to reach you, your business or organization, or an agent that you authorize to respond on your behalf to technical or administrative inquiries. The very existence of domain privacy services demonstrates that personal names – and identifying data generally – are not required. (It is also worth noting that subsequent clauses in the RAA accommodate the enforcement of personal data protection laws where such apply.)

There are many ways other than using your personal data or a privacy protection service to satisfy this obligation. Some examples follow.

Your registrant name need not be your natural name

If an individual chooses to do business under his or her natural person name, and also chooses to submit this name as a registrant name, then it is true that a Whois query would return the registrant’s natural person name. If you don’t want to expose your natural person name and you live in countries where personal data protection laws do not apply, you still have options.

For example, if you do business in the United States under an assumed business name (DBA), then you can submit this legal name as the registrant organization name and use a role name such as “domain contact” or any name that is meaningful to you as the Registrant Name, and you’ll fully comply with the Whois obligation. 

This is a common large enterprise practice, see, for example:

Domain Name: DUPONT.COM
Registrant Name: Domain Name Management
Registrant Organization: E.I. du Pont de Nemours and Company 

Domain Name: CISCO.COM
Registrant Name: Info Sec
Registrant Organization: Cisco Technology Inc.

Domain Name: GRATEFULDEAD.COM
Registrant Name: Rhino Entertainment
Registrant Organization: Rhino Entertainment

Domain Name: BEYONCE.COM
Registrant Name: Domain Administrator
Registrant Organization: BGK Trademark Holdings, LLC 

If it's good enough for Beyoncé, it's probably good enough for you. There's a cost: you'll have to incorporate or file your DBA. There are advantages to filing a DBA and privacy protection is one of them. My experience having once established a small business is that the benefits of filing your DBA are worth the cost.

Your registrant email need not be your personal email

You are obliged to provide a reachable email address so that your registrar can contact you with notices regarding your registration and also for situations where someone must contact you for technical or administrative purposes, however, you do not have to use a personal email address. Instead, use an email address that is separate from your personal email address.  ICANN’s Security and Stability Advisory Committee recommends such measures for security minded organizations and also comments that:

“Individuals or small businesses can implement a similar defensive measure. Create email accounts for points of contact through an email service provider that has earned a positive reputation for managing its mail service.” (SAC 044)

SSAC further recommends that you should use email address named outside your domain name for domain name registration.  For example, if your domain name is marysembroidery.<tld>, you could create a email address at Gmail of the form [email protected]. or [email protected].

Debunking the “but I’ll get lots of spam” myth

I follow the advice I give here. I’ve created an email address for my domain name registrations. I don’t use this email for any purpose not related to my domain name. Below is two years’ correspondence from my In Box of my Gmail account for my domain and I haven’t received spam at this address.

While #YMMV may apply, the evidence I illustrate here is consistent with the findings from an ICANN SSAC study (SAC023) on whether Whois is a source of email address harvesting for spammers.  

You can keep your phone number personal

If you choose to use your home or personal mobile phone number to conduct business, you’ve made a conscious choice to conflate this phone number’s purpose as both personal and business. It is again likely that you’ve published this number on business cards, your web site or in a phone directory. 

You are, however, not obliged to publish your personal phone number. Get a separate phone number for your business use. A Skype Personal Number or business number or a VOIP number from a service like NocTel or Vonage will do nicely  Some small businesses choose to use Google Voice. Your options are simple, abundant and inexpensive.  And so long as you can be reached at this number, you’ve complied with the Whois obligation.

You needn’t provide your home address as a Whois point of contact address

If you choose to publish your home address in any online or printed directory form, or on your web site, then publishing your address in Whois does not expose you to more or different data collection than you’ve already accepted.

You are, again, not obliged to publish your home address or address of any other physical residence. You can rent a postal box and use this, or (better) you can arrange with your attorney, accountant, agent or other party whom you know and trust to use their address as your postal address. I favor this approach because these are parties that you know and trust. As your authorized representatives, they will do as you instruct, consult with you, and comply with legal orders. These services may incur a fee, but while these fees may be higher than a privacy protection service, you know that these parties are very likely to serve you personally and well.

Having to choose is not the same as forcing you to disclose

Claims that ICANN will force you to disclose personal data are patently wrong. You have a choice to disclose personal data or to substitute equally compliant, complete and accurate contact information without revealing personal data when registering a domain name from an ICANN accredited registrar for an ICANN accredited Top Level Domain. There may be fees involved, but it should be increasingly clear today that what is "free" on the Internet often costs you in units of personal data. If you are interested in protecting your personal data, think carefully about protecting your personal data and about the value of separating business from personal identities. As an individual or home/small business operator, assess which arrangements of the kinds I’ve illustrated meet your needs.