Dnscrypt bloqué par iptables

Tags: #<Tag:0x00007f63f33e38f8>

Bonjours à toutes et à tous
Voilà 3 nuits blanche que j’écume le net sans relâche afin de débloquer iptables pour laisser passer dnscrypt-proxy. :scream: :scream: :scream:

ma résolution dns se fait par - unbound en cache port 53 et forward port 228
- dnscrypt- proxy port 228
malgrès l’ouverture des port sur iptables rien a faire dnscrypt-proxy n’arrive pas a sortir

Mon script /etc/init.d/firwall :

# Ne pas casser les connexions établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
 
# Autorise le loopback (127.0.0.1)
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
echo "Loopback"
 
# Redictions Traffic DNS
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 127.0.0.1:228
iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to 127.0.0.1:228

iptables -t filter -A OUTPUT -p tcp --dport 53  -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53  -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 53  -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53  -j ACCEPT
# DNS In/Out
iptables -t filter -A OUTPUT -p tcp --dport 228 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 228 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 228 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 228 -j ACCEPT
echo "dns ok"
 

# HTTP + HTTPS Out
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
 
# HTTP + HTTPS In
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT

j’ai testé une bonne 50aine de commandes et rien a faire, pourtant port 53 et 228 sont bien ouvert , tout roules si je désactive le firewall.

Merci d’avance pour votre aide car je vais finir complètement zinzin ^^ :ghost: :ghost:

Ne connaissant pas dnscrypt, trois questions :

  1. Quelle est la finalité des deux règles DNAT ?
  2. Comment dnscrypt envoie-t-il les requêtes chiffrées ?
  3. D’ou viennent les requêtes DNS ?
  4. C’est le script complet ? Pas de politiques par défaut (iptables -P) ?

Pour voir les paquets bloqués par une politique par défaut à DROP, tu peux ajouter des règles LOG à la fin des chaînes.

PS : pourrais-tu mettre le script en forme dans un bloc de code ?

bonjour @PascalHambourg merci de ton aide.

  • Pour les deux regles Dnat avec ou sans dnscrypt ne se connecte pas, elles sont issue des nombreuses regles que j’ai essayé

  • dnscrypt envoie les requetes a un serveur dns exterieur en chiffrées 127.0.01: 228
    -les requete dns viennent elle de unbound en mode cache 127.0.0.1:53

comment fait on pour mettre le script en mode bloc de code?
dans quel chemin seront loggué les paquet bloqué avec la régle LOG?

127.0.0.1 n’est pas un serveur extérieur, c’est l’adresse de loopback de la machine locale.

De ce que je comprends :

  • dnscrypt et unbound tournent sur la même machine
  • unbound reçoit des requêtes DNS en clair sur le port 53
  • unbound fait suivre les requêtes DNS en clair à dnscrypt sur le port 228 de l’adresse de loopback
  • dnscrypt fait suivre les requêtes DNS chiffrées sur le port ?? de l’adresse ??

Est-ce correct ? Si oui, peux-tu compléter les points d’interrogation ? (pour répondre à la question 2)

En complément, pourrais-tu fournir le contenu du script complet ou la sortie de la commande iptables-save ? (pour répondre à la question 4)

Pour mettre en forme un bloc de code, il faut le sélectionner et cliquer sur l’icone </> (texte préformaté) au dessus du champ d’édition.

Les paquets prise par la cible LOG sont loggés dans les logs du noyau lisibles par la commande dmesg ou dans le fichier /var/log/kern.log.

pour commencer voici mon iptables entiers,

#!/bin/sh
### BEGIN INIT INFO
# Provides:          firewall
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5 6
 Default-Stop:      0 1 6
# Short-Description: Demarrage du script lors de la sequence de boot
# Description:       Ajout des regles de parefeu
### END INIT INFO
 
############################ Politique Start: Basic ###################


echo 1 > /proc/sys/net/ipv4/ip_forward
# Politiques remise à 0

# Suppression des  Chaines prédéfinies.
iptables -F
iptables -t nat -F
iptables -t mangle -F

# Suppression des chaines personnelles :
iptables -X 
iptables -t nat -X
iptables -t mangle -X
echo "Mise à 0"
 
