On Sun, Mar 2, 2014 at 10:42 AM, Michael Haberler <mai...@mah.priv.at>wrote:
> > > > 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. > Those "pretty old existing" worms are still valid concerns to this day. Day after day we hear on the news of some big company's web server being hacked, and personal identity and financial information being stolen. Security issues ain't gonna go away any time soon, at least until someone actually comes up with a bullet proof server. Course, the black hats will just come up with a new kind of bullet. When my controller is running, the machine is not connected to any network. It's strictly a machine controller. I only turn networking on when I want to check for updates, at which time, LinuxCNC is not running. All my necessary network services are wrapped with TCP Wrappers, anything else is disabled. Why run unnecessary services, both from an overhead and security standpoint? A web server is, and always will be a security issue. Apache makes a good run at being secure, but there are plenty of patches put out almost every month fixing security flaws. Locking down my web servers, running wrappers, and running security scripts is the level of comfort I'm willing to deal with for a machine that runs strictly as a web server. Just because you are using strong encryption and encrypted authentication, does not mean your network server is secure. That connection that is properly presented, authenticated and accepted may be, but there's tons of ways to break into a port that is used for that encrypted communication. Nothing is perfect, and the folks that are good at what they do, can, and will find a way into your system. I'd rather limit their opportunity for doing that, rather than open up ways for them to do it. > > > 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. > Which protocol does it use? NFS? HTTP/HTTPS? rcp? ssh? If it's HTTP/HTTPS it's a web server. NFS has it's own problems, as does rcp, ssh, or any other network protocol. Sure, you can open an html file in your browser, but that's static content. The minute you introduce dynamic content, you need some kind of server that will update that page, unless you are manually hitting the update button, which kinda ruins the idea of dynamic content. Something has to push that dynamic content to your browser in order for it to be truly dynamic. > > > 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. > It's not an architectural discussion. Its an application, and inherent security, or lack of security discussion. Never said linuxcnc is safe in an adverse networking environment, nor that it is currently being made unsafe by you. You and I may be used to working with and making servers secure. How many folks out there in LinuxCNC land work daily with security issues, and manage and administer network servers in a plausibly hostile environment? I have secured my machine controller using best practices from both DoD (for which I work) and civilian arenas. I've shut down ports and disabled services that are unnecessary to the controller's operation. I've secured my home network as well, using the same kinds of things. My question to you is, how many LinuxCNC users out there are willing to, and have the knowledge base and experience to do the same? Please don't take this the wrong way. You can, obviously, do as you please with your machines and your network. Just as I will do with mine. Never said "you" should abandon your work. All I said were my druthers. I have no need to put a relatively non-secure http/https server on my machine control, and possibly open the machine up to security issues, based on my experiences running, maintaining and administering network servers, including web (http/https) servers for more than 20 years. > - Michael > Cheers, 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
