Avis Iptables

Support Debian
#1

Tout d’abord bonne année à tous !
Je viens d’établir un remake de script iptables j’attends vos avis en me corrigeant s’il le faut !

#!/bin/bash

VERT="\\033[1;32m"
NORMAL="\\033[0;39m"
ROUGE="\\033[1;31m"
BLEU="\\033[1;34m"
### IPTABLE 
# Provides: iptables
# Description: Gestions des iptables du serveur.
# toute les ouvertures de port, les bannissements
# les drop les rejects... seront indiques ici.
### END INFO

echo -e "$ROUGE""LOAD"

# On refuse tout
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
echo -e "$ROUGE""- Interdire toutes les connexions entrantes et sortantes : [OK]"

# On ne ferme pas les connexions etablie
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
echo -e "$ROUGE""- Ne pas casser les connexions etablies : [OK]"
 
# boucle locale (On autorise tout sur 127.0.0.1)
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
echo -e "$ROUGE""- Loopback autorise: [OK]"

# Autoriser le monitoring OVH
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --source ping.ovh.net -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --source proxy.ovh.net -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --source proxy.p19.ovh.net -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --source proxy.rbx.ovh.net -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --source proxy.rbx2.ovh.net -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --source proxy.sbg.ovh.net -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --source proxy.bhs.ovh.net -j ACCEPT
echo -e "$ROUGE""- Ping du monitoring OVH:[OK]"

# Autoriser Ping (entrant et sortant)
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
echo -e "$ROUGE""- Autoriser Ping:[OK]"


# SSH // Pour plus de sécurité changer le port par défaut (etc/ssh/sshd_config).
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
# SSH (Pour se connecter a d'autres serveurs)
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT
echo -e "$ROUGE""- SSH IN/OUT 22:[OK]"

# HTTP (Connection entrante)
# iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
 
# HTTP (Connection sortante)
#iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
 
# HTTPS (Connection entrante)
#iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
 
# HTTPS (Connection sortante)
#iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT

#echo -e "$ROUGE""- HTTP/HTTPS IN/OUT:[OK]"

# Sortie DNS
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
echo -e "$ROUGE""- DNS OUT:[OK]"

# Sortie NTP
iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT
echo -e "$ROUGE""- NTP OUT:[OK]"

# Teamspeak 3
# Port Voix IP
iptables -t filter -A INPUT -p udp --dport 9987 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --sport 9987 -j ACCEPT

# Port transfert de fichier
iptables -t filter -A INPUT -p tcp --dport 30033 -j ACCEPT

#
iptables -t filter -A INPUT -p tcp --dport 41144 -j ACCEPT
iptables -A OUTPUT -p udp --sport 2011:2110 -j ACCEPT
# Port TS3 Query
iptables -t filter -A INPUT -p tcp --dport 10011 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --sport 10011 -j ACCEPT

# Si vous avez une license teamspeak 3
iptables -A OUTPUT -p tcp -d accounting.teamspeak.com --dport 2008 -j ACCEPT
iptables -A OUTPUT -p udp -d weblist.teamspeak.com --dport 2010 -j ACCEPT

# Un tcpdump sur du trafic teamspeak légitime semble montrer que la taille des paquets UDP ne dépasse pas les 600 octets
iptables -A INPUT -p udp --dport 9987 -m length --length 600:65535 -j DROP
echo -e "$ROUGE""- TEAMSPEAK:[OK] "



# Mumble (Décomentez pour utiliser)
# iptables -t filter -A INPUT -p tcp --dport 64738 -j ACCEPT
# iptables -t filter -A INPUT -p udp --dport 64738 -j ACCEPT

