I would like to connect a volttron platform running on a raspberry pi connected to the local network of a building to a second volttron platform running on a virtual personal server.
I know that two volttron platforms can interact with each other using the Volttron Central Management Agent or using the ForwardAgent. However, it is not clear to me what security method is used. Our ICT manager only agrees to set up a connection if the information is exchanged through https.
Could you help me formulating an answer to ICT regarding the security issue? And give me some pratical tips on how to set up the volttron configuration files? I'm not very familiar with network/security technologies. Maybe important to know: the server has a proxy and a reverse-proxy security.
Thx!
Your security person is correct. You should only set the platform up in a "real" environment through https. Since you have a proxy, that should be forwarded to the volttron central agent.
internet (443) -> proxy -> http://127.0.0.1:8080
The proxy in this case is on the same machine as the volttron central platform.
This is how we are doing it with apache as our proxy. One could do the same thing with a different web server such as nginx.
Hopefully that helps
If you are indeed trying to connect from a single instance to another instance (e.g. the way the forwarder does). Then the answer is the security is using public/private key pairs with curve mq providing perfect forward security. All traffic between platforms is 100% encrypted and only authorized agents can transmit across the instances bus.
http://curvezmq.org/
Related
I was thinking not to set any External IP Addresses on the cockroach database cluster that I will be launching, as I would be connecting to the cluster using the Internal IP Addresses itself.
I am deploying the cluster on GCP (Google Cloud Platform) and would have other application servers that would have External IPs and would interface with the Database Cluster.
I wanted to know, if there are any drawbacks or generally not a good practice to proceed with the above configuration.
In my opinion it is a good decision to avoid external IPs as much as possible, especially for databases and backend servers. it is an increase in security on the expense of convince in connecting (e.g. direct SSH).
You'll be able to SSH to such servers as needed by opening SSH tunnels from other VMs in the same VPC or VPN (openvpn, tinc, ..).
While using volttron-cfg, I was asked some questions:
Include volttron central platform agent on volttron central? [Y] Is VC platform agent is the backend agent and VC is the frontend?
What is port 22916 (vip port)? The content returned from
"localhost:22916" is not readable.
Thanks.
The VOLTTRON central agent(VC) connects to the individual VOLTTRON instances through the VOLTTRON central platform agent(VCP).
Both the VC and VCP agents are not considered platform agents because they aren't started up when you start VOLTTRON by default.
When using the volttron-cfg command the question is asking you do you want to have a VCP as well as a VC installed on whatever instance you are setting up.
The port 22916 is the VIP (VOLTTRON Interconnect Protocol) port that allows all of the VOLTTRON agents to connect with the VOLTTRON router. If you have a VOLTTRON instance running (and left as the default port), you can telnet to it and see that it is indeed running. You will not be able to browse to it however as it is not serving http requests from that port.
Now an application is connected to a database server in the same LAN and performs selects and inserts.
The database will be moved to a remote location accessible throughout internet. Performance degradation will be addressed reducing the number of operations to the db. It is not possible to use vpn or configure access-in rules based on client IP on the firewall of the net where the database server will be moved. So it seems to me it is necessary to create a database front end in order to protect it. I suppose one way to achieve this goal is to create a web service.
Are there easier alternatives?
I'm new to web services: it should run into Glassfish server while the client would be a c# application.
I read a bit about securing a web service but I'm a confused.
One method I found in internet is to use Glassfish built-in authentication mechanism and configure web.xml limiting the access to the web service URL to a group of users.
It seems an easy approach, are there any drawbacks?
Is it easy to use this type of authentication in the C# client?
Other existing web services wants a parameter key in the request. Then this key is compared with valid ones and if the check is successful the request will be accepted.
Is this approach more secure than the previous one?
Another alternative is to use WSIT but at a first glance it seems over-complicated and all the security mechanisms need a server certificate.
Anyway it looks more secure; does it fit well with JAX-RS and restful web services?
You can use L2TP or PPTP VPN in this case.
Let me show you first Network topology.
Client (accessing firewall with L2TP or PPTP )-----> Firewall (L2TP or PPTP VPN Server)---> Firewall LAN where your Server placed.
In above case all Client come from VPN so its secure and On firewall you have to Configure VPN to LAN rule with client base rule.
I am trying to secure online transaction between application server and database. One-way is SSL, but is there any other way of securing transaction between them. I am trying to reduce the overhead in securing the line. Are there any tool or api's which I can integrate with the application server or deploy on it.
/SR
Sure, but it requires a thoughtful review of your architecture. If you have a dedicated line between your application and your database, the connection could be encrypted at the network layer.
I'm a bit surprised that your application server and your database are not within the same trust boundary. Is this an app in the cloud?
SSL is by far the best way, its extremely secure and absolutely free. If your database or another application doesn't support SSL then you can use a free SSL VPN such as OpenVPN. This will create a secure transport layer connection between 2 machines.
If you are connecting to a database on the local machine then there is no point in a secure transport layer connection. However you should firewall off the database port, for instance MySQL uses tcp 3306.
I need to transfer data daily from SQL Server (2008) to SQL Server (2005). One of the servers is located at our web host so the data will be transferred over the Internet. On the same network I would use SSIS to transfer the data, but over the Internet this is not a secure option. Is there a secure way of achieving this?
You can use SSL with SQL Server (2000/2005 Instructions / 2008 Instructions) and then force protocol encryption on the connection between both machines. You don't have to use a purchased SSL certificate either, you can use Windows Server Certificate Services to generate one - however if you do so then the CRL must be on a machine that both servers can connect to. An easy way to do this is install Certificate Services on a stand alone machine, perhaps just a VM and the configure it to embed a public DNS name for it's CRL. This doesn't have to be a machine running Certificate Services, just something you own and can upload to. Then you can generate the certificates and publish the CRL and tada, all done.
You will need to ensure the service account SQL is running as has access to the private key of the certificate it is using.
Generally it isn't recommended to have your SQL Servers exposed to the Internet, although that may be out of your control in this case. In your position I would investigate developing some separate Web Services that would perform the transfer of the data. These can then be secured using a variety of methods, such as SSL and WS-Security and other custom user permissions. If that isn't possible then blowdart's answer seems like the way to go.
You can use Service Broker:
Built into SLQ Server engine itself, no need for external process to drive communication.
Compatible protocol SQL 2005 and SQL 2008 communicate over Service Broker out-of-the box.
No need to expose either server to the internet. Through Message Forwarding you can expose
just a SQL Express, with no data on it, to the internet to act as a gateway that lets messages into the back end target.
Communication is encrypted.
Speed, the sample in the link shows how you can exchange over 5000 1k payload messages per second between commodity machines.
Unlike SSIS or replication Service Broker is a general communication framework so it won't provide support to extract the changes and to apply the changes, with conflict resolution and the like. You would have to code that part yourself.