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

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.. In the box on the left of the screen you

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

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

Snort IDS sensor

Snort IDS sensor Snort alert

messages

Snort alert messages

Syslog messages

Queries Queries

Queries

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

can also put postgresql or mssql if you want to use either of those two databases

for-mat, snort_log, is supported, though there are plans are for ACID to sup-port other IDS types in the future

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

it matches the MySQL user name you created when you set up the database

MySQL password for that user

snort_archive is fine unless you are storing multiple databases on this machine and want more descriptive names

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

as $alert_user above, though you could create a separate user for logging the archives

usu-ally the same value as $alert_password

jpgraph-1.11/src

are jpg and gif

Table 8.4 Variables for Configuring ACID

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 numnum-ber of unique alerts, and the numnum-ber 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

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

• 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

Other Ways to Analyze Alert Data Using ACID

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

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

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

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