Je vais bientôt mettre en place un serveur sous Windows .NET pour usage
personnel.
Je souhaiterais savoir si certaines personnes connaissent des logiciels
pour contrôler l'aspect sécurité du système, notamment au niveau de la
configuration IIS/ASP.NET.
J'ai téléchargé : Microsoft Baseline Security Analyzer 1.2.1
Pas encore testé.
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
Samuel
Bonjour,
Bonjour. Je vais bientôt mettre en place un serveur sous Windows .NET pour usage personnel. Je souhaiterais savoir si certaines personnes connaissent des logiciels pour contrôler l'aspect sécurité du système, notamment au niveau de la configuration IIS/ASP.NET. J'ai téléchargé : Microsoft Baseline Security Analyzer 1.2.1 Pas encore testé. J'attends vos retours, merci. -- Delf
Comme personne ne répond je vais essayer :
D'après mon expérience de IIS sur Win2000, ce n'est pas tant les mises à jour qui comptent (contrairement à un poste de travail) mais la configuration du service en lui-même :
Comme pour tout aspect sécuritaire, il faut tout virer pour ne garder que l'essentiel.
1) Mettre ton repertoire web sur une partition séparée (c'est encore plus important pour tes bases de données qui ne *doivent pas* être dans ton arborescence Web). 2) Virer tous les fichiers et repertoires de gestion et d'exemples à la racine du site.
Ensuite tu travailles les options *générales* relatives à tous les sites Web :
1) Supprimer l'accès relatif au chemin parent qui est la base des failles cross-scripting. 2) Supprimer toutes les extensions que tu n'utilises pas (perso il reste : .asp .asa .cert) c'est cette astuce qui permet d'avoir un peu plus de marge avec les mises à jour car les failles sur les 3 extensions que je garde sont rares ... mais pas improbables. 3) Ne pas envoyer de message d'erreur détaillé au client mais un message préformaté (faire l'inverse pour ton serveur de dev non relié au Net)
Après cette entrée en matière tu installes 'urlscan' qui va filtrer toutes les requêtes *avant* qu'elles n'arrivent à ton serveur Web.
Là encore j'ai choisi de *tout* virer et de ne rajouter *que* les extensions autorisées : htm; html, asp, txt, jpg, jpeg, gif, asf, asa, css et avi. Les autres configurations par défaut de urlscan sont bonnes et permettent d'éviter la majorité des failles par debordement de tampon mémoire à cause de requêtes trop longues par exemple.
Voilà quelques idées de base pour commencer à sécuriser un serveur IIS. Cependant le mot-clef 'urlscan' te permettra d'avoir d'autres bonnes infos sur le net.
Dans les resultats, j'ai un seveur IIS qui tourne depuis 2000 avec cette config en mettant juste de temps à autres les SP et je n'ai jamais eu le moindre problème ... j'ai encore vérifié il y quelques mois avec un anti-virus en ligne, pas d'activité suspecte.
Samuel.
Bonjour,
Bonjour.
Je vais bientôt mettre en place un serveur sous Windows .NET pour usage
personnel.
Je souhaiterais savoir si certaines personnes connaissent des logiciels
pour contrôler l'aspect sécurité du système, notamment au niveau de la
configuration IIS/ASP.NET.
J'ai téléchargé : Microsoft Baseline Security Analyzer 1.2.1
Pas encore testé.
J'attends vos retours, merci.
--
Delf
Comme personne ne répond je vais essayer :
D'après mon expérience de IIS sur Win2000, ce n'est pas tant les mises à
jour qui comptent (contrairement à un poste de travail) mais la
configuration du service en lui-même :
Comme pour tout aspect sécuritaire, il faut tout virer pour ne garder
que l'essentiel.
1) Mettre ton repertoire web sur une partition séparée (c'est encore
plus important pour tes bases de données qui ne *doivent pas* être dans
ton arborescence Web).
2) Virer tous les fichiers et repertoires de gestion et d'exemples à la
racine du site.
Ensuite tu travailles les options *générales* relatives à tous les sites
Web :
1) Supprimer l'accès relatif au chemin parent qui est la base des
failles cross-scripting.
2) Supprimer toutes les extensions que tu n'utilises pas (perso il reste
: .asp .asa .cert) c'est cette astuce qui permet d'avoir un peu plus de
marge avec les mises à jour car les failles sur les 3 extensions que je
garde sont rares ... mais pas improbables.
3) Ne pas envoyer de message d'erreur détaillé au client mais un message
préformaté (faire l'inverse pour ton serveur de dev non relié au Net)
Après cette entrée en matière tu installes 'urlscan' qui va filtrer
toutes les requêtes *avant* qu'elles n'arrivent à ton serveur Web.
Là encore j'ai choisi de *tout* virer et de ne rajouter *que* les
extensions autorisées : htm; html, asp, txt, jpg, jpeg, gif, asf, asa,
css et avi.
Les autres configurations par défaut de urlscan sont bonnes et
permettent d'éviter la majorité des failles par debordement de tampon
mémoire à cause de requêtes trop longues par exemple.
Voilà quelques idées de base pour commencer à sécuriser un serveur IIS.
Cependant le mot-clef 'urlscan' te permettra d'avoir d'autres bonnes
infos sur le net.
Dans les resultats, j'ai un seveur IIS qui tourne depuis 2000 avec cette
config en mettant juste de temps à autres les SP et je n'ai jamais eu le
moindre problème ... j'ai encore vérifié il y quelques mois avec un
anti-virus en ligne, pas d'activité suspecte.
Bonjour. Je vais bientôt mettre en place un serveur sous Windows .NET pour usage personnel. Je souhaiterais savoir si certaines personnes connaissent des logiciels pour contrôler l'aspect sécurité du système, notamment au niveau de la configuration IIS/ASP.NET. J'ai téléchargé : Microsoft Baseline Security Analyzer 1.2.1 Pas encore testé. J'attends vos retours, merci. -- Delf
Comme personne ne répond je vais essayer :
D'après mon expérience de IIS sur Win2000, ce n'est pas tant les mises à jour qui comptent (contrairement à un poste de travail) mais la configuration du service en lui-même :
Comme pour tout aspect sécuritaire, il faut tout virer pour ne garder que l'essentiel.
1) Mettre ton repertoire web sur une partition séparée (c'est encore plus important pour tes bases de données qui ne *doivent pas* être dans ton arborescence Web). 2) Virer tous les fichiers et repertoires de gestion et d'exemples à la racine du site.
Ensuite tu travailles les options *générales* relatives à tous les sites Web :
1) Supprimer l'accès relatif au chemin parent qui est la base des failles cross-scripting. 2) Supprimer toutes les extensions que tu n'utilises pas (perso il reste : .asp .asa .cert) c'est cette astuce qui permet d'avoir un peu plus de marge avec les mises à jour car les failles sur les 3 extensions que je garde sont rares ... mais pas improbables. 3) Ne pas envoyer de message d'erreur détaillé au client mais un message préformaté (faire l'inverse pour ton serveur de dev non relié au Net)
Après cette entrée en matière tu installes 'urlscan' qui va filtrer toutes les requêtes *avant* qu'elles n'arrivent à ton serveur Web.
Là encore j'ai choisi de *tout* virer et de ne rajouter *que* les extensions autorisées : htm; html, asp, txt, jpg, jpeg, gif, asf, asa, css et avi. Les autres configurations par défaut de urlscan sont bonnes et permettent d'éviter la majorité des failles par debordement de tampon mémoire à cause de requêtes trop longues par exemple.
Voilà quelques idées de base pour commencer à sécuriser un serveur IIS. Cependant le mot-clef 'urlscan' te permettra d'avoir d'autres bonnes infos sur le net.
Dans les resultats, j'ai un seveur IIS qui tourne depuis 2000 avec cette config en mettant juste de temps à autres les SP et je n'ai jamais eu le moindre problème ... j'ai encore vérifié il y quelques mois avec un anti-virus en ligne, pas d'activité suspecte.
Samuel.
Nicob
On Thu, 28 Jul 2005 16:41:11 +0000, Samuel wrote:
Comme pour tout aspect sécuritaire, il faut tout virer pour ne garder que l'essentiel.
Et faire un scan a posteriori, histoire de voir si tout à l'air OK : - Nessus (http://www.nessus.org) - Nikto (http://www.cirt.net/code/nikto.shtml) - DnaScan.pl (http://www.wikisecure.com/index.php/DnaScan.pl)
NB : le dernier de ces outils est dédié à .NET ...
Nicob
On Thu, 28 Jul 2005 16:41:11 +0000, Samuel wrote:
Comme pour tout aspect sécuritaire, il faut tout virer pour ne garder
que l'essentiel.
Et faire un scan a posteriori, histoire de voir si tout à l'air OK :
- Nessus (http://www.nessus.org)
- Nikto (http://www.cirt.net/code/nikto.shtml)
- DnaScan.pl (http://www.wikisecure.com/index.php/DnaScan.pl)
NB : le dernier de ces outils est dédié à .NET ...
Comme pour tout aspect sécuritaire, il faut tout virer pour ne garder que l'essentiel.
Et faire un scan a posteriori, histoire de voir si tout à l'air OK : - Nessus (http://www.nessus.org) - Nikto (http://www.cirt.net/code/nikto.shtml) - DnaScan.pl (http://www.wikisecure.com/index.php/DnaScan.pl)
NB : le dernier de ces outils est dédié à .NET ...
Nicob
Samuel
Et faire un scan a posteriori, histoire de voir si tout à l'air OK : - Nessus (http://www.nessus.org) - Nikto (http://www.cirt.net/code/nikto.shtml) - DnaScan.pl (http://www.wikisecure.com/index.php/DnaScan.pl) Nicob
En effet, j'ai parlé uniquement de la sécurisation de IIS, donc il faut penser à sécuriser *aussi* la machine (les ports autres que le 80). Dans mon cas une passerelle linux/netfilter s'occupe de filtrer les flux IP.
Côté programmation il faut faire attention au failles des scripts qui accèdent à des BDD via le langage SQL. Il est impératif de traiter les formulaires envoyés à des scripts de requêtes SQL en y enlevant tous les caractères non autorisés ('& etc ...) et cela côté serveur en ASP et non pas sur le client en javascript ;-) De plus tes bases doivent être en dehors de l'arborescence web et être appelées via DSN sinon il suffit pour un client de taper le chemin d'accès web à ta base pour la télécharger !
Concernant IIS, j'ai oublié un autre point important : les droits NTFS : De préférence régler les droits NTFS les plus restrictifs possibles : iwam et iusr en lecture seule sur toute l'arborescence sauf sur un repertoire par site où tu mets des droits d'écriture pour tes dossiers devant être accédés en écriture (compteur web etc...). Encore au niveau NTFS, on peut aussi interdire l'exécution de tous les fichiers sur toute l'arborescence web pour tous les comptes (sauf exception comme au-dessus). On doit même pouvoir réduire les droits des comptes administrateur et system et créer un autre compte qui lui a les droits de gestion distante.
Maintenant il faut avoir une arborescence web souple et le temps de tester pour pouvoir mettre en place toutes ces options de config. Et j'ai certainement oublié d'autres points importants.
Samuel.
Et faire un scan a posteriori, histoire de voir si tout à l'air OK :
- Nessus (http://www.nessus.org)
- Nikto (http://www.cirt.net/code/nikto.shtml)
- DnaScan.pl (http://www.wikisecure.com/index.php/DnaScan.pl)
Nicob
En effet, j'ai parlé uniquement de la sécurisation de IIS, donc il faut
penser à sécuriser *aussi* la machine (les ports autres que le 80).
Dans mon cas une passerelle linux/netfilter s'occupe de filtrer les flux IP.
Côté programmation il faut faire attention au failles des scripts qui
accèdent à des BDD via le langage SQL. Il est impératif de traiter les
formulaires envoyés à des scripts de requêtes SQL en y enlevant tous les
caractères non autorisés ('& etc ...) et cela côté serveur en ASP et non
pas sur le client en javascript ;-)
De plus tes bases doivent être en dehors de l'arborescence web et être
appelées via DSN sinon il suffit pour un client de taper le chemin
d'accès web à ta base pour la télécharger !
Concernant IIS, j'ai oublié un autre point important : les droits NTFS :
De préférence régler les droits NTFS les plus restrictifs possibles :
iwam et iusr en lecture seule sur toute l'arborescence sauf sur un
repertoire par site où tu mets des droits d'écriture pour tes dossiers
devant être accédés en écriture (compteur web etc...).
Encore au niveau NTFS, on peut aussi interdire l'exécution de tous les
fichiers sur toute l'arborescence web pour tous les comptes (sauf
exception comme au-dessus).
On doit même pouvoir réduire les droits des comptes administrateur et
system et créer un autre compte qui lui a les droits de gestion distante.
Maintenant il faut avoir une arborescence web souple et le temps de
tester pour pouvoir mettre en place toutes ces options de config.
Et j'ai certainement oublié d'autres points importants.
Et faire un scan a posteriori, histoire de voir si tout à l'air OK : - Nessus (http://www.nessus.org) - Nikto (http://www.cirt.net/code/nikto.shtml) - DnaScan.pl (http://www.wikisecure.com/index.php/DnaScan.pl) Nicob
En effet, j'ai parlé uniquement de la sécurisation de IIS, donc il faut penser à sécuriser *aussi* la machine (les ports autres que le 80). Dans mon cas une passerelle linux/netfilter s'occupe de filtrer les flux IP.
Côté programmation il faut faire attention au failles des scripts qui accèdent à des BDD via le langage SQL. Il est impératif de traiter les formulaires envoyés à des scripts de requêtes SQL en y enlevant tous les caractères non autorisés ('& etc ...) et cela côté serveur en ASP et non pas sur le client en javascript ;-) De plus tes bases doivent être en dehors de l'arborescence web et être appelées via DSN sinon il suffit pour un client de taper le chemin d'accès web à ta base pour la télécharger !
Concernant IIS, j'ai oublié un autre point important : les droits NTFS : De préférence régler les droits NTFS les plus restrictifs possibles : iwam et iusr en lecture seule sur toute l'arborescence sauf sur un repertoire par site où tu mets des droits d'écriture pour tes dossiers devant être accédés en écriture (compteur web etc...). Encore au niveau NTFS, on peut aussi interdire l'exécution de tous les fichiers sur toute l'arborescence web pour tous les comptes (sauf exception comme au-dessus). On doit même pouvoir réduire les droits des comptes administrateur et system et créer un autre compte qui lui a les droits de gestion distante.
Maintenant il faut avoir une arborescence web souple et le temps de tester pour pouvoir mettre en place toutes ces options de config. Et j'ai certainement oublié d'autres points importants.
Samuel.
Nicob
On Thu, 04 Aug 2005 16:44:41 +0000, Samuel wrote:
Encore au niveau NTFS, on peut aussi interdire l'exécution de tous les fichiers sur toute l'arborescence web pour tous les comptes (sauf exception comme au-dessus).
Et aussi retirer à iwan et iusr les droits d'accès aux répertoires "système" (dont entre autres ceux contenant cmd.exe, command.com, tftp.exe). Ceinture & bretelles, quoi ...
Nicob
On Thu, 04 Aug 2005 16:44:41 +0000, Samuel wrote:
Encore au niveau NTFS, on peut aussi interdire l'exécution de tous les
fichiers sur toute l'arborescence web pour tous les comptes (sauf
exception comme au-dessus).
Et aussi retirer à iwan et iusr les droits d'accès aux répertoires
"système" (dont entre autres ceux contenant cmd.exe, command.com,
tftp.exe). Ceinture & bretelles, quoi ...
Encore au niveau NTFS, on peut aussi interdire l'exécution de tous les fichiers sur toute l'arborescence web pour tous les comptes (sauf exception comme au-dessus).
Et aussi retirer à iwan et iusr les droits d'accès aux répertoires "système" (dont entre autres ceux contenant cmd.exe, command.com, tftp.exe). Ceinture & bretelles, quoi ...
