I have a server (that I don't control, but on my network) that uses unsecured web sockets to communicate. Rather than allow communication directly with that server from outside the network, I'm wanting to set up a secure proxy that uses secured web sockets to receive the requests from outside the network, and then forward those on to the real server within the network. That way, the unsecure traffic never leaves the network and any communication with outside the network is done via the secured proxy.
What would be the best way of achieving this?
If you're talking about having the internal communication still over regular HTTP, but only have communication to the external world over HTTPS, then this is a common practice. HAProxy supports this, and the general term is called "Terminating SSL" or "Terminating TLS".
You can read more about it here: TLS termination proxy
Related
I have a server that has a web server on it. I have setup wireguard vpn between me and server.
Do I need to serve my web server with https for security or wireguard is enough?
You should be fine as long as your web server is listening on the Wireguard interface only (i.e. it is bound to the IP address of the Wireguard interface) so that it is not reachable from outside the VPN. You do not technically need to wrap everything in another encryption layer such as HTTPS, as the only way to establish a connection to the web server is through the VPN, which already provides encryption and authentication.
Beware though that VPN + HTTP does not offer exactly the same security features that VPN + HTTPS does, there are some subtleties. For example, in case your private VPN key is leaked, it could be used to perform a Man-In-The-Middle attack on your connection, whereas using VPN + HTTPS a potential attacker would also need to break through HTTPS, which means either getting privileged access to your machine (since a new private key is generated by your browser on each TLS handshake) or a way to forge a valid CA-signed certificate for your web server's domain (generally not possible). Whether or not you care about this additional layer of security is up to you really.
We currently have VM environment setup with an internal network and a DMZ network. Historically we had no open ports between these environments, but needs arose for communication between the internet and services/APIs running on our internal servers.
We decided to use our DMZ network as a proxy/gateway, where we specifically use Kong Gateway, exposing ports 80/443 to the internet, and then proxying/forwarding requests through a different port opened up between the DMZ server and the specific internal server that needs to handle this communication. A random, non-standard, high port is being used for all requests between the DMZ server and our internal network, and we then use a reverse proxy on our internal server to route specific request via hostnames to specific APIs/services on the internal server.
Now, we're in the process of converting our internal environment to a k8s cluster, and I'm interested in knowing if there'd be any "real" difference to security, if we were to forego the DMZ proxy, and exposing ports 80/443 directly from the internet to our internal k8s cluster, and handle all the security/authentication/authorization through the ingress controller on our cluster.
It would simplify our infrastructure a decent bit, to not have this DMZ proxy running.
From my understanding the purpose of the DMZ proxy was that if a breach were to happen in the chain, it would be much harder to further penetrate our internal network, if the breach was only on the DMZ server. But my networking and security knowledge is not good enough to say if this is actually true, and it just provides a false sense of extra security, in which case, we'd have the exact same level of security with exposing those same ports directly on our internal k8s cluster, while simplifying the overall infrastructure.
if there'd be any "real" difference to security, if we were to forego the DMZ proxy, and exposing ports 80/443 directly from the internet to our internal k8s cluster, and handle all the security/authentication/authorization through the ingress controller on our cluster.
It would simplify our infrastructure a decent bit, to not have this DMZ proxy running.
You probably want a "Gateway" outside the cluster, with a static IP-address. The nodes in the cluster are more dynamic, you want to throw away the old and create new when upgrading e.g. the linux kernel.
From my understanding the purpose of the DMZ proxy was that if a breach were to happen in the chain, it would be much harder to further penetrate our internal network, if the breach was only on the DMZ server.
The book Zero Trust Networks is good about this. Things has changed, the older way of using "DMZ" to protect internal networks, called "perimeter security" is now replaced with a "Zero Trust Networking" model. Now every host (or Pod) should be responsible for its security, on Kubernetes, to get this hardened, you can use a "Service Mesh" to implement mutual TLS between all services, see e.g. istio.
I want to use the IP address of the Azure Application Gateway to use for outgoing traffic that comes from internal services and not the ones of the services. Basically I want to use the GW to act on behalf of the services - act as a forward proxy.
Unfortunately, that is not possible at the moment. The Application gateway is designed to work as a reverse proxy and not a forward proxy.
The alternative to which would be to use any of the below:
Azure ELB - If you are not looking for
cookie persistence
WAF capabilites
ssl offloading
ssl strengthening (use certain versions of tls and ciphers)
encrypt application cookie
disable headers (Server, X-Powered-By)
disable clickjacking (x-frame-options: SAMEORIGIN)
block blacklisted user agents
cookie encryption
schedule maintenance redirect to a webpage during a maintenance window
redirect HTTP error 403 to 404
restrict outside access to certain pages
** Most of which you can do over new Application gateway and Azure Firewall
3rd Party load balancers - F5, NetSclaer etc..
Use Ngnix, "best option" Resume complete control over load balancing.
Firewall of your choice with these capabilities
Reference Links:
https://kemptechnologies.com/load-balancing-nginx/microsoft-azure/
https://docs.citrix.com/en-us/netscaler/12/netscaler-cache-redirection-gen-wrapper-10-con/cache-redirection-config/configure-forward-proxy-redirection.html
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-faq
I'm trying to learn about why reverse proxy servers are useful. I just read...
Security and anonymity – By intercepting requests headed for your backend servers, a reverse proxy server protects their identities and acts as an additional defense against security attacks. It also ensures that multiple servers can be accessed from a single record locator or URL regardless of the structure of your local area network.
https://www.nginx.com/resources/glossary/reverse-proxy-server/
Why is it helpful that the identity of your backend servers are hidden? Couldn't one just still attack them through the reverse proxy server like how any normal client visiting the app would access them?
You can fine-tune the access restrictions for every request, apply rate-limiting and load-balancing so a possible attack may not bring down your whole infrastructure. Especially the load-balancing aspect is key. Additionally, the only server visible to the internet is the reverse proxy, so it's not a trivial task to map your entire server structure as it would be if you exposed them all.
A common use-case is setting the reverse proxy up as the SSL gateway so you can communicate via HTTP behind the firewall. Failover for non-responding servers is also possible. Adding additional servers to the setup is trivial this way.
Apart from this, the immediate benefit is a centralized setup that you don't have to replicate for all the servers behind the firewall. Also, a reverse proxy enables you to expose only HTTP/HTTPS port for one external IP address but have multiple services running with local IPs you can route wherever you want.
Please note that this question likely belongs on Server Fault since it's related to network and server infrastructure.
“A reverse proxy can hide the topology and characteristics of your back-end servers by removing the need for direct internet access to them. You can place your reverse proxy in an internet facing DMZ, but hide your web servers inside a non-public subnet.” [ 1 ]
“By intercepting requests headed for your backend servers, a reverse proxy server protects their identities and acts as an additional defense against security attacks. It also ensures that multiple servers can be accessed from a single record locator or URL regardless of the structure of your local area network.” [ 2 ]
There is a question related to this topic here.
Hope it helps
Can we ignore SSL verification for local network. My case is-
I have two applications deployed in a system. These two applications cannot communicate through internet, due to some security constraints. the two applications can communicate using their private IPs. But the certificate issued by CA is valid only for the public IP (accessible from internet), so when they tries to do a HTTP connection, it throws a Subject Alternative Name invalid exception.
I cannot use alternate certificate.
Please suggest if we can configure Java / JREs of the applications to ignore SSL validation?
Please suggest any alternate solution, if any.
It sounds to me like you might just be better off using HTTP on the local network.
If you need transport layer security on your LAN, you can probably use a VPN or SSH tunnel instead. And it sounds to me like you don't really need this, as you're OK with ignoring SSL handshake errors, which makes using SSL in the first place kind of moot.
You can set up your servers to listen on two ports, one for external requests over HTTPS, and one for internal requests on HTTP.
You can either set up your firewalls so that HTTP is only available from LAN IPs, or alternatively only listen on localhost and use a VPN or SSH tunnel to the target server and do the requests via the tunnel.