[iptables] Vérification de script

NuX_o · Février 21, 2016, 9:38pm

Bonjour à vous,

Je me suis un peu pris la tête sur les iptables, je crois avoir compris l’essentiel… j’ai donc fait un script que j’ai mis dans mon /etc/init.d/monIptable.

Le voici :

[code]#!/bin/bash

#Script parefeu iptables.

#Interdiction des connexions entrantes et sortantes(toutes)

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

#Log de ce que l’on jette

iptables -N LOG_DROP
iptables -A LOG_DROP -j LOG --log-prefix '[IPTABLES DROP] : ’
iptables -A LOG_DROP -j DROP

iptables -A FORWARD -j LOG_DROP
iptables -A INPUT -j LOG_DROP
iptables -A OUTPUT -j LOG_DROP

#vidage règles existantes
iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -X

#Accept les connexions déjà établies

iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#LOG de ce que l’on accept

iptables -N LOG_ACCEPT
iptables -A LOG_ACCEPT -j LOG --log-prefix '[IPTABLES ACCEPT] : ’
iptables -A LOG_ACCEPT -j ACCEPT

iptables -A FORWARD -j LOG_ACCEPT
iptables -A INPUT -j LOG_ACCEPT
iptables -A OUTPUT -j LOG_ACCEPT

#Accepter ce qui se passe sur le réseau local (lo et lan)

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT
27,1 Haut
[/code]

Lorsque je vérifie si tout est pris en compte :

[code]sudo iptables -L
[sudo] password for toto:
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all – anywhere anywhere state RELATED,ESTABLISHED
LOG_ACCEPT all – anywhere anywhere
ACCEPT all – anywhere anywhere
ACCEPT all – 192.168.0.0/24 anywhere
ACCEPT icmp – anywhere anywhere
ACCEPT udp – anywhere anywhere udp spt:domain
ACCEPT tcp – anywhere anywhere tcp spt:domain
ACCEPT tcp – anywhere anywhere tcp dpt:http
ACCEPT tcp – anywhere anywhere tcp dpt:63598
ACCEPT tcp – anywhere anywhere tcp dpt:urd
ACCEPT tcp – anywhere anywhere tcp dpt:imaps
ACCEPT tcp – anywhere anywhere tcp dpt:ftp-data
ACCEPT tcp – anywhere anywhere tcp dpt:ftp

Chain FORWARD (policy DROP)
target prot opt source destination
LOG_ACCEPT all – anywhere anywhere
ACCEPT all – 192.168.0.0/24 anywhere

Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all – anywhere anywhere state RELATED,ESTABLISHED
LOG_ACCEPT all – anywhere anywhere
ACCEPT all – anywhere anywhere
ACCEPT all – anywhere 192.168.0.0/24
ACCEPT udp – anywhere anywhere udp dpt:domain
ACCEPT tcp – anywhere anywhere tcp dpt:domain
ACCEPT tcp – anywhere anywhere tcp dpt:http
ACCEPT tcp – anywhere anywhere tcp dpt:63598
ACCEPT tcp – anywhere anywhere tcp dpt:urd
ACCEPT tcp – anywhere anywhere tcp dpt:imaps
ACCEPT tcp – anywhere anywhere tcp dpt:ftp-data
ACCEPT tcp – anywhere anywhere tcp dpt:ftp
ACCEPT udp – anywhere ns0.fdn.fr
ACCEPT tcp – anywhere ns0.fdn.org

Chain LOG_ACCEPT (3 references)
target prot opt source destination
LOG all – anywhere anywhere LOG level warning prefix "[IPTABLES ACCEPT] : "
ACCEPT all – anywhere anywhere [/code]

J’ai pourtant un doute…

LOG_ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere

J’ai l’impression que cette ligne autorise tout le trafic, je me trompe ?

Merci à vous !

PascalHambourg · Février 21, 2016, 9:38pm

C’est normal. Dans le cas contraire, c’est que tu as raté quelque chose.

