binding rethinkdb webUI to 'localhost' and proxy: refuses connections or exposes to full network - proxy

I am not able to successfully bind and secure the rethinkdb http client, either being exposed to the whole network or refusing connections behind the proxy.
I am thus left with no choice but to restart the rdb daemon with bind-http=all each
time I want to access it...
Rdb starts with systemctl under archlinux. Three configurations I tried:
# /etc/rethinkdb/instances.d/mydb.conf
bind-http=localhost #(1)
bind-http=127.0.0.1 #(2)
bind-http=1.2.3.4 #(3)
Resulting in:
Fails to parse 'localhost'
Refuses connections behind the proxy
Equivalent to bind-http=all
Firefox 59 uses a socks proxy, working ok
as the browser's ip address does become 1.2.3.4:
$ ssh -TND 8080 user#1.2.3.4
I am quite convinced that I had secured the http client as expected,
and problems started after I updated both FF and rdb
(FF59 fails to parse 'localhost' as well for example)
I don't know if this is a bug or a feature or if I am missing something,
any help is most welcome. Many thanks

Beware of the "localhost" string.
Configuring the rethinkdb server with:
#/etc/rethinkdb/instances.d/mydb.conf
bind-http=127.0.0.1
http-port=8084
and binding some local port with SSH:
[client]$ ssh -L 8080:127.0.0.1:8084 server
is enough to access the web interface at 127.0.0.1:8080, as suggested by #jishi.
Configuring the browser to use a SOCKS proxy as per the rdb docs is not at all necessary.
For some reason localhost:8080 is not understood by FF59 (gets invisibly prefixed by www or something).

Related

GET/POST Request from Jelastic environment to another: connection refused

I'm trying to make GET/POST requests from one Jelastic environment to another. Both are running Node/Express. I tried with env name (which works from my local machine) and internal IP address, but I always get a connection refused error:
FetchError: request to https://10.101.19.55/converter failed,
reason: connect ECONNREFUSED 10.101.19.55:443
Any hint on how to solve this is greatly appreciated.
You don't mention how your application is deployed (on what node type), but most likely it isn't listening on port 443; that only works remotely (if it does) because of proxying by the Shared Load Balancer of the Jelastic platform.
If you want to connect internally (between Jelastic nodes within the same platform), your requests do not pass via the Shared Load Balancer so cannot take advantage of that proxying.
In other words, you need to:
connect directly to the port you application actually runs on, such as https://10.101.19.55:5000/converter (if your application is running/listening on port 5000)
ensure that your firewall rules permit access from where you're connecting from

websocket will not connect from remote server

I have a web page to control a thermostat on a raspberry pi, and I'm running into difficulties when trying to get websockets to work from a remote client. It seems to work fine when on LAN however. I'm obviously missing something (and likely something basic), but I can't seem to figure out what it is.
The pi's local ip is 192.168.1.134. The web page (served from apache server) has the URL http://192.168.1.134:8010/thermostat.html. The page starts up some javascript, which then tries to connect to the pi's main program using websockets via ws://192.168.1.134:9000. (the server on the pi is running libwebsockets). The websocket comes up, and it seems to work fine. I then tried to connect via a remote client (a cell phone, where wifi was turned off) from http:\\23.239.99.99:8010\thermostat.html. The html/js files load fine, but the web socket attempts to connect to uri ws:\\23.239.99.99:9000, and this fials.
As far as I can tell, the NAT seems to be configured properly:
name ext ext protocol int int ip addr interface
port port port port
start end start end
Thermostat3 8010 8010 TCP 8010 8010 192.168.1.134 eth3.1
Thermostat5 8000 8000 TCP/UDP 80 80 192.168.1.134 eth3.1
Thermostat_ws 9000 9000 TCP/UDP 9000 9000 192.168.1.134 eth3.1
I checked, and the router does not have any firewalls set up, neither does my modem. I didn't install a firewall on the pi (I checked, and there's no odd iptables rule). Does anyone know what I'm missing?
--- EDIT ---
I'm still stuck on this. I called my ISP and they assure me there are no firewalls on their servers. Is there any way to tell if port 9000 is being blocked, and by who?
Bind your apache server to 0.0.0.0 address to make it accessible from remote machines
Try this tool to determine if the port is inaccessible (use the custom port): http://www.whatsmyip.org/port-scanner/
Everything else looks fine. As a sanity check I would try putting the ws port to 8010 to see if that works. I would also recommend using a tool like Advanced Web Client to isolate networking issues.
This is interesting. I once had a similar problem. I set up a WebSocket (I was using a nodejs ws) and once I tried to access it from remote client I was not able to reach it with ws://yourip:port but instead I had to use http://yourip:port. I don't know if you have the same problem, mine was due to a proxy I was using.
I still have an advice for you how you might be able to solve your problem. I don't know how concerned you are about security but as far as I understood your idea you basically connect to your raspberry pi through a WebSocket and tell it to change the temperature.
Back when did a similar project I found it rather hard to secure my WebSocket connection. I was basically sending a password plus command through the WebSocket to my server which then checks wether the password is correct. Otherwise everyone on the internet could heat your house. Not cool...
But therefore, I had to tunnel the connection through https to prevent a middleware attack.
I quickly threw the towel and decided to go with a completely different solution. Basically I set up a nodejs express server (can easily be configured with a self signed certificate to use https or used behind a nginx/apache https server) and authenticated with username and password. When someone made a POST request to /api/thermostats?id=0 with a temperature request, the server checks if the user is authenticated and then executes a terminal command from within node.
Maybe this idea also fits your demands.

