PEPPLER.ORG
Michael Peppler
Sybase Consulting
Menu
Home
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
Freeware
Sybperl
Sybase::Simple
DBD::Sybase
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
FAQs
Sybase on Linux FAQ
Sybperl FAQ
Personal
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

From: Robert Dorfman <dorfmanr at netlabs dot net>
Subject: Re: Net Security of SybPerl.
Date: Mar 27 1998 2:57AM

Return-Path: 
Received: from mail.mbay.net by kiruna.peppler.org (SMI-8.6/SMI-SVR4)
	id TAA07843; Thu, 26 Mar 1998 19:24:46 -0800
Received: from mail.mbay.net
	by kiruna (fetchmail-4.3.0 POP3 run by mpeppler)
	for  (single-drop); Thu Mar 26 19:24:50 1998
Received: by otter for mpeppler
 (with Cubic Circle's cucipop (v1.21 1997/08/10) Thu Mar 26 19:31:44 1998)
X-From_: owner-sybperl-l@trln.lib.unc.edu  Thu Mar 26 19:27:01 1998
Received: from trln (trln.lib.unc.edu [152.2.176.90])
	by otter.mbay.net (8.8.8/8.8.8) with SMTP id TAA08113
	for ; Thu, 26 Mar 1998 19:26:49 -0800
X-ListName: SybPerl Discussion List 
Warnings-To: <>
Errors-To: owner-sybperl-l@trln.lib.unc.edu
Sender: owner-sybperl-l@trln.lib.unc.edu
Received: from www.netlabs.net by trln (MX V4.2 VAX) with SMTP; Thu, 26 Mar
          1998 21:56:46 EST
Received: from netlabs.net (dyn73.netlabs.net [206.34.172.73]) by
          www.netlabs.net (8.8.8/8.7.3) with ESMTP id VAA07073 for
          ; Thu, 26 Mar 1998 21:56:48 -0501 (EST)
Message-ID: <351B157D.92080A42@netlabs.net>
Date: Thu, 26 Mar 1998 21:57:01 -0500
From: Robert Dorfman 
Reply-To: SYBPERL-L@trln.lib.unc.edu
MIME-Version: 1.0
To: SYBPERL-L@trln.lib.unc.edu
Subject: Re: Net Security of SybPerl.
References: <01BD46C1.AF58B260@kiril.idea.co.uk>
Content-Type: multipart/mixed; boundary="------------2571A1527D2BB0EE89FDBC5F"
content-length: 7253
X-Filter: mailagent [version 3.0 PL44] for mpeppler@mbay.net
Status:  O
X-Status: $$$$
X-UID: 0000001185

This is a multi-part message in MIME format.
--------------2571A1527D2BB0EE89FDBC5F
Content-Type: multipart/alternative; boundary="------------0235E28258A9C92738C4DFAE"

--------------0235E28258A9C92738C4DFAE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

    I know of one vendor, Trusted Information Systems (tis.com), whose firewall product, Guantlet, has a proxy specifically
designed for Sybase. It only lets TDS packets through. Anything else causes the connection to be dropped. I've used this
product very successfully. You can reach them at:
  Trusted Information Systems

Robert Dorfman

Kiril Mitev wrote:

> Or, invest/obtain "some" firewall-ish software to run on the server itself and
> screen incoming coming connections based on IP....You could try ip-filter,
> sorry dont have the URL handy, but their mailing list is
> ipfilter@coombs.anu.edu.au , it's a Majordomo list like this one
>
> Kiril
>
> ----------
> From:   Michael Peppler
> Sent:   03 March 1998 15:43
> To:     SYBPERL-L@trln.lib.unc.edu
> Subject:        Re: Net Security of SybPerl.
>
> MichaelPountney@caspian.com wrote:
> >
> > We are currently undergoing a project that will involve retrieving
> > information from our internal Sybase database from the Internet.
> >
> > Currently, the scripts are executed on the clean side, and the results
> > sent across the firewall. We want to increase performance however, so
> > it's planned to move the scripts onto the dirty side of the network to
> > reduce load on the DB server.
> >
> > We're unsure whether to use Sybperl or ODBC. What are the security
> > implications of using Sybperl in such a manner? I've heard of ODBC
> > proxies to restrict such connections, do similar proxies exist for
> > Sybperl/OpenClient?
>
> I don't know anything about any ODBC proxies, but here's what I
> understand the situation is for a pur sybase solution:
>
> The problem is that you have to open the firewall to let connections
> to the SQL server through (ie access to port xxxx). Once you do that
> you basically allow anyone who *knows* that theres a SQL server on
> the other side to connect to it with a little patience (ie just try
> all the ports from 1000 upwards, fairly easy to do in a little perl
> script).
>
> The Sybase solution would be to have an openserver on the clean side
> that only accepts connections from certain hosts and passes them
> through to the server. This requires writing the openserver of course,
> but that shouldn't be too hard as it's only a pass-through server.
>
> At least that's my understanding of how things stand in this case -
> others may have other ideas.
>
> Michael
> --
> Michael Peppler         -||-  Data Migrations Inc.
> mpeppler@datamig.com    -||-  http://www.mbay.net/~mpeppler
> Int. Sybase User Group  -||-  http://www.isug.com
>
>                                                   ------------------------------------------------------------------------
>
>    Part 1.2       Type: application/ms-tnef
>               Encoding: base64



--------------0235E28258A9C92738C4DFAE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit


    I know of one vendor, Trusted Information Systems (tis.com),
whose firewall product, Guantlet, has a proxy specifically designed for
Sybase. It only lets TDS packets through. Anything else causes the connection
to be dropped. I've used this product very successfully. You can reach
them at:

  Trusted Information Systems

Robert Dorfman

Kiril Mitev wrote:

Or, invest/obtain "some" firewall-ish software to run on the server itself and
screen incoming coming connections based on IP....You could try ip-filter,
sorry dont have the URL handy, but their mailing list is
ipfilter@coombs.anu.edu.au , it's a Majordomo list like this one

Kiril

----------
From:   Michael Peppler
Sent:   03 March 1998 15:43
To:     SYBPERL-L@trln.lib.unc.edu
Subject:        Re: Net Security of SybPerl.

MichaelPountney@caspian.com wrote:
>
> We are currently undergoing a project that will involve retrieving
> information from our internal Sybase database from the Internet.
>
> Currently, the scripts are executed on the clean side, and the results
> sent across the firewall. We want to increase performance however, so
> it's planned to move the scripts onto the dirty side of the network to
> reduce load on the DB server.
>
> We're unsure whether to use Sybperl or ODBC. What are the security
> implications of using Sybperl in such a manner? I've heard of ODBC
> proxies to restrict such connections, do similar proxies exist for
> Sybperl/OpenClient?

I don't know anything about any ODBC proxies, but here's what I
understand the situation is for a pur sybase solution:

The problem is that you have to open the firewall to let connections
to the SQL server through (ie access to port xxxx). Once you do that
you basically allow anyone who *knows* that theres a SQL server on
the other side to connect to it with a little patience (ie just try
all the ports from 1000 upwards, fairly easy to do in a little perl
script).

The Sybase solution would be to have an openserver on the clean side
that only accepts connections from certain hosts and passes them
through to the server. This requires writing the openserver of course,
but that shouldn't be too hard as it's only a pass-through server.

At least that's my understanding of how things stand in this case -
others may have other ideas.

Michael
--
Michael Peppler         -||-  Data Migrations Inc.
mpeppler@datamig.com    -||-  http://www.mbay.net/~mpeppler
Int. Sybase User Group  -||-  http://www.isug.com

                                                  ------------------------------------------------------------------------

   Part 1.2       Type: application/ms-tnef
              Encoding: base64

  --------------0235E28258A9C92738C4DFAE-- --------------2571A1527D2BB0EE89FDBC5F Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Robert Dorfman Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Robert Dorfman n: Dorfman;Robert org: Dorfman Consulting email;internet: dorfmanr@netlabs.net x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------2571A1527D2BB0EE89FDBC5F--