Switzerland (Suiza en inglés) hace el honor al país neutral por antonomasia, y simula el funcionamiento de un programa de intercambio de archivos P2P para analizar los cambios que sufren los paquetes de datos al pasar entre las redes de los ISPs. Por si no estan al tanto les recordamos que suciea lanzo una ley que permite a un organismo estatal espiar todas las conexiones de la red. Leer mas en Ley FRA

COMCAST, y el bloqueo del tráfico P2P siguen dando mucho de qué hablar, y es por ello que un grupo de desarrolladores, tiene en fase Alpha, es decir muy poco estable y susceptible a errores, un programa que han llamado Switzerland. El objetivo del mismo es verificar si nuestro ISP intercepta los paquetes y los modifica. ADSL Net lo ha probado, y por cierto hemos sudado para encontrar una plataforma donde hacerlo funcionar, pero lo tenemos y os lo contamos.

Lo primero que necesitamos es la versión actual de Switzerland. Lo podemos descargar desde la página oficial que de momento se encuentra en SourceForge.

Descargar Switzerland

Lo segundo y lo más importante quizás es, ¿ qué necesitamos para hacerlo funcionar ?

Nosotros hemos optado por Linux, dado que la herramienta ha sido desarrollado y orientada principalmente a funcionar bajo linux y en esta fase tan prealpha la cosa resulta compleja para hacerla funcionar en Windows si no se hacen modificaciones.

La versión viene lista para funcionar en Python 2.5, y la última release estable disponible de Python es la 2.5.2. Por ese lado no encontraremos problemas, pero nosotros sí lo hemos encontrado intentándo hacerlo funcionar debido a que hay problemas con el tamaño de la ventana TCP de los paquetes cuando los interfaces son Ethernet Gigabit.

Tempfile: /tmp/tmpWYvNNa
Initialized sniff on eth0
pcap_datalink: 1
ERROR: Cannot handle a packet of size 2814

(Check for Large Segment Offloading on gigabit Ethernet cards, and avoid loopback devices)

Esto nos ha obligado a utilizar versiones antiguas de sistemas operativos, descartando los servidores más potentes con el software más actualizado, dado que disponen de tarjetas Ethernet Gigabit.

Nos hemos ido entonces a Fedora Core 5, en unas máquinas de pruebas donde los interfaces activados eran Ethernet 100 Mbps. Sin embargo la versión de Python disponible en este caso era la 2.4.

Si la versión de Python era inferior a la 2.4 a la hora de ejecutar la instalación obteníamos lo siguiente:

[root@spider switzerland-0.0.5]# python setup.py install
Traceback (most recent call last):
File “setup.py”, line 7, in ?
import platform
ImportError: No module named platform

Hemos intentado realizar la compilación e instalación por tanto con Python 2.4, y esta ha funcionado así que lo que hemos hecho posteriormente ha sido editar de forma manual los scripts switzerland-client y switzerland-server para que buscase la variable de entorno python 2.4 en vez de python 2.5 y la cosa ha funcionado.

[root@dev1 switzerland-0.0.5]# vi switzerland-client

#!/usr/bin/env python2.4

try:
from switzerland.client import Alice
except ImportError:
import sys
sys.path.append(”/usr/local/lib/python2.5/site-packages/”)
sys.path.append(”/usr/lib/python2.5/site-packages/”)
sys.path.append(”.”)
from switzerland.client import Alice

Alice.main()

Todo bien hasta aquí pero en qué consiste Switzerland y cómo funciona. Básicamente el objetivo de la aplicación es funcionar con dos partes, una cliente y otra servidor. La parte servidor recoge los paquetes enviados por los clientes y pone al interfaz de red del sistema en modo escucha, para interceptar el tráfico del mismo. Cuando se detectan paquetes Peer To Peer, se analiza el emisor y se comprueba si el paquete que se originó ha sido modificado a su recepción en el servidor, indicando que en el trayecto intermedio, es decir la propia infraestructura del ISP, se ha alterado su contenido, pudiendo provocar, cortes, desconexiones, o filtrados del tráfico.

Para esta versión Alpha los desarrolladores han puesto un servidor en una dirección que se indica en el fichero de instalación, de tal forma que si no se dispone de un servidor o de suficientes máquinas como para montarlo, se pueda realizar la prueba contra él.

A nosotros el servidor no nos ha funcionado y hemos optado por realizar la instalación del servidor en una máquina Linux con Fedora Core 5 y python 2.4 y el cliente en otra máquina Linux con Fedora Core 5 y python 2.4, ambas con interfaces de Red Ethernet de 100 Mbps.

