Solution 1 :
En général :
L'affichage et la modification de la configuration du pare-feu nécessitent des privilèges d'administrateur (root ) comme le fait l'ouverture de services dans la plage de numéros de port restreinte. Cela signifie que vous devez soit être connecté en tant que root ou utilisez alternativement sudo pour exécuter la commande en tant que root. Je vais essayer de marquer ces commandes avec le [sudo] facultatif .
Contenu :
- L'ordre compte ou la différence entre
-Iet-A - Afficher la configuration actuelle du pare-feu
- Interpréter la sortie de
iptables -L -v -n - Connaissez votre environnement
- Les chaînes INPUT et FORWARD
- Modules du noyau
1. L'ordre compte ou la différence entre -I et -A
La chose à retenir est que les règles de pare-feu sont vérifiées dans l'ordre dans lequel elles sont répertoriées. Le noyau arrêtera de traiter la chaîne lorsqu'une règle est déclenchée qui autorisera ou refusera un paquet ou une connexion.
Je pense que l'erreur la plus courante pour les administrateurs de pare-feu novices, ils doivent suivre les instructions correctes pour ouvrir un nouveau port, comme celui ci-dessous :
[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT
puis découvrez qu'il ne prendra pas effet.
La raison en est que le -A l'option ajoute cette nouvelle règle, après toutes les règles existantes et comme très souvent la règle finale dans le pare-feu existant était celle qui bloquait tout le trafic qui n'était pas explicitement autorisé, ce qui entraînait
...
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
8 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
Ou équivalent dans iptables-save :
...
iptables -A INPUT -j REJECT
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
et la nouvelle règle ouvrant le port TCP 8080 ne sera jamais atteinte. (comme en témoignent les compteurs qui s'obstinent à rester à 0 paquet et à zéro octet).
En insérant la règle avec -I la nouvelle règle aurait été la première de la chaîne et fonctionnera.
2. Afficher la configuration actuelle du pare-feu
Ma recommandation pour l'administrateur du pare-feu est de regarder la configuration réelle du noyau Linux en cours d'exécution, plutôt que d'essayer de diagnostiquer les problèmes de pare-feu à partir d'outils conviviaux. Souvent, une fois que vous avez compris les problèmes sous-jacents, vous pouvez facilement les résoudre d'une manière prise en charge par ces outils.
La commande [sudo] iptables -L -v -n est votre ami (bien que certaines personnes aiment iptables-save meilleur). Souvent, lors de discussions sur les configurations, il est utile d'utiliser le --line-numbers option ainsi que pour numéroter les lignes. Se référer à la règle #X rend leur discussion un peu plus facile.
Remarque : Les règles NAT sont incluses dans le iptables-save sortie mais doivent être répertoriés séparément en ajoutant le -t nat option, c'est-à-dire [sudo] iptables -L -v -n -t nat --line-numbers .
Exécuter la commande plusieurs fois et vérifier l'incrémentation des compteurs peut être un outil utile pour voir si une nouvelle règle est réellement déclenchée.
[[email protected] ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 784K 65M fail2ban-SSH tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
2 2789K 866M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
3 15 1384 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num pkts bytes target prot opt in out source destination
Chain fail2ban-SSH (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 117.239.37.150 0.0.0.0/0 reject-with icmp-port-unreachable
2 4 412 REJECT all -- * * 117.253.208.237 0.0.0.0/0 reject-with icmp-port-unreachable
Sinon, la sortie de iptables-save donne un script qui peut régénérer la configuration du pare-feu ci-dessus :
[[email protected] ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT
C'est une question de préférence ce que vous trouverez plus facile à comprendre.
3. Interprétation de la sortie de iptables -L -v -n
La Politique définit l'action par défaut que la chaîne utilise lorsqu'aucune règle explicite ne correspond. Dans le INPUT chaîne définie pour ACCEPTER tout le trafic.
La première règle de la chaîne INPUT est immédiatement intéressante, elle envoie tout le trafic (source 0.0.0.0/0 et destination 0.0.0.0/0) à destination du port TCP 22 (tcp dpt:22 ) le port par défaut pour SSH vers une cible personnalisée (fail2ban-SSH ).Comme son nom l'indique, cette règle est maintenue par fail2ban (un produit de sécurité qui, entre autres, analyse les fichiers journaux du système à la recherche d'éventuels abus et bloque l'adresse IP de l'agresseur).
Cette règle aurait été créée par une ligne de commande iptables similaire à iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH ou se trouve dans la sortie de iptables-save sous -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH . Vous trouverez souvent l'une ou l'autre de ces notations dans la documentation.
Les compteurs indiquent que cette règle a correspondu à 784'000 paquets et 65 Mo de données.
Le trafic qui correspond à cette première règle est ensuite traité par le fail2ban-SSH chaîne qui, en tant que chaîne non standard, est répertoriée sous la chaîne OUTPUT.
Cette chaîne se compose de deux règles, une pour chaque abuseur (adresse IP source 117.253.221.166 ou 58.218.211.166) qui est bloqué (avec un reject-with icm-port-unreachable ).
-A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable
Les paquets SSH qui ne proviennent pas de ces hôtes bloqués ne sont ni autorisés ni interdits pour le moment et maintenant que la chaîne personnalisée est terminée, ils seront vérifiés par rapport à la deuxième règle de la chaîne INPUT.
Tous les paquets qui n'étaient pas destinés au port 22 ont passé la première règle de la chaîne INPUT et seront également évalués dans la règle INPUT #2.
Le numéro de règle INPUT 2 signifie qu'il s'agit d'un pare-feu avec état , qui suit les connexions. Cela présente certains avantages, seuls les paquets des nouvelles connexions doivent être vérifiés par rapport à l'ensemble de règles complet, mais une fois autorisés, les paquets supplémentaires appartenant à une connexion établie ou associée sont acceptés sans vérification supplémentaire.
La règle d'entrée #2 correspond à toutes les connexions ouvertes et associées et les paquets correspondant à cette règle n'auront pas besoin d'être évalués davantage.
Remarque : les modifications de règles dans la configuration d'un pare-feu avec état n'affecteront que les nouvelles connexions, pas les connexions établies.
En revanche, un simple filtre de paquets teste chaque paquet par rapport à l'ensemble de règles complet, sans suivre l'état de la connexion. Dans un tel pare-feu, aucun état des mots-clés seraient utilisés.
La règle INPUT #3 est assez ennuyeuse, tout le trafic se connectant au bouclage (lo ou 127.0.0.1) l'interface est autorisée.
Les règles INPUT 4, 5 et 6 sont utilisées pour ouvrir les ports TCP 22, 80 et 443 (les ports par défaut pour respectivement SSH, HTTP et HTTPS) en accordant l'accès aux NOUVELLES connexions (les connexions existantes sont déjà autorisées par la règle INPUT 2).
Dans un pare-feu sans état, ces règles apparaîtraient sans les attributs d'état :
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
ou
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
La règle INPUT finale, #7 est une règle qui bloque tout le trafic qui n'a PAS été autorisé à accéder dans les règles INPUT 1-7. Une convention assez courante :tout ce qui n'est pas permis est refusé. En théorie, cette règle aurait pu être omise en définissant la POLICY par défaut sur REJECT.
Enquêtez toujours sur toute la chaîne.
4. Connaissez votre environnement
4.1 . Les paramètres d'un pare-feu logiciel n'affecteront pas les paramètres de sécurité maintenus ailleurs sur le réseau, c'est-à-dire malgré l'ouverture d'un service réseau avec iptables les listes de contrôle d'accès non modifiées sur les routeurs ou autres pare-feu de votre réseau peuvent toujours bloquer le trafic...
4.2 . Lorsqu'aucun service n'écoute, vous ne pourrez pas vous connecter et obtenir une erreur de connexion refusée, quels que soient les paramètres du pare-feu. Par conséquent :
- Confirmez qu'un service écoute (sur la bonne interface réseau/adresse IP) et utilise les numéros de port que vous attendez avec
[sudo] netstat -plnutou utilisez alternativementss -tnlp. - Si vos services ne sont pas encore censés fonctionner, émulez un simple écouteur avec par exemple netcat :
[sudo] nc -l -p 123ouopenssl s_server -accept 1234 [options]si vous avez besoin d'un écouteur TLS/SSL (cochezman s_serverpour les options). - Vérifiez que vous pouvez vous connecter depuis le serveur lui-même, c'est-à-dire
telnet <IP of Server> 123ouecho "Hello" | nc <IP of Server> 123ou lors du test du service sécurisé TLS/SSLopenssl s_client -connect <IP of Server>:1234, avant d'essayer la même chose depuis un hôte distant.
4.3 . Comprendre les protocoles utilisés par vos services. Vous ne pouvez pas activer/désactiver correctement les services que vous ne comprenez pas suffisamment. Par exemple :
- TCP ou UDP est-il utilisé, ou les deux (comme avec DNS) ?
- le service utilise-t-il un port fixe par défaut (par exemple, quelque chose comme le port TCP 80 pour un serveur Web) ?
- autrement, un numéro de port dynamique choisi peut-il varier (c'est-à-dire des services RPC comme NFS classique qui s'enregistrent avec Portmap) ?
- l'infâme FTP utilise même deux ports , à la fois un numéro de port fixe et un numéro de port dynamique lorsqu'il est configuré pour utiliser le mode passif...
- les descriptions de service, de port et de protocole dans
/etc/servicesne correspondent pas nécessairement au service réel utilisant un port.
4.4 . Le filtre de paquets du noyau n'est pas le seul élément susceptible de restreindre la connectivité réseau :
- SELinux peut également restreindre les services réseau.
getenforceconfirmera si SELinux est en cours d'exécution. - Bien qu'ils deviennent un peu obscurs, les wrappers TCP restent un outil puissant pour renforcer la sécurité du réseau. Vérifiez avec
ldd /path/to/service |grep libwrapet le/hosts.[allow|deny]fichiers de contrôle.
5. INPUT ou FORWARD Chaînes
Le concept de chaînes est expliqué plus en détail ici, mais en bref :
Le INPUT La chaîne est l'endroit où vous ouvrez et/ou fermez les ports réseau pour les services exécutés localement, sur l'hôte où vous exécutez les commandes iptables.
Le FORWARD la chaîne est l'endroit où vous appliquez des règles pour filtrer le trafic qui est transféré par le noyau vers d'autres systèmes, des systèmes réels mais aussi des conteneurs Docker et des serveurs invités virtuels lorsque votre machine Linux agit comme un pont, un routeur, un hyperviseur et/ou effectue une traduction d'adresse réseau et la redirection de port.
Une idée fausse courante est que, puisqu'un conteneur docker ou un invité KVM s'exécute localement, les règles de filtrage qui s'appliquent devraient être dans la chaîne INPUT, mais ce n'est généralement pas le cas.
6. Modules du noyau
Étant donné que le filtre de paquets s'exécute dans le noyau Linux, il peut également être compilé en tant que module dynamique, plusieurs modules en fait. La plupart des distributions incluent netfilter en tant que modules et les modules netfilter requis seront chargés dans le noyau selon les besoins, mais pour certains modules, un administrateur de pare-feu devra s'assurer manuellement qu'ils sont chargés. Cela concerne principalement les modules de suivi de connexion, tels que nf_conntrack_ftp qui peut être chargé avec insmod .
Les modules actuellement chargés dans le noyau en cours d'exécution peuvent être affichés avec lsmod .
La méthode pour s'assurer que les modules sont chargés de manière persistante lors des redémarrages dépend de la distribution Linux.
Solution 2 :
"Introduction" à Iptables/Pare-feu
Un pare-feu est essentiellement un filtre réseau basé sur des politiques. Les pare-feux Linux sont construits autour de Netfilter; le cadre de traitement des paquets réseau du noyau qui est composé de plusieurs modules du noyau effectuant des tâches spécifiques :
- Le module FILTER (toujours chargé par défaut) nous permet principalement d'ACCEPTER ou d'ANNULER des paquets IP en fonction d'un certain critère de correspondance.
- L'ensemble de modules NAT nous permet d'effectuer des traductions d'adresses réseau (SNAT, DNAT, MASQUERADE).
- Le module MANGLE nous permet de modifier certains champs de paquets IP (TOS, TTL).
Les utilisateurs configurent le framework Netfilter en fonction de leurs besoins de pare-feu à l'aide d'iptables à partir de la ligne de commande. Avec iptables, nous définissons des règles qui indiquent au noyau ce qu'il faut faire des paquets IP lorsqu'ils arrivent, traversent ou quittent notre machine Linux. Ils ont plusieurs points d'ancrage spécifiques sur la carte de flux de paquets du réseau où ils sont invoqués par le noyau pour effectuer leurs tâches. et POSTROUTING. Il est facile de s'en souvenir si nous associons une TABLE à un "type de processus" et une CHAIN à "l'emplacement" sur la carte des flux de paquets du réseau où les instances de ces processus sont invoquées.
Puisqu'un paquet IP est reçu sur une interface réseau, ou créé par un processus local, jusqu'à ce qu'il soit finalement livré ou rejeté, le moteur Netfilter testera et appliquera séquentiellement les règles contenues dans la carte de flux de paquets réseau. A chaque bloc identifié par une paire [email protected] l'utilisateur peut ajouter une ou plusieurs de ces règles consécutives contenant un critère de correspondance de paquet IP et une ligne de conduite correspondante. Certaines actions (c'est-à-dire ACCEPT, DROP, etc.) peuvent être effectuées par plusieurs TABLE et d'autres actions (c'est-à-dire SNAT, DNAT, etc.) qui sont spécifiques à TABLE.
c'est-à-dire que lorsqu'un paquet IP arrive d'une interface réseau, il est d'abord traité par la chaîne PREROUTING en invoquant les règles définies par l'utilisateur de la table MANGLE, le cas échéant. S'il n'y a pas de règles qui correspondent au paquet actuel, la ligne de conduite ou la "politique" par défaut [email protected] s'applique. À ce stade, si le paquet n'a pas été supprimé, le processus continuera à invoquer les règles de la table NAT au niveau de la chaîne PREROUTING (voir la carte) et ainsi de suite. Afin de faciliter la disposition des règles, les utilisateurs peuvent également créer leurs propres chaînes personnalisées. et "sautez" dedans depuis différents points de la carte comme ils le souhaitent.
Alors que les chaînes intégrées peuvent avoir des politiques définies par l'utilisateur de paquets ACCEPT ou DROP, les chaînes définies par l'utilisateur ont toujours une politique par défaut non modifiable de RETURN à l'appelant pour continuer le processus.
Commandes Iptables
Les commandes principales d'iptables remplissent la carte de flux de paquets réseau avec les règles de traitement requises.
La règle iptables générique peut s'écrire :
# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>
Cela pourrait être lu comme :
Netfilter (kernel module) please <Add/Insert/Delete> this rule for <table> at <CHAIN> where packets matching <PKT_MATCHING_CRITERIA> have to be <ACTION>ed
<table>
-t filter (the filter table is assumed when omitted)
-t nat
-t mangle
<Add/Insert/Delete>
-A (append rule at the end of the chain list)
-I (insert rule at the begining of the chain list)
-D (Delete rule)
<CHAIN>
PREROUTING
INPUT
FORWARD
OUTPUT
POSTROUTING
USER_DEFINED_CHAIN
<PKT_MATCHING_CRITERIA>
ISO Level-2 matching:
-i [!] <if_name> or --in-interface [!] <if_name>
(OUTPUT and POSTROUTING chains cannot match on input interfaces)
-o [!] <if_name> or --out-interface [!] <if_name>
(INPUT and PREROUTING chains cannot match on output interfaces)
-mac-source [!] <xx-xx-xx-xx-xx-xx>
(OUTPUT and POSTROUTING chains cannot match on input interfaces)
ISO Level-3 matching:
-s [!] <src_ip> or --src [!] <src_ip> or --source [!] <src_ip>
-d [!] <dst_ip> or --src [!] <dst_ip> or --destination [!] <dst_ip>
ISO Level-4 matching:
-p [!] <prot_name> or --protocol [!] <prot_name> (udp|tcp|icmp)
Also available when ICMP protocol is defined
--icmp-type [!] <icmp_type>
Also available when UDP protocol is defined
--source-port [!] <udp_src_port> or --sport [!] <udp_src_port>
--destination-port [!] <udp_dst_port> or --dport [!] <udp_dst_port>
Also available when TCP protocol is defined
--source-port [!] <tcp_src_port> or --sport [!] <tcp_src_port>
--destination-port [!] <tcp_dst_port> or --dport [!] <tcp_dst_port>
--tcp-flags [!] <tcp_flags> (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE)
--syn
--tcp-option [!] <tcp_option#>
--state [!] <state>
-m <match> [options]
note: [!] = negation operator
<ACTION> (also called TARGET)
-j ACCEPT (process continues with rules of the next table in map)
-j DROP (discard current packet)
-j REJECT (discard current packet with ICMP notification)
option:
--reject-with <reject_type>
-j USER_DEFINED_CHAIN (start traversing USER_DEFINED_CHAIN rules)
-j RETURN (return from USER_DEFINED_CHAIN)
-j LOG (log to syslog, then process next rule in table)
options:
--log-level <level>
--log-prefix <prefix>
--log-tcp-sequence
--log-tcp-options
--log-ip-options
--log-uid
nat table specific
-j SNAT (rewrite the source IP address of the packet)
option:
--to <ip_address>
-j SAME (idem SNAT; used when more than one source address)
options:
--nodst
--to <a1-a2>
-j MASQUERADE (idem SNAT; used when the replace IP is dynamic)
-j DNAT (rewrite the destination IP address of the packet)
option:
--to <ip_address>
-j REDIRECT (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only)
option:
–-to-port <port#>
mangle table specific
-j ROUTE (explicitly route packets, valid at PREROUTING)
options:
--iface <iface_name>
--ifindex <iface_idx>
-j MARK (set Netfilter mark values)
options:
--set-mark <value>
--and-mark <value>
--or-mark <value>
-j TOS (set the IP header Type of Service field)
option:
--set-tos <value>
-j DSCP (set the IP header Differentiated Services Field)
options:
--set-dscp <value>
--set-dscp-class <class>
-j TTL (set the IP header Time To Live field)
options:
--ttl-set <value>
--ttl-dec <value>
--ttl-inc <value>
Les commandes auxiliaires iptables complètent le scénario en définissant les conditions par défaut, les règles de listage, les règles de vidage, etc.
#iptables -t <table> -L
(Lists the <table> rules in all chains)
#iptables -t <table> -L <CHAIN>
(Lists the <table> rules in <CHAIN>)
#iptables -t <table> -N <CHAIN>
(Creates a user-defined <CHAIN> for holding <table> rules)
#iptables -t <table> -E <CHAIN> <NEWCHAIN>
(Renames <CHAIN> that holds <table> rules to <NEWCHAIN>)
#iptables -t <table> -X
(Deletes all user-defined chains created for holding <table> rules)
#iptables -t <table> -X <CHAIN>
(Deletes user-defined <CHAIN> created for holding <table> rules)
#iptables -t <table> -P <CHAIN> <ACTION> where <ACTION> = ACCEPT|DROP
(Sets the default policy of <table> rules at <CHAIN> to <ACTION>)
#iptables -t <table> -F
(Flushes (deletes) all <table> rules in all chains)
#iptables -t <table> -F <CHAIN>
(Flushes (deletes) all <table> rules in <CHAIN>)
#iptables -t <table> -R <CHAIN> <INDEX> <NEWRULE>
(Replaces <table> rule at position <INDEX> in <CHAIN> with <NEWRULE>
Iptables charge nos commandes dans le moteur Netfilter au moment de l'exécution, Netfilter applique immédiatement les règles et les paramètres chargés, mais ils ne sont pas persistants. Après le redémarrage, toutes les règles et tous les paramètres Netfilter précédemment chargés seront perdus. Pour cette raison, il existe des utilitaires iptables qui permettent de sauvegarder l'ensemble de règles actuellement actif dans un fichier et de le recharger ultérieurement.
#iptables-save > fileName
(Save the currently active Netfilter ruleset to fileName)
#iptables-restore < fileName
(Restore Netfilter ruleset to the one saved in fileName)
Résumé d'Iptables
Netfilter est un framework extrêmement flexible et puissant mais il y a un prix à payer pour cela; Iptables est complexe. Du point de vue de l'utilisateur, certains termes comme TABLE, CHAIN, TARGET ne correspondent pas vraiment très bien au concept qu'ils représentent et n'ont pas beaucoup de sens au premier abord. Le sujet est long, les commandes semblent avoir une liste interminable de paramètres. Pour aggraver les choses, il n'y a pas un seul livre qui maîtrise vraiment Iptables. Ils se répartissent principalement en deux catégories :"livre de recettes" ou "livre de pages de manuel". Je pense que cette introduction vous donne un aperçu du paysage Netfilter/Iptables ainsi que la dose nécessaire de pages de manuel pré-digérées. Si vous êtes nouveau chez iptables, après avoir lu ces paragraphes plusieurs fois, vous serez prêt à lire des exemples iptables. Avec un peu de pratique, vous vous retrouverez bientôt à écrire vos propres règles.
Pare-feu
Un pare-feu est principalement conçu pour autoriser ou refuser dynamiquement le trafic réseau en fonction d'un ensemble de règles. À ce stade, il est facile de comprendre pourquoi le framework Linux Netfilter/Iptables est parfait pour la construction de pare-feu. En regardant la carte des flux de paquets du réseau, nous trouvons deux points particulièrement intéressants sur la table FILTER au niveau des chaînes INPUT et FORWARD ; Nous pouvons y décider de l'adresse IP source, du protocole IP (UDP/TCP), du port de destination (80, 21, 443, etc.), etc., si nous ACCEPTONS, REJETONS, ou simplement ABANDONNONS un paquet IP particulier. C'est ce qu'un pare-feu fait 80 % du temps lorsqu'il protège un serveur Web contre les requêtes réseau non autorisées. Les 20 % restants du temps consistent à manipuler des paquets réseau (NAT, MANGLE).
Scénarios de pare-feu
Il existe des centaines de configurations de pare-feu différentes répondant à différents besoins, mais 3 d'entre elles pourraient être considérées comme les scénarios de pare-feu les plus typiques.
- Serveur Web simple avec une ou plusieurs interfaces connectées à Internet. La stratégie comprend des règles de base pour autoriser un accès entrant restreint, un accès sortant illimité et des règles anti-usurpation d'identité. Le transfert IP est désactivé.
- Ce pare-feu se connecte à Internet et à une zone interne protégée. La stratégie comprend des règles de base pour autoriser un accès entrant restreint, un accès sortant illimité et des règles anti-usurpation d'identité. Étant donné que la zone protégée utilise des adresses IP privées, un NAT source est nécessaire. Le transfert IP est activé.
- Ce pare-feu se connecte à Internet, zone interne protégée et démilitarisée. La politique comprend des règles de base pour autoriser un accès entrant restreint, un accès sortant illimité et des règles anti-usurpation d'identité. Étant donné que les zones protégées et DMZ utilisent des adresses IP privées, elles ont besoin d'un NAT source et de destination. Le transfert IP est activé.
J'ai écrit ceci pour :http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html
Solution 3 :
Problèmes courants avec différents protocoles
DNS : DNS utilise le port 53 UDP par défaut, mais les messages qui ne tiennent pas dans un seul datagramme UDP seront transmis via TCP à la place (généralement des transferts de zone et autres), ce qui nécessite également l'ouverture du port 53 TCP lorsque vous exécutez un serveur de noms.
E-mail : De nombreux FAI grand public bloquent le trafic SMTP (ou au moins le port TCP 25 par défaut), ce qui rend impossible la réception ou l'envoi direct d'e-mails et leurs clients sont obligés d'utiliser le relais SMTP du FAI pour tous les e-mails sortants et parfois également pour les e-mails entrants. §1.1.
FTP : FTP est un protocole étrange dans la mesure où deux les connexions sont utilisées. La première est la connexion de contrôle, par défaut un serveur FTP écoutera sur le port TCP 21 pour cela. La connexion de contrôle est utilisée pour l'authentification et l'émission de commandes. Les transferts de fichiers réels et des éléments tels que la sortie d'une liste de répertoires passent par une deuxième connexion TCP, la connexion DATA . Dans le FTP actif, cette connexion DATA serait initiée à partir du serveur FTP à partir du port TCP 20 et se connecterait au client FTP. Le FTP actif ne fonctionne pas trop bien avec les utilisateurs derrière des pare-feu et des passerelles NAT, il est donc tombé en désuétude. La plupart des serveurs FTP prend en charge le FTP passif à la place. Avec le FTP passif, le serveur FTP ouvre un écouteur pour la connexion DATA sur un deuxième port, auquel le client FTP peut alors se connecter. Le problème pour un pare-feu est que le port DATA peut être n'importe quel port non privilégié disponible entre 1024 et 65536.
Dans un pare-feu sans état qui est généralement résolu en limitant le nombre de ports passifs que le serveur FTP peut attribuer, puis en ouvrant explicitement ces ports. c'est-à-dire
iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT
Dans un pare-feu avec état, vous n'avez pas besoin d'ouvrir explicitement le port DATA, le module d'assistance netfilter reconnaîtra le port dynamique qui est attribué et ouvrira dynamiquement ce port pour le bon client en marquant la connexion DATA comme RELATED après quoi il correspondra à la règle générique :
iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT
Cela nécessite que le module de noyau correct est chargé, dans le cas du FTP manuellement en exécutant par exemple insmod nf_conntrack_ftp , rendre cela persistant dépend du redémarrage dépend de la distribution.
Remarque : Le module de suivi de connexion FTP échouera lorsque FTP est utilisé avec SSL, car la connexion de contrôle sera cryptée et le nf_conntrack_ftp ne pourra plus lire la réponse PASV.
NFS et services RPC similaires : Le problème avec les services RPC est que, de par leur conception, ils n'utilisent pas de port fixe spécifique. Ils peuvent choisir n'importe quel port disponible au hasard, qui sera ensuite enregistré avec le démon RPC Portmap. Un client essayant de se connecter interrogera le démon Portmap puis se connectera directement au bon port. Cela a résolu le problème de manque de ports réservés...
Du point de vue du pare-feu, le port TCP/UDP 111 doit être ouvert et le port réel que le service RPC utilise actuellement. Le problème de l'ouverture d'un tel port aléatoire dans un pare-feu est généralement résolu en restreignant le service RPC, tel que le NFS serveur, pour utiliser un port fixe prédéfini.