# Iptable une plage IP (UDP) sur le service Teamspeak (Add les ports si plusieur serveurs 9987,9988,xxxx...) (vpn,...)
iptables -I INPUT -s 5.196.0.0/16 -p udp --dport 9987 -j DROP #OVH IPV4 BANNED LOAD ...
iptables -I INPUT -s 185.15.68.0/22 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 5.135.0.0/16 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 5.196.0.0/16 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 5.39.0.0/17 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 37.187.0.0/16 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 37.59.0.0/16 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 109.190.0.0/16 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 176.31.0.0/16 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 46.105.0.0/16 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 178.32.0.0/15 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 188.165.0.0/16 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 94.23.0.0/16 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 92.222.0.0/16 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 91.121.0.0/16 -p udp --dport 9987 -j DROP
iptables -I INPUT -s 87.98.128.0/17 -p udp --dport 9987 -j DROP #OVH IPV4 BANEED END
echo -e "$ROUGE""- IPTABLES OVH SUR TS3:[OK] "

# Iptable une ip
iptables -A INPUT -s 81.65.xx.xx -j DROP
echo -e "$ROUGE""- OWNED:[OK]"


### tcpdump -n  udp dst port 9987
### telnet accounting.teamspeak.com 2008 -b ure.ip.xx.xx #Pour test la comm avec le server de licence 

###### Fin Regles ######
echo -e "$VERT""- Firewall mis a jour avec succes :[OK]"
echo -e "$NORMAL"""

J’hésite a ajouter ça mais je ne sais pas vraiment :

[code]# Syn Cookies
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo - Syncookies : [OK]

Syn-Flood

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
echo - Limiter le Syn-Flood : [OK]

Spoofing

iptables -N SPOOFED
iptables -A SPOOFED -s 127.0.0.0/8 -j DROP
iptables -A SPOOFED -s 169.254.0.0/12 -j DROP
iptables -A SPOOFED -s 172.16.0.0/12 -j DROP
iptables -A SPOOFED -s 192.168.0.0/16 -j DROP
iptables -A SPOOFED -s 10.0.0.0/8 -j DROP
echo - Bloquer le Spoofing : [OK] [/code]

#2

Salut,

Depuis quand l’on donne ses astuces sur Support Debian et de plus sans même respecter la forme des titres :laughing:

#3

Ce n’est pas un truc & astuce mais une demande d’avis et de corrections. Les voici.

  • Pourquoi avoir défini /bin/bash comme shell au lieu du shell par défaut /bin/sh (habituellement dash, plus rapide et plus sûr) ? Je ne vois pas de “bashisme” dans le script.

Le commentaire est erroné. Il ne s’agit pas de la boucle locale (qui désigne la paire de cuivre pour le téléphone) mais du “loopback” (rebouclage). Il n’y a pas que l’adresse 127.0.0.1 qui utilise cette interface, mais aussi toutes les communications entre processus locaux avec n’importe quelle adresse locale (127.0.0.0/8 et les adresses des autres interfaces de la machine).

  • Pourquoi faire des règles spécifiques et restrictives (sur le type ICMP et la fréquence) pour le monitoring OVH alors qu’elles sont suivies par une règle beaucoup moins restrictive :

# Autoriser Ping (entrant et sortant) iptables -t filter -A INPUT -p icmp -j ACCEPT iptables -t filter -A OUTPUT -p icmp -j ACCEPT
Le commentaire ne correspond pas aux règles : celles-ci autorisent tous les paquets ICMP, pas seulement le ping. Or certains types ICMP sont potentiellement dangereux (redirect, source-quench).

  • Changer le port de SSH n’apporte plus de sécurité que dans le cas d’un mot de passe faible ou d’une faille exploitable à distance de sshd. Autrement cela évite surtout la pollution des logs par les tentatives infructueuses des robots.

# Port TS3 Query iptables -t filter -A INPUT -p tcp --dport 10011 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --sport 10011 -j ACCEPT
Je ne sais pas à quoi cela correspond, mais je trouve bizarre que le même port local serve à la fois pour des connexions TCP entrantes et sortantes.

Mais c’est trop tard. Une règle précédente a déjà accepté les paquets que cette règle aurait bloqués. La limitation de taille pouvait être incluse dans la règle précédente.

Ce commentaire est pour le moins obscur pour ce qui ressemble à un blacklistage d’adresses…

# Iptable une ip iptables -A INPUT -s 81.65.116.71 -j DROP
Même chose ici. Mais cette règle ne sert à rien car elle arrive après toutes les règles qui acceptent.

  • Les SYN cookies peuvent être activés. De toute façon ils ne sont utilisé qu’en cas de saturation du backlog TCP.

  • Les règle “Syn-flood” ne riment à rien.
    Elles sont dans la chaîne FORWARD alors que visiblement la machine n’est pas un routeur.
    La limitation à 1 paquet par seconde est simplement ridicule. C’est beaucoup trop bas.
    La notion de SYN est propre à TCP et n’existe pas en UDP.
    Les règles acceptent n’importe quel port.

  • "Spoofing"
    La plage link local est 169.254.0.0/16, pas 169.254.0.0/12.
    Tant que la chaîne SPOOFED n’est appelée nulle part, ses règles sont sans effet.

#4

Merci de t’as réponse je vais donc essayer au mieux de comprendre et de corriger mes erreurs !
Je reviens dans la journée pour apporter mes corrections et/ou questions si j’ai des incompréhensions !

Merci.

EDIT :

j’ai donc modifié l’interprète #!/bin/sh, corrigé le commentaire # Loopback, suppression des requêtes icmp en laissant le monitoring pour OVH.

# Port TS3 Query iptables -t filter -A INPUT -p tcp --dport 10011 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --sport 10011 -j ACCEPT
En effet c’est l’accès admin TS j’ai donc supprimé le OUT est cela semble fonctionnel.

Mais c’est trop tard. Une règle précédente a déjà accepté les paquets que cette règle aurait bloqués. La limitation de taille pouvait être incluse dans la règle précédente.
Je pense que tu parle de fusionner ces règles :

iptables -t filter -A INPUT -p udp --dport 9987 -j ACCEPT iptables -A INPUT -p udp --dport 9987 -m length --length 600:65535 -j DROP

Mais je ne vois pas trop comment peut etre comme ça :

iptables -t filter -A INPUT -p udp --dport 9987 -m length --length 0:600 -j ACCEPT ???

En effet, drop de toute les plages ip OVH sur le service teamspeak pour bloquer les nombreux VPN OVH

# Iptable une ip iptables -A INPUT -s 81.65.xx.xx -j DROP
Même chose ici. Mais cette règle ne sert à rien car elle arrive après toutes les règles qui acceptent.

Ah bon ? J’ai test et pourtant elle est bien drop …

Merci bcp.

#5

Remarques d’ordre général :

  • Comme tu as édité ton message, je ne l’ai pas vu car cela ne met pas à jour sa date d’émission ni son statut lu/non lu. Il aurait mieux valu créer un nouveau message. L’édition doit être réservée aux petites modification rapides après l’envoi et aux corrections.

  • Quand tu cites des parties d’autres message, utilise les balises [ Quote ] (sélectionne le texte dans le message originel et clique sur le bouton “citer”) pour bien les différencier de ton propre texte.

Maintenant, revenons au sujet.

Tu risques de rencontrer des problèmes si tu bloques tous les ICMP. Le ping ne fonctionnera pas ni en sortie ni en entrée sauf depuis les serveurs de monitoring. Plus gênant, Quelques types ICMP sont indispensables au bon fonctionnement du protocole IP :

  • destination-unreachable
  • time-exceeded
  • parameter-problem
    Les bloquer peut rendre impossible la communication avec certaines destinations. Je recommande de les accepter en entrée et en sortie s’ils sont dans l’état RELATED, c’est-à-dire quand ils signalent une erreur liée à une connexion existante.

[quote=“kqly”]Mais je ne vois pas trop comment peut etre comme ça :

