Is there cloudify's management and agent communication encryption?
if not, How can I implement encryption?
thank you very much! Steve
The internal communications between Cloudify agents and managers is not encrypted.
In a production setting, you would have all of the Cloudify internal traffic use a dedicated management network, and application processes should use a dedicated application network.
Related
I am building a golang offline application for a company that will operate in their office internal Wireless / Wired Network.
There will be one server computer and many client computers communicating over the network. (They are not connected to the Internet).
How should I encrypt the HTTP communication between the clients and the server so that the data is not vulnerable to any attackers who might be snooping on the network?
How should I encrypt the HTTP communication between the clients and the server
Short answer - use https.
They are not connected to the Internet
HTTPS basically works on two parameters. Hostname and trusted authorities.
The best practice would be to assign each service/server a proper internal hostname and use a valid certificate for the hostname.
There are multiple options which you should to choose based on requirements which are not stated. Have a single wildcard cartificate or individual server/service certificates? Using a trusted external CA or create your own CA for certificates? Do you use client-auth mutual SSL? Each option has its advantages and risks.
Question regarding a management VLAN. Should there be an IP address for every device you need to manage, or just enough addresses on the subnet for a few people to manage devices?
From Cisco Design Best Practices for VLAN:
A good security practice is to separate management and user data traffic. The management VLAN, which is VLAN 1 by default, should be changed to a separate, distinct VLAN. To communicate remotely with a Cisco switch for management purposes, the switch must have an IP address configured on the management VLAN. Users in other VLANs would not be able to establish remote access sessions to the switch unless they were routed into the management VLAN, providing an additional layer of security.
Often, admin workstations with access to the management VLAN do not have a direct connection but they are routed by a firewall.
We are investigating adding the Kaa client to our products and using the Kaa server operationally, and we have some questions in the networking and protocol area. Our main concern is having the IoT device access the IoT server through the Internet without being blocked by the firewall at the IoT device in a "typical" environment. For this reason we see that HTTP/HTTPS using port 80/443 is often used.
Do you believe that most of the IoT device will communicate because most firewalls allow all outgoing traffic?
Or do you think that most end users will have to explicitly configure a firewall rule for the IoT device?
What was the rationale for using the port numbers 9889/9888 and 9999/9997?
Can these port numbers be reasonablely modified? If so, where and how?
Is there a specification of the Kaa TCP protocol?
Thank You
Keith Krajewski
About Kaa TCP protocol use official documentation page
you can change ports of bootstrap and operations services in this files:
bootstrap-http-transport.config
bootstrap-tcp-transport.config
operations-http-transport.config
operations-tcp-transport.config
I am woking on a Mobile application, which sends GPS co-ordinates from the mobile to an azure website.
Right now I am able to do this using TCP endpoints in Azure Web/Worker Role. The Mobile hardware I am using is SIM300 module.
SIM300 also provides sending data via UDP, which is much simpler, faster for my application.
I have heard Azure Connect uses UDP to communicate between local and virtual machines through UDP.
I am not sure, but is there any way to implement the same application to use UDP instead of TCP in Azure?
I managed to get UDP to work over the service bus using a UDP -> TCP tunnel. But as Simon says, you're better off using TCP if you can.
http://coderead.wordpress.com/2012/03/14/tunnelling-udp-over-the-service-bus-or-how-to-get-sentinel-licencing-server-working-on-azure/
Azure doesn't support public UDP endpoints (yet). The only current alternative is to use an non-Azure server that listens on UDP and, via Windows Azure Connect, forwards it to the 'internal' endpoint. Since your device already uses TCP anyway, I would stick with that for now.
I'm implementing a protection system for household network. There are several digital devices in the home, and they all have web services running on them in order that they can visit each other easily.
To visit them outside home, I need UPnP to penetrate the NAT.
My question is: Is there any authentication in the UPnP server to protect my private network, or I have to implement it for all my digital devices which have web services running on?
The answer is: no, there is not. This is a weak aspect of UPnP.