Why do SSO providers like Ping Federate run on ports that aren't well-known like 9031. Does this enhance security? It seems like it just increases connectivity issues in organizations with strict firewall rules.
That's just a default semi-random port so that it doesn't clash with existing services on the same machine and is a high port so that the server can run under a non-privileged user account.
For production usage one would typically change it to 443 and/or run a reverse-proxy/loadbalancer in front of the SSO server (on port 443).
Generally security is managed at the perimeter of a network. For deployments I have been involved, port 443 is predominately used for SSO (e.g. PingFederate) at the perimeter. For the internal network, I have seen two models, mainly (i) change the HTTPS port in PingFederate to 443, or (ii) utilize load balancer port forwarding from 443 to 9031. I usually see item (i) for Windows deployments and item (ii) for Linux deployments where reserved ports are avoided. There really isn't a true security enhancement for either pattern.
As Hans points out, PingFederate utilizes 9031 as a default so that conflict with other processes on a server are avoided when first deploying the technology. As the SSO capability matures into an environment, the proper port for the service can be managed. The default port avoids issues when first installing that can be frustrating to folks new to the technology.
Related
I'm running a Minecraft server on one of my old computers. I'm planning on opening it to the public but I want to first secure everything. I bought a domain for the server and tried to use Cloudflare but apparently Cloudflare only protects ports 80 and 443 https://i.stack.imgur.com/mxQOw.png. I haven't been able to find a free or at least cheap proxy that could protect port 25565 which is the port that the server runs on.
I don't believe there are any free services for that. The closest is Cloudflare, but that's only for HTTP traffic like you said.
However, just quite recently they've released Spectrum, that allows you to proxy any TPC/UDP port, which means you can proxy your game server ports through it (source). It's not cheap though. Spectrum is only available for paid plans, and it's charged on usage basis.
There is a Cloudflare product but I think there are also other cheaper alternatives you can find by Googling.
I deployed an app with nodejs on Google App Engine and mongodb on Compute Engine.
Without security rules, GAE can successfully connect to mongodb, but when I set a security rule which allow to access port 27017 of the VM from the App Engine service account I get timeout request so mongodb is not reachable.
As is not possible to set a static ip to GAE, is there another solution to securing mongodb on Compute Engine?
Check the priority of firewall allow rule and deny rule. Lower numbers have higher priorities. Be sure that the allow firewall rule has a higher priority than other rules that might deny traffic.
Yes, at the moment you're not able to set a static external IP on your GAE application.
There's a possible workaround for GAE Flex to solve your issue:
reserve an external static IP
create f1-micro VM instance with reserved external IP address (this likely fits in the Compute Engine free tier)
create a firewall rule to allow connection to MongoDB server from reserved external IP
create a SOCKS proxy by running a ssh client that routes the traffic through created VM similar to this example
configure nodejs application to use SOCKS Proxy
connect to MongoDB server
UPDATE
Also, if you application can run over HTTP proxy you can Squid proxy installed on this VM instead of SOCKS Proxy.
I have a domain name registered at ovh.com, let's say it's called domain.com.
This domain is pointing on my router's public IP, then I redirect the https port 443 of my router to my server port 443. So when we go to domain.com it redirects to my server:443.
To be more accurate, domain.com just redirect to my router's public IP. So for example if I use a graphic database manager, I can tell him that the server address is domain.com:[SGBD port] and It will works.
But all my applications are running on this same server. And to add a little more security, I am not using the usual port for all protocols. So let's say my port are the following :
git : 50000
SGBD : 55000
cloud : 60000
website 65000
and some others, for example some TCP ports between 40000 and 50000.
My git and my cloud have a graphical manager I can access by typing domain.com:50000 or domain.com:60000 in my web browser from everywhere. I use the same URL on all my software. domain.com:50000 for my git client, domain.com:55000 for my database client and so on.
This way is working perfectly but there are 2 problems annoying me :
The first one is that I have to tell the port number to everyone who's susceptible to use my applications. But like I said I am not using usual port number for a little more security so I don't want to share these numbers with everyone.
The second problem is more important :
When I am somewhere, for example at work, it's possible that the firewall is blocking the port numbers I am using. So my personal git isn't accessible, same for my cloud etc.
To solve these problem in one move I wanted to add subdomain on my domain and redirect these subdomain to my differents ports. For example :
website : domain.com:65000
git.domain.com ==> domain.com:50000
SGBD.domain.com ==> domain.com:55000
cloud.domain.com ==> domain.com:60000
So in my mind, with this solution I can type git.domain.com in my browser to initiate the communication by https (the https port is almost never blocked), then redirect it to my router's port 50000 from OVH then my router redirect it to the git port of my server.
But obviously this would be to good to be truth.
When creating a subdomain (at least on OVH ?) we can't specify a port. So I can't set git.domain.com is redirecting to myRouterIp:50000 but just to myRouterIp. So with a web browser, typing git.domain.com will redirect to myRouterIp:443, which is already taken by my website.
So i'm a little confused. Do I have to buy one router with a different public IP per application then making all differents subdomain pointing on a different router ? I almost sure it's a bit ridiculous. How do you think I can solve it ?
As you correctly noticed, in your DNS console you can't specify port; the reason is that DNS does not care about ports, its only purpose is to resolve hostnames to IP addresses.
Another thing important for your problem is that most (non http) application clients will, even if they use friendly hostname, resolve that name to IP address before initiating the connection to your router/server, and then use that IP address for communicating to router/server. That means that when request reaches a port on your router/server, there will be no way for router/server to determine which hostname was initially used.
The rare exception to this is HTTP, where the browser is always sending the requested hostname in Host HTTP header. That means that you can run multiple different websites on one IP address on the same port (that is how shared web hosting works, for example). Setting this up should be pretty straightforward, but is probably out of scope on SO, try SF or SU.
For other (non HTTP services), the only solution is to run them on different ports (which you already do), or to have multiple public IP addresses (which might be difficult to get from your ISP). Also, running non-http services on some random non-default ports (and telling that port number to your users) might be (very sightly) more secure than running them on their respective default ports.
Depending on your use case, one other possible solution would be to have your users connect to your local network using secure VPN, and after that they could have access to your services (which would run on different private IP addresses and any port you like).
Just curious. When developing with Casini development server, one has an infinite number of ports. But, the production servers seem to give a particular importance to port 80.
Has that to do with a technical requirement, a convention, or both? I've checked the web but haven't been able to find a clear response so far.
Thanks for helping.
Many services have specifically-assigned ports This allows users to type, for example http://stackoverflow.com and get the website for SO, without needing to enter a port as well. This isn't a technical requirement; however, using a different port requires the user to know an extra piece of information, which must be entered into the URL every time.
When you connect to a server via TCP/IP you specify particular port you connect to. You do not connect to a server and hope that server guesses which port you would like to talk to.
So in most cases you tell browser to use protocol http, say "http://example.com/" then browser uses default port number assigned to that protocol (http) to connect to server "example.com". In this case port is 80. If for example you specify "https://example.com/" then browser looks for default port for https and then connects to port 443 instead.
So if you do not want to tell to every of your users to specify some non-default port for your service (say "http://example.com:60765/") you better use default one.
BTW there is a way to get port number your service listens to by it's protocol name (by asking a service's host's daemon at port 0) but this method seems to be rarely used (if at all).
See also other answers: default protocol numbers are assigned by IANA
It's a convention: you can use whatever port you feel like. You can look at the evolution of RFCs to see when the convention was official (http://www.faqs.org/rfcs/rfc1700.html)
You can see in the RFC 1060 (http://www.faqs.org/rfcs/rfc1060.html ) that it's the ISO Internet Protocol :)
In a production environment your web server is embedded in a server infrastructure (firewalls, proxies) protecting you against attacks from the internet. In such an environment port 80 is normally open for HTTP traffic. If you use this port there is no need to configure your server infrastructure.
I am trying to understand how a solution will behave if deployed in a server farm. We have a Java web application which will talk to an FTP server for file uploads and downloads.
It is also desirable to protect the FTP server with a firewall, such that it will allow incoming traffic only from the web server.
AT the moment since we do not have a server farm, all requests to the FTP server come from the same IP (web server IP) making it possible to add a simple rule in the firewall. However, if the application is moved to a server farm, then I do not know which machine in the farm will make a request to the FTP server.
Just like the farm is hidden behind a facade for it's clients, is it hidden behind a facade for the services it might invoke, so that regardless of which machine from the farm makes the request to the FTP server, it always sees the same IP?
Are all server farms implemented the same way, or would this behavior depend on the type of server farm? I am thinking of using Amazon Elastic CLoud.
It depends very much on how your web cluster is configured. If your cluster is behind a NAT firewall, then yes, all outgoing connections will appear to come from the same address. Otherwise, the IP addresses will be different, but they'll almost certainly all be in a fairly small range of addresses, and you should be able to add that range to the firewall's exclude list, or even just list the IP address of each machine individually.
Usually you can enter cnames or subnets when setting up firewall rules, which would simplify the maintenance of them. You can also send all traffic through a load balancer or proxy. Thats essentially how any cloud/cluster/farm service works.
many client ips <-> load balancer <-> many servers