Title: SQL security settings Raiders: ChiliHot (red pepper) Issue Date: 2005-4-2 0:10:45
From: R4T recently SQL Injection's attack test has become more intensified, many large websites and forums are induced. These websites are generally used for SQL Server databases, because of this, many people began to suspect SQL Server security. In fact, SQL Server 2000 has passed the US government's C2 safety certification - this is the highest certification level that the industry can have, so use SQL Server is still quite safe. Of course, there is still a gap between orcal, db2, but SQL Server is easy to use and widely becoming the reasons we continue to use. How can I make the SQL Server's setup make people feel relieved? The first step is definitely the latest security patches on SQL Server, and now the patch has been available to SP3. Download address: http://www.microsoft.com/sql/downloads/2000/sp3.asp. If this is not done, then we have not continued it. The second step is to modify the default 1433 port and hide SQL Server. This can prohibit response to the broadcast of the existing SQL Server clients attempt to enumerate the network. In addition, you also need to shield the 1433 port in the TCP / IP filter, and hide your SQL Server database as much as possible. So, let the attack created the account of SQL Server, or immediately use the query analyzer to remotely log in to the next attack. If you construct a malicious statement from the ASP, PHP, etc., there is a problem that needs to view the return value, which will not be able to fall by the direct query analyzer. So we must first do it even if others are injected, they can't let the attackers will be smooth. Modification: Enterprise Manager -> Your Database Group -> Properties -> General -> Network Configuration -> TCP / IP -> Properties, modify your default port here, and SQL Server Hidden. The third step is a very important step, and SQL INJECTION is often generated in web code. As a system administrator or database administrator, you can't always see each code. Even often look at the code, we can't guarantee our negligence above. What should I do? We have to start from the database role to let the database user's permissions to the lowest point. The default rights of SQL Server is really a headache. The permissions are very high. If the permissions are small, sysadmin and db_owner are really love and hate. Attacks one but confirmed that there is a SQL INJECTION vulnerability in the website, and there is certain step by step is how much permissions are to test the SQL Server user of the website. The SQL Server will prompt the error message with SELECT IS_SRVROLEMEMBER ('sysadmin'), or select is_member ('db_owner'), or by user = 0 (let character and digital comparison, SQL Server will prompt the error message, from this information " Some statements such as sensitive information are tested. There is still, I don't dare to say more. It is afraid of the fault, and the people in the alliance are flat. At present, if the website's database user uses SA permissions, add the absolute path you confirmed by the Web, then announce your website over. DB_OWNER privilege, if the absolute path is confirmed, 50% of the opportunity can give your machine in the WEB mode Trojan, such as Haiyang, etc. So we confirm this, we have to create self-propied permissions, let the attacker can't find the lower mouth.
Create an example in the SQL Server online help: Create a SQL Server database role (Enterprise Manager) Create a SQL Server Database role 1. Expand the server group, and then expand the server. 2. Expand the Database folder and expand the database you want to create. 3. Right-click "Role" and click New Database Role command. 4. Enter the name of the new role in the Name box. 5. Click Add to add a member to the Standard Role list, and then click one or more users you want to add. (Optional) Only the user in the selected database can be added to the role. Object privileges requires permission categories called object privileges when processing data or execution procedures: · SELECT, INSERT, UPDATE, and DELETE statement, they can be applied to the entire table or view. · SELECT and UPDATE statement permissions, they can be selectively applied to a single column in the table or view. · SELECT permissions, they can be applied to user-defined functions. · INSERT and DELETE statement permissions, they affect the trial, so they can only be applied to tables or views without being applied to a single column. · Execute statement permissions, they can affect stored procedures and functions. Statement Permissions Creating a Database or Database (such as a table or stored procedure) The activities involved in the data requires that the other class is called statement authority. For example, if a user must be able to create a table in a database, the user should grant CREATE TABLE statement permission. Statement privileges (such as CREATE DATABASE) apply to statements themselves without applicable to specific objects defined in the database. Statement Permissions include: Backup Database · Create Default · Create Function · Create Procedure · Create Rule · Create Table · CREATE VIEW HED INPORTER TELY Permissions Control Things can only be used by predefined system roles or databases Activities performed by the object owner. For example, the SYSADMIN Fixed Server Role member is automatically inherited in the SQL Server installation to perform all permissions. The database object owner also has suggestive permissions, and all activities can be performed on the objects you have. For example, users who have a table can view, add, or delete data, change table definitions, or control allows other users to operate on the table. DB_OWNER has all permissions in the database. DB_ACCESSADMIN can add or delete the user ID. DB_SecurityAdmin can manage all permissions, object ownership, role, and role membership. DB_DDLADMIN can issue ALL DDL but cannot issue a GRANT, REVOKE or DENY statement. DB_BACKUPOPERATOR can issue DBCC, CheckPoint, and Backup statements. DB_DataReader can select all the data in any user table in the database. DB_DATAWRITER can change all the data in any user table in the database.
DB_DenyDataReader cannot select any of the data in any user table in the database. DB_DENYDATAWRITER cannot change any of the data in any user table in the database. Configure the newly built database roles here, such as which table, view, stored procedure, etc. need to be used. Then remove DB_OWNER and DB_SECURITYADMIN, DB_BACKUPOPERATOR, do not give attackers Backup Database and Create Table opportunities, one, the attacker has these two permissions, then your website is still in a very dangerous state. Also pay attention to, when you create a database account, you must not choose the server role. The fourth step is to modify the SQL Server built-in stored procedure. SQL Server estimates are for installation or other aspects, there is a built-in dangerous stored procedure. You can read the registry information, you can write to the registry information, you can read disk sharing information, etc. ... You can see it, you may think that there are other code in my website, no Query the analyzer can check the result output. Give you this permission, can't, or you can't see information. If you want to think about it, you have a big mistake. Tip, if the attacker has a CREATE TABLE permission, create a temporary table, then put the information insert to the table, but SELECT comes out, then compares the number, let SQL Server report error, then the result is all out ... ... so we have to report the attitude of killing, not letting. First of built-in memory to list the dangerous process: xp_cmdshellxp_regaddmultistringxp_regdeletekeyxp_regdeletevaluexp_regenumkeysxp_regenumvaluesxp_regreadxp_regremovemultistringxp_regwriteActiveX automatic script: sp_OACreatesp_OADestroysp_OAMethodsp_OAGetPropertysp_OASetPropertysp_OAGetErrorInfosp_OAStop above the full list in our block, such as xp_cmdshell shielding methods as: sp_dropextendedproc 'xp_cmdshell', if necessary, and then sp_addextendedproc 'xp_cmdshell', 'xpsql70 .dll 'is restored. If you don't know which .dll file is used by XP_cmdshell, you can use sp_helpextendedProc XP_cmdshell to see which dynamic link library is used by XP_cmdshell. In addition, after the XP_cmdshell is masked, the step we need to do is to change the XPSQL70.dll file to prevent the SA from recovering it. We do this here, your SQL Server is basically safe. But information is still the same. After all, SELECT we cannot cancel unless your website is HTML. SQL INJECTION prevention requires us to pay attention to it, this is the law of the rules. We then then analyze the security of SQL Server security in advanced settings. This article If there is any wrong leak, please include it. Thank you ... I also recommend it. SQL Injection test tool NBSI2, which is developed by Comrade Xiaozhu, Xiaozhu, which is a representative effect on SQL Injection's injection, and the other is the Nbwebshell of the younger brother.
These tools can be downloaded to the Alliance website for downloading NB Alliance - Jadesun (pants) QQ: 280155NB Website: www.54nb.com (Source: http://www.spicy-girl.net/forum/thread_show.asp? Forum_id = F062936A96D3C8BD & Thread_ID = 00ADD814D197AF4 & PAGE_POS = 1)
