Quels moyens -P INPUT ACCEPT dans une relation iptables?

Je suis nouveau à B. iptables Et j'essaie de comprendre si j'ai mis en place mon ensemble de règles. Concernant

-P Entrer accepter

Une partie de ma question, j'essaie de déterminer si c'est vraiment dans le contexte des règles que je veux postuler. S'il vous plaît voir ci-dessous pour plus d'informations.

j'ai utilisé

Iptables-restauration

Avec un fichier contenant les règles suivantes. En fait, j'essaie de résoudre le trafic d'anneau installé / Composés associés SSH et HTTP. Tous les autres trafics doivent être rejetés.

*filter
:fail2ban-ssh - [0:0]

# Input chain rules
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -s 127.0.0.0/8 -j REJECT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
# Reject all other inbound traffic
-A INPUT -j REJECT

# Output chain rules
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT

# Forward chain rules
-A FORWARD -j REJECT

# fail2ban-ssh chain rules
-A fail2ban-ssh -s 146.0.77.33/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-ssh -s 62.75.236.76/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-ssh -j RETURN

COMMIT

Si je cours

iptables -S

, Je reçois la conclusion suivante:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-ssh
-A INPUT -i lo -j ACCEPT
-A INPUT -s 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A fail2ban-ssh -s 146.0.77.33/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-ssh -s 62.75.236.76/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-ssh -j RETURN

J'ai lu un peu iptables et je comprends que les premières lignes (par exemple, "

-P Entrer accepter

") En substance, cela signifie que l'action par défaut, si aucune des autres règles ne s'applique, - Il prend du trafic (Dans ce cas, d'entrer, d'expédition et de sortie).

Si oui, devrais-je clairement mettre les lignes suivantes dans mon fichier de règles et rétablir à nouveau iptables?

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP

Merci d'avance, tous ceux qui liront cette question complète! C'est un peu long, mais je pensais qu'il était nécessaire d'inclure tous les éléments ci-dessus pour expliquer de manière adéquate mon script.
Invité:

Dominique

Confirmation de:

Au fait, je viens de laisser tomber vos règles (

INPUT

chaîne) dans
http://iptables.isabelle.systems/
Pour extraire une version simplifiée. Il ne montre que qui peut installer des connexions:

ACCEPT     all  --  127.0.0.0/8          0.0.0.0/0    
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 dports: 22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 dports: 80
DROP tcp -- 146.0.77.33/32 0.0.0.0/0 dports: 22
DROP tcp -- 62.75.236.76/32 0.0.0.0/0 dports: 22
DROP all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Vous pouvez voir votre approche fail2ban En fait, cela ne fonctionne pas: la deuxième règle prend toutes les connexions ssh; Numéro de règles 4 et 5 (règlements DROP) Tondre (ils ne peuvent jamais être atteints).

Je suppose que votre politique par défaut

ACCEPT

, que vous pouvez voir comme dernière règle dans une liste simplifiée. Comme vous pouvez le constater, la stratégie par défaut pour

INPUT

Peu importe ici, car la deuxième règle a déjà jeté tous les paquets qui ne correspondaient pas à la règle. C'est à cause de votre

-A INPUT -j REJECT

Régner.

Dominique

Confirmation de:

Pour répondre à la question que vous avez réellement posée, les politiciens devraient apparaître dans l'habituel.

iptables-save

fichier mais pas comme un argument

-P

règlements.

Au lieu de cela, ils devraient apparaître au début avec votre annonce de toutes les chaînes personnalisées avec leurs politiques, par exemple:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:fail2ban-ssh - [0:0]

Defis dans votre chaîne personnalisée - Il s'agit d'un argument de politique manquant, car il n'y a pas de politicien dans les chaînes d'utilisateurs.

Veuillez noter qu'avec votre pare-feu, comme indiqué si vous modifiez toutes les stratégies sur

DROP

, Votre serveur aura des difficultés à trouver DNS, Et beaucoup de choses seront imprévisibles.

Alice

Confirmation de:

En substance, outre tout ce blocs fail2ban, Vos règles actuelles signifient que vous n'avez pas de pare-feu.

Pensez comment votre pare-feu réagira dans le scénario suivant:

Vous utilisez MySQL Ou une autre base de données qui écoute la connexion TCP pour les connexions locales, mais vous n'avez pas besoin de connexions à distance.

Ensuite, un ordinateur distant malveillant tente d'accéder au serveur. mysql à travers le port

3306

.

Suppose que fail2ban Ils n'ont pas été bloqués, la question est de savoir si l'une des règles existantes vous aidera? Qu'en est-il de:


-A INPUT -s 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable

- NE PAS


-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

- NE PAS


-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

- NE PAS

et ainsi de suite. Rien ne correspond DROPs connexion donc votre politique INPUT Il est également appliqué à la connexion.

Ensuite, considérons le même scénario

Pour tout autre service exécuté sur votre ordinateur

- si un fail2ban Non bloqué, votre serveur les manquera.

Alors oui, je vous suggère d'ajouter à votre

iptables-restore

règlements

-P INPUT DROP
# Any unmatched packets on FORWARD chain will be dropped
-P FORWARD DROP

NOTE: Bien que les règles iptables Généralement pas enregistré après le redémarrage, la politique sera. Dans ce cas, la règle ci-dessus bloque la session SSH, S'il n'y a pas de règle pertinente ACCEPT, Ce qui a été chargé après le redémarrage du serveur, c'est-à-dire que cette stratégie vous bloquera.

Personnellement, j'utiliserais toujours la politique de défausse, mais certaines personnes préfèrent partir

-P INPUT ACCEPT

et plutôt utiliser

-A INPUT DROP

En règle générale, au bas de la chaîne INPUT Comme "quasi" politiciens. Vous devez faire attention à cela et continuer à relire vos règles lors de la modification du mur de fichier, mais si vous n'avez pas configuré iptables Pour restaurer ses règles lors du redémarrage, cet emplacement signifierait que vous pouvez revenir à votre voiture.

Pour répondre aux questions, connectez-vous ou registre