Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 44 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
44
Dung lượng
615,03 KB
Nội dung
290 9.7 Monitor and audit job creation and scheduling options is the Event Monitors folder, which lists all event monitors defined and shows their status as part of the tabular pane on the right. In reviewing this pane I can see that I have only one event monitor—and in this case that’s what I expect. Manually inspecting event monitors and traces can become tedious and is not sustainable in the long run. Therefore, you should either revert to real-time monitoring of event monitor and trace creation or at least periodically audit them and compare activity with a baseline. For the example shown in Figure 9.10, you can set a baseline that defines that the SAMPLE database has only one event monitor with the specifications shown in Figure 9.10. You can then define an automated procedure that will query the event monitors in your database every day and alert you when the list has changed. 9.7 Monitor and audit job creation and scheduling When a Trojan is injected into your database to collect information to be used by an attacker, the attacker can either connect into the database or have the Trojan deliver the information to the attacker. If a connection is made to the database, you can resort to methods you have already seen for monitoring and blocking rogue database connections. If the Trojan is also responsible for delivering the information, you need to monitor jobs that are running in the database. The delivery of the stolen data may be external to the database. For example, a Trojan can write the information to a file where the delivery mechanism is based on other programs, such as FTP, e-mails, and so on. While you can monitor activities at the host level, if your primary responsi- bility is the database, this may be off-limits to you. In addition to the use of event monitors and traces as described in the previous section, database Trojans will often use scheduled jobs. In this way they can insert the data quickly into a table whenever an event fires and then periodically move this information into a file to be sent off using any number of methods. Therefore, in addition to monitoring event cre- ation and/or auditing which traces are active, you should monitor or audit which jobs are currently scheduled within the database. As in the previous section, you can choose to monitor and alert on statements that create a new job (that the Trojan would probably initiate when it is first injected) or choose to audit (and possibly baseline) the jobs you have scheduled within the database. 9.7 Monitor and audit job creation and scheduling 291 Chapter 9 Monitoring for job creation and scheduling follows techniques you learned in previous chapters. For example, to schedule a job in SQL Server that would take the event information into a file, you can use: Add the job EXECUTE @ReturnCode = msdb.dbo.sp_add_job @job_id = @JobID OUTPUT , @job_name = N'trojan', @owner_login_name = N'sa', @description = N'Get Login/Logout events', @category_name = N'[Uncategorized (Local)]', @enabled = 1, @notify_level_email = 0, @notify_level_page = 0, @notify_level_netsend = 0, @notify_level_eventlog = 2, @delete_level= 0 IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback Add the job steps EXECUTE @ReturnCode = msdb.dbo.sp_add_jobstep @job_id = @JobID, @step_id = 1, @step_name = N'RunSproc', @command = N'Exec sp_trojan', @database_name = N'pubs', @server = N'', @database_user_name = N'', @subsystem = N'TSQL', @cmdexec_success_code = 0, @flags = 0, @retry_attempts = 0, @retry_interval = 0, @output_file_name = N'', @on_success_step_id = 0, @on_success_action = 1, @on_fail_step_id = 0, @on_fail_action = 2 IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback EXECUTE @ReturnCode = msdb.dbo.sp_update_job @job_id = @JobID, @start_step_id = 1 IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback Add the job schedules EXECUTE @ReturnCode = msdb.dbo.sp_add_jobschedule @job_id = @JobID, @name = N'ScheduledUpdates', @enabled = 1, 292 9.7 Monitor and audit job creation and scheduling @freq_type = 4, @active_start_date = 20020812, @active_start_time = 10000, @freq_interval = 1, @freq_subday_type = 4, @freq_subday_interval = 10, @freq_relative_interval = 0, @freq_recurrence_factor = 0, @active_end_date = 99991231, @active_end_time = 235959 IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback Add the Target Servers EXECUTE @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @JobID, @server_name = N'(local)' IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback In this example, you would monitor all usage of sp_add_jobserver, sp_add_jobstep, sp_add_jobschedule, and sp_add_job. The other option is to watch and audit the jobs scheduled within the database. As in the previous section, you can do this manually using the database tools. Figure 9.11 shows a user-defined job in the DB2 Task Cen- ter (within the Control Center) and one within the SQL Server Enterprise Manager. This task, however, becomes tedious, and you would do better to automate it by periodically listing all active jobs scheduled within the data- base and comparing this list with your baseline to see whether any changes have been made. Finally, remember that in some environments the scheduler will be the operating system rather than the database. This is especially true in data- bases where the authentication model is based on the operating system. For example, scheduling of jobs that need to run within DB2 on UNIX and Figure 9.11 Reviewing scheduled jobs using the DB2 Control Center and the SQL Server Enterprise Manager. 9.8 Be wary of SQL attachments in e-mails 293 Chapter 9 Linux is often done by adding a cron job (possibly at the user level) and having a script connect to the database. In this case, the script will connect to the database normally, and you can revert to techniques learned in the previous chapter for monitoring database activities. 9.8 Be wary of SQL attachments in e-mails Finally, one last word of caution: Windows Trojans and other “conven- tional” Trojans often come in through e-mails. Database Trojans can too. If someone sends you a SQL blurb, you can inadvertently apply it to your database if you open it naïvely. For example, if I get an e-mail with a SQL attachment (as shown in Figure 9.12) and double-click the attachment in Outlook, it will open up in SQL Server 2005 Management Studio— because that’s how the file extensions are set up on my machine. After open- ing up the procedure in a window, I get a prompt to sign onto my database, as shown in Figure 9.13. This is too close for comfort, and I can easily end Figure 9.12 SQL Attachment in an e-mail message. Figure 9.13 Auto sign-on after opening a SQL attachment. 294 9.A Windows Trojans up creating the procedure inside my database—and using the user privi- leges assigned to my account! 9.9 Summary In this chapter you learned about a new type of threat—Trojans that allow attackers to collect information and/or perform actions within the database continuously, without necessarily connecting to the database. There is an initial connection to plant the Trojan, but once planted, the Trojan can often run independently. All this makes the Trojan a little more difficult (or at least different) to detect, and this chapter showed you the approaches to use to uncover such attacks or mistakes, including the monitoring of the actual methods through which the Trojan is injected into the database. A Trojan is an unauthorized program that runs within your database, and as such it is an example of the need for protecting data from foreign ele- ments that may have direct access to the data. This topic is a wider issue, and the technique used most often to address protection of the data is encryption (of data at rest, in this case)—the topic of the next chapter. 9.A Windows Trojans Windows Trojans usually have two components: a client and a server. The server is embedded into something the victim trusts, and the victim unknowingly activates the server component of the Trojan. Once the Trojan server component is running, it will communicate with the attackers to inform them of the IP of the victim’s machine. The attackers then use the client component to connect to the server, which normally listens on a cer- tain port of the victim’s machine. Trojans often attach themselves to other executables, such as explorer.exe or iexplorer.exe. This ensures that they will be activated and reactivated no matter how many times the machine is powered down. Other techniques for ensuring auto-run include use of the autostart folder, insertion of load=trojan.exe and run=trojan.exe into the win.ini file, or insertion of Shell=Explorer.exe trojan.exe into the system.ini file. The registry is also a common method used to ensure that the Trojan will run: [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ Run]"Info"="c: \trojan.exe" 9.A Windows Trojans 295 Chapter 9 [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ RunOnce]"Info"="c:\trojan.exe" [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ RunServices]"Info"="c:\trojan.exe" [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ RunServicesOnce]"Info="c:\trojan.exe" [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Run]"Info"="c:\trojan.exe" [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ RunOnce]"Info"="c:\trojan.exe" [HKEY_CLASSES_ROOT\exefile\shell\open\command] -> value=trojan.exe %1 %* [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\exefile\shell\open\ command] -> value=trojan.exe %1 %* The last two registry lines use the fact that if the value for these keys is trojan.exe %1 %*, then the Trojan will be executed each time you open a binary file. Some Trojans have a single purpose in life and others are general-pur- pose “let the attackers do whatever they please” -type Trojans. Specialized Trojans include password-sending Trojans that extract passwords stored in various locations on the machine. Another specialized Trojan is one that does keystroke logging—these Trojans send anything you type to the attackers (allowing them to get your passwords). General-purpose Trojans include server Trojans that allow attackers to run anything on your machine, file deletion Trojans, and denial-of-service (DoS) Trojans that just vandalize your system. There are even Trojans that will combat security products—for example, there are Trojans that look for and kill Norton anti- virus software—so it is truly a battle between good and evil. 297 10 Encryption Most databases contain sensitive, proprietary, and/or private information. This can include customer information, employee salaries, patient records, credit card numbers—the list goes on and on. The key to maintaining this information in a secure manner is confidentiality—and companies that cannot ensure security for confidential information risk embarrassment, financial penalties, and sometimes even the business itself. Would you do business with a bank if you discovered that other customers’ account infor- mation (including information that can be used to do wire transfers) fre- quently leaked out and used by criminals? A related subject is that of privacy, and there has been a lot of press on security and privacy incidents. Such incidents are usually reported generi- cally, and it is difficult to understand exactly how information was stolen and how privacy was compromised. However, because most of today’s busi- ness data resides in relational databases, it is likely that at least some, and possibly many, of these incidents involved unauthorized access to this data. The same is true for identity theft: leakage of data from relational databases is a potential disaster when it comes to identity theft. The focus on confidentiality of information has been fueled by two additional developments: Web applications and regulations. In the past five years, Web applications have transformed the way we do business and the way we live, and while such applications have certainly improved access to information, they have also improved access for hackers. The other develop- ment (perhaps spurred by the increase in risk and an increase in the number of incidents) is the emergence of data-privacy regulations that have been forced on many companies across the globe. Such regulations and programs include the U.S. Gramm-Leach-Bliley Act (GLBA), the U.S. Health Infor- mation Portability and Accountability Act (HIPAA), the VISA U.S.A. Cardholder Information Security Program (CISP), the VISA International Account Information Security (AIS), the European Union 95/46/EC 298 Directive of Data Protection, the Canadian B.11-C6 Personal Information Protection and Electronic Document Act (PIPEDA), the Japanese JIS Q 15001:1999 Requirement for Compliance Program on Personal Informa- tion Protection, and more. Hackers can do all sorts of damage, but when it comes to databases, the worst thing that can happen is the theft of proprietary information. In the previous chapters you saw many methods hackers can use to attack a data- base as well as learned what you should do to protect your database envi- ronments. You also learned about best practices that you should follow in order to limit what hackers can do and/or what they can gain. In this chap- ter you will learn about encryption and how it can serve as an additional layer of security—almost a safety net, in case a hacker does manage to get at your data even though you’ve secured your database environment using all the techniques discussed so far. Confidentiality of information is the subject of a mature and age-old domain called cryptography . Of all the areas of mathematics and science, cryptography and encryption are perhaps most closely associated with secu- rity, and people have been inventing ways to encrypt data since the dawn of humankind. For a good, nontechnical, and readable introduction to cryp- tography, see The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography by Simon Singh (Doubleday, 1999). In this chapter you will learn why it is important to use such techniques to ensure confi- dentiality of data and when to use them. I will not spend time on an expo- sition of cryptography, encryption algorithms, and keys because many reference books have covered these topics. Rather, I will focus on two main uses of encryption that are relevant to the topic of database security and how you should use these techniques. The two techniques you will learn are encryption of data-in-transit and encryption of data-at-rest. In both cases, encryption should be used as an additional layer of security that can guarantee confidentiality in case all of your other layers have been breached. Encryption does not come in place of a secure database environment and is not a panacea; you should always do your utmost to create a secure database environment and use encryption to help you deal with risk mitigation in case a hacker does manage to over- come all of your other security mechanisms. The idea is to employ good encryption practices because the impact of encrypted data (usually called cipher text ) falling into the wrong hands is considerably less disastrous than the impact of clear text falling into the hands of the enemy. 10.1 Encrypting data-in-transit 299 Chapter 10 10.1 Encrypting data-in-transit In Chapter 3, you learned quite a bit about the database server as a net- worked service. You learned that most database environments use TCP/IP and that the database server listens to certain ports and accepts connections initiated by database clients. While the ports are configurable, most people tend to use the default server ports (e.g., 1433 for Microsoft SQL Server, 1521 for Oracle, 4100 for Sybase, 50000 for DB2, and 3306 for MySQL). Database clients connect to the server over these agreed-upon ports to ini- tiate a conversation, and depending on the database type and the server configuration, redirect to another port or complete the entire conversation on the same server port. In the same way that you know this, so do hackers. Moreover, because many hackers are system and network geeks, they know a lot about the TCP/IP protocol and specifically about sniffing TCP/IP traffic. At a high level, this means that with the right tools and the right access to the net- work, anybody can tap into your database conversations and eavesdrop on database access—capturing and stealing both the statements that you issue as well as the data returned by the database server. Eavesdropping on your database communications is relatively easy because database communications are mostly in clear text—or close enough to clear text. Therefore, by using simple utilities and mostly free tools, a hacker can listen in and steal information. The way to stop this from hap- pening—and the topic of this section—is to encrypt the communications between database clients and database servers. This type of encryption is called encryption of data-in-transit because all (or pieces of the) communica- tions between the client and the server are encrypted. The encryption occurs at the endpoints. Although I have yet to define what endpoints are (and these will be different in different encryption schemes), one side will encrypt the data being passed over the network and the other will decrypt it—the data stored in the tables and the data used within the application is not encrypted. Although encryption of data-in-transit is becoming popular, I don’t want to give you the wrong impression—most people do not encrypt data- in-transit, and for many environments that is perfectly fine. If you feel that a potential eavesdropper is something you cannot live with, then you should definitely encrypt data-in-transit. If you consider this to be unlikely and you think that on the odd chance that this occurs no heads will roll, then it may not be worth the effort and the performance degradation. Deg- radation depends on the encryption method as well as the database, but as [...]... network packet: 4500 c0a8 80 18 0326 bb 38 4d50 6033 779f f55b 6715 aa90 9ea0 da20 9fb9 90ca ef69 7f65 0109 0330 82 18 75e0 0b81 6c2a ae 78 5b2c 9ad9 83 85 b1a2 1dc3 00b0 d5c3 eb3d 5677 994f f0d6 80 22 4 487 1703 d9cd 5a63 46e6 19da 4 383 84 0d 23f1 d673 54 68 3ef4 ee39 5531 e741 4000 0cea 0000 0100 ab9d e25d cad6 c047 0a6e b3ed a5db 4922 5d7d 244f f409 c1b4 8eb3 4006 3609 0101 d0 18 3 487 79ba f05c 139c ff3f 4b7a... 05 40 0d 00 8e 2c 02 00 00 00 00 05 00 00 34 00 bf 00 d6 00 00 00 00 00 00 05 00 00 00 3f 2e 01 e8 00 02 00 00 01 00 00 00 00 0e 06 5f 51 b8 00 00 00 06 80 00 00 01 00 d7 58 36 00 98 00 16 00 44 00 00 00 80 00 98 22 88 00 58 00 00 00 45 00 00 05 00 00 07 c0 64 06 00 00 00 00 50 0e 00 44 00 00 7f a8 56 00 00 31 00 00 54 00 00 4e 0d 00 08 02 a7 00 78 00 00 00 4e 00 1f 41 00 00 00 17 47 00 68 00 00 00... 15:10:43.32 487 6 goose.guardium.com.1522 > 192.1 68. 1.1 68. 4326: ack 244 win 6432 (DF) 15:10:43.34 984 0 goose.guardium.com.1522 > 192.1 68. 1.1 68. 4326: 1:9 (8) ack 244 win 6432 (DF) 15:10:43.350464 192.1 68. 1.1 68. 4326 > goose.guardium.com.1522: 244: 487 (243) ack 9 win 64232 (DF) S S P P P 10.1 Encrypting data-in-transit 303 15:10:43.350714 goose.guardium.com.1522 > 192.1 68. 1.1 68. 4326: P 9:41(32) ack 487 win 7504... ff3f 4b7a 26d0 b9ff 62cd 62fd 6a6e c9b7 93 c15e 3537 080 a f87f 9 380 23c4 427b 12 98 586 9 f1f1 c721 354b cd89 5a2e af76 629c c0a8 dd89 0005 2bc2 d6cf dd5c 82 44 66b1 6f54 dc7d 44 38 cc5d 03ba c900 781 a 9e00 0339 7e14 4f76 ba1c d775 9355 717d 2a34 3e01 04 78 1bf6 36f2 2067 4b2c 73c3 33c2 | | | | | | | | | | | | | | | | | E M ` w g & 8 P 3 [ i e u l [ V \t 0 D ... 15:10:43.323110 192.1 68. 1.1 68. 4326 > goose.guardium.com.1522: 3477922729:3477922729(0) win 64240 (DF) 15:10:43.323236 goose.guardium.com.1522 > 192.1 68. 1.1 68. 4326: 385 6403494: 385 6403494(0) ack 3477922730 win 584 0 (DF) 15:10:43.323736 192.1 68. 1.1 68. 4326 > goose.guardium.com.1522: ack 1 win 64240 (DF) 15:10:43.32 486 0 192.1 68. 1.1 68. 4326 > goose.guardium.com.1522:... 61 68 00 00 00 12 65 3e 40 05 00 80 ae 00 00 00 73 70 74 00 f2 00 00 d9 00 00 00 65 74 00 80 64 00 00 00 00 00 00 6c 01 0d 06 56 a0 00 0c 01 00 9a 65 00 56 e0 a6 00 00 00 00 00 ae 63 00 b2 a6 a7 00 00 00 00 00 d9 74 00 05 c0 2e 06 00 00 00 00 00 20 00 34 a8 5f 00 10 00 00 00 d4 2a 00 08 01 36 00 59 00 00 00 5c 20 00 00 a8 88 00 da 00 00 00 da 66 00 45 c0 50 00 00 00 00 00 00 72 00 00 a8 18 00 12 98 00... 15:10:43.4327 78 goose.guardium.com.1522 > 192.1 68. 1.1 68. 4326: P 4055:4070(15) ack 4642 win 11319 (DF) 15:10:43.622017 192.1 68. 1.1 68. 4326 > goose.guardium.com.1522: ack 4070 win 63407 (DF) What I can see from the first line is the client machine with an IP of 192.1 68. 1.1 68 connecting to the server The client port is 4326 and the server port is 1522 Note that this is not the standard Oracle listener port, and. .. tunnel any conversation, including database sessions The really neat thing is that the database is oblivious to this action, and it is completely transparent to both the database client and the database server From a database server perspective, the packets that are delivered to the database networking libraries are “normal” because they are decrypted before they reach the database On the network the data... IPSec layer, and both database client and database servers send and receive the information unencrypted, so there is no setup at the database level 10.2 Encrypt data-at-rest The other use of encryption in database environments is the encryption of the data itself (i.e., encrypting the values that are stored within the database 10.2 Encrypt data-at-rest 317 tables) This additional layer of security is... 54 70 55 00 6e 20 0c 45 72 00 30 48 00 52 54 54 30 00 00 45 38 48 74 54 00 69 28 00 13 64 08 33 5f 00 5f 45 49 27 0d 00 44 35 5f 73 48 29 64 54 00 00 69 41 31 41 12 53 52 4d 00 41 00 44 37 54 2f 5f 2e 2e 4e 00 00 75 55 37 43 00 45 20 45 01 55 20 41 44 45 31 50 2f 67 53 0c 00 6d 54 00 4c 00 53 53 5f 00 54 30 32 00 52 31 52 73 75 20 41 13 2e 48 00 04 00 53 45 5a 00 48 42 46 00 4d 00 4f 61 61 56 55 6c . 0e d7 98 07 7f 08 00 45 00 V 4 E. 0010 01 79 5d 4d 40 00 3f 06 58 22 c0 a8 02 17 c0 a8 .y]M@.?. X" 0020 01 a8 05 f2 0d bf 2e 5f 36 88 64 56 a7 47 50 18 _ 6.dV.GP. 0030 2c 37 2f 98 00 00. db 46 3e 74 00 0d 56 b2 05 34 08 00 45 00 F>t V 4 E. 0010 00 c8 94 79 40 00 80 06 e0 a6 c0 a8 01 a8 c0 a8 y@ 0020 02 17 0d bf 05 f2 64 56 a6 a7 2e 5f 36 88 50 18 dV _6.P. 0030 f7 af 04 4d 00. 192.1 68. 1.1 68. 4326: P 9:41(32) ack 487 win 7504 (DF) … 15:10:43.4327 78 goose.guardium.com.1522 > 192.1 68. 1.1 68. 4326: P 4055:4070(15) ack 4642 win 11319 (DF) 15:10:43.622017 192.1 68. 1.1 68. 4326