Nuevo hack La Fonera para ejecutar código

mave · 18 noviembre 2006 15:51

Supongo que esto hay que ejecutarlo estando conectado por la wifi privada.

santito · 18 noviembre 2006 15:55

Sí, ya que el acceso al entorno de administración por defecto sólo es posible desde la red privada, sólo se puede hacer desde ella.

Además te pide el usuario (admin) y password de administración de la fonera

Nkieto · 18 noviembre 2006 18:23

¿Lo habéis probado?

Yo he probado con las dos sentencias por separado:

/usr/sbin/iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
/etc/init.d/dropbear

Y nada.

Luego he probado con la conjunta:

/usr/sbin/iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT && /etc/init.d/dropbear

Y adios Fonera. Ya no arranca ningún señal Wifi, ni ya puedo acceder con un cable directo, ni nada. Voy a resetearla.

santito · 18 noviembre 2006 18:40

Yo como ya tengo abierto el puerto para SSH y ejecutándose el dropbear, no lo he probado con esos comandos específicamente, pero sí ejecutando un "touch /tmp/prueba" y funciona correctamente. Voy a probar a cerrar el puerto y parar el dropbear a ver y ejecutarlos mediante el script web.

Nkieto · 18 noviembre 2006 18:52

La he reseteado, que susto, todo vuelve a la normalidad, pero nada, por más que lanzo las dos secuencias no cambia nada.

Aplico la primera, y se queda en la pantalla del panel de la Fonera, "Advanced Wireless Settings", y luego vuelvo a lanzar la segunda, pero nada, no se abre puerto alguno.

Es raro, en los foros DD-WRT dicen que les ha funcionado con la 0.7.0 rev.4, la misma que tengo yo también.

santito · 18 noviembre 2006 18:56

Qué panel de la Fonera? Si no tiene que salir nada de la web de configuración, mas que la ventana de diálogo donde te pide el usuario y password para hacer login en la fonera.

santito · 18 noviembre 2006 18:54

Me respondo a mí mismo, ya lo he probado, cerrando con iptables el 22 y ejecutando killall dropbear, he pasado por el formulario el comando

/usr/sbin/iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT && /etc/init.d/dropbear

todo en una línea y todo ha vuelto a vivir, puerto abierto y servidor dropbear ejecutándose de nuevo.

Así que reiniciala La Fonea y prueba de nuevo, a mi creo que la primera vez que lo he probado se ha ido a cascarla por cualquier cosa de la vida, pero no tiene nada que ver siempre que no ejecutes algún comando que la líe ;-)

Suerte

Nkieto · 18 noviembre 2006 18:56

Una vez ejecutado el comando no tengo que reiniciar ni nada ¿no?. Volvería a perder el puerto abierto imagino!.

Angelus · 19 noviembre 2006 00:19

efectivamente funciona

 BusyBox v1.1.3 (2006.08.17-19:56+0000) Built-in shell (ash)

 Enter 'help' for a list of built-in commands.

 _______ _______ _______

 | ____|| || _ |

 | ____|| - || | | |

 | | |_______||__| |__|

 |___|

 Fonera Firmware (Version 0.7.0 rev 4) -------------

 *

 * Based on OpenWrt - http://openwrt.org

 * Powered by FON - http://www.fon.com

 ---------------------------------------------------

elchavaldelapeca · 19 noviembre 2006 00:57

Hola,

tras muchas pruebas, me he dado cuenta que el código html que ha pegado el autor del post no es correcto, o al menos en mi caso no se lo tragaba el Firefox o la Fonera...

Finalmente he comparado la versión colgada por el autor del post con la versión que se posteó el día 16 en dd-wrt.com/phpBB2/viewtopic.php?t=5083&p…asc&start=90

El fallo está al pegar el código directamente, el weblog de bandaancha lo interpreta como codigo html y sustituye los dos & q u o t por "

Happy Hacking ... ;)

Nkieto · 19 noviembre 2006 14:02

Que grande eres, quiero un hijo tuyo :-P

Al final lo he conseguido, como dice elchavaldelapeca, y mira que alguien dijo que verificáramos el html a ver si estaba igual, pero yo estaba cegado en otros temas.

*BocaDePez* · 19 noviembre 2006 01:53

que es ssh?
hay algun comando para solucionar el problema de que desde la red de fuera pueden acceder al cablemodem?
con algo de iptables no se podria denegar el acceso a la ip 192.168.100.1?
como se haria?
saludos

braculas · 19 noviembre 2006 12:04