Exactement.
Une remarque toutefois : cette règle ne traite pas les paquets dans l’état ESTABLISHED qui ont déjà été accepté par une des premières règles. Si le flux se comporte comme une connexion, avec des paquets entrants vers le port 9987 et des paquets sortants depuis ce même port à destination de l’adresse et du port source du paquet initial, alors seul le premier paquet du flux aura l’état NEW et sera traité par cette règle. Les suivants auront l’état ESTABLISHED et seront acceptés par la règle générale en début de chaîne, et non soumis à la limitation de taille. Ceci s’applique à tous les paquets faisant partie d’une connexion TCP ou d’un flux UDP ou ICMP assimilé.

A mon avis ce serait plus clair de mettre ceci plutôt que le commentaire originel.

[quote=“kqly”]iptables -A INPUT -s 81.65.xx.xx -j DROP

Ah bon ? J’ai test et pourtant elle est bien drop[/quote]
Testé comment ?
Si par exemple cette adresse envoie un paquet TCP vers le port 22, la règle pour SSH en entrée l’acceptera avant que la règle de blocage puisse le bloquer.

#6

[quote=“PascalHambourg”]Remarques d’ordre général :

  • Comme tu as édité ton message, je ne l’ai pas vu car cela ne met pas à jour sa date d’émission ni son statut lu/non lu. Il aurait mieux valu créer un nouveau message. L’édition doit être réservée aux petites modification rapides après l’envoi et aux corrections.

  • Quand tu cites des parties d’autres message, utilise les balises [ Quote ] (sélectionne le texte dans le message originel et clique sur le bouton “citer”) pour bien les différencier de ton propre texte.
    [/quote]

Done !

Donc j’ai regarder sur different page web je suis tombé sur un truc de se genre qui me semble correcte même si j’ignore icmp-type 8 & 0 :

SERVER_IP="my.ip.xx.xx" iptables -A OUTPUT -p icmp --icmp-type 8 -s $my.ip.xx.xx -d 0/0 -m state --state RELATED -j ACCEPT iptables -A INPUT -p icmp --icmp-type 0 -s 0/0 -d $my.ip.xx.xx -m state --state RELATED -j ACCEPT

Ok merci de l’info donc il faudrait ajouter “–m state --state NEW,ESTABLISHED” mais je n’ai pas idée de la syntaxe de cette règles.

Merci encore une fois !

Bonne soirée

#7

[quote=“kqly”]Donc j’ai regarder sur different page web je suis tombé sur un truc de se genre qui me semble correcte même si j’ignore icmp-type 8 & 0 :

SERVER_IP="my.ip.xx.xx" iptables -A OUTPUT -p icmp --icmp-type 8 -s $my.ip.xx.xx -d 0/0 -m state --state RELATED -j ACCEPT iptables -A INPUT -p icmp --icmp-type 0 -s 0/0 -d $my.ip.xx.xx -m state --state RELATED -j ACCEPT[/quote]
C’est mauvais, sur la forme et sur le fond.

Sur la forme : la variable contenant l’adresse est mal utilisée ($my.ip.xx.xx au lieu de $SERVER_IP) ; les types ICMP numériques ne sont pas parlants, il vaut mieux utiliser les noms équivalents (que j’ai indiqués dans mon message précédents), comme tu l’avais fait dans ton script initial.

Sur le fond (et un peu la forme) : aucun intérêt à spécifier l’adresse source ou destination surtout quand c’est 0/0 qui signifie n’importe quelle adresse. Cela ne fait qu’alourdir les règles et nuire à leur lisibilité.
Sauf cas particulier mis en place par l’administrateur de la machine, un paquet dans la chaîne INPUT a forcément une adresse de destination locale (y compris broadcast ou multicast), et un paquet dans la chaîne OUTPUT a forcément une adresse source locale.

Pour info, les types ICMP 8 et 0 correspondent respectivement à echo-request (ping) et echo-reply (réponse au ping).