# On bloque tout
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
echo "Interdiction"
 
# Ne pas casser les connexions établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
 
# Autorise le loopback (127.0.0.1)
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
echo "Loopback"
 
# Redictions Traffic DNS
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 127.0.0.1:228
iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to 127.0.0.1:228

iptables -t filter -A OUTPUT -p tcp --dport 53  -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53  -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 53  -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53  -j ACCEPT
# DNS In/Out
iptables -t filter -A OUTPUT -p tcp --dport 228 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 228 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 228 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 228 -j ACCEPT
echo "dns ok"
 

# HTTP + HTTPS Out
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
 
# HTTP + HTTPS In
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT

echo "http/https [ OK ]"
 				
		### Couches Sécu de: Politique Basic ####
# anti scan
iptables -A INPUT -i eth0 -p tcp --tcp-flags FIN,URG,PSH FIN,URG,PSH -j DROP
iptables -A INPUT -i eth0 -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -i eth0 -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -i eth0 -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -i eth0 -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j DROP

#Make sure NEW incoming tcp connections are SYN packets
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

#Packets with incoming fragments
iptables -A INPUT -f -j DROP

#incoming malformed XMAS packets
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

#Incoming malformed NULL packets
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

#Regles de sécurités
iptables -A INPUT -p all -j DROP
iptables -A OUTPUT -p all -j DROP
iptables -A FORWARD -p all -j DROP

echo " Couches de Sécu [ OK ]"

retour commande iptables-save

# Generated by iptables-save v1.4.21 on Fri Jan 27 17:11:56 2017
*mangle
:PREROUTING ACCEPT [153907:198288535]
:INPUT ACCEPT [153907:198288535]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [101998:14800511]
:POSTROUTING ACCEPT [101998:14800511]
COMMIT
# Completed on Fri Jan 27 17:11:56 2017
# Generated by iptables-save v1.4.21 on Fri Jan 27 17:11:56 2017
*nat
:PREROUTING ACCEPT [2:360]
:INPUT ACCEPT [2:360]
:OUTPUT ACCEPT [2508:178417]
:POSTROUTING ACCEPT [2508:178417]
COMMIT
# Completed on Fri Jan 27 17:11:56 2017
# Generated by iptables-save v1.4.21 on Fri Jan 27 17:11:56 2017
*filter
:INPUT ACCEPT [153907:198288535]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [101998:14800511]
COMMIT

fichier unbound

   # Unbound configuration file for Debian.
#
# See the unbound.conf(5) man page.
#
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.
#
# The following line includes additional configuration files from the
# /etc/unbound/unbound.conf.d directory.
include: "/etc/unbound/unbound.conf.d/*.conf"
port: 53
prefetch: yes
use-caps-for-id: yes
harden-dnssec-stripped: yes
hide-identity: yes
hide-version: yes
harden-glue: yes
 do-not-query-localhost: no
cache-min-ttl: 900
cache-min-ttl: 3600
val-clean-additional: yes
 forward-zone:
     name: "."
        forward-addr: 127.0.0.1@228
        forward-first: no
remote-control:
        control-enable: no

fichier dnscrypt

#!/bin/sh
### BEGIN INIT INFO
# Provides: dnscrypt-proxy
# Required-Start: $local_fs $network
# Required-Stop: $local_fs 
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: dnscrypt-proxy
# Description: dnscrypt-proxy secure DNS client
### END INIT INFO

/usr/local/sbin/dnscrypt-proxy --edns-payload-size=4096 -R dnscrypt.eu-dk -a 127.0.0.1:228 -d

dnscrypt chiffre [quote=“PascalHambourg, post:4, topic:72498”]

  • dnscrypt fait suivre les requêtes DNS chiffrées sur le port ?? de l’adresse ??
    [/quote]

pour répondre a ta question il me semble que dnscrypt s’occupe de l’envoie ET de la reception des requete en chiffré.
unbound lui ne sert de cache dns !

Pitié, formate les blocs de texte !

Tu veux dire de l’envoi des requêtes chiffrées et de la réception des réponses chiffrées ?

Concernant le script, primo, tu n’avais posté qu’un extrait des règles, c’est ce que je voulais voir.
Secundo, un peu de nettoyage : vire tout à partir de “### Couches Sécu…”. Ensuite tu peux ajouter des règles de LOG en INPUT et OUTPUT.
Tertio, iptables-save montre des chaînes vides à ACCEPT et non les règles mises en place par le script. Cela ne m’est d’aucune utilité.

Du fichier de configuration d’unbound, je devine qu’il écoute sur le port 53 et fait suivre les requêtes DNS en clair sur le port 228 de l’adresse de loopback 127.0.0.1 comme je le pensais.

Du script d’init de dnscrypt, je devine qu’il écoute sur le port 228 et l’adresse 127.0.0.1 (là où unbound fait suivre les requêtes), et qu’il s’appuie sur un serveur dnscrypt.eu-dk qui n’existe pas. Il ne manquerait pas un espace avant le tiret ? Dans ce cas, l’option -k attend la clé publique du fournisseur.
Edit : si le problème venait de là, ça ne marcherait pas non plus sans filtrage…

En tout cas ça ne me dit pas à quoi il envoie les requêtes. Peut-être plus d’infos dans le fichier CSV qui contient la liste des serveurs.

il envoie les données au serveur : dnscrypt.eu-dk ( fichier CSV )

" Fri Jan 27 18:28:41 2017 [NOTICE] Proxying from 127.0.0.1:228 to 77.66.84.233:443 "

effectivement si celà venait d’une histoire d’authentification quelqu’on je ne pourrais te répondre en ce moment meme :wink:

je ne comprend pas trop, il y a 4 mois j’avais tout monté ainsi et celà fonctionné sans un accro.

pour iptables-save

# Generated by iptables-save v1.4.21 on Fri Jan 27 18:40:54 2017
*mangle
:PREROUTING ACCEPT [6:711]
:INPUT ACCEPT [6:711]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5:852]
:POSTROUTING ACCEPT [5:852]
COMMIT
# Completed on Fri Jan 27 18:40:54 2017
# Generated by iptables-save v1.4.21 on Fri Jan 27 18:40:54 2017
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [1:60]
:POSTROUTING ACCEPT [1:60]
-A PREROUTING -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.1
-A PREROUTING -p tcp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.1
COMMIT
# Completed on Fri Jan 27 18:40:54 2017
# Generated by iptables-save v1.4.21 on Fri Jan 27 18:40:54 2017
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 228 -j ACCEPT
-A INPUT -p udp -m udp --dport 228 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,PSH,URG FIN,PSH,URG -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j DROP
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -f -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 228 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 228 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -j DROP
COMMIT
# Completed on Fri Jan 27 18:40:54 2017

ménage fait dans mon script init.d :wink:

L’effet du “ménage” ne se voit pas, les règles que j’avais dit de virer sont toujours présentes.
Il faut aussi supprimer les règles DNAT qui ne servent à rien, au contraire puisqu’elles redirigent les requêtes DNS en clair provenant de l’extérieur vers une adresse de loopback, ce qui est interdit.

Si dnscrypt utilise le port 443 en UDP, il faut ajouter une règle dans OUTPUT pour l’autoriser.
Tu peux le vérifier en ajoutant des règles de LOG après avoir supprimé les règles en trop.

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [15:907]
:POSTROUTING ACCEPT [15:907]
COMMIT
# Completed on Fri Jan 27 19:03:13 2017
# Generated by iptables-save v1.4.21 on Fri Jan 27 19:03:13 2017
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:LOGGING - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 228 -j ACCEPT
-A INPUT -p udp -m udp --dport 228 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -j LOGGING
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 228 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 228 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -j LOGGING
-A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: "
-A LOGGING -j DROP
COMMIT

voilà pour le ménage, j’avais déjà tenté de commenter toute la partie sécurité voir si elle n’entrer pas en conflit mais sans résultat

pour logger les paqut droppé j’ai fait ca:

iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A OUTPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

ca convient?

la commande dmesg me donne

