Mensajes

Hasta donde sé este tipo de gestores de descarga como clientes que son utilizan puertos efímeros del nivel de transporte, no puertos well-know. Es decir que tendría que correr como server-thread (servicio) para que abriera un puerto permanente al cual se pudiera conectar desde Internet.

Cualquier puerto que hayas abierto en el router deberá corresponder a un servicio y protocolo determinado en algún host de la LAN al que quieres que se acceda desde la WAN: por ejemplo HTTP y puerto 80 del servidor que tengas en un equipo dentro la red privada. No tendrías que cerrar ningún puerto para una aplicación que se conecta como cliente a un servidor de descargas (pj de megaupload), porque éstos sólo están activos durante el tiempo de la descarga, por eso se les llama efímeros y corresponden sólo a los clientes. En cambio los servidores sí que necesitan de puertos bien conocidos y registrados que permanentemente estén abiertos para aceptar las solicitudes de los clientes.

Para saber qué puertos tienes abiertos permanentemente puedes usar un portscanner y dirigirlo a la dirección loopback o con el comando y argumentos netstat -noa desde el command prompt.

Espero haberte ayudado. Saludos.

¿Te refieres quizá a multistage switch fabrics para Omega networks, Banyan networks, Delta networks y así?

La verdad no entendí bien..

Saludos.

Por pura curiosidad ¿qué esquema de VLAN usan, dinámico? Además ¿lo que quieres es que no accedan los usuarios mediante sus propios equipos a la red o que de ésta tengan salida? Te lo pregunto poque eso se debió de haber previsto con unas políticas y modelo de control de acceso desde un principio cuando se diseñó. Ahora para mí la opción más viable es que consultes con tus superiores la posibilidad de implementar una nueva política para los accesos vía cable (control de jacks) o vía inalámbrica (control de APs inalámbricos). Si lo que quieres es un control centralizado vía login, la mejor opción podría ser implementar un NOS que se encargue de asignar todos los recursos de la red a las estaciones. Obviamente eso sería mucho trabajo y tal vez sería difícil de realizar. Igual lo de un filtrado mediante direcciones físicas, pues necesitarías identificar de cada uno de los hosts autorizados su MAC y llevar un registro. Otra opción es solo dejar DHCP en los segmentos que realmente se necesite y lo demás asignación estática (UUUG).

¿Qué apoyo tendrías de tus superiores para implementar una política de cero tolerancia?

Saludos.

Mejor podrías instalarte una VM con WinXP, poner la conexión de la NIC en puente y probar tu exploit.

Ah y no es cosa de que la tarjeta sea vulnerable o no. El exploit que te interesa es para un servicio de un Sistema Operativo específico como bien te mencionaron ya, no para 'explotar' una tarjeta.

¿Recomendarte algún exploit para Win7? Jajaj mejor investígale por medio de tu buscador preferido y luego nos comentas qué encontraste.

Si estás experimentando con Metasploit, podrías comenzar por ahí.. hay mucha documentación sobre los scripts que soporta.

Saludos.

ea disculpa que te conteste hasta ahora, ya sabes esto de las fiestas, los reyes de los chamacos y eso..

De lo de CSRF -->http://es.wikipedia.org/wiki/Cross_Site_Request_Forgery

Lo que quieres es "Si tengo un dominio www.ejemplo.com vulnerable a XSS y en usuarios.ejemplo.com se logean los usuarios. Como puedo hacer para conseguir la cookie de usuarios.ejemplo.com desde www.ejemplo.com"---> la respuesta es haciendo bypass a same origin policy y claro estamos hablando de un persistente ¿no?

