<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I'm not trying to start an argument about this.  I'm just really
    interested in how IT infrastructure gets hacked.  Here's an example
    of a real life hack that has had very serious repercussions for a
    firm and its clients.<br>
    <br>
<a class="moz-txt-link-freetext" href="http://www.techrepublic.com/article/no-1-thing-it-departments-can-learn-from-the-panama-papers-hack/">http://www.techrepublic.com/article/no-1-thing-it-departments-can-learn-from-the-panama-papers-hack/</a><br>
    <br>
    Mossack Fonseca seems to have not taken security very seriously,
    although privacy should have been a huge issue for them.<br>
    <br>
    Another example of a serious data theft I heard about was a
    financial services firm keeping backups for their wealthy clients in
    a private home safe.  It seems reasonable on the surface, but
    thieves broke into the home and the first thing they took was the
    safe.  The thieves probably chucked the most valuable item in the
    safe, the data, and went for currency or gold/jewels, etc.  Not all
    thieves are that stupid, though.  Physically securing data is one
    place where local, private storage will never be able to compete
    with 24/7 patrolled clouds in terms of privacy.<br>
    <br>
    Thanks,<br>
    <br>
    Omar<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 4/16/2016 7:03 AM, Omar Eljumaily
      wrote:<br>
    </div>
    <blockquote cite="mid:57124619.7030806@omnicode.com" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      <div class="moz-cite-prefix">I've never heard of a server side
        cloud encryption hack.  Maybe you can give some examples.<br>
        <br>
        <br>
        On 4/16/2016 6:33 AM, Aaron Grattafiori wrote:<br>
      </div>
      <blockquote
cite="mid:CAFNk+g76BEy3iu=rYi3MmtK8ed-KD2Wh0UgyDkY2NiWJM7YoPQ@mail.gmail.com"
        type="cite">
        <p dir="ltr">Server side encryption isn't really a secure
          solution for most threat models, including typical cloud
          backup scenarios.</p>
        <p dir="ltr">Client side encryption is a better option, via
          something like duplicity, although you then have to remember
          to backup the (strongly password protected) encryption key
          somewhere. </p>
        <p dir="ltr">-Aaron</p>
        <div class="gmail_quote">On Apr 16, 2016 7:25 AM, "Omar
          Eljumaily" <<a moz-do-not-send="true"
            href="mailto:omar@omnicode.com">omar@omnicode.com</a>>
          wrote:<br type="attribution">
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">
              <div>Amazon seems to offer encryption through a setting. 
                That may be easier than what you're attempting.<br>
                <a moz-do-not-send="true"
href="https://aws.amazon.com/blogs/aws/new-amazon-s3-server-side-encryption/"
                  target="_blank">https://aws.amazon.com/blogs/aws/new-amazon-s3-server-side-encryption/</a><br>
                <br>
                I use Google cloud, and they encrypt as a standard
                feature. <br>
                <a moz-do-not-send="true"
href="https://cloud.google.com/storage/docs/gsutil/addlhelp/SecurityandPrivacyConsiderations#encryption-at-rest"
                  target="_blank">https://cloud.google.com/storage/docs/gsutil/addlhelp/SecurityandPrivacyConsiderations#encryption-at-rest</a><br>
                <br>
                All Google Cloud Storage data are stored encrypted. For
                more information see <a moz-do-not-send="true"
href="https://cloud.google.com/storage/docs/concepts-techniques#encryption"
                  target="_blank">Server-Side Encryption</a>.
                <div>
                  <p>You can also provide your own encryption keys. For
                    more information, see <a moz-do-not-send="true"
