The Valhalla maps server docs assume that the server is always running on "http://[hostname]:8002"
(see https://github.com/valhalla/valhalla)
How can the server be configured to listen via SSL/https instead?
Is there any detailed documentation on how to do this?
Thnx.
To answer my own question:
After much reading & research I came to the conclusion that a practical way to achieve this is simply to hide the Valhalla port (port 8002) behind my Linux firewall and to expose port 443 (SSL) instead and have Nginx running on that port. Nginx then port-forwards the Valhalla request obj to the internal port 8002 and proxies the response back to the caller for the return journey on the encrypted channel.
Setting up Nginx to achieve this is fairly straightforward and the procedure is documented on many websites.
I open IE explorer & Chrome in my computer and type localhost:80 and I get the index page.
Here I think my machine's IP is same to both connections (IE explorer & Chrome) and ports are too (80).
Note: Source port will be different (as destination is same: localhost IP), this is my second question.
So how webserver (lets say apache) handles this port 80 connections without failing? Does it port forwarding? In OS level even I tried with addr re-use, port re-use parameters and it is all same we cannot make multiple connection with same IPs & ports.
Now, probably you have came up with a solution: although source ports and IPs are same, destination port is different in package: <protocol>, <src addr>, <src port>, <dest addr>, <dest port>.
A. I got 49483~50004 ports as you can see on image. How client knows which destination port (49483~50004) is bound by webserver? If it is random between 0 and 65355 the webserver always binds all ports, it is very resource consuming. How webservers avoid from this?
Look at this image: command prompt-> netstat
If this question is related with low level sources it is OK, I understand Embedded TCP/IP/UDP, Phy MAC communication and package structures.
You have this all back to front.
All the port numbers at the server are the same: 80. So the client only has to know port 80.
All the port numbers at the client are different: 49483-50004 etc. So there is no ambiguity in the connection, because the 4-tuple you mentioned is unique.
All http request by default call to servers in the port 80, because servers listen by default in that port. So you only give an IP or hostname and the web browser add the default port (80). You can give a custom port if you web server is listenning in another port (usually Tomcat listen by default in 8080) for example you call it in: http://www.youamazingweb.com:8080.
A good example is see the IP as the home and the port is the door where clients enter to consume some resource hosted in server.
I have recently starred out with EC2. Currently I am using the Free Tier to test and learn about it. However as I am behind a proxy that allows only connections at port 80 and 443, I am unable to connect the EC2 instance. Is there a way to get past this ?
So far I've guess that running sslh on the EC2 instance, as described here might help. But I am not sure if this behavior should remain persistent once the instance is terminated and re-started (as I am using Free Tier). Is there a way I can achieve persistence in terms of settings and installed resources like sslh (and many others) while using the Free Tier ?
Thanks in advance.
Once when behind a firewall that only allowed outgoing communication on ports such as 80, I just ran an sshd on the server on a different port. You won't be able to set this up while behind the firewall, you'll have to go somewhere else, ssh in, and reconfigure ssh.
Instead of running sshd on a non-standard port, you could also just have something redirect traffic from some other port to port 22.
If your ec2 instance isn't running a web server, you can use port 80 or 443 for the sshd. If you're not using https, then use 443.
You say they only allow outgoing traffic to remote ports 80 and 443, but often times ports above 1024 are also unblocked.
Make sure you've also correctly configured your security groups on the ec2 instance, since it has a firewall as well. You'll have to make sure it's configured to allow incoming traffic on the port supplying the sshd from your IP address. This can be done through the aws management console.
Here there's is a neat solution. I haven't tried it. The idea is to pass a script to boot the instance with ssh bind to port 80.
Goto instances
at the top of the list of your running instances you should see "instance action"
In that menu you should see "connect"
Select "connect from your browser using Java ssh client"
note, you need Java to be installed.
My question may be a little confusing, but anyway. My school is going to open up WiFi DMZ on separate IP for students, but they said port 80 will be the only port open.
What do I want? Well I want to tunnel my traffic thru my home server, which is running Apache2 on 80 and SSH on 21. It's just a regular setup. As it is a production machine and I want clients to be able to connect on port 80, but I want to connect to port 80 to make a tunnel. The question is: How to do that?
The possible sollution: Abandon possibility of connecting to websites running on the server from the school IP and use IPTABLES. If source ip == $school_ip && port == 80: Redirect to port 21. Done. But I think there must another, elegant sollution... Isn't it possible to actually use the HTTP transfer for SSH transit? I mean create a host named for example ssh.mydomain.tld and use some apache module to do a server-side redirection to port 21 but only on that particular hostname? What can I do?
Box is running Debian GNU/Linux
Thanks for any help...
Off topic: They think they will block any sort of illegal operation. In fact HTTP is probably the second most-vulnerable protocol after BitTorrent. Why don't lock it down too? It'll be absolutely safe if there's no open ports, wouldn't it? I don't personally think blocking ports for POP, IMAP, Jabber, etc is any good. I think they'll probably seriously piss someone off if they even can't open mail teacher sent them. Oh, there's a webmail? No no no! SSL/TLS goes on port 443, remember? I don't think blocking all the traffic will be any good. IMO they should block unencrypted BitTorrent and apply low-priority QoS for unclassified transfers.
You could try the instructions found here:
http://dag.wieers.com/howto/ssh-http-tunneling/
proxytunnel is available in the stable repo:
http://packages.debian.org/search?keywords=proxytunnel&searchon=names&suite=stable§ion=all
A simple and working solution is sslh.
It is exactly the tool to solve that problem.
BTW ssh is usually set on port 22.
At my workplace, the traffic blocker/firewall has been getting progressively worse. I can't connect to my home machine on port 22, and lack of ssh access makes me sad. I was previously able to use SSH by moving it to port 5050, but I think some recent filters now treat this traffic as IM and redirect it through another proxy, maybe. That's my best guess; in any case, my ssh connections now terminate before I get to log in.
These days I've been using Ajaxterm over HTTPS, as port 443 is still unmolested, but this is far from ideal. (Sucky terminal emulation, lack of port forwarding, my browser leaks memory at an amazing rate...) I tried setting up mod_proxy_connect on top of mod_ssl, with the idea that I could send a CONNECT localhost:22 HTTP/1.1 request through HTTPS, and then I'd be all set. Sadly, this seems to not work; the HTTPS connection works, up until I finish sending my request; then SSL craps out. It appears as though mod_proxy_connect takes over the whole connection instead of continuing to pipe through mod_ssl, confusing the heck out of the HTTPS client.
Is there a way to get this to work? I don't want to do this over plain HTTP, for several reasons:
Leaving a big fat open proxy like that just stinks
A big fat open proxy is not good over HTTPS either, but with authentication required it feels fine to me
HTTP goes through a proxy -- I'm not too concerned about my traffic being sniffed, as it's ssh that'll be going "plaintext" through the tunnel -- but it's a lot more likely to be mangled than HTTPS, which fundamentally cannot be proxied
Requirements:
Must work over port 443, without disturbing other HTTPS traffic (i.e. I can't just put the ssh server on port 443, because I would no longer be able to serve pages over HTTPS)
I have or can write a simple port forwarder client that runs under Windows (or Cygwin)
Edit
DAG: Tunnelling SSH over HTTP(S) has been pointed out to me, but it doesn't help: at the end of the article, they mention Bug 29744 - CONNECT does not work over existing SSL connection preventing tunnelling over HTTPS, exactly the problem I was running into. At this point, I am probably looking at some CGI script, but I don't want to list that as a requirement if there's better solutions available.
Find out why the company has such a restrictive policy. It might be for a good reason.
If you still find that you want to bypass the policy, you could write a small proxy that will listen on your server on port 443 and then, depending on the request, will forward the traffic either to your web server or to the SSH daemon. There are two catches though.
To determine whether it's an HTTPS request or an SSH request, you need to try to read some data with a (small) timeout, this is because TLS/SSL handshakes start with the client sending some data, whereas the SSH handshake starts with the server sending some data. The timeout has to be big enough to delays in delivering the initial data from the client in the TLS/SSL handshake, so it'll make establishing SSH connections slower.
If the HTTP proxy in your company is smart, it'll actually eavesdrop on the expected TLS/SSL "handshake" when you CONNECT to port 443, and, when it detects that it's not an TLS/SSL handshake, it might terminate the SSH connection attempt. To address that, you could wrap the SSH daemon into an TLS/SSL tunnel (e.g., stunnel), but then you'll need to differentiate requests based on the TLS/SSL version in your client request to determine whether to route the TLS/SSL connection to the web server or to the TLS/SSL-tunneled SSH daemon.
You should be able to use iptables to forward ssh traffic from your work machines to ssh while all other machines attaching to your home server on port 443 get the Apache server.
Try a rule like this:
iptables -t nat -A PREROUTING -p tcp -s 111.111.111.111 --dport 443 -j REDIRECT --to-port 22
Where 111.111.111.111 is your office computer's ip address.
That all assumes you're running Linux >= 2.4, which you should be by now. It's been out for almost a decade.
Documentation for iptables is at http://www.netfilter.org.
Set up OpenVPN 2.1 server at home, use port 443 (if you set up your home any HTTPS service at port 443, trigger OpenVPN's port-share option to handle both OpenVPN and HTTPS transactions at port 443; this feature is only available to non-Windows OS)
Then, set up your OpenVPN client on your laptop in road-warrior mode to access the OpenVPN server at home. You will be able to call home or anywhere you like within a secure VPN network you've created with OpenVPN. It is no longer required to use SSH for this purpose.
I'm really sorry for being the Devil's advocate here, but if they are blocking ports at your work, its likely because they don't want people breaching security.
Now if you get permission to open a tunnel from your boss, that's fine, but IF something happens, ANYTHING, and they figure out you have a tunnel, I can almost assure you, you'll become the scapegoat. So if I were you I'd not be opening tunnels at work if they are setting up firewalls against it.
How about using 2 IP adresses on your machine?
Bind apache/https on one IP_1:443 and your sshd on the other IP_2:443?
Could you set up a middle man?
Run a small/free/cheap instance in the cloud listening on 443 for SSH, then though that cloud instance tunnel to your home box on your favorite port - 22 or whatever.
It'll add some latency I'm sure, but it solves the problem of leaving the original home setup intact.
I think you'll have to find a port that you're not using currently that you can get out on, and listen on that. 443 is the obvious candidate, but you say that's not possible. What about mail (25, 110, 143), telnet (23), ftp (21), DNS (53), or even whois (43)?
Proxy tunnel may be your answer
http://proxytunnel.sourceforge.net/
lets say my ssh server is host.domain.tld and my works proxy server is 10.2.4.37
I would add this to my local ssh config
Host host.domain.tld
ProxyCommand /usr/local/bin/proxytunnel -q -p 10.2.4.37:3128 -d %h:%p
ProtocolKeepAlives 30
See:
SSH Through or Over Proxy
http://daniel.haxx.se/docs/sshproxy.html
http://www.agroman.net/corkscrew/
Since apache has no problem whatsoever with CONNECT when no SSL is involved, I turn off SSL features and I use stunnel to serve an https version of my site. This does not require any recompilation, and allows your site to serve https normally. So far, the cleanest workaround I know.
See http://chm.duquesne.free.fr/blog/?p=281 for details.
Must work over port 443, without disturbing other HTTPS traffic (i.e. I can't just put the ssh server on port 443, because I would no longer be able to serve pages over HTTPS)
Is it possible to bind your HTTPS server to a different port? Depending on what it's used for, you may even be able to get around the problem of not being able to directly access it from work by just SSHing home and then using lynx from there.
So, then, give proxifier a try (- it supports HTTP Proxy Server)!
http://www.proxifier.com/documentation/intro.htm
I managed to bypass my company's firewall using the following design via AjaxTerm, it works for me.
PC on company network --> company's proxy via https --> INTERNET --> My home Apache reverse proxy server on SSL + .htpasswd protection --> AjaxTerm Server(From here on ward, I can SSH to any other servers ).
Still not the perfect world... would be good if I can can tunneling to my home network via HTTPS.