#6 Por fin nos Hacercamos a...
Joder, es que no puedo seguir. Qué dolor de ojos
Activistas de redes libres en vias de fabricar su propio Libre-Router
guifi.netEn respuesta a las nuevas restricciones impulsadas por la agencia estatal de Estados Unidos FCC que impide a los usuarios instalar sistemas operativos libres como OpenWRT o LEDE en los routers WiFi. Un grupo de activistas situados alrededor del proyecto LibreMesh estan en vias de fabricar su propio router: LibreRouter. Este tiene como objetivo servir a las necesidades de las redes autogestionadas como el proyecto Guifi.net y no depender de las políticas de exportación de los grandes fabricantes como TpLink o NetGear.
#32 Haztelo mirar... http://www.nlm.nih.gov/medlineplus/spanish/ency/article/003032.htm
#6 No necesitas permisos de administrador en el PC para hacer el tunel de la manera que se explica en el artículo
Cierto todo lo que dices #4
Pero en la realidad, en muy pocos sitios se utilizan IDS...
Son cosas distintas. Un tunel SSH no tiene nada de especial. Esto es un tunel mediante encapsulado HTTP.
#2 Es que los túneles por HTTP no existen. Los túneles se realizan en la capa de red si no, no es un túnel.
#3 WHAT ?!?!?
Un tunel es en definitiva encapsular algo en otra cosa.
Puedes encapsular trafico IP en peticiones DNS (http://proxychains.sourceforge.net/)
Y tambien puedes encapsular logicamente trafico IP en peticiones HTTP.
El problema de esto es que un IDS/IPS correctamente configurado va a delatarte, por lo que es un buen motivo para buscar que te despidan si lo haces en una compañia mediana/grande que haya implementado algun sistema de monitorizacion.
Y alguno me dira, pues se encapsula en HTTPS, a lo que respondere que los actuales FW/IPS pueden obligarte a cifrar el trafico HTTPS con su certificado generado al vuelo por la CA de la compañia (Men in the middle) y si no pueden descifrar el trafico porque no aceptas no dejarlo pasar.
Aun asi, el articulo es didactico, meneo.
#4 Gracias por el comentario, ha sido muy esclarecedor
Navega libremente: Tunel http a través de un proxy
dabax.netEs común que en algunos sitios como: universidades, colegios, oficinas, etc... Nos restringen la conexión a internet, limitándonos a utilizar sólo protocolos HTTP (puertos 80 y 443), y también prohibiendo la entrada en algunos sitios web. Además, nuestro tráfico es monitorizado y almacenado en logs, lo que viene a ser una molestia bastante importante. Para saltarnos estas restricciones, hoy explicaré como hacer un tunel HTTP a través de un proxy, de manera que nadie podrá saber donde accedemos, ni podrá limitarnos los protocolos.
Acces Point
#14 Gracias, estaba sencillo 
Tunel DNS: Cómo saltarse un portal cautivo
dabax.netEn ocasiones, y cada vez más, encontramos redes Wi-Fi públicas y abiertas (sin codificación de datos) que requieren autenticación. Cuando te conectas y accedes a cualquier dirección Web, salta un portal cautivo donde tienes que introducir un login: controlan el tráfico HTTP. Algunas están restringidas a cierto público cerrado, como estudiantes de una universidad. Y otras son del estilo: "envía un SMS y te dejamos navegar durante 30 minutos". ¿Existe alguna manera de vulnerar dicha restricción? La respuesta es si, mediante un tunel DNS.
Y si la petición es a:
HOlAESTEESUNMENSAJEQUEESTOYENVIANDOAMISERVIDORDNSIONIZADO.foo.com
Entonces? Puedes o no comunicarte con el servidor? Funciona o no con recursividad?
#11
Llegar llegara la peticion, otra cosa es que llegue con el payload o sin el Sinceramente dudo que con recursividad funcionase.
#8
1. 74.125.77.99 es uno de los servidores DNS de google.
netcat -vv -u 74.125.77.99 53
ew-in-f99.1e100.net [74.125.77.99] 53 (domain) open
netcat -vv 74.125.77.99 53
...
timeout
Como verás, tiene el puerto TCP 53 CERRADO. Por lo tanto da igual que los clientes windows hagan peticiones por TCP, los servidores DNS de internet no las van a resolver...
2. Tu puedes hacer cache de google.com -> XXX.XXX.XXX.XXX pero luego si te piden test.google.com deberá volver a hacer la peticion, y si luego te piden test2.google.com otra vez... Y asís succesivamente, por lo que la cache no sirve de nada.
Y no! tampoco puedes "descargar" de una vez lo referente a todos los subdominios, ese sería un grave fallo de seguridad para un servidor DNS.
Punto 1, los servidores DNS funcionan bajo UDP. Aunque puedan funcionar por TCP, no se utiliza.
Punto 2, si quieres que tu portal cautivo funcione, y quieres dejar únicamente acceso a tu propio servidor dns, este tiene que permitir RECURSIVIDAD, ya que sino, no podría resolver las direcciones como google.com, ebay.es, etc... Y si permite recursividad, entonces sigue siendo vulnerable.
La única solucion es controlar el tráfico DNS (inspeccionar los paquetes), cosa que a la práctica no se hace.
#7 Te reto a que pases el wireshark en una red llena de máquinas windows filtrando el trafico al puerto 53, te vas a encontrar paquetes tanto TCP como UDP. Que teóricamente se tenga que utlizar UDP no quiere decir que los fabricantes de S.O. hagan lo que les salga de los huevos (sobre todo en el caso de M$)
Respecto a lo que me comentas sobre permitir la recursividad en las zonas, eso funcionaría si tu servidor DNS no hiciera cache de las peticiones y te pasara directamente la información tal cual de los servidores raíz, pero eso en la práctica no se hace (o no se debería hacer, ya que incrementas el tráfico hacia afuera).
#7 Dudo que permitiendo recursividad siguiese siendo vulnerable ya que la recursividad implica que es el servidor DNS del portal el que resuelve la direccion (corregidme si me equivoco) y esa resolucion implica una nueva solicitud DNS que no tendria el payload que se quiere enviar al servidor DNS externo.
Aviso, no he probado el IODine, solo estoy teorizando.
#2 si, esa es una posible solucion. Pero ¿cuantos portales cautivos implementan eso? Me atrevería a decir que el 95% no lo hacen.
#3 para empezar DNS va sobre UDP, no TCP.
Y en segundo lugar, los portales cautivos requieren de resolución de DNS, ya que sinó cuando desde un cliente web accedes a google.com, este no es capaz de resolver la IP, y tampoco se le podrá redireccionar la petición hacia al portal.
#4
Punto 1:
DNS funciona bajo ambos, me he dejado la regla para UDP, pero es la misma que para TCP
Punto 2:
Se supone que tienes tu propio servidor DNS, evidentemente tienes una regla configurada para que tu DNS pueda salir, pero no permites el tráfico desde cualquier otra ip, daba por sentado que era evidente, pero es tan fácil como poner antes de la regla anteriormente mencionada, la siguiente:
iptables -A OUTPUT -p tcp --dport 53 -s ip_servidor_dns -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -s ip_servidor_dns -j ACCEPT
Lo puedes complicar todo lo que quieras, poniendo direcciones MAC, ESTABLISHED,RELATED, etc ...
#4 Te vuelvo a contestar sobre TCP/UDP, ya que me he repasado el protocolo:
En la guia de especificaciones de implementación de DNS, en el apartado 4.2.2 aparece el texto siguiente:
http://www.faqs.org/rfcs/rfc1035.html
4.2.2. TCP usage
Messages sent over TCP connections use server port 53 (decimal). The
message is prefixed with a two byte length field which gives the message
length, excluding the two byte length field. This length field allows
the low-level processing to assemble a complete message before beginning
to parse it.
Several connection management policies are recommended:
- The server should not block other activities waiting for TCP
data.
- The server should support multiple connections.
- The server should assume that the client will initiate
connection closing, and should delay closing its end of the
connection until all outstanding client requests have been
satisfied.
- If the server needs to close a dormant connection to reclaim
resources, it should wait until the connection has been idle
for a period on the order of two minutes. In particular, the
server should allow the SOA and AXFR request sequence (which
begins a refresh operation) to be made on a single connection.
Since the server would be unable to answer queries anyway, a
unilateral close or reset may be used instead of a graceful
close.
Read more: http://www.faqs.org/rfcs/rfc1035.html#ixzz0gSUKtVoG
supongo que queda claro ¿no?
#31 El cliente DNS que es el que se está hablando funciona sobre UDP, lo de TCP es en algunos servidores que lo utilizan para enviar información entre slave/master. Pero el cliente funciona solo en UDP.
Así que en este caso la regla o cualquier cosa que haga referencia a TCP no sirve para aplicarlo en este caso.
la pag. ya funciona
Estudio comparativo de varios compresores: bzip2, gzip, 7z, rar & zip
dabax.netLa compresión de datos hoy en dia es una tecnologia altamente usada. Buscamos el crecimiento exponencial del almacenaje de datos: soportes de almacenamiento mayores con archivos menores. Este artículo trata los compresores más comunes: rar, zip, 7z, bzip y gzip. Se estudian teniendo en cuenta dos factores distintos: Ratio y tiempo de compresión. También con tipos de datos distintos: Texto, Audio, Imagen, Binario...
#8
Se utilizan wave y bmp porque son formatos no comprimidos.
Jpg, mp3 y pdf son comprimidos, y volviendolos a comprimir no ganas nada...
El doc entraría dentro del campo de "Archivos de texto", es el mismo caso que un Código Fuente
La gente cree que en windows solo existe: Zip y Rar....
En el artículo no se explica "como robar la conexión al vecino", sinó como asociar una interfaz de red a un UID concreto. El uso que se le de a esta técnica depende del usuario. El caso del emule es un ejemplo para que se vea más claro de que trata. No pretendo fomentar nada ilegal.
El emule por la línea del vecino, y el resto por la tuya. En Linux es posible
dabax.net¿Alguna vez habeis querido poner el emule/bitorrent por la conexión wireless del vecino, mientras el resto de aplicaciones usan vuestra línea ADSL? En Linux es posible, mediante unas sencillas reglas de iptables. En este pequeño artículo se explica como asociar una conexión de red a un UID (identificador de usuario). De esta manera puede conseguirse que por ejemplo el usuario "manolo" salga por eth0 y el resto de usuarios por eth1. Luego bastará con ejecutar el emule con el usuario manolo y navegar con cualquier otro sin tener saturada la red.
#22 Jeje, me has pillado, era mi intención oculta. Es que estoy enamorado de Kahun y por eso quiero discutir...
Te vuelvo a poner el mismo ejemplo . La noticia a salido en Antena3, y seguramente en muchas otras cadenas. Si sale en un medio de comunicación masivo, tal como es la TV, ¿crees realmente que la noticia es "irrelevante"?
Además el PP ya se ha pronunciado en contra del partido. Y el mismo gobierno ha dicho que lo investigará...
Creo que la cosa es bastante relevante... Que a ti no te interese no quiere decir que sea irrelevante...
#18 ¡Vale, entonces la noticia es correcta!
Lo único que podría estar equivocado es el título, y creo que no lo esta. Porque yo no hablo de "selección oficial" sino simplemente de selección. Que ésta provenga de una entidad privada no quita el hecho que sea una selección.
#15 Pues acabo de oir la noticia por Antena3 y SI hablaban de selección.
#7 no creo que esta noticia sea provocativa. El resultado es lo de menos, lo polémico es que se haya jugado tal partido y en tales condiciones (en RUSIA). EL gobierno lo esta investigando... Si ubiese ganado España la polémica seria la misma!
Que yo sepa, el voto negativo no es para expresar que el contenido de la noticia no ha sido de tu agrado. Sino para reportar algo no correcto o difamatorio. Creo que este artículo no es incorrecto ni difamatorio, es objetivo. Por eso creo que no es justo votar negativamente esta noticia y otras noticias igual que esta.
Es una gran noticia!!
Una red elaborada por los ciudadanos, finalment ha terminado conectándose al punto neutro y a internet. Sin timofonicas, ni juazteles. Conexión simétrica con ips públicas (estáticas), y de gran velocidad para la gente de la calle. Por fin nos hacercamos un poco más al modelo de conexión utilitzado en los paises desarollados de verdad!
SAX!