After some (failed it seems, can't be sure since if someone actually got access can erase the trails) hack attempts during last few days over one of my servers I decided to tighten the security a bit.
The project is on symfony 4, with a rather standard structure. Server is nginx, with php-fpm as interpretor.
One of the (many) changes I want to make is not allowing any .php calls (since all traffic is routed towards index.php anyway that should be the only file that is directly interpreted by php). So I came up with the following config:
server {
listen 80 443;
# https config here
server_name epicServer.com;
root /var/www/html/epicProject/public;
location / {
try_files $uri /index.php$is_args$args; # This should route towards index.php
}
location ~ index\.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param APPLICATION_ENV "production";
include fastcgi_params;
fastcgi_read_timeout 300;
# This should interpret index.php and do stuff
}
location ~ \.php$ {
deny all; # This should deny any other php file directly accessed
}
}
I have 2 questions regarding this config:
Is there any way for someone to still execute a php file that is not matched to a symfony route (basically... did I miss anything?)? The case I'm trying to mitigate is "ok, someone somehow managed to upload a php-shell (I took different measures against that, another topic); he should not be able to execute it".
Is it vulnerable to CVE-2019-11043? At first glance it doesn't seem to be but I'm not sure (I did upgrade php to 7.3.11 so should not matter anyway but just for my peace of mind, even on 7.3.9, is this vulnerable?)
0 Answers