Condenaron a un pedófilo argentino por corromper a una nena de 9 años
junio 7, 2013 § 1 comentario
Decía que se llamaba ‘Sole’, que tenía 10 años y su foto de rubia angelical era su tarjeta de presentación en el Messenger y en Facebook. Sin embargo, su verdadera identidad era Leandro Nicolás Fragosa, de 26, vivía en Zárate, y fue condenado a 10 años de prisión por corrupción de menores. La víctima fue una chiquita de 9 años de Necochea, aunque en la computadora del imputado hallaron más de 70 contactos de chicos y cientos de videos perversos: “Se veía a nenes de unos 8 años teniendo sexo con una naturalidad como si tuvieran 30; había violaciones y hasta imágenes con bebés”.
El Tribunal Criminal N°1 de Necochea fue quien ayer condenó a 10 años de prisión a Fragosa por encontrarlo penalmente responsable del delito de “promoción de la corrupción de menor agravada por la edad de la víctima y su comisión mediante engaño”.
El caso de Necochea por el que fue condenado Fragosa –que trabajaba como operario en una automotriz- se inició en 2010, cuando el papá de una nena advirtió el contenido de los mensajes que recibía su hija de ‘Sole’. “Le escribía ‘quisiera hacerte’ tal o cual cosa y ese tal o cual cosa eran cuestiones sexuales. Algo muy grave”, explican desde la Fiscalía General a Clarín.
El papá de la chiquita hizo la denuncia, se ordenó una pericia de la computadora familiar y así se dio con el IP (algo así como DNI de la máquina) del sospechoso. Se descubrió que vivía en Zárate y se ordenó un allanamiento en su vivienda y la compulsa (pericia) de la notebook de Fragosa.
“Hallaron videos de alto contenido sexual: filmaciones de nenes teniendo sexo entre sí, con mayores, de una violación. Algunos eran muy violentos y otros involucraban hasta bebés”, señalan desde el entorno de la fiscal Analía Duarte, quien durante el juicio a Fragosa había reclamado la pena de 13 años por considerar que se trata de un delito de peligro difuso en el que puede haber “infinidad de damnificados y todos son menores”.
Es más, en la computadora del condenado también se encontraron que ‘Sole’ tenía contactos con, al menos, 73 chicos (de varias provincias y de la Capital), más el de la nena por la que se inició la causa. Y que, también, Fragosa participaba de foros de pedófilos.
Y en ese punto, ahora también se lo investiga a Fragosa en la Justicia Nacional –por un requerimiento de Interpol España- por participar en un foro internacional de pedófilos donde se intercambiaban imágenes pornográficas de menores.
En España, el ‘Grooming’ está penado por la ley. ¿Qué es el ‘Grooming’? Se define como las “acciones deliberadas por parte de un adulto de cara a establecer lazos de amistad con un niño o niña en Internet, con el objetivo de obtener una satisfacción sexual mediante imágenes eróticas o pornográficas del menor o incluso como preparación para un encuentro sexual, posiblemente por medio de abusos”.
El ‘Grooming’ tiene varias etapas. Primero, el adulto genera una relación de confianza con el menor. “Por medio de una red social, se hacen pasar por chicos. Después, le sigue la erotización de la relación ya sea diciéndole cosas que le haría o que conoce y la menor engañada no, mandándole fotos o videos”, se explayan en la Fiscalía de Necochea.
Y advierten: “Luego, llega la parte en la que el mayor le pide fotos, diciéndole algo así como ‘mostrame la colita’. Y va subiendo de tono el pedido hasta que llegan al punto de la extorsión para que le envíe fotos más jugadas y, luego, como van cayendo las barreras de inhibición del pedófilo, se pasa de la relación virtual a la real y se da el abuso; y hasta de tráfico de niños y trata”.
Fragosa está con prisión preventiva desde 2012 y, tras la condena, fue derivado al penal de Batán, aunque su abogado defensor ya presentó la reserva para apelar el fallo en Casación.
Fuente: Clarin.com
Cómo hacer para que NIC.AR te entienda
mayo 17, 2013 § 1 comentario
Para muchos de nosotros registrar un dominio no es cosa que sea de todos los días. Registrar un dominio .AR tiene sus particularidades, y son bastante evidentes si uno ha experimentado registrar por ejemplo un dominio .COM.
Hacer los trámites es NIC.AR no es muy problemático (aunque lento en comparación con otros TLD), si uno tiene la suerte de tener todo configurado como NIC.AR espera. ¿Configurado? si, me refiero al correo, porque los trámites se realizan con confirmaciones por correo electrónico.
El sistema de NIC.AR que procesa los trámites funciona con las misma limitaciones y exigencias al menos hace 8 años (quizás más).
Una vez que uno registra la solicitud, recibe un correo con el “formulario” y los datos ingresados más un identificador. Y para confirmar el inicio del trámite uno debe responder ese correo, con los siguientes cuidados:
- formato solo texto (tal como se recibió)
- nada de ese correo puede ser alterado,
- no pueden haber más ni menos lineas,
- ni más ni menos saltos de lineas o espacios,
- ni renglones truncados,
- ningún formateo está permitido.
Hasta aquí parece, relativamente, sencillo. Con un modesto cliente de correo esto se configura fácilmente: correo solo texto/sin formato, y largo de linea 90 caracteres (para que no trunque el formulario). Incluso NIC.AR posee guías de configuración para varios clientes muy usados.
Pero si uno trabaja dentro de una organización es probable que el correo se envíe mediante un servidor propio y que los correos salgan, sin que uno necesite saberlo, codificados con base64. Y eso es algo que NIC.AR no entiende.
Ejemplo 1, aceptable para NIC.AR:
- Abrir el mensaje de asigdom@nic.ar (o de asigdel@nic.ar) titulado “Nueva Registracion …” ó “Registro y Delegacion de ….“.
- Con el correo abierto, ir al Menú “Acciones” -> “Otras Acciones” -> “Codificación” y allí cambiar de “Unicode(UTF-8)” a “Definido por el usuario”.
- Hecho lo anterior, procedo a responder tal como lo indican. (quitar cualquier firma o los encabezados del correo original que incluye el cliente de correo).
Codificación base64
La codificación base64 en los correos electrónicos, es un mecanismo estándar para resolver cuestiones de transferencia de contenidos o archivos entre sistemas de correo. Uno como usuario no se entera ni debe preocuparse de nada de eso. Salvo cuando uno debe responde al sistema de NIC.AR.
NIC.AR en el año 2013 mantiene un sistema de gestión de tramites híbrido, parte web y parte por correo. Siendo el correo algo crucial para la gestión. Sigue así, casi sin cambios, hace muchos años y no se ha modernizado aun hacia una gestión web completa. Lamentablemente sigue con el formato de respuestas por correo donde valida datos como en los inicios de Internet. Pero aun así sigue también sin haberse modernizado y en los correos no entiende la codificación base64, a pesar que esto es algo estándar y normalizado (RFC 4648).
Decodificar base64 es trivial. Esa funcionalidad está disponible gratis para cualquier programador en cualquier lenguaje. Hasta la fecha NIC.AR no ha incorporado ningún mecanismo para decodificar algo tan estándar como el formato MIME “Content-Transfer-Encoding:base64″. (librerías hay para C++, Apache, PHP, Python).
Pero discutir acerca de que NIC.AR decodifique base64 es una discusión atrasada. Hace tiempo pasó su momento; aunque siga presente esa deficiencia.
Lo actual es discutir porque no tienen, hace tiempo, una gestión web ágil. En eso los que sigue retrasando son los sistemas de NIC.AR. Ojalá el hace varios meses anunciado “nuevo sistema” de NIC.AR traiga soluciones a la dificultades actuales.
Raúl de la Redacción de Segu-Info
Conozca el proyecto SIMON
mayo 7, 2013 § Dejar un comentario
Hace años que las limitaciones de infraestructura en las comunicaciones de Latino América son notorias, específicamente en la conectividad entre los países. La aparición de muchos puntos de intercambio de trafico (IXPs) han ayudado para mejorar esta situación pero el real estado de la conectividad entre los países aun es un misterio.
Pensamos que uno de los motivos para estas latencias tan elevadas es la falta de interconexión local entre los distintos proveedores de backbone, o simplemente la falta de infraestructura entre los países.
Esto obliga que el trafico entre países vecinos muchas veces sea intercambiado en USA.
El Proyecto Simon busca generar información para las empresas que están en condiciones de invertir en la región puedan sustentar los planes de negocios para desenvolver internet en la región. Simon se establece como un esfuerzo conjunto, colaborativo y abierto para toda la comunidad, buscando organizar los esfuerzos para conocer la situación actual de la internet regional y apoyar a las empresas que desean participar en solucionar el problema.
Fuente: Portal IPV6 Lacnic
Configuración silenciosa en IPv6 – Ataque al protocolo SLAAC de autoconfiguración de direcciones
abril 29, 2013 § 1 comentario
Aprovechando que el equipo de DARFE (I y II) ha iniciado la publicación de una serie de artículos relacionados con IPv6, hemos pensado en hacer mención a un problema de seguridad inherente a este protocolo.
Pero antes, hay que explicar el por qué de la necesidad de cambiar de protocolo de comunicación. Desde hace un tiempo uno de los recursos más escasos de los que se dispone en Internet es el número de direcciones públicas. Estas, que antes los operadores no tenían problemas en cederte se han convertido en un bien bastante escaso. Tan escaso que, hace unos años alguien dijo que se iban a acabar los 4200 millones de direcciones y que había que diseñar un nuevo protocolo de comunicación. Por esto, a mediados de los 90 se diseña y se crea IPv6 que, entre otras cosas, amplía el número de direcciones un número inagotable, pasando de direcciones de 32 bits a 128 bits.
IPv6 trae nuevos retos de seguridad. Hay que diseñar alguna forma de que IPv6 e IPv4 sean capaces de coexistir y esta tarea no es sencilla porque básicamente son dos protocolos que están diseñados para no entenderse. Para facilitar que IPv6 se fuera integrando en las redes nuevas, se estableció en todos los sistemas operativos actuales una preferencia de IPv6 sobre IPv4, de forma que si un sistema tiene ambos protocolos configurados, se utilice preferentemente IPv6. Además todos los sistemas operativos habituales modernos traen la pila de IPv6 activada y a la espera de ser configurada.
De este despliegue de doble pila IPv4-IPv6 surge un vector de ataque característico de este protocolo, la configuración silenciosa de IPv6. En ella, de aprovechan las capacidades de IPv6 de configurarse de forma sencilla mediante el protocolo SLAAC para “secuestrar” las comunicaciones de los equipos afectados.
El proceso se basa en el envío fraudulento de mensajes ICMPv6 al destino. Por necesidades de diseño el protocolo ICMPv6 no puede ser descartado en su totalidad en los equipos de seguridad perimetral, ya que es un protocolo necesario para las comunicaciones IPv6 al permitir determinar la MTU máxima de la comunicación. Debe permitirse el paso de determinados mensajes ICMPv6 si se utiliza IPv6, pero hay que filtrar aquellos mensajes que puedan ser dañinos.
Los mensajes de Router Advertisment (RA) que provienen de fuera de la red suponen un peligro para la arquitectura de la misma. Este tipo de mensajes, diseñados para facilitar el despliegue y la configuración de IPv6 contienen información de conexión, con parámetros tales como la puerta de enlace o el prefijo, por lo que un equipo que no tenga configurada la pila de IPv6 la configurará con esta información fraudulenta, pudiendo el atacante establecer la puerta de enlace para todas las comunicaciones. Las siguientes imágenes, obtenidas de Infosec institute 
ilustran el proceso:
El atacante ha conseguido enviar mensajes de RA a los equipos de la red, que configuran sus pilas IPv6 con los datos que les han enviado. La preferencia de IPv6 sobre IPv4 hace el resto, y los equipos pasan a utilizar los recursos proporcionados por el atacante.
Este ataque es posible de mitigar mediante la incorporación de un cortafuegos con capacidades IPv6 en el perímetro y mediante el control de los mensajes ICMPv6 que circulan dentro de la organización en los cortafuegos que delimitan las zonas de la red de la organización.
Si esta no utiliza IPv6 se podrá descartar todos los mensajes ICMPv6 entrantes e informar a los operadores de red de la presencia de dicho tipo de mensajes. También se puede mitigar si se deshabilita la opción de configuración mediante SLAAC y se utiliza para la asignación de direcciones otros métodos tales como DHCPv6.
Fuente: INTECO-CERT
Direccionamiento en IPv6 (segunda parte)
abril 23, 2013 § Dejar un comentario
El objetivo de esta serie (primera parte) es despertar el interés dentro del mundo hispano, sobre este nuevo desafío que nos pone por delante Internet, para poder conocer en detalle su funcionamiento y poder estar en primera línea en el momento en que esté implantado definitivamente en la red.
En este caso Alejandro Corletti, el autor de la serie, acaba de publicar el segundo artículo de esta serie IP versión 6 – Direccionamiento. El documento es de libre difusión, descarga y empleo en el ámbito docente (sin fines de lucro).
Cristian de la redacción de Segu-Info
DNSSEC, securizando las comunicaciones en la web (II)
abril 17, 2013 § Dejar un comentario
¿Por qué implementar DNSSEC?
En la primera parte se vió que el protocolo DNS adolece de algunas debilidades estructurales que lo hacen vulnerable a ciertos tipos de ataques y por eso se debió definir las extensiones de DNSSEC que permiten solventar estas debilidades sin forzar a un reemplazo inmediato de todos los servidores DNS existentes. El despliegue de DNSSEC es gradual a medida que los diferentes operadores van firmando zonas.
¿En qué consiste la firma de zonas?
Se genera un par de claves (pública y su correspondiente privada) para cada zona:
- El par de claves es propio de cada zona y no del servidor autoritativo.
- La parte privada se debe mantener bajo custodia:
- La privada firma los RRSets de la zona.
- La pública se debe publicar en DNS mediante un registro DNSKEY:
- La privada permite verificar las firmas de los RRSets.
- Un RRSet puede tener múltiples firmas generadas con diferentes claves.
La firma digital de un RRSet se devuelve en forma de un registro RRSIG que es parte de la respuesta. Por ejemplo:
¿Como puede un cliente verificar un RRSet de una cierta zona?
La manera de realizarlo es haciendo una consulta por el DNSKEY correspondiente o realizando los cálculos correspondientes y comparar con el RRSIG. Si coinciden la firma verifica, de lo contrario, no
Pero para confiar en la DNSKEY que sale de la misma zona que queremos verificar necesitamos verificar la cadena de confianza. Para ello con el registro DS “Delegation Signature”:
- Los registros DS “firman” claves de zonas hijas
- De esta forma uno puede verificar el DNSKEY de una zona buscando un registro DS en la zona padre
El registro DS contiene un hash de una clave pública, del contenido de un registro DNSKEY. Los registros DS en la zona padre están firmados con la(s) claves de esa zona y para completar la cadena de confianza tiene que estar firmada la raíz del DNS.
Por otra parte, la zona raíz no tiene “padre” a quien ir a pedirle un registro DS.
¿Cómo se verifica la autenticidad del root Trust-Anchor (TA)?
El TA de la zona raíz se publica fuera de banda, por ello la validación debe ser diferente:
- Se puede bajar por HTTP/HTTPS
- Se puede verificar por otros mecanismos (certificados, firmas PGP)
- Similar a lo que pasa con la zona raíz misma, se debe cargar manualmente
¿Qué necesito para firmar mis zonas?
Se necesita trabajar en dos niveles:
- Instalar y operar software que soporte el firmado de zonas.
- Definir los procedimientos y políticas de gestión y, manejo de claves y firmas.
A nivel de software podemos nombrar los siguientes productos:
- BIND
- OpenDNSSEC
- Otros…
Cadena de confianza
Los datos de una zona serán confiables si:
- Se encuentran firmados por la llave de la zona zone-signing-key (zsk), mediante los respectivos RRs RRSIG.
- La zone-signing-key de la zona será confiable si está firmada por la llave key-signing-key (ksk), ambos RRs DNSKEY.
- La key-signing-key será confiable si está siendo apuntado por su respectivo RR DS del padre.
El RR DS será confiable si:
- Está firmado por la zone-signing-key del padre, o;
- Los records DS o DNSKEY fueron intercambiados fuera de banda y almacenados localmente (“Secure entry point”).
¿Qué necesito para validar respuestas DNS?
A nivel de servidores DNS recursivos es posible validar respuestas de DNS de inmediato. Para lograrlo, se deben seguir los pasos especificados por el fabricante del software.
Por ejemplo:
BIND 9.7 y superior:
- https://dnssec.surfnet.nl/?p=402
- http://www.isc.org/community/blog/201007/using-root-dnssec-key-bind-9-resolvers
- Unbound: https://dnssec.surfnet.nl/?p=212
DNSSEC vs. PKI
DNSSEC no implementa una PKI sobre DNS aunque se parecen.
Los procedimientos de gestión de claves están basados en políticas locales y no hay “certificate authority”. Además, si todo un dominio y subdominios están bajo una administración única, entonces se puede aplicar más estrictamente un conjunto de políticas. Además, no hay CRL (“Certificate Revocation List”).
Procedimiento básico de firma de zona
Generación de un par de claves
- Incluir el DNSKEY creado en la zona
- Si lo hacemos con BIND esto dispara:
- El ordenamiento de la zona
- Inserción de los registros RRSIG
- Generación de registros DS:
- Recordar que van en el padre
El Rol de Google en la implementación de DNSSEC
Google ha lanzado hace tres años Google Public DNS al igual que OpenDNS, para ayudar a hacer Internet más rápido y seguro. Actualmente, están avanzando con el proyecto para hacer la validación de los DNS resolvers totalmente compatible con DNSSEC . Anteriormente, se han aceptado y se ha enviado mensajes con DNSSEC, pero no validaba. Con esta nueva característica de seguridad, se puede proteger a las personas de los ataques, identificando y rechazando las respuestas no válidas de DNSSEC.
Para contrarrestar los ataques de envenenamiento de caché, resolvers debe ser capaz de verificar la autenticidad de la respuesta. DNSSEC resuelve el problema mediante la autenticación de las respuestas DNS que utilizan las firmas digitales y la criptografía de clave pública. Cada zona DNS mantiene un conjunto de pares de claves públicas / privadas, y para cada registro de DNS, una firma digital única se genera y se cifra con la clave privada. La clave pública correspondiente se verifica a través de una cadena de confianza con las teclas de las zonas de nivel superior. DNSSEC previene eficazmente la respuesta de manipulación porque en la práctica, las firmas son casi imposible de falsificar sin acceso a las claves privadas. Además, los dispositivos de resolución rechazará las respuestas correctas sin firmas.
Actualmente Google Public DNS está atendiendo, en promedio, más de 130 mil millones de consultas DNS de más de 70 millones de direcciones IP cada día. Sin embargo, sólo el 7% de las consultas client-side se realizan con DNSSEC habilitado y el 1% de las respuestas DNS del server-side están firmadas. En general, DNSSEC se encuentra todavía en una fase inicial y se espera que con este apoyo se acelere la implementación.
Para obtener más información acerca de Google Public DNS, siga el siguiente enlace: https://developers.google.com/speed/public-dns.
¿Dónde obtengo información sobre DNSSEC?
Existe gran cantidad de información disponible sobre DNSSEC. Algunos de ellos son:
- Introducción a DNSSEC (LACNIC Labs, en español y en inglés).
- Tutoriales de Registro.BR (en portugués).
- DNSSEC HOWTO (en inglés).
Además, hay disponible públicamente material del entrenamiento sobre DNSSEC brindado en Febrero de 2012 por Olaf Kolkman de los laboratorios de NLnet.
Video: Cómo funciona DNSSEC
Fuentes:
- SecurityWeek
- Lacnic
- http://www.labs.lacnic.net/site/sites/default/files/dnssec-citel-generalidades-ES-01.pdf
Mauro D. Gioino de la Redacción de Segu-Info
DNSSEC, securizando las comunicaciones en la web (I)
abril 16, 2013 § 1 comentario
Introducción a DNS
El protocolo DNS fue definido originalmente en 1983 (RFC 882 y 883) y desde entonces no ha sufrido grandes cambios. Las nuevas funcionalidades han venidas asociadas a extensiones y nuevos tipos de registros. Dicho protocolo consiste básicamente en traducir un nombre de dominio como ser: http://www.segu-info.com.ar a una dirección IP. A su vez, esa IP permite al equipo buscar el sitio web.
Vulnerabilidades del protocolo DNS
La información transmitida en DNS puede ser “spoofed”:
- Entre maestro y esclavo (AXFR).
- Entre maestro y sus clientes “resolver”.
Actualmente el protocolo DNS no permite validar la información contenida en una respuesta:
- Vulnerable a las diferentes técnicas de poisoning.
- Datos envenenados siguen causando problemas por un tiempo (potencialmente grande, TTL).
Tampoco los secundarios tienen manera de autenticar al primario con el que están hablando.
¿Qué es DNSSEC?
DNSSEC (DNS Security Extensions) es un conjunto de extensiones al protocolo DNS que permiten validar criptográficamente que las respuestas que envían los servidores DNS sean reales, las que dicen ser. El mismo nace oficialmente en 2005 (ya que venía siendo tratado en el IETF) con las especificaciones en los RFC 4033, 4034, 4035. DNSSEC no es un nuevo protocolo. Algunos de los cambios que implementa son:
- Cambios en el “wire protocol” (EDNS0)
- Extensión del tamaño máximo de una respuesta UDP de 512 a 4096 bytes
- Agregado de nuevos resource records
- RRSIG, DNSKEY, DS, NSEC
- Agregado de nuevos flags
- Checking Disabled (CD)
- Authenticated Data (AD)
Los nuevos RR que implementa son:
- RRSIG: Resource Record Signature
- DNSKEY: DNS Public Key
- S: Delegation Signer
- NSEC: Next Secure
Y los nuevos Flags que se añaden son:
- AD: que indica que la respuesta está autenticada.
- CD: indica que no se realiza chequeo (deshabilitado).
Un Resource Record en DNS es una tupla de cinco valores:
- Nombre
- Clase
- Tipo
- TTL
- Valor
Donde por ejemplo: http://www.empresa.com. 86400 IN A 200.40.100.141, tiene que:
- Nombre (www.empresa.com)
- Clase (IN)
- Tipo (A)
- TTL (86400 segundos)
- Valor (200.40.100.141)
Como contrapartida DNSSEC opera firmando RRSets (no RR individuales). Un RRSet es un conjunto de resource records que comparten igual:
- Clase
- Tipo
- Nombre
Ejemplos de RRSet con TTL omitido:
- www IN A 200.40.241.100
- www IN A 200.40.241.101
Alcance de DNSSEC
El alcance de las extensiones de seguridad a DNS pueden resumirse en tres servicios:
- Distribución de llaves (key distribution): El servicio de distribución de llaves no sólo permite la recuperación de una llave pública de un nombre DNS para verificar la autenticidad de los datos de una zona DNS, sino que también proporciona un mecanismo mediante el cual cualquier llave asociada a un nombre DNS puede ser usada para otros propósitos. El servicio de distribución de llave pública soporta diferentes tipos de llaves y de algoritmos de encriptación.
- Autenticación del origen de los datos (Data Origin Authentication): Este servicio es el punto crucial en el diseño de DNSSEC. Mitiga amenazas tales como envenenamiento de caché y compromiso de los datos de una zona en un servidor DNS. Los RRSets dentro de una zona son firmados criptográficamente, dando así un alto nivel de certeza de que los datos recibidos por resolvers y servidores pueden ser confiables. DNSSEC utiliza firmas digitales para firmar los RRSets dentro de DNS. Dicha firma digital contiene un valor hash cifrado del RRSet, el cual es una suma de control criptográfica de los datos contenidos en el mismo. Este hash es firmado (digitalmente encriptado) mediante una clave privada, generalmente perteneciente al dueño de la información, conocido como signer (o signing authority). El receptor del RRSet puede simplemente chequear la firma digital contra los datos en el RRSet, primero desencriptando la firma digital (RRSIG) utilizando la llave pública del signer para obtener el hash original de los datos, y luego computando su propio hash de los datos en el RRSet utilizando el mismo algoritmo de suma de control criptográfica De esta manera puede comparar los resultados del hash encontrado en la firma digital contra el hash recién computado. Si los dos valores hash coinciden, existe integridad en los datos y el origen de datos es auténtico.
- Autenticación de transacciones y pedidos (DNS Transaction and Request Authentication): Permite autenticar pedidos y cabeceras de mensajes DNS. Esto garantiza que una respuesta sea verdaderamente en respuesta a una consulta realizada, y que dicha respuesta proviene efectivamente desde el servidor al cual estaba destinada la consulta. Proporcionar la seguridad para ambos se hace en un solo paso, parte de la información regresada desde un servidor seguro es una firma, dicha firma es producida por la concatenación de la consulta y su respectiva respuesta. Esto permite a un resolver seguro, realizar cualquier verificación concerniente a la transacción realizada. Esta autenticación también se utiliza en las actualizaciones dinámicas de DNS. Sin DNSSEC, las actualizaciones dinámicas no proveen ningún mecanismo que prohíba, a cualquier sistema que tenga acceso a un servidor autoritativo DNS, la actualización de información de su zona. Para proveer seguridad para estas modificaciones se incorpora DNSSEC para brindar una autentificación fuerte a sistemas habilitados a manipular dinámicamente información de zonas DNS en el servidor primario.
Protección proporcionada
DNSSEC nos protegerá de corrupción y del spoofing de datos:
- Proporciona un mecanismo para poder validar la autenticidad y la integridad de los datos contenidos en una zona DNS
- DNSKEY/RRSIG/NSEC
- Proporciona un mecanismo para delegar la confianza en ciertas claves públicas (cadena de confianza)
- DS
- Proporciona un mecanismo para autenticar las transferencias de zona entre primarios y secundarios
- TSIG
Mauro D. Gioino de la Redacción de Segu-Info
Componentes de IPv6 (primera parte)
abril 11, 2013 § 1 comentario
Una vez más, nos hacemos eco de la nueva serie de artículos que nos llegan de la mano de nuestro amigo Alejandro Corletti. En este caso orientada a un protocolo tan fundamental como IPv6.
Tal y como nos informa Alejandro:
Estoy comenzando una serie de artículos sobre IP versión 6 que serán eminentemente técnicos. En este mail os adjunto el primero de ellos “IPv6 (Parte 01) – Componentes” , en el que comenzamos esta serie describiendo el conjunto de protocolos que van asociados (tanto por modificaciones como por ser nuevos) a esta nueva versión de IP.El objetivo de esta serie será despertar el interés dentro del mundo hispano, sobre este nuevo desafío que nos pone por delante Internet, para poder conocer en detalle su funcionamiento y poder estar en primera línea en el momento en que esté implantado definitivamente en la red, cosa que no nos sucedió (al mundo hispanohablante) con IPv4 y nos subimos al carro cuando ya estaba demasiado rodado. Tengo toda la FE en que esta vez podamos ser parte de la vanguardia tecnológica, y sinceramente podemos lograrlo si ponemos voluntad y esfuerzo, esta vez no es cuestión de dinero o inversiones, sino de “Ponernos las pilas a tiempo”.
Por esta razón es que os hago llegar este primer artículo por si os interesa; si deseáis difundirlo es para su libre difusión, descarga y empleo en el ámbito docente (sin fines de lucro).
Fuente: Daboweb
Argentina: el 23,4% de los adolescentes fue perjudicado alguna vez
abril 3, 2013 § Dejar un comentario
El Inadi (Instituto Nacional contra la Discriminación, el Racismo y la Xenofobia) realizó un relevamiento sobre el uso que dan los adolescentes de las redes sociales y cuáles son los riesgos más comunes a los que se enfrentan. A partir de esos datos realizaron un documento con recomendaciones que, hace unos días, la delegación local entregó a referentes de los gremios docentes de la provincia.
“Es una publicación que busca dar masivamente herramientas a adultos para que niñas, niños y adolescentes disfruten de las redes sociales sin riesgos ni discriminación”, manifestó en diálogo con Diario UNO, Stella Vallejos, delegada del Inadi Santa Fe. Y agregó: “Para elaborarlo previamente se hizo una investigación que arrojó importantes datos”.
En ese sentido, destacó que el 64,4 % de adolescentes entre 13 y 17 años navega sin la compañía de un adulto. Y que el 23,4 % fue perjudicado al menos una vez, mientras que el 15,9 % perjudicó al menos una vez a alguien mientras utilizaba esa herramienta. Al respecto, añadieron que el 88,8 % de los jóvenes utiliza Facebook, la más elegida.
Ante la pregunta del uso de las redes sociales las respuestas espontáneas fueron que el 69,7 % opta por contactarse con amigos; el 39,9 % quiere divertirse; el 27,1 %, hacer nuevos amigos; el 25,5 %, compartir momentos; el 16,4 %, encontrar información; y el 9,7 % quiere “compartir cosas que nos pasan”.
Por otro lado, se evidenció que la mitad de los encuestados conoció a, por lo menos, una persona en internet; y que seis de cada 10 de ellos se han visto personalmente.
-¿Por qué considera que es importante que el Inadi se involucre en esta problemática?
-Nuestro organismo trabaja en prevención de conductas sociales discriminatorias y en actos discriminatorios, las redes hoy son un sitio de contactos masivo en el que resulta valiosa la observación y la incidencia, tanto como lo hacemos en los diferentes ámbitos donde las personas desarrollan sus relaciones interpersonales. Si analizamos la encuesta observamos la cantidad de adolescentes que utilizan el Facebook por lo que se hace necesario nuestra intervención no para demonizar internet sino para que los usuarios la disfruten sin riesgos, sobre todo esa franja etaria que por las características que les son propias a su edad son vulnerables.
- Algunos especialistas en bullying señalan que el uso de las tecnologías acrecienta el problema porque le da masividad ¿Coincide con esa apreciación?
-Por supuesto que la masividad acrecienta el sufrimiento de la persona víctima de bullying, lo que antes se circunscribía en el aula hoy se masifica y en algunos casos de viraliza. Por otro lado, éste es un ámbito aún sin legislar, hemos acompañado el caso de una adolescente que mediante la intervención de un juez se logró eliminar de la red la discriminación de la que fue víctima, en este caso hubo un fuerte compromiso de la familia y la escuela que conoció la situación y la abordó con firmeza, en otros casos, la familia no recibe el acompañamiento de la escuela (la institución argumenta que sucede “fuera” de la institución) y otros a lo mejor suceden y los adultos no nos enteramos.
Un diagnóstico
-¿Cuáles son las situaciones de discriminación más habituales que detectan en las redes sociales?
-Las situaciones de discriminación que suceden en la red son las mismas que suceden en otros ámbitos, manifestándose principalmente a través del acoso o exclusión de personas debido a su pertenencia, real o percibida, a determinado grupo históricamente discriminatorio. Toda distinción, restricción o preferencia basada en motivos de una supuesta raza, religión, nacionalidad, ideología, opinión política o gremial, género, orientación sexual, identidad sexual, posición económica, condición social o aspecto físico que tenga por objeto anular o menoscabar el reconocimiento y ejercicio en condiciones de igualdad, de los Derechos Humanos y libertades fundamentales es considerada una acción discriminatoria.
-¿De qué manera se puede trabajar en la escuela para prevenir o detener ese problema?
-Las niñas, niños y adolescentes son nativos digitales (nacen y crecen con la red) a diferencia de las personas adultas que debemos aprender a usarla, esto genera una brecha generacional, que debemos afrontar, entre otras estrategias dialogando, observando cambios conductuales, y acompañando en la medida de lo posible. Explicarles en que consiste la privacidad. La importancia de proteger sus datos personales, deben recordar que detrás de un nick o perfil hay una persona que merece ser respetada. Asimismo hacerse respetar cuando se sientan incómodos y que lo compartan con algún adulto de su confianza.
Por último, Vallejos reflexionó: “Hoy internet se presenta como una gran posibilidad para la inclusión sin discriminación, la democratización y la promoción de la diversidad en el espacio virtual posibilita sociedades más democráticas, diversas y plurales”.
Fuente: Uno
Los ataques DDoS de amplificación DNS son de este siglo
abril 1, 2013 § Dejar un comentario
Ahora que esta semana está tan de moda el uso de ataques de amplificación utilizando servidores DNS, es importante comentar el porqué ahora es posible, cuando antes era imposible de realizar técnicamente.
Me acuerdo cuando hace muchos años estudiaba el protocolo DNS, siempre se hacía hincapié en que si la respuesta era mayor de 512 bytes, siempre se utilizaba TCP para la misma (independientemente de que si la pregunta había sido realizada con UDP, puesto que nos obliga a volver a formular la pregunta usando TCP). En esa época (a finales de los 90) era así. Pero en agosto de 1999 se propuso la RFC 2671 que pretendía añadir más funcionalidades al protocolo DNS, que no olvidemos que la RFC 1035 del DNS actual se publicó en 1987, o que el sistema de dominios se publicó en 1983 en la RFC 882.
Poco a poco se quería añadir más información en los paquetes DNS (por ejemplo debido a DNSSEC), pero no había espacio para ello; existen 7 flags en la cabecera de un paquete DNS, pero de 1987 a 1999 se vió que se necesitaban más. Además, la limitación de un paquete máximo de 512 bytes tenía sentido en la época, debido a la conectividad que había existente en los años 80, pero que hoy en día no tiene mucho sentido. El problema que tenían es el que hemos visto que ha sido el detonante de muchos problemas de seguridad actuales: todo tendría que ser compatible con lo que hubiera en ese momento. Por ello, en la RFC 2671 hicieron un parche al protocolo y se permitió añadir otros parámetros en los registros adicionales de un paquete DNS (de tal forma que si el servidor soportaba estos nuevos parámetros los aplicaría, y sino los ignoraría): había nacido EDNS0 (Extension Mechanisms for DNS, versión 0).
Contenido completo en fuente original LostInSecurity
