The particular issue didn't compromise the web server it only compromised the web application, but yes that made me look deeper into operating systems and security. I even tested FreeBSD Jails, but lets not go there.
I used OpenBSD back in the 3.x days, but eventually began using Debian because it was much easier to maintain - yes, I compromissed quality over convinience. Theo thank you for your reply. My mail was not meant in any negative way, I just didn't understand it. Having all these always-enabled-security settings of course makes a big difference! 2014-04-04 6:24 GMT+02:00 Theo de Raadt <dera...@cvs.openbsd.org>: > > On Thu, Apr 3, 2014 at 10:04 PM, Martin Braun <yellowgoldm...@gmail.com > >wrote: > > > > > As we all know on the front page of OpenBSD it says "Only two remote > holes > > > in the default install, in a heck of a long time". > > > > > > I don't understand why this is "such a big deal". > > > > > > > Because their shit don't stink? Unlike other distributions that are > > defective upon install? > > > > You cannot understand why that is not a big deal? > > https://lists.debian.org/debian-user/2014/03/msg00795.html > > On Mar 13, 2014 11:06 PM, "Martin Braun" <yellowgoldm...@gmail.com> > wrote: > > Hi > > I have recently experienced a server being "hacked" due to a security > problem with a PHP application that made it possible for the "hacker" > to gain a web shell. > > > > Software security is a tricky thing. If Martin's PHP got hacked, it > is likely he does not have a strong understanding of the underpinnings > of how holing happens. That's fine. I don't tune my engine either. > > 1) Some attacks are possible because of rather simple logic errors > in the software. > (**** everyone makes logic errors...) > > 2) Other attacks involve extremely complex mechanisms and, depend > upon memory layout conditions that can be guessed or controlled > by an attacker. This attack surface received significant attention > starting around 2001. > > (**** this is where OpenBSD's efforts have focused attention, with > tremendous effect, meaning the mitigations we trailed are now proven > enough your phones have them enabled system-wide, but your Linux boxes > do not.) > > 3) Other attack mechanisms are based on configuration errors, and > sometimes default configuration processes trick people into > those mistakes > (**** our group argues for simpler setups, shrug) > > 4) The list goes on, but the above 3 cover the most serious penetrations. > > > None of us know which particular combination of things got Martin's > environment fried. > > > I hazard a guess that he can't believe that a group exists who have > focused on this for 20 years, with such success over 10 years. > > > Obviously other software groups are better financed... > > > > Anyways, it is possible to succeed. > > The explanation is simple, we traded about 5% of application > performance for built-in ALWAYS-ENABLED security mitigations that we > found in research papers, or elsewhere, or invented ourselves. > Because machines keep getting faster, our community barely noticed the > performance loss. > > But they notice that they were not getting holed. > > That's worth praising. > > > Good god, Ubuntu says you can "Start, drag, drop, deploy, done!" > Unbelievable, how pathetic a claim. You go get 'em, Martin...
