Why is it unsafe to open Octoprint to the internet?

I just installed external access to my Octoprint from the web. No I get a big fat red warning when I log into the server :wink:

Why is this dangerous? Is the username/password protection of Octoprint not safe?

You can get some decent information on that topic in this blog:

It's not that potential hackers can get into your OctoPrint installation, also they can corrupt your Raspberry Pi and enter your home network via that gate.

1 Like

I actually found that guide before. But I was not sure if these are these just theoretical issues, or if there are actually known security problems in OctoPi or the Octoprint webserver?

Have there been any reports of Octoprint devices being hacked via the web interface so far?

1 Like

They are just theoretical issues and I don't have any reports of hacked (secured) devices.

However, I would sleep better at night if more people followed this advice :wink: Also, even if you don't get hacked, making your pi accessible from the net makes it susceptible to denial of service by simple attempts to hack something or just curious script kiddies. You don't want to get a print ruined by 200 people concurrently spamming your server with (denied) requests simply because the poor Pi runs out of resources.

1 Like

Well, you had that one (almost hilarious) report...

1 Like

Make that "substantial reports" then :wink:


I have a Synology DiskStation as a reverse proxy in front of my Pi. It has a DoS protection feature that will hopefully block this kind of attack.

But of course nothing is 100% secure. Maybe I'll use the Telegram plugin for Octoprint instead. On the other hand I have so many other services running (Gitea, Drive, Moments, CalDAV, CardDAV, Mail, Grafana, Murmur etc. etc.), that one more won't make much of a difference :wink:

Please don't put your OctoPrint on the Internet. It's just a bad idea.

  • Your printer is presumably something which you want to protect, it cost you money to purchase and to set it up
  • You could arrive home to see that someone has done something malicious like extruding an entire spool of filament
  • You could arrive home to find that your hotend has drilled into your print bed
  • Many people have webcams so that could potentially be vulnerable, too
  • There are people who script things to look for open ports and then add them to a report which sells others this information
1 Like

Don't see much response on this. But if you are protecting it with a basic username/password auth, basically anyone on the Internet can sit and try to guess your username and password. Endlessly. With a script.

"Oh, but I used a port other than 80".

Yeahhh, that doesn't help much.

Thats what the account system is for, isn't it? To limit access to all that functionality to people with valid credentials?

I don't think that any sane user account system allows endless login retries. Is Octoprintany different in that aspect? I would assume after a couple of failed attempts the IP or the whole login system would be blocked for a few seconds (which would make brute force attacks impossible).
How does Octoprint handle this?

That's nontrivial, you need to maintain a lot of state, have a way to handle locked accounts, and so on. Considering it feels like half the community is on a Zero and/or doesn't use even basic auth, that's a bit of an ask.

With one modern exception the standard practice in modern IT is to leave private systems off the routable public Internet or put other controls in place, most commonly a VPN with tight controls.

1 Like

Maybe a simple solution would suffice: if the Octoprint server would enforce a 3 second timeout after a failed login attempt, this would effectively block brute force attacks.

Where will this timeout go? On the http response? I'll just set my hax0r script to time out after 300msec, because a success will be shorter. I can still have plenty of concurrent connections.

Putting it on the IP via iptables? Back to maintaining state, as well as deeper OS integration than Octoprint's core was designed for.

Blocking for seconds doesn't help.
You get IP addresses for so little money


@VanKurt I wished we lived in a world where I could create a new server at Linode.com, push a website design to it, start it up and then NOT have to then begin the arduous task of editing IP tables, .htaccess, watching the immediate attempts at hacking and to see what they're trying. It's like some sort of futuristic comedy movie in which someone buys a house and then the real estate agent hands the new buyer their flak jacket as the random drive-by shootings start up before the ink has yet dried on their paperwork. It's seriously that bad. Within about three minutes of opening your IP address to port 80 (or anything honestly) it's being tested by scripted computers out there. And once any response at all is returned from port 80 you're now on their list for the full monty, so-to-speak.

Now imagine that you're on the other end of those scripts. You're the person who wrote the 1st-level script that looks for webservers. You then get your report of what kind of webservers responded by type. "This one says OctoPrint... oh look, that's open-source!" so now you go read the actual source code, see what Python modules are used, what OctoPi is, what goes into that image. If you're into that, it makes it a fun game to play and you're the target of that "fun".

So now, search the forum for the safe ways of doing this.


For anyone interested in this thread, here is a prime example of what I am talking about. The person punched a hole in their firewall to expose their security system and guess what? Now they're the victim of a DDOS (distributed denial-of-service) attack on their external router. Now their OctoPrint instance keeps dropping off their overworked router.

"...in case your next question is why ddos, i have a port exposed for remote access to my security system and that port gets pounded thousands of times a day."

not exactly. The automated pings and port scanning has always been there, and the asus protection package included with this router sheds all of the connect attempts. it is just that for this asus router there is a bug that causes it to go non-responsive after a several days of this. And while on trips it was causing me to lose connection to my alarm system and my thermostat. as well as losing the ability to remote into my computers.

if you only knew how many thousands of these pings occur to every ip in the world you would not be shocked at how many real exposed vulnerabilities are exploited in this world

I got my start as an I.T. guy seven days after the IBM PC came out. I once owned and operated my own datacenter in NORCAL. Trust me, I know.

1 Like

That is rather easy to fix. I have a reverse proxy in place, which blocks DOS attacks. So the Octoprint webserver should not get hit by those.

In this case, I don't believe it was that his-Pi-was-getting-slammed, it was more like his-firewall-was-getting-slammed. In many cases of rapid-fire incoming traffic, some firewalls just choke after a few hours and eventually crash. In the meantime, they're too busy to respond to standard internal traffic to be useful.

1 Like