Puse reglas en el firewall pero ¿están bien todas? Puerto 80, 443, 22 — ¿qué más debo cerrar?

no abras la mierda del puerto 22 de ssh cambia el puerto a 2222 o algo así. pero instala fail2ban igualmente. si no tienes correo no abras smtp/imap para nada. deja solo abiertos 80, 443, 2222, el resto cerrado...

Comandos de UFW: ufw default deny incoming, ufw allow 80/tcp, ufw allow 443/tcp, ufw limit 2222/tcp (limitación de tasa para SSH), ufw deny 3306/tcp (bloquear MySQL externo). Verificar: ufw status numbered. Activar registro: ufw logging on, level medium. Config de SSH (/etc/ssh/sshd_config): Port 2222, PermitRootLogin no, PubkeyAuthentication yes, PasswordAuthentication no (basado en claves). Reiniciar: systemctl restart sshd. Comunicación interna: reglas de iptables o grupos de seguridad (a nivel de proveedor cloud).

la instalación más simple: cierra el puerto 22 a internet, ábrelo solo desde la IP de la oficina. o cambia el puerto ponllo en 2222. no abras nunca el puerto 3306 de MySQL solo localhost... hTTP y HTTPS normal, no abras nada más. eso es todo, termina el trabajo fácil.

Niveles de firewall: Perímetro (nivel ISP), Red (firewall del router), Host (firewall basado en host). Para el servidor web: Firewall de host (UFW) + Grupo de seguridad cloud (si es cloud). Acceso SSH: Bastion host detrás de una VPN, o en lista blanca de IPs. Acceso a la base de datos: Solo red interna, nunca externa. Registro de todos los paquetes rechazados — la integración con SIEM es ideal. Limitación de tasa para SSH + protección contra inundación TCP SYN.

Puerto 22 abierto = estás invitando a hackers 😂 Cambia el puerto instala fail2ban y listo, se acabó... ¿Puertos de correo? Si no son necesarios, los cierras, ¿para qué los vas a abrir...

Tiene razón. Los cambios en los datos de pago nunca se verifican por el mismo canal por el que llegan.

Si es la primera vez que lo hacéis, empezad poco a poco, la escala llegará después. Por supuesto, cambia si tu situación es diferente.

entrando en detalle: Ningún proceso mejora si no se registran datos porque no sabes qué tienes que arreglar.

ánimo.

me pasó lo mismo.

Estoy de acuerdo a medias, en parte no. Si intentas cambiarlo todo a la vez, nada termina de asentarse.

Los primeros tres meses todo va bien, los problemas aparecen en el cuarto. Si escribís el resultado aquí, también servirá de ayuda a otros.

el año pasado nos pasó casi exactamente lo mismo. lo que más tiempo nos hacía perder era no saber quién tomaba las decisiones.

si el permiso y el alcance no están por escrito, que no empiece la prueba pero por supuesto, cambia si tu situación es diferente.

Estoy de acuerdo. La seguridad no es absoluta; significa hacer que el ataque no merezca la pena.

Por supuesto cambia si tu situación es diferente.

Me pasó lo mismo. la verdad si es la primera vez que lo hacéis empezad poco a poco, la escala llegará después.

Yo seguiría por ese camino.

Hace mucho que oímos eso, pero a nosotros nunca nos pasó así. Los cambios en los datos de pago nunca se verifican por el mismo canal por el que llegan.

La mayoría de los incidentes no empiezan por una vulnerabilidad, sino por una contraseña filtrada. Yo seguiría por ese camino.

Tomo nota, gracias.

Yo pasé por esto déjenme contarlo... Si la verificación en dos pasos está activa, una contraseña robada no sirve de nada por sí sola.

Si el camino de la notificación es largo, la notificación no llega; una notificación que no llega significa un incidente detectado tarde. Yo seguiría por ese camino.

Permíteme resumir lo que se ha dicho hasta ahora. Lo que más tiempo nos hacía perder era no saber quién tomaba las decisiones.

Una copia de seguridad no probada no es una copia de seguridad. Por supuesto, cambia si tu situación es diferente.

Lo probaré.

Yo pasé por esto, déjenme contarlo. Tomar notas durante dos semanas da mejores resultados que estimar seis meses.

Ningún proceso mejora si no se registran datos, porque no sabes qué tienes que arreglar. También me gustaría saber si alguien lo hace de otra manera.