Salut à tous,
 
Je cherche à renforcer la sécurité de mes petits serveurs web. J'ai trouvé à droite à gauche des scripts pour iptables mais ils sont tous orientés "home usage" (notamment le célèbre script d'Arno).
 
Je cherche donc à faire un script sans fioritures destiné à sécuriser efficacement un serveur web classique. Et je propose qu'on l'élabore ensemble histoire d'en faire profiter tout le monde.
 
 
NB : je suis au courant qu'un firewall sur un serveur n'est pas la meilleure solution, car les services tournant dessus sont autant de failles possibles, mais ça me semble un bon début avant d'installer un firewall en amont. En plus c'est une sécurité supplémentaire car au cas où le super firewall qui protège toute la baie tombait en panne et qu'on devait le court-circuiter, les machines sont toujours protégées. Mais bon, bref, c'est pas le sujet.
 
 
 
J'ai donc commencer par faire le tour des services dont j'avais besoin sur mon serveur web, et ça a été assez vite : ssh, http, smtp, mysql.
smtp et mysql n'étant pas nécessaire pour la plupart des serveurs, je vais pour l'instant me concentrer sur ssh et http.
J'ai 2 interfaces réseaux sur mes serveurs, mais pour l'instant je vais me concentrer sur celle qui est connectée au net (l'autre est connecté en réseau local et ne sert qu'à faire des rsync via ssh).
 
 
NB2 : je suis un total newbie avec iptables, je vais donc sans doute faire de grosses conneries, soyez indulgent et je suis sûr qu'on pourra faire un truc bien ;-)
 
 
NB3 : si vous trouver que c'est une idée complètement con vous pouvez le dire aussi
 
 
Bon aller je post le début de mon script d'ici peu...

bon ben voilà mon premier script, il est basique mais ne demande qu'à évoluer, des grosses conneries déjà?
Je me suis évidemment inspiré des scripts existants déjà sur le forum ou autre.
 
Il est maintenant pleinement fonctionnel mais peut encore être amélioré
 

 
 
 
 
 
EDIT1 : j'avais oublié les règles pour les DNS
EDIT2 : j'ai ajouté les règles de l0ky en ligne 17 pour de meilleures perfs.
EDIT3 : corrigé une erreure au niveau des règles mysql
EDIT4 : grosses discussions sur les règles aux lignes 29 à 35
EDIT5 : ajout du flag --syn pour identifier les ouvertures de connexion tcp.
EDIT6 :  
- ajout du flag  -m state --state NEW pour les protocoles attendant une réponse (tous sauf SMTP dans mon cas)
- ajout du support du ftp en sortie
- suppression de la restriction ssh par adresse IP en sortie sur l'interface $INTERNET (trop restrictif si je veux synchroniser vers plein de serveurs et peu risqué), mais comme je ne synchronise que sur l'interface $LOCAL pour l'instant c'est en commentaire.
EDIT7 :
- ajout de règles pour vérifier la validité des paquets
- optimisations à l'aide de chaines personnelles
EDIT8 :
- ajout d'une variante pour n'autoriser que le trafic ftp en sortie vers les miroirs de paquets d'un système
- mis en place d'autre protections réseau (non spécifiques à iptables) inspirées du guide de sécurisation debian
EDIT9 : LOGs!
EDIT10 :  
- ajout de règles plus précises pour l'icmp
- correction d'erreurs au niveau des flags sport et dport
EDIT11 : ajout d'un flag  --sport 1025: pour les protocoles utilisant un port>1024 en sortie
EDIT12 :  
- ajout d'un script de démarrage
- mise en commentaire de la ligne pour ip_always_defrag qui n'est pas dispo sur toutes les distros
EDIT13 : ajout du chargement des modules
EDIT14 :
- suppression des règles TCP pour les DNS (seul l'UDP est utilisé ici)
- ajout d'un lien pour l'exlpication des protections réseau du noyau
EDIT15 : ajout d'une règle pour la synchro ntp

pour le dns c'est plutot --dport 53

Tu ne precise jamais les tables utilisées et par defaut, c'est filter. Ce qui fait que la table nat et mangle ne sont pas initialisées dans ton script car tu utilise toujours filter. ex:

 
Tes premieres regles (les 3 INPUT et 3 FORWARD) de DROP sont inutiles puisque par defaut, tu as tout droppé

copier/coller qui a rippé, corrigé.
Merci
 
pas de remarques sinon, pas de trucs inutiles, de trous...
 
EDIT : je répondais à l0ky

j'aurais un peu renforcé l'affaire avec --syn pour l'acceptation des connection TCP (entrante/sortante)

sebchap > effectivement je n'utilise que la table filter
je devrais donc mettre ces règles à la fin, après avoir accpeter certains paquets?

 
ouaip, j'ai vu que c'était utilisé mais pour l'instant je n'ai pas encore tout compris, donc plutôt que de faire des copier/coller où je ne comprends rien, j'y vais petit à petit...

L'initialisation se fait au debut (flush des regles puis application des regles par defaut DROP).
Après, tu ne devrais plus avoir de regles DROP
 
edit: dans tes regles ACCEPT, tu peux aussi rajouter a chaque fois l'interface de sortie/entrée ainsi que la source/destination des connexions si elles sont connues et fixes. Mais ce n'est pas obligatoire.

oups, mais alors si je drop les paquets prétendant venir du réseau local et qu'ensuite j'accepte toutes les connexions venant d'internet, ça sert à rien?!?
 
j'suis perdu là...

 
c'est ce que j'ai fait au niveau de ssh et des dns, pour le reste je ne pense pas en avoir besoin.

Tu es obligé de dropper toute les connexions par defaut, c'est une regles de base
Ensuite, tu n'accepte pas TOUTE les connexions venant d'internet, tu acceptes seulement celle qui ont un statut particulier (ESTABLISHED et RELATED). C'est ce qu'on appele le suivi de connexion. Ca bloque donc les nouvelles connexions (NEW), les connexions invalides (INVALID) et UNTRACKED.
Par contre, il me semble que tu dois accepter les nouvelle connexions vers l'exterieur (relgle OUTPUT) et pas seulement les connexions ESTABLISHED et RELATED.

ces règles là (pour http par exemple) ne suffisent pas a accepter des nouvelles connexions? :
 
# $IPT -A INPUT -p tcp --dport http -j ACCEPT
# $IPT -A OUTPUT -p tcp --sport http -j ACCEPT

je profite de ce topic, car je ne comprends pas un truc:
dans chaque script iptable je vois ces lignes
# ### Autorise tout le trafic appartenant à des connections existantes. ###
# $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# $IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
 
 
c'est quoi ces connections deja existantes ?

bah ça il me semble que j'ai compris, ce sont des paquets en rapport avec une connexions déjà existante (où des paquets ont déjà été transmis) ou en relation avec une connexion existantes.
 
Je suppose que le kernel se débrouille pour les reconnaitre...

Ca c'est juste pour ton serveur http
tes connexions avec internet sont bcp plus diversifiées (port, ptotocole etc...)

bah oui, ce n'était qu'un exemple mais dans le cas de mon serveur, les connexions à internet ne sont pas très diversifiée.
en tout et pour tout, je n'ai que 4 ports d'ouvert et je les ai ouvert explicitement par des règles, c'est pour ça que je ne comprends pas où est le blème

Tu n'auras que 2 ports d'ouvert en permanence a priori: 80 et 22 pour le serveur web et ssh respectivement.
Pour ces deux serveur tu dois autoriser les connexions entrantes vers ces ports et les connexions sortante en provenance de ces ports. Mais quand tu te connecte a un site internet par exemple, la reponse que ce site t'envoie ne vas pas arriver sur ton port 80 mais sur un port quelconque. C'est pour ca que tu dois aussi autoriser certaine connexions quelque soit leur port de destination, a partir du moment où elles ont un statut correct.

ah, ok compris, mais comment tu fais ça? avec --state NEW, c'est ça?

Je n'ai jamais monté de serveur web donc je ne sais pas s'il faut accepter les connexions entrantes NEW, mais a priori, je dirais oui (mais attends la confirmation de qqun d'autre).
Ce qui est sur, c'est que tu ne dois pas accepter TOUTE les connexions entrante NEW, seulement celle a destination de ton serveur web (port 80) (en supposant que j'ai raison)
Pour filtrer selon le statut, c'est avec l'option -m puis le nom du filtre et enfin les options du filtre (cf man iptables)

j'ai réfléchis à ça en allant chercher mon porc sauce aigre douce, mais il ne me semble pas que j'ai besoin d'une règle particulière, car comme c'est moi qui initie la connexion, les paquets qui viennent du serveur sont ESTABLISHED, non?

C'est possible, essaye

bon alors et pour en revenir à ce que tu me disais tout à l'heure, elles servent à rien mes règles DROP à la fin?

oui puisque par defaut, tout est bloqué des le debut

bah ouais, mais comme ensuite j'accepte TOUT ce qui rentre sur mon port 80 (par exemple), il faut bien ces règles DROP pour accepter ce qui rentre sur le port 80 SAUF les requêtes qui viennent prétendument d'un réseau local.
 
j'étais d'accord avec toi pour dire que placée au début elle ne servait à rien puisque il y avait les règles DROP avant et qu'ensuite, j'acceptais tout, mais à la fin il me semble que ça a un sens, car le paquet va continuer son bonhomme de chemin jusqu'à se faire dropper.

Si tu veux que ton serveur web ne soit pas accesible via le reseau local, alors c'est dans les regles d'acces au port 80 qu'il faut le specifier:

 
edit: quand tu dis "pretendument", ca veut dire quoi ? Si tu pense que quelqu'un venant d'internet peut avoir ce genre d'adresse, alors rassure toi, ce n'est pas possible. Elle serait automatiquement detruite sur les routeurs. Ce sont des plages reservé aux adresse privées.

oui effectivement si elles ne peuvent pas arriver jusqu'à ma machine, ces règles ne servent à rien. > j'efface
 
En ce qui concerne l'accès au port 80 par le réseau local, ça ne me dérange pas, mais si je voulais l'interdire je ne ferais pas comme tu propose mais plutôt comme ça :
 
$IPT -A INPUT -p tcp --dport http -i $INTERNET -j ACCEPT
$IPT -A OUTPUT -p tcp --sport http -o $INTERNET -j ACCEPT
 
en gros comme les packets sont DROP par défaut je ne les accepte que sur l'interface $INTERNET, ce qui reviens à les interdire sur l'interface $LOCAL, j'ai bon?

Si si c'est possible
Il y a certains FAI qui utilisent des adresses privées pour leur équipement et qui ne drop pas au niveau des routeurs . Y a un topic sur WSR qui en parle.
 
indice: le FAI est en étroite relation avec FT et se termine par doo
 
Mais bon, c'est toujours bon de dropper ca

ah bah merde alors, je vais remettre ces règles, mais je les met où finalement?

Le lien stp
 

Bah si tu droppe, ton serveur sera inacessible du reseau local (sauf peut etre si tu filtre par MAC). Enfin c'est comme tu veux. Tu peux les remettre a la fin

non mon serveur ne sera pas accessible du réseau local puisque je ne DROP que sur l'interface $INTERNET

Ah, autant pour moi, je n'avais plus les lignes sous les yeux

bon, ok maintenant que tout le monde est d'accord sur la base, il ne reste plus qu'à amélioré ça.
 
l0ky tu parlais tout à l'heure de --syn, j'ai lu la manpage de iptables (une fois de plus) et sur ce coup là, je trouve pas ça très clair, tu pourrais m'éclairer?
 
j'ai vu aussi que HuGoBioS utilisait toute une ribambelle de règles pour vérifier la validité des paquets (voi ici : http://forum.hardware.fr/forum2.ph [...] ash_post=0 au milieu du topic) z'en pensez quoi?

J'en sais rien moi, je suis pas un moteur de recherche
Le titre du topic était à propos de ping d'ordinateur fantome...
 
J'essaierai de le retrouver mais la pas le temps

C'est pour renforcer un peu l'aspect statefull du paquet. Il ne matches que les paquets ayant seulement les paquets TCP ayant le flag syn d'activer (signalant une demande de connection TCP)

ok j'ai compris (enfin je crois), comme au début on accepte tous les paquets provenant d'une connexion ESTABLISHED ou RELATED, on peux dans les règles suivantes être plus restrictifs et n'accepter que les paquets correctement formés  pour ouvrir une connexion.
 
Ceux-là seront acceptés la première fois grâce aux règles spécifiques, et ensuite tout les paquets correspondant au flux TCP qui n'auraient pas été accepté par ces règles le seront avant grâce aux règles des lignes 18, 19 et 20.
 
j'ai bon?

http://forum.hardware.fr/forum2.ph [...] ash_post=0
 
 
 

jap

y'a qd même un truc que je capte pas (et c'est un peu grave) :  
si un paquet est DROP, logiquement les règles suivantes ne devraient pas être évaluées (d'après ce que j'ai lu), et pourtant c'est le cas puisque sinon les paquets ne passeraient pas la première chaine (qui DROP tout...).
Inversement un paquet ACCEPTé, peut continuer à parcourir les chaines jusqu'à ce qu'il rencontre une chaine qui éventuellement le DROP, alors pourquoi dans le cas de l'utilisation de --syn alors qu'il est passé par les règles 18,19, et 20 le paquet ne serait-il pas DROPpé par les règles contenant le flag --syn?

Presque:
Sauf que iptables -P OUTPUT DROP ne met pas en place une regle mais une politique. C'est à dire ce que fera netfilter si aucun match n'a correspondu durant la traversée de la chaine OUTPUT
 
En fait, pour simplifier, netfilter parcours une chaine jusqu'à ce qu'une regle matche. Dans ce cas là il applique l'action et basta, il ne finit pas la traversée. Si aucue règle n'a matchée alors il applique la politique (ici DROP)