Re: General security question

["Stephen P. Berry" <spb () meshuggeneh net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


TDyson () sybex com writes:

> We are getting ready to do business with a remote warehouse.  We will send
> them order details, they will ship the order and send us back shipping
> details.
> We'll be using a VPN,  I have no idea what security they have at the other
> end.

You heard it from everyone else, now hear it from me:  ditch the VPN.
I suppose you could put the near-side VPN endpoint out past the perimeter of
your local network(s) and then treat it as just another untrusted pipeline,
but then why bother with the VPN in the first place?  In general, if
you're not interested in establishing a two-way trust relationship with
the far end, you really don't want a VPN.

Here's a better answer:

        -Install OpenSSH on the remote box(-en)
        -Install rsync(1) on the remote box(-en)
        -Generate two {RSA|DSA} key pairs locally.
        -Put the keys in the remote box(-en)'s ~foo/.ssh/authorized_keys
         (for some unprivileged luser foo, where foo will have read but
          not write access to the data)
        -In the authorized_keys file, associate one of the keys you
         generated with whatever rsync semantics are required to
         push the data (your order details) at your end to some location
         at their end.  Associate the other key with an rsync command
         to pull the data (shipping details) from their end.
        -Set up two scripts locally, each of which invokes rsync with the
         appropriate key, one for pulling and one for pushing.
        -Secure the rsync box at your end commensurately with your risk
         assessment of the data (or the assessment you agreed to with
         whatever parties are involved in the process).

The big win here:  You don't have to establish a two-way trust relationship
with the far end.  Granted, you're still presumably wanting to trust
the data that they're providing, but you're never going to be able to
trust it more than you can trust that endpoint.  Unless the guys on
the far end are only serving as intermediaries for the data (in which
case the data could be signed (and encrypted) by the originator of the
data), the only way to fix that problem is to audit (and take corrective
action on) the far end.


It would be kinda nice if there was a canonical reference for simple
architectures like this.  You know, so when this sort of question
was asked, everyone could just say yeah, you want something like
the #119-Z from RFCwhatever.  Of course, that would blow a lot of
consultant's gigs[0].





- -Steve

- -----
0     Standard disclaimer:  Not all consultants are ignorant rubes with
      technical skills just this side of a concussed tarsier's.  Not
      even all security consultants.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6Dv3aG3kIaxeRZl8RAs6xAKDkZchSnNu3FIoys1KlH7njY7reIwCfVo91
oTfR/NCCNGTIFw+9dDISVfg=
=p518
-----END PGP SIGNATURE-----

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards