Secure your printers before it's too late.

Phaedrux

This is also a good time to mention this thread.

https://forum.duet3d.com/topic/5851/duetwifi-dwc-encryption-using-rasberry-pi-zero-w-as-proxy-server

Another good solution to the problem, if you must open access to the Duet to the internet.

Personally, I consider anything capable of controlling pinch points, shock and burn hazards, and switching of mains voltage to be industrial equipment and should be air gapped from the internet.

Jacotheron

@Phaedrux while the method explained in the thread encrypts the data leaving the computer, it does not really provide a safeguard - the Duet still operates in plain text. This method was simply made to stop the browser nagging about the unencrypted site asking for a password (something that will soon become even worse). It may protect a little bit if someone is monitoring the traffic in and out of your computer (something like WireShark does), but if they can monitor your traffic, they might be able to monitor other devices as well and then see the plain text. Also, since the security certificate is self signed, it is even less secure (basically only good enough that the browsers accept it to stop the nagging).

I agree that 3D printers and similar machines should not be accessible through the Internet - simply way too much that can go wrong when a hacker gains access and following the rule "anything on the Internet is accessible to hackers" simply means that I try to keep everything away from the Internet as far as I can.

Danal

@mrehorstdmd said in Secure your printers before it's too late.:

I may be wrong (it's happened once or twice before) but VPN encrypts the traffic coming from the device running a VPN client, such as your laptop, to the VPN servers, which keeps your ISP from knowing what you are doing, but on your own network, if the Duet board doesn't run a VPN client that can talk to the VPN client in your computer, it won't understand anything the computer is saying to it. Maybe I misunderstand VPN and maybe someone with more expertise can comment.

When people say VPN in this context, they mean:

(computer on internet, running VPN client) >>>>>>>>Internet>>>>>>>>Your Home>>>("reverse proxy" VPN server in your home)>home LAN/WiFi>Printer

You are correct. The VPN in such a setup protects the traffic on the internet. It is assumed that your home network is physically secure (and the WiFi segment of your home network is protected by WPA2 or better).

SupraGuy

Honestly, I'd have felt much better about the Duet Ethernet, but the Wifi model was/is significantly less expensive.

I have WPA2 on my wireless of course, plus my access point has to have the MAC address verified over a wired line before it will grant any network access. Still, MAC addresses can be spoofed easily enough, so if someone were targeting my home, they could probably find a way to get my phone's MAC address and spoof that, then I suppose that anything that accesses the wireless can also get to the wired network, but I still heavily prefer wired access whenever possible.

RCarlyle

Nobody is wardriving around neighborhoods with a big wifi antenna looking for crackable WPA2 routers just in case they have 3d printers hooked up to them that can be used for high-tech arson.

What's a lot more likely is an overseas hacking group probing your router ports for unsecured net-connected devices that they can 1) screw around with for fun, like open webcams, or 2) take over to add to a botnet for DDoS or cryptocurrency mining purposes.

The other concerning scenario is places like school networks where bored and ethically-challenged kids have time and interest to try to burn the building down when they already know there is a printer present.

One thing that does bug me about the RRF approach to configuration is that temp caps and PWM limits can be changed remotely. I know the first defense is securing access to devices, but I wonder if we should have some commands or files that DWC can't easily override remotely? I'm imagining a "duet_security.g" file that can only be accessed on the physical SD card (invisible to DWC) and contains secure setup Mcodes and a blacklist of Mcodes that will be ignored outside of startup.

dc42

@rcarlyle said in Secure your printers before it's too late.:

I'm imagining a "duet_security.g" file that can only be accessed on the physical SD card (invisible to DWC) and contains secure setup Mcodes and a blacklist of Mcodes that will be ignored outside of startup.

An attacker could still edit config.g and then send M999 to reboot the machine, so I don't think that would help much. Also, an attacker prepared to hack their own firmware could install is and program the machine to do anything that it is physically capable of doing.

We did consider using a file on the SD card to hold network SSIDs and passwords, and making that file inaccessible over the network.

RCarlyle

@dc42 What I would propose for a security.g file:

Cannot be read or updated over the network
Runs before config.g at startup/reboot if present
Commands run within security.g (or perhaps put in a new command-disable mcode that only works within security.g) are blacklisted and become non-functional in config.g, DWC gcode console, etc
A firmware update password (or disable) can be set within security.g that will prevent unauthorized DWC users from running firmware updates

I don't know how much work this would be to implement, maybe more than you want to put into it, but I think shared-network and safety-sensitive environments like schools and offices could benefit a lot from the ability to lock out specific functionality, prevent overriding temperature caps, etc.

Yes, anything can be hacked, but we're not trying to keep the CIA or FSB out of this, are we? Just blocking bored teenagers from burning their school down would be of value.

dc42

@rcarlyle, your suggestion could certainly be implemented. The question is, would it provide enough additional security to be worthwhile. Let's see what others think.

NoSkillzEngineer

I've thought about this topic quite a bit, especially considering I'd like to be able to control my printer from anywhere else in the world. One of the easiest ways I could think of is a simple login required for the Duet Web Control...Perhaps with two factor authentication?

There is one interesting new thing that would be the latest and greatest form of security. Anyone ever see "Catch Me If You Can" the movie about Frank William Abagnale Jr?

Frank William Abagnale Jr. is an American security consultant known for his history as a former con man, check forger, and impostor between the ages of 15 and 21 years old. Pan American World Airways, Panam, estimates that between the ages of 16 & 18 Frank flew more than a million miles for free, boarded more than 260 commercial aircraft in more than 26 countries around the world. Panam said, "keep in mind the fact that Frank Abagnale did in fact pose as one of our pilots for a long period of time, he never once stepped on board one of our aircraft."

And that was just until he was was 18!

A fascinating video here if you're interested to learn more: https://youtu.be/vsMydMDi3rI

Why is this important? Well, in the video I linked above after he talks about his life, he talks about his job at the FBI, I highly suggest the video, it's great, it really is. He mentions this: https://www.trusona.com/

With another link here: https://www.trusona.com/faq/

Now, to explain why I post this, I am working on something where I will integrate this into the UI of every app I create. If this can be implemented into a 32 bit system, fantastic. If not, well, don't worry, this would be what I implement into it in order to interact with it and authentication will "expire" and be required a little more often than every user may want, however, is worth the little bit of a minor inconvenience to have that peace of mind, no?

Two factor authentication [alone] is supposed to put you into the top 5% of technology users as far as security goes, yes really....how sad is that? this is supposed to be in a whole nother level. Developed with the help of Frank Abagnale, who consulted on the project directly.

The app requires biometric scanning to enter the app, is it impenetrable? No, but the majority of security (in all seriousness) is making it more difficult than another target. Car alarms alone have pretty irradiated vehicle theft, at least that I'm aware of.

I don't fear access to the internet, I fear unfiltered, unmonitored, unrestricted, blind access to the internet. A login in my opinion is probably sufficient, two factor authentication is supposed to put you in the top 5% or so, and Trusona would just be overkill but....in all seriousness, I believe that anything in life....worth doing at all...is worth overdoing. Best part is....it's free. So...I'm sold.

Demo here: https://youtu.be/1YyLmi2ia2g

I haven't worked out every detail but it's what I intend to use my project that's in the works.

T3P3Tony

I still highly recommend not putting a Duet on the internet. it is not an "IOT" device and not designed to be exposed outside of your home network. If you are at a university or other site with a large "intranet" i would also avoid putting a Duet on that sort of network.

As others have said - if you must connect to the duet outside of the local network then use a correctly setup VPN. That effectively puts your remote device onto the local network in a secure manner.

While adding more security to the Duet as we go on is a good idea i still don't think it will get to the point that this advice changes.

Danal

I agree with @T3P3Tony the device (in this case printer) should NOT be secured, instead, the network segment on which IOT devices run SHOULD be secured, and reachable only by a (secured) "reverse proxy" or "jump host" or "Firewall" or "VPN" or whatever you call it. Let the good guys on that segment; keep the bad guys off that segment, AT THE BOUNDARY OF THE SEGMENT, not at the IOT device.

Why?

Because security in our current software/processor/service architectures is INCREDIBLY difficult. Honestly, I'd never trust any given device/program that was not a specialized security device/program which is in very common use and has been hammered and debugged and pen-tested very thoroughly.

As such, I'd STILL insist on having any given IOT device on a secure segment, with a secure proxy/firewall/VPN into that segment.

Therefore, I'd much rather see the limited time/energy of the developers for the IOT device go toward that device's actual function, and not toward security that ultimately can NEVER mean "run that IOT device unprotected".

Does that chain of logic make sense?

tinkerz

@phaedrux Do you mind if I share pic on social media?

Phaedrux

@tinkerz go right ahead. I found it on Reddit myself.

Jacotheron

Just my opinion with regards to the state of security on the Duet:

For newer hardware, I would highly suggest having the HTTPS capability built-in (even if it simply uses a self-signed certificate that the user would need to create to use it - maybe have a tutorial on how to do it). The only real reason why I am asking for this is simply to stop browsers nagging about passwords entered. Currently I run a RaspberryPi Zero W for primarily this reason (explained in another thread linked to above).
Layered Security (should be optional). If we take a look at Operating Systems, CPUs and other things, security is layered, like an onion. On the outside you have very little abilities (can for example be an unauthenticated user only be able to monitor the machine, but not interact in any other way). Then you have the standard authenticated user, which can start/stop prints, upload gcode and run standard macros (the stuff you normally need to run a print; this can for example be used to give specific people access to use the machine, but not re-configure the machine). as the 3rd layer, perhaps the one that a PanelDue runs (it can't reconfigure, but have more gcodes that may be used as it is physical access; perhaps allow the M999 command, but since you can't upload the file via a PanelDue it should be safe). Finally we reach the center most layer, which allows the person to configure the machine (update firmware etc; as well as change the passwords). I think having the gcode be able to restrict, based on a blacklist file perhaps, what gcodes (maybe even with the attributes) may be run as a normal user*.

*- this part may need changing in the gcode handling, and the Duet Will need to figure out where the command came from (gcode print file, PanelDue and DWC [in this case also the user level of the user]).

I think that the same Gcode used to set a password for the machine, can perhaps be extended to have the optional attributes: Admin Password (text) and Allow Unauthenticated Monitoring (boleen). If the Admin Password is not supplied, the same password is used for both and a user logged in is running in Admin mode (giving the same options as they currently have; also since the blacklist file is empty everything should work as it currently is). If the Allow Unauthenticated Monitoring is true, a login using the default password on DWC (which is sent when connecting), will still load the interface, but in read only mode.

This, I think, will allow schools, universities and other places to give restricted access to specific people (able to print), while ensuring that they can't do a lot of harm (configuring the machine). For anyone happy with the way it currently is, this would not change that (as default will continue working as it currently is).

I believe that more security than this, is not required for the printer itself. It is everyone's responsibility to use network infrastructure that is secure and which will prevent remote access from outside of the local network. A while back I looked at videos from hackers at the BlackHat convention and yes, they were able to hack into and root practically all of the devices they found (brand new smart devices from common brands), they were only in a few very special cases able to gain remote access to these devices - all of the rest was simply having physical access (from a security perspective, if someone have physical access to your device, you have a lot more issues than them simply hacking your device).

Danal

@dc42 said in Secure your printers before it's too late.: (bolding mine):

@rcarlyle, your suggestion could certainly be implemented. The question is, would it provide enough additional security to be worthwhile. Let's see what others think.

Additional security, such as network segment control via VPN or reverse proxy or similar, will always be needed no matter what security features are added to Duet/RepRap. Several people seem to be saying things that fit with this broad idea... layered security, don't put it directly on the Internet, etc.

Therefore, I'd like the see the number of hours devoted to adding security features to Duet/RepRap be relatively small.