Is it possible to protect plesk panel 11.5.30 GUI with a basic auth protection?
11.5.30 use as internal web server nginx. I founded this file:
/etc/nginx/plesk.conf.d/server.conf
but its not allowed to edit:
ATTENTION!
DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED.
Have here anyone a simple example to add basic auth to plesk GUI?
This is the correct way (original posted by SergeyUgdyzhekov)
# Create /etc/sw-cp-server/conf.d/protect-plesk.inc with content:
location / {
auth_basic "Restricted";
auth_basic_user_file /etc/sw-cp-server/conf.d/passwd;
}
# Generate passwd file
htpasswd -c /etc/sw-cp-server/conf.d/passwd admin
# Set correct permissions:
chown sw-cp-server:psaadm /etc/sw-cp-server/conf.d/passwd
chmod 640 /etc/sw-cp-server/conf.d/passwd
# Restart panel web server
/etc/init.d/sw-cp-server restart
Plesk panel server's config stored in /etc/sw-cp-server/conf.d/plesk.conf
This config /etc/nginx/plesk.conf.d/server.conf it's a config of public web server on port 80.
Related
I am looking at options to add client-side certificate authentication with a fingerprint whitelist to a local site, and have successfully configured nginx to operate in the intended manner. My configuration is as follows:
# Client Certificate Whitelisting
map $ssl_client_fingerprint $reject {
default 1;
<ALLOWED_FINGERPRINT_1> 0;
<ALLOWED_FINGERPRINT_2> 0;
...
<ALLOWED_FINGERPRINT_N> 0;
}
server {
...
ssl_client_certificate /etc/pki/tls/certs/Private-CA-bundle.pem;
ssl_verify_client on;
...
if ($reject) { return 403; }
...
}
However, I would like to store the fingerprint list in a separate text file, rather than manipulating the nginx configuration file directly each time. Is this possible?
As a bonus, it would be great if I could modify the contents of the text file and have them take effect without reloading nginx. It is acceptable for removals to still require a service restart or other manual session teardown procedure.
---- EDIT ----
Based on the accepted answer, I was able to get this working.
The updated configuration file is:
# Client Certificate Whitelisting
map $ssl_client_fingerprint $reject {
default 1;
include /etc/nginx/cert-whitelist;
}
I was able to add a new certificate and apply the changes without a full service restart.
### Attempt connection with client certificate; returns 403 Forbidden
[root]# cat /run/nginx.pid
5606
[root]# echo "${FINGERPRINT} 0;" >> /etc/nginx/cert-whitelist
[root]# kill -1 $(cat /run/nginx.pid)
[root]# cat /run/nginx.pid
5606
### Attempt connection with client certificate; success
The map directive has the ability to source a correctly formatted file. See this document for details.
You can use SIGHUP to re-read the configuration file without restarting Nginx. See this document for details.
I'm currently running a number of servers, each running NGINX used as reverse proxies to other websites. However, if I need to change a backend IP address or change other variables within NGINX, I need to manually SSH into the server and change the configurations OR log onto NGINX Proxy Manager.
What I'm looking to do is create a central website that will enable me to edit NGINX variables such as 'proxy_pass' and send the updated value to the selected remote server, updating the NGINX config and reloading the service.
Is there any current way to do this and how could I implement that? What comes to mind is some kind of CURL request to the remote server, and then I'm not sure how I'd automatically rewrite the correct portion of NGINX config etc.
Any help would be appreciated!
If you have root access on those servers, all you need is a service or a script that will fill the new values. The simplest way I see fit is to do it with a bash script and a template for the config file.
Template config file: /home/user/nginx_config/nginx.config.sample:
-- your generic config settings
proxy_pass
location /your/location {
proxy_pass {{proxy_pass}};
}
-- rest of standard file
The bash script for filling the template: /home/user/nginx_config/generator.sh
new_ip=$1
template_path="/home/user/nginx_config/nginx.config.sample"
config_path="/etc/nginx/nginx.conf"
if [[ -z $1 ]]
then echo "Missing IP param"; exit;
fi
cp "$config_path" "${config_path}.bak"
sed "s/{{proxy_pass}}/$new_ip/g" "$template_path" > "$config_path"
echo "Done! Updated $config_path file to $1:"
cat "$config_path"
Then, all you need to do is to make a local script to connect using ssh and run the generator script (with 1.2.3.4 as your new IP address)
sshpass -p password ssh -oStrictHostKeyChecking=no -oCheckHostIP=no user#your_server "bash /home/user/nginx_config/generator.sh 1.2.3.4"
On my site, registered users, after logging in, have the possibility to download files with the curl command, i.e.
curl -O https://example.com /assets/file/test.txt
I would like to somehow avoid that the user not logged in or deleted still has the possibility to download the file by running the command again or by going directly to the address from the browser.
I use Nginx as web server.
Is it possible to block access to the user that no longer exists or is no longer logged in?
I had thought about the possibility of doing something like this:
curl -u {{user.id}}:{{unique_value}} https://example.com/assets/file/test.txt
or
curl -O https://example.com/assets/file/test.txt?param={{unique_value}}
But I don't know how to verify the existence of the user, and if it is possible to do so, with nginx or some other tool.
I tried using cookie control with Nginx, but as far as I know it is easy to circumvent.
yeah you can use http basic auth to restrict file access to authorized people, per the documentation at https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/
touch /etc/nginx/users.htpasswd;
htpasswd /etc/nginx/users.htpasswd user1 'password';
followed by
server {
listen 80;
listen [::]:80
location /assets{
root /wherever/assets/..;
auth_basic "assets";
auth_basic_user_file /etc/nginx/users.htpasswd;
}
}
now only curl -u user1:password1 can download files in /assets/
I'm successfully able to run a flask app on my IP:5000 path. A simple Hello World program that shows the output on my browser.
Now, what I would like to do is to configure NGINX with a proxy so that if I access only IP which apparently runs on a default port 80, it should navigate to port 5000 and show output of my application.
In other words...
This is working : IP:5000 -> Output = Hello world
This isn't working: IP -> This site can’t be reached
The server settings that I want to add would be something like this.
server {
listen 80;
server_name MY_IP;
location / {
proxy_pass http://127.0.0.1:5000;
}
}
However, I'm not sure where to add this? Should it be inside http block inside /etc/nginx/nginx.conf?
Updates: Based on the answers given below, I've managed to do the following.
I did restart nginx after this. However, I'm still facing the same issue. App works on IP:5000 but does not work on IP
The configuration you have mentioned should be in a separate file, assume example.com.conf under /etc/nginx/conf.d. You can put all the configuration in /etc/nginx/nginx.conf and it'll work, it's just that for readability we create separate configuration files which would be auto included when you add it inside conf.d.
Ok, the problem is fixed. As #senaps and #Mukanahallipatna had mentioned, I created the new configuration file under conf.d.
However, the most imp step that I was missing was this part mentioned in the below link.
It is recommended that you enable the most restrictive profile that will still allow the traffic you've configured. Since we haven't configured SSL for our server yet, in this guide, we will only need to allow traffic on port 80.
Reference Link
sudo ufw allow 'Nginx HTTP'
Now, everything is working fine.
Put the working blocks in a file with any_name.conf inside the folder named /etc/nginx/conf.d and it will be loaded automatically.
You will need to restart your nginx.
update:
What are you using to serve flask? if you are using uwsgi, then you should use configurations like this:
include uwsgi_params;
uwsgi_pass unix:path_to_your.sock;
Other options for uwsgi_pass are:
uwsgi_pass localhost:9000; #normal
uwsgi_pass uwsgi://localhost:9000;
uwsgi_pass suwsgi://[2001:db8::1]:9090; #uwsgi over ssl
If you are using gunicorn to serve your flask app, then your current configs should be fine, check if your app is running and if you can get your index page or not using 5000 port, then check for other problems. your configs looks good, maybe it's a problem on flask not being run?
I need to deploy more than one bundled meteor apps on the same server, using nginx-passenger. I followed the phusion passenger guide and all works smoothly with one app. No documentation find on how to configure nxinx-passenger (I mean the appX.mydomain.conf in /etc/nginx/sites-availabe) to run more than one app. I need to publish the apps in the form app1.mydomain.com, app2.mydomain.com and so on. Someone can help me to understand how to do?
Thanks in advance!
Edit: my original config file
server {
listen 80;
server_name app1.mydomain.com;
# Tell Nginx and Passenger where your app's 'public' directory is
root /path/toApp1/bundle/public;
# Turn on Passenger
passenger_enabled on;
# Tell Passenger that your app is a Meteor app
passenger_app_type node;
passenger_startup_file main.js;
# Tell your app where MongoDB is
passenger_env_var MONGO_URL mongodb://localhost:27017/myapp1db;
# Tell your app what its root URL is
passenger_env_var ROOT_URL app1.mydomain.com;
}
Edit: my proposed config file for the second meteor instance
server {
listen 80;
server_name app2.mydomain.com;
# Tell Nginx and Passenger where your app's 'public' directory is
root /path/toApp2/bundle/public;
# Turn on Passenger
passenger_enabled on;
# Tell Passenger that your app is a Meteor app
passenger_app_type node;
passenger_startup_file main.js;
# Tell your app where MongoDB is
passenger_env_var MONGO_URL mongodb://localhost:27017/myapp2db;
# Tell your app what its root URL is
passenger_env_var ROOT_URL app2.mydomain.com;
}
You will need a file for each Meteor instance in
/etc/nginx/sites-available
similar to the one you have already.
You will need to sym-link these files to
/etc/nginx/sites-enabled
The name of the files isn't important except for your convenience, let's say you have domain app1.mydomain.com, so the file is called app1
Save this as
/etc/nginx/sites-available/app1
and issue these commands:
cd /etc/nginx/sites-enabled
ln -s ../sites-available/app1
You will just need to sort out which ports each server will run on, and set up the contents of the nginx files (which I assume you did already for the first one)