> > In my other recent reply I mentioned my security concerns. These small, > light weight web servers just don't seem to have much security built into
Ah, the great security debate ;) that opens a rich subject for exchange. You're opening a can of worms - with some pretty old existing worms, that is. please understand that I am not engaging bow-by-blow as long as compiled-in cleartext passwords, binding to 0.0.0.0 and cleartext TCP connections are the norm in LinuxCNC, along with a command enabling any user to build and load arbitrary kernel code, and that isnt even checked against a, say, group permission. And I have not even started to consider the number of unpatched kernel bugs - including networking - which have been uncovered and are being exploited since 2.6.32, and which affect probably 90%+ of the installed base nowadays. suffice it to say for the status quo: anybody running LinuxCNC with unfiltered inbound public Internet reachability is "ill advised", to put it politely. I can however comment how I adress encryption and authentication in the work in the stuff I am working on. It's not all there yet, but it will, and it is clear how it will. As planned, all connections types (websockets as well as zeroMQ) should eventually support strong encryption and authentication as (separate) options. The aforementioned websockets+http gateway supports certificate-based authentication and SSL if you need to secure this AND you enable the service AND you make it run explicitly on a different interface than 127.0.0.1. As for the rest of the middleware stack: this uses zeroMQ, and the latter already supports strong authentication and encryption based on libsodium (google for curveCP and zeroMQ). I did not integrate this yet as the API is still a bit in flux, but I will as it shakes out, but such that both of encryption and authentication are optional. For the relative merits of perfect forward secrecy in sodium, and how that relates in strength to say SSL, you will find lots of material at the libsodium and zeromq sites. > them. Yes, SSL is a good thing, but that only encrypts "that" single data > stream, while not really securing the server itself. Even full-blown web > servers running Apache can be broken into if they aren't configured > correctly, and that previous link that was posted for that small python web > server didn't leave me with a good basis for presuming the web server was > secure, or could easily be made so by the user. > > I'm just not thrilled with the idea of running a web server on a machine I think I was pretty clear: you have the _option_ to enable a server which serves _files_ from under a single directory and nothing else. Not sure this qualifies as 'web server'. You can load html locally from the filesystem if you think TCP connections are a bad idea to start with, but if this is so: warning - disconcerting material ahead in the next paragraph. > that's controlling a big hunk of heavy, fast moving metal that can do > damage (and lots of it) by someone on the outside with mischief or > malicious intent on their mind. Once somebody's in your network, and if > they've gotten that far there's a decent chance they can get on your > controller machine, who's to say they couldn't wreak havoc with an unsecure > web server which is one of the easiest things to hack into? > I'm not sure where you get the idea from that linuxcnc is safe now in an adverse networking environment, and is currently being made unsafe by me. That idea needs a bit of a reality check. You should not be thrilled by running linuxcncsrv with default passwords and TCP sockets enabled on a machine either. But I am sure you turned that port off on your public-facing machine, or not? If not, try yourself: leave linuxcnc running, leave port 5005 inbound open, drive home, move your machine from home, share results here. Please report if you needed to use a specific password. So as long as 'netstat -an|grep 5005' shows this while linuxcnc is running, lets keep things a bit in perspective: tcp 0 0 0.0.0.0:5005 0.0.0.0:* LISTEN ------------------^^^^^^^^^^^^^^ here we go, something for your iptables As for your break-in fears, a) see above b) note all services bind to 127.0.0.1 unless enabled otherwise (other than this linuxcncsrv whiz-bang piece of hard-headed security engineering, in review for a mere decade or so, which straight out binds to 0.0.0.0, I guess for "better reachability"). > I ain't buying the idea that it's a good thing to introduce into this kind > of environment. For security and safety reasons. As for an architectural discussion: I am sorry, but I will not abandon the work towards web-based UI support based on your argument, but you are certainly free not to use the result since this is optional anyway. Other than that, I am all ears for qualified arguments as to how improve things, both the status quo and what I work on. - Michael > > Mark > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
