Je ne sais pas comment utiliser le logiciel de pare-feu Linux IPtables ! Quel genre de personne chargée de l'exploitation et de la maintenance êtes-vous ?
Le suivi des connexions est la base de nombreuses applications Web. Par exemple, le service Kubernetes, le side-car ServiceMesh, l'équilibreur de charge logiciel à quatre couches LVS/IPVS, le réseau Docker, OVS, le pare-feu hôte iptables, etc., reposent tous sur la fonction de suivi des connexions. Le suivi de connexion, comme son nom l'indique, consiste à suivre (et enregistrer) l'état de la connexion. Par exemple, la figure 1.1 est une machine Linux avec une adresse IP de 10.1.1.2. Nous pouvons voir qu'il y a trois connexions sur cette machine :
La connexion pour que la machine accède au service HTTP externe (destination). port 80)
La connexion de la machine d'accès externe au service FTP (port de destination 21)
La connexion de la machine au service DNS externe (port de destination 53)
Le suivi des connexions permet de découvrir et de suivre l'état de ces connexions :
Extraire les informations de tuple du paquet de données, identifier le flux de données (flux) et la connexion correspondante (connexion).
Maintenir une base de données d'état (table conntrack) pour toutes les connexions, comme l'heure de création de la connexion, le nombre de paquets envoyés, le nombre d'octets envoyés, etc.
Recyclez les connexions expirées (GC).
Fournir des services pour les fonctions de niveau supérieur (telles que NAT).
Il est à noter que la notion de « connexion » dans le suivi de connexion n'est pas exactement la même que la notion « orienté connexion » dans le protocole TCP/IP Pour faire simple :
In. le protocole TCP/IP, la connexion est un concept de couche 4. TCP est orienté connexion et tous les paquets envoyés nécessitent une réponse (ACK) de la part du homologue, et il existe un mécanisme de retransmission. UDP est sans connexion, les paquets envoyés ne nécessitent pas de réponse de la part du homologue et il n'existe aucun mécanisme de retransmission. Dans
conntrack(CT), un flux de données (flow) défini par un tuple (tuple) représente une connexion (connection). Nous verrons plus tard que les protocoles à trois couches tels que UDP et même ICMP ont également des enregistrements de connexion dans CT, mais tous les protocoles ne seront pas connectés.
Netfilter
Le suivi des connexions Linux est implémenté dans Netfilter. Netfilter est un framework du noyau Linux permettant de contrôler, modifier et filtrer les paquets de données (manipulation et filtrage). Il définit plusieurs points d'ancrage dans la pile de protocoles du noyau pour intercepter, filtrer ou traiter les paquets de données.Maintenant, lorsque le suivi des connexions (conntrack) est mentionné, Netfilter peut d'abord venir à l'esprit. Netfilter n'est qu'une implémentation de suivi des connexions dans le noyau Linux. En d'autres termes, tant que vous disposez de la capacité de hook et que vous pouvez intercepter chaque paquet entrant et sortant de l'hôte, vous pouvez implémenter vous-même un ensemble de suivi de connexion sur cette base. La solution réseau cloud native Cilium a implémenté un tel mécanisme indépendant de suivi des connexions et de NAT dans la version 1.7.4+ (la fonctionnalité complète nécessite le noyau 4.19+). Le principe de base est le suivant :
Implémenter une fonction d'interception de paquets basée sur le hook BPF (équivalent au mécanisme de hook dans netfilter)
Basé sur le hook BPF, implémenter un nouvel ensemble de conntrack et NAT Par conséquent, même si Netfilter est désinstallé, cela n'affectera pas la prise en charge par Cilium de fonctions telles que Kubernetes ClusterIP, NodePort, ExternalIPs et LoadBalancer. Étant donné que ce mécanisme de suivi des connexions est indépendant de Netfilter, ses informations de connexion et NAT ne sont pas stockées dans la table de connexion et la table NAT du noyau (c'est-à-dire Netfilter).Par conséquent, conntrack/netstats/ss/lsof et d'autres outils ne peuvent pas être vus. Vous devez utiliser les commandes Cilium, telles que :
$ cilium bpf nat list$ cilium bpf ct list global
Iptables
Iptables est un outil d'espace utilisateur pour configurer le filtrage Netfilter. fonction. Netfilter est le véritable cadre de sécurité du pare-feu, et netfilter est situé dans l'espace noyau. iptables est en fait un outil de ligne de commande situé dans l'espace utilisateur. Nous utilisons cet outil pour faire fonctionner le vrai framework. Iptable traite les paquets de données selon les méthodes définies par des règles, telles que l'acceptation, le rejet, l'abandon, etc. Par exemple, lorsque le client accède au service Web du serveur, le client envoie un message à la carte réseau, et la pile de protocole tcp/ip fait partie du noyau. Par conséquent, les informations du client seront transmises à l'utilisateur. espace via le protocole TCP du noyau. Dans le service Web, à ce stade, le point de terminaison cible du message client est le socket (IP:Port) surveillé par le service Web. Lorsque le service Web doit répondre à la demande du client, le. message de réponse envoyé par le service Web Le point final cible est le client. À ce stade, l'adresse IP et le port surveillés par le service Web deviennent l'origine. Nous avons dit que netfilter est le véritable pare-feu et qu'il fait donc partie du noyau. , si nous voulons que le pare-feu puisse atteindre l'objectif de "prévention des incendies", vous devez configurer des points de contrôle dans le noyau. Tous les messages entrants et sortants doivent passer par ces points de contrôle, uniquement ceux qui remplissent les conditions de publication. peuvent être libérés, et ceux qui remplissent les conditions de blocage doivent être bloqués. iptables contient 4 tables et 5 chaînes. La table se distingue selon l'opération sur le paquet de données (filtrage, NAT, etc.), et la chaîne se distingue selon différents points de Hook La table et la chaîne sont en fait les deux dimensions de netfilter.Les quatre tables d'iptables sont filter, mangle, nat et raw. La table par défaut est filter.
table de filtrage : utilisée pour filtrer les paquets de données. Les exigences de règles spécifiques déterminent comment traiter un paquet de données.
Table nat : Principalement utilisée pour modifier les informations sur l'adresse IP et le numéro de port des paquets de données.
table mangle : principalement utilisée pour modifier le type de service et le cycle de vie des paquets de données, définir des balises pour les paquets de données, mettre en œuvre la mise en forme du trafic, le routage des politiques, etc.
table brute : principalement utilisée pour décider d'effectuer ou non un suivi de l'état des paquets de données.
Les cinq chaînes d'iptables sont PREROUTING, INPUT, FORWARD, OUTPUT et POSTROUTING.
chaîne d'entrée : Lorsqu'un paquet accédant à l'adresse locale est reçu, les règles de cette chaîne seront appliquées.
chaîne de sortie : lorsque la machine envoie un paquet, les règles de cette chaîne seront appliquées.
chaîne de transfert : lors de la réception d'un paquet de données qui doit être transféré vers d'autres adresses, les règles de cette chaîne seront appliquées. Notez que si vous devez implémenter le transfert de données, vous devez activer la fonction ip_forward dans. le noyau Linux.
chaîne de préroutage : Les règles de cette chaîne seront appliquées avant le routage du paquet.
chaîne de postroutage : Après avoir acheminé le paquet, les règles de cette chaîne seront appliquées.
La relation correspondante entre la table et la chaîne est illustrée dans la figure ci-dessous : Nous pouvons imaginer le flux de messages dans certains scénarios courants :
Messages destinés à un certain processus sur la machine locale : PREROUTING –>
Messages transmis par cette machine : PREROUTING –> FORWARD –>
Un message (généralement un message de réponse) envoyé par un processus sur la machine locale : OUTPUT –>
Nous pouvons résumer le processus de passage des paquets de données à travers le pare-feu comme suit :
Règles de requête
-t : Nom de la table
-n : Ne pas résoudre Adresse IP
-v : Affichera les informations du compteur, le nombre et la taille des paquets
-x : L'option indique d'afficher la valeur exacte du compteur
--line-numbers : Le numéro de série de la règle d'affichage (en abrégé --line)
De plus, lors de la recherche du compte public Linux, c'est ainsi que vous devez apprendre à répondre "singe" dans le fond et recevez un paquet cadeau surprise.
当我们通过 http 的 url 访问某个网站的网页时,客户端向服务端的 80 端口发起请求,服务端再通过 80 端口响应我们的请求,于是,作为客户端,我们似乎应该理所应当的放行 80 端口,以便服务端回应我们的报文可以进入客户端主机,于是,我们在客户端放行了 80 端口,同理,当我们通过 ssh 工具远程连接到某台服务器时,客户端向服务端的 22 号端口发起请求,服务端再通过 22 号端口响应我们的请求,于是我们理所应当的放行了所有 22 号端口,以便远程主机的响应请求能够通过防火墙,但是,作为客户端,如果我们并没有主动向 80 端口发起请求,也没有主动向 22 号端口发起请求,那么其他主机通过 80 端口或者 22 号端口向我们发送数据时,我们可以接收到吗?应该是可以的,因为我们为了收到 http 与 ssh 的响应报文,已经放行了 80 端口与 22 号端口,所以,不管是”响应”我们的报文,还是”主动发送”给我们的报文,应该都是可以通过这两个端口的,那么仔细想想,这样是不是不太安全呢?此时 state 扩展模块就派上用场了。Pour la connexion du module d'état, les messages dans la "connexion" peuvent être divisés en 5 états, qui sont :
NEW : Le premier paquet dans la connexion, l'état est NEW, nous On comprend que l'état du premier paquet de la nouvelle connexion est NEW.
ESTABLISHED : Nous pouvons comprendre l'état du paquet après le NOUVEAU paquet d'état comme ESTABLISHED, indiquant que la connexion a été établie.
RELATED : Littéralement compris, RELATED se traduit par relation, mais ce n'est toujours pas facile à comprendre. Donnons un exemple. Par exemple, dans le service FTP, le serveur FTP créera deux processus, un processus de commande et un processus de données. Le processus de commande est responsable de la transmission des commandes entre le serveur et le client (on peut comprendre ce processus de transmission comme un état dit de « connexion », temporairement appelé « connexion de commande »). Le processus de données est responsable de la transmission des données entre le serveur et le client (nous appelons temporairement ce processus « connexion de données »). Cependant, les données spécifiques à transmettre sont contrôlées par la commande. Par conséquent, les messages dans la « connexion de données » sont « liés » à la « connexion de commande ». Ensuite, les paquets dans la « connexion de données » peuvent être dans l'état RELATED, car ces paquets sont liés aux paquets dans la « connexion de commande ». (Remarque : si vous souhaitez effectuer un suivi de connexion pour FTP, vous devez charger le module de noyau correspondant nf_conntrack_ftp séparément. Si vous souhaitez le charger automatiquement, vous pouvez configurer le fichier /etc/sysconfig/iptables-config)
INVALIDE : si un paquet n'a aucun moyen de l'identifier, ou si le paquet n'a aucun statut, alors le statut de ce paquet est INVALIDE. Nous pouvons bloquer activement les paquets avec le statut INVALIDE.
UNTRACKED : lorsque l'état du paquet est non suivi, cela signifie que le paquet n'a pas été suivi. Lorsque l'état du paquet est non suivi, cela signifie généralement que la connexion correspondante est introuvable.
刚才举例中的问题即可使用 state 扩展模块解决,我们只要放行状态为 ESTABLISHED 的报文即可,因为如果报文的状态为 ESTABLISHED,那么报文肯定是之前发出的报文的回应,这样,就表示只有回应我们的报文能够通过防火墙,如果是别人主动发送过来的新的报文,则无法通过防火墙:
iptables -t filter -I INPUT -m state --state ESTABLISHED -j ACCEPT
Lorsqu'il y a trop de règles dans la chaîne par défaut, il n'est pas pratique pour nous de gérer. Imaginez s'il y a 200 règles stockées dans la chaîne INPUT. Certaines de ces 200 règles sont destinées au service httpd, d'autres au service sshd, d'autres au réseau IP privé et d'autres au réseau IP public. les règles liées au service httpd, faut-il lire ces 200 règles depuis le début pour savoir quelles règles sont spécifiques à httpd ? C'est évidemment déraisonnable. Ainsi, dans iptables, vous pouvez personnaliser la chaîne, et les problèmes ci-dessus peuvent être résolus en personnalisant la chaîne. Supposons que nous personnalisions une chaîne nommée IN_WEB. Nous pouvons écrire toutes les règles entrantes pour le port 80 dans cette chaîne personnalisée. Lorsque nous souhaitons modifier les règles entrantes pour les services Web à l'avenir, nous pouvons simplement modifier directement les règles de la chaîne IN_WEB. s'il y a plus de règles dans la chaîne par défaut, nous n'aurons pas peur, car nous savons que toutes les règles entrantes pour le port 80 sont stockées dans la chaîne IN_WEB.