Désolé si mes questions font lever les yeux (ou les bras) au ciel à
certains, je débute..
Soit un serveur web (Apache 2.0.53 sur Win2000 serveur) dans une DMZ
(IPCOP 1.4.4), auquel il faut bien accéder depuis le réseau interne pour
les mises-à-jour, machines client en win98 ou 2000, ou MAC OSX.
Quelle serait la solution à retenir pour ces tranferts de fichiers ?
Un classique serveur FTP installé sur la machine serveur web ?
Le module FTP de IIS (par ailleurs utilisé pour sa fonction SMTP)
peut-il convenir ? Ou quelque chose de plus sécurisé ? (j'ai entendu
parler de SSH ?)
Je suppose qu'il faudra bien entendu veiller sous IPCOP à n'autoriser le
FTP que pour DMZ <-> réseau local.
Si vous avez une solution simple, sûre, et gratuite, je suis à votre écoute.
Dernier point : lors de divers test de sécurité en ligne, Apache renvoie
sa banière standard, serait plus prudent de modifier cela, et comment ?
De même que bloquer les ICMP type 8 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
MaXX
bonjour, un morceau de reponse...
Kefran wrote:
Bonjour à tous [...] Dernier point : lors de divers test de sécurité en ligne, Apache renvoie sa banière standard, serait plus prudent de modifier cela, et comment ? Par httpd.conf
---extrait de la page---- ServerTokens Prod[uctOnly] Server sends (e.g.): Server: Apache ServerTokens Major Server sends (e.g.): Server: Apache/2 ServerTokens Minor Server sends (e.g.): Server: Apache/2.0 ServerTokens Min[imal] Server sends (e.g.): Server: Apache/2.0.41 ServerTokens OS Server sends (e.g.): Server: Apache/2.0.41 (Unix) ServerTokens Full (or not specified) Server sends (e.g.): Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2 --------------------------
ça doit marcher sous w32 aussi
Merci pour votre aide.
-- MaXX
bonjour,
un morceau de reponse...
Kefran wrote:
Bonjour à tous
[...]
Dernier point : lors de divers test de sécurité en ligne, Apache renvoie
sa banière standard, serait plus prudent de modifier cela, et comment ?
Par httpd.conf
---extrait de la page----
ServerTokens Prod[uctOnly]
Server sends (e.g.): Server: Apache
ServerTokens Major
Server sends (e.g.): Server: Apache/2
ServerTokens Minor
Server sends (e.g.): Server: Apache/2.0
ServerTokens Min[imal]
Server sends (e.g.): Server: Apache/2.0.41
ServerTokens OS
Server sends (e.g.): Server: Apache/2.0.41 (Unix)
ServerTokens Full (or not specified)
Server sends (e.g.): Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2
--------------------------
Bonjour à tous [...] Dernier point : lors de divers test de sécurité en ligne, Apache renvoie sa banière standard, serait plus prudent de modifier cela, et comment ? Par httpd.conf
---extrait de la page---- ServerTokens Prod[uctOnly] Server sends (e.g.): Server: Apache ServerTokens Major Server sends (e.g.): Server: Apache/2 ServerTokens Minor Server sends (e.g.): Server: Apache/2.0 ServerTokens Min[imal] Server sends (e.g.): Server: Apache/2.0.41 ServerTokens OS Server sends (e.g.): Server: Apache/2.0.41 (Unix) ServerTokens Full (or not specified) Server sends (e.g.): Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2 --------------------------
ça doit marcher sous w32 aussi
Merci pour votre aide.
-- MaXX
Nicob
On Wed, 23 Mar 2005 17:48:04 +0000, Kefran wrote:
Quelle serait la solution à retenir pour ces tranferts de fichiers ? Un classique serveur FTP installé sur la machine serveur web ?
C'est en effet la solution la plus simple.
Le module FTP de IIS (par ailleurs utilisé pour sa fonction SMTP) peut-il convenir ?
Si tenu à jour (avec en plus le compte anonyme désactivé), c'est tout à fait correct pour l'usage que tu souhaites en faire.
Ou quelque chose de plus sécurisé ? (j'ai entendu parler de SSH ?)
Tout dépend de tes besoins. Si tu as confiance dans ton LAN, tu peux très bien utiliser FTP. SI tu passes en SSH, tu vas galérer pour convaincre tes utilisateurs (nouveau soft, GUI différente de leur client FTP habituel, ...).
Je suppose qu'il faudra bien entendu veiller sous IPCOP à n'autoriser le FTP que pour DMZ <-> réseau local
Euh .. LAN -> DMZ, tu veux dire, non ?
Nicob
On Wed, 23 Mar 2005 17:48:04 +0000, Kefran wrote:
Quelle serait la solution à retenir pour ces tranferts de fichiers ? Un
classique serveur FTP installé sur la machine serveur web ?
C'est en effet la solution la plus simple.
Le module FTP de IIS (par ailleurs utilisé pour sa fonction SMTP) peut-il
convenir ?
Si tenu à jour (avec en plus le compte anonyme désactivé), c'est tout
à fait correct pour l'usage que tu souhaites en faire.
Ou quelque chose de plus sécurisé ? (j'ai entendu parler de
SSH ?)
Tout dépend de tes besoins. Si tu as confiance dans ton LAN, tu peux
très bien utiliser FTP. SI tu passes en SSH, tu vas galérer pour
convaincre tes utilisateurs (nouveau soft, GUI différente de leur client
FTP habituel, ...).
Je suppose qu'il faudra bien entendu veiller sous IPCOP à n'autoriser
le FTP que pour DMZ <-> réseau local
Quelle serait la solution à retenir pour ces tranferts de fichiers ? Un classique serveur FTP installé sur la machine serveur web ?
C'est en effet la solution la plus simple.
Le module FTP de IIS (par ailleurs utilisé pour sa fonction SMTP) peut-il convenir ?
Si tenu à jour (avec en plus le compte anonyme désactivé), c'est tout à fait correct pour l'usage que tu souhaites en faire.
Ou quelque chose de plus sécurisé ? (j'ai entendu parler de SSH ?)
Tout dépend de tes besoins. Si tu as confiance dans ton LAN, tu peux très bien utiliser FTP. SI tu passes en SSH, tu vas galérer pour convaincre tes utilisateurs (nouveau soft, GUI différente de leur client FTP habituel, ...).
Je suppose qu'il faudra bien entendu veiller sous IPCOP à n'autoriser le FTP que pour DMZ <-> réseau local
Euh .. LAN -> DMZ, tu veux dire, non ?
Nicob
Kefran
Euh .. LAN -> DMZ, tu veux dire, non ?
Heu, oui, j'ai bien pensé mais mal écrit.
Que penses-tu de l'utilité de droper les ICMP 8 en entrée ? J'ai lu qu'ils pouvaient être utilisés à des fins nocives, et en dehors d'un petit outil qui pinguerait à intervalles réguliers l'IP fixe attribuée au modem-routeur, ou le "www.massociété.com" pour voir si le serveur est toujours vivant, je n'en vois pas trop l'utilité ?
Merci pour tes lumières :)
Euh .. LAN -> DMZ, tu veux dire, non ?
Heu, oui, j'ai bien pensé mais mal écrit.
Que penses-tu de l'utilité de droper les ICMP 8 en entrée ?
J'ai lu qu'ils pouvaient être utilisés à des fins nocives, et en dehors
d'un petit outil qui pinguerait à intervalles réguliers l'IP fixe
attribuée au modem-routeur, ou le "www.massociété.com" pour voir si le
serveur est toujours vivant, je n'en vois pas trop l'utilité ?
Que penses-tu de l'utilité de droper les ICMP 8 en entrée ? J'ai lu qu'ils pouvaient être utilisés à des fins nocives, et en dehors d'un petit outil qui pinguerait à intervalles réguliers l'IP fixe attribuée au modem-routeur, ou le "www.massociété.com" pour voir si le serveur est toujours vivant, je n'en vois pas trop l'utilité ?
Merci pour tes lumières :)
VANHULLEBUS Yvan
(Xavier) writes:
Nicob wrote:
Je suppose qu'il faudra bien entendu veiller sous IPCOP à n'autoriser le FTP que pour DMZ <-> réseau local
Euh .. LAN -> DMZ, tu veux dire, non ?
Ben non, avec cette saloperie de protocole, il faut bel et bien des règles retour.
Euh, soit IPCop utilise encore ipchains, et il faudrait penser a mettre a jour, soit il utilise Netfilter, et il y a un conntrack pour FTP, qui permet d'ecrire des regles de filtrage relativement simples et d'avoir un suivi stateful des sessions, y compris des sessions DATA FTP...
A +
VANHU.
xavier@groumpf.org (Xavier) writes:
Nicob <nicob@I.hate.spammers.com> wrote:
Je suppose qu'il faudra bien entendu veiller sous IPCOP à n'autoriser
le FTP que pour DMZ <-> réseau local
Euh .. LAN -> DMZ, tu veux dire, non ?
Ben non, avec cette saloperie de protocole, il faut bel et bien des
règles retour.
Euh, soit IPCop utilise encore ipchains, et il faudrait penser a
mettre a jour, soit il utilise Netfilter, et il y a un conntrack pour
FTP, qui permet d'ecrire des regles de filtrage relativement simples
et d'avoir un suivi stateful des sessions, y compris des sessions DATA
FTP...
Je suppose qu'il faudra bien entendu veiller sous IPCOP à n'autoriser le FTP que pour DMZ <-> réseau local
Euh .. LAN -> DMZ, tu veux dire, non ?
Ben non, avec cette saloperie de protocole, il faut bel et bien des règles retour.
Euh, soit IPCop utilise encore ipchains, et il faudrait penser a mettre a jour, soit il utilise Netfilter, et il y a un conntrack pour FTP, qui permet d'ecrire des regles de filtrage relativement simples et d'avoir un suivi stateful des sessions, y compris des sessions DATA FTP...
A +
VANHU.
Kefran
Euh, soit IPCop utilise encore ipchains, et il faudrait penser a mettre a jour, soit il utilise Netfilter, et il y a un conntrack pour FTP, qui permet d'ecrire des regles de filtrage relativement simples et d'avoir un suivi stateful des sessions, y compris des sessions DATA FTP...
Sauf erreur, il utilise Iptables. C'est lui qu'on peut utiliser en ligne de commande pour affiner les réglages que permet l'interface web de gestion d'IPCOP.
Euh, soit IPCop utilise encore ipchains, et il faudrait penser a
mettre a jour, soit il utilise Netfilter, et il y a un conntrack pour
FTP, qui permet d'ecrire des regles de filtrage relativement simples
et d'avoir un suivi stateful des sessions, y compris des sessions DATA
FTP...
Sauf erreur, il utilise Iptables.
C'est lui qu'on peut utiliser en ligne de commande pour affiner les
réglages que permet l'interface web de gestion d'IPCOP.
Euh, soit IPCop utilise encore ipchains, et il faudrait penser a mettre a jour, soit il utilise Netfilter, et il y a un conntrack pour FTP, qui permet d'ecrire des regles de filtrage relativement simples et d'avoir un suivi stateful des sessions, y compris des sessions DATA FTP...
Sauf erreur, il utilise Iptables. C'est lui qu'on peut utiliser en ligne de commande pour affiner les réglages que permet l'interface web de gestion d'IPCOP.
VANHULLEBUS Yvan
Kefran writes:
Euh, soit IPCop utilise encore ipchains, et il faudrait penser a mettre a jour, soit il utilise Netfilter, et il y a un conntrack pour FTP, qui permet d'ecrire des regles de filtrage relativement simples et d'avoir un suivi stateful des sessions, y compris des sessions DATA FTP...
Sauf erreur, il utilise Iptables. C'est lui qu'on peut utiliser en ligne de commande pour affiner les réglages que permet l'interface web de gestion d'IPCOP.
iptables est l'outil en ligne de commande qui permet d'influer sur la configuration du moteur de filtrage lui meme, qui s'appelle netfilter.
Donc pour ce qui est du flux FTP (en supposant que ca soit une solution pertinente, je n'ai fait que vaguement survoler le reste du thread), il ne faut pas mettre de regles explicites pour les flux de retour et/ou les flux de donnees (sessions DATA), mais "juste" la regle pour l'initiation des sessions de commandes (client -> serveur port ftp), les regles de stateful qui vont bien et le module de CONTRACK ftp, les deux derniers se chargeront d'autoriser dynamiquement tout ce qui est normal mais pas autorise par la regle d'initiation de sessions...
A +
VANHU.
Kefran <invalid@invalid.org> writes:
Euh, soit IPCop utilise encore ipchains, et il faudrait penser a
mettre a jour, soit il utilise Netfilter, et il y a un conntrack pour
FTP, qui permet d'ecrire des regles de filtrage relativement simples
et d'avoir un suivi stateful des sessions, y compris des sessions DATA
FTP...
Sauf erreur, il utilise Iptables.
C'est lui qu'on peut utiliser en ligne de commande pour affiner les
réglages que permet l'interface web de gestion d'IPCOP.
iptables est l'outil en ligne de commande qui permet d'influer sur la
configuration du moteur de filtrage lui meme, qui s'appelle netfilter.
Donc pour ce qui est du flux FTP (en supposant que ca soit une
solution pertinente, je n'ai fait que vaguement survoler le reste du
thread), il ne faut pas mettre de regles explicites pour les flux de
retour et/ou les flux de donnees (sessions DATA), mais "juste" la
regle pour l'initiation des sessions de commandes (client -> serveur
port ftp), les regles de stateful qui vont bien et le module de
CONTRACK ftp, les deux derniers se chargeront d'autoriser
dynamiquement tout ce qui est normal mais pas autorise par la regle
d'initiation de sessions...
Euh, soit IPCop utilise encore ipchains, et il faudrait penser a mettre a jour, soit il utilise Netfilter, et il y a un conntrack pour FTP, qui permet d'ecrire des regles de filtrage relativement simples et d'avoir un suivi stateful des sessions, y compris des sessions DATA FTP...
Sauf erreur, il utilise Iptables. C'est lui qu'on peut utiliser en ligne de commande pour affiner les réglages que permet l'interface web de gestion d'IPCOP.
iptables est l'outil en ligne de commande qui permet d'influer sur la configuration du moteur de filtrage lui meme, qui s'appelle netfilter.
Donc pour ce qui est du flux FTP (en supposant que ca soit une solution pertinente, je n'ai fait que vaguement survoler le reste du thread), il ne faut pas mettre de regles explicites pour les flux de retour et/ou les flux de donnees (sessions DATA), mais "juste" la regle pour l'initiation des sessions de commandes (client -> serveur port ftp), les regles de stateful qui vont bien et le module de CONTRACK ftp, les deux derniers se chargeront d'autoriser dynamiquement tout ce qui est normal mais pas autorise par la regle d'initiation de sessions...
