I'm using mosquitto for some IoT projects. I can use ACLs files to easily add authentication based on write and read access. But is there any way to active readwrite for a localhost connection and read for connections from outside (public IP)?
I don't see any reason to open the write access for the other connections outside even with a password, and access without the password would be easier for local services.
Not with the built in Username/Password + ACL scheme.
Mosquitto has a plugin interface for authentication/authorisation so you may be able to use that to build what you want.
The other option is to run 2 brokers and set one up with read/write and only listening on localhost, then bridge that to the other with the anonymous user set up with read only and one user for the bridging broker to use.
Related
I created the 3 necessary containers for NuoDB using the NuoDB instructions.
My Docker environment runs on a virtual Ubuntu Linux environment (VMware).
Afterwards I tried to access the database using a console application (C# .Net Framework 4.8) and the Ado.Net technology. For this I used the Nuget "NuoDb.Data.Client" from Nuget.org.
Unfortunately the connection does not work.
If I choose port 8888, my thread disappears to infinity when I open the connection.
For this reason I tried to open the port 48004 to get to the admin container.
On this way I get an error message.
"System.IO.IOException: A connection attempt failed because the remote peer did not respond properly after a certain period of time, or the established connection was faulty because the connected host did not respond 172.18.0.4:48006, 172.18.0.4"
Interestingly, if I specify a wrong database name, it throws an error:
No suitable transaction engine found for database.
This tells me that it connects to the admin container.
Does anyone have any idea what I am doing wrong?
The connection works when I establish a connection with the tool "dbvisualizer".
This tool accesses the transaction engine directly. For this reason I have opened the port 48006 in the corresponding container.
But even with these settings it does not work with my console application.
Thanks in advance.
Port 8888 is the REST port that you would use from the administration tool such as nuocmd: it allows you to start/stop engines and perform other administrative commands. You would not use this port for SQL clients (as you discovered). The correct port to use for SQL clients is 48004.
Port 48004 allows a SQL client to connect to a "load balancer" facility that will redirect it to one of the running TEs. It's not the case that the SQL traffic is routed through this load balancer: instead, the load balancer replies to the client with the address/port of one of the TEs then the client will disconnect from the load balancer and re-connect directly to the TE at that address/port. For this reason, all the ports that TEs are listening on must also be open to the client, not just 48004.
You did suggest you opened these ports but it's not clear from your post whether you followed all the instructions on the doc page you listed. In particular, were you able to connect to the database using the nuosql command line tool as described here? I strongly recommend that you ensure that simple access like this works correctly, before you attempt to try more sophisticated client access such as using Ado.Net.
I have a server and I am using Ubuntu 20.04, nginx , mosquitto and node-red and docker , let's call the website http://mywebsite.com. The problem that I am facing that I have created a client lets call it client1 in docker so the URL will be http://mywebsite.com/client1
and I want to establish an MQTT connection via mosquitto and I'm sending the data on topic test
The problem that on node red node of MQTT when I write the IP address of my mosquitto container it works
But if I change the IP address 192.144.0.5 with mywebsite.com/client1 I can't connect to mosquitto and I can't send or receive any form of data
any idea on how to solve this problem
OK, you are going to have several problems here.
You can not do path based proxying with MQTT. If you want to have multiple MQTT brokers (1 per client) bound to a single public facing domain/IP address then they are all going to have to run on separate ports (other than the default 1883).
Nginx can do MQTT protocol proxying (e.g. like this), so you can use this to expose the different ports and forward them to the separate instances of mosquitto, but even if you had a different hostname (all pointing at the same IP address) nginx has no way to know which host name was used because there is no equivalent to the HOST HTTP header to direct it. If you were to use MQTT with TLS then you may be able to get it to work with SNI, but I've never seen anybody do that yet (possible docs for SNI based routing here) It works, explanation about how to do it here.
If you use MQTT over Websockets then you should be able to use hostname based routing.
Path based proxying for Node-RED currently doesn't work properly if you enable admin authentication, because the admin auth tokens are currently stored in browser local storage and only scoped to the hostname, not the hostname + path. This will mean that a client will only ever be able to log into one instance at a time.
You can work round this by using host based proxying, e.g. http://client1.mywebsite.com
A fix for this is on the backlog for Node-RED, probably (no promises) to be looked at after version 1.2.0 ships
I am currently communicating with my Redis instance from my iOS client using a websocket. I specify the host address and the listening port and execute some Redis Commands from my IOS client directly.
The reason I am doing that because I am doing real live geolocation tracking and executing these commands from my backend which is in php will result in latency.
I am afraid that this is not the most secure way because if someone knows my host address and ports he will be able to access my Redis Instance.
My question is how can I communicate with my Redis Instance from my iOs client using a websocket but in a more secure way.
#Ahmed,
I read the answer provided by #ThatCampbellKid and the comments and understand your wish to have the iOS client communicate directly with the Redis server.
However, Redis was NOT designed for this approach. As indicated in the documentation (emphasis added):
Redis is designed to be accessed by trusted clients inside trusted environments.
The internet is not a trusted environment and the direct access allows Redis to be accessed by non-trusted clients.
The same documentation gives the following example (emphasis added):
In the common case of a single computer directly exposed to the internet, such as a virtualized Linux instance (Linode, EC2, ...), the Redis port should be firewalled to prevent access from the outside. Clients will still be able to access Redis using the loopback interface.
The correct approach would be to use a dynamic application to authenticate clients and bridge between clients and the Redis server.
You can use JWT (the nginx module suggested by #ThatCampbellKid), PHP, Ruby, node.js, Java, C or whatever you want - but you will need to use something.
I'm sorry to say this, but any other shortcut will expose your system to security risks.
EDIT:
Yes, you can still use WebSocket.
The difference is that this architecture is not secure:
Client <=(WebSockets)=> Redis
And this architecture is secure (if implemented correctly):
Client <=(WebSockets)=> Authentication Layer <=(TCP)=> Redis
There are a couple ways of doing it, depending on how your project is set up. You could add an NGINX loadbalancer in front of your php/redis containers that accepts JSON Web Tokens for authentication.
https://www.nginx.com/blog/authentication-content-based-routing-jwts-nginx-plus/
Redis has the ability to do authentication as well, but isn't considered best practices it looks like, but you can find more information about it here also:
https://redis.io/commands/auth
As you said you are already running Nginx then have a look at the Nchan websockets module
Your Nginx install can then serve websocket connections directly and it has support for several methods of client authentication as well as direct integration with redis
I am using the ActiveMQ extension of AppDynamics. It is good to start. With JMXRemote(enabled in artemis.profile) it is OK. But, I want it from localhost. JMX is enabled by default for localhost for AMQ. AMQ management console use jmx internally and it works without JMXRemote enabled. What service URL jolokia use internally to connect using JMX from localhost? I have tryed with following URL:
serviceUrl: "service:jmx:rmi:///jndi/rmi://:1099/jmxrmi"
The first step is to add a username and password in the etc/users.properties file. For most purposes, it is ok to just
use the default settings provided out of the box. For this, just uncomment the following line:
admin=admin,admin,manager,viewer,Operator, Maintainer, Deployer, Auditor, Administrator, SuperUser
Then, you must bypass credential checks on BrokeViewMBean by adding it to the whitelist ACL configuration. You can do so by replacing this line:
org.apache.activemq.Broker;getBrokerVersion=bypass
with this:
org.apache.activemq.Broker=bypass
In addition to being the correct way, it also enables several different configuration options (eg: port, listen address, etc) by just changing the file org.apache.karaf.management.cfg on broker's etc directory.
Please keep in mind that JMX access is made through a different JMX connector root in this case: it uses karaf-root instead of jmxrmi, which was previously used in the older method. It also uses port 1099 by default, instead of 1616.
Therefore, the uri should be
service:jmx:rmi:///jndi/rmi://<host>:<port>/karaf-root
I created one service which is running in one server and I need to copy directory from another server to directory in this server through this service. The service is failed when finding directory specified in another server. Like If DirectoryExists("\\ServerName\DirectoryName"). It is not working even, I set up the service with Network Authority.
Please give solution for this. It will be helpful.
Mallik.
A possible explanation is that the service runs as a user that does not have read rights to the other server's volumes. Authenticating with NETWORKSERVICE does not help you. That's just a user that has access to TCP etc.
What you need to do is to run your service as a user which has read access to the other server's volumes. As a test try your personal login, but in the longer run you may wish to use a dedicated user just for this task.