I have a sub domain routed through cloudflare. They don't cover websockets unless it enterprise or maybe business depending on traffic.
So now when users visit the external site, it connects to my sub domain via a websocket with the url of my site being passed in their url.
e.g thridpartysite.com?ws=my.subdomain.com
But my IP is revealed and I am worried about DDoS.
I am using nginx and ubuntu 14.04. Is there anything I can do to mask the IP?
Here is my current nginx config
# Config
server {
listen 80;
listen [::]:80;
server_name my.subdomain.com www.my.subdomain.com;
location / {
proxy_pass http://MySubdomainIP:443;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
So it takes the app on 443 and proxies to 80 so I can route that through cloudflare but no websocket support means I need to reveal my IP which leaves me open to DDoS attacks.
Is there anything I can do at this point?
All plan levels support websoxkets.
https://support.cloudflare.com/hc/en-us/articles/200169466-Can-I-use-CloudFlare-with-WebSockets-
Related
I want to be able to access my web app by by both ip and domain.with my current config i can only access either one depending with what i put on the server name property server_name: ip|domain
here is how my config is like
server {
server_name ip-address here;
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_http_version 1.1;
proxy_pass http://localhost:3000;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
Like #Amin commented, you could just add your IP as a "server name" like:
server_name 171.233.45.4 www.mydomain.com;
However this is discouraged as the main point of a server name directive is to have multiple domains or subdomains hosted at the same IP address. I.e. you want to serve two apps at 171.233.45.4 and NGINX can distinguish them because one has server_name my_app.com; and the other server_name potatos.com;.
If you want access by IP then that indicates you are running only one service on that address+port combination, meaning you do not need to specify a server name and instead could just configure DNS in the hosts file or in your router.
The simplest config would be:
server {
listen 80;
...
}
Where 80 is the service port number. Then, you would be able to access the server by IP and hostname if you configure your hosts files or some sort of DNS service to point your hostname to the server's IP.
I have a small network with a webserver and an OpenVPN Access Server (with own webinterface). I have only 1 public ip and want to be able to point subdomains to websites on the webserver (e.g. website1.domain.com, website2.domain.com) and point the subdomain vpn.domain.com to the web interface of the OpenVPN access server.
After some Google actions i think the way to go is setup a proxy server. NGINX seems to be able to do this with the "proxy_pass" function. I got it working for HTTP backend URL's (websites) but it does not work for the OpenVPN Access Server web interface as it forces to use HTTPS. I'm fine with HTTPS and prefer to use it also for the websites hosted on the webserver. By default a self signed cert. is installed and i want to use also self signed cert. for the other websites.
How can i "accept" self signed cert. for the backend servers? I found that i need to generate a cert. and define it in the NGINX reverse proxy config but i do not understand how this works as for example my OpenVPN server already has an SSL certificate installed. I'm able to visit the OpenVPN web interface via https://direct.ip.address.here/admin but got an "This site cannot deliver an secure connection" page when i try to access the web interface via Chrome.
My NGINX reverse proxy config:
server {
listen 443;
server_name vpn.domain.com;
ssl_verify_client off;
location / {
# app1 reverse proxy follow
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass https://10.128.20.5:443;
proxy_ssl_verify off;
}
access_log /var/log/nginx/access_log.log;
error_log /var/log/nginx/access_log.log;
}
server {
listen 80;
server_name website1.domain.com;
location / {
# app1 reverse proxy follow
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://10.128.11.20:80;
}
access_log /var/log/nginx/access_log.log;
error_log /var/log/nginx/access_log.log;
}
A nearby thought...
Maybe NGINX is not the right tool for this at all (now or on long term)? Lets assume i can fix the cert. issue i currently have and we need more backend web servers to handle the traffic, is it possible to scale the NGINX proxy as well? like a cluster or load balancer or something? Should i look for a completely different tool?
I have two instances of nginx server running one with corporate ip and second with internal ip.I want a link from external nginx get redirected to internal nginx server and use external nginx as gateway. Also need to make sure that internal nginx running on dynamic IP
Tried to use variable for dynamic IP as shown in code snippet
location /route/(?<section>.+){
proxy_bind 172.31.*.*;
proxy_pass http://$section/single-table-view;
proxy_set_header Host $http_host;
}
You need to configure nginx as mentioned below:
If you want to redirect your External nginx to Internal nginx you should configure your External server like:
server {
listen 80;
listen [::]:80;
server_name domain_name;
location / {
proxy_pass http://InternalNginxIpAddress:PortYouWant;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
Now each request from External nginx will be forwarded to Internal nginx, where your Internal nginx server is set as
proxy_pass http://localhost:PortYouWant;
I heard that MEAN stack would be beneficial if it has nginx at front for some reasons and am following instructions from some people already done it. I installed MEAN stack via Bitnami and AWS and am trying to setting nginx configuration. I am modifying file /usr/share/nginx/default which contains this code.
server {
listen 80;
server_name example.com www.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
My question is that should I have to put my address instead of 127.0.0.1?
and should I have to keep 3000 and change my AWS port setting? Thanks in advance!
127.0.0.1 is a loopback ip address of the server, so the answer is no, you have to keep that ip address.
Port 3000 is an application port,that mean your application is listening on that port. Regularly, you can check port number that is in app.js or server.js files. You can change that port belong to port that you have set your application's port is listening. Sorry for my poor English.
I have a node app that uses websockets which is working on local host but not in production. In production, the messages being posted aren't appearing in the client. Since it's using socket.io, I'm assuming this is a problem with the ports. In production, I'm using nginx with this as the following config. Nginx is listening on port 80 but I have the port for the application at localhost:3000. Every nginx config I've ever seen has it listening on port 80, and I've heard problems will result if I set localhost below 1000, yet I believe the socket.io is not working because these ports are not the same. Can you suggest how to fix this problem?
/etc/nginx/conf.d/example.com.conf
server {
listen 80;
server_name mydomain.com;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}