Apparemment la copie de ton script est incomplète, il manque la fin et la dernière ligne n’a rien à y faire. Je suppose une erreur de copier-coller depuis l’éditeur de texte ?

Il y a aussi plusieurs erreurs :

il manque les en-têtes LSB et la forme générale pour que le script s’intègre dans le système d’init (voir /etc/init.d/skeleton)
au début tu crées une chaîne et des règles, puis tu effaces tout
ensuite, tu log et acceptes tout d’abord et tu acceptes sélectivement ensuite, ce qui ne sert à rien puisque tout a déjà été accepté.

Note : pour une meilleure lisibilité (à mon avis), utilises plutôt [mono]iptables-save[/mono] pour afficher le jeu de règles. Si tu n’aimes pas, utilises à défaut [mono]iptables -nvL[/mono] pour afficher les interfaces et ne pas résoudre les adresses et les ports.

NuX_o · Février 21, 2016, 9:38pm

Merci à toi pour la réponse rapide.

mmmmmmmm effectivement j’ai oublié beaucoup de chose, je me repenche sur le magma et je reviens avec cette fois, une copie plus convenable

Merci encore

NuX_o · Février 21, 2016, 9:38pm

humpf ! je me suis repenché sur le tuto du wiki, j’ai voulu être malin et refaire par moi-même… Je comprends déjà la syntaxe (simple) c’est déjà une bonne chose

1 - voici mon /etc/init.d/moniptable.sh modifié :

[code]#!/bin/bash

BEGIN INIT INFO

Provides: iptables

Required-Start:

Should-Start:

Required-Stop:

Should-Stop:

Default-Start: 2 3 4 5

Default-Stop: 0 1 6

Short-description: iptables

Description: Firewall

END INIT INFO

chargement/déchargement d’iptables

case “$1” in
‘start’)
/sbin/iptables-restore < /etc/config_parefeu
RETVAL=$?
;;
‘stop’)
/sbin/iptables-save > /etc/config_parefeu
RETVAL=$?
;;
‘clean’)

clean le parefeu pendant que la machine tourne

ça peut être une faille de sécurite si on l’exécute lors de l’extinction avant l’arrêt des interfaces

pensez à refaire un start après sinon la sauvegarde se fera automatiquement à l’extinction

/sbin/iptables -t filter -F
/sbin/iptables -t nat -F
/sbin/iptables -t mangle -F
/sbin/iptables -t raw -F
/sbin/iptables -t filter -P INPUT ACCEPT
/sbin/iptables -t filter -P OUTPUT ACCEPT
/sbin/iptables -t filter -P FORWARD ACCEPT
/sbin/iptables -t nat -P PREROUTING ACCEPT
/sbin/iptables -t nat -P POSTROUTING ACCEPT
/sbin/iptables -t nat -P OUTPUT ACCEPT
/sbin/iptables -t mangle -P PREROUTING ACCEPT
/sbin/iptables -t mangle -P OUTPUT ACCEPT
/sbin/iptables -t mangle -P POSTROUTING ACCEPT
/sbin/iptables -t mangle -P FORWARD ACCEPT
/sbin/iptables -t mangle -P INPUT ACCEPT
/sbin/iptables -t raw -P OUTPUT ACCEPT
/sbin/iptables -t raw -P PREROUTING ACCEPT
RETVAL=$?
;;
‘restart’)
$0 stop && $0 start
RETVAL=$?
;;
*)
echo “Usage: $0 { start | stop | restart | clean}”
RETVAL=1
;;
esac
exit $RETVAL

#on jette tout ce qui entre, sauf le lo et ce qui sort

iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#OK pour le FTP, SSH, apache, Cups
iptables -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 63598 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 631 -j ACCEPT

iptables -A OUTPUT -p tcp -o eth0 --dport 465 -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport 993 -j ACCEPT
[/code]

Le résultat me laisse circonspect :

[code]iptables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0.0/0
6 702 ACCEPT all – * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
0 0 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:63598
0 0 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:631
0 0 ACCEPT tcp – eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:993

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 7 packets, 698 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – * eth0 0.0.0.0/0 0.0.0.0/0 tcp dpt:465

Chain LOG_ACCEPT (0 references)
pkts bytes target prot opt in out source destination
[/code]

2 - J’ai changé mon port SSH (en le spécifaint dans sshd_conf pour qu’il utilise 63598, est-ce correct ?)

3 - pour mon SMTP (465) je ne l’autorise qu’en sortie (?) et idem pour imap (993) mais en entrée pour lui (?)

4 - Les commandes iptables -nvL ou iptables-save suffisent pour s’assurer que le pare-feu tournent convenablement ?

Merci encore à toi !

PascalHambourg · Février 21, 2016, 9:38pm

Tout ce qui suit la commande [mono]exit[/mono] n’est jamais exécuté.
Le résultat affiché par [mono]iptables -nvL[/mono] correspond néanmoins aux commandes iptables de la fin du script, à l’exception de la chaîne utilisateur LOG_ACCEPT qui reste probablement d’une ancienne configuration mal réinitialisée.

Oui, si sshd écoute bien sur ce port.

Il est inutile d’autoriser des ports spécifiques en sortie puisque tout est autorisé par défaut dans OUTPUT.

Non, elles servent juste à vérifier que les règles actives correspondent à celles que tu veux créer. Il y a une différence entre “ça correspond”, “ça tourne convenablement”, “ça fait ce que tu veux” voire “ça fait ce qu’il faut”.

Aussi, [mono]iptables -L[/mono] n’affiche que la table “filter”, à la différence d’[mono]iptables-save[/mono].

Je déduis de ces règles que ta machine héberge des services FTP, SSH, HTTP, CUPS et IMAPS qui doivent être accessibles de l’extérieur par n’importe quelle interface sauf IMAPS qui ne doit être accessible que par eth0. Et elle doit pouvoir se connecter à n’importe quel service extérieur. Si ce n’est pas le cas, les règles sont erronées.

Note que pour que le serveur FTP puisse fonctionner en mode passif, il faut que le module de suivi de connexion FTP du noyau [mono]nf_conntrack_ftp[/mono] soit chargé et que la connexion de commande sur le port 21 ne soit pas chiffrée (idem pour se connecter depuis la machine à un serveur FTP en mode actif). Sinon, il faut ajouter des règles pour autoriser les connexions entrantes aux ports “passifs”.

NuX_o · Février 21, 2016, 9:38pm

Salut et merci pour tes réponses intéressantes.

J’ai encore quelques questions qui me travaillent…

1 - 1 - Je ne comprends pas quel(s) port(s) utilise mon thunderbird … ça a l’air con, mais voilà : dans les paramètres du logiciel c’est le port 993 en IMAP et mon SMTP le 465.

Quand je fais un netstat j’ai ça :

tcp 0 0 192.168.0.11:46513 ns0.ovh.net:imaps ESTABLISHED tcp 0 0 192.168.0.11:46369 ns0.ovh.net:imaps ESTABLISHED tcp 0 0 192.168.0.11:46443 ns0.ovh.net:imaps ESTABLISHED tcp 0 0 192.168.0.11:46510 ns0.ovh.net:imaps ESTABLISHED tcp 0 0 192.168.0.11:46370 ns0.ovh.net:imaps ESTABLISHED tcp 0 0 192.168.0.11:46512 ns0.ovh.net:imaps ESTABLISHED
ça veut dire qu’il utilise non pas 1 port mais une plage de ports (??) 465XXX Selon thunderbird, 465 c’est le SMTP, ici il me montre IMAPS… je ne comprends pas ^^

Alors comment être sûr d’ouvrir les bons ports ?

2 - [quote]Je déduis de ces règles que ta machine héberge des services FTP, SSH, HTTP, CUPS et IMAPS qui doivent être accessibles de l’extérieur par n’importe quelle interface sauf IMAPS qui ne doit être accessible que par eth0. Et elle doit pouvoir se connecter à n’importe quel service extérieur. Si ce n’est pas le cas, les règles sont erronées.[/quote]

Cela me laisse songeur, bien que je comprennes tout à fait ce que tu veux dire… voilà mes questions :

Pour accéder au web, à mon moteur de recherche favoris, je dois ouvrir les ports 80 en sortie et en entrée (?) en sortie pour faire une demande et en entrée pour recevoir la requête (? je ne sais pas pourquoi mais j’ai l’impression d’avoir louper quelque chose…) si je comprends bien ta phrase, si je ne fais QUE de la navigation, sans serveur HTTP, il ne faut pas que j’ouvre en INPUT le port 80 (??).
Si c’est le cas, je crois que les choses s’éclaircissent un peu…
Ce qui voudrait dire que pour mon Thunderbird, je n’ouvre que le SMTP en sortie (si on par sur le principe que je n’ai pas autorisé tous les OUTPUT) et pas pour mon IMAP , car je n’ai pas un serveur de courriel qui écoute sur ce port… (???)

3 - comment être sûr, mis à part devoir installer un logiciel de test d’intrusion ou de snif, que les ports soient bien fermer ?

4 - Je comprends vite mais je pose des questions un peu … simpliste on va dire

Un grand merci à toi !

PascalHambourg · Février 21, 2016, 9:39pm

Une connexion TCP utilise deux ports : un port côté client et un port côté serveur. Le port côté serveur est fixe et dépend du service (par exemple HTTP=80) ; le port côté client est généralement alloué dynamiquement par le système dans la plage des ports non privilégiés 1024-65535. Quand on fait du filtrage, on ne se préoccupe généralement que du port serveur et pas du port client.

[mono]netstat[/mono] affiche l’adresse et le port locaux d’une part, l’adresse et le port distant d’autre part. Sur le poste client, l’adresse et le port locaux sont ceux du client et l’adresse et le port distants sont ceux du serveur. Sur le serveur, c’est l’inverse.

Le fait que les ports locaux dynamiques soient de la forme 465XX n’est qu’une coïncidente et n’a aucun rapport avec le port 465. C’est le port distant qui compte, ici imaps=993. Tu peux utiliser l’option [mono]-n[/mono] pour afficher les adresses et ports sous forme numérique au lieu de les résoudre.

iptables n’ouvre pas des ports. C’est un filtre de paquets : il applique des règles qui acceptent ou bloquent des paquets en fonctions de critères tels que le protocole, l’adresse source, le port source, l’adresse destination, le port destination, l’état de suivi de connexion…

Pour “accéder au web”, un poste client doit :

envoyer (chaîne OUTPUT) un paquet UDP de requête DNS à destination du port 53 d’un serveur DNS, dans l’état NEW
recevoir (chaîne INPUT) le paquet UDP de réponse en provenance (source) du port 53 du serveur DNS, dans l’état ESTABLISHED
envoyer un paquet TCP SYN de demande de connexion à destination du port 80 du serveur web, dans l’état NEW
recevoir le paquet TCP SYN+ACK d’acceptation de connexion en provenance du port 80 du serveur, dans l’état ESTABLISHED
envoyer le paquet TCP ACK de confirmation d’établissement de la connexion au port 80 du serveur, dans l’état ESTABLISHED
envoyer et recevoir des paquets TCP de données à destination ou provenant du port 80 du serveur, dans l’état ESTABLISHED

Le principe est le même pour les autres protocoles simples basés sur le transport TCP (POP, IMAP, SMTP…). FTP est un peu plus compliqué car il met en oeuvre des connexions de données vers des ports dynamiques qui peuvent être établies du client vers le serveur (mode passif) ou du serveur vers le client (mode actif). Le module du noyau nf_conntrack_ftp sert à aider le suivi de connexion à identifier le paquet initial d’une connexion de données FTP et lui attribue l’état RELATED au lieu de NEW.

Ça dépend de ce que tu entends par “port fermé”.

NuX_o · Février 21, 2016, 9:39pm

Un grand merci pour toutes ces explications ! ça éclaircie pas mal de choses ; suite à ma lecture minutieuse je réalise que ma question sur “les ports fermés” ne veut rien dire, que cette notion est beaucoup trop vague.

