I have a windows server 2012 VPS running a web app behind Cloudflare. The app needs to initiate outbound connections based on user actions (eg upload image from URL). The problem is that this 'leaks' my server's IP address and increases risk of DDOS attacks.
So I would like to prevent my server's IP from being discovered by setting up a forward proxy. So far my research has shown that this is no simple task, and would involve setting up another VPS to act as a proxy.
Does this extra forward proxy VPS have to be running windows ? Are their any paid services that could act as a forward proxy for my server (like cloudflare's reverse proxy system)?
Also, it seems that the suggested IIS forward proxy plugin, Application Request Routing, does not work for HTTPS.
Is there a solution for both types of outgoing (HTTPS + HTTP) requests?
I'm really lost here, so any help or suggestions would be appreciated.
You are correct in needing a "Forward Proxy". A good analogy for this is the proxy settings your browser has for outbound requests. In your case, the web application behaves like a desktop browser and can be configured to make the resource request through a proxy.
Often you can control this for individual requests at the application layer. An example of doing so with C#: C# Connecting Through Proxy
As far as the actual proxy server: No, it does not need to run Windows or IIS. Yes, you can use a proxy service. The vast majority of proxy services are targeted towards consumers and are used for personal privacy or to get around network restrictions. As such, I have no direct recommendations.
Cloudflare actually has recommendations regarding this: https://blog.cloudflare.com/ddos-prevention-protecting-the-origin/.
Features like "upload from URL" that allow the user to upload a photo from a given URL should be configured so that the server doing the download is not the website origin server.
This may be a more comfortable risk mitigator, as it wouldn't depend on a third party proxy service. A request for upload could be handled as a web service call to a dedicated "file downloader" server. Keep in mind that if you have a queued process for another server to do the work, and that server is hosted in the same infrastructure, both might be impacted by a DDoS, depending on the type of DDoS.
Your question implies that you may be comfortable using a non-windows server. Many softwares exist that can operate as a proxy(most web servers), but suffer from the same problem as ARR - lack of support for the HTTP "CONNECT" verb, which is used by modern browsers to start an HTTPS connection before issuing a "GET". SQUID is very popular, open source, and supports everything to connect to.. anything. It's not trivial to set up. Apache also has support for this in "mod_proxy_connect", but I have no experience in that and the online documentation isn't very robust. It's Apache, though, so it may be worth the extra investigation.
Related
I was going through Uber Engineering website where I came across this paragraph and I it confused me a lot, if anyone can make it clear for me then I would be thankful to him/her:
The Edge The frontline API for our mobile apps consists of over 600
stateless endpoints that join together multiple services. It routes
incoming requests from our mobile clients to other APIs or services.
It’s all written in Node.js, except at the edge, where our NGINX front
end does SSL termination and some authentication. The NGINX front end
also proxies to our frontline API through an HAProxy load balancer.
This is the link.
NGINX is already a reverse proxy + load balancer, then from where HAProxy load balancer came in the picture and where exactly it fits in the picture? What is "the edge" he talked about? Either the guy who wrote his he wrote confused words or I dont know English.
Please help.
It seems like they're using HAProxy strictly as a load balancer, and using NGINX strictly to terminate SSL and for authentication. It isn't necessary in most cases to use HAProxy along with NGINX, as you mentioned, NGINX has load-balancing capabilities, but being Uber, they probably ran into some unique problems that required the use of both. According to the information I've read, such as http://www.loadbalancer.org/blog/nginx-vs-haproxy/ and https://thehftguy.com/2016/10/03/haproxy-vs-nginx-why-you-should-never-use-nginx-for-load-balancing/, NGINX works extremely well as a web server, including the use case where it is serving as a reverse proxy for a node application, but its load-balancing capabilities are basic and not nearly as performant as HAProxy. Additionally, HAProxy exposes many more metrics for monitoring, and has more advanced routing capabilities.
Load balancing is not the core feature of NGINX. In the context of a node.js application, usually what you would see NGINX used for is to serve as a reverse proxy, meaning that NGINX is the web server, and http requests come through it. Then, based on the hostname and other rules, it forwards on the HTTP request to whatever port your node.js application is running on. As part of this flow, often NGINX will handle SSL termination, so that this computationally-intensive task is not being handled by node.js. Additionally, NGINX is often used to serve static assets for node.js apps, as it is more efficient, especially when compressing assets.
I have an API server running behind an nginx reverse proxy. It is important to have all requests to my API server be secured via TLS since it handles sensitive data.
I've setup nginx to work with TLS (LetsEncrypt) so that seems to be okay. However, requests from nginx to my API server are still insecure http requests (this is all happening across docker containers, by the way).
Is it a best practice to also setup https between the reverse proxy and the API server? If so, how would I go about doing that without over-engineering it?
It all comes down to how secure or paranoid you'd like your implementation to be. It may also depend on the type of data you're playing with. For instance: I'd definitely do this for credit card numbers or other sensitive information.
As the comments have already stated, you would typically terminate SSL connections at the front facing webserver, assuming the API backend is also inside your LAN, which you trust and control. If you want to go that extra mile, you could also set up SSL on the API backend. Details of how to do that depend on the software you're using on your backend.
If you do decide to implement SSL on the API backend, the setup would be similar to what you did to setup Nginx with SSL on the frontend, with the main difference being you don't need to use a public certificate on the backend. It can be self-signed, since no one else besides your web server will be talking to it. Then it's just a matter of fixing all the URIs in your code to use HTTPS.
so I have 0% experience with web programming, and the project I am working on doesn't have anything to do with it, but I hit a small roadblock and need to solve a small port problem.
So we want to build a cluster of GPU machines on Azure for some Deep Learning calculations, and want to install some applications on them and let our scientists use the app' GUIs to launch and monitor their jobs. The problem is that an app A for example runs on port 5050, but our firewall doesn't let us communicate to unusual ports. The problem is easy to fix from the Azure side, but our IT team won't let us modify our security policies.
That's why I need to find a hacky and fast solution to overcome this, I don't want to spend my whole internship doing something complicated for it, just something that does the job.
What I thought about was to have some kind of server running on the machines (let's say Machine A has public IP address ipbA and private IP ipvA) that when we type "http://ipba/app1" on our browser, the server on A will fetch the page "http://ipva:5050" (or "----://ipba/app2" -> "----://ipva:5051") and display it, but does this work if the page needs to be interactive because we would like to launch jobs?
I have no clue how to do this, if you could please just tell me what I should look into, google and read about, or if there is an easier way to handle it, (maybe some VPN stuff, which I don't prefer since we're moving towards a hybrid cloud architecture and I don't think we would want to VPN into all the different cloud platforms) that would be awesome :)
Two common solutions for your problem:
Set-up a reverse proxy on a standard port (such as 80 or 443 if you want some SSL certificates headaches).
All your domain names will point to the reverse proxy (single IP) but the reverse proxy will forward the traffic transparently to the real servers on their special ports.
https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html
https://www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension
For the technical details, in short: you keep in file(s) the configuration for each domain or subdomain and where they should be forwarded.
Chain of events:
User types http://interface-1.company.com
Browser resolves interface-1.company.com (DNS: IP Reverse Proxy)
Browser connects on reverse proxy (port 80)
Reverse proxy reads configuration which says where to forward
Proxy forwards request to realserver.company.com:5050
Realserver relays response to reverse proxy
reverse proxy relays response to browser
I think that is what you are trying to achieve.
Set-up a VPN service which will be connectible through the proxy of your company and provide VPN clients to the end-users. OpenVPN clients can use an HTTPS proxy connection (your company proxy) to establish connexion to a remote VPN.
Once connected on the VPN, everyone uses the VPN's IP address + firewall policy, and are therefore no more restricted by the company's firewalling policy. Any kind of traffic can also be forwarded. This is harder to set up and your security team might not accept it. However, it's a fully functional solution and it can also offer additional security features if implemented properly.
I do not recommend going this way for all the paperwork that would involve.
I have a front end web server running over HTTPS - this is public facing - i.e. port is open.
I also have a backend API server that my webserver makes API requests to - this is public facing and requires authentication - port is open.
These 2 servers run over HTTPS.
Behind the API server, there are lots of other servers. The API server reverse proxies to these servers. Ports for these other servers are not open to incoming traffic. They can only be talked to via the API server.
My Question ... Do the "lots of other servers" need to run over HTTPS or, given that they cannot be accessed externally, can they run over HTTP safely instead?
I thought this would be a common question but I could not find an answer to it. Thanks. If this is a dupe please point me to the right answer.
TL;DR you should encrypt the traffic unless it's on the same host.
You can't trust your network. Malwares in your own network can intercept/modify http requests.
It's not theoretical attacks, but real life example:
Routers (probably hacked) inside the network of some websites injecting ads: https://www.blackhat.com/docs/us-16/materials/us-16-Nakibly-TCP-Injection-Attacks-in-the-Wild-A-Large-Scale-Study-wp.pdf
Indian network sniffing between cloudfare and back-end: https://medium.com/#karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know-it-90935f7f6d98#.hymc3785e
The now famous "SSl Added and removed here :-)" from the NSA
The question is how much do you trust the connection between the public IP and the backend server?
If it is not your data center, at least any privileged employee of the ISP could see/change the data. I guess that's not something your customers would like to hear.
If it is your data center, meaning you are a kind of ISP still everybody who has physical access to the data center can potentially sniff the clear text traffic. Or in general, anybody who has access to the wire can see the traffic, it is much harder to implement a strict access control in your company.
I'm just setting up an SSL area of a website, and was just wondering... is it as simple as adding HTTPS on the url?
(this is presuming I have a valid certificate of the hosting company?)
Or is there something more to it?
Thanks.
You have to setup the server to allow ssl connections. That includes generating a signed server request. You send this CSR to the cert authority (Verisign etc), and they send you a cert to install on the server. If you are behind a firewall you need to open port 443.
If you don't control the server i.e. shared hosting, there is probably a page in your control panel to do it all for you using a GUI.
When you replace http: in a URL with https: you are asking your web browser to do two things:
To attempt an encrypted (SSL) connection
To change which port to use on the remote server if none is specified in the URL
Most web browsers use port 80 for unencrypted traffic and port 443 for encrypted traffic by default. So, the first thing you need is a web server that is listening on port 443. If you are using a hosting company, this is probably already the case or becomes the case when you configure SSL.
You do not have to use port 443 but that is where browsers will be looking when users do not specify a port. You could also force everybody that connects at port 80 to use SSL as well though with the right configuration. That means that ALL traffic to your site would be encrypted.
To get the encryption up and running you generally need three things: a certificate, an encryption key, and a server request (CSR).
How you configure these is extremely dependent on how you are hosting the web server. Most hosting companies have 'control panels' that you log into for configuration. Common ones are Plex and CPanel. If either of those ring a bell you can post more information to get a better answer.
If you are managing the server yourself the big question is whether you are hosting on Windows or Linux. If it is windows, you are most likely going to want to configure IIS (Internet Information Server) while if it is on Linux you are probably going to configure Apache.
If you are using IIS, this link might help:
http://www.petri.co.il/configure_ssl_on_your_website_with_iis.htm
If it is Apache, Byron gave a good link above:
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html
You can use other web servers. For example, I use nginx:
http://rubypond.com/blog/setting-up-nginx-ssl-and-virtual-hosts
So, I guess the real step one is finding out more about your server. :-)
Once your web server has the SSL cert installed, it is as easy as using HTTPS on the URLs. There are some considerations to be aware of:
Port 443 must be open between the user and web server. (obvious)
Browser caching will be reduced to in-memory session cache and not stored on disk. Also, caching proxies in between will not be able to cache anything, since everything is encrypted. This means an increase in load times and bandwidth requirements of the web server.
When using HTTPS to receive sensitive data, be sure to disallow its use over HTTP. e.g. If you have a page that accepts credit card numbers in a POST, the app should fail validation if it was not done over HTTPS. This can be done in your code or in web server configuration. This prevents a bug or malware from systematically sending sensitive data in the clear without the user knowing.