C’est de l’inconscience pure !
Le script rc.local est exécuté après tous les autres scripts d’init, donc bien après le démarrage du réseau. Ta machine était à poil durant de longues secondes… Un vrai miracle qu’elle n’ait pas été piratée jusqu’ici.
Oui, je m’en suis bien rendu compte en lisant ce tuto 
J’avais gardé cette (très) mauvaise habitude de mes débuts sur Ubuntu (et sur Linux). J’avais trouvé cette astuce[sic] dans la doc bien qu’elle n’était pas recommandée…
D’où mon intervention lorsque j’ai vu que mon script de parefeu ne se lançais pas avant le démarrage de la connexion. Bien que cela soit beaucoup mieux que quand j’utilisais rc.local :-°
[quote=“ricardo”]j’ai lu et compris de quoi il s’agissait et j’ai retenu ce lien du forum Ubuntu :
[quote]J’utilise Ubuntu depuis quelques jours et à chaque démarrage le message suivant apparait:
EXT3FS: recovery required on read-only filesystem …
Ce système de fichier est la racine (/) ce qui signifie que la racine n’est pas démontée correctement avant le reboot ou le stop.
Après investigation j’ai pu constaté qu’aucun système de fichier n’est démonté.
Le problème est du à l’utilisation de insserv. Commande qui m’a permis de désactiver certains services.
insserv à un bug sérieux semble-t-il. Lorsque l’on reboot on entre dans le runlevel 6, le système exécute les scripts présents dans le répertoire /etc/rc6.d, (en fait des liens vers les scripts de /etc/init.d) lançant d’abord ceux commençant par K puis ceux commençant par S. C’est un héritage de Unix System V. Chaque script se voit affecté un préfixe en K ou S et un numéro compris entre 00 et 99. Le système les lance dans l’ordre numérique puis lexicographique pour ceux ayant le même numéro.
Mais insserv attribue a reboot le préfixe S01 , alors qu’il attribue à umountfs, umountroot et sendsigs (arrêt des processus) le même numéro mais leur nom commence par u et s, ils sont donc lancés après. Donc le script /etc/init.d/reboot (tout comme /etc/init.d/halt dans le runlevel 0) redémarre (stop) sans avoir invité les processus restant à quitter et sans avoir démonté les systèmes de fichier montés.
Me voilà donc obligé de gérer les liens des répertoires /etc/rc6.d (reboot) et /etc/rc0.d (halt) à la main. A chaque utilisation de insserv ils sont perdus.
Si quelqu’un connait une meilleur solution merci de m’en informer.[/quote][/quote]
Tu crois vraiment que l’équipe de release laisserais passer quelque chose comme ça ?
% ls /etc/rc6.d
K01alsa-utils@ K01fglrx-atieventsd@ K01network-manager@ K01wicd@ K05nfs-common@ K08umountfs@
K01atd@ K01fuse@ K01openbsd-inetd@ K01xdm@ K05portmap@ K09umountroot@
K01avahi-daemon@ K01gdm3@ K01shorewall@ K02sendsigs@ K06hwclock.sh@ K10reboot@
K01bluetooth@ K01gdomap@ K01udftools@ K03rsyslog@ K06networking@ README
K01exim4@ K01lpd@ K01urandom@ K04umountnfs.sh@ K07ifupdown@
Il n’y a pas ce souci sous Debian.
Mais non, pas de panique, en fait c’était de l’exagération de ma part, pour relativiser la nécessité réelle d’un pare-feu. Une machine hôte sous GNU/Linux à jour et correctement paramétrée ne devrait pas avoir besoin de pare-feu. En effet à quoi bon bloquer des ports en entrée qu’aucun service n’écoute, ou des ports en sortie auxquels aucun programme n’est censé se connecter ? A quoi bon bloquer des paquets invalides que la pile IP ignore de toute façon ?
Pour une machine servant de routeur et devant contrôler le trafic d’autres machines, c’est différent.
Sujet passionnant, et sans fin… 
Je viens de me faire prendre…
$ ssh root@lamachine
(création de /etc/init.d/parefeu)
/etc/init.d/parefeu clean
iptables -t filter -P INPUT DROP
Et hop… plus de ssh, je me fait jeter 
Peut-être préciser dans le T&A qu’il faut passer les commandes sans passer par ssh…
Forcément, si tu scies la branches sur laquelle tu es assis…
Néanmoins il n’est effectivement pas inutile de rappeler que dans le cas d’une machine distante il vaut mieux prendre des précautions pour ne pas se retrouver bêtement “enfermé dehors”.
-
Si le jeu de règles iptables/ip6tables est basé sur le suivi de connexion (-m state ou conntrack), il vaut mieux charger les modules de suivi de connexion IPv4 (nf_conntrack_ipv4) et/ou IPv6 (nf_conntrack_ipv6) du noyau un peu avant d’activer les règles, afin que la connexion SSH en cours soit “connue” par le suivi de connexion comme ESTABLISHED. Ainsi la session ne sera pas coupée sec lorsque le script de création des règles sera exécuté.
-
Les règles doivent de préférence être installées en une seule commande, par un script ou iptables-restore, et pas une par une dans le shell. Dans le cas contraire, il faut créer les règles et les politiques par défaut dans un ordre tel que cela ne provoque pas de perte de connectivité intempestive. Dans le cas d’une situation de départ avec les chaînes vides et politiques ACCEPT, il faut créer les règles ACCEPT avant de mettre les politiques à DROP, à l’inverse de ce que fait normalement un script.
Mise en garde ajoutée au tuto.
Salut,
Je me permet de m’incruster discretement avec mes gros sabots. 
J’ai trouvé ça en fouillant sur le net : [code]# SSH In
iptables -t filter -A INPUT -p tcp --dport 2222 -j ACCEPT
SSH Out
iptables -t filter -A OUTPUT -p tcp --dport 2222 -j ACCEPT [/code]
Je n’ai pas testé ( pas encore de ssh chez moi )
Mais bon voilà si ça peut permettre d’éviter de se faire “enfermer dehors” …
Je le laisse a l’appréciation des pros …
Et je file ===> [] [size=50]Trés loin[/size] 
Pour OUTPUT, c’est plutôt --sport s’il s’agit de la règle acceptant les paquets dans le sens retour.
Ces règles peuvent être une sage précaution temporaire, à condition
- de les mettre en début de chaîne, on ne sait pas ce qui peut se passer ensuite ;
- de dire à sshd d’écouter sur le port 2222 en plus ou à la place du port 22 par défaut.
Bien le bonjour chez vous !
Sujet on ne peut plus passionnant …
Se post n’ayant pour seul but, que quelques observations d’un “nul”
Un “nul” qui ne fait que passer, vite vite.
Très très vite te dis-je ! Dépêche toi 
!
Merci à vous tous ! 
Mes règles étant construites sur la base de l’excellent tuto ( merci à tous ces contributeurs ) ici :
http://www.debian-fr.org/installation-parefeu-iptables-pour-les-nuls-t1901.html
Il est grand temps que je cherche à comprendre (ce que j’ai copier en toute confiance ) 
!
C’est pourquoi je remonte l’intégralitée de ce fil.
Voilà, si vous me le permettez…
@ dric64 >
http://www.debian-fr.org/digression-installation-parefeu-iptables-pour-les-nuls-t26303-175.html#p280119
À l’intention des "nuls d’on je fait parti.
[quote]dric64 à écrit :
3. Redémarrer le service ulogd (en root : service ulogd restart)[/quote]
J’ai essayer tel quel ! … 
debian:/home/lenny505# service ulogd restart
bash: service: command not found
debian:/home/lenny505# ulodg restart
bash: ulodg: command not found
debian:/home/lenny505#
Et t’as pas honte … bovin que tu est ! 
J’ai chercher un p’tit peu ( " Usage: /etc/init.d/ulogd {start|stop|restart|force-reload} ")
Site officiel d’ulogd : http://netfilter.org/projects/ulogd/index.html
Et si tu m’y autorise @ dric64,
la commande pour les “nuls” :
/etc/init.d/ulogd restartQui donne après installation :
Oct 16 13:18:09 debian [IPTABLES DROP OUT] : IN= OUT=lo MAC= SRC=127.0.0.1 DST=127.0.0.1 LEN=1012 TOS=00 PREC=0x00 TTL=64 ID=55187 CE DF PROTO=UDP SPT=38932 DPT=38932 LEN=992
Oct 16 13:18:09 debian [IPTABLES DROP OUT] : IN= OUT=lo MAC= SRC=127.0.0.1 DST=127.0.0.1 LEN=820 TOS=00 PREC=0x00 TTL=64 ID=55188 CE DF PROTO=UDP SPT=38932 DPT=38932 LEN=800
Oct 16 13:18:09 debian [IPTABLES DROP OUT] : IN= OUT=lo MAC= SRC=127.0.0.1 DST=127.0.0.1 LEN=244 TOS=00 PREC=0x00 TTL=64 ID=55189 CE DF PROTO=UDP SPT=38932 DPT=38932 LEN=224
Oct 16 13:18:18 debian [IPTABLES DROP OUT] : IN= OUT=eth0 MAC= SRC=192.168.1.12 DST=192.168.1.1 LEN=84 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=39475 SEQ=1
Oct 16 13:18:19 debian [IPTABLES DROP OUT] : IN= OUT=eth0 MAC= SRC=192.168.1.12 DST=192.168.1.1 LEN=84 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=39475 SEQ=2
Oct 16 13:18:20 debian [IPTABLES DROP OUT] : IN= OUT=eth0 MAC= SRC=192.168.1.12 DST=192.168.1.1 LEN=84 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=39475 SEQ=3
Oct 16 13:18:21 debian [IPTABLES DROP OUT] : IN= OUT=eth0 MAC= SRC=192.168.1.12 DST=192.168.1.1 LEN=84 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=39475 SEQ=4
Oct 16 13:18:22 debian [IPTABLES DROP OUT] : IN= OUT=eth0 MAC= SRC=192.168.1.12 DST=192.168.1.1 LEN=84 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=39475 SEQ=5
Me reste plus cas trouver et comprendre ce qui en ressort.
@ j’ai oublier ( lien fournit à deux où trois reprises dans ce fil)
Dommage lien mort :
http://ashgenesis.debian-fr.net/ricardo/iptables/
[quote]Un problème s’est produit lors du chargement de ashgenesis.debian-fr.net/ricardo/iptables/ :
Hôte ashgenesis.debian-fr.net inconnu[/quote]
J’aurai bien aimer savoir de quoi il en retourner.
Note: ce lien qui paraît incontournable également ! http://olivieraj.free.fr/fr/linux/information/firewall/
Je ne faisais que passer … 
Maintenant, je sais ou toqué pour des informations complémentaires. Oui …
Je vous en serre cinq, amicalement, loreleil. 
[quote=“loreleil.747”]debian:/home/lenny505# service ulogd restart
bash: service: command not found[/quote]
La commande ‘service’, d’origine RedHat, n’est pas installée en standard dans Debian. Elle est fournie par les paquets chkconfig ou sysvconfig.
[quote=“loreleil.747”]la commande pour les “nuls” :
/etc/init.d/ulogd restart[/quote]
La “bonne” façon Debian d’exécuter un script d’init est via la commande ‘invoke-rc.d’. Elle tient compte du runlevel courant, contrairement à l’exécution directe du script.
Paquet UDP émis sur l’interface de loopback. Probablement par une application locale pour ses communications internes. Il me semble que PostgreSQL fait ce genre de chose. ‘netstat -uanp | grep 38932’ devrait permettre d’identifier le processus.
Paquet de requête “ping” (ICMP type 8 = echo request) émis sur l’interface eth0.
Pour les commandes :
et
Je conseillerais de les remplacer par :
et
les commandes étant plus courtes et plus simples il y a moins de risque d’erreur.
Un grand bravo à Ricardo pour le tuto (ça rime en plus !) et je suis pleinement d’accord avec toi concernant la pédagogie, moi qui suis autodidacte en informatique et en linux.
Si tu continues, tu vas être référencé ou embauché par le Site du Zéro.
Encore merci de la part d’un nul !
Bonjour a tous ,
Je suis un nouveau du forum , et de Linux en général qui m’emballe pas mal je dois dire .
Je n’ai pas fais d’étude en informatique donc pas de grosse connaissance en ma possession alors je glane des infos ici et là dans la mesure de mes capacités a comprendre ce que je lis , et j’essaye de les appliquer.
J’ai utilisé quelques distributions comme Ubunut Mandriva Fedora et plus récemment Crunchbang qui ma poussé vers debian squeeze que J’ai installé .
Jusqu’à présent niveau sécurité je n’ai jamais pas trop fouillé , trop peur de m’y coller _ Iptable rebute pas mal de monde même ceux avec qui j’ai discuté sur différents forum préferant utiliser un pare feu complémentaire . Jusqu’à présent j’utilise ufw qui est simple d’utilisation , mais peut etre pas suffisant .
En effet j’ai remarquer quelque chose d’étrange lorsque je suis sur le Net il y a du download et de l’upload qui s’accumule au fur et a mesure que le temps de connection sur le net sans que télécharge et cela m’inquiète ( en 1h30 17mo/download et 2mo/upload).
J’ai donc décider de me lancer dans l’aventure Iptable si j’arrive a suivre .
Je n’ai pas lu encore toutes les pages de ce post mais j’ai une question très idiote certainement mais il faut que je la pose quand même :
Dans le tuto il est dit :
“Pour un hôte (station ou serveur) non routeur”: ou “Pour une machine faisant office de routeur avec NAT” :
Et là je me questionne déjà , moi qui suis un particulier derrière une box machin (Pas de pub, pas la peine) j’aurai été tenter de dire que je suis un hôte non routeur puisque mon routeur est la box mais je n’en suis pas si sur et j’aurai aimer savoir si je suis dans le vrai ou pas ? Je pense que je dois désinstaller ufw aussi avant d’appliquer quoi que ce soit ?
Merci a vous pour votre aide
Salut et bienvenue !
Si tu n’as qu’une seule machine : pas de fatigue, tu prends ça :
Pour un hôte (station ou serveur) non routeur
Si tu as plusieurs machines et que celle que tu dois protéger sert de “routeur” pour les autres, alors c’est le second cas.
Il y a toutes les chances que tu n’aies à t’occuper que du premier cas.
Vas-y les yeux fermés et suis le tuto “à la lettre”.
Si problèmes, n’hésite pas, il y aura toujours quelqu’un ici pour te dépanner …
À condition que ta question soit précise et unique (une seule question par fil mais autant de fils que tu le désires)
Merci pour ton accueil Ricardo ,
Ecoute je post ici parce que c’est en relation avec le sujet de départ mais si ce n’est pas sa place je m’en excuse et te laisse le déplacer a ta guise .
Bon ben j’étais sur la bonne piste alors avec mon idéé de départ c’est deja bien .
Alors j’ai suivi le tuto et ajouter ces lignes qui sont “les règles personelles” suggérées
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 -p tcp -m tcp --dport 80 -j ACCEPT
et en fin de procédure la commande
m’a renvoyé une erreur en relation avec insserv ( sous réserve vraiment ) donc je ne me souviens pas le contenu je l’ai effacé, désolé c’est une erreur de ma part .
Bref j’ai trouvé sur le forum un topic concernant cette erreur qui disait de rajouter ces quelques lignes en dessous de #!/bin/sh ( je crois meme que c’est ricardo qui avait posé la question) .
Edit: lien d’un topic traitant du meme sujet
[code]#!/bin/sh
BEGIN INIT INFO
Provides: chillispot et freeradius dans le chroot
Required-Start: $local_fs $network
Required-Stop: $local_fs $remote_fs
Default-Start: 2 3 4 5
Default-Stop: 0 1 6
Short-Description: Wireless & LAN Access Point Controller
Description: ChilliSpot is an open source captive portal
or wireless LAN access point controller.
END INIT INFO
[/code]
Apres tout cela terminé au moment de lancer le parfeu avec la meme commande :
J’ai cette erreur là :
update-rc.d: using dependency based boot sequencing
update-rc.d: warning: mon_parefeu start runlevel arguments (S) do not match LSB Default-Start values (2 3 4 5)
update-rc.d: warning: mon_parefeu stop runlevel arguments (0 6) do not match LSB Default-Stop values (0 1 6)
Et là malheureusement j’ai pas encore trouvé dans le forum la solution donc je ne suis pas contre un petit coup de puce .
D’avance Merci pour votre aide.
Edit :
Apres redemarrage je fais un
et j’obtiens
[code]Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all – anywhere anywhere
ACCEPT all – anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp – anywhere anywhere tcp dpt:www
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination [/code]
Que dois je en déduire ?
À vue de nez tu acceptes les connexions entrantes sur le port 80 et puis c’est tout, pas de restrictions en sortie et pas de relai vers une autre machine. Note que la sortie de
iptables-save
est beaucoup plus parlante que celle de iptables -L
Bonjour et merci pour la réponse ,
C’est vrai que la commande iptables-save est plus complete
cela me donne ceci :
[code]# Generated by iptables-save v1.4.8 on Fri Jan 21 17:51:37 2011
*raw
:PREROUTING ACCEPT [16598:1474469]
:OUTPUT ACCEPT [16763:894129]
COMMIT
Completed on Fri Jan 21 17:51:37 2011
Generated by iptables-save v1.4.8 on Fri Jan 21 17:51:37 2011
*mangle
:PREROUTING ACCEPT [16598:1474469]
:INPUT ACCEPT [16596:1473813]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [16763:894129]
:POSTROUTING ACCEPT [16775:895940]
COMMIT
Completed on Fri Jan 21 17:51:37 2011
Generated by iptables-save v1.4.8 on Fri Jan 21 17:51:37 2011
*nat
:PREROUTING ACCEPT [26:1328]
:POSTROUTING ACCEPT [15133:683595]
:OUTPUT ACCEPT [15133:683595]
COMMIT
Completed on Fri Jan 21 17:51:37 2011
Generated by iptables-save v1.4.8 on Fri Jan 21 17:51:37 2011
*filter
:INPUT DROP [36:2483]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [16763:894129]
-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
COMMIT
Completed on Fri Jan 21 17:51:37 2011
[/code]
Oui je pense qu’il faut je j’agrémente les règles , je compte ajouter le https port 443/tcp , xchat port 6667 et vais essayer de tout fermer si c’est possible pour ensuite ouvrir seulement ce dont j’ai besoin .
Le port 53 pour le DNS est il necessaire je vois qu’il est systematiquement recommander de l’ouvrir ?
Le message d’erreur du message précédent n’a pas d’incidence ou il faut s’en préoccuper ?
Au lieu de modifier comme tu l’as fait en début de script, mets plutôt ce qui suit :
[quote]### 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[/quote]
en laissant les quatre lignes vides de réponse.
ensuite, reprends le processus.
Je vais ajouter ces lignes au tuto, ce que j’avais oublié de faire.
Autre chose : tu ouvres le port 80, ça veut dirte que tu comptes faire un serveur web, ce qui n’a rien à voir avec “utiliser” le web.
Je croise avec ta dernière réponse.
[quote=“Garfoon”]
Le port 53 pour le DNS est il necessaire je vois qu’il est systematiquement recommander de l’ouvrir ?
Le message d’erreur du message précédent n’a pas d’incidence ou il faut s’en préoccuper ?[/quote]
Ne confonds pas les ports en entrée et en sortie. Tu as ta politique de sortie à «ACCEPT» donc tu peux aller partout et n’a pas besoin d’ouvrir un port en sortie. Tu as tes ports en entrée bloqués sauf le port 80 (as tu un serveur Web sur ta machine accessible de l’extérieur? Si non, ça n’est pas la peine d’ouvrir le port 80 comme tu l’as fait). De même le port 443 et le port 53 n’ont besoin d’être ouvert en INPUT que si tu héberges un serveur Web https respectivement un serveur de nom. Si ça n’est pas le cas, tu n’as pas à les ouvrir. Pour une machine personnelle non suspectée d’être infectée, la protection est déjà plutôt bien en fermant les ports en entrée comme tu l’as fait et en laissant les ports ouverts en sortie.