"Si tengo un XSS en www.ejemplo.com , desde www.paginaweb.com puedo ejecutar acciones, a traves de peticiones GET o POST a www.ejemplo.com, aunque la XSS no este en ese mismo dominio, ¿no?.. Corrigeme si me equivoco." Lo mejor sería que el XSRF lo tuvieras en www.ejemplo.com junto con el XSS persistente, podrías hacer requests al subdominio que quieres usuarios.ejemplo.com, preparar tu script para añadir un iframe nulo y de ahí enviarte las galletas tu mismo (aunque este tipo de control sobre el browser, como te mencioné, haría trivial lo de las cookies y por cierto existen algunas tools que lo automatizan), busca el texto al que hice referencia --->"Buy one XSS, get a CSRF for free".

En cuanto a readViewPort(), es una función ficticia aunque posible, con ella se podría escanear la intranet desde el browser controlado. Como te dije, si llegas a tener un control del navegador a ese nivel mediante una 'simple' vulnerabilidad XSS, lo de robarse las cookies de sesión termina siendo algo trivial.

Un saludo.

Hay formas mediante las cuales una vulnerabilidad XSS en el contexto de un subdominio pude ser aprovechada para  bypassear la regla de 'same origin policy' y tener impacto fuera de éste, por mencionar dos: CSRF ("Buy one XSS, get a CSRF for free") e iframes que utilicen el método readViewPort() (¿Para qué conformarse con robar cookies si podemos registrar pulsaciones del teclado, mantener infectado el browser o atacar la intranet?).

Saludos.

xD
Antes que nada la expresión 'rootear' no aplica para arquitecturas Windows, pues no existe cuenta o privilegios root, eso es para servers *nix-linux. En windows es más bien obtener privilegios de System o Administrador.

IIS históricamente ha tenido muchos bugs y sus correspondientes exploits. El más conocido quizas es el unicode encoded directory traversal attack.

Saludos.

Aparte del método usando binario hay uno más rápido que sólo requiere saber aritmética y memorizar unos valores.

Ejemplo:
memorizamos que:
todo el byte de la dirección a 0 == 0 -->0
1 bit del byte de la dirección a 1 == 128 -->relación 128
2 bit del byte de la dirección a 1 == 192--->64
3 == 224-->32
4 == 240-->16
5 == 248-->8
6 == 252-->4
7 == 254-->2
Todos los bits a 1 == 255.
Entonces: red 192.168.10.0 y máscara 255.255.255.240. Si te fijas los 3 primeros bytes están a 1 porque la máscara es 255.255.255. Eso quiere decir que el cuarto es el que se toma para subnet y está en 240.
Primero encontramos las subnets: 240 son 4 bits (ve los valores a memorizar), 2 a la cuatro menos 2 = 14 (se sustraen dos porque tradicionalmente no se utilizan las subredes todo a 1 y todo a 0).
Segundo los hosts : del cuarto byte se tomó 4 bits y quedan otros 4. 2 a la cuatro menos 2 = 14
Tercero las subredes válidas: 256 menos 240 = 16. Entonces 16+16 = 32, 32+16=48, 48+16= 64, 64+16=80, 80+16=96, 96+16=112...224+16=240 hasta tener nuestras 14 subredes.
Ya nada más faltaría asignar direcciones a hosts y encontrar direcciones reservadas para broadcast en cada subnet.

Sin embargo, aunque con este método casi no usas binario, sí es recomendable que lo entiendas bien, pues éste fue un ejemplo sencillo dividiendo una 24.

Saludos.

Eso se debe muchas veces a interferencias ocasionadas por dispositivos 2.4Ghz que pueden literalmente barrer el polvo con algunos canales de redes wifi cercanas. Haz un escaneo con WiSpy 2.4x para ver si detectas el dispositivo que esta matando canales, localiza otro canal que deje libre y reconfigura tu router-AP con ese.

Saludos.

Gracias por contestar, mi duda es ... si subo a canales altos, tendré más conflicto que en los pequeños??? es que no te he entendido bien lo de los conflictos.

Al contrario, si eliges canales altos habrá menos probabilidad de interferencia con otras redes wifi y dispositivos en el rango 2.4Ghz. Primero porque canales más altos equivale a un incremento de frecuencia radial, segundo porque comunmente los canales intermedios son los que muchos AP usan por default.