# Iptables : pourquoi les règles par défaut de drop ne marchent pas ?

**URL:** <https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184>\
**Category:** Support Debian\
**Created:** [Décembre 12, 2018, 9:30 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184 "2018-12-12T09:30:07Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\
**Post date:** [Décembre 12, 2018, 9:30 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/1 "2018-12-12T09:30:07Z")

</div>

Bonjours,

j’ai un truc plutôt etrange si je fait la police par defaut:

```nohighlight
Chain INPUT (policy DROP 0 packets, 0 bytes)

```

Cela ne marche pas ! ?

j’ai donc ajouter et je precise bien que la règle est la dernière:

```nohighlight
iptables -A INPUT -j DROP

```

le resulta est le suivant:

```nohighlight
62 5 360 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

```

la ligne qui précède qui donc log est fait avec le paquet `ulog2` de cette manière.

```nohighlight
iptables -A INPUT -m limit --limit 10/h --limit-burst 2 -j NFLOG --nflog-group 2 --nflog-prefix "LINPUT"

```

curieusement sur une autre machine cela fonctionne, j’ai donc un paramètre quelque par qui fait passer les paquet …??  
Merci d’avance

---

<div class="post-metadata">

**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\
**Post date:** [Décembre 12, 2018, 9:53 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/2 "2018-12-12T09:53:47Z")

</div>

Bonjour,

Tout d’abord, “policy” en anglais se traduit par “politique”.

Si tu veux que l’on puisse comprendre l’éventuel soucis, il faudrait que tu fournisse la chaîne `INPUT` au complet avec la commande :

```nohighlight
sudo iptables --line-numbers -nvx -t filter -L INPUT

```

–  
AnonymousCoward

---

<div class="post-metadata">

**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\
**Post date:** [Décembre 12, 2018, 11:27 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/3 "2018-12-12T11:27:30Z")

</div>

> [@AnonymousCoward](#):
>
> ```plaintext
> iptables --line-numbers -nvx -t filter -L INPUT
> 
> ```

mouai je croit pas non

```plaintext
iptables --line-numbers -nvx -t filter -L INPUT |wc -l
64

```

c’est lier a la cible `ulog2` mai je pige pas pourquoi ☹

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 12, 2018, 12:14 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/4 "2018-12-12T12:14:40Z")

</div>

> [@panthere](#):
>
> Cela ne marche pas

Qu’est-ce qui ne marche pas précisément ?

> [@AnonymousCoward](#):
>
> iptables --line-numbers -nvx -t filter -L INPUT

A mon avis la sortie de -S serait plus lisible que -L.

> [@panthere](#):
>
> je croit pas non

Alors tant pis, on ne peut rien pour toi.

---

<div class="post-metadata">

**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\
**Post date:** [Décembre 12, 2018, 2:00 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/5 "2018-12-12T14:00:11Z")

</div>

Bon voila des nouvelles.

le coupable c’est très clairement `ulog2` , je veux bien coller 64 ligne mai franchement c est inutile.

pourquoi. ?  
alors c’est simple:  
avec :

```nohighlight
- j "NFLOG --nflog-group 0 --nflog-prefix "

```

ça log j’ai les entrées dans le fichier `/var/log/ulog/syslogemu.log`  
mai la politique `drop` rien !  
Avec:

```nohighlight
NFLOG --nflog-group 1 --nflog-prefix 

```

ça ne fait rien du tout

```nohighlight
NFLOG --nflog-group 2 --nflog-prefix 

```

ça fait rien du tout

ensuite sa coupe la connextion `ssh` …

```nohighlight
 cat /etc/ulogd.conf
# Example configuration for ulogd
# Adapted to Debian by Achilleas Kotsis <achille@debian.gr>

[global]
######################################################################
# GLOBAL OPTIONS
######################################################################

# logfile for status messages
logfile="syslog"

# loglevel: debug(1), info(3), notice(5), error(7) or fatal(8) (default 5)
loglevel=3

######################################################################
# PLUGIN OPTIONS
######################################################################

# We have to configure and load all the plugins we want to use

# general rules:
#
# 0. don't specify any plugin for ulogd to load them all
# 1. load the plugins _first_ from the global section
# 2. options for each plugin in seperate section below

#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inppkt_NFLOG.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inppkt_ULOG.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inppkt_UNIXSOCK.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inpflow_NFCT.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_IFINDEX.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_IP2STR.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_IP2BIN.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_IP2HBIN.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_PRINTPKT.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_HWHDR.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_PRINTFLOW.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_filter_MARK.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_LOGEMU.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_SYSLOG.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_XML.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_SQLITE3.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_GPRINT.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_NACCT.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_PCAP.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_PGSQL.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_MYSQL.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_DBI.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_raw2packet_BASE.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_inpflow_NFACCT.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_GRAPHITE.so"
#plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_JSON.so"

# this is a stack for logging packet send by system via LOGEMU
stack=log1:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,emu1:LOGEMU

# this is a stack for packet-based logging via LOGEMU
#stack=log2:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,emu1:LOGEMU

# this is a stack for ULOG packet-based logging via LOGEMU
#stack=ulog1:ULOG,base1:BASE,ip2str1:IP2STR,print1:PRINTPKT,emu1:LOGEMU

# this is a stack for packet-based logging via LOGEMU with filtering on MARK
#stack=log2:NFLOG,base1:BASE,mark1:MARK,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,emu1:LOGEMU

# this is a stack for packet-based logging via GPRINT
#stack=log1:NFLOG,gp1:GPRINT

# this is a stack for flow-based logging via LOGEMU
#stack=ct1:NFCT,ip2str1:IP2STR,print1:PRINTFLOW,emu1:LOGEMU

# this is a stack for flow-based logging via GPRINT
#stack=ct1:NFCT,gp1:GPRINT

# this is a stack for flow-based logging via XML
#stack=ct1:NFCT,xml1:XML

# this is a stack for logging in XML
#stack=log1:NFLOG,xml1:XML

# this is a stack for accounting-based logging via XML
#stack=acct1:NFACCT,xml1:XML

# this is a stack for accounting-based logging to a Graphite server
#stack=acct1:NFACCT,graphite1:GRAPHITE

# this is a stack for NFLOG packet-based logging to PCAP
#stack=log2:NFLOG,base1:BASE,pcap1:PCAP

# this is a stack for logging packet to MySQL
#stack=log2:NFLOG,base1:BASE,ifi1:IFINDEX,ip2bin1:IP2BIN,mac2str1:HWHDR,mysql1:MYSQL

# this is a stack for logging packet to PGsql after a collect via NFLOG
#stack=log2:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,mac2str1:HWHDR,pgsql1:PGSQL

# this is a stack for logging packet to JSON formatted file after a collect via NFLOG
#stack=log2:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,mac2str1:HWHDR,json1:JSON

# this is a stack for logging packets to syslog after a collect via NFLOG
#stack=log3:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,sys1:SYSLOG

# this is a stack for logging packets to syslog after a collect via NuFW
#stack=nuauth1:UNIXSOCK,base1:BASE,ip2str1:IP2STR,print1:PRINTPKT,sys1:SYSLOG

# this is a stack for flow-based logging to MySQL
#stack=ct1:NFCT,ip2bin1:IP2BIN,mysql2:MYSQL

# this is a stack for flow-based logging to PGSQL
#stack=ct1:NFCT,ip2str1:IP2STR,pgsql2:PGSQL

# this is a stack for flow-based logging to PGSQL without local hash
#stack=ct1:NFCT,ip2str1:IP2STR,pgsql3:PGSQL

# this is a stack for flow-based logging to SQLITE3
#stack=ct1:NFCT,sqlite3_ct:SQLITE3

# this is a stack for logging packet to SQLITE3
#stack=log1:NFLOG,sqlite3_pkt:SQLITE3

# this is a stack for flow-based logging in NACCT compatible format
#stack=ct1:NFCT,ip2str1:IP2STR,nacct1:NACCT

# this is a stack for accounting-based logging via GPRINT
#stack=acct1:NFACCT,gp1:GPRINT

[ct1]
#netlink_socket_buffer_size=217088
#netlink_socket_buffer_maxsize=1085440
#netlink_resync_timeout=60 # seconds to wait to perform resynchronization
#pollinterval=10 # use poll-based logging instead of event-driven
# If pollinterval is not set, NFCT plugin will work in event mode
# In this case, you can use the following filters on events:
#accept_src_filter=192.168.1.0/24,1:2::/64 # source ip of connection must belong to these networks
#accept_dst_filter=192.168.1.0/24 # destination ip of connection must belong to these networks
#accept_proto_filter=tcp,sctp # layer 4 proto of connections

[ct2]
#netlink_socket_buffer_size=217088
#netlink_socket_buffer_maxsize=1085440
#reliable=1 # enable reliable flow-based logging (may drop packets)
hash_enable=0

# Logging of system packet through NFLOG
[log1]
# netlink multicast group (the same as the iptables --nflog-group param)
# Group O is used by the kernel to log connection tracking invalid message
group=0
#netlink_socket_buffer_size=217088
#netlink_socket_buffer_maxsize=1085440
# set number of packet to queue inside kernel
#netlink_qthreshold=1
# set the delay before flushing packet in the queue inside kernel (in 10ms)
#netlink_qtimeout=100

# packet logging through NFLOG for group 1
[log2]
# netlink multicast group (the same as the iptables --nflog-group param)
group=1 # Group has to be different from the one use in log1
#netlink_socket_buffer_size=217088
#netlink_socket_buffer_maxsize=1085440
# If your kernel is older than 2.6.29 and if a NFLOG input plugin with
# group 0 is not used by any stack, you need to have at least one NFLOG
# input plugin with bind set to 1. If you don't do that you may not
# receive any message from the kernel.
#bind=1

# packet logging through NFLOG for group 2, numeric_label is
# set to 1
[log3]
# netlink multicast group (the same as the iptables --nflog-group param)
group=2 # Group has to be different from the one use in log1/log2
numeric_label=1 # you can label the log info based on the packet verdict
#netlink_socket_buffer_size=217088
#netlink_socket_buffer_maxsize=1085440
#bind=1

[ulog1]
# netlink multicast group (the same as the iptables --ulog-nlgroup param)
nlgroup=1
#numeric_label=0 # optional argument

[nuauth1]
socket_path="/tmp/nuauth_ulogd2.sock"

[emu1]
file="/var/log/ulog/syslogemu.log"
sync=1

[op1]
file="/var/log/ulog/oprint.log"
sync=1

[gp1]
file="/var/log/ulog/gprint.log"
sync=1
timestamp=1

[xml1]
directory="/var/log/ulog/"
sync=1

[json1]
sync=1
#file="/var/log/ulog/ulogd.json"
#timestamp=0
# device name to be used in JSON message
#device="My awesome Netfilter firewall"
# If boolean_label is set to 1 then the numeric_label put on packet
# by the input plugin is coding the action on packet: if 0, then
# packet has been blocked and if non null it has been accepted.
#boolean_label=1
# Uncomment the following line to use JSON v1 event format that
# can provide better compatility with some JSON file reader.
#eventv1=1

[pcap1]
#default file is /var/log/ulogd.pcap
#file="/var/log/ulog/ulogd.pcap"
sync=1

[mysql1]
db="nulog"
host="localhost"
user="nupik"
table="ulog"
pass="changeme"
procedure="INSERT_PACKET_FULL"
# backlog configuration:
# set backlog_memcap to the size of memory that will be
# allocated to store events in memory if data is temporary down
# and insert them when the database came back.
#backlog_memcap=1000000
# number of events to insert at once when backlog is not empty
#backlog_oneshot_requests=10

[mysql2]
db="nulog"
host="localhost"
user="nupik"
table="conntrack"
pass="changeme"
procedure="INSERT_CT"

[pgsql1]
db="nulog"
host="localhost"
user="nupik"
table="ulog"
#schema="public"
pass="changeme"
procedure="INSERT_PACKET_FULL"
# connstring can be used to define PostgreSQL connection string which
# contains all parameters of the connection. If set, this value has
# precedence on other variables used to build the connection string.
# See http://www.postgresql.org/docs/9.2/static/libpq-connect.html#LIBPQ-CONNSTRING
# for a complete description of options.
#connstring="host=localhost port=4321 dbname=nulog user=nupik password=changeme"
#backlog_memcap=1000000
#backlog_oneshot_requests=10
# If superior to 1 a thread dedicated to SQL request execution
# is created. The value stores the number of SQL request to keep
# in the ring buffer
#ring_buffer_size=1000

[pgsql2]
db="nulog"
host="localhost"
user="nupik"
table="ulog2_ct"
#schema="public"
pass="changeme"
procedure="INSERT_CT"

[pgsql3]
db="nulog"
host="localhost"
user="nupik"
table="ulog2_ct"
#schema="public"
pass="changeme"
procedure="INSERT_OR_REPLACE_CT"

[pgsql4]
db="nulog"
host="localhost"
user="nupik"
table="nfacct"
#schema="public"
pass="changeme"
procedure="INSERT_NFACCT"

[dbi1]
db="ulog2"
dbtype="pgsql"
host="localhost"
user="ulog2"
table="ulog"
pass="ulog2"
procedure="INSERT_PACKET_FULL"

[sqlite3_ct]
table="ulog_ct"
db="/var/log/ulog/ulogd.sqlite3db"

[sqlite3_pkt]
table="ulog_pkt"
db="/var/log/ulog/ulogd.sqlite3db"

[sys2]
facility=LOG_LOCAL2

[nacct1]
sync = 1
#file = /var/log/ulog/nacct.log

[mark1]
mark = 1

[acct1]
pollinterval = 2
# If set to 0, we don't reset the counters for each polling (default is 1).
#zerocounter = 0
# Set timestamp (default is 0, which means not set). This timestamp can be
# interpreted by the output plugin.
#timestamp = 1

[graphite1]
host="127.0.0.1"
port="2003"
# Prefix of data name sent to graphite server
prefix="netfilter.nfacct"

```

ce fichier est celui par défaut du système.

Merci pour vos réponse 🙂

---

<div class="post-metadata">

**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\
**Post date:** [Décembre 12, 2018, 2:35 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/6 "2018-12-12T14:35:21Z")

</div>

Bonjour,

Je suis perdu, on parle d’`iptables` ou d’autre chose ?

---

<div class="post-metadata">

**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\
**Post date:** [Décembre 12, 2018, 4:08 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/7 "2018-12-12T16:08:53Z")

</div>

> Je suis perdu, on parle d’ `iptables` ou d’autre chose ?  
> un gps alors 😃

```plaintext
aptitude show ulogd2
Paquet : ulogd2
Version : 2.0.7-1
État: installé
Automatiquement installé: non
Priorité : optionnel
Section : net
Responsable : Debian Netfilter Packaging Team <pkg-netfilter-team@lists.alioth.debian.org>
Architecture : amd64
Taille décompressée : 581 k
Dépend: adduser, lsb-base, libc6 (>= 2.15), libmnl0 (>= 1.0.3-4~), libnetfilter-acct1, libnetfilter-conntrack3,
        libnetfilter-log1, libnfnetlink0
Suggère: ulogd2-dbi, ulogd2-json, ulogd2-mysql, ulogd2-pcap, ulogd2-pgsql, ulogd2-sqlite3
Description : démon de journalisation pour Netfilter en espace utilisateur
 Ulogd est un démon perfectionné de journalisation pour Netfilter. Il peut agir comme remplaçant de syslog pour
 les violations des règles de Netfilter (à l’aide des cibles iptables NFLOG ou ULOG). Il peut collecter les
 comptes rendus par connexion en utilisant NFCT ou par règle en utilisant NFACCT. La sortie peut être dirigée
 vers des journaux en texte pur, divers formats de base de données SQL, des fichiers XML, des fichiers pcap,
 syslog et bien d’autres formats.

 Les prises en charge de la couche d’abstraction de base de données DBI et des bases de données MySQL,
 PostgreSQL et SQLite 3 sont dans des paquets séparés appelés ulogd2-dbi, ulogd2-mysql, ulogd2-pgsql et
 ulogd2-sqlite3 respectivement. La prise en charge pour l’écriture dans des fichiers JSON est dans le paquet
 ulogd2-json. La prise en charge pour l’écriture dans des fichiers pcap est dans le paquet ulogd2-pcap.
Site : https://www.netfilter.org/projects/ulogd/

```

si tu veux plus de détail pas problème 🙂

---

<div class="post-metadata">

**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\
**Post date:** [Décembre 12, 2018, 6:00 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/8 "2018-12-12T18:00:24Z")

</div>

Je suis désolé mais je ne vois toujours pas le rapport entre `ulogd2` et ton poste original… Tu parles d’un problème avec des règles `iptables`… Malheureusement pour toi, tu ne les fournis pas, comment veux-tu qu’on t’aide ?

---

<div class="post-metadata">

**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\
**Post date:** [Décembre 12, 2018, 7:07 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/9 "2018-12-12T19:07:29Z")

</div>

> [@sk4hrr](#):
>
> `ulogd2`

c’est la configuration ulogd2 qui ser a remplacer la cible -j LOG donc en rapport avec iptables, ce qui faut comprendre c est ce que ulog (nflog) fait rien d’autre.

je devrai peut être changer le titre et l’inverser, avec un titre comme ceci:  
gestion des log grace à ulogd2…

Ce qui reviens exactement aux même c’est le même service qui concerne donc iptables plus claire je ne peux pas faire,

Fournir les règles c 'est fait il n’y en a qu’une seul qui concerne ce paquet et c’est la CIBLE

`-j NFLOG --nflog-group 2 --nflog-prefix `

je parle toujours pas assez claire :

> **[!netdoc.net](https://www.inetdoc.net/guides/iptables-tutorial/ulogtarget.html)**
>
> Découvrez les articles, guides et travaux pratiques sur l'administration système et réseau en utilisant du logiciel libre

ce qui fait que sa logue pas visiblement c’est le numéro du groupe !  
–nflog-group 2 \<======\< ici

j’ai tester les trois valeur comme citer plus haut .

Il y a 64 ligne ,  
Il y en qu’une seul qui possed cette syntaxe qui est pour moi la souce du problème  
elle est bien prise en compte puisque qu’avec un --nflog-group 0 sa fait le boulot . mai derrière les politiques ne fonctionne plus .

---

<div class="post-metadata">

**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\
**Post date:** [Décembre 13, 2018, 11:12 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/10 "2018-12-13T11:12:44Z")

</div>

Tu utilises iptables pour envoyer des paquets IP vers NFLOG, NFLOG étant un système de files d’attente, au pluriel. L’identifiant de la file d’attente utilisée est le numéro de groupe NFLOG.  
Bien évidemment, le contenu de la file d’attente NFLOG est censé être traité par une application, ce qui permet ensuite aux paquets de poursuivre leur parcours dans la chaîne iptables.

Tu utilises le logiciel ulogd2 pour traiter le contenu de la file d’attente. Et tu as forcément lu dans la documentation que ce logiciel utilise un concept de “stack”, que je qualifierais plutôt de pipeline, pour organiser le traitement des données.  
Ces stacks sont définies avec un ensemble de couples nom:type séparés par des virgules. Comme la seule stack activée dans la configuration par défaut de ulogd2 :  
`stack=log1:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,emu1:LOGEMU`

On voit ici que le premier couple, d’entrée dans ulogd2, a comme nom “log1” et comme type “NFLOG”.  
Et si tu parcours le fichier de configuration de ulogd2 jusqu’à [log1] qui est la configuration de l’entrée log1 , tu peux voir que cela utilise le numéro de groupe NFLOG 0 , qui est d’ailleurs indiqué comme étant un numéro de groupe NFLOG bien particulier.

Je peux donc imaginer que pour résoudre tes problèmes il faut que ulogd2 soit configuré avec une stack traitant un groupe NFLOG autre que le 0 . Puis que via une règle iptables tu envoie des paquets sur le groupe en question.

Si avec iptables tu envoie des paquets sur un groupe NFLOG qui n’est jamais traité (par ulogd2 ou autre logiciel), il est possible que les paquets ne soient jamais renvoyés à iptables et ne soient donc jamais traités via la politique par défaut de la règle INPUT.  
Je n’ai pas vérifié cela, je compte sur toi pour le faire.

–  
AnonymousCoward

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 13, 2018, 8:55 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/11 "2018-12-13T20:55:09Z")

</div>

> [@AnonymousCoward](#):
>
> le contenu de la file d’attente NFLOG est censé être traité par une application, ce qui permet ensuite aux paquets de poursuivre leur parcours dans la chaîne iptables.

Je doute fort que le sort des paquets dépende ainsi du bon vouloir d’une application. Il s’agit de log, pas de traitement sur le paquet lui-même. La page de manuel spécifie explicitement :

> Like LOG, this is a non-terminating target, i.e. rule traversal continues at the next rule.

Tu ne confondrais pas avec la cible NFQUEUE ?

> [@AnonymousCoward](#):
>
> Si avec iptables tu envoie des paquets sur un groupe NFLOG qui n’est jamais traité (par ulogd2 ou autre logiciel), il est possible que les paquets ne soient jamais renvoyés à iptables et ne soient donc jamais traités via la politique par défaut de la règle INPUT.

Dans ce cas le résultat serait équivalent à un DROP. Or @panthere semble dire que ce n’est pas ce qui se passe.

---

<div class="post-metadata">

**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\
**Post date:** [Décembre 14, 2018, 1:34 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/12 "2018-12-14T01:34:14Z")

</div>

Bon c’est bien simple sa marche pas comme je le voudrai, et surtout sujet délica car c’est quand même un sacrer danger.  
j’ai donc mis un règle de drop juste après et la sa marche (mai pas la politique ,logique…).  
Je vai voir si il y a aurait pas autre chose que ulogd2. j’imagine que c’est destiner a mettre les information dans une base de donnée , ce qui n’est pas mon but, mai juste de loguer dans un fichier différent,

je laisse le topic ouvert , mai je pense sérieusement a me tourner ver autre chose.

Merci tous de m’avoir aider 🙂

---

<div class="post-metadata">

**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\
**Post date:** [Décembre 14, 2018, 5:49 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/13 "2018-12-14T17:49:24Z")

</div>

Comme je l’ai écrit, je n’ai pas vérifié.

Aussi, je suis ravi que tu te proposes pour tester tout cela et je suis impatient de lire tes résultats.

–  
AnonymousCoward

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 14, 2018, 8:02 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/14 "2018-12-14T20:02:18Z")

</div>

Je n’ai rien proposé du tout.  
J’ai juste testé de créer une règle avec la cible NFLOG qui prend tous les paquets, sans démon ulog2, et ça n’a pas empêché les paquets de continuer leur chemin.

---

<div class="post-metadata">

**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\
**Post date:** [Décembre 15, 2018, 4:05 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/15 "2018-12-15T04:05:56Z")

</div>

Et avec le démon tu as le même résulta ?  
Chez moi il était charger ?

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 15, 2018, 12:32 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/16 "2018-12-15T12:32:06Z")

</div>

> [@panthere](#):
>
> Et avec le démon tu as le même résulta ?

ulog2 n’est pas installé et je ne l’installerai pas sur cette machine à usage bureautique. Ça devra attendre que je sois sur une machine de test, si j’y pense.

> [@panthere](#):
>
> Chez moi il était charger ?

Comment veux-tu que je le sache ?

---

<div class="post-metadata">

**Author:** ![panthere](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/5daacb/32.png) [@panthere](https://www.debian-fr.org/u/panthere)\
**Post date:** [Décembre 17, 2018, 5:41 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/17 "2018-12-17T05:41:50Z")

</div>

> Comment veux-tu que je le sache ?

faute de frappe moi = toi 😓

Chez toi il était charger ?  
pas de souci en attendant je suis revenu a la version de base avec la cible LOG , mai le problème persiste . plutôt étrange . Du coup j’ai rajouter les règles qu’il faut je vai attendre une version de kernel plus ressente pour voir si le souci ne viens pas de la.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 22, 2018, 7:57 UTC](https://www.debian-fr.org/t/iptables-pourquoi-les-regles-par-defaut-de-drop-ne-marchent-pas/78184/18 "2018-12-22T19:57:24Z")

</div>

> [@panthere](#):
>
> Chez toi il était charger ?

Comme je l’ai écrit, ulog2 n’est pas installé sur cette machine donc il aurait eu du mal à être chargé.
