Home Office Server Security

[Stephen]

As for performance hit, if you have a modern processor a number of
encryption performance boots for whole disk or partial disk encryption are
now built into the processor. and as long as you stay current there you
will likely not notice a hit. i would not personally stack Raid5 and
encryption on the same array if i could help it. to me that might create
some weird latency that i would prefer to avoid. but R10 or 0+1 should be
fine.


On Tue, Apr 2, 2013 at 9:48 AM, Paul Mooring <paul at opscode.com> wrote:

> You could run some tests yourself, but due to the nature of encryption I
> strongly suspect that the overhead added by LVM is negligible.  Encryption
> is supposed to be CPU intensive, like everything else involve security
> it's a tradeoff.  The most important thing to keep in mind is that you
> don't need to care about CPU overhead, if it's lightly used getting your
> files 0.25 seconds later and averaging 60% CPU rather than 40% just
> doesn't matter.
>
> Stepping on my soapbox for a minute here, network/server security is far
> less magical than many make it out to be.  It's really up to you to
> determine how much risk is involved in something and what the costs are to
> mitigate that risk.  In your case if the server isn't heavily used so the
> CPU overhead isn't a problem, the only cost is having to put in a password
> to mount the encrypted drive.  The risk of having sensitive files makes it
> a no brainer to set this up.  Contrast that to a file server being used
> for just public files (say free exes and isos from the internet) that's
> heavily used by an office of people.  In that case setting up encryption
> is definitely more secure and also a very bad idea because the costs are
> greater than the risk.
>
> All that to say, don't pay too much attention to those numbers.  Setting
> this up is pretty straightforward and moving data off the encrypted drive
> is also pretty easy, so just set it up and if it works for you don't worry
> about trying to squeeze that last drop of performance out until you need
> to.
> --
> Paul Mooring
> Systems Engineer and Customer Advocate
>
> www.opscode.com
>
>
>
>
>
>
> On 4/2/13 9:36 AM, "Nathan England" <nathan at nmecs.com> wrote:
>
> >
> >Paul,
> >
> >Thanks for the article. Interesting. The server will be an AMD with AES
> >extensions, but I wonder how that same machine in the article would have
> >performed with a hardware raid controller verses using a software raid.
> >I know certain raid configurations are a bit faster with the software
> >raid but I would imagine this is not one of them. If the server has the
> >basic over-head of encryption on top of the over-head of managing raid
> >on top of the over-head of managing the LVM I could see a lot more CPU
> >use than if the CPU was only dealing with encryption on a hardware raid
> >without LVM.
> >
> >Nathan
> >
> >On 4/2/2013 9:11 AM, Paul Mooring wrote:
> >> Not really, encrypting data has overhead in terms of CPU:
> >>
> >> Benchmarks are generally awful as you care about real world impact (like
> >> it use to take .3 seconds now it takes .5) and benchmarks are the
> >>quickest
> >> route to getting hung up on theoretical numbers rather than worthwhile
> >> metrics.  That being said, here's one anyway:
> >>
> >> http://dentarg.it64.com/content/luks-ext4-performance
> >>
> >>
> >>
> >
> >---------------------------------------------------
> >PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
> >To subscribe, unsubscribe, or to change your mail settings:
> >http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>



-- 
A mouse trap, placed on top of your alarm clock, will prevent you from
rolling over and going back to sleep after you hit the snooze button.

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20130402/390a0cfb/attachment.html>