I've seen a lot of solution for redirecting a webserver, but I have a Ubuntu server that is running an application, not over a url. I'd like to redirect requests from https://ip to http://ip, without setting up a domain for this server.
I want the response from http://ip to be returned when https://ip is queried.
I've tried using iptables to redirect traffic from port 443 to 80, but this did not work as requests to https://ip could not get a response.
I also tried using firewall-cmd to allow traffic on port 443, but this did not work either.
Any help on this issue would be greatly appreciated!
By changing the port from 443 to 80, traffic doesn't magically change from HTTP to HTTPS. You can see the port number as a house number and the protocol as a secret knock to get in.
You need to have a service running (who knows the secret knock) on port (house number) 80, which understands the HTTPS protocol (the secret knock).
Related
I have a Windows PC with some Flask webapps running on various ports 5000, 5001, ...
I have mapped subdomains with CNAMEs to point to the server and Nginx handles the rerouting (correct wording?) to the appropriate ports: x.server.net -> ip:5000, y.server.net -> ip:5001
It works
Now I want to enable https so I would like to redirect users from http to https.
Further, I discovered that Nginx doesn't handle when users supply a non-standard port, so x.server.net:5001 actually points to the wrong Flask app. So I would also like to redirect non-default ports to the default (80 or 443 depending on http or https). Some of the apps don't need https, so I might mix it.
Can this be done with Nginx or should I use something else? I found others asking this, but the replies are only for Linux as far as I understand (iptables?).
And last but not least, is redirects a safe approach? Can it be ignored by a malicious client?
I know port 80 is one of well-know-port, but I am confused that if I build the website server process on other port except of 80, would it works when other client try to access this website server?
Port 80 is the default port for http. So connecting to http://domain would in essence send you to http://domain:80 (by default).
Port 443 is the default for https and would work the same way as stated for http above.
Any other port would require the you to do url:port to connect to. There are definitely ways to get around this (like forwarding) but I don't see the need for it and I think it causes more issues than anything.
You would also need to make sure that the new port is open, forwarded and can receive connections.
(Source for the first 2 paragraphs https://developer.mozilla.org/en-US/docs/Glossary/Port)
Somehow I've stumbled on this website that has an http url and an https url at the same time:
http://www.actbrain-vn.com/
https://www.actbrain-vn.com/
I'm not that seasoned in web development yet, so here are my questions:
How does that work? Why doesn't the http url redirect to the newer https? Could this be oversight? If I'm to turn an http website into an https website, what should I do so that this won't happen?
http runs on port 80, and https runs on TCP port 443. They can both be open at the same time, they can even serve different websites. In some ways they are 2 different websites.
To avoid this you can simply close down port 80, or alternatively, make sure that website served on port 80 always sends a redirect to the https website.
Theres a server in a customer that runs a nginx, a salt master daemon from saltstack and a secret web app that does secret things.
Considerations:
In this scenario, theres only one ip, only one server and multiple DNS records available;
I have nginx running in port 80;
And salt master running in 6453;
A domain.example.com binding to that IP, exposing my nginx 80 port, that points to the secret webapp;
otherdomain.example.com binding to the same IP, exposing my nginx 80 port, that I want to use to proxy salt port.
That customer has a machine in other place, that does need to connect to the salt and the internet connection is provided by a secret organization and they only allow connections to port 80, no negotiation possible.
My question:
Is possible to use nginx to redirect the otherdomain.example.com 80 port to the 6453 port? I tried the following:
server {
listen 80;
server_name otherdomain.example.com;
proxy_pass 127.0.0.1:6453;
}
But that doesn't work as expected. It is possible? There's some way to do this using nginx?
The error I got from log was:
"proxy_pass" directive is not allowed here
proxy_pass needs to be specified within a location context, and is fundamentally a Web Thing. It only comes into play after the web headers are sent and interpreted.
Things like what you're trying to accomplish are commonly done using HAProxy in tcp mode, although there is a tcp proxy module that also does similar things.
However, I don't think you're going to be very successful, as ZMQ does not participate in the protocol (HTTP Host: headers) that easily allows you to tell the web requests apart from the non-web requests (that come in on the same port).
My recommendation is to either find some way to use another port for this, a second IP address, or write a tricky TCP proxier that'll identify incoming HTTP and/or ZMQ connections and transparently forward them to the correct local port.
I have a play application running on port 8080. I currently forward to this by using
http://ip_address:8080
as my 'URL to forward to' in my forwarding service control panel.
The problem with this is: frame forwarding is used and I think this may be stopping Google Analytic for working.
I have control over DNS
A, CNAME, AAAA, TXT and NS records
&
DNS Service records
For other websites in the past running on port 80 I have simply created an A record with the destination as the server IP address, however because I am using port 8080 in this case, this does not work.
What is the best way to go about getting away from framed forwarding?
You can't put port numbers into the DNS resource record (there's a notable exception, namely SRV records, but as client support for those is rather spotty, those won't be much help). A nameserver commonly resolves hostnames to ip addresses - no directory/file names, no port numbers.
You can use a permanent redirect, which is a webserver facility, used to tell web clients to contact a different webhost. In order to use that, you need a webserver which responds to requests on port 80, and knows that requests concerning your zone must be redirected to your actual webserver. Very similar to the iframe solution you've been already using, but a permanent redirect instead of iframe.
If your reason for dropping the current iframe approach isn't that you, for example, want to get rid of decorative framing, ads, "branding" etc (with those, a permanent redirect would help), but want to cease using an intermediate webserver, adding another level of indirection to the queries, there's little you can do:
your firewall may be able to do port redirection, meaning that the incoming requests will hit your gateway/firewall on port 80, where the request is sent on to port 8080 where the webserver is actually listening. Another possibility could be, but requiring again another webserver, listening to port 80, to set up proxying: incoming requests to that webserver will be served from a cache on that server, which is populated and occasionally refreshed as result of that webserver querying your webserver on port 8080.
Even though with the latter suggestion an additional webserver will be existing, there'd be no visible indirection, as it would be transparent to clients: The web files are produced by the first server which is hit, even if they are once every so often taken from another server.