I have following nginx configurations
if ($host != mydomain.com) {
return 403;
}
When I hit the url http://127.0.0.1/test/test2/index.php (from POSTMAN) I get 403. Fine. But adding a Host -> mydomain.com in Headers I get 200.
When I added add_header Host "$host"; in nginx configurations I noticed in response that nginx has mydomain.com in its host variable. I know intentionally mentioning Host header in http request overrides 127.0.0.1 according to nginx documentation.
But in this way an attacker can send requests direct to web server by bypassing Cloudflare WAF. so what's the solution to block such requests from nginx?
I have tried following solutions but didn't work for me.
https://www.digitalocean.com/community/questions/how-to-block-access-using-the-server-ip-in-nginx
https://blog.knoldus.com/nginx-disable-direct-access-via-http-and-https-to-a-website-using-ip/
When I hit the url http://127.0.0.1/test/test2/index.php (from POSTMAN) I get 403. Fine. But adding a Host -> mydomain.com in Headers I get 200.
If I understand correctly, you seem to think that "adding a Host" header in your request is somehow a bypass. And it's not ... it's how hostnames work in HTTP.
A server doesn't magically know that you typed http://domain.tld/test/ in your browser address bar. Your browser makes a DNS lookup for domain.tld and establishes a TCP connection with the resolved IP address; it then sends headers, which is where the server gets the information from:
GET /test/ HTTP/1.1
Host: domain.tld
That's the only way the server knows you requested http://domain.tld/test/.
add this block:
server {
listen 80 default_server;
server_name "";
return 444;
}
OR
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 444;
}
The “default_server” parameter cannot be present in any other server block. NGINX Block direct IP access.
Related
I'm trying to enforce the SSL protocol in a Jelastic Enviroment.
My setup is:
one node, with a Nginx Load balancer (+ public ip + custom ssl certificate) and a NodeJS application server.
The SSL setup is working, but i want to enforce the use of HTTPS no HTTP (a redirect).
I've tried to modify the nginx.conf but no success.
Any ideas how should I do that?
Create the config file /etc/nginx/conf.d/nginx_force_https.conf and add the lines below:
server {
listen 80;
server_name _;
return 301 https://$host$request_uri;
}
It will redirect all configured sites to https.
If you want only exact site example.com:
server {
listen 80;
server_name example.com;
return 301 https://example.com$request_uri;
}
Make sure that you have these includes enabled in /etc/nginx/nginx.conf
include /etc/nginx/nginx-jelastic.conf;
in /etc/nginx/nginx-jelastic.conf:
include /etc/nginx/conf.d/*.conf;
Check for errors in the configuration:
sudo service nginx configtest
Reload configuration (this would be enough to make changes "work"):
sudo service nginx reload
Check if all works as expected. Restart the whole webserver (if needed):
sudo service nginx restart
The detailed answer can be found in this post Force www. and https in nginx.conf (SSL)
Consider the following nginx config file:
server {
listen 443;
ssl on;
ssl_certificate /etc/tls/cert.pem;
ssl_certificate_key /etc/tls/key.pem;
location / {
proxy_pass http://api.default.svc.cluster.local;
}
}
All incoming TCP requests on 443 should redirect to my server running on api.default.svc.cluster.local:80 (which is a node REST-Api btw). This works fine, I can curl https://<nginx-IP>/ nginx and get a correct response, as expected.
Now, I'd like to change the location from / to /api, so I can fire a curl https://<nginx-IP>/api in order to get the same response as before.
1. Attempt
So I change the location line in the config to:
location /api {
Unfortunately this won't work, instead I get an error Cannot GET /api which is a node error, so obviously it gets routed to the api but something's still smelly.
2. Attempt
It seems as the trailing slash in an URI is required so I added it to the location:
location /api/ {
Now something changed. I won't get the same error as before, instead I get an "301 moved permanently". How can I fix my nginx config file?
Additional information regarding the environment
I'm using a kubernetes deployment that deploys the nginx reverse proxy incl. the config introduced. I then expose nginx using a kubernetes service. Also, I tried using kubernetes ingress to deal with this situation, using the same routes, however, the ingress service would respond with a default backend - 404 message.
As mentioned in the question, trailing slashes in URIs are important. I fixed this in the location, however, I didn't add it to the URI I pass using proxy_pass.
As for the nginx proxy I got it to work using the following config:
server {
listen 443;
ssl on;
ssl_certificate /etc/tls/cert.pem;
ssl_certificate_key /etc/tls/key.pem;
location /api/ {
proxy_pass http://api.default.svc.cluster.local/;
}
}
Concerning the ingress solution, I was not able to get it to work by adding the missing trailing slash to the path. The service is specified due its name and therefore no trailing slash can be added (i.e. it would result in an error).
How to pass parameters in nginx url. When I hit http://127.0.0.1:1000/samp/test1/result?num1=10&num2=30, it should redirect me to http://127.0.0.1:80/samp/test1/result?num1=10&num2=30. Is this possible? Below is my nginx config file.
upstream apache {
server 127.0.0.1:1000;
}
server {
listen 80;
server_name 127.0.0.1;
location / {
#root html;
#index index.html index.htm;
#return 503;
proxy_pass http://apache;
}
}
I think what you want to do is possibe, but you'd have to make that configuration change on the apache end of things.
If 'apache' handles a request coming into port 1000 directly, it will see a URI like this:
http://127.0.0.1:1000/samp/test1/result?num1=10&num2=30
However, if it is sent through nginx, it will look more like this:
http://apache/samp/test1/result?num1=10&num2=30
So, you could check the incoming URL for :1000 and then rewrite the request on the apache side to go to port 80 instead ( which is the default, so you don't need :80 - you can just leave the port unspecified entirely.
If the backend really is apache, you can use a rewrite rule there to handle the rewriting.
However, if you're not already on port 80, you're not connecting to nginx - so nginx can't rewrite this for you.
Hope it makes sense!
Here's how I tested:
Apache side I used a quick sinatra (ruby) app to print out the full URI of the request it sees:
require 'sinatra'
set :bind, "0.0.0.0"
set :port, 1025
get "/*" do
"<p>Hello from \"apache\"! You've just requested:
<code>#{request.url}</code></p>
"
end
Then nginx is configured thusly:
upstream apache {
server 192.168.70.1:1025;
}
server {
server_name localhost;
location / {
proxy_pass http://apache;
}
}
Note I used port 1025, because port 1000 is a privileged port.
I used curl to generate the requests to test:
$ curl 'http://192.168.70.1:1025/samp/test1/result?num1=10&num2=30'
<p>Hello from "apache"! You've just requested:
<code>http://192.168.70.1:1025/samp/test1/result?num1=10&num2=30</code></p>
$curl 'http://127.0.0.1:80/samp/test1/result?num1=10&num2=30'
<p>Hello from "apache"! You've just requested:
<code>http://apache/samp/test1/result?num1=10&num2=30</code></p>
If I wanted to do the redirect you're describing, I could match with a regular expression of IPV4 address and port and redirect as such:
get "/*" do
if request.url =~ %r|^http://([0-9]{1,3}\.){3}[0-9]{1,3}:1025/|
redirect "http://localhost:80/#{request.fullpath}"
else
"<p>Hello from \"apache\"! Tou've just requested:
<code>#{request.url}</code></p>
"
end
end
Now I tell curl to follow redirects (-L) and we see it redirect me over to the "correct" route.
$ curl -L 'http://192.168.70.1:1025/samp/test1/result?num1=10&num2=30'
<p>Hello from "apache"! Tou've just requested:
<code>http://apache/samp/test1/result?num1=10&num2=30</code></p>
I know it's not the language you're using, but I hope it iwll help you get started.
I have below nginx conf file
upstream entry {
server 127.0.0.1:3001;
}
server {
listen 80;
server_name 127.0.0.1;
location / {
proxy_pass http://entry/;
}
Whenever I hit http://127.0.0.1:80/, it will be redirected to 127.0.0.1:3001. In the same way if I hit http://127.0.0.1:3001/ it should be redirected to nginx server.
Any help on this will be really helpful.
If I am getting it correct you want http://127.0.0.1:3001/ (node http server) to redirect to http://127.0.0.1:80/ (nginx), which in turn will redirect to http://127.0.0.1:3001/ (node http server). Why on earth you want to do that? You can use node proxy module to do that if you want to fall inside a infinite for loop.
But generally, sane people will will use nginx as reverse proxy (80->3001). And block port 3001 for any outside communication through firewall.
There are several questions on SO about nginx subdomain configuration but didn't find one that exactly the same as mine.
Say I got a virtual host some.example.com from higher-level net admin example.com at our organization. I want to use some.example.com as my primary site and use foo.some.example.com and bar.some.example.com for auxiliary usage (proxy, etc). I tried this simple configuration and put it under sites-enabled but didn't work:
server {
listen 80;
server_name some.example.com;
root /home/me/public_html/some;
index index.html index.htm;
}
server {
listen 80;
server_name foo.some.example.com;
root /home/me/public_html/foo;
index index.html index.htm;
}
server {
listen 80;
server_name bar.some.example.com;
root /home/me/public_html/bar;
index index.html index.htm;
}
In this setting some.example.com works fine, but for the other two browser return that could not find foo.some.example.com. I'm running it on a ubuntu server.
Is there something wrong with this configuration? Or is it something I should talk to higher level net admin (make foo.some.example.com and bar.some.example.com to be registered)?
Sub-domain configuration starts with an entry in the DNS server of the parent domain and the lookup resolves the sub-domain to an IP address of the web server. The web server in turn delegates the requests based on its configuration for the sub-domain.
If you don't have a DNS setup in your sub-domain, then the admin at example.com needs to set up a CNAME alias. The alias points the subdomain to the same web server, which hosts the website for the parent domain. The canonical names (CNAMES) are added for each of the subdomains. Once the subdomain is resolved to the IP address of the web server, the web server can route the request to a different website.
CNAME is just a way to get the web traffic to your IP address. The
request will still include the original name in the Host: header.