snort 2.1 intrusion detection second edition phần 9 pot

295_Snort2e_11.qxd 5/5/04 6:58 PM Page 578 578 Chapter 11 • Mucking Around with Barnyard configuration files that will allow us to occasionally extract specific data from the unified files. Finally, we will add the configurations necessary to view alerts on the console in real-time. Remote Syslog Alerting The first capability our system needs is to be able to send alerts to a remote syslog server. While this could be accomplished by enabling syslog alerting directly in Snort, we want to make use of some of the additional features found in the alert_syslog2 output plug-in in Barnyard. For this output, we will be using a syslog server with the hostname “chips.” However, this particular syslog server has been configured to listen for syslog messages on a nondefault port; instead of using UDP port 514, it listens for messages on port 25451. In addition, instead of using the default tag for the alerts, we want to use the string IDS-Alert. Additionally, instead of the default location, gen-msg.map and sid-msg.map are installed in /var/snort/rules. We are going to specify these files in the Barnyard configuration file instead of using the command-line options. For this configura- tion, our Barnyard configuration file looks like: config sid-msg-map: /var/snort/rules/sid-msg.map config gen-msg-map: /var/snort/rules/gen-msg.map output alert_syslog2: syslog_host: chips; syslog_port: 25451; \ tag: IDS-Alert; Since we anticipate having multiple Barnyard configurations, we have saved this configuration to the file /etc/snort/bysyslog.conf.To verify that we config- ured the output plug-in correctly, we run Barnyard with the –R command and look at the section for the output plug-ins enabled for alert records. Doing so, we get the following output: OpAlertSyslog2 configured Syslog Host/Port: chips:25451/udp Syslog Facility: LOCAL7(23) Syslog Severity: NOTICE(5) Hostname: phlegethon Tag: IDS-Alert This matches what we want for our syslog configuration so we know we have the output plug-in configured correctly. If we wanted to verify that the www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_11.qxd 5/5/04 6:58 PM Page 579 Mucking Around with Barnyard • Chapter 11 579 configuration works correctly, we could run Barnyard in batch-processing mode to test it. OINK! When using batch-processing mode to test a configuration, it is wise to use a test unified file that only has a small number of records in it. The last thing that most administrators want is to test a particular alerting configuration by sending thousands of alerts through it. Therefore, it is recommended to generate some unified files that only have a handful of records in them for testing purposes. Now we need to determine the command-line options that we need to specify. From our Snort configuration, we know that the base filename for the unified alert files is unified.alert. We will need to specify this value as the argu- ment to the –f option. Additionally, since we plan to run multiple Barnyard pro- cesses simultaneously in the future, we are going to want to specify a nondefault PID file. We are going to use /var/snort/run/bysyslog.pid for our PID file. Finally, since we want Barnyard to run as a daemon process, we will specify the –D option. Combining all of this with the option to specify the configuration file, we get the following command line: barnyard –c /etc/snort/bysyslog.conf –X /var/snort/run/bysyslog.pid –D \ –f unified.alert Unfortunately, after trying to use this command we notice a problem. In par- ticular, every time we start it, all of the old alerts are also sent to the syslog server, which is definitely not what we want.To solve this problem we need to either enable bookmark support or configure Barnyard to only process new records (or both). Deciding which we want to use depends on what data we want the syslog server to see. For this scenario, our syslog server, chips, wants to see all of the events since we installed this configuration.Thus, if this process is not running for some reason, we still want to receive the events received during that time period. However, we do not want to receive any events that existed before we first added this alerting type.To accomplish this we will enable both the new records only option and the bookmark option.This way, if there is no bookmark file, as would be the case when we first install this configuration, Barnyard will start processing at the most recently received event, and if there is a bookmark www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_11.qxd 5/5/04 6:58 PM Page 580 580 Chapter 11 • Mucking Around with Barnyard file, Barnyard will start processing at the first event after the ones it has already processed. Keeping with the file naming we have used so far, we are going to use /var/snort/run/bysyslog.bookmark as the bookmark file for this configuration. Updating our command line accordingly gives us: barnyard –c /etc/snort/bysyslog.conf –X /var/snort/run/bysyslog.pid –D \ -f unified.alert –w /var/snort/run/bysyslog.bookmark –n This command line gives us exactly what we want for our syslog reporting and we can now add it to our system startup scripts. If we ever need to stop this Barnyard process from running, we can send a signal to tell it to exit. Since the process ID is stored in the PID file, we can read it from there instead of having to find it in a process listing.To stop the Barnyard process we’ve started, use this command: kill `cat /var/snort/run/bysyslog.pid` Database Logging After receiving syslog alerts for a while, we have decided that we want to start using some of the analysis tools that require the data to be stored in a database. While we still want to keep our syslog alerts, we now also need to insert the alerts into a database using the standard Snort database schema. We have read the Snort documentation and have managed to load the schema onto our MySQL database server.The server is running on the host named pizza and we named the database snort. Additionally, we created a database user named snortdb with a password of abc123. We have used the mysql command-line tool to connect to the remote database to verify that we can connect to the database server and access the database. Now, all that is left is to configure Barnyard to send data to the database. We have decided that in addition to the alert information, we also want to have full packet details inserted into the database. Creating the appropriate configuration file for database logging requires a little more work than the one for syslog alerting. In addition to specifying the output plug-in configuration and where to load the message maps from, we may also need to configure the interface, BPF filter, and hostname values. For this particular system, we are running Snort of eth1 and we are not using a BPF filter. We want to use the default hostname, so we will not need to specify an alternate value in the configuration file. Since we want packet logs, we know we need to use the log_acid_db output plug-in. Combining all this information, we have created the following configuration file and saved it to /etc/snort/bymysql.con.: www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_11.qxd 5/5/04 6:58 PM Page 581 Mucking Around with Barnyard • Chapter 11 581 config sid-msg-map: /var/snort/rules/sid-msg.map config gen-msg-map: /var/snort/rules/gen-msg.map config interface: eth1 output log_acid_db: mysql, database snort, server pizza, \ user snortdb, password abc123, detail full The command line for logging events to a database is similar to the com- mand line for syslog alerts. We still want to run in continual-processing mode, we still need to specify an alternate PID file, we still want to enable bookmark sup- port to avoid reprocessing the same data, and we still want to run as a daemon. There are a few changes that we must make. First, we will need to change the filenames for the configuration file, PID file, and bookmark file. Second, since we need to process unified log files instead of unified alert files, we need to change the base filename specified with the –f option. Finally, unlike our syslog case, when we first start processing data, we want to insert all of the old records into the database.Therefore, we will omit the –n option. Making all these changes gives us the following command line: barnyard –c /etc/snort/bymysql.conf –X /var/snort/run/bymysql.pid –D \ -f unified.log –w /var/snort/run/bymysql.bookmark This command line runs Barnyard in the configuration we want. If there is a bookmark file present, then Barnyard starts processing the next record that has been processed. If the bookmark file is not found, then Barnyard will process all of the existing unified log files before processing new records. Of course, if there are many existing unified files, it will take some time before current records are added to the database. Extracting Data So far, we have configured syslog alerting for real-time notification and database logging for our analysis console. While this provides us with considerable flexi- bility, we may also have the need to extract some of the alert data for other pur- poses. Suppose, for example, that we have a report generation tool that we want to use to create periodic reports to show to management.This tool requires that we provide it with data in a CSV file. We would like to be able to periodically process the unified alert data to create CSV files to use with this reporting tool. www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_11.qxd 5/5/04 6:58 PM Page 582 582 Chapter 11 • Mucking Around with Barnyard To do so, we can use the alert_csv output plug-in.This reporting program uses the timestamp, event type, and source and destination IP addresses, and generates statistics about the amount, the type, and the targets of the alerts that were detected. While we could modify the reporting program to read this data from the database, it is far easier to provide CSV file that it already supports.This fic- tional program expects each line of the CSV file to use the following format: timestamp, event message, source IP address, destination IP address Using our knowledge of the alert_csv output plug-in and the Barnyard con- figuration file format, we can quickly write a configuration file that can be used to generate the correct output. We have written such a file and saved it as /etc/snort/bycsv.conf.This file contains the following configuration: config sid-msg-map: /var/snort/rules/sid-msg.map config gen-msg-map: /var/snort/rules/gen-msg.map output alert_csv: report.csv timestamp,msg,srcip,dstip Since we only want to generate these CSV files occasionally, we do not need to run Barnyard in continual-processing mode. Instead, we will use batch-pro- cessing mode and only run it when we need to generate a CSV file to create a report.The command line for this is much simpler than the ones we used for our syslog alerting and database logging. In this case, we only need to specify the config file to use, the directory we want the output to be written to, and the file to process. Supposing that we want the output file to be written to the directory /var/snort/report_input/, we would use the following command: barnyard –o –c /etc/snort/bycsv.conf –L /var/snort/reports/ <filename> This command will process the file <filename> and create the file /var/snort/reports/report.csv. We can then call our reporting program and tell it to use the CSV file as its input. If we wanted to process multiple unified alert files, we could specify multiple filenames on the previous command line. OINK! When using this example, we have to remember that the alert_csv output plug-in will append data to the output file if it already exists. Therefore, we will want to run rm –f /var/snort/reports/report.csv before we run Barnyard. www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_11.qxd 5/5/04 6:58 PM Page 583 Mucking Around with Barnyard • Chapter 11 583 Real-Time Console Alerting The final thing we want from our sample deployment is the capability to log in to our IDS system and display the events to the screen as they are received.The output from the alert_fast output plug-in meets our needs since we only need a limited amount of information about each alert and we want it in a human-read- able format. However, there is a severe limitation to this output plug-in for what we want to do. We want the information displayed to the screen, while the alert_fast output plug-in writes information to a file. While we could modify the alert_fast plug-in to write to the screen, instead we will work around this limita- tion by writing the output to a file and using another program, tail, to display the events as they are written to the file. The first thing we need to do is create the appropriate configuration file. By now, you can probably guess what this file will look like, but will we include it here anyway.The following is the configuration that we are going to use. We have saved this to the file /etc/snort/byalertfast.conf. config sid-msg-map: /var/snort/rules/sid-msg.map config gen-msg-map: /var/snort/rules/gen-msg.map output alert_fast: alerts.out Now that we have our configuration file, we need to construct the command line that we will use to run Barnyard. In this case, we want to run Barnyard in continual-processing mode, but since we will only use this configuration occa- sionally, we do not need to enable bookmark support. However, since we only care about new events, we will want to include the new records only option. In addition, since we are going to run another command to view the contents of alerts.out, we will need to background the Barnyard process.To do this we will use the daemon mode option and specify a PID file as we did for the syslog alerting and database logging configurations. Finally, we will need to specify the log directory to which we want the output to be written.The command line we are going to use for this configuration is: barnyard –c /etc/snort/byalertfast.conf -X /var/snort/run/byalertfast.pid \ -D -f unified.alert –n -L /var/snort/log/ www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_11.qxd 5/5/04 6:58 PM Page 584 584 Chapter 11 • Mucking Around with Barnyard Once we have started Barnyard, we will then want to start the process that will display the events as they are written to the output file.To do this, we run the following command: tail –f /var/snort/log/alerts.out Now all of the alerts will be displayed to the screen as they happen. When we tire of watching the events scroll past at a mind-numbing rate, we simply exit tail and then kill the Barnyard process by running: kill `cat /var/snort/run/byalertfast.pid` While this process works, it has several negative aspects. First, if there are any problems with running Barnyard, all of the errors will go to syslog.Therefore, before we start looking at the output, we need to make sure that Barnyard actually started. Second, this process has the possibility to consume a large amount of disk space if it is left running for a long time or we neglect to remove the output file when we are finished. Additionally, the command line is overly complex for a command we want to run only occasionally. In the next section, we will extend Barnyard by adding a new output plug-in that is designed to solve these problems. Writing a New Output Plug-In In the previous section, we realized that displaying events from a unified alert file to the screen was a complicated process with several deficiencies.This made the final phase of our deployment much more complex and prone to error. It would be much more convenient if Barnyard had a way to display the contents of a uni- fied alert file directly to the screen instead of requiring us to write the output to a file and then process that file with another program. If Barnyard included an output plug-in that rendered output to the screen instead of a file, we could just run Barnyard with the proper configuration and not have to worry about using any other programs. Additionally, the command line would become much simpler. Since Barnyard is an open-source program, we have the ability to add new functionality to it. Additionally, since Barnyard uses a modular design for the implementation of output plug-ins, it is relatively easy to add one.Therefore, to make things work the way we want, we can add a new output plug-in designed to satisfy our particular needs. In this section, we will cover the basics of writing a new output plug-in and adding it to Barnyard. Since this output plug-in is going to display alert events to console output, we are going to name it “alert_console.” www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_11.qxd 5/5/04 6:58 PM Page 585 Mucking Around with Barnyard • Chapter 11 585 Implementing the Plug-In As we shall see here, the basic implementation of a new output plug-in is not a difficult task. All that is required is to set up the source files, implement a handful of functions, and update op_plugbase to initialize the new plug-in when Barnyard starts up.The plug-in we are implementing here is extremely simple. It does not need to handle several of the tasks that a more complex output plug-in may require.This level of simplicity was chosen to focus on the essentials of writing an output plug-in instead of getting bogged down in the intricacies of other tasks (such as connecting to a database). When implementing a new output plug-in, it is always useful to refer to the existing output plug-ins to learn how to handle some of the more complex tasks that may be needed. Setting Up the Source Files The first step when writing a new output plug-in is to create the source files. Most of the output plug-ins contain two source files, a header file and a C file. The alert_console output plug-in is no different and is composed of the files op_alert_console.h (the header file) and op_alert_console.c (the C file). For manage- ability, all of the output plug-ins are grouped together in a single directory, src/output-plugins. We have placed the source files for the alert_console output plug-in in this directory as well. The Header File The header file is used to define functions and variables that are exported from the .c file and made available to other parts of the program. Each Barnyard output plug-in exports exactly one function, the initialization function.The alert_console header file is displayed in the following code.The header files for the other output plug-ins all look very much like this one. /* ** Copyright (C) 2004 Andrew R. Baker <andrewb@snort.org> ** ** This program is distributed under the terms of version 1.0 of the ** Q Public License. See LICENSE.QPL for further details. ** ** This program is distributed in the hope that it will be useful, ** but WITHOUT ANY WARRANTY; without even the implied warranty of ** MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_11.qxd 5/5/04 6:58 PM Page 586 586 Chapter 11 • Mucking Around with Barnyard ** */ #ifndef __OP_ALERT_CONSOLE_H__ #define __OP_ALERT_CONSOLE_H__ void OpAlertConsole_Init(); #endif /* __OP_ALERT_CONSOLE_H__ */ The C File The C file contains the actual implementation of the output plug-in. It is in this file that all of the required functions are implemented.This file contains include directives, function prototypes, and function definitions.The next section, Writing the Functions, explains all of the required functions and shows the implementation of each for the alert_console output plug-in. However, before we can start implementing these, we need to create a basic C file that contains the standard set of include directives and the output plug-in API function prototypes.This section of op_alert_csv.c is shown in the following code: /* ** Copyright (C) 2004 Andrew R. Baker <andrewb@snort.org> ** ** This program is distributed under the terms of version 1.0 of the ** Q Public License. See LICENSE.QPL for further details. ** ** This program is distributed in the hope that it will be useful, ** but WITHOUT ANY WARRANTY; without even the implied warranty of ** MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ** */ #ifdef HAVE_CONFIG_H #include "config.h" #endif #include "barnyard.h" www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_11.qxd 5/5/04 6:58 PM Page 587 Mucking Around with Barnyard • Chapter 11 587 #include "util.h" #include "input-plugins/dp_alert.h" #include "output-plugins/op_plugbase.h" #include "classification.h" #include "sid.h" #include <netinet/in.h> /* Output plug-in API functions */ static int OpAlertConsole_Setup(OutputPlugin *, char *args); static int OpAlertConsole_Exit(OutputPlugin *); static int OpAlertConsole_Start(OutputPlugin *, void *); static int OpAlertConsole_Stop(OutputPlugin *); static int OpAlertConsole_LogConfig(OutputPlugin *); static int OpAlertConsole(void *, void *); Writing the Functions The most difficult part of implementing a new output plug-in is writing the seven required functions.These functions comprise the rest of the C file for the alert_console output plug-in. The Init Function The initialization, or Init, function registers the output plug-in to Barnyard.The registration procedure is fairly straightforward. First, we call RegisterOutputPlugin specifying the name and type of the output plug-in.The name can be just about anything, but most of the output plug-ins include the type of the output plug-in in the name (for example, alert_fast, log_dump).The name of the output plug-in is the keyword that is used when configuring the output plug-in in the Barnyard configuration file.The type of the output plug-in identifies which type of uni- fied records the output plug-in will process.The supported types are alert, log, and stream-stat. This function returns a pointer to a newly created OutputPlugin object. Once we have this object, we just need to add all of our plug-in specific functions to it.The OutputPlugin object has member elements that are used to store references to these functions, and we just use a simple assignment to associate them. Here is the initialization function we wrote for the alert_console plug-in: /* Initialize and register this output plug-in */ www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... UDP ports 111 and 32000–34000 being sent to the Web server or NFS server, respectively Figure 12.1 Network Architecture Snort IDS (1 92 .16 8.20.2) evilhost (207.174.x.x) switch firewall (68.48.x.x) 1 92 .16 8.20.1 Intnernet 1 92 .16 8.10.1 sniffing link hub Web server (1 92 .16 8.10.20) www.syngress.com NFS server (1 92 .16 8.10.30) Active Response • Chapter 12 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com... vs Intrusion Prevention ■ Snortsam ■ Fwsnort ■ Snort_ inline Summary Solutions Fast Track Frequently Asked Questions 605 606 Chapter 12 • Active Response Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Introduction Up to this point we have concentrated on aspects of classic rule-based intrusion detection with the Snort Intrusion Detection System (IDS) It has been shown that Snort. .. address Hence, Snortsam is an active response system, whereas both Fwsnort and Snort_ inline fall into the IPS category www.syngress.com 6 09 610 Chapter 12 • Active Response Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com OINK! Just as the capability to directly interact with the flow of traffic increases as we move from Snortsam to Fwsnort to Snort_ inline, so does the potential impact... defined by the powerful Snort ruleset and can then be logged and/or dropped directly by IPtables Fwsnort functions as a basic IPS, since it is deployed within IPtables and hence runs inline with any network protected by the firewall Michael Rash, a coauthor of this book, wrote Fwsnort, based on William Stearns’ snort2 iptables script Snort_ inline Snort_ inline falls squarely into the intrusion prevention... uses Snort_ inline as an important research tool, and has been released by Jed Haile under the GPL as open-source software Attack and Response It is the goal of this chapter to show how Snortsam, Fwsnort, and Snort_ inline each protect a network from two specific attacks; the first against a Web server and the second against an NFS server.The Web server attack is derived from Snort ID (SID) 807, which Snort. .. was previously calculated) This chapter discusses three software applications; Snortsam, Fwsnort, and Snort_ inline Each of these implements active response capabilities based on the Snort IDS.These applications alter or block traffic by IP address (Snortsam), by transport-layer protocol (Fwsnort), and by application layer (Snort_ inline) We will show how each active response application deals with a reconnaissance... First, let’s look at the Snort rule for SID 807 from the Snort rules file web-cgi.rules (see Figure 12.2) Figure 12.2 WWWBoard passwd.txt Access Snort Rule (SID 807) alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI /wwwboard/passwd.txt access"; flow:to_server,established; uricontent:"/wwwboard/passwd.txt"; nocase; reference:arachnids,463; reference:cve,CVE 199 9- 095 3; reference:nessus,10321;... the direction of a modified version of the Snort IDS Snortsam supports a flexible time specification for blocked addresses so that IPs can be blocked for a period of seconds, minutes, hours, days, weeks, or even years Snortsam runs as a daemon on the firewall host and accepts commands from a special output plug-in for the Snort IDS over an encrypted TCP session Snortsam, written by Frank Knobbe, is free... network for the Web and NFS servers with IP 1 92 .16 8.10.1, and the third is connected to a separate www.syngress.com 611 612 Chapter 12 • Active Response Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com management network for the Snort box with IP 1 92 .16 8.20.1.The line labeled “sniffing link” connects one interface on the dual-homed Snort box to the Web server network.There is... www.syngress.com 597 598 Chapter 11 • Mucking Around with Barnyard Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Summary Barnyard is an event-processing tool that was developed to assist Snort with the task of generating event output It allows the time-consuming tasks of output, such as communicating with a database server, to be separated from the Snort process, thus allowing Snort . http://www.simpopdf.com 29 5 _Snort2 e _11 .qxd 5/5/04 6:58 PM Page 5 92 5 92 Chapter 11 • Mucking Around with Barnyard snprintf(sip, 16 , "%u.%u.%u.%u", (alert->sip >> 24 ) & 0xff, (alert->sip. Split Unregistered Version - http://www.simpopdf.com 29 5 _Snort2 e _11 .qxd 5/5/04 6:58 PM Page 5 91 Mucking Around with Barnyard • Chapter 11 5 91 places in Barnyard to report warnings and errors.The. Version - http://www.simpopdf.com 29 5 _Snort2 e _11 .qxd 5/5/04 6:58 PM Page 595 Mucking Around with Barnyard • Chapter 11 595 op_alert_syslog2.c op_alert_syslog2.h INCLUDES = -I$(top_srcdir) -I$(top_srcdir)/src