March 9, 2012 at 7:57 am
Hello all,
I've been around the net and back trying to understand how SQL Server 2000 works....
I have installed the personal edition on a desktop running XP pro....no prob there.
I have setup three or four users with their IDs and passwords...no prob there either.
But I cannot see the bigger picture as to how a person from another PC on the net logs into the server and hence a particular DB i've given them access to when setting up their IDs and pws.
I have a web page front end calling on an access DB at the moment and can use the IP address of the machine to see that web page, but how do I get the Server 2000 login box asking for ID and pw when I stop using the access DB and use the SQL DB.
The server listens on port 1433 as per default setup. Do I append the IP address with :1433 to get the incoming connection to divert from the default web page and use port 1433 and then will the server ask me via a box for a user ID and pw ?.....or does this bit have to be done in code within the classic ASP webpage I'm using. Is the server 'blindly' listening on port 1433? how does it not get attacked constantly by hackers?.. or is it not really connected to the net via my port forwarding enabled router?.....as u see i am lost as to the big picture of using a personal server. I know some of u are saying I should put it back in the box and forget about it, but I would like to see how to use a server which I can then connect to from anywhere securely.........
March 9, 2012 at 12:39 pm
If you expose it directly - it would likely be attacked continuously.
A few recommendations:
1. drop "classic ASP". it's unfortunately got a fair amount of weaknesses, making it a rather popular target for attacks and exploits. ASP.NET has some better options on how to secure applications
2. unless you have a server OS to host this all - you will want to leverage "split" authentication (where you secure the application and make the user log into the application, but the application uses separate, restricted access credentials to talk to the DB).
3. Assuming that web site is being served up from within your internal network (through a secure port forwarder), prevent your SQL server from responding to any direct inquiries from any external machine.
4. secure the channel between your web server and IIS. You can do that using SSL or other methods.
Here's some reading on the types of access you want to set up.
http://msdn.microsoft.com/en-us/library/ff649362.aspx
http://msdn.microsoft.com/en-us/library/ff649357.aspx
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
March 10, 2012 at 10:48 am
Very many thanks Matt for replying. I now have a lot of reading to do.
Cheers
Victor
March 11, 2012 at 6:25 pm
Security is a science "per se", and there is nothing 100% secure.
But, for your optimal/reasonable security needs probably you can do a few steps:
- upgrade to SQL2008R2 and latest Service Pack (at least latest SP if you stay with SQL 2000)
- in connection string you define how you connect to db. Use windows authentication (no username/pwd stored anywhere in your app, not even encrypted).
- that account should not be db_owner, or be able to drop anything directly. It should be able just to call stored procedures it needs (or all stored procedures in worst case, and no direct table access).
- limit IP's that can connect to your DB
- in your app, do not use string concatenation when you call stored procedures or build sql commands. Use parameters instead. That will prevent sql injection attacks.
E.g. this is BAD code (note the "+" operator, sql string changes as username changes - very bad!):
sql = "SELECT name FROM Persons WHERE USERNAME="+username;
This is good (sql is static, it is the same no matter what username value we have):
sql = "SELECT name FROM Persons WHERE USERNAME=@username";
parameters.Add("@username", username);
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply