Raspbian: proxy squid au travers de neorouteur (VPN)

Bonjour à tous.

Si je ne suis pas totalement novice s’agissant de linux, je suis plus habitué aux interfaces graphiques (suze, ubuntu et naturellement windows…).

Précisément, étant un nouvel utilisateur de raspbian (basé sur debian raison de mon inscription ici), uniquement en accès en ssh (car mon raspberry est utilisé en serveur web basique sans écran), je pêche sérieusement s’agissant de la difficulté suivante:

Je souhaite mettre en place un petit vpn et, au travers, accéder au serveur proxy installé sur le serveur VPN. L’objectif étant que toute machine sur le VPN puisse utiliser le proxy et donc mon IP française depuis l’étranger.

Pour l’anecdote avec neorouter (tout comme openvpn) j’y arrivais sans mal sous windows (mais je n’utilisais pas squid comme proxy).

S’agissant du VPN, en l’espèce neorouter le serveur est correctement installé sur le raspberry, auquel j’ai ajouté également un client neorouter, de sorte que je vois et je “pingue” sans difficulté l’ensemble des IP du VPN.

S’agissant du proxy, ici squid 2.7, il est également installé sur le serveur raspberry et fonctionne parfaitement s’agissant du réseau local “réel” puisque je peux surfer sur firefox en renseignant l’ip du serveur proxy et le port d’écoute dans les paramètres (passant iptable sans problème).

En revanche, si j’entre l’ip du serveur proxy dans le réseau VPN , cela ne fonctionne pas;
. un refus de connexion si j’entre l’ip du serveur neorouter dans le VPN,
. délai d’attente dépassé si j’entre l’ip du client neorouter installé sur le serveur

Pour faciliter la compréhension de mon fichier de configuration de squid je précise comment est mon réseau:
. raspbian:
ip locale fixe; 192.168.0.50 / 255.255.255.0
ip du serveur neorouter: 10.0.0.1 / 255.0.0.0
ip du client neorouter (installé également) : 10.0.0.7 / 255.0.0.0
. Ma machine locale:
ip locale fixe; 192.168.0.29
ip du client neorouter : 10.0.0.3/255.0.0.0

Voilà ma configuration de squid:

visible_hostname raspberrypi
acl all src all
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl localnet src 192.168.0.0/255.255.255.0      # RFC1918 possible internal network
acl netvpn src 10.0.0.0/255.0.0.0     # RFC1918 possible internal network
acl SSL_ports port 443          # https
acl SSL_ports port 563          # snews
acl SSL_ports port 873          # rsync
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl Safe_ports port 631         # cups
acl Safe_ports port 873         # rsync
acl Safe_ports port 901         # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access allow localhost
http_access allow netvpn
tcp_outgoing_address 192.168.0.0/255.255.255.0 localnet
tcp_outgoing_address 10.0.0.0/255.0.0.0 netvpn
http_access deny all
forwarded_for off
icp_access allow localnet
icp_access allow netvpn
http_port 3128

Pour info voila partie dédiée à SQUID dans iptable:

iptables -A INPUT -s 192.168.0.0/24 -p tcp --dport 3128 -j ACCEPT
iptables -A INPUT -p tcp --dport 3128 -j DROP

iptables -A OUTPUT -d 192.168.0.0/24 -p tcp --sport 3128 -J ACCEPT
iptables -A OUTPUT -p tcp --sport 3128 -j DROP

iptables -A INPUT -s 10.0.0.0/8 -p tcp --dport 3128 -j ACCEPT
iptables -A INPUT -p tcp --dport 3128 -j DROP

iptables -A OUTPUT -d 10.0.0.0/8 -p tcp --sport 3128 -J ACCEPT
iptables -A OUTPUT -p tcp --sport 3128 -j DROP

Et toujours dans iptable, celle s’agissant de neorouter:

iptables -t filter -A INPUT -p tcp --dport 1196 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 1196 -j ACCEPT

Votre aide est donc la bienvenue, car même en commentant deny all et !safe_ports, rien n’y fait.

Merci :slight_smile:

iptables -A INPUT -p tcp --dport 3128 -j DROP
iptables -A INPUT -s 10.0.0.0/8 -p tcp --dport 3128 -j ACCEPT

iptables -A OUTPUT -p tcp --sport 3128 -j DROP
iptables -A OUTPUT -d 10.0.0.0/8 -p tcp --sport 3128 -J ACCEPT

Il n’y a rien qui te choque dans ces deux séquences de règles ?

J’aimerai te répondre que oui mais j’ai vraiment du mal avec iptable (que je gère habituellement via une petite interface, mais pas là voulant préserver les ressources du Pi), surtout qu’il s’agit de la même séquence que celle du réseau 192.168.0.0/24 qui passe puisque j’accède au proxy sans problème sur le réseau local “réel”.

Si tu peux me mettre sur la voie ça serait sympa :slight_smile:

iptables -A INPUT -p tcp --dport 3128 -j DROP

bloque tous les paquets TCP entrants destinés au port 3128.

iptables -A INPUT -s 10.0.0.0/8 -p tcp --dport 3128 -j ACCEPT

est au chômage technique puisque tous les paquets qu’elle pourrait accepter ont déjà été bloqués par la règle précédente.

Un jeu de règles iptables doit toujours être pensé comme un ensemble cohérent, pas une simple juxtaposition de règles ou de blocs de règles, surtout quand on combine DROP et ACCEPT.

Merci pour ta patience, mais si je comprends ce que tu veux dire, je semble encore faire une erreur puisqu’en retirant les lignes DROP sur 10.0.0.0/8 et 192.168.0.0/24 , j’ai maintenant “La connexion a été refusée par le serveur proxy”, là où elle passait (étrangement) sur 192.168 (et où était affichait “délai d’attente trop long” sur 10.0).

Si tu veux bien m’aider, car je n’aime pas comprendre pourquoi ça cloche.

Je me permets de reproduire l’ensemble de mon iptable (qui est court):

# Suppression des règles antérieures
iptables -t filter -F
iptables -t filter -X

# On laisse tout sortir et on bloque tout en entrée
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT

# On conserve les connexions déjà établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# On autorise le loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

# Serveur HTTP (80)
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT

# Serveur NEOROUTER (1196)
iptables -t filter -A INPUT -p tcp --dport 1196 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 1196 -j ACCEPT

# Serveur SQUID (3128)
# # iptables -A INPUT -p tcp --dport 3128 -j DROP
iptables -A INPUT -s 192.168.0.0/24 -p tcp --dport 3128 -j ACCEPT
iptables -A INPUT -s 10.0.0.0/8 -p tcp --dport 3128 -j ACCEPT

# # iptables -A OUTPUT -p tcp --sport 3128 -j DROP
iptables -A OUTPUT -d 192.168.0.0/24 -p tcp --sport 3128 -J ACCEPT
iptables -A OUTPUT -d 10.0.0.0/8 -p tcp --sport 3128 -J ACCEPT

# Serveur FTP (21) dont mode passif
modprobe ip_conntrack_ftp
iptables -t filter -A OUTPUT -p tcp --dport 20:21 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 20:21 -j ACCEPT
iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Connexionx SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

# Autorisation du PING :
iptables -A INPUT -p icmp -m limit --limit 15/minute -j ACCEPT
iptables -A INPUT -p icmp -j DROP

# Bloquer les attaques par déni de service
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT

# Bloquer les scans de ports
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Merci encore :slight_smile:

Pas terrible. Un certain nombre d’inohérences et d’erreurs. Néanmoins ce n’est pas iptables qui provoque le refus de connexion, car seule la cible REJECT peut causer cette erreur et tes règles ne l’utilisent pas.

squid : écoute-t-il bien sur l’adresse que tu vises, ou sur toutes les adresses locales ?

ss -ntl | grep 3128

neorouteur : je ne connais pas ce VPN. Pourquoi as-tu besoin de faire tourner un client VPN sur la même machine que le serveur VPN ?
Peux-tu monter la sortie des commandes suivantes sur les deux machines lorsque le client est connecté ?

ip addr
ip route

J’ai désinstallé squid 2.7 (proprement) pour installer squid3 avec un fichier conf. lisible.

Pour être précis, voilà le retour de ifconfig:

eth0      Link encap:Ethernet  HWaddr b8:27:eb:a1:8d:a6
          inet addr:192.168.0.50  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::63e3:e0b6:6ebb:9ac8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4652 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4643 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1278179 (1.2 MiB)  TX bytes:1726701 (1.6 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

nrtap     Link encap:Ethernet  HWaddr 5a:5a:2c:cb:3c:6c
          inet addr:10.0.0.7  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::585a:2cff:fecb:3c6c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1300  Metric:1
          RX packets:1009 errors:0 dropped:0 overruns:0 frame:0
          TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:293995 (287.1 KiB)  TX bytes:11025 (10.7 KiB)

Liste des services:

service --status-all
 [ + ]  alsa-utils
 [ + ]  avahi-daemon
 [ - ]  bluetooth
 [ - ]  bootlogs
 [ - ]  bootmisc..sh
 [ - ]  checkfs..sh
 [ - ]  checkroot-bootclean..sh
 [ - ]  checkroot..sh
 [ + ]  console-setup
 [ + ]  cron
 [ + ]  dbus
 [ + ]  dhcpcd
 [ + ]  dphys-swapfile
 [ + ]  fake-hwclock
 [ - ]  firewall
 [ - ]  firewall.save
 [ - ]  hostname..sh
 [ - ]  hwclock..sh
 [ + ]  kbd
 [ + ]  keyboard-setup
 [ - ]  killprocs
 [ + ]  kmod
 [ - ]  motd
 [ - ]  mountall-bootclean..sh
 [ - ]  mountall..sh
 [ - ]  mountdevsubfs..sh
 [ - ]  mountkernfs..sh
 [ - ]  mountnfs-bootclean..sh
 [ - ]  mountnfs..sh
 [ + ]  networking
 [ - ]  nfs-common
 [ + ]  nginx
 [ + ]  nrserver..sh
 [ + ]  nrservice..sh
 [ + ]  ntp
 [ + ]  php5-fpm
 [ - ]  plymouth
 [ - ]  plymouth-log
 [ + ]  procps
 [ + ]  raspi-config
 [ + ]  rc.local
 [ - ]  rmnologin
 [ - ]  rpcbind
 [ + ]  rsyslog
 [ - ]  sendsigs
 [ + ]  squid3
 [ + ]  ssh
 [ - ]  sudo
 [ + ]  triggerhappy
 [ + ]  udev
 [ + ]  udev-finish
 [ - ]  umountfs
 [ - ]  umountnfs..sh
 [ - ]  umountroot
 [ + ]  urandom

Les grep:

ps aux | grep squid
pi        1762  1.0  0.4   4264  1952 pts/0    S+   14:02   0:00 grep --color=auto squid
sudo netstat -atup | grep LISTEN
tcp        0      0 *:1196                  *:*                     LISTEN      436/nrserver
tcp        0      0 localhost:32975         *:*                     LISTEN      444/nrservice
tcp        0      0 *:http                  *:*                     LISTEN      692/nginx -g daemon
tcp        0      0 *:ssh                   *:*                     LISTEN      672/sshd
tcp6       0      0 [::]:http               [::]:*                  LISTEN      692/nginx -g daemon
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      672/sshd

Sauf erreur de ma part, squid n’écoute pas sur le port 3128 (même après un reboot ou sudo service squid3 start)

ipp addr:

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:a1:8d:a6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.50/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::63e3:e0b6:6ebb:9ac8/64 scope link
       valid_lft forever preferred_lft forever
3: nrtap: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1300 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 5a:5a:2c:cb:3c:6c brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.7/24 brd 10.0.0.255 scope global nrtap
       valid_lft forever preferred_lft forever
    inet 169.254.114.100/16 brd 169.254.255.255 scope global nrtap
       valid_lft forever preferred_lft forever
    inet6 fe80::585a:2cff:fecb:3c6c/64 scope link
       valid_lft forever preferred_lft forever

Et ip route:

ip route
default via 192.168.0.254 dev eth0  metric 202
10.0.0.0/24 dev nrtap  proto kernel  scope link  src 10.0.0.7
169.254.0.0/16 dev nrtap  proto kernel  scope link  src 169.254.114.100  metric 203
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.50  metric 202

Pour info, voilà l’actuel fichier conf de squid3:

# Autoriser son réseau local dans les ALC avec la ligne ci-dessous :
acl localnet src 192.168.0.0/24 # (à adapter en fonction de votre adressage réseau)
acl localnet src 10.0.0.0/8 # (à adapter en fonction de votre adressage réseau)

acl SSL_ports port 443      # https
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT

http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

http_access allow localnet # Autorise les machines de votre réseau à accéder au Proxy
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 3128 # Déclaration du port d'écoute de Squid (3128 par défaut mais peut être changé ici)

#  TAG: visible_hostname
visible_hostname raspberrypi

# Add any of your own refresh_pattern entries above these.

refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320

# Les valeurs off et deny all servent à masquer les adresses IP locales dans les requêtes HTTP
# Un peu de confidentialité ne peut jamais faire de mal
#via off
forwarded_for off
#follow_x_forwarded_for deny all
#request_header_access X-Forwarded-For deny all
#header_access X_Forwarded_For deny all

Pour répondre à ta question, j’utilise neorouter car les clients sont gratuitement installables sur les tablettes et smartphones sans être root.

Le serveur neorouter est en principe invisible des clients, c’est pourquoi si on veut accéder à la machine serveur depuis un client, ils indiquent d’installer un client sur la machine serveur en plus. (cette configuration fonctionnait sous windows, je tente de la reproduire sous raspbian. Je ne pense pas que le VPN soit en cause car je peux pinguer tout le monde, prendre le controle en vnc etc…, l’os doit venir se squid. S’il y a plus simple que ce dernier je suis d’ailleurs preneur).

Au regard des infos que tu commandes que tu m’as donné, je note que squid est actif mais ne semble pas écouter sur le port 3128 (et même tout court).

Merci encore :slight_smile:

Edit: et malgré l’installation de squid3 j’ai toujours le message de refus de connexion.

(ps: j’ai édité les .sh en …sh , le forum les prend pour des liens m’interdisant de poster plus de 2 liens par message…)

Eureka!

En recopiant une ligne d’un exemple de configuration trouvée sur le net, je n’avais pas fait attention que les parenthèses bloquaient la bonne exécution de squid.

Je n’avais aucune erreur au lancement, mais uniquement en vidant la cache via sudo squid3 -z , m’indiquant que la ligne ne se terminait pas correctement, j’ai viré les commentaires dont les parenthèses (et dans le doute les caractères accentués), ajouté l’ip découpe en plus du port et relancé squid et cela fonctionne je poste depuis le proxy là :slightly_smiling_face:

Pour info le fichier conf est le suivant:

acl localnet src 192.168.0.0/24
acl localnet src 10.0.0.0/8

acl SSL_ports port 443      # https
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT

http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

http_access allow localnet
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 10.0.0.7:3128

#  TAG: visible_hostname
visible_hostname raspberrypi

# Add any of your own refresh_pattern entries above these.

refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320

#via off
forwarded_for off

Si tu as par ailleurs quelques astuces pour améliorer mon iptable, je suis preneur :slight_smile:

Je vais pointer quelques maladresses et préciser quelques points.

# Serveur HTTP (80)
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT

La première règle ne sert que si la machine est un serveur web qui reçoit des connexions HTTP de clients.
La seconde règle ne sert que si la machine est un client HTTP qui se connecte à des serveurs web, ce qui est généralement le cas au moins pour télécharger les mises à jour de paquets. Dans ton script est est superflue car la politique par défaut de la chaîne OUTPUT est réglée à ACCEPT.

La même remarque s’applique aux autres protocoles applicatifs (Neorouter, Squid proxy, FTP…), je ne vais pas la répéter pour chacun.

# Serveur FTP (21) dont mode passif
modprobe ip_conntrack_ftp
iptables -t filter -A OUTPUT -p tcp --dport 20:21 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 20:21 -j ACCEPT
iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Les règles iptables pour le protocole FTP sont souvent un grand moment à lire, on y retrouve souvent les mêmes erreurs.

  • Le module a été renommé “nf_conntrack_ftp” depuis longtemps. Le nom “ip_conntrack_ftp” fonctionne toujours avec modprobe car il a été défini comme alias, mais cela pourrait ne pas durer éternellement et peut causer de la confusion si un jour tu cherches ce module dans /lib/modules/.

  • Le port 20 n’est pas utilisé comme le port 21. Ce n’est pas un port sur lequel le serveur écoute et auquel le client se connecte, mais un port à partir duquel le serveur se connecte au client, lors d’un transfert de données en mode actif.

  • Avec les noyaux récents, par défaut les connexions de données FTP n’ont plus automatiquement l’état RELATED. Il faut ajouter une règle iptables spécifique avec la cible CT pour signaler les connexions de commande qui doivent être surveillées par le module de suivi de connexion FTP.

.

# Connexionx SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Vouloir limiter ainsi les connexions SSH est à mon avis une mauvaise idée. D’une part un attaquant peut exploiter ces règles pour provoquer un déni de service contre les utilisateurs légitimes. D’autre part on peut assez facilement se bloquer soi-même à cause de ses règles. Notamment si on utilise scp pour copier un ensemble de fichiers.
Il n’y a pas de raison de limiter les connexions SSH de cette façon s’il ne s’agit pas d’échecs d’authentification répétés, ce qu’iptables ne peut pas détecter. Une meilleure approche consiste à bloquer les sources abusives avec des outils comme fail2ban qui se basent sur les échecs d’authentification.

# Autorisation du PING :
iptables -A INPUT -p icmp -m limit --limit 15/minute -j ACCEPT
iptables -A INPUT -p icmp -j DROP

Encore une confusion classique. ICMP, ce n’est pas seulement le ping. Le ping, c’est le type “echo-request” pour la requête et “echo-reply” pour la réponse.

# Bloquer les attaques par déni de service
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT

Les règles de la chaîne FORWARD ne traitent que les paquets qui traversent la machine, pas ceux qui lui sont destinés ou qu’elle émet, et ne servent strictement à rien si la machine ne fonctionne pas en routeur.

D’autre part ces règles autorisent les connexions sur n’importe quel port donc telles quelles elles sont incompatibles avec un jeu de règles qui a pour ambition d’autoriser les connexions uniquement sur des ports donnés.

# Bloquer les scans de ports
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

L’exemple type de la règle idiote qui ne bloque pas “les scans de ports” mais ne fait que ralentir un type particulier de scan de port, et qui peut bloquer des paquets légitimes. Enfin, au lieu de dire “bloque” je devrais plutôt dire “n’accepte pas” puisque la cible est ACCEPT.

EDIT : je n’avais pas regardé les drapeaux TCP assez attentivement ; cette combinaison est invalide car RST doit être accompagné par ACK. Donc pas de risque de bloquer des paquets légitimes ici. Par contre la limite à 1/s n’a pas lieu d’être, tous ces paquets invalides devraient être bloqués.

Un jeu de règles iptables n’est pas une simple juxtaposition de règles qui font quelque chose chacune prise indépendamment des autres. Ce doit être un enemble cohérent. Les règles “anti-scan/déni/etc” doivent être adaptées pour s’intégrer au jeu de règles dans sa globalité. Il faut traduire le cahier des charges sous une forme qui permet d’écrire le jeu de règles.

Exemple simplifié de cahier des charges :

  • autoriser les connexions sur le port X

  • limiter les connexions à N par seconde

Le résultat ne doit pas être une règle qui autorise les connexions sur le port X et une règle qui autorise N connexions par seconde indépendamment l’une de l’autre, car l’objectif ne serait pas atteint : la première règle ne limiterait pas les connexions, et la seconde autoriserait des connexions sur d’autres ports. De bonnes approches peuvent être par exemple :

  • une règle qui combine les deux conditions

  • une première règle qui bloque si une condition n’est pas remplie et une seconde règle qui accepte si l’autre condition est remplie

  • une première règle qui renvoie dans une chaîne utilisateur si une condition est remplie, et une seconde règle dans la chaîne utilisateur qui autorise si la seconde condition est remplie

Nickel merci beaucoup, enfin des explications simples et concises s’agissant d’iptables :slight_smile:

Je vais regarder ça dans le détail (peut être m’aider de webmin même si certains n’aiment pas ça), étant précisé que pour l’instant les risques sont limités puisque de l’extérieur le raspberry n’est accessible que via le port du serveur VPN (pouvant néanmoins craindre une attaque depuis un des clients du VPN).

J’ai édité mon message précédent pour corriger une erreur de ma part dans un commentaire sur une de tes règles.