How to setup rethinkdb proxy server

we have two client machines, how do we connect both of them using proxy server? As you said earlier:
"To start a RethinkDB proxy on the client:
rethinkdb proxy -j -j ..."
only of the clients can connect in this way, since the ports will already be in use.
As mentioned elsewhere, you can avoid the port conflict by passing in the -o 1 argument. This shifts the ports that the proxy uses by an offset of 1.

Proxify an application via loopback adapters and SSH

This is part programming, part sysadmin, so please excuse me if you feel that this should be over on serverfault.
I have an application that is not SOCKS aware and that we need to use through a firewall. We cannot modify the application to have SOCKS support either.
At the moment, we do this by aliasing the IPs the application talks to the loopback adapter on the host, then creating SSH tunnels out to another host. The IP's the application uses are hardcoded. Our SSH connections look like:
ssh -L 1.2.3.4:9999:1.2.3.4:9999 user#somehost
Where 1.2.3.x are aliases on the loopback.
So the application connects to the open port on the loopback, which gets sent out to the SSH host and onto the real 1.2.3.4.
It works, but the problem is that this application connects to quite a few IPs ( 50+ ), so we end up with 50 ssh connections out from the box.
We've tried to use several 'proxifying' apps, like tsocks and others but have had alot of issues with them ( the app is running on OS X and tsocks doesn't work so well, even with the patches )
Our idea was to write a daemon that listened on all interfaces on the specified port - it would then take the incoming packets from the application, scrape the packet info ( dst IP, port, payload ), recreate the packet and proxify it through a single SSH SOCKS connection ( ssh -D 1080 user#somehost ). That way, we only have 1 SSH connection that all the ports are being proxied through.
My question is - is this feasible? Is there something that I'm missing here? I've been combing through pfctl, ipfw, iptables docs, but I don't see any option to do it through those and this doesn't seem like it'd be the most difficult thing to code. It would recreate the packet based on the original destination IP and port, connect to the local SOCKs proxy and resend the packet as if it were the original application, but now with SOCKS support.
If I'm missing something that someone knows about that already does this, please let me know. I don't know socket programming or SOCKs too well, but this doesn't seem like it'd be too big of a project to tackle, but I'd like some opinions if I'm biting off way more that I should.
Thanks
If your application could add SOCKS client support, you can simply ssh -D lock_socks_port remote_machine, which will open up the local *lock_socks_port* as a SOCKS server at localhost, which can then connect to any host accesible by the remote machine.
Example: imagine you are using an untrusted wifi network without encryption. You can simply launch ssh -D 1082 home, and then configure your web browser to use localhost:1080 as SOCKS server. Of course, you need a SOCKS-enabled client. All the traffic would appear as coming from your gateway, and the connection would be opaque to those snooping the wifi.
You can also open a single ssh client with an indefinite number of LocalForward requests, which would be tunneled on top of a single ssh session.
Moreover, you can add ssh connections to an already-established ssh connection by using the ControlMaster and ControlPath options of ssh.

Other hosts cannot connect to websocket server on my host

First of all, sorry for my bad English : )
My Java application (multiplayer game server) uses this package to communicate with a web application in client's browser using websockets: https://github.com/TooTallNate/Java-WebSocket
I've encountered a problem running my application: only I can connect to the websocket server, clients on other hosts can't do so. In browser I estabilish connection as usual, address here is certainly correct:
new WebSocket("ws://"+serverIp+":8787");
When I connect from my own host to the websocket server running on the same host, it runs perfectly. When other hosts try to connect to me, connection in not being estabilished: in browser WebSocket objects's .readyState is 0 (whilst it should be 1), and even server does not recieve any handshakes (no output from onClientOpen in server console, I even tried to get any output from certain WebSocketServer class' methods).
Other hosts are still recieving, for example, static contents of web application from webserver on 80 port on the same host. Problem is not the closed 8787 port: I checked it, it's open.
What may be the reason that other host can't connect to my websocket server?
WebSockets uses a cross-origin permission system. You might need to tell you WebSocket server to accept connections from more than just your local host. The verification of Origin happens during the WebSocket handshake which likely happens prior to onclientOpen.

Resources