Christophe TREMBLAY-GUILLOUX
Infogérance serveur Debian Linux

Exemple de configuration NGINX pour SecuPress 2.3 et plus

Voici un exemple provisoire (étude en cours) pour appliquer les recommandations SecuPress.
Sauvegarder le contenu dans un fichier /etc/nginx/conf.d/secupress.conf car ce fichier doit être chargé dans le context “http” de NGINX.

Les variables ne sont calculées que si nécessaire. Par exemple, quand la configuration d’un site appelle la variable $REDIRECT_PHP404, c’est seulement à ce moment-là que les calculs sont faits.

J’ai ajouté une ligne pour ouvrir l’accès au fichier lock.php du plugin memberpress qui permet de faire du contrôle d’accès à des téléchargements de fichier.

				
					# Default value
map '' $REDIRECT_PHPTYPE {
    default '';
}

# FOLDERS case and php FILES case
map "$REDIRECT_PHPTYPE:$request_uri" $REDIRECT_PHP404_CHECK1 {
    default 0;
    "~*:/\.well-known/" 0;
    "~*(D|F):/secupress-sandbox-" 0;
    "~D:/?(\?|$)" 0;
    "~*D:/wp-admin(/(?:\?.*)?)?$" 0;
    "~D:.*" folders;
    "~*F:/(index|wp-activate|wp-comments-post|wp-cron|wp-links-opml|wp-load|wp-login|wp-mail|wp-pass|wp-signup|wp-trackback|xmlrpc)\.php(\?|$)" 0;
    "~*F:/wp-admin/(about|admin-ajax|admin-footer|admin-post|admin|async-upload|authorize-application|comment|contribute|credits|customize|edit-comments|edit-form-advanced|edit-form-blocks|edit-form-comment|edit-link-form|edit-tag-form|edit-tags|edit|erase-personal-data|export-personal-data|export|freedoms|import|index|link-add|link-manager|link|load-scripts|load-styles|maint/repair|media-new|media-upload|media|moderation|ms-admin|ms-delete-site|ms-edit|ms-options|ms-sites|ms-themes|ms-upgrade-network|ms-users|my-sites|nav-menus|network/about|network/admin|network/contribute|network/credits|network/edit|network/freedoms|network/index|network/plugin-editor|network/plugin-install|network/plugins|network/privacy|network/profile|network/settings|network/setup|network/site-info|network/site-new|network/site-settings|network/site-themes|network/site-users|network/sites|network/theme-editor|network/theme-install|network/themes|network/update-core|network/update|network/upgrade|network/user-edit|network/user-new|network/users|network|options-discussion|options-general|options-media|options-permalink|options-privacy|options-reading|options-writing|options|plugin-editor|plugin-install|plugins|post-new|post|press-this|privacy-policy-guide|privacy|profile|revision|site-editor|site-health|term|theme-editor|theme-install|themes|tools|update-core|update|upgrade|upload|user/about|user/admin|user/credits|user/freedoms|user/index|user/privacy|user/profile|user/user-edit|user-edit|user-new|users|widgets-form-blocks|widgets-form|widgets)\.php(\?|$)" 0;
    "~*F:/wp-includes/js/tinymce/wp-tinymce\.php(\?|$)" 0;
    "~*F:/wp-content/plugins/memberpress/lock\.php(\?|$)" 0;
    "~*0:F:/wp-content/.*\.php(\?|$)" content;
    "~*F:.*\.php(\?|$)" files;
    "~*:.*\.php(\?|$)" files;
}

# EXTS case
map "$REDIRECT_PHP404_CHECK1:$REDIRECT_PHPTYPE:$request_uri" $REDIRECT_PHP404 {
    default 0;
    "~folders:.*:.*" folders;
    "~files:.*:.*" files;
    "~content:.*:.*" content;
    "~*0:F:.*\.(jpg|jpeg|jpe|gif|png|bmp|tiff|tif|webp|avif|ico|heic|heif|heics|heifs|asf|asx|wmv|wmx|wm|avi|divx|flv|mov|qt|mpeg|mpg|mpe|mp4|m4v|ogv|webm|mkv|3gp|3gpp|3g2|3gp2|txt|asc|c|cc|h|srt|csv|tsv|ics|rtx|css|htm|html|vtt|dfxp|mp3|m4a|m4b|aac|ra|ram|wav|x-wav|ogg|oga|flac|mid|midi|wma|wax|mka|rtf|js|pdf|class|tar|zip|gz|gzip|rar|7z|psd|xcf|doc|pot|pps|ppt|wri|xla|xls|xlt|xlw|mdb|mpp|docx|docm|dotx|dotm|xlsx|xlsm|xlsb|xltx|xltm|xlam|pptx|pptm|ppsx|ppsm|potx|potm|ppam|sldx|sldm|onetoc|onetoc2|onetmp|onepkg|oxps|xps|odt|odp|ods|odg|odc|odb|odf|wp|wpd|key|numbers|pages|php|ai|eps|ttf|otf|ott|woff|woff2|eot|svg|md|log|xml|xsl)(\?|$)" 0;
    "~*0:F:.*" exts;
}

				
			

Puis ajouter l’autre partie dans le context “server” du site internet, pas dans un context “location” car l’idée est de pouvoir appliquer à la fois au php et aux fichiers statics :

				
					# BEGIN SecuPress bad_url_access
if (-d $request_filename) {
    set $REDIRECT_PHPTYPE D;
}
if (-f $request_filename) {
    set $REDIRECT_PHPTYPE F;
}
if ($REDIRECT_PHP404 != 0) {
    rewrite ^ /wp-content/plugins/secupress-pro/free/data/404-handler.php?secupress_bad_url_access__ID=$REDIRECT_PHP404&secupress_bad_url_access__URL=$request_uri last;
}
# END SecuPress

# WORDPRESS
location / {
    # BEGIN SecuPress directory_listing
    autoindex off;
    # END SecuPress

    # BEGIN SecuPress php_disclosure
    if ( $query_string ~* "\=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}" ) {
        return 403;
    }
    # END SecuPress

    try_files $uri $uri/ /index.php?$args;
}
				
			

Actuellement, le fichier 404-handler.php retourne une erreur 404 (ce qui est normal a priori) mais le scan du module ne détecte pas correctement le fait qu’on a bien intercepté les erreurs 404 sur les fichiers php qui n’existent pas.

Quelle est la mystérieuse ingénierie qui me permet d'obtenir un serveur Linux fiable et performant, sans devoir monter la garde jour et nuit ?

Accéder aux tarifs

Accéder aux tarifs