RE: General security question

["Loomis, Rip" <GILBERT.R.LOOMIS () saic com>]

To follow up to both of MJR's posts on the
subject:

1.  You almost certainly want to send the
    order data over an encrypted tunnel--
    if not for the sake of privacy or
    proprietary data, then at least for
    authentication--which you need in
    both directions.  This implies either
    a full-up VPN or some other encrypted
    tunnel such as SSH.  (You had already
    specified a VPN, I'm just reinforcing
    that for anyone's benefit.)

2.  The biggest vulnerability that typically
    shows up in the "send it over a socket"
    method is that the person writing the
    socket thing on the other end has to
    handle not only the expected inputs, but
    all the other cases.  Although this is
    also true for processing a text file,
    there are more well-bounded conditions
    in the text file case and fewer oddities.

3.  If you establish a full-up VPN connection,
    then you may very well have "crosswired"
    your existing security domain to the
    warehouse's, and destroyed your security
    architecture in the process.  Generally
    not recommended in my experience.  The
    only advantage of a full-up (permanent,
    usually with indiscriminate forwarding
    of packets) VPN connection for this sort
    of use is the set-up and tear-down time
    of each file transfer, which you avoid by
    a permanent connection.  I doubt that the
    volume of order traffic is enough to
    make the set-up/tear-down time a major
    impact.

I had a situation similar to this for moving
SGI IRIX audit data from multiple clients to
a central server--and I was able to prototype
something using Perl+SSH (actually scp) in a
weekend, and get it running reliably within a
week (including the time necessary to correct
for SGI's silly non-Y2K compliant filenames.)

I would strongly recommend the "scp" course
over the network socket method--you have the
advantage of other folks already having gotten
the network stuff working, so all you have to
do is send a file and then the other side has
to handle it.  It is also possible to setup
the authentication on the "receiver" side so
that the authentication is RSA credentials
without a password (for unattended action), but
the user cannot obtain a terminal session
and no ports are forwarded in either direction.
This maintains the maximum separation between
the two security domains.

The biggest problem with the "scp" method is
making sure that the receiver knows that the
sender has sent something.  The most common
methods are either notification (syslog or
email) or polling the incoming directory on
a regular basis.

Note also that it is possible to have both the
SSH client and server pieces running on NT--
although you didn't specify an OS, that is
often a concern.

<ObDisclaimer: I love OpenSSH enough to have
contributed code to it.  Please see the
http://www.OpenSSH.com website for more info.>

Rip Loomis              Voice Number: (410) 953-6874
--------------------------------------------------------
Senior Security Engineer
Center for Information Security Technology
Science Applications International Corporation
http://www.cist.saic.com


> -----Original Message-----
> From: Marcus J. Ranum [mailto:mjr () nfr com]
> Sent: Saturday, November 11, 2000 12:30 PM
> To: TDyson () sybex com; firewall-wizards () nfr com
> Subject: Re: [fw-wiz] General security question
>
>
> TDyson () sybex com wrote:
> > We are debating communication protocols: sockets connection or ftp.
>
> I'd strongly recommend you look at using SSH and SCP (Secure Copy)
> It doesn't have FTP's horrible security properties and it 
> provides link
> level encryption and public keys as an option. There are free versions
> available for download, so it's hard to beat the price. See 
> www.openssh.org
> for details.
>
> mjr.
>
> ---
> Marcus J. Ranum     Chief Technology Officer, NFR Security, Inc.
> Work: http://www.nfr.com
> Play: http://pubweb.nfr.net/~mjr
>
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://www.nfr.com/mailman/listinfo/firewall-wizards


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