| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente Prochaine révisionLes deux révisions suivantes |
| technique:adminsys:secu:firewall [2021/09/06 17:34] – qduchemi | technique:adminsys:secu:firewall [2023/06/10 19:01] – qduchemi |
|---|
| {{indexmenu_n>10}} | {{indexmenu_n>10}} |
| # Pare-feu | # Filtrer le trafic autorisé : pare-feu |
| |
| Pour filtrer les accès au strict minimum sur les machines de Picasoft, on utilise un firewall. | Pour filtrer les accès au strict minimum sur les machines de Picasoft, on utilise un firewall. |
| |
| ## Firewall basique avec ufw | ## Firewall basique avec ufw |
| | |
| | <bootnote> |
| | Sur Debian 11, `iptables` est disponibles en deux versions : une moderne (nft) et une ancienne (legacy). La version moderne n'est plus compatible avec `ufw`, qui construit des règles `iptables`. |
| | |
| | Beaucoup de gens critiquent `ufw`, et à raison. En revanche, pour ce qu'on en fait, et pour simplifier l'administration système et l'intégration des nouvelles personnes dans l'équipe technique, on décide de garder un système de pare-feu simple et homogène. Il faut donc utiliser l'ancienne version. |
| | |
| | Exécuter la commande : |
| | |
| | ``` |
| | update-alternatives --set iptables /usr/sbin/iptables-legacy |
| | ``` |
| | |
| | sur les machines qui font tourner Debian 11 pour utiliser l'ancienne version d'`iptables`. |
| | </bootnote> |
| |
| ### Installation | ### Installation |
| <bootnote warning>Remarquer que l'on n'ouvre pas les accès aux ports 80/443, parce que les services web de Picasoft sont derrière un conteneur Docker, [[technique:docker:general:traefik|Traefik]]. `ufw` n'est donc pas en mesure de filtrer les paquets à destination d'un conteneur Docker.</bootnote> | <bootnote warning>Remarquer que l'on n'ouvre pas les accès aux ports 80/443, parce que les services web de Picasoft sont derrière un conteneur Docker, [[technique:docker:general:traefik|Traefik]]. `ufw` n'est donc pas en mesure de filtrer les paquets à destination d'un conteneur Docker.</bootnote> |
| |
| ## Configuration (hyperviseurs) | ### Configuration (hyperviseurs) |
| |
| Sur la plupart des machines, l'idée va être d'autoriser uniquement les accès aux ports SSH, DNS et Proxmox. On pourra ouvrir d'autres ports si nécessaires, mais ça ne devrait pas arriver trop souvent, les services tournant sur les machines virtuelles. | Sur la plupart des machines, l'idée va être d'autoriser uniquement les accès aux ports SSH, DNS et Proxmox. On pourra ouvrir d'autres ports si nécessaires, mais ça ne devrait pas arriver trop souvent, les services tournant sur les machines virtuelles. |
| <bootnote warning>La plupart des règles sont en IPv4 **et** en IPv6, il faut faire deux fois l'opération, en commençant par le numéro le plus haut pour éviter les erreurs.</bootnote> | <bootnote warning>La plupart des règles sont en IPv4 **et** en IPv6, il faut faire deux fois l'opération, en commençant par le numéro le plus haut pour éviter les erreurs.</bootnote> |
| |
| ### Filtrage IP vers Docker | ## Filtrage IP vers Docker |
| |
| [[technique:adminsys:secu:fail2ban|fail2ban]] s'occupe déjà de bannir les adresses IP qui essayent de se connecter trop de fois en SSH. Mais l'analyse de logs est compliquée, et parfois certaines IP vont consulter de manière répétée des URL inexistantes sur nos services, essayer de forcer les connexions... Difficile de déterminer l'origine de ces comportements, mais lorsqu'ils sont répétés et viennent de la même IP, il peut être pertinent de bloquer les IP. | [[technique:adminsys:secu:fail2ban|fail2ban]] s'occupe déjà de bannir les adresses IP qui essayent de se connecter trop de fois en SSH. Mais l'analyse de logs est compliquée, et parfois certaines IP vont consulter de manière répétée des URL inexistantes sur nos services, essayer de forcer les connexions... Difficile de déterminer l'origine de ces comportements, mais lorsqu'ils sont répétés et viennent de la même IP, il peut être pertinent de bloquer les IP. |