Best way to copy database: port

Showing posts with label port. Show all posts

Sunday, March 25, 2012

Bind failed on TCP port 1433

Dolph
"Mark Allison" wrote:

> I didn't finish. :-/
> If you still cannot find the cause of the problem, I suggest that you
> reboot the server.
> In the case of 1) the solution is to put a small pause in your code
> before starting the MSSQLServer service again.
> In the case of 2) you will need to ensure that your application uses
> another port - perhaps there is a setting somewhere (maybe the registry)
> where you can tweak this.
> --
> Mark Allison, SQL Server MVP
> http://www.markallison.co.uk
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602m.html
>
> Mark Allison wrote:
>
|||Dolph Larson wrote:
> Can someone please help. I have not seen the answer and I have been
> searching for 2 days now.
For the benefit of any other poor ***s trying to work this one out,
here's what I just found...
We got the "SuperSocket Info: Bind failed on TCP port 1433" error, yet
netstat says the socket _is_ listening. TCPView (from the excellent
sysinternals site) confirms that it's listening, and that it's SQL
server that doing it.
Stumped despite much googling, I suddenly realised we'd recently
installed a new remote access _client_ on this server, Windows Secure
Application Manager from netscreen. This seems to work by hooking the
TCP stack with an LSP. Needless to say, it was this that was messing
up SQL server - using the diagnostics tool to remove the LSP sorted it
out straight away.
Thinking back, I've seen problems with an LSP before: some weird
problem with Norton Antivirus left a machine in a state where ipconfig
said it was dialled up OK, it could ping, but it couldn't do email or
http... Zapping the LSP sorted it (not that I can remember how I
removed it!)
Cheers,
Martin.

Bind failed on TCP port 1433

Dolph
"Mark Allison" wrote:

> I didn't finish. :-/
> If you still cannot find the cause of the problem, I suggest that you
> reboot the server.
> In the case of 1) the solution is to put a small pause in your code
> before starting the MSSQLServer service again.
> In the case of 2) you will need to ensure that your application uses
> another port - perhaps there is a setting somewhere (maybe the registry)
> where you can tweak this.
> --
> Mark Allison, SQL Server MVP
> http://www.markallison.co.uk
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602m.html
>
> Mark Allison wrote:
>|||Dolph Larson wrote:
> Can someone please help. I have not seen the answer and I have been
> searching for 2 days now.
For the benefit of any other poor ***s trying to work this one out,
here's what I just found...
We got the "SuperSocket Info: Bind failed on TCP port 1433" error, yet
netstat says the socket _is_ listening. TCPView (from the excellent
sysinternals site) confirms that it's listening, and that it's SQL
server that doing it.
Stumped despite much googling, I suddenly realised we'd recently
installed a new remote access _client_ on this server, Windows Secure
Application Manager from netscreen. This seems to work by hooking the
TCP stack with an LSP. Needless to say, it was this that was messing
up SQL server - using the diagnostics tool to remove the LSP sorted it
out straight away.
Thinking back, I've seen problems with an LSP before: some weird
problem with Norton Antivirus left a machine in a state where ipconfig
said it was dialled up OK, it could ping, but it couldn't do email or
http... Zapping the LSP sorted it (not that I can remember how I
removed it!)
Cheers,
Martin.

Bind failed on TCP port 1433

