Notice that the code validates that the payload contains well-formed XML. This simply means that all nested elements are closed properly. It doesn’t require the use of an XML schema. That would require the statement VALIDATION=VALID_XML.
Now that the message types have been created, you can create a contract that uses them by typing the command in Listing 2. The contract, named IncContract, specifies the message type of RequestMessage for sending by a conversation initiator. Notice that the code specifies a Reply-Message that can be sent by the target. We won’t be using that message type in our solution, but adding it to the contract allows you to use it at a later time with little effort.
Now that you’ve created the message type and the contract, you can create the queue for storing the incoming security incidents. You also need to create the service, which you can accomplish with the first pair of CREATE QUEUE and CREATE SERVICE commands in Listing 3. Because SQL Server 2005 supports only dialogues and not monologues, you have to create another queue and service that you won’t actually use (i.e., the second CREATE QUEUE and CREATE SERVICE pair in Listing 3). This technique lets you implement a monologue scenario with SQL Server 2005’s dialogue structure.
The Service Broker is now set up, but you also need a stored procedure to process messages dropped into TargetQueue. Listing 4 shows the code for the stored procedure. You’ll notice that the code doesn’t actually use InitiatorQueue. As I mentioned earlier, it exists to set up the conversation appropriately because SQL Server 2005 lacks support for monologues. Ultimately, the stored procedure takes the input of an incident description and outputs it to a SQL Server table.
At this point, you have the infrastructure in place to begin entering data in the queues; however, I want to show you how to create a simple ASP page that can be called to place an entry in the queue. Listing 5 shows some sample code that you could save in an ASP file and place on an internal IIS server. You’ll notice the simple way this ASP page can be called. It looks for a parameter called Description to provide the information related to the incident. For example, incident.asp?Description=some_code would work just fine.
Utilizing the Solution
With the infrastructure in place, any device can now report a security incident with a simple HTTP connection. For example, assuming the previous ASP code was saved to a file named incident.asp at the root of a Web server, you could enter the following URL
http://webserver/incident.asp?Description=
Unusual Firewall Activity
into a Web browser to add a new security incident.
Many OSs support command-line tools that you can use to execute HTTP GET commands (which is what a Web browser does when you enter a URL). As long as you can run a batch file when a security incident occurs on a Windows computer, you can add information to the incident log. You need only a client computer with a full TCP/IP stack and an application that can submit an HTTP request. The valuable UnxUtils collection available at unxutils.sourceforge.net includes a wget executable for the Windows command line. With this free utility, you can execute the following or a similar command:
wget http://webserver.com:80/
incident.asp?description=
405:10.10.10.43
Take note of how the description is formatted in the wget example. Instead of a descriptive phrase such as “Unusual Firewall Activity,” there’s a code (405) and the IP address of the source device. You’ll probably want to develop a set of standard codes for security events that occur in your organization. For example, the code 304 could represent a possible malware infection and the code 305 could represent a possible spam attack. Mapping wordy attack descriptions to simple numeric codes keeps your incident tracking database small and the HTTP commands simple.
That’s it! No need to install a SQL Server client utility, because you’re communicating with Service Broker via a stored procedure that’s executed through an ASP page on the IIS server. For many network administrators and IT employees, this functionality is phenomenally helpful. You could expand it well beyond just security logging; it could easily become the framework for centralized logging of any event categories that you must report. It could even save you thousands of dollars in client agent licenses for third-party applications. Of course, you’d need the proper SQL Server 2005 or later licensing and the sweat and tears to fully develop your solution.
You could enhance this logging solution to provide automatic notification of specified events based on risk-level IDs or the point on the network at which the incident occurred. This could be accomplished by using the Notification Services architecture or a custom-built solution that simply monitors the incidents table for the relevant entries. Additionally, you could create modules so that more devices could communicate with the database. For example, a solution could be built that receives SNMP alerts and forwards them to the security incident database when applicable.
The most obvious enhancement to this solution would be to take even greater advantage of the Service Broker component. You could implement an activation scheme that fires a stored procedure as soon as an item is placed in TargetQueue. This would mean that the automatic processing currently employed would be removed from the uspIncident stored procedure. The new stored procedure could still add the data to the incidents table, but it could additionally look for specific codes and then take predetermined actions such as launching external scripts that would shut down sections of the network or individual computers that might be problematic. Once you have the infrastructure in place, the hooks and branches that can be implemented are practically endless.
The ultimate goal of this article is to provide you with a real-world example of using Service Broker to solve a problem. I hope it helps you to begin thinking of even more and better ways to use this technology. I’d love to hear from you if you have ideas about how to expand this example.
End of Article
Prev. page
1
[2]
next page -->