ifconfig ath0 down y problema resuelto.

*BocaDePez* · 22 noviembre 2006 13:30

este comando se puede meter directamente desde el hack html o tiene que ser por narices en el cliente ssh?

Luke · 19 noviembre 2006 12:50

iptables -I FORWARD 1 -d 192.168.100.1 -j DROP

si lo pones en el archivo /etc/firewall.user se ejecutará cada vez que arranques el trasto.

Por cierto, editad el archivo /bin/thinclient con vi y comentad la última línea (poniendo un # delante de ". /tmp/.thinclient.sh") que si no os pueden actualizar la fonera y joder el invento en cualquier momento

howto :p :

vi /bin/thinclient
3 veces a Av. pág
i
#
esc
:x

y listo..

Recon · 19 noviembre 2006 13:48

1 me lo puedes explicar mas facil, es que de esto no tengo ni idea?
ponian que solo valia hasta que se apagara la fonera.
2 hay alguna manera de que este siempre?
3 en caso de querer dejar la fonera como estaba por defecto se puede?
4 alguien lo ha probado?
5 esa ip estara prohibida para las 2 redes o solo la externa?
6 esta prohibida paracualquier puerto?
gracias

Recon · 19 noviembre 2006 19:25

porfa

braculas · 20 noviembre 2006 12:13

Con esa línea que ha puesto luke prohibe la entrada a la dirección desde las dos redes.

Recon · 19 noviembre 2006 20:45

podeis explicar como se hace lo de impedir el acceso a una ip.
detalladamente?.
saludos

hawkmoon · 20 noviembre 2006 12:59

Busca en google iptables, o un manual de iptables.

*BocaDePez* · 21 noviembre 2006 19:51

perfecto
lo acabo de hacer y ya no se pueden conectar a mi modem con ip 192.168.100.1
como es que si no hay acceso a esa ip si hay salida a internet?
gracias a los 2

mave · 22 noviembre 2006 12:34

Porque una cosa son los paquetes que se "forwadean" para que los rute, y otra los paquetes que tienen como destino "la ip" del router. Se tratan distinto.

*BocaDePez* · 22 noviembre 2006 13:26

si no me equivoco
iptables -I FORWARD 1 -d 192.168.100.1 -j DROP
esos los esta "forwardeando"

*BocaDePez* · 22 noviembre 2006 13:27

otra cosa, podeis explicar que significa -I -d y -j?
gracias

mave · 22 noviembre 2006 20:01

-I Insertar la regla en la cadena FORWARD
-d La ip destino a la que se va aplicar la regla
-j Que hacer con los paquetes que cumplan la condicion (drop=tirar)

mave · 22 noviembre 2006 20:00

Eso es FORWARD de un paquete que entra por un interfaz y sale por otro....

Los paquetes que van hacia internet o cualquier sitio, la fonera les hace NAT con su ip, por lo que en realidad son paquetes que aplican a la cadena OUTPUT.

Luke · 23 noviembre 2006 18:19

no, son forward. Aunque fuera la misma interfaz TAMBIEN sería forward, porque está enrutando. Da igual que en la cadena prerouting o postrouting se haya hecho nat/masquerade.

output e input sería en este caso para paquetes con destino FINAL la fonera y que salen de ella (de procesos de la fonera), el resto, sea el sentido que sea, va por forward

Puedes comprobarlo en cualquier router ADSL con linux (como el comtrend):

Chain FORWARD (policy ACCEPT 82M packets, 59G bytes)

Por ejemplo. En un comtrend, que es el que tengo, ese contador es el de la policy por defecto, y es tráfico red->internet, porque todos los casos internet->red están cubiertos por reglas . No hay regla específica para el otro sentido (-o ppp_8_35_1) y el policy por defecto de la cadena es ACCEPT, de ahí que esos 59G sean todo saliente. No he pegado las reglas de entrante porque son muchas.. pero vamos, se ve que es forward todo.

*BocaDePez* · 23 noviembre 2006 15:03

es interesante, comentar algo

*BocaDePez* · 23 noviembre 2006 18:55

he hecho lo que decia luke pero tengo dudas
si le doy a reset queda como estaba?
se puede poner algun comando temporal para que este disponible esa ip hasta que se reinicie?
lo de deshabilitar la publica hay que hacelo por cojones en ssh o hay alguna manera de hacerlo con el codigo html?
saludos

Angelus · 24 noviembre 2006 00:28

Bug resuelto en un nuevo Firmware

Cierro