Open Source Security Tools : Practical Guide to Security Applications part 28 pptx

Using Databases and Web Servers to Manage Your Security Data 249 This chapter assumes you will be installing ACID on a separate machine from your Snort sensor. Putting them on the same machine is not only a bad idea from a security standpoint, but will also bog down your Snort sensor to the point of making it unusable. The box running ACID should preferably be located at a separate site from the Snort sen- sors—this makes it harder for someone who hacks a Snort sensor to get to your logs. Fig- ure 8.1 illustrates the elements of an ACID-Snort IDS. Installing ACID Once you have all the prerequisite programs loaded, you can finally install ACID. 1. Get the program file from the book’s CD-ROM or download it from the ACID Web site. 2. Place the tar file in your /www/htdocs directory. Unzip it there and it will create its own directory. Figure 8.1 ACID-Snort Intrusion Detection System MySQL Database Ethernet ACID PHP front-end Web server ACID uses PHP to provide a front-end for querying the database from a Web browser. Various sensors collect alert data and forward it to a MySQL database. These may be Snort sensors or syslog-enabled devices Syslog-enabled firewall Ethernet Snort IDS sensor Ethernet Snort IDS sensor Snort alert messages Snort alert messages Syslog messages Queries Queries Queries Howlett_CH08.fm Page 249 Thursday, June 24, 2004 9:54 PM 250 Chapter 8 • Analysis and Management Tools 3. Remove the remaining tar file, as anything left in your root /htdocs directory could be accessed by someone using the Web server. Configuring ACID 1. Change directories to the /htdocs/www/acid directory. 2. Edit the acid_conf.php file. The lines starting with slashes and stars represent com- ments and instructions on how to complete the configuration. The lines starting with $ are variables and tell the program specific things about your system. 3. Change each of these $ statements with the parameters for your system. Table 8.4 lists the variables and information about and recommendations for each entry. Table 8.4 Variables for Configuring ACID Variable Names Descriptions $DBtype The type of database ACID will be using. The default is mysql, but you can also put postgresql or mssql if you want to use either of those two databases. $alert_dbname The IDS that ACID is drawing from. Currently only the Snort native for- mat, snort_log, is supported, though there are plans are for ACID to sup- port other IDS types in the future. $alert_host The host on which the alert database is going to be stored. This can be an IP address or host name. If it’s running on the same machine, it would be localhost. For better security or performance, you could run the database on a separate machine than the PHP Web server. $alert_port Port on which to access the database. If you are hosting it locally, just enter “” for this value. $alert_user The database user name that ACID will use to log the data. Make sure it matches the MySQL user name you created when you set up the database. $alert_password The password for the database user. Again, make sure it matches your MySQL password for that user. $archive_dbname The name of the database for Snort to archive to. The default of snort_archive is fine unless you are storing multiple databases on this machine and want more descriptive names. Howlett_CH08.fm Page 250 Thursday, June 24, 2004 9:54 PM Using Databases and Web Servers to Manage Your Security Data 251 4. After you have saved the file with these parameters, open a Web browser and enter the hostname or IP address of your Web server followed by /acid/ acid_main.php . For example: http://localhost/acid/acid_main.php This displays the ACID configuration page. From here on in, you can use the Web interface to finish configuring ACID. 5. Click on the Create ACID AG button. This will create a database for your Snort data. The default database name is “snort.” 6. Go to http://localhost/acid and you will see the ACID main page for your Snort database (see Figure 8.2). You have now finished configuring ACID and can start using it to manage your IDS systems. Introduction to Using ACID When you first log in, the ACID main page displays (see Figure 8.2). The top area of the main database view gives you overall statistics on the database you are viewing, including Variable Names Descriptions $archive_host The host where the archive database will be located. If it’s on the same machine, this should be localhost . $archive_port The port to log into the database server. Use “” if you are logging locally. $archive_user The database user to log the archive data under. Typically the same value as $alert_user above, though you could create a separate user for logging the archives. $archive_password The password for the database user logging the archive data. Again, usu- ally the same value as $alert_password. $chartlib_path Path to the charting modules. This should be /www/htdocs/ jpgraph-1.11/src . $chart_file_format The file format of chart graphics. The default is png. Other valid formats are jpg and gif. Table 8.4 Variables for Configuring ACID Howlett_CH08.fm Page 251 Thursday, June 24, 2004 9:54 PM 252 Chapter 8 • Analysis and Management Tools its name, the time frame of all the records contained in the database, and the date and time last queried. The section below that has all the summary information on this particular alert group (AG). The AG is the sensor or group of sensors represented in this database. If you want to track different groups of sensors as an entity, such as for different customers or divisions, you need to create a separate database or AG for each one. This is also important when you are running reports and using the archival capabilities of ACID. You can only take search or query actions on an individual AG, not on multiple AGs, so make sure that your sensors are properly organized into distinct AGs. For most companies, it will be sufficient to have just one AG with all your sensors in it. But if you are a consulting company or have large operations with multiple divisions, you may want to put groups of sensors into different AGs so you can track them separately. In the box on the left of the screen you can see the statistics on this AG: the total num- ber of alerts, the number of unique alerts, and the number of different IP addresses appear- ing in the database, both by source IP and destination IP. If you have multiple sensors in your ACID network, you can click on the Sensors item to see them listed. You can narrow your search criteria down to the data from just one sensor. This main page also profiles your alert traffic graphically by each protocol and port scan traffic so you can get a flavor for what kind of traffic is being scanned by your NIDS sensor. Figure 8.2 Main ACID Interface Howlett_CH08.fm Page 252 Thursday, June 24, 2004 9:54 PM Using Databases and Web Servers to Manage Your Security Data 253 Using ACID to Tune and Manage Your NIDS Before your NIDS can be useful at all, you must tune it to your network to eliminate false positive alerts. ACID can be invaluable in this effort. When you first turn on your NIDS, all of the alert signatures will be active and your database will begin to fill up with alert activity. Most of these alerts are going to be false positives at first. To make the alert data relevant to your network, you need to begin removing some of these signatures to elimi- nate much of the erroneous activity and to give you only data that is actionable. Once you have a sufficient number of alerts in the database (at least a thousand on a busy network), you can start analyzing your alert data and eliminating some alert types. Watch your database carefully, as it may not take very long at all for it to fill up, especially with the default Snort rule list. Open ACID and click on the Unique Alerts button. This shows the most recent alerts categorized by alert type (see Figure 8.3). On this page, you see the following information on each alert type: • Signature name • Alert classification • Total number of that type of alert in the database • Sensor number that the alert came from Figure 8.3 Most Recent Unique Alerts Listing Howlett_CH08.fm Page 253 Thursday, June 24, 2004 9:54 PM 254 Chapter 8 • Analysis and Management Tools • The number of different source IP addresses associated with that alert • The number of different destination IP addresses associated with that alert • The time the alert came in You can sort any of the columns by clicking on the little arrows at the top of the col- umn. For example, you can sort by the number of alerts, then click on the largest offender. This narrows down the list to only that alert type. Scan the list and see if you can deter- mine if this is really a security issue or a false positive. Are there any discernable patterns? Are they all coming from the same IP address? Are they all going to the same IP address? Are they happening at regular intervals or do they seem random? If this analysis doesn’t lead to any conclusions, drill deeper by clicking on individual alerts. This lets you see the actual packet that set off the alert, and is very helpful from a forensic standpoint if you are actually being attacked and are trying to respond or pursue the attackers further. Also, be forewarned: If sensitive data is crossing your network, you may inadvertently end up viewing it since you are capturing whole packets of data in the alerts. Make sure you are cleared to see this kind of data. It is also very important that your Snort database is properly secured, because anyone who breaks into your database machine would poten- tially have access to that sensitive information. Another solution to this is to turn down the level of detail captured in the alerts, though this may hinder your ability to use the alerts to track down the culprit. In the example in Figure 8.3, Web-IIS cmd.exe is the most common alert. By clicking on the alert detail, you can see the actual packet that generated this alert (see Figure 8.4). The source IP is shown, along with all the TCP ports and settings. Based on the host name, this packet came from an address in Japan (upper-level domain of .jp). You can use this to determine whether this is an address that should nor- mally be accessing your network. You can also look lower and see the actual packet pay- load. The left side has the packet data in hexadecimal and the right side converts it to ASCII (if it is possible to display that way). This shows the actual commands the sender was trying to issue against your machine. From looking at these, it seems someone was trying to access the cmd.exe command; in other words, get a command line prompt. This is clearly an attack on your system. Unfortunately, this is probably a scripted attack done by an Internet worm, and these types of attacks happen dozens of times a day, as you can see from the large number of cmd.exe alerts in the database. Still, it’s worth keeping an eye on, to see if that IP comes up consistently. You can at least file a complaint with the ISP and make sure the destination machine being attacked is secure against that exploit. You could also take further action against the IP address listed as the source, such as legal prosecution or civil action, if a successful break-in had occurred. At least you now know exactly what kinds of attacks are coming at your network and what they are trying to do. This will better enable you to proactively protect your network and react if it comes under attack. Howlett_CH08.fm Page 254 Thursday, June 24, 2004 9:54 PM Using Databases and Web Servers to Manage Your Security Data 255 Other Ways to Analyze Alert Data Using ACID Who’s Being Attacked? Using ACID, look up the most common IP destination addresses. This shows the IP addresses that are supposedly getting attacked the most, and therefore they are the machines to focus your security efforts on. This also helps you dis- cern false positives from real ones, as you may find one particular machine generating a huge number of alerts from an application it is running. A sudden upsurge in alerts to a particular IP address could point you to an attack on that machine that is underway. Then you can batten down the hatches by running vulnerability scanners, checking patch levels, dropping packets from the offending source IP(s) at the router, and so on. Who’s Doing the Attacking? Look at the IP source address that appears the most often. Go to the source IP list off the main page; this shows the IP and then the Fully Qual- ified Domain Name (FQDN). This tells you where the attack is coming from. Sorting by the number of alerts lets you see the worst offenders in terms of generating alerts. If the IP addresses with the most alerts are on your network, you may have an internal culprit or an application that is triggering an alert. Use the process discussed earlier to drill down to the alert detail level and analyze the alerts. If they are from external IP addresses, you will want to determine if this is legitimate traffic bound for your network or actual attacks. Look at the individual alerts to see what they are trying to do. Click on the IP address; this displays a page with additional information on the address and some options to analyze it further (see Figure 8.5). You can perform various functions on that address such as reverse Figure 8.4 ACID Alert Detail Howlett_CH08.fm Page 255 Thursday, June 24, 2004 9:54 PM 256 Chapter 8 • Analysis and Management Tools DNS lookup, ARIN lookup, and even a Sam Spade search (similar to the tool studied in Chapter 2) from within ACID. The output of these functions should tell you what organi- zation owns those IPs, any contact e-mails for their network operations center, and abuse e-mail contacts (if available). You can use these contacts to register a complaint about these activities. Also, if you see certain addresses showing up again and again, you can filter these IP addresses at your router or firewall. What Service Is Being Attacked the Most? By looking at the most common ports on which alerts are being received, you can see what services are being targeted. If you see a lot of Web-based alerts, you will want to pay closer attention to keeping your Web servers properly locked down. If the alerts show a lot of Windows NetBIOS activity, you will want to look at your Windows permissions and password policies. This will give you a good idea of what services to focus your attention on first. Using ACID on a Daily Basis Once you have ACID running and sufficiently tuned for your NIDS configuration, you should get in the habit of checking it at least once a day to see what new alerts have been generated. A good rule of thumb is to check first thing in the morning and again just before you go home. If you have after-hours personnel working, you could also add check- ing the ACID alert database to their routine. Figure 8.5 ACID Source IP Address Detail Howlett_CH08.fm Page 256 Thursday, June 24, 2004 9:54 PM Using Databases and Web Servers to Manage Your Security Data 257 When you log into the ACID database, you can go immediately to the Snapshot sec- tion (see Figure 8.6) and click on Most Recent Alerts to get a quick view of the most cur- rent activity. This shows you all the alerts in chronological order. If it is still generating too many alerts to be useful, in the Today’s Alerts section select Unique. This shows you all the alerts from today grouped by alert type so you can see which ones are generating the most traffic. The Snapshot section options Last 24 Hours and Last 72 Hours are also use- ful. These let you search on the most frequent alerts, addresses, and ports during various periods. Graphing ACID Data If you are more of a visual person or you need something graphical to show management, ACID comes with the ability to create graphs and charts based on your alert database. This feature is still experimental, and you must have the PHP graphing modules listed at the beginning of this section. However, this does give you some nice options for outputting graphical summaries of Snort data. You can access the graph feature by clicking on Graph Alert Data just below the Alert statistics box off the main ACID screen. This displays the graphing options. You can arrange the data for your graph by: • Time (hour, day, month) versus the number of alerts • IP addresses (source or destination) versus the number of alerts • TCP or UDP ports (source or destination) versus the number of alerts Figure 8.6 ACID Snapshot Section Howlett_CH08.fm Page 257 Thursday, June 24, 2004 9:54 PM 258 Chapter 8 • Analysis and Management Tools Set your parameters using the pull-down boxes and click on Graph Data. Make sure you have filled in every box or you will get an error message. ACID generates and dis- plays a graph. See Figure 8.7 for an example of an ACID graph Maintaining Your ACID database As your alert database grows, you will need to perform some maintenance on it periodi- cally to keep it from getting too big and unwieldy. Also, your statistics and graphs will be more accurate if you archive your early alerts, which will contain many false positives. In addition, cleaning out your database from time to time will make your queries process faster. To archive your alerts, use the query control at the bottom of the main screen. Create a query for the alerts you want to archive, for example, all the alerts generated last year. Then select Archive Alerts as the action for your query. You can selectively archive alerts by date, alert type, or other criteria. You can also choose to just copy the alerts into the archive or to remove them. The archived alerts will be placed in their own database with the name you set in the acid_conf.php file during configuration. You should archive all of your alerts from the first few months of operation when you are fine-tuning the Snort sensor. After that, the data will have more relevance to actual attacks versus false positives. It is also a good idea to archive at least once a year or per- haps quarterly depending on the volume of alerts being logged. As a general rule of thumb, you don’t want more than 100,000 alerts in your database at any given time. Figure 8.7 ACID Alert Data Graph Howlett_CH08.fm Page 258 Thursday, June 24, 2004 9:54 PM . 2004 9:5 4 PM Using Databases and Web Servers to Manage Your Security Data 253 Using ACID to Tune and Manage Your NIDS Before your NIDS can be useful at all, you must tune it to your network to eliminate. database will begin to fill up with alert activity. Most of these alerts are going to be false positives at first. To make the alert data relevant to your network, you need to begin removing some. Page 255 Thursday, June 24, 2004 9:5 4 PM 256 Chapter 8 • Analysis and Management Tools DNS lookup, ARIN lookup, and even a Sam Spade search (similar to the tool studied in Chapter 2) from within