Non, tu n’as pas compris ce que je voulais dire. Tu peux ajouter tout ce que tu veux aux règles qui limitent, cela ne sert à rien si les paquets ont déjà été acceptés (sans la limite) par une règle précédente.
Ce qu’il faut faire, c’est soit appliquer la limite avant la règle générale afin de bloquer les paquets que cette dernière aurait acceptés (avec la règle de ton script initial déplacée avant la règle ESTABLISHED), soit changer la cible de la règle générale pour envoyer les paquets dans une chaîne utilisateur où leur sort pourra être décidé selon des critères supplémentaires, soit supprimer la règle générale et la remplacer par des règles spécifiques pour chaque type de flux tenant compte de l’état.

Demande-toi aussi si cette limitation de la taille est vraiment justifiée.

#8

D’accord donc je vois pas trop comment faire pour le icmp et pour la limitation des length je laisse comme cela c’est une règle annexe.

Merci pour tout

#9

Pourtant pas compliqué.

A reproduire dans INPUT et pour les autres types ICMP concernés.

#10

Merci

et sinon pour les connexions établie

[quote]

iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
ou
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT[/quote]

j’ai pas tout compris …

Corrige moi si …

iptables -A OUTPUT -p icmp --icmp-type destination-unreachable -m state --state RELATED -j ACCEPT iptables -A INPUT -p icmp --icmp-type destination-unreachable -m state --state RELATED -j ACCEPT

#11

[mono]-m state --state[/mono] et [mono]-m conntrack --ctstate[/mono] sont équivalent. La seconde forme supporte des pseudo-états supplémentaires liés au NAT, cela ne concerne pas ton script.

Note concernant le traitement des paquets dans l’état RELATED :
Les jeux de règles de filtrage contiennent souvent une règle générale en début de chaîne comme celles que tu cites. L’inconvénient est qu’elles acceptent certains paquets RELATED potentiellement nocifs et rarement utiles, comme les types ICMP que j’ai mentionnés (source-quench et redirect) dont l’usage peut être détourné à des fins malveillantes (d’autre types ICMP peuvent être détournés mais ils sont indispensables, contrairement aux deux précités). Si on veut s’en prémunir, on peut soit les bloquer avant la règle générale, soit ne pas inclure l’état RELATED dans la règle générale et ajouter des règles spécifiques pour les différents types de paquets RELATED susceptibles d’être rencontrés (c’est ce que je fais). En dehors des paquets ICMP, un paquet ne peut avoir l’état RELATED que s’il fait partie du flux secondaire d’un protocole complexe géré par un module dédié du suivi de connexion, par exemple nf_conntrack_ftp pour le protocole FTP. En fonction des modules que tu actives, tu dois savoir à quels types de paquets RELATED t’attendre.

Tes règles pour le type ICMP destination-unreachable sont correctes. Il reste à faire la même chose pour les autres types d’erreurs ICMP à autoriser, time-exceeded et parameter-problem.

#12

[quote=“PascalHambourg”][mono]-m state --state[/mono] et [mono]-m conntrack --ctstate[/mono] sont équivalent. La seconde forme supporte des pseudo-états supplémentaires liés au NAT, cela ne concerne pas ton script.

Note concernant le traitement des paquets dans l’état RELATED :
Les jeux de règles de filtrage contiennent souvent une règle générale en début de chaîne comme celles que tu cites. L’inconvénient est qu’elles acceptent certains paquets RELATED potentiellement nocifs et rarement utiles, comme les types ICMP que j’ai mentionnés (source-quench et redirect) dont l’usage peut être détourné à des fins malveillantes (d’autre types ICMP peuvent être détournés mais ils sont indispensables, contrairement aux deux précités). Si on veut s’en prémunir, on peut soit les bloquer avant la règle générale, soit ne pas inclure l’état RELATED dans la règle générale et ajouter des règles spécifiques pour les différents types de paquets RELATED susceptibles d’être rencontrés (c’est ce que je fais). En dehors des paquets ICMP, un paquet ne peut avoir l’état RELATED que s’il fait partie du flux secondaire d’un protocole complexe géré par un module dédié du suivi de connexion, par exemple nf_conntrack_ftp pour le protocole FTP. En fonction des modules que tu actives, tu dois savoir à quels types de paquets RELATED t’attendre.

