Merge replication security

I am doing merge replication to PocketPC devices using SSCE over the
internet and I'm wondering if I can increase security by moving the
distributor into the DMZ so that IIS will not need to connect all the way
back into our internal network (where our SQL is). We are curently using
standard security and have holes in our firewall to allow traffic from dmz
to sql. If we put the distributor into DMZ could and made the internal
domain trusted in the DMZ, could we close the firewall holes so that all
communication needs to be initiated from the internal network? That way if
someone hacked into the DMZ they couldn't take advantage of the open ports.
Would this also allow us to use integrated security with DMZ domain
accounts?
Alternatively, is there a way to use VPN on PocketPC with merge replication?
What is the best solution for this problem?
Thanks.
I'm not totally sure if I understand this question, so let me see if I have
it correct.
You are using "standard security" which I take to mean SQL Authentication or
do you perhaps mean Basic Authentication?
Currently you have port 1433 open on your firewall so your web server can
connect to your SQL Server which is on your internal network. You want to
move SQL Server into the DMZ so you can close port 1433.
Whether you have Windows Authentication or SQL Authentication port 1433 has
to be open. You will not be able to use Windows Authentication across the
DMZ, or you shouldn't if your firewall is configured correctly. Your idea of
an internal domain is a possibility.
I think you want to use certificates. Rob Tiffany's book on SQL CE
development does some pretty good coverage of this area.
"Elmer Miller" <millere@.empireco.nospam> wrote in message
news:epS5QaaxEHA.260@.TK2MSFTNGP11.phx.gbl...
>I am doing merge replication to PocketPC devices using SSCE over the
>internet and I'm wondering if I can increase security by moving the
>distributor into the DMZ so that IIS will not need to connect all the way
>back into our internal network (where our SQL is). We are curently using
>standard security and have holes in our firewall to allow traffic from dmz
>to sql. If we put the distributor into DMZ could and made the internal
>domain trusted in the DMZ, could we close the firewall holes so that all
>communication needs to be initiated from the internal network? That way if
>someone hacked into the DMZ they couldn't take advantage of the open ports.
>Would this also allow us to use integrated security with DMZ domain
>accounts?
> Alternatively, is there a way to use VPN on PocketPC with merge
> replication? What is the best solution for this problem?
> Thanks.
>
|||I know port 1433 needs to be open for OUTBOUND traffic, but I'm trying to
find out if it can be closed for INBOUND traffic, thus greatly improving
security. By having a separate SQL server in the DMZ I can use Windows
Authentication from the Web server to the SQL server since both are on the
same domain (in the DMZ). You can use Windows Authentication across the DMZ
securely as long as it is only from the Internal network to the DMZ as long
as you enable a one-way domain trust or a forest trust with Selective
Authentication enabled. My biggest question is this: Does the Distributor
need to initiate any communication with the Publisher? If it does then it
wouldn't work because inbound traffic will be blocked on port 1433. But if
the Publisher initiates all communication with the Distributor, then it
should work since outbound traffic will be allowed on port 1433. I think
this makes sense, but I've not heard anyone else discuss this option or
recommend it and I'm no security expert.
Thanks for the ref on the book. Use of certificates may solve this and many
other problems too, but I'm still curious if my idea could work.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:Om2hHdfxEHA.2624@.TK2MSFTNGP11.phx.gbl...
> I'm not totally sure if I understand this question, so let me see if I
> have it correct.
> You are using "standard security" which I take to mean SQL Authentication
> or do you perhaps mean Basic Authentication?
> Currently you have port 1433 open on your firewall so your web server can
> connect to your SQL Server which is on your internal network. You want to
> move SQL Server into the DMZ so you can close port 1433.
> Whether you have Windows Authentication or SQL Authentication port 1433
> has to be open. You will not be able to use Windows Authentication across
> the DMZ, or you shouldn't if your firewall is configured correctly. Your
> idea of an internal domain is a possibility.
> I think you want to use certificates. Rob Tiffany's book on SQL CE
> development does some pretty good coverage of this area.
>
> "Elmer Miller" <millere@.empireco.nospam> wrote in message
> news:epS5QaaxEHA.260@.TK2MSFTNGP11.phx.gbl...
>
sql

Merge Replication Problem (Private,Public Data - Security Issue)

Hello,
We plan to establish a merge replication topology in which several servers
(subscribers) have "public" data – data that have to be propagated to the
other servers, and private data - data reside only at original servers.
Private and public data are marked with one table column (1/0). Those servers
are at local branches in different countries. We have one server on the
Internet, which can be publisher and hold all public data, besides its own
private data. Subscriptions will be anonymous pull subscriptions. Subscribers
would periodicaly make dialup connections and merge data. Article filter
would be something like "Public=1". The problem is that subscribers' private
data will go to the publisher in merge replication. As far as we understand,
filter is only checked at the publisher and not at the subscriber. Only
public data goes from publisher to the subscribers, but all data goes from
subscriber to the publisher.
Our client is to happy about the fact that data marked as private is
available on the Internet server.
Is there any possibility to prevent private data going to the publisher?
Many thanks in advance.
Mirza
The easiest solution is to partition the data - have 2 tables, one for
private and one for public. This way, the data is protected and can be
selectively replicated. To show the data to the user on teh subscriber you
could use partitioned views, or standard views with an instead-of trigger.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)