href="https://cloud.google.com/storage/docs/gsutil/addlhelp/SecurityandPrivacyConsiderations#id1"
                      target="_blank"><span>``</span></a>gsutil help
                    encryption
                    </storage/docs/gsutil/addlhelp/SupplyingYourOwnEncryptionKeys>`_`.</p>
                </div>
                <br>
                On 4/15/2016 7:35 PM, <a moz-do-not-send="true"
                  href="mailto:gandalf@sonic.net" target="_blank">gandalf@sonic.net</a>
                wrote:<br>
              </div>
              <blockquote type="cite">Hey, thanks. This looks real good.
                I'll start digging into it next week. I have even found
                a elaborate setup script just for Amazon. <br>
                <br>
                On 2016-04-15 19:14, Aaron Grattafiori wrote: <br>
                <blockquote type="cite">Checkout duplicity... <br>
                  On Apr 15, 2016 8:13 PM, <a moz-do-not-send="true"
                    href="mailto:gandalf@sonic.net" target="_blank"><gandalf@sonic.net></a>
                  wrote: <br>
                  <br>
                  <blockquote type="cite">Well I just got something
                    working and am setting it up to work over <br>
                    the weekend. <br>
                    <br>
                    tar -zcf - -C /backups/servers itdocs | openssl enc
                    -aes-256-cbc <br>
                    -salt -pass <a moz-do-not-send="true">file:/etc/backups/key.bin</a>
                    | aws s3 cp - <br>
                    s3://XXXXXXX/servers/itdocs.160415.tar.gz.aes <br>
                    <br>
                    I was able to reverse the command and have it create
                    a fresh itdocs <br>
                    folder full of goodies in a tmp folder. The key.bin
                    file is 2048 <br>
                    bytes of randomness: <br>
                    <br>
                    openssl rand -base64 2048 -out key.bin <br>
                    <br>
                    Is this any good? The sample I had only used 128 and
                    I thought 2048 <br>
                    would be better. <br>
                    <br>
                    I don't know how good this all is as backup
                    encryption, but it <br>
                    looks like it should be as good as most. I'm not
                    sure how it's going <br>
                    to handle the larger backups, but I guess I'll find
                    out on Monday. <br>
                    It's set to do half Saturday morning and half Sunday
                    morning. <br>
                    <br>
                    On 2016-04-15 18:46, Zack Zatkin-Gold wrote: <br>
                    I was about to say -- usually when you see malloc
                    errors in a piece <br>
                    of <br>
                    software, it's because that software is unable to
                    allocate more <br>
                    memory! <br>
                    <br>
                    On Fri, Apr 15, 2016 at 9:19 PM,  <a
                      moz-do-not-send="true"
                      class="moz-txt-link-rfc2396E"
                      href="mailto:gandalf@sonic.net"><a class="moz-txt-link-rfc2396E" href="mailto:gandalf@sonic.net"><gandalf@sonic.net></a></a>
                    wrote: <br>
                    I think I found the problem. The method works for
                    large files but <br>
                    openssl <br>
                    loads the entire file into memory and hence it needs
                    one gigabyte <br>
                    of memory <br>
                    available for every gigabyte of file. This method
                    isn't going to <br>
                    work to <br>
                    encrypt a 500gig file and indeed breaks on my two
                    gig test backup. <br>
                    <br>
                    Anybody have any suggestions for encrypting very
                    large backup <br>
                    files? <br>
                    <br>
                    On 2016-04-15 15:41, <a moz-do-not-send="true"
                      href="mailto:gandalf@sonic.net" target="_blank">gandalf@sonic.net</a>
                    wrote: <br>
                    <br>
                    I was looking for a way to encrypt files using a key
                    or keys and <br>
                    found <br>
                    this article: <br>
                    <br>
                    <br>
                  </blockquote>
                  <a moz-do-not-send="true"
href="https://blog.altudov.com/2010/09/27/using-openssl-for-asymmetric-encryption-of-backups/#comment-399"
                    target="_blank">https://blog.altudov.com/2010/09/27/using-openssl-for-asymmetric-encryption-of-backups/#comment-399</a>
                  <br>
                  <blockquote type="cite">[1] <br>
                    <br>
                    I tied it out and it worked, but oddly when I moved
                    the keys to a <br>
                    different folder openssl said it couldn't find them.
                    Of course I <br>
                    adjusted the encryption/description commands to
                    point to the proper <br>
                    files. I moved them back to /root and suddenly they
                    work. <br>
                    <br>
                    Here's the command the article says to use to create
                    keys: <br>
                    openssl req -x509 -nodes -days 100000 -newkey
                    rsa:2048 -keyout <br>
                    MyCompanyBackupsPRIVATE.pem -out
                    MyCompanyBackupsPublicCert.pem <br>
                    -subj <br>
                    '/' <br>
                    <br>
                    Here's one of the errors I got: <br>
                    root@vault:/etc/backups/tmp# openssl smime -in <br>
                    itdocs.160415.tar.gz.aes -decrypt -binary -inform
                    DEM -inkey <br>
                    ../MSRI-Backups-PRIVATE.pem | tar -zx -f - <br>
                    Error reading S/MIME message <br>
                    139777656317600:error:07069041:memory buffer <br>
                    routines:BUF_MEM_grow_clean:malloc
                    failure:buffer.c:159: <br>
                    139777656317600:error:0D06B041:asn1 encoding <br>
                    routines:ASN1_D2I_READ_BIO:malloc
                    failure:a_d2i_fp.c:242: <br>
                    <br>
                    gzip: stdin: unexpected end of file <br>
                    tar: Child returned status 1 <br>
                    tar: Error is not recoverable: exiting now <br>
                    <br>
                    Moved the pem files back to /root and everything
                    works great. <br>
                    Although <br>
                    I find this reassuring I also find it disturbing as
                    these keys are <br>
                    for <br>
                    encrypting backups and they may have to be manually
                    typed in on a <br>
                    new <br>
                    system and used to restore an offsite backup from a
                    disaster. I'd <br>
                    like <br>
                    to know that I can put these keys in folder and use
                    them to decrypt <br>
                    backups. <br>
                    <br>
                    _______________________________________________ <br>
                    talk mailing list <br>
                    <a moz-do-not-send="true"
                      href="mailto:talk@nblug.org" target="_blank">talk@nblug.org</a>
                    <br>
                    <a moz-do-not-send="true"
                      href="http://nblug.org/cgi-bin/mailman/listinfo/talk"
                      target="_blank">http://nblug.org/cgi-bin/mailman/listinfo/talk</a>
                    [2] <br>
                    <br>
                    _______________________________________________ <br>
                    talk mailing list <br>
                    <a moz-do-not-send="true"
                      href="mailto:talk@nblug.org" target="_blank">talk@nblug.org</a>
                    <br>
                    <a moz-do-not-send="true"
                      href="http://nblug.org/cgi-bin/mailman/listinfo/talk"
                      target="_blank">http://nblug.org/cgi-bin/mailman/listinfo/talk</a>
                    [2] <br>
                  </blockquote>
                   _______________________________________________ <br>
                   talk mailing list <br>
                   <a moz-do-not-send="true"
                    href="mailto:talk@nblug.org" target="_blank">talk@nblug.org</a>
                  <br>
                   <a moz-do-not-send="true"
                    href="http://nblug.org/cgi-bin/mailman/listinfo/talk"
                    target="_blank">http://nblug.org/cgi-bin/mailman/listinfo/talk</a>
                  [2] <br>
                  <br>
                  <br>
                  Links: <br>
                  ------ <br>
                  [1] <br>
                  <a moz-do-not-send="true"
href="https://blog.altudov.com/2010/09/27/using-openssl-for-asymmetric-encryption-of-backups/#comment-399"
                    target="_blank">https://blog.altudov.com/2010/09/27/using-openssl-for-asymmetric-encryption-of-backups/#comment-399</a>
                  <br>
                  [2] <a moz-do-not-send="true"
                    href="http://nblug.org/cgi-bin/mailman/listinfo/talk"
                    target="_blank">http://nblug.org/cgi-bin/mailman/listinfo/talk</a>
                  <br>
                  <br>
                  _______________________________________________ <br>
                  talk mailing list <br>
                  <a moz-do-not-send="true" href="mailto:talk@nblug.org"
                    target="_blank">talk@nblug.org</a> <br>
                  <a moz-do-not-send="true"
                    href="http://nblug.org/cgi-bin/mailman/listinfo/talk"
                    target="_blank">http://nblug.org/cgi-bin/mailman/listinfo/talk</a>
                  <br>
                </blockquote>
                _______________________________________________ <br>
                talk mailing list <br>
                <a moz-do-not-send="true" href="mailto:talk@nblug.org"
                  target="_blank">talk@nblug.org</a> <br>
                <a moz-do-not-send="true"
                  href="http://nblug.org/cgi-bin/mailman/listinfo/talk"
                  target="_blank">http://nblug.org/cgi-bin/mailman/listinfo/talk</a>
                <br>
              </blockquote>
              <br>
            </div>
            <br>
            _______________________________________________<br>
            talk mailing list<br>
            <a moz-do-not-send="true" href="mailto:talk@nblug.org">talk@nblug.org</a><br>
            <a moz-do-not-send="true"
              href="http://nblug.org/cgi-bin/mailman/listinfo/talk"
              rel="noreferrer" target="_blank">http://nblug.org/cgi-bin/mailman/listinfo/talk</a><br>
            <br>
          </blockquote>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
talk mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:talk@nblug.org">talk@nblug.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://nblug.org/cgi-bin/mailman/listinfo/talk">http://nblug.org/cgi-bin/mailman/listinfo/talk</a>
</pre>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>