Firewall linux (iptables)

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Firewall linux (iptables)

MorgenDavid

Voici Mon Firewall

Il est déjà très efficace.

Si vous avez des idées pour l'améliorer davantage....

Hardware

Impressionnant, j'en ai jamais vu un aussi complet sur internet

Sinon 2 choses :

- Pourquoi ne pas mettre les règles sysctl directement dans /etc/sysctl.d/xx-rules.conf par exemple ? Ça me semble plus adapté de les mettre ici, en plus elles seront chargées automatiquement au démarrage.

https://wiki.archlinux.org/index.php/sysctl
http://superuser.com/questions/625840/how-do-i-reload-sysctl-from-sysctl-d-directory

- Pourquoi définir la policy en ACCEPT par défaut ? Moi j'aurais fait le contraire justement.

Sinon GG pour ton script.

BXT

Impressionant le script en effet oO

Thanks!

EDIT: En regardant ton script de plus près, ça se voit que tu sais ce que tu fais et que tu connais très bien ton domaine

dennis-nedry

comment fais t'on pour l'installer car il m’intéresse

merci

Hardware

Vu que c'est un script init avec des en-têtes LSB, tu dois le mettre dans le répertoire /etc/init.d, par exemple /etc/init.d/firewall puis :

# Rendre exécutable le script :
chmod +x /etc/init.d/firewall

# Activer le service au démarrage
insserv firewall

A toi d'adapter le script pour qu'il corresponde à tes besoins.

dennis-nedry

Hardware wrote:Vu que c'est un script init avec des en-têtes LSB, tu dois le mettre dans le répertoire /etc/init.d, par exemple /etc/init.d/firewall puis :
# Rendre exécutable le script :
chmod +x /etc/init.d/firewall

# Activer le service au démarrage
insserv firewall
A toi d'adapter le script pour qu'il corresponde à tes besoins.

oki et je fais un nano firewall pour créer le script?

BXT

Beaucoup de règles pour serveur CSS par contre prise en compte automatiquement, dommage ça

jean-luc

Bonjour;

Vous trouverez ici un topic très intéressant sur l'utilité réelle d'un pare-feu sous linux; surtout les propos d'un certain TIRAxxx qui a publié un article a ce sujet dans la revue "LINUX-PRATIQUE" de janvier-février.

Surtout la métaphore utilisée, pour se demander l'utilité de mettre une porte cadenassée devant un mur; et si il y a une porte, c'est qu'il y a un soft en écoute dessus, et donc on ne peut la fermer; ce qui met un sérieux doute sur l'utilité du tout drop pour ouvrir ce que l'on a besoin ensuite; puisque par défaut les ports sont fermés sous linux...plein de bon sens...

http://forum.ubuntu-fr.org/d/1285441
http://forum.ubuntu-fr.org/d/1758661

C'est un peu long à lire, mais reste néanmoins très intéressant, et fait se poser beaucoup de questions sur plein d'idées reçues.
Bonne lecture : (zapper les interventions du firewall derrière une box qui ne nous concerne pas); et a chacun d'en tirer ses propres conclusions.

Hardware

Je suis pas d'accord avec toi Jean-luc, ce n'est pas un simple script qui ne fait qu'ouvrir les ports nécessaires pour ses services, MorgenDavid va beaucoup plus loin que ça, il se protège de pas mal d'attaques courantes, il a mis aussi quelques check sur le traffic entrant en fonction de ses services.

Sinon pour ce qui est du tout drop, par défaut oui tous les ports sont fermés, mais si un jour une application vérolée ouvre un nouveau port sans que tu le saches et que ce port permet de prendre le contrôle de ton serveur avec imaginons une faille 0day pas encore connue, tu fais quoi ?

L'intérêt majeur est là justement, un pare-feu permet de contrôler tous les flux entrants/sortants, donc tu sais exactement ce que ton serveur à le droit de reçevoir et ce qu'il ne peut pas, parce que c'est toi qui l'aura définit.

Je t'invite à lire ces deux fils de discussion sur serverfault :

http://serverfault.com/questions/232642/why-would-i-need-a-firewall-if-my-server-is-well-configured
http://serverfault.com/questions/201298/why-should-i-firewall-servers

MadHatter wrote:A firewall which defaults to DENY ANY ANY is the sysadmin way of saying that if something new comes along and opens up a network listener on this server, noone will be able to talk to it until I have given explicit permission.

Tout est dit

Un conseil, même si l'article est parut dans LINUX-PRATIQUE, il répond peut-être à un usage mais les besoins varies d'une infrastucture/environnement à un(e) autre.

jean-luc

Hardware wrote:Je suis pas d'accord avec toi Jean-luc.

J'ai dit, chacun en tire ses propres conclusions....!!!

mais si un jour une application vérolée ouvre un nouveau port sans que tu le saches

Ils en parlent d'ailleurs de celà dans le topic (faut le lire..); et sur un système propre à la base ça ne doit et ne devrait pas arriver, et que dans ce cas autant repartir à zéro.

Hardware

Je vois que tu as pas lu ce qu'il y a sur serveur fault, MadHatter donne un exemple tout con qui fout en l'air la sécurité d'un serveur même propre à la base

Encore une fois je suis pas d'accord, ok un système est propre à la base, mais rien te dit qu'après quelques mois il le soit encore, donc quand tu as un doute, tu repart de 0 à chaque fois ? Tu dis "ça ne devrait pas arriver" mais rien ne peut te le garantir, on ne base pas la sécurité informatique d'un serveur en utilisant le conditionnel, tu vois ce que je veux dire ?

Le risque 0 n'existe pas, mais un pare-feu augmente de manière non négligable la sécurité, encore faut-il le configurer correctement.

Hardware

Je viens de lire le thread en entier sur ubuntu-fr que tu as donné, en fait ils parlent des pare-feu côté poste bureautique de Mr tout le monde, leur discussion est pas vraiment orientée pour une utilisation côté serveur, ici on parle bien d'un pare-feu côté serveur hein

Solinvictus

Je suis également en train de lire ces échanges, c'est vachement intéressant.

MorgenDavid

Hardware wrote:Impressionnant, j'en ai jamais vu un aussi complet sur internet 😀

Merci, J'avoue, j'en suis assez fier.

Hardware wrote: - Pourquoi ne pas mettre les règles sysctl directement dans /etc/sysctl.d/xx-rules.conf par exemple ? Ça me semble plus adapté de les mettre ici, en plus elles seront chargées automatiquement au démarrage.
https://wiki.archlinux.org/index.php/sysctl
http://superuser.com/questions/625840/how-do-i-reload-sysctl-from-sysctl-d-directory

En effet, Je vais me faire un ticket pour moi même...

Hardware wrote: - Pourquoi définir la policy en ACCEPT par défaut ? Moi j'aurais fait le contraire justement.

Oublie de ma part. Originellement j'ai commencer ce firewall en le voulant accessible au plus large public possible. donc faire un firewall de type "j'accepte tous, Je refuse uniquement ce que je ne veut pas"
Mais finalement il a virer a "Je refuse tout, j'accepte uniquement ce qui m’intéresse"
Ce qui le rends, du coup, moins accessible au pure néophyte.

Hardware wrote:Sinon GG pour ton script.

Mici, mici

MorgenDavid

dennis-nedry wrote:
Hardware wrote:Vu que c'est un script init avec des en-têtes LSB, tu dois le mettre dans le répertoire /etc/init.d, par exemple /etc/init.d/firewall puis :
# Rendre exécutable le script :
chmod +x /etc/init.d/firewall

# Activer le service au démarrage
insserv firewall
A toi d'adapter le script pour qu'il corresponde à tes besoins.
oki et je fais un nano firewall pour créer le script?

erf, Quoique mon script ne devrait pas poser de problème....
c'est quand même le firewall...

en clair, teste le avant de le mettre le script de démarrage de ton serveur. Histoire que, si tu te retrouve bloquer... tu puisse redémarrer la machine.

bref, télécharge le, customise le un peu, rends le exécutable, exécute le

si pas de problème... Alors seulement met le en démarrage.

PS: "/etc/ipbanlist.txt" ==> pour ajouter des ranges de ban/ ban simple d'ips. Un pti reload et tu perds pas les stats de iptables...

MorgenDavid

Ce qui manque a ce firewall ?

==> Que la personalisation se fasse dans un fichier externe (idéalement dans "/etc")
==> Une option "NAT" qui ferait du QOS (Traffic shapping). (Pour ceux qui ont un dédié a la maison..)
==> Une doc...

Dans tous les cas, pour ceux qui sont intéressé, Ce script est sur un SVN avec un bugtrac. A bon entendeur..

PS: la licence de ce script est sous FPC.... Pour... (Faite Pas Chier...) En clair, faite ce que vous voulez avec... Soyez juste respectueux du travail fournit.

jean-luc

@Hardware
Le LINUX-pratique N°87 (5 ou 6 pages sur le sujet); je l'ai feuilleté dans le rayon d'une GMS, mais je ne lai pas acheté (7.90€); plus complet certes, mais ça reprend les idées principales de TIRAxxx sur la non utilité dans plus de 90% des cas des règles iptables.
D'ailleurs j'ai moi même réduit celles ci au minimum sur mon serveur, les seules qui restent sont des blocages des ip connues de TMG HADOPI, et le blocage d'ip effectué par fail2ban, et par contre je suis en connexion exclusive par clés (j'ai banni la connexion par mot de passe).

Par contre toutes les règles du type :

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -A INPUT ... -j ACCEPT
iptables -A OUTPUT ... -j ACCEPT

Poubelle...

Je viens de lire le thread en entier sur ubuntu-fr que tu as donné, en fait ils parlent des pare-feu côté poste bureautique de Mr tout le monde, leur discussion est pas vraiment orientée pour une utilisation côté serveur, ici on parle bien d'un pare-feu côté serveur hein

Pour un serveur, il a les mêmes idées : http://forum.ubuntu-fr.org/d/1758661
Et dans celui ci :http://forum.ubuntu-fr.org/d/1285441 :

D'ailleurs, même sur une machine qui a directement accès à Internet sans être derrière un routeur ou une box, ce n'est pas nécessairement indispensable

D'ailleurs il ne fait pas seulement allusion à l'ordi de Mme MICHU (je ne pense pas que l'ordi de Mme MICHU embarque un serveur SSH, un serveur WEB..).

Encore une fois je suis pas d'accord, ok un système est propre à la base, mais rien te dit qu'après quelques mois il le soit encore

Pourquoi ne le serait il pas ??

Linux, ce n'est pas WINDOWS, ou les utilisateurs téléchargent et installent et désinstallent des softs pris n'importe ou : (SOFTONIC,..); des softs avec des addons, pleins de malwares, spywares et j'en passe..qui ont souvent pour but que de se connecter au web une fois installés.

Sous Linux, les softs sont pris sur les dépôts et donc fiables, et l'utilisateur s'il est prudent se doit d'ailleurs se contenter de ceux là exclusivement.

Ce n'est pas le firewall qui est surtout utile, mais les précautions prise en amont comme il le dit aussi dans ce topic.

#####################

Edit : J'ai relevé sur ce forum quelques autres interventions de cette personne intéressantes et complémentaires :

Logiciel malicieux à l'intérieur ou venant de l'extérieur:

http://forum.ubuntu-fr.org/d/0/0 :

"Je reprend maintenant mon argumentation que j'ai donnée hier soir dans un autre fil sur ce même forum.

- le blocage en entrée servirait à "protéger" le cas où un logiciel malicieux se mettrait en écoute sur un port quelconque
- le blocage en sortie servirait à "protéger" le cas où un logiciel malicieux se connecterait vers l'extérieur.

Dans les deux cas, ça n'arrive pas sur un système "propre" : on est déjà dans le cas d'une machine corrompue, il est trop tard pour penser à la sécurité......

Pas plus utile pour un serveur :

http://forum.ubuntu-fr.org/d/0/0 :

"L'utilité de Netfiler, c'est :
- soit de bloquer des ports que tu ne peux pas fermer (cas très rare) ;
- soit de faire un filtrage sélectif (mais je parie que ce n'est pas ce que tu envisageais de faire) ;
- soit de faire des redirections de port."

Quelles sont les bases pour sécuriser son serveur ?:

http://forum.ubuntu-fr.org/d/0/0

Et je précise à nouveau que je parle là d'une machine de type serveur :

http://forum.ubuntu-fr.org/d/0/0

J'ai commandé un Kimsufi:

http://forum.ubuntu-fr.org/d/1206651

installation et configuration d'un p'tit serveur Dedibox

http://forum.ubuntu-fr.org/d/0/0

MadHatter a écrit :
A firewall which defaults to DENY ANY ANY is the sysadmin way of saying that if something new comes along and opens up a network listener on this server, noone will be able to talk to it until I have given explicit permission.

Des tutos, des articles web...qui affirment l'utilité de tout fermer; il y en a à chier!!
Faire des affirmations, c'est bien, mais étayer avec des arguments qui tiennent la route c'est mieux...

TIRAXX lui affirme la non utilité systématique de ces règles; mais avec l'avantage de justifier le pourquoi, et ceci, étayé par des arguments cohérents.

LetsGo67

Salut, très beau script cependant je remplacerais :

Tu déclare

SYSCTL

mais aucune variable ?

Obtenir l'ip :

ip addr | grep 'inet' | grep -v inet6 | grep -vE '127\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | grep -o -E '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | head -1

et pour l'interface :

declare -a IFACE
index=0
unset i
for i in $( ${INIP} ); do
        IFACE[$index]=$i
        let "index += 1"
        if [[ "${DEBUG}" == "true" ]]; then
                echo "Debug ON: Success = $i ${IFACE[$index]}"
        fi
done

car là sur un vps, ton code ne fonctionnera pas.

Vu que tu ouvre les ports, tu peux mettre dans iptables_policy :

$IPTABLES -t filter -P INPUT DROP
$IPTABLES -t filter -P FORWARD DROP
$IPTABLES -t filter -P OUTPUT DROP

Tu as oublié de vérifier l'utilitaire ethtool si présent ou non

Si je trouve plus de temps, je regarderais en approfondi mais très beau travail malgré tout !

MorgenDavid

LetsGo67 wrote: Tu déclare
SYSCTL
mais aucune variable ?

Pas sur de comprendre..
La variables SYSCTL est principalement utilisé dans la fonction "add_sysctl"
Juste avant l'appel de cette fonction, je teste si sysctl est bien présent et c'est a ce moment que j'initialise SYSCTL=`type -P sysctl`;
Mais en effet, pour être plus propre je devrais effectivement plutôt la mettre en en-tête parmi les autres déclarations.

LetsGo67 wrote: Obtenir l'ip :

ip addr | grep 'inet' | grep -v inet6 | grep -vE '127\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | grep -o -E '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | head -1

oui... et non. Dans mon cas ta fonction me donne "192.168.1.12" <=== IP locale IPsec
la mienne me donne les deux.
bref... de toute façon, aucune commande n'utilise l'IP dans mon script.Uniquement utilisé pour indication dans le titre

LetsGo67 wrote: et pour l'interface :

declare -a IFACE
index=0
unset i
for i in $( ${INIP} ); do
        IFACE[$index]=$i
        let "index += 1"
        if [[ "${DEBUG}" == "true" ]]; then
                echo "Debug ON: Success = $i ${IFACE[$index]}"
        fi
done

car là sur un vps, ton code ne fonctionnera pas.

hummm... possible..
Mais la,, si je comprends bien, ton code me donne un tableau contenant... ben... Je sais pas trop. Bref pas clair pour moi.

LetsGo67 wrote: Vu que tu ouvre les ports, tu peux mettre dans iptables_policy :
$IPTABLES -t filter -P INPUT DROP
$IPTABLES -t filter -P FORWARD DROP
$IPTABLES -t filter -P OUTPUT DROP
Tu as oublié de vérifier l'utilitaire ethtool si présent ou non

Effectivement, des petites corrections sont a prévoir.

LetsGo67 wrote: Si je trouve plus de temps, je regarderais en approfondi mais très beau travail malgré tout !

Merci,
Et oui, les critiques constructive sont toujours les bienvenues.

LetsGo67

pour sysctl oui j'ai vu que tu vérifiais plus bas

Pour l'ip, moi ça me donne 127.0.0.2 et l'IP.

Pour l'interface, à toi de voir ^^

Page suivante »