Portada
mis comunidades
otras secciones
#29:
Un tutorial tan fácil, sencillo y práctico que se le he enviado a a mi madre, y vecinos para que se conecten al Güifi gratis
#6:
#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 ...
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 ...
Comentarios
Un tutorial tan fácil, sencillo y práctico que se le he enviado a a mi madre, y vecinos para que se conecten al Güifi gratis
qué pena que no entiendo ni papa...
Cualquier protocolo que permita payload es susceptible de algo así. Creo que sería mas exacto llamarlo canal encubierto.
Concretamente este caso concreto tiene un par de puntos flacos:
a) Muchos puntos de acceso no solo sirven de gateway, sino que proveen tambien la resolucion DNS. Eso implica que el administrador de turno pueda bloquear el trafico a servidores DNS externos.
b) Puede ser que haya instalado en la red un sistema IPS que detecte el trafico DNS modificado y lo considere sospechoso, bloqueándolo en consecuencia.
#2 si, esa es una posible solucion. Pero ¿cuantos portales cautivos implementan eso? Me atrevería a decir que el 95% no lo hacen.
vaya, siempre pensé en hacer un programita de este tipo... también me llamaba mucho la atención que el DNS lo permitan. Gran descubrimiento. Gracias =)
Yo en clase lo hago con:
ssh -p80 -ND 1234 usuario@servidor (obviamente el servidor tiene ssh en el puerto 80)
luego configuro un proxy socks v5 en el navegador (localhost:1234) y listo!
#20. Se suele camuflar mejor en el puerto 443
#20 Entiendo que lo que usas en este caso no serviría, ya que el AP, al hacerle la petición de dns de tu servidor, te redireccionaría al portal cautivo
#24 Una pregunta de principiante... ¿las peticiones no irían cifradas? (o al menos no "visibles" al AP)
#24 Lo he usado para saltarme portales cautivos. No tienes por qué hacerle una petición al servidor DNS si te sabes la IP de tu servidor
Muy relacionado.
Para la gente que en su empresa le han puesto un proxy (le han capado el accedo a ciertas páginas) yo he usado con gran éxito:
http://www.privoxy.org/
Monta un proxy local tuneleando a tu servidor fuera de la red.
#22 Para eso hay proxys como dice #18. Otro buen proxy es Ultrasurf
http://www.ultrareach.com/download_en.htm
Doble click y navegando en Windows.
#23: Joneame es un saco.
¿Qué es AP?
El artículo muy interesante, y los comentarios también
Meneo
Y yo me pregunto.
¿No hay este tipo de servidores "en Internet"? ¿Sin tener que crearnos nosotros uno?
A que no sabéis cómo se hace en Android...
Muy buena aunque requiere un servidor externo controlado por nosotros y para eso tb puedo hacer un tunel ssh con el putty (si es que se permite la salida por el puerto 22 o el que haya configurado en mis servidor ssh claro) y redirigir peticiones a donde me plazca
¿Alguien lo ha probado en los aeropuertos de AENA?
Lo que hace la gente por ahorrarse los 2 euros
Acces Point
#14 Gracias, estaba sencillo
Por lo que entiendo es que solo "se bloquea" la DNS.
Mi solucion sencilla, que entiendo funcionaria tambien
Yo en el pasado, en una empresa usaban WINS (algo asi como unas DNs de microsoft para un controlador de dominio) y claro, si escribias www.google.es no te resolvia nada, solo las urls que ellos querian. Por lo tanto me busque una pagina DNS a IP y me apunté la IP de dicha web.
accedí al sitio al estilo http:// XX.XX.XX.XX y de ahi tecleaba la web que queria visitar y me daba la IP y accedia sin mayor problema la mayoria de veces, otras habia errores puesto que los vinculos a otras webs o imagenes no se resuelven, pero al menos vale para navegar un poco.
Entiendo que con el iodine no pasara puesto que te "resuelve" todas las peticiones que tenga la pagina html y fucnionara mejor, pero requiere instalacion y tener un servidor preparado por detras.
muy buen aporte bros ¡¡
¿Por symbian se podría hacer algo similar?
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).
#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.
#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.
#7. Sólo por informar. TCP se utiliza para las transferencias de zonas. Te aseguro que en donde estoy se hacen varias veces al día.
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.
iptables -A output -p TCP -dport 53 -j DROP
#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.