Otro de los problemas que hemos determinado, es que Switzerland intenta controlar la organización de los paquetes Peer to Peer mediante el control del tiempo, vía servicio NTP. El servicio NTP es aquel que nos permite mantener sincronizado nuestro reloj del sistema mediante el acceso a un servidor que le ofrece a nuestro sistema la hora. Sin embargo parece que las versiones antiguas contra las que Switzerland debe comprobar si nuestro sistema está actualizado o no, no funcionan del todo muy bien, así que mediante la opción del parámetro -u 0 desactivamos la utilización de NTP en el control de los paquetes.

La ejecución de nuestro cliente produce por tanto lo siguiente en la línea de comandos de nuestro CLIENTE Switzerland en Linux:

[root@dev1 switzerland-0.0.5]# ./switzerland-client -s 10.43.99.4 -u 0
No scapy… that’s okay, we don’t really need it
——————————————————————————–
Welcome to Switzerland. This is a Version Zero alpha release. It’s sure to
break at some point. If/when that happens, please let us know by email
(switzerland-devel@eff.org), IRC (#switzerland on irc.oftc.net) or bug report
( https://sourceforge.net/tracker/?func=browse&group_id=233013&atid=1088569 )
——————————————————————————–
interface is now eth0
Logging events to /var/log/switzerland-client.log
Looking for ntpd…
ntpdc: read: Connection refused
ntpdc is present but ntpd does not appear to be alive: (”[]”)
but allow_uncertain_time is set so we’re defaulting the clock error to 0.000000
Connecting to 10.43.99.4:7778
Private IP: ‘10.43.99.20? ; Public IP: ‘10.43.99.20?
The psyco package is unavailable…
Listening for traffic with peers

Y a continuación podemos ver los datos en el servidor:

[root@moo2 switzerland-0.0.5]# ./switzerland-server
psyco not available — the server will be more efficient if psyco is installed
SwitzMas: Server listening for connections on port 7778…
got a connection from 10.43.99.20 44797
SwitzMas: peers: {’10.43.99.20?: {44797: <SwitzerlandLink(Thread-2, initial daemon)>}}
SwitzMas: Initialising server thread
Switz-2s: attempting handshake with (’10.43.99.20?, 44797)
Switz-2s: completed handshake with (’10.43.99.20?, 44797)
Switz-2s: Sending [’public-ip’, 0, ‘10.43.99.20?]
Switz-2s: Sending [’new-members’, 0, []]
SwitzMas: Joining circle, notifying 0 others
(’10.43.99.20?, 44797) is running on (’Linux’, ‘2.6.11-1.1369_FC4smp’, ‘i686?, (2, 4, 1, ‘final’, 0))
Switz-2s: Received ack for 0

CURRENT FLOW TABLE: okay drop mod/frg pend t/rx prot

CURRENT FLOW TABLE: okay drop mod/frg pend t/rx prot

CURRENT FLOW TABLE: okay drop mod/frg pend t/rx prot

Durante la ejecución, el servidor va notificando la producción de eventos en las conexiones Peer To Peer y determina si en la actual tabla de flujo de datos se producen eventos inexperados.

Todo esto además queda registrado en los logs que Switzerland crea. Que por cierto hay que tener en cuenta que es necesario de forma manual crear el directorio para alojar los logs y darle permisos de escritura, o bien ignorarlos con el parámetro: -P- para que no se creen.

[root@file1 switzerland-0.0.5]# mkdir /var/log/switzerland-pcaps
[root@file1 switzerland-0.0.5]# chmod 777 /var/log/switzerland-pcaps

Switzerland está aún como decíamos en una fase Alpha de desarrollo, por lo tanto aún le queda bastante, pero el concepto de análisis y auditoría es sencillo, así que desde ADSL Net no descartamos la posibilidad de desarrollar un piloto gráfico que se incluya en ANT en próximas releases.

Os mantendremos informados.

Por cierto!!!, nuestras infraestructura de pruebas, no se ha visto afectada, y para la prueba se han utilizado hasta 4 operadores. Telefónica, Colt, Vodafone 3G y British Telecom

Via www.adslnet.es


Japón está intentando capar el trafico p2p limitando en cierta medida las velocidades de las redes para desincentivar la pirateria.

Como medida decidieron reducir las velocidades de subida. El razonamiento es el siguiente: si no hay nadie que suba los archivos a las redes p2p, nadie va a poder descargarlos.

En Japón las velocidades de conexión son infinitamente superiores y por eso nosotros ciertamente no podemos apreciar las cantidades de Mbps en comparación con las nuestras. El promedio en Japón de una línea de ADSL supera 20 veces más el promedio de España, por lo que pueden subir  archivos a las redes p2p 20 veces más rapido.

El límite sera de 30Gb diarios, lo que limitaria en japon la subida de archivos en 2hs suponiendo que se utiliza todo el ancho de banda de subida ininterrumpidamenteo. En España con un adsl normal que tenga una capacidad de subida de unos 800Kpbs para alcanzar el limite habria que tener un ordenador ininterrumpidamente durante unas 12 horas al día subiendo achivos.

Según un artículo publicado en The Register, la compañía de Internet proporcionará a los usuarios las herramientas necesarias para saber en todo momento lo que acontece en su línea ADSL, evitando así que los proveedores de acceso a Internet, o ISPs, discriminen el contenido o aplicacones que pasan por la red.

Hace unos meses los usuarios de Estados Unidos se despertaron con la noticia de que la operadora Comcast interfería en la transferencia de archivos de las redes peer-to-peer, incluso si el archivo era pequeño. Aunque las operadoras españolas han negado estas prácticas, en nuestro país han corrido rumones similares sin que haya sido posible comprobarlo, algo que las nuevas herramientas de Google podrían hacer.

Richard Whitt, ejecutivo de Google afirmó durante una conferencia que “si los operadores de banda ancha no le dicen al usuario exactamente qué está pasando en sus redes, queremos darles a los usuarios la posibilidad de descubrirlo ellos mismos”.

Por el momento Whitt no ha puesto fecha a la disponibilidad de las herramientas ni ha ofrecido detalles sonbre cómo funcionarán.

Via www.vnunet.es/es

Las principales operadoras de cable estadounidenses, Comcast y Time Warner Cable, comenzarán esta semana las pruebas para introducir límites a los clientes particulares que consumen más ancho de banda en Internet, en un esfuerzo por proteger sus redes de alta velocidad. Procedimiento al que denominan “priorización“.

Las operadoras justifican estas medidas a las grandes inversiones que se ven obligadas a realizar para mejorar su infraestructura y ofrecer el ancho de banda cada vez necesario para responder a la explosión de las descargas de contenidos, tanto de música como de películas y vídeos.

Según un portavoz de Time Warner Cable el canon cobrado por el ancho de banda exedente consumido sera destinado a la inversion en infraestructura para mejorar el servicio. “Para hacer inversiones en la infraestructura, tenemos que encontrar los ingresos para pagarla”. Claro esta del dicho al hecho… hay un largo trecho, en Argentina ya tenemos bastante de esto sino pongan en google “decada del 90″.

Time Warner Cable ha anunciado que el jueves iniciará un sistema que cobra a los nuevos clientes de Internet de alta velocidad en función de su uso. Los clientes de banda ancha de Beaumont, Texas, pagarán un dólar por gigabite además de la cuota mensual, indicó un portavoz de la compañía.

Comcast ha anunciado un cambio en su forma de gestionar el tráfico, comenzando por una prueba para reducir la transferencia de archivos a los particulares que consuman más recursos en periodos de congestión del tráfico.

Las “pruebas” comenzarán el jueves en las zonas de Chambersburg, en Pensilvania, y Warrenton, en Virginia.

La nueva política de Time Warner se dirige al 5% de usuarios que suponen requieren más recursos, y que según dijo el portavoz, han pasado una cantidad de tiempo “desproporcionada” en la red de la empresa.

Las redes de intercambio P2P serán las más perjudicadas

El origen de esta polémica medida se remonta a enero cuando la Comisión Federal de Comunicaciones afirmó que investigaría las quejas de los grupos de consumidores que aseguraban que Comcast estaba bloqueando servicios de intercambio de archivos como BitTorrent.

Comcast dijo entonces que no bloqueaba este tipo de servicios, sino que utilizaba tecnología de gestión de redes para retrasar la transferencia de archivos a los mayores usuarios de estos servicios.

Este modelo podría adoptarse en España donde la velocidad comenzará a multiplicarse en los próximos años. Precisamente, la mayoría de las quejas de los internautas españoles en este sentido tienen que ver con los operadores de cable Ono y Telecable que son los que peor rendimiento ofrecen con los programas de intercambio p2p.


3601396memoria total
Memoria usada: 3517 KB de 3840 KB
16 queries.
0.513 seconds.