Write out FAQ entries for recommended actions

[vpetersson]

Here are the recommended actions that we currently have in our system:

• Default credentials detected. We found default credentials present on {devices}. Please consider changing them as soon as possible. Rework Default credentials detected #200
• Consider moving to SFTP. There appears to be an FTP server running on {devices}. FTP is generally considered insecure as the credentials are sent unencrypted over the internet. Consider switching to an encrypted service, such as SFTP. Rework Recommended Action for SFTP #199
• Permissive firewall policy detected. We found permissive firewall policy present on {devices}. Please consider change it to more restrictive one. Permissive firewall policy detected  #203
• Insecure services found. We found insecure services installed on {devices}. Because these services are considered insecure, it is recommended that you uninstall them. Run sudo apt-get purge {services}to disable all insecure services. Insecure services found #205
• Insecure configuration for OpenSSH found. We found insecure configuration issues with OpenSSH on {devices}. To improve the security posture of your node, please consider making the following changes: {changes}. UPDATE: Requires three different ones as per Insecure configuration for OpenSSH found #206.
• Consider enable automatic security updates. We found that {devices} are not configured to automatically install security updates. Consider enabling this feature. Details for how to do this can be found here: {doc_url}. Consider enable automatic security updates #207
• Your MongoDB instance may be publicly accessible. We detected that a MongoDB instance on {devices} may be accessible remotely. Consider either blocking port 27017 through the WoTT firewall management tool, or re-configure MongoDB to only listen on localhost. Your MongoDB instance may be publicly accessible #208
• Your MySQL instance may be publicly accessible. We detected that a MySQL instance on {devices} may be accessible remotely. Consider either blocking port 3306 through the WoTT firewall management tool, or re-configure MySQL to only listen on localhost. Your MySQL instance may be publicly accessible #209
• No root password set for the MySQL/MariaDB server. We detected that there is no root password set for MySQL/MariaDB on {devices}. Not having a root password set makes it easy for anyone with access to the service to copy all information from the database. It is recommended that you change the password as soon as possible. There are multiple ways to do this, including using mysqladmin as follows: mysqladmin -u root password NEWPASSWORD. Tip: If you are using mysqladmin as per above, make sure to add a space before the command to avoid it being stored in your shell's history. No root password set for the MySQL/MariaDB server #210
• Your Memcached instance may be publicly accessible. We detected that a Memcached instance on {devices} may be accessible remotely. Consider either blocking port 11211 through the WoTT firewall management tool, or re-configure Memcached to only listen on localhost. Your Memcached instance may be publicly accessible #211
• Your system is vulnerable to Meltdown and/or Spectre attacks. We detected that {devices} is vulnerable to Meltdown/Spectre. You can learn more about these issues here. To fix the issue, please run apt-get update && apt-get upgrade. Your system is vulnerable to Meltdown and/or Spectre attacks #212
• Your Redis instance may be publicly accessible. We detected that a {service} instance on {devices} may be accessible remotely. Consider either blocking port {port} through the WoTT firewall management tool, or re-configure {service} to only listen on localhost. Your Redis instance may be publicly accessible. #214
• Enroll your node(s) to unlock this feature [RA] Enroll your node(s) to unlock this feature  #220
• Enable our GitHub integration for improved workflow [RA] Enable our GitHub integration for improved workflow  #221

For each of these, we need to write out a corresponding FAQ entry. These entries need to be 3-5 paragraphs that gives the user some background to the problem and why it is important.

The idea is to then embed the corresponding FAQ entry into the dashboard. However, we do want to keep this in the FAQ due to SEO benefits.

[AlEsmail]

@vpetersson Should this also include more elaborate tutorials on how to remediate?

[vpetersson]

That's not applicable to all of them, but where applicable, we should probably do that in a blog post instead.

[vpetersson]

I'm turning this issue into a "parent issue" instead and will be distributing the work.

For context, content for three places to keep in mind:

• Within the dashboard (let's call this the 'tl;dr version')
• FAQ (let's call this the 'faq version')
  • This version will be embedded within the dashboard under a 'learn more' button and be rendered within a popover
• The GitHub Issue (let's call this the 'github version'
• Optional: A fully fleshed out tutorial (let's call this the 'tutorial version')

Considerations for the versions

For each of these we need to define:

• The title
• The body
• Where to find out more info (if applicable)
• It's perfectly fine to include links to additional (non WoTT) references

Be mindful that all of these can include variables, such as package names etc. Also, note that we should strive to make this understandable for users without too deep technical knowledge.

Use Markdown for all content.

tl;dr version

This part needs to be very short. It should be a quick tl;dr and explain what the issue is that we discovered and provide the solution (such as the command).

This should be a paragraph as a description, and then a command block below it.

Faq version

This is a more elaborate version of the previous one. We would normally assume that the person has read the tl;dr version when reading this.

In this version, you need to expand on the problem and properly explain why this is an issue with supporting facts (such as attack vectors).

This should be 3-6 paragraphs (use your best judgment). Keep in mind that most users will read this in a popover within the dashboard.

Github version

The Github version is likely going to be similar to the Faq version. We need to provide enough backstory here, because this will be read independently by users who may not have seen the WoTT Dashboard.

It's perfectly fine (and probably preferable) to include a link to the FAQ entry (or tutorial) in here.

Tutorial version

This is not applicable to all of the recommended actions. Where this is relevant is if it is something that is worth exploring in depth that we can write an entire blog post about.

[vpetersson]

@a-martynovich Are we not missing Redis in this list btw?

[fshmcallister]

Am I still working on this? I'm a little lost :'(

[vpetersson]

@fshmcallister This is a big task, so I've broken it out into sections. Let me create a sub-task for you.

[a-martynovich]

@vpetersson

Are we not missing Redis in this list btw?

There never was a task regarding Redis. Hence it's not in the list.

[vpetersson]

There never was a task regarding Redis. Hence it's not in the list.

Ok, I'll add it in.

[fshmcallister]

I have created a set of issues based off each article after talking to Al. I can't add labels or assignments but am going to try tackle all of these except #206 #208 #209 #210 which @Menmarin can do.
Each block needs:

• Title
• Title grey text(?) as per image: https://user-images.githubusercontent.com/357664/71345830-abf3e080-2566-11ea-8815-1b0c477045bd.jpeg
• TL;DR
• FAQ

Comment directly in issue for @vpetersson to review afterwards. I will leave options within the issues to consider

[AlEsmail]

@fshmcallister For the titles, can you implement some consistency? Are we going to give them an action (e.g. Enable updates) or a vulnerability (e.g. Insecure OpenSSH configuration).

Secondly, remove the extra words - e.g. your and found

Perhaps the Title could be the vulnerability and the 'Grey Title' can be the 'brief' action.

You make the call, but be consistent.

[fshmcallister]

These are just placeholders based off the context of the parent issue to make things a bit quicker to do. I personally think that exposing a vulnerability is a nicer option, thoughts?

The issues as they are are not the working titles - they're just there to work off of. All the 'new stuff' will be commented

[AlEsmail]

I like the idea of the 'action' being the title but I think this might get difficult depending on what it is. Let's go with vulnerability as you suggest.

[fshmcallister]

Suggestion for scaleability:

As WoTT is going to be implemented on large fleets of devices for some companies, perhaps group an issue by type that can be expanded once the number of affected devices exceeds a number, say 10.

In the image, you see a note that says 'Affected nodes' followed by a list. Perhaps have an implementation of:
'Node 1', 'Node 2', 'Node 3', and others
Whereupon clicking 'others' would expand a list of affected nodes

[AlEsmail]

Good idea - put this in slack in the design chat and tag alex capellan