Here is the challenge. I go to m server MS SQL 2008 and checking the log file, i see a whole lot of fail login for the 'sa' account coming from some external IP addresses.
I go " Oh Gosh" why me. Then I reflect and I realize it has to be me because i did not learn.
Standard Practice.
Don't expose your database on the web.
Before I knew better i use this method to allow external user to connect with their software from remote office, this is the good old, remote access for sql.
All you have to do is just enable remote access, create an SQL Authentication account, open firewall port 1433 and 1434- and you are pretty good to go from any where you have an internet connection.
Well that used to be a great tool for me, but now I don't like to see what is happening on my server.
So I revert to what school taught me.
1. Build client software to run on the client.
2. leave all connection string with the data access layer
3. leave rules with a business access layer.
4. your presentation layer should not even have connect to the business layer.
Ah the good old n-layer approach. These days we have a whole lot of different approaches even with the .NET framework RIA services, REST, SOAP, etc.
So using these kind of tools - You work by building all your connection on your server, you never have to expose or open ports, or even turn on remote services on the SQL Database. In-fact when the infrastructure is controlled by your enterprise, the "Public" Application will never need to know the database. ( this will be transparent, it could be Oracle, MS SQL ,etc)
Today, i am reworking the wheel. Trust me it is not easy to be doing something that you should of done upfront, but this is the price to pay for Cocoa...
I am now building some SOAP web methods - which i am passing as web services calls to my client desktop application.
The client will only be able to know the Web Server (UDDI Services) - the database sites behind the firewall and is not exposed on the DMZ or not port on this server is opened on the WAN side.
In two days I should be saying " Hack it now you suckers!! Hack it nuh!!"
I go " Oh Gosh" why me. Then I reflect and I realize it has to be me because i did not learn.
Standard Practice.
Don't expose your database on the web.
Before I knew better i use this method to allow external user to connect with their software from remote office, this is the good old, remote access for sql.
All you have to do is just enable remote access, create an SQL Authentication account, open firewall port 1433 and 1434- and you are pretty good to go from any where you have an internet connection.
Well that used to be a great tool for me, but now I don't like to see what is happening on my server.
So I revert to what school taught me.
1. Build client software to run on the client.
2. leave all connection string with the data access layer
3. leave rules with a business access layer.
4. your presentation layer should not even have connect to the business layer.
Ah the good old n-layer approach. These days we have a whole lot of different approaches even with the .NET framework RIA services, REST, SOAP, etc.
So using these kind of tools - You work by building all your connection on your server, you never have to expose or open ports, or even turn on remote services on the SQL Database. In-fact when the infrastructure is controlled by your enterprise, the "Public" Application will never need to know the database. ( this will be transparent, it could be Oracle, MS SQL ,etc)
Today, i am reworking the wheel. Trust me it is not easy to be doing something that you should of done upfront, but this is the price to pay for Cocoa...
I am now building some SOAP web methods - which i am passing as web services calls to my client desktop application.
The client will only be able to know the Web Server (UDDI Services) - the database sites behind the firewall and is not exposed on the DMZ or not port on this server is opened on the WAN side.
In two days I should be saying " Hack it now you suckers!! Hack it nuh!!"
Comments
Post a Comment