Je vais méditer sur tout cela, me pencher sur mon script iptables et faire des tests…

je reviendrai certainement en disant que la lumière m’est enfin apparue

Un grand merci à toi

NuX_o · Février 21, 2016, 9:55pm

Bonjour,

Tout d’abord merci pour tes réponses instructives

J’ai pris le parti au final de faire des règles simplissimes et de bannir la multitudes de ports.

En sommes, tout passera par le SSH (scp, sftp) et pas un port VPN (avec openvpn chiffré.)

voici mon humble script :

[code]sudo iptables -L -v -n
[sudo] password for mayoux:
Chain INPUT (policy DROP 79 pkts bytes target prot opt in 0 0 fail2ban-dovecot tcp – * * 0 0 fail2ban-postfix tcp – * * 5 248 fail2ban-apache-multiport tcp – * 5 248 fail2ban-apache tcp – * * 0 0 fail2ban-ssh-ddos tcp – * 32476 32M fail2ban-pam-generic tcp – * 0 0 fail2ban-ssh tcp – * * 0 0 fail2ban-SSH tcp – * * 0 0 fail2ban-mysqld-auth tcp – * 0 0 fail2ban-dovecot tcp – * * 0 0 fail2ban-postfix tcp – * * 0 0 fail2ban-vsftpd tcp – * * 5 248 fail2ban-apache-multiport tcp – * 5 248 fail2ban-apache tcp – * * 0 0 fail2ban-ssh-ddos tcp – * 32476 32M fail2ban-pam-generic tcp – * 0 0 fail2ban-ssh tcp – * * 0 0 fail2ban-SSH tcp – * * 0 0 fail2ban-mysqld-auth tcp – * 0 0 fail2ban-dovecot tcp – * * 0 0 fail2ban-postfix tcp – * * 0 0 fail2ban-vsftpd tcp – * * 5 248 fail2ban-apache-multiport tcp – * 5 248 fail2ban-apache tcp – * * 0 0 fail2ban-ssh-ddos tcp – * 32476 32M fail2ban-pam-generic tcp – * 0 0 fail2ban-ssh tcp – * * 16 1504 ACCEPT all – lo * 32696 32M ACCEPT all – * * 5 248 ACCEPT tcp – * * 0 0 ACCEPT tcp – * * packets, 9244 bytes)
out source destination
0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587,143,220,993,110,995
0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587
* 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443
0.0.0.0/0 0.0.0.0/0 multiport dports 80,443
* 0.0.0.0/0 0.0.0.0/0 multiport dports 63598
* 0.0.0.0/0 0.0.0.0/0
0.0.0.0/0 0.0.0.0/0 multiport dports 63598
0.0.0.0/0 0.0.0.0/0 tcp dpt:22
* 0.0.0.0/0 0.0.0.0/0 multiport dports 3306
0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587,143,220,993,110,995
0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587
0.0.0.0/0 0.0.0.0/0 multiport dports 21,20,990,989
* 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443,80,443
0.0.0.0/0 0.0.0.0/0 multiport dports 80,443,80,443
* 0.0.0.0/0 0.0.0.0/0 multiport dports 22,63598
* 0.0.0.0/0 0.0.0.0/0
0.0.0.0/0 0.0.0.0/0 multiport dports 33598
0.0.0.0/0 0.0.0.0/0 tcp dpt:22
* 0.0.0.0/0 0.0.0.0/0 multiport dports 3306
0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587,143,220,993,110,995
0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587
0.0.0.0/0 0.0.0.0/0 multiport dports 21,20,990,989
* 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443,80,443
0.0.0.0/0 0.0.0.0/0 multiport dports 80,443,80,443
* 0.0.0.0/0 0.0.0.0/0 multiport dports 22,63598
* 0.0.0.0/0 0.0.0.0/0
0.0.0.0/0 0.0.0.0/0 multiport dports 33598
0.0.0.0/0 0.0.0.0/0
0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0.0.0.0/0 0.0.0.0/0 tcp dpt:32491

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 23948 packets, 2405K bytes)
pkts bytes target prot opt in out source destination

Chain fail2ban-SSH (2 references)
pkts bytes target prot opt in out source destination

Chain fail2ban-apache (3 references)
pkts bytes target prot opt in out source destination
15 744 RETURN all – * * 0.0.0.0/0 0.0.0.0/0

Chain fail2ban-apache-multiport (3 references)
pkts bytes target prot opt in out source destination
15 744 RETURN all – * * 0.0.0.0/0 0.0.0.0/0

Chain fail2ban-dovecot (3 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all – * * 0.0.0.0/0 0.0.0.0/0

Chain fail2ban-mysqld-auth (2 references)
pkts bytes target prot opt in out source destination

Chain fail2ban-pam-generic (3 references)
pkts bytes target prot opt in out source destination
97428 96M RETURN all – * * 0.0.0.0/0 0.0.0.0/0

Chain fail2ban-postfix (3 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all – * * 0.0.0.0/0 0.0.0.0/0

Chain fail2ban-ssh (3 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all – * * 0.0.0.0/0 0.0.0.0/0
[/code]

par contre il y a une réitération des règles de fail2ban ^^ pourtant, un [mono]ps aux |grep fail2ban[/mono] ne me donne qu’une instance qui tourne sur le poste

Est-ce que ces règles te semblent convenables ?

J’ai choisi d’ajouter fail2ban pour bannir des IPs trop insistants Je me suis longtemps demandé si ce n’était pas récurrent avec mes règles, vu que fail2ban utilise déjà iptables… j’ai décidé, après quelqus lectures que les deux pouvaient cohabiter et ne faisaient pas forcément la même chose

Désolé du délais de réponse, il me fallait un ptit temps de digestion…

PascalHambourg · Février 21, 2016, 9:55pm

La sortie d’[mono]iptables -L[/mono] est illisible. Utilise plutôt [mono]iptables-save[/mono].

NuX_o · Février 21, 2016, 9:55pm

:INPUT DROP [127:13060] :FORWARD DROP [0:0] :OUTPUT ACCEPT [51180:7821206] :fail2ban-SSH - [0:0] :fail2ban-apache - [0:0] :fail2ban-apache-multiport - [0:0] :fail2ban-dovecot - [0:0] :fail2ban-mysqld-auth - [0:0] :fail2ban-pam-generic - [0:0] :fail2ban-postfix - [0:0] :fail2ban-ssh - [0:0] :fail2ban-ssh-ddos - [0:0] :fail2ban-vsftpd - [0:0] -A INPUT -p tcp -m multiport --dports 25,465,587,143,220,993,110,995 -j fail2ban-dovecot -A INPUT -p tcp -m multiport --dports 25,465,587 -j fail2ban-postfix -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-multiport -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache -A INPUT -p tcp -m multiport --dports 63598 -j fail2ban-ssh-ddos -A INPUT -p tcp -j fail2ban-pam-generic -A INPUT -p tcp -m multiport --dports 63598 -j fail2ban-ssh -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH -A INPUT -p tcp -m multiport --dports 3306 -j fail2ban-mysqld-auth -A INPUT -p tcp -m multiport --dports 25,465,587,143,220,993,110,995 -j fail2ban-dovecot -A INPUT -p tcp -m multiport --dports 25,465,587 -j fail2ban-postfix -A INPUT -p tcp -m multiport --dports 21,20,990,989 -j fail2ban-vsftpd -A INPUT -p tcp -m multiport --dports 80,443,80,443 -j fail2ban-apache-multiport -A INPUT -p tcp -m multiport --dports 80,443,80,443 -j fail2ban-apache -A INPUT -p tcp -m multiport --dports 22,63598 -j fail2ban-ssh-ddos -A INPUT -p tcp -j fail2ban-pam-generic -A INPUT -p tcp -m multiport --dports 63598 -j fail2ban-ssh -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH -A INPUT -p tcp -m multiport --dports 3306 -j fail2ban-mysqld-auth -A INPUT -p tcp -m multiport --dports 25,465,587,143,220,993,110,995 -j fail2ban-dovecot -A INPUT -p tcp -m multiport --dports 25,465,587 -j fail2ban-postfix -A INPUT -p tcp -m multiport --dports 21,20,990,989 -j fail2ban-vsftpd -A INPUT -p tcp -m multiport --dports 80,443,80,443 -j fail2ban-apache-multiport -A INPUT -p tcp -m multiport --dports 80,443,80,443 -j fail2ban-apache -A INPUT -p tcp -m multiport --dports 22,63598 -j fail2ban-ssh-ddos -A INPUT -p tcp -j fail2ban-pam-generic -A INPUT -p tcp -m multiport --dports 63598 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 62491 -j ACCEPT -A fail2ban-apache -j RETURN -A fail2ban-apache-multiport -j RETURN -A fail2ban-dovecot -j RETURN -A fail2ban-pam-generic -j RETURN -A fail2ban-postfix -j RETURN -A fail2ban-ssh -j RETURN -A fail2ban-ssh-ddos -j RETURN COMMIT

Merci à toi

PascalHambourg · Février 21, 2016, 9:55pm

Objectivement, c’est beaucoup plus lisible ainsi, non ?
Si on fait abstraction de toutes les règles et chaînes créées par fail2ban, il ne reste pas grand-chose. En substance, sont autorisés :

les communications sur l’interface de loopback (classique),
les connexions sortantes,
les connexions entrantes sur les ports TCP 80 (HTTP) et 62491 (SSH ?),
les paquets entrants liés à des connexions existantes.

iptables et fail2ban font des choses différentes, en effet. fail2ban se sert d’iptables pour appliquer ses bannissements.

Je ne sais pas pourquoi les mêmes règles de fail2ban se répètent plusieurs fois. En tout cas ce n’est pas parce que le processus fail2ban ne tourne plus que ces règles vont être supprimées. A part charger un peu le listing, ce n’est pas très grave. Par contre, je vois que la plupart des règles de fail2ban concernent des ports qui ne sont pas autorisés par tes propres règles, donc ne servent à rien à part t’auto-bloquer. Inversement, l’accès au port 62491 qui est autorisé en entrée ne peut pas être bloqué par fail2ban.

NuX_o · Février 21, 2016, 9:55pm

C’est beaucoup plus lisible, effectivement, il faudrait que je perde l’habitude d’utiliser iptables -L.

Tout est juste ^^, SSH nous propose beaucoup d’outil chiffré sur un même port, sur le plan sécurité, ça restreint le nombre de ports ouverts

Concernant des ports inutiles, je suis d’accord avec toi, j’ai passé plusieurs fois en revue le jail.local, je ne comprends toujours pas… ça ne peut pas faire de mal je me dis

y a t-il une utilité réelle de bloquer en OUTPUT, me le conseils-tu ?
Est-ce pour prévenir d’un logiciel espion qui enverrait des données (piratage, vol de données privés, tracker…) ou plutôt réservé à un proxy/passerelle ? (ou les deux ?)

Merci, grâce à tes explications j’ai une vue plus clair sur iptables… je comprend vite mais faut m’expliquer longtemps

Merci encore

aytine · Février 21, 2016, 9:55pm

[quote]y a t-il une utilité réelle de bloquer en OUTPUT, me le conseils-tu ?
Est-ce pour prévenir d’un logiciel espion qui enverrait des données (piratage, vol de données privés, tracker…) ou plutôt réservé à un proxy/passerelle ? (ou les deux ?)
[/quote]

Un bon pare-feu est un pare-feu bien configuré. En substance ça ne peux que te faire du bien pour la pratique de configurer également les OUTPUT.
En réalité, si tu viens à te faire infecter, le logiciel espion aura en règle générale moyen de sortir quelque soit tes règles de filtrage (une fois sur la machine il a souvent facilement accès au root).
A toi de voir si tu veux faire les choses correctement du début à la fin.