Hola a todos,

A ver si alguien me puede ayudar con este problema: He modificado por error las iptables en un RHEL 5.2 y he tenido que reiniciar el sistema. En el reinicio, se queda en el mensaje "Aplicando Reglas del Firewall" y no termina de arrancar. He modificado en el arranque de Grub , con la opción e (editar), los parámetros de arranque añadiendo la opción single que fuerza el arranque en modo monousuario" para poder luego deshabilitar las iptables, pero siempre intenta cargar las reglas del firewall.
También he probado en el menu Grub con la opción a y añadir a la linea del kernel la opción single pero tampoco funciona, siempre intenta cargar las iptables.

Todo esto lo he probado en un centos 5.3 y ha funcionado sin problemas.

Alguien me puede ayudar? Mil gracias!!


cso

Creo que es obvio que hay algún error en el script que maneja las reglas. O bien nunca sale, o bien entra en un bucle infinito.

Supongo que ya has probado lo más simple: Ctrl+C, Ctrl+Z; aunque lo más probable es que eso no funcione, dependiendo del momento en que intenta cargar el script.

Así que lo más rápido, creo que es entrar con un livecd, y editar el archivo que modificaste. Ni siquiera hace falta un chroot.

Muchas gracias, neurus

Pero lo que hice fue ejecutar un script con unas reglas de iptables erróneas. Una vez arancado con el livecd, qué archivo de configuración tendría que modificar para evitar que las arranque?

Gracias

pues el mismo que modificaste XD

Con simplemente ejecutar un script, no puede pasarte eso. En última instancia, el script se instaló en algún archivo de arranque (¿lo tienes a mano, para ver qué hace ese script?).

En RedHat, el archivo de arranque por excelencia es /etc/rc.local; pero debes saber qué estás buscando.

Lo que sí es seguro, es que agregaste una llamada a un script, que entra en un bucle y no libera el sistema para la carga normal de sysv.

Si, el script se instaló en algún archivo de arranque, ocurrió que tenía un script de iptables que funcionaba perfecto pero por error sustituí las primeras lineas que contenían ACCEPT por DROP, con lo que se ejecutó algo así:

iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

etc..

Gracias

Creo que tenemos un problema de comunicación.

Te digo que el script se instaló en algún archivo de arranque, y me respondes que sí, efectivamente, se instaló en algún archivo de arranque. Ahora me toca a mí, corroborar: sin dudas, se instaló en un archivo de arranque. Ahora sería tu turno.

O, si lo prefieres, puedes buscar el script que ejecutaste para saber concretamente qué hizo (no "algo así"), o buscar el dichoso archivo de arranque y modificarlo. Pero no puedes pretender que adivinemos qué ejecutaste ("un script" no es ningún dato), y dónde se está ejecutando ahora. Empieza por /etc/rc.local y sigue por el directorio init.d. Con los datos que das, es imposible más precisión de nuestra parte.

Ok, tienes razón. El script que he lanzado se llama iptables.sh y contiene lo sig:

####Configuracion de iptables que aplicamos a esta maquina #######
/sbin/iptables -F
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP
/sbin/ifconfig
#
/sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth0 -o eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth0 -o eth3 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth0 -o ib0 -m state --state RELATED,ESTABLISHED -j ACCEPT
#
/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
/sbin/iptables -A FORWARD -i eth2 -o eth0 -j ACCEPT
/sbin/iptables -A FORWARD -i eth3 -o eth0 -j ACCEPT
/sbin/iptables -A FORWARD -i ib0 -o eth0 -j ACCEPT
#
/sbin/iptables -A FORWARD -j DROP
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 150.234.123.34
/sbin/iptables -L -v
/sbin/service iptables save
/sbin/service iptables start

Gracias,

Pero por lanzar eso, no se puede dañar el arranque.

