Jean-Francois wrote: > Hi All, > > My question is in two parts. > > First considering the default install, assuming that one box should be > only used for exapample as a firewall, how good is the security level ?
what kind of rating system are you looking for? My answer is, "better than anything else", but even that would require massive amounts of qualifications. Compared to a machine that is off? (what if the machine has Wake On LAN active, and someone manages to throw the right magic packet at it to wake it up to an insecure config?) Compared to a machine which can't run an IP-aware OS? (but then, what use is it in this discussion?). > I mean I know there are only 2 remote holes in 10 years, but my qustion > is do we have any experience about the level of security such as studies > that demonstrated the failure to break into the default system for > example ? or any other experience in regards with that ? and these would relate to you..how? Those kinds of "studies" get people various advanced degrees, but don't tend to relate to the real world any better than the seekers of those degrees. > On the other side, now if we assume that one box should be used to host > a website, there are ways that the code such as php + mysql will be > breakable into. My question is that considering the chroot, can we > consider that the supposed hacker can never evade from the chroot by any > mean, even after he will be able to upload and execute files directly on > the web server ? that would be a foolish assumption, even if a "known way" doesn't exist. Using OpenBSD does not excuse you from good design practices, including minimizing the amount of data exposed should there be a security breach. For example: if you were building an order processing system, you would probably want to "unload" user data from the web-exposed machines ASAP, rather than letting it accumulate, so if there is a breach on this machine, only an hour's or a day's worth of users have had their data potentially compromised, rather than every customer of the last five years. Of course, the unloading process has to not introduce additional exposures. Get too fancy, you can create bigger problems than you solve. Note well that executing files directly on the webserver is ONLY ONE risk. Many others exist. For example, administrators who refuses to do basic research, but rather resorts to posting basic questions on public mail lists rather than reading documentation or hiring a qualified administrator opens themselves to "social engineering" exploits which no OS can protect them from. Nick.
