OctoPrint On Linux - Revisit - Multiple Instance Install - Chris's Basement:
1 Like
Hello, I don't know if this is the right place top ask but I followed the tutorial. I could make the setup for 3 instances. My only problem is that I can't connect to one of the instances by specifying the port on the address.
Here's an example:
The internal ip address of the Raspberry Pi is 192.168.X.100 and I have 3 instances with the following ports: 5000, 5001, 5002.
When I try to connect from browser to 192.168.X.100:5001 and 192.168.1.100:5002, I can connect to the corresponding instances. But I can't connect to 192.168.X.100:5000. If I write the address as 192.168.X.100, then I can connect to it. But I'm trying to connect to my octopi servers from outside of my home network. That's why I've created port forwarding rules as below for 3 of these ports:
192.168.X.100 Range: 5000 to Local: 5000 TCP
192.168.X.100 Range: 5001 to Local: 5001 TCP
192.168.X.100 Range: 5002 to Local: 5002 TCP
So when It try to connect from outside I can connect to both 5001 and 5002 ports.
myhomewanipaddresscom:5001 redirects me to the instance on the port 5001 and myhomewanipaddresscom:5002 redirects me to the instance on the port 5002. But;
myhomewanipaddresscom:5001 fails to load just like I can't connect to it locally by specifying the port as 192.168.X.100:5000
I don't know what the problem is. I don't have a firewall blocking this otherwide I wouldn't be able to connect to 192.168.X.100 (instance1) without specifying the port because I believe it's on the port 5000 but I can only connect to it without typing the port info on the address.
Any ideas what I can try?
Thank you very much in advance.
OctoPi comes with a reverse proxy set up to proxy traffic from :80 (the "no port specified in the browser port") to port 5000. It also has a rule to disallow access to port 5000 directly. This is done so you can configure the reverse proxy with eg basic authentication. If port 5000 were left accessible, that would give you a way to skip the authentication.
By the way, port forwarding to the three instances - especially with no further protection - is a really, really bad idea.
Thank you. But what would happen ? I mean there is nothing else connected to my Raspberry Pi other than 3 printers 
But if this is seriously dangereous, can you explain what could happen?
And what other protections can I use to secure this?
Someone could gain access to your printer. They could find a way to burn down your house.
The chances of the latter happening are small to very small. But not zero.
1 Like
Thank you for the warning. I fixed the problem above by changing a ling in /etc/default -> octoprint file. The local server address seemed to be 127.0.0.1 but when I checked octoprint2 and octoprint3 the address was 0.0.0.0 so I changed 127.0.0.1 to 0.0.0.0 in octoprint file and it worked. I don't know if I did correct but now I can connect to myhomeaddress:5000
What kind of security can I use here?
I linked an article above outlining many different options to secure your OctoPrint instances.
Oh yes sorry I missed that. I'll check that out.
Hey mate, I have one more question. Now that I have done my octoprint setup on 3 printers with 3 instances, I want to try the octopi camera v2 that I have. I’m going to connect this on the board but I’ll use it on just one printer for now. I need to make the setup for just one camera eventhough I have 3 printers with 3 instances.
What guide would you suggest me to follow? It’s not a USB cam and I don’t know if there is any specific thing I should pay attention on my setup. So an appropriate guide suggestion would be very appreciated.
Thanks.
If you wanted to throw some economy at this, push the webcam feature to a dedicated Pi Zero with the webcam and use it for all three printers (assuming that you only use one at a time). Then just move the camera to wherever it's needed and build a clamping case for it.
Thank you, as of today, I want to stick to my plan. I’ll think about a pi zero another time. Now I need a guide for my setup
Why? Whether three OctoPrint servers are directly reachable via three ports or through different vhosts/subdirs of a proxy makes zero difference in security, as long as each OctoPrint server is securely configured with a strong password, of course, and as long as you do not setup fancy filtering with the proxy. Firewall rules, when used, need to be duplicated, of course. However, in combination with a TCP camera, which cannot be password-protected by itself to be viewable via OctoPrint web interface, a proxy is required anyway to protect it together with OctoPrint instances via HTTP authentication.
@Ewald_Ikemann
Many thanks for the tutorial, the question just came up with one of our users. We'll see whether it still works in 2022 without too many changes 
.
It's not only the OctoPrint access, it's also the SSH access of the OS.
But SSH is not and cannot be proxied through a HTTP proxy, so this is not related and needs to be secured independently with key authentication and blocked password inputs. Whether you forward ports 5000 - 5002 or port 80 (and in case 443) does not affect SSH security, listening on port 22, in any way .
Passwords over HTTP can be sniffed out with a man in the middle attack. Forwarding only the HTTPS port to eg HAProxy and proxying that to OctoPrint helps. All of those things you mention is what I meant with "especially with no further protection". Strong passwords alone is not enough.
1 Like
Would you put a fridge on the public facing internet? Would you put a heatgun on the internet? No? Then don't put a 3d printer on the internet either. Throw it behind a VPN or the very least a reverse proxy with authentication.
I'm flattered that you trust me and the authors of the dependencies that I depend on for writing OctoPrint to not make any kind of mistakes or oversights that will allow to bypass security, and so far there has only ever been one such mistake and it was discovered & fixed by myself years ago, but when it comes to making an interface that controls a physical device that has one or more heaters capable of heating up past 200°C mounted on a movable gantry directly accessible from the internet, you really should not have this kind of trust.
4 Likes
I just recognised that one cannot enable HTTPS directly at OctoPrint, so then using a proxy (to enable HTTPS) is basically required for basic security, of course. However, the "is a really, really bad idea" statement was done together with "proxy traffic from :80" plain HTTP, so HTTPS was not the argument at that point. But HTTPS together with the camera issue and the fact that one doesn't want to rely on managing multiple individual passwords for multiple OctoPrint instances (as of this topic), makes a proxy pretty reasonable, no doubt 
.
That it usually doesn't make any sense to make accessible either a fridge or OctoPrint to www is clear, but has nothing to do with the question of whether to use a proxy and ports 80/443 or the backend ports directly, when both are accessible via VPN only anyway, which makes pretty much sense, that is true. A proxy on ports 80/443 for OctoPrint then however limits you not being able to make other web applications / websites publicly available 
.
Generally:
Whether you make your fridge available directly to www or behind a proxy doesn't make any difference, as long as both can be authentication-protected and configured to use encrypted communication protocols. A downside of the proxy is that HTTP authentication is quite weak, depending on which variant is used either weak at storing the password or weak at transmitting it, especially relevant for plain HTTP, of course. A proper backend password/token handling, which does not depend on old HTTP authentication browser support, can be much safer.
Another major downside of a proxy is that you usually make available backend servers on default ports 80/443, which are major targets for random bot logins, brute-force attacks, website scans, crawlers (allowed or unallowed), API scans and all such. On port 500x will likely never ever face such as long as you do not publish your FQDN associated with that port somewhere.
Basically what I want to say is that a proxy is not meant to enhance security, and usually does not add security but often weakens the security of backends (as long as they have authentication and HTTPS implemented themselves), adds complexity, possibly has/adds own security vulnerabilities, can be badly configured etc etc. A proxy is used for convenience, or because firewalls you do not control force you to use ports 80/443. For OctoPrint however it makes sense as of the first paragraph .
A proxy with additional security (even just HTTP Basic auth) is what I'm referring to when I say "throw a reverse proxy in front". However, what I actually said was "Throw it behind a VPN or the very least a reverse proxy with authentication" - VPN being the actual recommendation here.
OctoPi (so the image) does ship with a haproxy with a self signed cert (self signed because something else sadly ain't possible to ship with in self-hosted internal environments, https not default because scary browser warnings on self-signed certs), so if port-forwarding to 443 (from whatever port you desire btw, the source and target port really don't have to be the same), the password would not go over the line in plain text, however that still doesn't solve the issue of putting a lot of trust into OctoPrint's/Flask-Login's security. All I'm saying is, I would never throw a printer frontend on the public internet, even with access control enabled, even though I wrote OctoPrint myself. It should be fine, yes, I'm not aware of any issues. But I would still never ever directly expose a server with a direct connection to moveable heating elements to the public internet, just as I wouldn't throw my oven or a heatgun on the public internet, not even if it came with https, 2FA and an IDS.
May I refer you to shodan.io?
1 Like
That makes sense of course.
You mean that default OctoPrint port 5000 is actually a known target? Probably, which would then be a reason to use a different one in general. Of course bots can do port scanning as well, but the random internet scanning bots I was referring to mostly don't. It is fascinating how failed login attempts decreased to zero after I moved forwarded SSH port away from 22 and HTML/HTTP(S) applications away from ports 80/443, which on the other hand is not so convenient of course.
However, sorry for opening that discussion, which is really not related to this topic 
.
1 Like
I have a clean elegant solution using LXC(linux containers.)
Octoprint in a Linux Container(LXC) - Development - OctoPrint Community Forum