¿Es posible detectar el tráfico de una red remota? (Con acceso de administrador al enrutador)

La pregunta # 3 es demasiado abierta para responder. Para los demás, la respuesta depende del modelo de enrutador en cuestión y, en función de eso, el significado exacto de "acceso de administrador".

Si el enrutador es un dispositivo basado en Cisco IOS y usted tiene acceso privilegiado de nivel 15, puede usar los comandos regulares de detección de paquetes de IOS que le permitirán alcanzar su tarea de detección. Sin embargo, ningún administrador de Cisco en su sano juicio haría que la interfaz de administrador fuera accesible desde Internet, y mucho menos con una contraseña predeterminada, por lo que el ataque no es muy factible en la vida real. Además, todos los administradores de Cisco que valgan la pena deberían haber configurado el registro en un servidor central de syslog para que su inicio de sesión y todos los comandos que use estén visibles en el registro.

Si se trata de un enrutador de consumo barato y normal y tiene acceso a la interfaz gráfica de usuario web, la mayoría de los modelos no ofrecen una función de detección de paquetes allí. Sin embargo, unos pocos lo hacen. (A menudo, en una URL "oculta", pero eso no es un obstáculo, por supuesto). La mayoría de los modelos no son accesibles desde Internet por defecto, pero algunos sí lo son. Entonces, si el enrutador en cuestión es uno de los modelos con un rastreador incorporado y accesibles desde Internet, entonces sí, el ataque sería factible y podría pasar desapercibido ya que la mayoría de estos dispositivos ni siquiera admiten el registro en un servidor de registro, e incluso si lo hacen, un propietario que no cambia la contraseña predeterminada tampoco configurará el registro. Por lo tanto, en este caso, el ataque depende completamente del modelo de enrutador específico y que usted conozca al respecto.

Si se trata de un enrutador basado en Linux (ya sea uno de los muchos modelos comerciales que utilizan un kernel de Linux o un dispositivo de fabricación casera) y usted tiene acceso de root al kernel de Linux, entonces, por supuesto, puede hacer lo que desee. Sin embargo, el acceso a la raíz con la autenticación de contraseña desde Internet es definitivamente imprudente, y no es la configuración predeterminada para ningún dispositivo que haya visto.

Si puede iniciar sesión de forma remota, habrá muy poco que no pueda hacer. Una vez que tenga un shell raíz, puede ejecutar fácilmente tcpdump. Puede leer las bases de datos locales que proporcionan claves de cifrado en otro lugar. Si dentro de ese shell, faltan comandos; Puedes escribir, o simplemente ir a buscar los comandos que quieras. Si logras entrar, probablemente haya mucho ancho de banda; y puede pasar desapercibido por un tiempo mientras las cosas sigan funcionando.

enlace

Sin embargo, la mayoría de la gente permitirá que el ISP configure el enrutador que se conecta al ISP; y eso no va a tener la contraseña predeterminada y dejará entrar al mundo. Verizon usa un UUID enorme para la clave de cifrado (escrita en una etiqueta en el módem), etc. Habrá cosas mal configuradas por ahí, pero no es como se usa para ser (con los usuarios finales que van a Best Buy y (mal) configurarlo él mismo).

Dado que estamos hablando de tráfico http no cifrado (si está cifrado, simplemente déjelo), suba el servidor al puerto deseado, incremente el servicio dns falso, que devolverá la IP de su servidor en cada solicitud de dns y cambie parámetro DHCP del enrutador "Servidor (es) DNS" en la IP de su servidor.

Además de intentar rastrear paquetes en el enrutador, hay, por supuesto, métodos que le permiten aprovechar el hecho de que tiene cierto control sobre el enrutador para habilitar ataques en otros lugares donde tiene mayor flexibilidad y amplitud. ; Facilidad de olfatear su tráfico. Dos ejemplos:

1. Si el enrutador tiene la capacidad y usted tiene acceso, configúrelo para que reenvíe el tráfico http saliente a un servidor proxy transparente que haya configurado, con cualquier rastreador de paquetes que le guste ejecutar en la caja o VM a su lado. La parte "transparente" significa que el usuario en el cliente final (es decir, él, usando su computadora) no podrá detectar ningún cambio en la configuración de red de su dispositivo, ya que no se necesitarán ni ocurrirán tales cambios; Todo será hecho por su enrutador y su proxy. En cuanto a si esto generaría sospechas con un usuario final al afectar significativamente la velocidad de la conexión, supongo que eso depende del rendimiento del servidor proxy seleccionado y la latencia agregada por la longitud del segmento entre su enrutador y su servidor. entre otros factores. Apache configurado como un proxy transparente, que se ejecuta en una instancia de AWS con especificaciones adecuadas, podría ser una forma bastante sencilla de configurar algo como esto y obtener un rendimiento de proxy no pésimo. Contra un usuario común, la táctica probablemente no se detecte durante bastante tiempo en la mayoría de los casos. Contra una persona experta en tecnología que observa específicamente las anomalías de latencia de conexión ... no hay garantías.

2. Cambie la configuración de su servidor DNS para que apunte a un servidor DNS malicioso que haya configurado, señalándolo cuando solicite un sitio http sin cifrar / sin formato a una página de error de aspecto legítimo que contenga un elemento malicioso que haya adjuntado con Metasploit. Si no está ejecutando de forma no diligente un cliente Java o una versión de Flash no parcheados, puede soltar una carga útil de https inversa en su caja, luego entrar y correr un sniffer o compartir su pantalla y verlo mientras dispara su ping a donde sea. :-)

(Nota: la segunda cosa fue una broma. Ir más allá de cambiar la configuración del enrutador del otro tipo para piratear su PC sin su mayor consentimiento sería exceder el alcance de lo que tiene permiso para hacer. Lo que podría / afectaría La legalidad de tus acciones. No vayas allí.)