=2 
[  731.859240] IPTables-Dropped: IN=wlan0 OUT= MAC=70:18:8b:12:a1:f6:64:7c:34:b8:37:6f:08:00 SRC=216.58.211.14 DST=192.168.1.1 LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=14561 PROTO=TCP SPT=443 DPT=43433 WINDOW=0 RES=0x00 RST URGP=0 
[  731.864780] IPTables-Dropped: IN=wlan0 OUT= MAC=70:18:8b:12:a1:f6:64:7c:34:b8:37:6f:08:00 SRC=216.58.211.14 DST=192.168.1.1 LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=14562 PROTO=TCP SPT=443 DPT=43433 WINDOW=0 RES=0x00 RST URGP=0 

alors là je suis en chine mdrr :sunglasses:
un problème d’interface dans mes chaines ? Oo
pour formater les code en bloc j’ai pas reussie je suis vraiment navré j’ai beau cliquer sur </> et copier mon texte ca n’y fait rien ? -_- pas ma journée ahah

Bonsoir Hector

essaye en mettant avant et après le bloc une ligne ne contenant qu’une suite de 3 “backticks” :

mode block avec les ascenseurs horizontal et vertical et la coloration mode block avec les ascenseurs

ouuuf merci beaucoup @MicP, j’ai refait tous mon poste, il parait plus clair a présent :slight_smile:

Bof, pas trop.
L’emploi d’une chaîne utilisateur était superflu, de même que le DROP final. Quant à la limite sur le LOG, elle est carrément contre-productive puisqu’elle empêche de logger plus de 2 paquets par minute, ce qui n’est rien du tout ! Dans le bruit ambiant tu as toutes les chances de manquer les paquets que tu cherches.

Les deux paquets loggés sont en réception, ont une adresse source qui appartient à Google et ont le drapeau RST. Ce sont probablement des paquets liés à d’anciennes connexions terminées ou expirées et classés dans l’état INVALID.

Je m’excuse par avance de dire une évidence, mais après avoir supprimé la limite, il faudra regarder les logs après avoir fait une tentative de résolution DNS.

il n’y a pas de changement dans dmesg avec et sans parfeu