Tes règles pour le type ICMP destination-unreachable sont correctes. Il reste à faire la même chose pour les autres types d’erreurs ICMP à autoriser, time-exceeded et parameter-problem.[/quote]

Merci de ton aide en espérant que cela puisse en aider d’autre !

Bonne journée

#13

Je reviens pour une petit question portant toujours sur iptables …

J’ai un programme sur node.js qui a besoin se connecter sur un serveur distant en socket mais je n’arrive pas a lui accorder la permission même si je t’autorise l’ip en question … de se faite j’ai voulu effacer mes règles iptables pour test sans, j’ai donc fais un iptables -F && iptables -X mon ssh crash (logique je suppose)
Je décide alors de me connecter en KVM je regarde les règles iptables, elles sony toutes bien effacer mais je n’ai toujours pas d’accès au ssh et je suis obliger de restart le serveur … Je ne comprend pas pourquoi

#14

Tu as probablement laissé les politiques par défaut (-P) à DROP, qui bloquent tout en l’absence de règles qui autorisent quelque chose. Il faut les remettre à ACCEPT, ou insérer une règle au début des chaînes (-I) acceptant tout. Pas besoin de supprimer les autres règles.

Quand je veux savoir quels paquets sont bloqués, j’ajoute une règle LOG à la fin des chaînes pour voir les paquets qui n’ont pas été acceptés dans les logs du noyau. S’il y a des règles DROP, il faut les adapter pour faire un LOG avant.

#15

[quote=“PascalHambourg”]Tu as probablement laissé les politiques par défaut (-P) à DROP, qui bloquent tout en l’absence de règles qui autorisent quelque chose. Il faut les remettre à ACCEPT, ou insérer une règle au début des chaînes (-I) acceptant tout. Pas besoin de supprimer les autres règles.

Quand je veux savoir quels paquets sont bloqués, j’ajoute une règle LOG à la fin des chaînes pour voir les paquets qui n’ont pas été acceptés dans les logs du noyau. S’il y a des règles DROP, il faut les adapter pour faire un LOG avant.[/quote]

D’accord merci de l’info … et pour mon problème avec node j’ai pourtant bien autoriser l’ip en TCP mais cela ne fonctionne pas visiblement

#16

Fais voir ta règle.
Et ajoute une simple règle avec [mono]-j LOG[/mono] à la fin des chaînes INPUT et OUTPUT, tu verras les paquets non acceptés dans les logs du noyau.

#17

[quote=“PascalHambourg”]Fais voir ta règle.
Et ajoute une simple règle avec [mono]-j DROP[/mono] à la fin des chaînes INPUT et OUTPUT, tu verras les paquets non acceptés dans les logs du noyau.[/quote]

Voilà

#18

A quoi correspond l’adresse 146.xx.xx.xx dans la règle ? Si c’est l’adresse du serveur distant, il faut utiliser [mono]-d[/mono] (destination) et non [mono]-s[/mono] (source).

PS : erreur de ma part dans mon précédent message, je voulais dire [mono]-j LOG[/mono] au lieu de [mono]-j DROP[/mono]. C’est corrigé.

#19

[quote=“PascalHambourg”]A quoi correspond l’adresse 146.xx.xx.xx dans la règle ? Si c’est l’adresse du serveur distant, il faut utiliser [mono]-d[/mono] (destination) et non [mono]-s[/mono] (source).

PS : erreur de ma part dans mon précédent message, je voulais dire [mono]-j LOG[/mono] au lieu de [mono]-j DROP[/mono]. C’est corrigé.[/quote]

Oh oui le con et ok pour le -j DROP ça log dans qu’elle .log ?

#20

Dans le tampon des messages du noyau lisible avec la commande [mono]dmesg[/mono], ou bien dans /var/log/kern.log (messages du noyau) ou /var/log/syslog (messages système dont ceux du noyau).