I installed SP3a and now I am getting this error message in the application
event log. Also, I can only connect to my server using namepipes. But
TCP/IP won't connect, even using 127.0.0.1 or the IP of my machine. The
event logs says that SQL is listening on 127.0.0.1:1433.
Can someone please help. I have not seen the answer and I have been
searching for 2 days now.
Log:
SQL server listening on 127.0.0.1: 1433.
SuperSocket Info: Bind failed on TCP port 1433.
SuperSocket info: (SpnRegister) : Error 1355.
Thanks in advance!Dolph,
There are two scenarios that I can think of that will cause this situation.
1) You have bounced the SQL Server service programmatically (probably in
C++) and the service has been stopped and restarted too quickly. SQL
Server does not release the port quickly enough before it is restarted
and thinks that another service is using port 1433. The bind, then fails.
2) Another application is using port 1433.
You can check your ports using this on the commandline:
netstat -a
Look at the local address column for <machinename>:ms-sql-s or
<machinename>:1433
On my Inspiron laptop I get these results:
Active Connections
Proto Local Address Foreign Address State
TCP inspiron4100:ftp inspiron4100:0 LISTENING
TCP inspiron4100:http inspiron4100:0 LISTENING
TCP inspiron4100:epmap inspiron4100:0 LISTENING
TCP inspiron4100:https inspiron4100:0 LISTENING
TCP inspiron4100:microsoft-ds inspiron4100:0 LISTENING
TCP inspiron4100:1025 inspiron4100:0 LISTENING
TCP inspiron4100:ms-sql-s inspiron4100:0 LISTENING
TCP inspiron4100:2869 inspiron4100:0 LISTENING
TCP inspiron4100:3389 inspiron4100:0 LISTENING
TCP inspiron4100:1028 inspiron4100:0 LISTENING
TCP inspiron4100:1061 inspiron4100:0 LISTENING
TCP inspiron4100:1134 localhost:1135 ESTABLISHED
TCP inspiron4100:1135 localhost:1134 ESTABLISHED
TCP inspiron4100:netbios-ssn inspiron4100:0 LISTENING
TCP inspiron4100:1056 baym-cs91.msgr.hotmail.com:1863
ESTABLISHED
TCP inspiron4100:1130 82.152.34.166:50002 ESTABLISHED
TCP inspiron4100:1173 msnews.microsoft.com:nntp ESTABLISHED
TCP inspiron4100:1205 64.233.161.107:http ESTABLISHED
UDP inspiron4100:microsoft-ds *:*
UDP inspiron4100:isakmp *:*
UDP inspiron4100:1026 *:*
UDP inspiron4100:1069 *:*
UDP inspiron4100:1070 *:*
UDP inspiron4100:1131 *:*
UDP inspiron4100:ms-sql-m *:*
UDP inspiron4100:3456 *:*
UDP inspiron4100:4500 *:*
UDP inspiron4100:ntp *:*
UDP inspiron4100:1050 *:*
UDP inspiron4100:1057 *:*
UDP inspiron4100:1156 *:*
UDP inspiron4100:1900 *:*
UDP inspiron4100:ntp *:*
UDP inspiron4100:netbios-ns *:*
UDP inspiron4100:netbios-dgm *:*
UDP inspiron4100:1900 *:*
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602m.html
Dolph Larson wrote:
> I installed SP3a and now I am getting this error message in the application
> event log. Also, I can only connect to my server using namepipes. But
> TCP/IP won't connect, even using 127.0.0.1 or the IP of my machine. The
> event logs says that SQL is listening on 127.0.0.1:1433.
> Can someone please help. I have not seen the answer and I have been
> searching for 2 days now.
> Log:
> SQL server listening on 127.0.0.1: 1433.
> SuperSocket Info: Bind failed on TCP port 1433.
> SuperSocket info: (SpnRegister) : Error 1355.
> Thanks in advance!|||I didn't finish. :-/
If you still cannot find the cause of the problem, I suggest that you
reboot the server.
In the case of 1) the solution is to put a small pause in your code
before starting the MSSQLServer service again.
In the case of 2) you will need to ensure that your application uses
another port - perhaps there is a setting somewhere (maybe the registry)
where you can tweak this.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602m.html
Mark Allison wrote:
> Dolph,
> There are two scenarios that I can think of that will cause this situation.
> 1) You have bounced the SQL Server service programmatically (probably in
> C++) and the service has been stopped and restarted too quickly. SQL
> Server does not release the port quickly enough before it is restarted
> and thinks that another service is using port 1433. The bind, then fails.
> 2) Another application is using port 1433.
> You can check your ports using this on the commandline:
> netstat -a
> Look at the local address column for <machinename>:ms-sql-s or
> <machinename>:1433
> On my Inspiron laptop I get these results:
>
> Active Connections
> Proto Local Address Foreign Address State
> TCP inspiron4100:ftp inspiron4100:0 LISTENING
> TCP inspiron4100:http inspiron4100:0 LISTENING
> TCP inspiron4100:epmap inspiron4100:0 LISTENING
> TCP inspiron4100:https inspiron4100:0 LISTENING
> TCP inspiron4100:microsoft-ds inspiron4100:0 LISTENING
> TCP inspiron4100:1025 inspiron4100:0 LISTENING
> TCP inspiron4100:ms-sql-s inspiron4100:0 LISTENING
> TCP inspiron4100:2869 inspiron4100:0 LISTENING
> TCP inspiron4100:3389 inspiron4100:0 LISTENING
> TCP inspiron4100:1028 inspiron4100:0 LISTENING
> TCP inspiron4100:1061 inspiron4100:0 LISTENING
> TCP inspiron4100:1134 localhost:1135 ESTABLISHED
> TCP inspiron4100:1135 localhost:1134 ESTABLISHED
> TCP inspiron4100:netbios-ssn inspiron4100:0 LISTENING
> TCP inspiron4100:1056 baym-cs91.msgr.hotmail.com:1863 ESTABLISHED
> TCP inspiron4100:1130 82.152.34.166:50002 ESTABLISHED
> TCP inspiron4100:1173 msnews.microsoft.com:nntp ESTABLISHED
> TCP inspiron4100:1205 64.233.161.107:http ESTABLISHED
> UDP inspiron4100:microsoft-ds *:*
> UDP inspiron4100:isakmp *:*
> UDP inspiron4100:1026 *:*
> UDP inspiron4100:1069 *:*
> UDP inspiron4100:1070 *:*
> UDP inspiron4100:1131 *:*
> UDP inspiron4100:ms-sql-m *:*
> UDP inspiron4100:3456 *:*
> UDP inspiron4100:4500 *:*
> UDP inspiron4100:ntp *:*
> UDP inspiron4100:1050 *:*
> UDP inspiron4100:1057 *:*
> UDP inspiron4100:1156 *:*
> UDP inspiron4100:1900 *:*
> UDP inspiron4100:ntp *:*
> UDP inspiron4100:netbios-ns *:*
> UDP inspiron4100:netbios-dgm *:*
> UDP inspiron4100:1900 *:*
>
>
>|||Thanks for trying to help. Sadly, it can not be either case. I am not
doing anything with C++ and I have not downloaded any application lately that
is build on it. Esp. working with SQL server. I looked at the ports with
netstat -an and I see the port being listened by SQL Server. The server just
wont bind to that port. If I can't find a solution soon, I will be left to
do a re-install. :(
Dolph
"Mark Allison" wrote:
> I didn't finish. :-/
> If you still cannot find the cause of the problem, I suggest that you
> reboot the server.
> In the case of 1) the solution is to put a small pause in your code
> before starting the MSSQLServer service again.
> In the case of 2) you will need to ensure that your application uses
> another port - perhaps there is a setting somewhere (maybe the registry)
> where you can tweak this.
> --
> Mark Allison, SQL Server MVP
> http://www.markallison.co.uk
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602m.html
>
> Mark Allison wrote:
> > Dolph,
> >
> > There are two scenarios that I can think of that will cause this situation.
> >
> > 1) You have bounced the SQL Server service programmatically (probably in
> > C++) and the service has been stopped and restarted too quickly. SQL
> > Server does not release the port quickly enough before it is restarted
> > and thinks that another service is using port 1433. The bind, then fails.
> >
> > 2) Another application is using port 1433.
> >
> > You can check your ports using this on the commandline:
> >
> > netstat -a
> >
> > Look at the local address column for <machinename>:ms-sql-s or
> > <machinename>:1433
> >
> > On my Inspiron laptop I get these results:
> >
> >
> > Active Connections
> >
> > Proto Local Address Foreign Address State
> > TCP inspiron4100:ftp inspiron4100:0 LISTENING
> > TCP inspiron4100:http inspiron4100:0 LISTENING
> > TCP inspiron4100:epmap inspiron4100:0 LISTENING
> > TCP inspiron4100:https inspiron4100:0 LISTENING
> > TCP inspiron4100:microsoft-ds inspiron4100:0 LISTENING
> > TCP inspiron4100:1025 inspiron4100:0 LISTENING
> > TCP inspiron4100:ms-sql-s inspiron4100:0 LISTENING
> > TCP inspiron4100:2869 inspiron4100:0 LISTENING
> > TCP inspiron4100:3389 inspiron4100:0 LISTENING
> > TCP inspiron4100:1028 inspiron4100:0 LISTENING
> > TCP inspiron4100:1061 inspiron4100:0 LISTENING
> > TCP inspiron4100:1134 localhost:1135 ESTABLISHED
> > TCP inspiron4100:1135 localhost:1134 ESTABLISHED
> > TCP inspiron4100:netbios-ssn inspiron4100:0 LISTENING
> > TCP inspiron4100:1056 baym-cs91.msgr.hotmail.com:1863 ESTABLISHED
> > TCP inspiron4100:1130 82.152.34.166:50002 ESTABLISHED
> > TCP inspiron4100:1173 msnews.microsoft.com:nntp ESTABLISHED
> > TCP inspiron4100:1205 64.233.161.107:http ESTABLISHED
> > UDP inspiron4100:microsoft-ds *:*
> > UDP inspiron4100:isakmp *:*
> > UDP inspiron4100:1026 *:*
> > UDP inspiron4100:1069 *:*
> > UDP inspiron4100:1070 *:*
> > UDP inspiron4100:1131 *:*
> > UDP inspiron4100:ms-sql-m *:*
> > UDP inspiron4100:3456 *:*
> > UDP inspiron4100:4500 *:*
> > UDP inspiron4100:ntp *:*
> > UDP inspiron4100:1050 *:*
> > UDP inspiron4100:1057 *:*
> > UDP inspiron4100:1156 *:*
> > UDP inspiron4100:1900 *:*
> > UDP inspiron4100:ntp *:*
> > UDP inspiron4100:netbios-ns *:*
> > UDP inspiron4100:netbios-dgm *:*
> > UDP inspiron4100:1900 *:*
> >
> >
> >
> >
> >
>|||Dolph Larson wrote:
> Can someone please help. I have not seen the answer and I have been
> searching for 2 days now.
For the benefit of any other poor ***s trying to work this one out,
here's what I just found...
We got the "SuperSocket Info: Bind failed on TCP port 1433" error, yet
netstat says the socket _is_ listening. TCPView (from the excellent
sysinternals site) confirms that it's listening, and that it's SQL
server that doing it.
Stumped despite much googling, I suddenly realised we'd recently
installed a new remote access _client_ on this server, Windows Secure
Application Manager from netscreen. This seems to work by hooking the
TCP stack with an LSP. Needless to say, it was this that was messing
up SQL server - using the diagnostics tool to remove the LSP sorted it
out straight away.
Thinking back, I've seen problems with an LSP before: some weird
problem with Norton Antivirus left a machine in a state where ipconfig
said it was dialled up OK, it could ping, but it couldn't do email or
http... Zapping the LSP sorted it (not that I can remember how I
removed it!)
Cheers,
Martin.

Bind failed on TCP port 1044.

I am getting this error in the Event Viewer and the clients are unable to
connect to the SQL server. What is wrong?
PLEASE HELP!!
ScottHi
You SQL Server is configured not to use the standard 1433 port, but this is
not a problem in itself.
By the time SQL Server starts, there is another application that is using
the port 1044. This results in SQL Server not being able to use it. You need
to either stop that application or configure SQL Server to use a different
port. Configure the port though Server Network Utility in the SQL Server men
u.
Regards
Mike
"scottdog129" wrote:

> I am getting this error in the Event Viewer and the clients are unable to
> connect to the SQL server. What is wrong?
> PLEASE HELP!!
> Scottsql

Bind failed on TCP port 1044.

I am getting this error in the Event Viewer and the clients are unable to
connect to the SQL server. What is wrong?
PLEASE HELP!!
Scott
Hi
You SQL Server is configured not to use the standard 1433 port, but this is
not a problem in itself.
By the time SQL Server starts, there is another application that is using
the port 1044. This results in SQL Server not being able to use it. You need
to either stop that application or configure SQL Server to use a different
port. Configure the port though Server Network Utility in the SQL Server menu.
Regards
Mike
"scottdog129" wrote:

> I am getting this error in the Event Viewer and the clients are unable to
> connect to the SQL server. What is wrong?
> PLEASE HELP!!
> Scott

Friday, February 24, 2012

Best way to update database behind firewall?

Hello

I have a project where I need to update a few tables in a SQL Server 2000
database which resides behind a firewall, ie port 1433 is blocked. I also
need to verify the updates were successful.
I am a C# developer. What are my options in doing this.. web services?

John DalbergHi

Assuming that you are not allowed to use a different port or a different
method of communicating directly with the database, then web services seems
the way to go!

John

"John Dalberg" <john_dd@.hotmail.com> wrote in message
news:x8g4yff5ouij.1ew6u2lc8iovb$.dlg@.40tude.net...
> Hello
> I have a project where I need to update a few tables in a SQL Server 2000
> database which resides behind a firewall, ie port 1433 is blocked. I also
> need to verify the updates were successful.
> I am a C# developer. What are my options in doing this.. web services?
> John Dalberg

Sunday, February 19, 2012

Best way to secure an exposed SQL Server

Hi experts,
I have an application that my company designed and sold to users years ago
that requires SQL port 1433 to be open to the Internet. (Insert .. shame a
you here!).
There is basically a straight NAT statement from our firewall to the SQL
server that allows ALL inbound traffic to SQL. I am looking for the best
method to secure this connection from the application side (it is under
rewrite). Possibly encode the app to use some sort of VPN or maybe add a
front end server to autheticate the SQL users first, change the port and pass
to the back-end sql server?... I dont know really... can someone please
provide me with some design suggestions to take to my developers in order to
secure and encrypt there SQL sessions for their appications? I am able to
design hardware solutions to assist with this too!
I know its best practices to NOT have SQL open, but this late in the game,
it would take a miracle to get all our customers to change ports. Thanks for
your timely suggestions!!
"Scott" <Scott@.discussions.microsoft.com> schrieb im Newsbeitrag
news:CE23D173-4B46-4AB3-B139-4664E65B58B3@.microsoft.com...
> Hi experts,
> I have an application that my company designed and sold to users years ago
> that requires SQL port 1433 to be open to the Internet. (Insert .. shame a
> you here!).
There you are :-)

> There is basically a straight NAT statement from our firewall to the SQL
> server that allows ALL inbound traffic to SQL. I am looking for the best
> method to secure this connection from the application side (it is under
> rewrite). Possibly encode the app to use some sort of VPN or maybe add a
> front end server to autheticate the SQL users first, change the port and
> pass
> to the back-end sql server?... I dont know really... can someone
> please
> provide me with some design suggestions to take to my developers in order
> to
> secure and encrypt there SQL sessions for their appications? I am able to
> design hardware solutions to assist with this too!
I wouldnt code that on my own, I would suggest using a software VPN client
which establishs a conection to the internal network and use the SQLServer
the old fashioned way. Exposing the SQLerver is always risky because your
are exposing productional data to the internet and to possible hackers. Even
if you are coding of 99% solution, that would bring nightmares if I would be
responsible for that.
SO my suggestion would be to use a hardware solution on the one sideand a
software / Hardware solution on the other side implementing VPN (perhaps, if
you have money left to implement some securiyt with some kind of external
certification /smartcard solution)

> I know its best practices to NOT have SQL open, but this late in the game,
> it would take a miracle to get all our customers to change ports. Thanks
> for
> your timely suggestions!!
Just my two cents for that.
HTH, Jens Suessmeyer.
|||We use a hardware firewall to only let some specific IP to access the
SQLServer through the Internet, until now, it is fine.
"Jens Smeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> glsD:Olhu%23%230eFHA.1404@.TK2MSFTNGP09.p hx.gbl...
> "Scott" <Scott@.discussions.microsoft.com> schrieb im Newsbeitrag
> news:CE23D173-4B46-4AB3-B139-4664E65B58B3@.microsoft.com...
> There you are :-)
>
> I wouldnt code that on my own, I would suggest using a software VPN
> client which establishs a conection to the internal network and use the
> SQLServer the old fashioned way. Exposing the SQLerver is always risky
> because your are exposing productional data to the internet and to
> possible hackers. Even if you are coding of 99% solution, that would bring
> nightmares if I would be responsible for that.
> SO my suggestion would be to use a hardware solution on the one sideand a
> software / Hardware solution on the other side implementing VPN (perhaps,
> if you have money left to implement some securiyt with some kind of
> external certification /smartcard solution)
>
> Just my two cents for that.
> HTH, Jens Suessmeyer.
>

Best way to secure an exposed SQL Server

Hi experts,
I have an application that my company designed and sold to users years ago
that requires SQL port 1433 to be open to the Internet. (Insert .. shame a
you here!).
There is basically a straight NAT statement from our firewall to the SQL
server that allows ALL inbound traffic to SQL. I am looking for the best
method to secure this connection from the application side (it is under
rewrite). Possibly encode the app to use some sort of VPN or maybe add a
front end server to autheticate the SQL users first, change the port and pas
s
to the back-end sql server?... I dont know really... can someone please
provide me with some design suggestions to take to my developers in order to
secure and encrypt there SQL sessions for their appications' I am able to
design hardware solutions to assist with this too!
I know its best practices to NOT have SQL open, but this late in the game,
it would take a miracle to get all our customers to change ports. Thanks for
your timely suggestions!!"Scott" <Scott@.discussions.microsoft.com> schrieb im Newsbeitrag
news:CE23D173-4B46-4AB3-B139-4664E65B58B3@.microsoft.com...
> Hi experts,
> I have an application that my company designed and sold to users years ago
> that requires SQL port 1433 to be open to the Internet. (Insert .. shame a
> you here!).
There you are :-)

> There is basically a straight NAT statement from our firewall to the SQL
> server that allows ALL inbound traffic to SQL. I am looking for the best
> method to secure this connection from the application side (it is under
> rewrite). Possibly encode the app to use some sort of VPN or maybe add a
> front end server to autheticate the SQL users first, change the port and
> pass
> to the back-end sql server?... I dont know really... can someone
> please
> provide me with some design suggestions to take to my developers in order
> to
> secure and encrypt there SQL sessions for their appications' I am able to
> design hardware solutions to assist with this too!
I wouldnt code that on my own, I would suggest using a software VPN client
which establishs a conection to the internal network and use the SQLServer
the old fashioned way. Exposing the SQLerver is always risky because your
are exposing productional data to the internet and to possible hackers. Even
if you are coding of 99% solution, that would bring nightmares if I would be
responsible for that.
SO my suggestion would be to use a hardware solution on the one sideand a
software / hardware solution on the other side implementing VPN (perhaps, if
you have money left to implement some securiyt with some kind of external
certification /smartcard solution)

> I know its best practices to NOT have SQL open, but this late in the game,
> it would take a miracle to get all our customers to change ports. Thanks
> for
> your timely suggestions!!
Just my two cents for that.
HTH, Jens Suessmeyer.|||We use a hardware firewall to only let some specific IP to access the
SQLServer through the Internet, until now, it is fine.
"Jens Smeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> glsD:Olhu%23%23
0eFHA.1404@.TK2MSFTNGP09.phx.gbl...
> "Scott" <Scott@.discussions.microsoft.com> schrieb im Newsbeitrag
> news:CE23D173-4B46-4AB3-B139-4664E65B58B3@.microsoft.com...
> There you are :-)
>
> I wouldnt code that on my own, I would suggest using a software VPN
> client which establishs a conection to the internal network and use the
> SQLServer the old fashioned way. Exposing the SQLerver is always risky
> because your are exposing productional data to the internet and to
> possible hackers. Even if you are coding of 99% solution, that would bring
> nightmares if I would be responsible for that.
> SO my suggestion would be to use a hardware solution on the one sideand a
> software / hardware solution on the other side implementing VPN (perhaps,
> if you have money left to implement some securiyt with some kind of
> external certification /smartcard solution)
>
> Just my two cents for that.
> HTH, Jens Suessmeyer.
>

Best way to secure an exposed SQL Server

Hi experts,
I have an application that my company designed and sold to users years ago
that requires SQL port 1433 to be open to the Internet. (Insert .. shame a
you here!).
There is basically a straight NAT statement from our firewall to the SQL
server that allows ALL inbound traffic to SQL. I am looking for the best
method to secure this connection from the application side (it is under
rewrite). Possibly encode the app to use some sort of VPN or maybe add a
front end server to autheticate the SQL users first, change the port and pass
to the back-end sql server?... I dont know really... can someone please
provide me with some design suggestions to take to my developers in order to
secure and encrypt there SQL sessions for their appications' I am able to
design hardware solutions to assist with this too!
I know its best practices to NOT have SQL open, but this late in the game,
it would take a miracle to get all our customers to change ports. Thanks for
your timely suggestions!!"Scott" <Scott@.discussions.microsoft.com> schrieb im Newsbeitrag
news:CE23D173-4B46-4AB3-B139-4664E65B58B3@.microsoft.com...
> Hi experts,
> I have an application that my company designed and sold to users years ago
> that requires SQL port 1433 to be open to the Internet. (Insert .. shame a
> you here!).
There you are :-)
> There is basically a straight NAT statement from our firewall to the SQL
> server that allows ALL inbound traffic to SQL. I am looking for the best
> method to secure this connection from the application side (it is under
> rewrite). Possibly encode the app to use some sort of VPN or maybe add a
> front end server to autheticate the SQL users first, change the port and
> pass
> to the back-end sql server?... I dont know really... can someone
> please
> provide me with some design suggestions to take to my developers in order
> to
> secure and encrypt there SQL sessions for their appications' I am able to
> design hardware solutions to assist with this too!
I wouldn´t code that on my own, I would suggest using a software VPN client
which establishs a conection to the internal network and use the SQLServer
the old fashioned way. Exposing the SQLerver is always risky because your
are exposing productional data to the internet and to possible hackers. Even
if you are coding of 99% solution, that would bring nightmares if I would be
responsible for that.
SO my suggestion would be to use a hardware solution on the one sideand a
software / Hardware solution on the other side implementing VPN (perhaps, if
you have money left to implement some securiyt with some kind of external
certification /smartcard solution)
> I know its best practices to NOT have SQL open, but this late in the game,
> it would take a miracle to get all our customers to change ports. Thanks
> for
> your timely suggestions!!
Just my two cents for that.
HTH, Jens Suessmeyer.|||We use a hardware firewall to only let some specific IP to access the
SQLServer through the Internet, until now, it is fine.
"Jens Süßmeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> ¼¶¼g©ó¶l¥ó·s»D:Olhu%23%230eFHA.1404@.TK2MSFTNGP09.phx.gbl...
> "Scott" <Scott@.discussions.microsoft.com> schrieb im Newsbeitrag
> news:CE23D173-4B46-4AB3-B139-4664E65B58B3@.microsoft.com...
>> Hi experts,
>> I have an application that my company designed and sold to users years
>> ago
>> that requires SQL port 1433 to be open to the Internet. (Insert .. shame
>> a
>> you here!).
> There you are :-)
>> There is basically a straight NAT statement from our firewall to the SQL
>> server that allows ALL inbound traffic to SQL. I am looking for the best
>> method to secure this connection from the application side (it is under
>> rewrite). Possibly encode the app to use some sort of VPN or maybe add a
>> front end server to autheticate the SQL users first, change the port and
>> pass
>> to the back-end sql server?... I dont know really... can someone
>> please
>> provide me with some design suggestions to take to my developers in order
>> to
>> secure and encrypt there SQL sessions for their appications' I am able
>> to
>> design hardware solutions to assist with this too!
> I wouldn´t code that on my own, I would suggest using a software VPN
> client which establishs a conection to the internal network and use the
> SQLServer the old fashioned way. Exposing the SQLerver is always risky
> because your are exposing productional data to the internet and to
> possible hackers. Even if you are coding of 99% solution, that would bring
> nightmares if I would be responsible for that.
> SO my suggestion would be to use a hardware solution on the one sideand a
> software / Hardware solution on the other side implementing VPN (perhaps,
> if you have money left to implement some securiyt with some kind of
> external certification /smartcard solution)
>> I know its best practices to NOT have SQL open, but this late in the
>> game,
>> it would take a miracle to get all our customers to change ports. Thanks
>> for
>> your timely suggestions!!
> Just my two cents for that.
> HTH, Jens Suessmeyer.
>

Sunday, March 25, 2012

Bind failed on TCP port 1433

Bind failed on TCP port 1433

Bind failed on TCP port 1433

Bind failed on TCP port 1044.

Bind failed on TCP port 1044.

Friday, February 24, 2012

Best way to update database behind firewall?

Sunday, February 19, 2012

Best way to secure an exposed SQL Server

Best way to secure an exposed SQL Server

Best way to secure an exposed SQL Server

Best way to copy database

Blog Archive

About Me