[   21.654668] wl0: link up (wlan0)
[   23.760937] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=20560 DF PROTO=UDP SPT=59941 DPT=443 LEN=36 
[   23.760976] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=20561 DF PROTO=UDP SPT=59941 DPT=443 LEN=63 
[   28.769356] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=21743 DF PROTO=UDP SPT=59941 DPT=443 LEN=36 
[   29.771291] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=21847 DF PROTO=UDP SPT=56547 DPT=443 LEN=63 
[   34.779284] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=23038 DF PROTO=UDP SPT=56547 DPT=443 LEN=63 
[   57.805580] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=26449 DF PROTO=UDP SPT=54927 DPT=443 LEN=36 
[   83.844725] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=29201 DF PROTO=UDP SPT=58166 DPT=443 LEN=36 
[  119.896449] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=33513 DF PROTO=UDP SPT=53370 DPT=443 LEN=63 
[  149.932770] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=37463 DF PROTO=UDP SPT=60467 DPT=443 LEN=63 
[  154.941207] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=37477 DF PROTO=UDP SPT=60467 DPT=443 LEN=63 
[  159.944653] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=37583 DF PROTO=UDP SPT=60467 DPT=443 LEN=36 
[  159.944691] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=37584 DF PROTO=UDP SPT=60467 DPT=443 LEN=63 
[  162.786950] IPTables-Dropped: IN=wlan0 OUT= MAC=70:18:8b:12:a1:f6:64:7c:34:b8:37:6f:08:00 SRC=163.172.90.35 DST=192.168.1.1 LEN=98 TOS=0x00 PREC=0x00 TTL=56 ID=770 PROTO=TCP SPT=443 DPT=54165 WINDOW=2160 RES=0x00 ACK PSH URGP=0 
[  162.787392] IPTables-Dropped: IN=wlan0 OUT= MAC=70:18:8b:12:a1:f6:64:7c:34:b8:37:6f:08:00 SRC=163.172.90.35 DST=192.168.1.1 LEN=83 TOS=0x00 PREC=0x00 TTL=56 ID=36850 PROTO=TCP SPT=443 DPT=54165 WINDOW=2160 RES=0x00 ACK PSH URGP=0 
[  162.788195] IPTables-Dropped: IN=wlan0 OUT= MAC=70:18:8b:12:a1:f6:64:7c:34:b8:37:6f:08:00 SRC=163.172.90.35 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=56 ID=38245 PROTO=TCP SPT=443 DPT=54165 WINDOW=2160 RES=0x00 ACK FIN URGP=0 
[  164.953112] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=37720 DF PROTO=UDP SPT=60467 DPT=443 LEN=36 
[  174.289773] IPTables-Dropped: IN=wlan0 OUT= MAC=70:18:8b:12:a1:f6:64:7c:34:b8:37:6f:08:00 SRC=163.172.90.35 DST=192.168.1.1 LEN=490 TOS=0x00 PREC=0x00 TTL=56 ID=62209 DF PROTO=TCP SPT=443 DPT=54165 WINDOW=2160 RES=0x00 ACK PSH FIN URGP=0 
[  182.983267] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=38053 DF PROTO=UDP SPT=55028 DPT=443 LEN=63 
[  187.991699] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=38512 DF PROTO=UDP SPT=55028 DPT=443 LEN=63 
[  192.995202] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=38957 DF PROTO=UDP SPT=55028 DPT=443 LEN=36 
[  192.995276] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=38958 DF PROTO=UDP SPT=55028 DPT=443 LEN=63 
[  198.003680] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=39024 DF PROTO=UDP SPT=55028 DPT=443 LEN=36 
[  219.038744] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=41169 DF PROTO=UDP SPT=51283 DPT=443 LEN=63 
[  224.047167] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=41742 DF PROTO=UDP SPT=51283 DPT=443 LEN=63 
[  229.050591] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=41864 DF PROTO=UDP SPT=51283 DPT=443 LEN=36 
[  229.050630] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=41865 DF PROTO=UDP SPT=51283 DPT=443 LEN=63 
[  234.059008] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=42604 DF PROTO=UDP SPT=51283 DPT=443 LEN=36 
[  255.148486] IPTables-Dropped: IN=wlan0 OUT= MAC=01:00:5e:00:00:01:64:7c:34:b8:37:6f:08:00 SRC=192.168.1.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 
[  258.099093] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=44849 DF PROTO=UDP SPT=54381 DPT=443 LEN=63 
[  263.106848] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=45737 DF PROTO=UDP SPT=54381 DPT=443 LEN=63 
[  268.111304] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=46003 DF PROTO=UDP SPT=54381 DPT=443 LEN=36 
[  268.111345] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=46004 DF PROTO=UDP SPT=54381 DPT=443 LEN=63 
[  273.119757] IPTables-Dropped: IN= OUT=wlan0 SRC=192.168.1.1 DST=77.66.84.233 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=46404 DF PROTO=UDP SPT=54381 DPT=443 LEN=36 

Comment ça ? Tu écrivais au début que c’est iptables qui bloquait ?

En tout cas les paquets émis à destination du serveur 77.66.84.233 qui sont loggés correspondent à ce que j’écrivais dans un message précédent :

effetivement en ouvrant le port 443 UDP comme tu me l’as indiqué marche!

iptables -t filter -A OUTPUT -p udp --dport 443 -j ACCEPT

et je suis belle est bien connecté derrière iptables avec unbound et dnscrypt

mais je ne comprend pas!! dnscrypt est sur le port 228, unbound lui sur le port 53 comment se fait t’il qu’il faille ouvrir sur notre parefeu le port du serveur en face??
car si j’ai bien compris tu as eu ta déduction a cause de

dnscrypt-proxy[546]: Proxying from 127.0.0.1:40 to 77.66.84.233:443

la logique m’échappe…

Il faut distinguer les “connexions” entrantes (à destination de la machine) et les connexion sortantes (émises par la machine). Pour autoriser des connexions entrantes, il faut créer des règles dans la chaîne INPUT. Pour autoriser des connexions sortantes, il faut créer des règles dans la chaîne OUTPUT. Cas particulier : les connexions locales de la machine vers elle-même sont à la fois sortantes et entrantes et doivent être autorisées dans les deux chaînes OUTPUT et INPUT.

Unbound reçoit des connexions entrantes sur le port 53 UDP (et occasionnellement TCP pour certaines requêtes DNS) à n’importe quelle adresse locale, et émet des connexions sortantes vers le port 228 UDP (et occasionnellement TCP) à l’adresse 127.0.0.1.

Dnscrypt reçoit des connexions entrantes sur le port 228 UDP (et occasionnellement TCP) à l’adresse locale 127.0.0.1, et émet des connexions sortantes vers le port 443 UDP (et peut-être TCP) à l’adresse 77.66.84.233.

J’observe que tu as mis les mêmes règles dans les chaînes INPUT et OUTPUT. Dans le cas général, cela n’a pas lieu d’être car les connexions entrantes et sortantes à autoriser sont différentes. Un client web a besoin d’autoriser les connexions sortantes HTTP et HTTPS (et DNS) alors qu’un serveur web a besoin d’autoriser les connexions entrantes HTTP et le cas échéant HTTPS. Pour dnscrypt, tu n’as pas eu besoin de créer une règle en INPUT pour autoriser le port 443 UDP en entrée.

Si cette machine ne fait pas tourner un serveur web accessible de l’extérieur, les règles INPUT pour les ports 80 et 443 n’ont pas lieu d’être.

Même chose pour le port 53 si la machine ne reçoit pas de requêtes DNS de l’extérieur (dans ce cas je t’invite aussi à configurer unbound pour n’écouter que sur l’adresse de loopback 127.0.0.1 qui n’est accessible que depuis la machine elle-même). Les communications locales à la machine sont déjà autorisées avec les règles sur l’interface de loopback lo.

Et si les requêtes DNS ne sortent de la machine que sous forme chiffrée via dnscrypt vers le port 443, alors tu n’as pas besoin d’autoriser le port 53 dans OUTPUT.

Toutes les règles pour le port 228 sont aussi superflues puisque les communications sur ce port ne peuvent être que locales à la machine (entre unbound et dnscrypt), dnscrypt n’écoutant que sur l’adresse de loopback 127.0.0.1 qui n’est pas accessible de l’extérieur.

Est-ce clair ? On ne peut pas écrire de bonnes règles iptables si on n’a pas une bonne compréhension des flux réseau en jeu.

1 J'aime

Bonjours @PascalHambourg, merci pour ta dernière réponse qui est très précise et formatrice!
effectivement j’ouvrais vers l’exterieur des port localhost :sweat_smile:

penses tu qu’il sois indispensable d’utiliser les tables NAT et Manggle pour plus de sécurité ou iproute? afin d’éviter des fuites
( oui je vois ton regard d’ici^^ je ne suis pas rendu! mais… le savoir est un long chemin :stuck_out_tongue: )

je précise dans ma config final j’utilise unbound+dnscrypt ssh et sock5 pour firefox

le mélange de tous ca marche niquel mais, j’aimerai eviter des fuites.
(poser une baignoire de luxe est découvrir que ca pisse l’eau de partout c’est pas génial XD)

le tout sur mon tout nouveau kernel! :grin:

root@Kracken:/home/kracken# uname -a
Linux Kracken 4.8.17-grsec #1 SMP  Tue Jan 31 15:11:45 CET 2017 x86_64 GNU/Linux

Les tables nat et mangle ne sont pas prévues pour la sécurité. C’est le rôle de la table filter.
Je ne vois pas le rapport d’iproute avec la sécurité.
Qu’appelles-tu “fuites” ?

salut Pascal,

j’utilise quotidiennemnt unbound et dnscrypt pour ma résolution de dns
ajouter a celà ssh pour ma seedbox (+vps bientot)
et ssh sock5 pour firefox + proxy
quand je suis au boulot impossible me connecter en ssh a cause du parfeu de mon entreprise,

tout marche nickel

mais j’aurais souhaiter etre sur que la stabilité du tout que se soit par une surcouche qui gere lensemble et/ou un monitoring par script ou autre?!

d’ou mes question sur les tables mangle et NAT ainsi que iproute, ne peuvent ils pas m’aider a assurer l’isolement de chacune de mes connections.

sacré calcutta informatisé je te l’accorde^^.