Como faltan el encabezado (#!/bin/bash), que supongo has omitido para ahorrar espacio, supongo también que falta el "exit" final. Pero este fallo sólo tiene sentido si este script está siendo llamado desde un script de arranque. Y seguimos sin enterarnos de dónde está el archivo de arranque con la llamada defectuosa.

Una solución a lo bestia (porque no proporcionas datos que permitan otra cosa), es cargar un live cd, montar la partición raíz de Red Hat, y quitarle permisos de ejecución, o renombrar, el archivo /etc/init.d/iptables . Esto no dañará el sistema, y es perfectamente reversible. Pero al menos te permitirá arrancar para luego tratar de solucionar el problema, cualquiera sea, con sysinit.

Te cuento cómo ha sucedido. El equipo está en otra ciudad y yo estaba conectado via ssh para hacer ciertos cambios. El script de las iptables no tiene ni el #!/bin/bash ni el exit, lo ejecuté con sh iptables.sh y permisos de root, y automáticamente me cerró la sesion ssh. Al llamar al operador de la máquina no conseguía ver nada en pantalla por lo que reinició el sistema y me dice que empieza a arrancar pero se queda en un punto diciendo "aplicando reglas firewall" y de ahí no pasa. Por esto he intentado que el operador haga el arranque en modo single user (editando grub cuando arranca y añadiendo al final de la linea kernel 2.6.... un espacio en blanco y la palabra single y b para pedirle que aranque), pero siempre intenta cargar las reglas del firewall y se queda en ese punto.

simple dile al operador que cargue el livecd y que quite el firewall o lo remplace por el anterior

Luego tengo que vérmelas con quienes dicen que respondo de mala gana... Y no es que me guste maltratar a la gente... pero ¿después de todos estos posts se te ocurre decir que no tienes acceso físico?

Por lo que cuentas, eres el administrador. ¿Hace falta pedirle a un administrador que copie el script para saber qué hizo?

En fin. Tu problema es esta línea:



Que llama a un script de Red Hat (no lo conocía, puesto que soy usuario de Debian).

Como dice el artículo del link, debería haber un backup de la configuración original en /etc/sysconfig/iptables.save

Ahora, la cuestión está en ver cómo te las apañas para explicarle a quien sí tiene acceso físico, la manera de:

bootear con un live, montar la partición raíz de RedHat, y renombrar el archivo iptables.save a iptables.

De todos modos, ahora no me termino de creer que no haya podido iniciar en modo single. Apostaría a que escribió algo mal, o no siguió tus instrucciones y terminó arrancando en modo normal. Porque lo lógico es que en modo single (¿existe todavía el modo interactivo?) arranque sin ningún servicio, y te deje en una consola.

E insisto: ¿Ctrl+C no funciona?.

El problema con esta metodología (tú le preguntas a él, nos cuentas a nosotros, nosotros te respondemos, tu le cuentas a él...) es que se siente como operar la Mars Rover, pero una Mars Rover con los algoritmos de Bender.


Edit: y todo esto, suponiendo que el problema está en el inicio de iptables (que yo no lo veo en el script, si he de ser sincero). Porque existe la posibilidad de que el problema estuviera latente, y sólo hiciera falta un reinicio para manifestarlo. Y entonces sí: puede ser casi cualquier cosa.

No, el CTR-C no funciona. Ni CTRL-Z.
Bueno, tendré que ir yo.
Muchas gracias por todo.

no me acabo de convencer que se contrate un servidor dedicado y el contratado no sepa lo único que debe saber sobre GNU/Linux para brindar el servicio, bootear con un LIVECD y desactivar un script XDD ... no lo digo solo por este caso sino también por otro que hace poco surgió ->

En este caso, no me suena a servidor dedicado, sino más bien a una oficina, comercio o empresa, que este usuario tiene a cargo (soporte informático). Y del otro lado, no está el empleado de un web hosting, sino un oficinista, o un comerciante sin conocimientos específicos de informática.

Me ha pasado, tener que tomarme un taxi por un error de tipiado mientras trabajaba por ssh; y la absoluta imposibilidad de hacerle entender a la secretaria lo que debía escribir en la consola. Es decir: atravesar la ciudad en taxi, entrar, escribir /etc/init.d/ssh start; saludar a todo el mundo, volver a casa...

Creo que esa es la situación aquí.