Vaya por Dios ... bueno, empecemos el curso de iptables. A ver, todos juntos: "Migraré todos mis RHa SUSE" (repetir hasta caer hipnotizados) ... ;)
Lo hago todos los días, lo prometo :-). Pero es que no me hacen caso. Cuando digo que si ´lo habéis probado en suse´ me miran raro. De momento he conseguido que se lo instalen con arranque dual en los portatiles. Y eso que tengo una version sles con un mes de parches gentileza de Novell para que lo prueben... pues no quieren :-? (lamentablemente, RH sigue muy por delante de suse-novell comercialmente hablando). Entre los que quieren instalar SAP sobre windows (agh), y los que quieren hacerlo sobre HPUX... son muchas guerras :D
Resulta que tengo un RHEL ejecutando un SAP. En teoria, los clientes pueden conectarse con un navegador web a la direccion:
Madre mía !!! ¿Qué mal has hecho para que te encarguen esa misión? ;)
En realidad, no es mi misión, sólo les hecho un cable. Mal que bien, vamos tirando...
pero el servidor rechaza la conexión. Si apago iptables (/etc/init.d/iptables stop), ya da un error 503, asi que imagino que
ah si, yo creo que esto ocurrio cuando apague iptables y paramos el servivio sap. No me preguntes por qué hicimos las cosas al mismo tiempo, no tiene sentido.
A ver si no va a ser cosa del iptables. Ten en cuenta que un 503 es "Service unavailable". Comprueba que los puertos estén abiertos y que estén escuchando en la tarjeta que deben:
eso pensé yo en un primer momento. La cosa es que instalando sap en windows deja acceder por defecto, e instalando sap sobre linux no, solo desde localhost. Asi que pensamos que era cosa de linux, no de sap.
lsof -i -n -P
ah!! ese era el comando que no recordaba para mirar esto! Luego lo pruebo (estan con pruebitas en windows :-( )
Así que me imagino que tengo que modificar iptables. Lo que hay hasta ahora (iptables -L):
Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp any ACCEPT ipv6-crypt-- anywhere anywhere ACCEPT ipv6-auth-- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:5353 ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Estas reglas son un poco confusas, tienes una que acepta todas las conexiones:
ACCEPT all -- anywhere anywhere
y una regla que las rechaza:
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
solo por especular, esta regla no rechazaría todos los paquetes _icmp_ y solo los icmp?
A ver qué podemos hacer:
iptables -F
iptables -A -s IP_buena_que_puede_conectar -d IP_servidor_SAP --destination-ports 5000 -j ACCEPT
iptables -j DROP
Es la regla más sencilla que se me ocurre:
- el paso 1 lo que hace es borrar todo lo relativo a iptables que haya cargado. Es _OBLIGATORIO_ que en todo FW sea la primera regla
ahá...
- el paso 2 tendrás que repetirlo por cada equipo que pueda conectar. Sustituye:
* IP_buena_que_puede_conectar: por la IP de cada máquina que tenga derecho a conectar
* IP_servidor_SAP: por la IP del servidor SAP
Bien...
- la tercera regla lo que hace es desechar todas las conexiones que no cumplan las reglas anteriores.
Uhm... o sea, solo dejo conexiones al puerto 50000 de las ips que determine, no? A ver, lo que me hubiese gustado, y expliqué mal asumiendo que esta implicito, es añadir a las reglas existentes, las del paso 2. No tirar todas las que hay (que no se que mas hacen, aparte de lo que has comentado), y usar solo esas. Por ejemplo, uso masivamente ssh, seguramente necesite tb alguna bbdd, quien sabe si un ftp (como curiosidad, el puerto 80 responde con iptables funcionando), etc etc. Hay alguna forma de añadir la regla 2 a lo que ya existe?
Epsero que funcione ;) De todas maneras, cuando cambies el FW, es importante que mires lo que se logea. El FW (iptables) es una facilidad de kernel, por lo que tendrás que configurar el syslog/syslog-ng para poder ver los mensajes del kernel.
Ahora es cuando me arrepiento, entre comillas, de usar tanto suse. Suse ya lo conozco. En otros linux en general, rh en particular, me cambian los ficheros de sitio, y no se si hasta el formato. No se ni donde están estos ficheros! (es todo distinto!) Vamos, que me va a tocar apuntarme a alguna lista de rh. Muchas gracias... -- Saludos, miguel