Default credentials are credentials (usually username/password combinations), such as admin/admin that device producers put in during manufacturing. These are intended to be temporary and changed by the user as soon as possible. In reality however, many users fail to change this, leaving the device(s) vulnerable to attackers.
Default credentials are usually attributed to one of the biggest problems in IoT, and enabled malware like Mirai to spread like wildfire.
WoTT will automatically scan your devices for default credentials. We have built a database that includes not only the data set that Mirai used (to ensure you won’t get compromised), but also additional credentials we’ve found to be common.
If the WoTT Dashboard displays a warning that default credentials were found, we strongly recommend that you quickly resolve this issue.
Default credentials will lower your device’s Trust Score.
SELinux, short for Security Enhanced Linux, provides more granular access control to Linux. You can use this to limit what your applications can and cannot do. Therefore if the application were to get compromised, the attacker is restricted in the damage they can inflict. For instance, you can configure what network resources and interprocess communication (IPC) the application can use.
The possible modes in WoTT’s dashboard are:
(Where Enforcing will give you the best Trust Score).
AppArmor is similar to SELinux, and also provides more granular access control for processes. It is for instance heavily leverage in Ubuntu Core to confine what a particular application can and cannot do.
It is recommended that you either use AppArmor or SELinux (not both) for the best security posture of your device.
A firewall can be configured with two default policies:
If you select “Accept by default,” all inbound communication is allowed unless explicitly blocked. With a “Deny by default” all incoming traffic is blocked, unless explicitly allowed.
The most secure firewall configuration is “Deny by default.”
A group policy is a set of configurations that can apply to one or more nodes. These policies can include things like firewall configurations for a fleet of servers.
By using group policies, you are able to easily manage configuration at scale and avoid duplicate work.
Open connections are network connections (incoming or outgoing) reported by the WoTT Agent during its last run. We monitor this on an ongoing basis in order to determine what the normal behavior of the device is. Contrary to a workstation, an IoT device tends to have very predictable network operations. Hence, by monitoring the network behavior for abnormalities, we are able to find potentially malicious activities.
A device certificate is the public part of the cryptographic identity of a device (the private part is called a “private key”). Using the device certificate, we are able to perform cryptographic operations that only the device in possession of the private key can decrypt or interact with.
An example of how this can be used is found in our Google Core IoT example, where we upload the device certificate to Google in order to grant the device access to communicate to Google’s IoT services. In this example, the device uses its private key to prove its identity.
The URL found in the dashboard is permanent, and you will always be able to download the latest certificate; but it is recommended that you do this programatically due to the short life span of the certificates. An example of how to do this can be found here.
The (WoTT) Node ID (formerly known as “Device ID”), is the unique identifier in WoTT. When creating policies, like in our Nginx + Appserver example, this is the identity we use for each node. Because this is a cryptographic identity, is is possible to issue challenges to the node and be certain that the node is what it claims to be.
An FQDN, or Fully Qualified Domain Name, is the hostname that the system itself has been given. This can either be a private name (like my-device.local) or a public name (like my-device.company.com). An FQDN is used to identify the device on a network.
It is strongly recommended that you disable root login over SSH. The reason for this is that you shouldn’t login as root remotely, and instead utilize something like sudo or su to escalate privileges whenever needed (i.e. don’t use root as your day-to-day user account).
By changing “PermitRootLogin” to “no”, you disable root login over SSH.
For more details, please see the sshd_config man page.
AllowedAgentForwarding is convenient, as it allows you to use your local SSH keys on a remote host. This is useful when you want to use a host to jump to another host (e.g. a bastion/jump server).
However, there is a known attack vector where another user on the jump box could intercept your key(s), which is why it is recommended to disable this feature unless you explicitly need it.
By changing “AllowAgentForwarding” to “no”, you improve the security.
For more details, please see the sshd_config man page.
PasswordAuthentication, as the name implies, allows you to authenticate using passwords. This should be avoided whenever possible, as it exposes your servers to brute-force attacks (i.e. if there is a user with a weak password on the system, the system is likely to be breached eventually).
To mitigate this, we recommend disabling password logins entirely. Do however note that before you do this, you need to generate and install your SSH key(s) on the remote system. If not, you will lock yourself out. For more information on how to get started with OpenSSH keys, please see this article.
For more details, please see the sshd_config man page.
See this page for an up to date list.
Strictly speaking, no; you will still have access to the certificates. However, we highly recommend registering and using the Dashboard. The Dashboard provides a user friendly interface where you can easily visualize and monitor your nodes as well as seeing what security risks your nodes have and how to fix them. Additionally, the WoTT Dashboard is free to use, you just need to register with your email.
Firstly, thank you for installing the Agent and welcome to the world of security conscious IoT developers! If you need some inspiration, head to our Use Cases page. You’ll find a list of use cases and examples utilizing both our CA provided certificates and Dashboard managed credentials. We’ve included examples of some popular cloud services which you may already have projects on and how to secure them.
Yes, the WoTT Agent is licensed under the MIT License.
The WoTT Agent is written in Python 3. You will need the relevant libraries to create virtual environments, in this case venv not virtualenv. Linux by default comes with Python 2.7 installed- install pip3 using apt-get to get access to venv to create your own virtual environments; and when running applications that use WoTT Agent, use python3. Additionally any modifications you wish to make must also be in Python 3.