Problema con el cortafuegos en odoo 10
248 views
Skip to first unread message
Fernando Garcia Hansen - Humanoide
May 22, 2018, 5:35:23 AM5/22/18
to Usuarios Odoo / OpenERP en España
Hola,
Tengo el siguiente problema con el cortafuegos.
Tengo el odoo con un proxy inverso apache
Uso el cortafuegos que facilita el proveedor de VPS.
Le pongo que solo deje entrar puertos 22 y 443
No funciona.
Tengo que habilitar el 80 sinó no va.
El 80 esta redirigido en el fichero de configuracion de odoo
Jose R. Prieto
May 23, 2018, 6:05:24 AM5/23/18
to openerp-s...@googlegroups.com
Con todo mi respeto; esas son preguntas de sys, y no de Odoo.
Puertos en TCP, 80, 443, en la IP 217.182.142.40, para nginx; puerto 22 para SSH, para todas las IPs de la máquina (podría llegar a plantear problemas, mejor restringir a la IP / dominio que se quiera), y escuchando en local (127.0.0.1) MySQL, en puerto 3306 (en el estándar de MySQL).
Si nos ponemos a hablar en las listas de posibles configuraciones del stack base para Odoo (por que eso no es específico de Odoo, como podría ser montar un servidor de etherpad, libreoffice en headless, o cosas similares), podemos convertir la lista en un galimatías.
No obstante, para que no digáis que soy un "gruñón"...
El puerto 443 es de HTTPS por defecto; no recuerdo ahora mismo si lo cogía por defecto como HTTPS, o no; no obstante:
Básicamente, en la ocnfiguración de Apache, ha de aparecer alguna línea tipo a:
Listen 80
Listen 443
(opción no recomendable, así escucha en todas las interfaces de red / IPs de la máquina)
Mejor:
Listen xxx.yyy.zzz.ttt:80
Listen xxx.yyy.zzz.ttt:443
xxx.yyy.zzz.ttt = IP por la que Apache va a responder; si se quiere que responda a más de una ip, se añade línea correspondiente.
Para explícitamente indicar el protocolo del tráfico:
Listen xxx.yyy.zzz.ttt:443 https
En el vhost, hay que tener habilitado el SSLEngine, claro; algo similar a:
<VirtualHost 0.0.0.0:443>
ServerName the.server.name # dominio de respuesta principal
# config adicional..
SSLEngine On
SSLCertificateFile /the/certificate/file
SSLCertificateKeyFile /the/key/file
# config adicional..
</VirtualHost>
Para saber, desde línea de comandos, los puertos en escucha de la máquina, etc, puedes ejecutar:
$ sudo netstat -tupln
(o bien, si eres root, directamente: netstat -tupln)
Una salida "estándar" sería algo como:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 217.182.142.40:80 0.0.0.0:* LISTEN 32092/nginx: master
tcp 0 0 217.182.142.40:443 0.0.0.0:* LISTEN 32092/nginx: master
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1123/sshd
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 898/mysqld
tcp6 0 0 :::63431 :::* LISTEN 1123/sshd
udp 0 0 0.0.0.0:68 0.0.0.0:* 717/dhclient
udp 0 0 217.182.142.40:123 0.0.0.0:* 814/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 814/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 814/ntpd
udp6 0 0 fe80::f816:3eff:fe0:123 :::* 814/ntpd
udp6 0 0 ::1:123 :::* 814/ntpd
udp6 0 0 :::123 :::* 814/ntpd
```
Ahora, bien, está el Firewall de Linux; IPTables. Si es Debian, no debería usar "nada" por encima; si es Ubuntu, tienes ufw por encima.
En el caso de Debian, para ver qué reglas tienes activas en el Firewall:
iptables -L
Que puede devolver algo similar a:
Chain INPUT (policy ACCEPT)
target prot opt source destination
f2b-sshd tcp -- anywhere anywhere multiport dports ssh
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere loopback/8 reject-with icmp-port-unreachable
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:22
ACCEPT icmp -- anywhere anywhere icmp echo-request
LOG all -- anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: "
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain f2b-sshd (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
(El f2b-sshd son las reglas del fail2ban, firewall dinámico).
Has de tener el puerto tcp 443 (https) entre los que se aceptan (policy ACCEPT).
También útil, para testear la configuración de apache (y vhosts):
apachectl configtest
(apachectl o binario alternativo)
Una guía bastante clara, sobre Apache, SSL, y Let's Encrypt:
https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-debian-8
Por último, yo no usaría ningún Firewall del ISP, y usaría los servicios de la propia máquina; es más, utilizar fail2ban es algo básico, ya que cerrar puertos como estás indicando, es un firewall estático; que te vale para el primer chequeo que harán con un nmap o similar; pero después, una vez sepan cuales están abiertos, serán los que ataquen; y ahí es donde entra en juego fail2ban (entre otras herramientas).
Si quieres aislar totalmente esa máquina, monta un firewall propio en Linux, crea una DMZ, etc. Pero así te aseguras de tener el control tú, y no el ISP.
Otra opción es utilizar un cloud privado, al estilo del que tiene OVH:
Un saludo.
--
Has recibido este mensaje porque estás suscrito al grupo "Usuarios Odoo / OpenERP en España" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a openerp-spain-users+unsub...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Victor Daniel Witoszek
May 23, 2018, 6:34:47 AM5/23/18
to Usuarios Odoo / OpenERP en España
--
Has recibido este mensaje porque estás suscrito al grupo "Usuarios Odoo / OpenERP en España" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a openerp-spain-u...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages