firewall sous linux - debutant

dans (in) fr.comp.securite, "Olivier Croquette" <ocroquette@free.fr>
ecrivait (wrote) :

Bonsoir Olivier,

Considérons le schéma suivant :

LAN --- Switch --- Passerelle --- ADSL --- Internet

Sur la passerelle tournent quelques services ainsi que le pare-feu.
Le pare-feu refuse tout flux entrant venant d'Internet.

C'est globalement une bonne initiative.

Si l'on fait confiance aux utilisateurs ( ce qui est à priori le cas
d'un reseau domestique ), je trouve la sécurité suffisante.

Je m'en excuse par avance auprès d'eux, mais faire confiance aux
utilisateurs est déraisonnable en matière de sécurité.

--
Eric

Olivier Croquette nous disait récement dans fr.comp.securite
<news:9382136012642381.NC-1.48.ocroquette@news.free.fr> :

On 06 Sep 2003 20:59:31 GMT, Stephane Catteau wrote:

Un firewall est fait pour protéger un réseau, pas pour proposer
un service.

Ca dépend pleinement du degré de sécurité qu'on vise.
Pas vraiment non.

[Snip]

Sur la passerelle tournent quelques services ainsi que le pare-feu.

Et évidement tu es sûr à mille pourcent que ton filte IP ne tombera
jamais à cause, par exemple, d'une faiblesse face à certains paquets
malformés.

Le pare-feu refuse tout flux entrant venant d'Internet.

Ce qui ne l'empèche pas d'être obligé de traité tout le flux entrant,
et d'être donc potentiellement vulnérable.

Si l'on fait confiance aux utilisateurs ( ce qui est à priori le
cas d'un reseau domestique ), je trouve la sécurité suffisante.

Voilà... Votre problème, à deadcow et à toi, c'est que vous raisonnez
en partant de la situation idéale.
Pour lui c'était "Les failles d'un serveur HTTP ne sont pas
dangeureuse pour le système", oubliant que ce n'est pas le cas des
scripts qui tourneront sur ce serveur, qu'il suffit d'une mauvaise
configuration pour qu'un serveur HTTP puisse être nefaste
(http://blabla.tld/../../../../../../../etc/ipf.rules), et qu'une
faille sur un serveur HTTP peut réellement s'avérer dangeureuse.
Quant à toi, tes deux utopies sont dans ce message. Le filtre IP
resistera à tout, et les utilisateurs sont de confiance. Evidement
qu'ils sont de confiance les utilisateurs d'un réseau domestique,
jamais, au grand jamais, mon fils n'attrapera le virus de
l'informatique et jamais, au grand jamais, il ne lui viendra à l'idée
de tester la sécurité de ma passerelle-filtrante en essayant de la
trouer ou, pire, d'essayer d'améliorer sa configuration parce qu'à
quinze ans[1] il s'y connait forcément mieux que moi...


[1]
Ouf, j'ai encore un peu de temps pour apprendre ;-)
--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

Bonjour,

Je debute et je note.
J'ai bien compris que :
si je veux vraiment du secure, je ne fais pas tourner de serveur
sur mon firewall: pas de serveur http, pas de serveur ftp ....
Bon OK mais juste un truc.
J'ai sur mon firewall un disque de 20GO. je vais pas quand meme laisser
toute cette place inutilisée !!
Je peux quand meme monter un serveur nfs (accesible seulement a
partir du reseau local) pour pouvoir acceder a partir de mes
postes linux a mes partition de ce disque, non ?
Sinon dites moi quoi faire des 18 GO inutilisee de ce poste.

Merci.
J.C

"Stephane Catteau" <stephane@sc4x.net> a écrit dans le message news:
bjq170.3vv1i7n.1@sc4x.org...

Voilà... Votre problème, à deadcow et à toi, c'est que vous raisonnez
en partant de la situation idéale.

Et ton problème c'est que tu tente de metre en place une protection idéale
utopie ) alors qu'il faut adapter la protection à ce qu'il y a à proterger.
Jusqu'a présent, le réseaux dont on parle n'avait même pas de firewall, on
peut en conclure que les besoin en sécurité sont modeste d'où une solution
modeste, engageant peu de frais, et améliorant nettement le niveau de
sécurité actuel.

Pour lui c'était "Les failles d'un serveur HTTP ne sont pas
dangeureuse pour le système", oubliant que ce n'est pas le cas des
scripts qui tourneront sur ce serveur, qu'il suffit d'une mauvaise
configuration pour qu'un serveur HTTP puisse être nefaste

Idem avec tout les logiciel, y compris le firewall. Nous sommes donc
d'accord : rien n'est invulnérable par principe. Reste à adapter la solution
au besoin.

(http://blabla.tld/../../../../../../../etc/ipf.rules),

Un peu caricatural mais je vois le principe =)

et qu'une
faille sur un serveur HTTP peut réellement s'avérer dangeureuse.

Donc on parle bien de configuration. Mais si l'utilisateur configure mal le
serveur http, pourquoi est ce qu'il configurerai mieux le firewall ?

Quant à toi, tes deux utopies sont dans ce message. Le filtre IP
resistera à tout, et les utilisateurs sont de confiance.

Et l'administrateur réseaux, faut-il lui faire confiance ? Ce que je veut
dire c'est que le bas blaisse forcement à un endroit où à un autre. Le tout
c'est d'évaluer ce qui est résonable de mettre en place en fonction du temps
et des moyens qu'on décide de mettre au service de la sécurité.
Personellement, je préfaire mettre le firewall sur la même machine que le
serveur http, et prendre une demi-journée pour former le personel aux
précautions à prendre contre les virus.

-- Nicolas Repiquet

"Jean-Claude" <jcDOTaygalenq@NOSPAMwanadoo.fr> a écrit dans le message news:
20030911161514.4e55bbc9.jcDOTaygalenq@NOSPAMwanadoo.fr...

Bonjour,

Je debute et je note.
J'ai bien compris que :
si je veux vraiment du secure, je ne fais pas tourner de serveur
sur mon firewall: pas de serveur http, pas de serveur ftp ....
Bon OK mais juste un truc.
J'ai sur mon firewall un disque de 20GO. je vais pas quand meme laisser
toute cette place inutilisée !!
Je peux quand meme monter un serveur nfs (accesible seulement a
partir du reseau local) pour pouvoir acceder a partir de mes
postes linux a mes partition de ce disque, non ?
Sinon dites moi quoi faire des 18 GO inutilisee de ce poste.

Merci.
J.C

Si tu laisse que le firewall, tu peut carrement enlever le disque dur, et
mettre une distribution de linux spéciale firewall sur disquette genre
coyote linux floppy firewall ( http://www.coyotelinux.com/ )

-- Nicolas Repiquet

DeadCow nous disait récement dans fr.comp.securite
<news:3f60718e$0$27013$626a54ce@news.free.fr> :

"Stephane Catteau" <stephane@sc4x.net> a écrit dans le message

Voilà... Votre problème, à deadcow et à toi, c'est que vous
raisonnez en partant de la situation idéale.

Et ton problème c'est que tu tente de metre en place une protection
idéale utopie ) [...]

Comme le fait tout admin lorsqu'il s'agit de sécurité.

Jusqu'a présent, le réseaux dont on parle n'avait même pas de
firewall, on peut en conclure que les besoin en sécurité sont
modeste [...]

Ah bon ?

|je souhaiterai installer un firewall pour ma boite [...] Nous
|souhaitons monter un reseau digne de ce nom donc achat d'un serveur
|[...] je viens de m'en occuper et c'est un peu le bazar, il y a tout a
|faire.

Personnellement, ce que j'en conclus c'est qu'avant que tagada ne
mette son nez dans le réseau personne n'avait la moindre idée de ce
qu'était la sécurité informatique et des risques que courrait le réseau
et qu'il faisait courrir aux autres.

Pour lui c'était "Les failles d'un serveur HTTP ne sont pas
dangeureuse pour le système", oubliant que ce n'est pas le cas
des scripts qui tourneront sur ce serveur, qu'il suffit d'une
mauvaise configuration pour qu'un serveur HTTP puisse être
nefaste

Idem avec tout les logiciel, y compris le firewall. Nous sommes
donc d'accord : rien n'est invulnérable par principe.

Raison de plus pour ne pas multiplier les risques.

(http://blabla.tld/../../../../../../../etc/ipf.rules),

Un peu caricatural mais je vois le principe =)

Un classique qui marche bien plus souvent qu'on ne le croit. Cette
faille était d'ailleurs présente chez un hébergeur français à ses
débuts.

et qu'une faille sur un serveur HTTP peut réellement s'avérer
dangeureuse.

Donc on parle bien de configuration.

Ben non, tu cites justement la seule partie qui ne concerne aucunement
la configuration et qui échappe complètement au controle de
l'utilisateur.

Mais si l'utilisateur configure mal le serveur http, pourquoi est ce
qu'il configurerai mieux le firewall ?

Parce que les connaissances demandées ne sont pas les mêmes. Je suis
toujours incapable configurer correctement INN (je sais, ce n'est pas
un serveur HTTP), mais ça ne m'empèche pas d'avoir un filtre IP
étanche.

Quant à toi, tes deux utopies sont dans ce message. Le filtre IP
resistera à tout, et les utilisateurs sont de confiance.

Et l'administrateur réseaux, faut-il lui faire confiance ?

Non, et un bon admin commencera par se brider lui-même. Ce n'est pas
uniquement pour embêter les vilains pas beau que l'une des premières
choses à faire est d'interdire les logins sous root.

Ce que je veut dire c'est que le bas blaisse forcement à un endroit
où à un autre. Le tout c'est d'évaluer ce qui est résonable de mettre
en place en fonction du temps et des moyens qu'on décide de mettre
au service de la sécurité.

Comme l'a dit Cédric, tu prends le problème à l'envers. La pire faille
dans ta façon de procéder vient du fait que tu n'as aucune idée du
niveau de sécurité qui en résulte. Et je ne parle pas là uniquement de
la présence d'un serveur sur le firewall.
En suivant ta logique, on prend une machine, et ensuite on y rajoute
les briques que l'on veut pour le sécuriser. Soit, mais si la machine
n'est pas sécurisée par défaut, tu fais quoi ? Tu proposais du nunux,
prenons du nunux. Suivant les distributions l'on trouvera sendmail ou
postfix, en simple MTA pour la distribution locale et la liaison vers
l'extérieur, ou en véritable MTA ouvert sur le monde. Rajoute autant de
briques que tu le veux, si tu tournes avec sendmail en pleins services
tu auras une brèche à la base de tes briques.
Ce qu'il faut, c'est commencer par blinder entièrement la machine et,
après, retirer les briques qui empèchent de profiter de la vue.

Personellement, je préfaire mettre le firewall sur la même machine
que le serveur http, et prendre une demi-journée pour former le
personel aux précautions à prendre contre les virus.

Je préfère perdre cette demi-journée à installer un serveur local pour
la distribution des mails, avec un anti-virus intégré. Là au moins j'ai
la garantie que je ne devrais pas tout recommencer dans une semaine.


--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

On Thu, 11 Sep 2003 18:58:23 +0000, Stephane Catteau wrote:

[...] un bon admin commencera par se brider lui-même. Ce n'est pas
uniquement pour embêter les vilains pas beau que l'une des premières
choses à faire est d'interdire les logins sous root.

OK. Mais j'appelle pas ça "brider".

Démarrer son agent SSH et pouvoir se logguer sur ses machines, avec des
rebonds et tout le tralala, c'est le bonheur pour scripter les
interventions sur les machines. Avec un sudo pour avoir un compte
personnel par admin et une traçabilité des actions. C'est mieux que
l'époque "login en root via Telnet et Expect" :)

Ce qu'il faut, c'est commencer par blinder entièrement la machine et,
après, retirer les briques qui empèchent de profiter de la vue.

L'idéal, c'est d'avoir un "master" hyper-blindé qui sert à monter les
machines à la base (paquets à jour, base minimaliste de softs, pas de
démon qui tourne, comptes admins créés, droits sur le fs, kernel
maison+grsec, blindage de lILO, config apt, ...), et effectivement après,
la phase d'install de services, d'ouverture de règles de filtrage, etc.)

A terme, c'est le plus facile moyen (AMA) d'avoir un parc secure, à jour
et homogène. Sous Debian, avec un truc comme replicator, on peut monter
un serveur blindé en 20 minutes max, de l'ouverture du carton au serveur
"nickel".


Nicob

Nicob nous disait récement dans fr.comp.securite
<news:pan.2003.09.11.20.43.47.372421@nicob.net> :

On Thu, 11 Sep 2003 18:58:23 +0000, Stephane Catteau wrote:

[...] un bon admin commencera par se brider lui-même. Ce n'est
pas uniquement pour embêter les vilains pas beau que l'une des
premières choses à faire est d'interdire les logins sous root.

OK. Mais j'appelle pas ça "brider".

Moi non plus, mais j'avais pas d'autres exemples en tête :-(

Démarrer son agent SSH et pouvoir se logguer sur ses machines,
avec des rebonds et tout le tralala, c'est le bonheur pour
scripter les interventions sur les machines.

Et pourquoi pas[1] un compte juste pour les scripts, compte qui ne
pourrait se connecter que depuis une seule et unique machine. Le compte
est sans réels privilèges et se contente de déposer des instructions
(signées PGP ou autrement) pour un démon qui tourne sur la machine et
se chargera de terminer le scriptage à sa place, avec les droits
nécessaires puisque lui il les a.

Ce qu'il faut, c'est commencer par blinder entièrement la machine
et, après, retirer les briques qui empèchent de profiter de la vue.

L'idéal, c'est d'avoir un "master" hyper-blindé qui sert à monter
les machines à la base [...]

A terme, c'est le plus facile moyen (AMA) d'avoir un parc secure,
à jour et homogène.

Le plus important dans ce cas, amha, c'est surtout l'homogénéité.
Evidement aucune machine ne se ressemble exactement, mais si on bricole
à droit et à gauche, on fini par s'y perdre entre A qui a ceci mais pas
cela, et B qui a cela mais pas ceci. Ca tourne à la prise de tête, et
l'admin est tellement stressé[2] lorsqu'il s'occupera de la config'
qu'il fera des conneries.

Sous Debian, avec un truc comme replicator, on peut monter un serveur
blindé en 20 minutes max, de l'ouverture du carton au serveur
"nickel".

Ou FreeBSD avec Freesbie ( <http://www.freesbie.org/> )


[1]
Ca tombe bien puisque je suis justement entrain d'étudier un truc dans
ce genre.

[2]
Pour s'être éclaté un fois contre un mur qu'il croyait absent de cette
machine, et être tombé deux fois dans le vide en essayant de passer par
un pont qui n'est pas là.

--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

On 11 Sep 2003 11:53:28 GMT, Eric Demeester wrote:

Si l'on fait confiance aux utilisateurs ( ce qui est à priori le cas
d'un reseau domestique ), je trouve la sécurité suffisante.

Je m'en excuse par avance auprès d'eux, mais faire confiance aux
utilisateurs est déraisonnable en matière de sécurité.

Cf mon autre message en réponse à Stéphane, il faut bien faire des
compromis.

Tu ne fais pas confiance à tes utilisateurs.
Je suppose donc que tu ne fais pas non plus confiance aux développeurs
de logiciels ? Donc tu as développé toi-même ta chaine logiciele, de ton
propre compilateur fait en langage-machine aux bibliothèques, jusqu'aux
outils ?
Non ?
Donc tu fais un peu confiance aux auteurs des logiciels ?

Cela me parait aussi déraisonnable que de faire confiance à mes
utilisateurs [1].


[1] en nombre très réduits et dont les compétences en informatique sont
très connues, je rappelle.


--
Olivier

On 11 Sep 2003 16:08:05 GMT, Jean-Claude wrote:

si je veux vraiment du secure, je ne fais pas tourner de serveur
sur mon firewall: pas de serveur http, pas de serveur ftp ....
[...]

Je peux quand meme monter un serveur nfs (accesible seulement a
partir du reseau local) pour pouvoir acceder a partir de mes
postes linux a mes partition de ce disque, non ?

Tu dis toi-même pas de serveur, donc pas de serveur NFS non plus :)
En entreprise, tu risques d'avoir en plus des problèmes de
disponibilité. Si la machine tombe en carafe, tu perds à la fois le
disque de partage et la connexion, gênant doublement les utilisateurs.

--
Olivier