snort 2.1 intrusion detection second edition phần 7 ppsx

76 579 0
snort 2.1 intrusion detection second edition phần 7 ppsx

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

426 Chapter • Dealing with the Data Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Figure 8.22 Top 20 Attacking IPs The IP links present in the Source IP column will take you to a page dis­ playing a summary of signatures triggered by the traffic from this particular source.This summary page also contains links that will help you discover to whom this IP address belongs—whois lookups, DNS lookups, and so forth Optional SnortSnarf features include a tool for creating incident reports.This feature resembles the ACID alert grouping and e-mailing Its installation is described in README.SISR in the SnortSnarf distribution package The SnortSnarf script has many options other than those described in this section It is possible to specify various filters by: ■ Sensor ID ■ Alert priority ■ Date ■ Time The main difference between SnortSnarf and ACID is that you need to specify everything on the command line and not interactively.To sum up, SnortSnarf (similarly to ACID) helps you bring data together.The format is such that potential problems can be easily analyzed and researched.This analysis will verify if there was an incident, and Snort alert logs and system log files will pro­ vide data of what was possibly compromised When a security incident occurs, www.syngress.com Dealing with the Data • Chapter Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com the link in the SnortSnarf browser window allows the analyst to review the inci­ dent data and start looking for ways to prevent further incursions.This further research and analysis of SnortSnarf reports will help provide enough information to make incident-related decisions.The analysis should help identify whether your defense in-depth plan failed With this knowledge of what failed, where it failed, and how it failed, you can make plans to prevent unauthorized access in the future Damage & Defense Beware of the External Intranet As with any Web-based security monitoring tool, ensure that you lock down access to the Web server that is serving up your intrusion data One prevalent reconnaissance tactic is to Google for IDS data For instance, if an attacker wants to see whether your site is running SnortSnarf and whether you’ve left the resulting HTML files open to the world, all that attacker has to search for is: site: www.yourdomain.com "SnortSnarf brought to you" This will bring up SnortSnarf pages, which at the bottom contain the string “SnortSnarf brought to you courtesy of Silicon Defense.” It’s amazing how many people leave their intrusion data on the Web for attackers to see Some attackers will go to the lengths of attacking your site, then checking your IDS logs to see if they have triggered an event To protect your IDS data, place your Web server and SnortSnarf repository on a management network that is not connected to the Internet Utilizing the defense-in-depth strategy, configure Apache’s htac­ cess list to allow only authorized hosts to connect to the SnortSnarf server Network and host-based firewalls can also be used to limit the exposure of the SnortSnarf data www.syngress.com 427 428 Chapter • Dealing with the Data Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Swatch Automating part of the alert monitoring and event triage is an essential part of the intrusion analyst’s job Swatch is a log-monitoring tool designed to watch log files and match patterns for events of interest Swatch can be configured to mon­ itor any log files In this example we will monitor Snort logging to syslog Using Swatch after you have created the configuration file is simple Swatch can be started in a variety of ways: ■ Via a Snort initialization script ■ Used separately as part of init set of scripts ■ Manually The following is a command line used for starting Swatch: /usr/local/bin/swatch -c /var/log/.swatchrc -t /var/log/snort/alert & This line assumes that Swatch is installed in the /usr/local/bin directory, the configuration file swatchrc is located in the /var/log directory, and the Snort alert file is in the /var/log/snort directory Note that the -c option defines the location of the configuration file, and the -t option tells Swatch which log file to monitor The & sign at the end of the line means that this command is started in the background Background processes cannot communicate with the terminal or stdin/ stdout streams, so you cannot use echo actions in the Swatch configuration file if you want to start it in the background You can also set up Snort logging to syslog in addition to its standard log files using the output option (in snort.conf ): output alert_syslog: LOG_AUTH LOG_ALERT Then, each alert will appear in /var/log/messages (the default location on Red Hat) in the following way (lines are wrapped in this example): Feb 12 19:19:00 witt snort: [117:1:1] (spp_portscan2) Portscan detected from 10.1.1.34: targets 21 ports in 24 seconds {TCP} 10.1.1.34:33531 -> 10.1.1.30:1439 Feb 12 19:19:01 witt snort: [1:1418:2] SNMP request tcp [Classification: Attempted Information Leak] [Priority: 2]: {TCP} 10.1.1.34:33531 -> 10.1.1.30:161 Feb 12 19:19:01 witt snort: [1:615:3] SCAN SOCKS Proxy attempt [Classification: Attempted Information Leak] [Priority: 2]: {TCP} 10.1.1.34:33531 -> 10.1.1.30:1080 www.syngress.com Dealing with the Data • Chapter Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Feb 12 19:19:01 witt snort: [111:12:1] (spp_stream4) NMAP FINGERPRINT (stateful) detection {TCP} 10.1.1.34:33541 -> 10.1.1.30:21 Feb 12 19:19:01 witt snort: [1:628:1] SCAN nmap TCP [Classification: Attempted Information Leak] [Priority: 2]: {TCP} 10.1.1.34:33543 -> 10.1.1.30:1 Feb 12 19:19:01 witt snort: [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection {TCP} 10.1.1.34:33544 -> 10.1.1.30:1 Feb 12 19:19:02 witt snort: [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection {TCP} 10.1.1.34:33539 -> 10.1.1.30:21 Each alert Snort generates starts with snort: prefix, so you might set up an action in the Swatch configuration file to react to all syslog messages with this string: watchfor /snort:/ mail addresses=abuse@yourcompany.net,subject= - Snort Alert! ­ throttle 00:00:10 Alternatively, if you want to receive e-mail alerts on IIS-related attacks, you can use something like this in your swatchrc: watchfor /IIS/ mail addresses=abuse@yourcompany.net,subject= - Snort Alert, IIS attack! -­ throttle 00:00:5 Figure 8.23 shows a more complicated example of a Swatch configuration file Figure 8.23 Swatch Configuration File for Monitoring Snort Syslog Alerts watchfor /MS-SQL/ echo bold mail addressess=root,subject= - Snort MS-SQL Attack Alert ­ exec echo $0 >> /var/log/MSSQL throttle 00:10 watchfor /Portscan detected/ echo bold mail addresses=root,subject= - Snort Port Scan Alert ­ exec echo $0 >> /var/log/portscans Continued www.syngress.com 429 430 Chapter • Dealing with the Data Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Figure 8.23 Swatch Configuration File for Monitoring Snort Syslog Alerts watchfor /approved AXFR/ echo bold mail addresses=root,subject= - Snort Zone Transfer Alert ­ exec echo $0 >> /var/log/zonetransfers When this configuration is used, alerts related to MS-SQL exploits will be emailed to the “root” user and stored in a file /var/log/MSSQL Port-scanning alerts and zone transfers will also cause Swatch to send an e-mail to the same user, but with a different subject line, and store the e-mails in different files.The following action is useful for producing separated log files for different types of alerts It adds a matched log line to the specified file: exec echo $0 >> file Swatch can also be used in monitoring syslog files for other events that are not generated by Snort For example, the following rule will alert the “root” user about failed authentication events: watchfor /failed/ echo bold mail addressess=root,subject=Failed Authentication OINK! It is more convenient to monitor syslog events than, for example, Snort alert files, because syslog messages are always one line, whereas in alert files, each alert produces several lines of text, which is not always useful for pattern matching To conclude, Swatch is a simple but powerful tool for real-time monitoring and alerting www.syngress.com Dealing with the Data • Chapter Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Analyzing Snort IDS Events In Snort, as we have discussed, there are two principle output systems: packet logs and alert messages We begin our exploration of intrusion analysis by examining the products of these two systems: alert and packet logs Here we see a Full Alert mode alert, which in this case is alerting us to a classic teardrop attack: Full Alert: [**] [113:2:1] (spp_frag2) Teardrop attack [**] 02/19-16:52:06.046302 172.16.10.151 -> 172.16.10.200 UDP TTL:3 TOS:0x0 ID:242 IpLen:20 DgmLen:24 Frag Offset: 0x0003 Frag Size: 0x0004 Begin the Analysis by Examining the Alert message The first key to looking at this alert is that we have a message describing the alert: (spp frag2) Teardrop attack.The spp_frag2 lets the analyst know that a Snort preprocessor known as frag2 (handles fragmentation processing) has fired the alert Following the message we have the basic statistics regarding the event, from source and destination IPs, timestamp, and pertinent protocol information Validate the Traffic Next we validate the traffic by looking at the packets involved in these attacks We will concentrate on identifying the target and the attacker as well as checking to see if protocol behavior is correct Examples of what to look for here: tcp handshake completion, proper sequence numbers, fragmentation ID reuse, frag­ mentation overlaps (this is what we see here) or gaps Is the source address of this attacked spoofed? # snort –dvr teardrop_attack.cap 02/19-16:52:06.029368 172.16.10.151 -> 172.16.10.200 UDP TTL:3 TOS:0x0 ID:242 IpLen:20 DgmLen:56 MF Frag Offset: 0x0000 Frag Size: 0x0024 04 01 00 87 00 24 00 00 00 00 00 00 00 00 00 00 .$ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 www.syngress.com 431 432 Chapter • Dealing with the Data Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 00 00 00 00 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 02/19-16:52:06.046302 172.16.10.151 -> 172.16.10.200 UDP TTL:3 TOS:0x0 ID:242 IpLen:20 DgmLen:24 Frag Offset: 0x0003 Frag Size: 0x0004 04 01 00 87 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Tcpdump view of the Teardrop attack: # tcpdump –nnvvr teardrop_attack_cap 16:52:06.029368 172.16.10.151.1025 > 172.16.10.200.135: [no cksum] udp 28 (frag 242:36@0+) (ttl 3, len 56) 16:52:06.046302 172.16.10.151 > 172.16.10.200: (frag 242:4@24) (ttl 3, len 24) Snort and the granddaddy of sniffers, tcpdump, each have different output formats Snort was written with the analyst in mind, whereas tcpdump has been a longtime standard We notice right away that Snort prints out the Fragment Offset and the Fragment Size in hexadecimal In the following, we the simple conversion by hand: Packet #1: Frag Offset: 0x0000 Frag Size: 0x0024 Fragment Offset is 0, as no value is set To calculate the decimal equivalent of the Fragment Size, multiply the hex­ adecimal value by powers of 16, as outlined in Table 8.2 Table 8.2 Fragment Size Power of 16 163 162 161 160 Original hex Resulting decimal 0 0 32 4 www.syngress.com Dealing with the Data • Chapter Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com We multiply the hexadecimal value by powers of 16.The resulting decimal value equals 32 + = 36.This indicates that this fragment carries 36 bytes of data to be placed at offset (zero) What we can see here is that we have two fragments.The first fragment (fragment id 242) has an offset of (zero) and a length of 56 bytes.The second fragment attempts to overwrite previous data by instructing the stack to place bytes of data at offset 24 Identify the Attack Mechanism Once we have our alert message and packet logs, we begin to triage and analyze the event What rule or subsystem triggered this event? Is it a good rule? What type of an attack is it? Are we vulnerable? Are we running that service? Is the source IP spoofed? In this case we see a second fragmented UDP packet attempting to overwrite the data in the first fragment On a susceptible host, this attack will cause a tem­ porary denial of service since protocol stacks were not designed to travel in reverse (overwrite previous data).This is commonly known as a teardrop attack Could the attacker have spoofed the IP addresses? Sure.This is a UDP DoS attack that does not require a response from the target.The attacker can spoof any routable IP address and have the potential to successfully disable their target Note: The IPs in this incident have been changed to protect the innocent Correlations Now that we have identified the attack mechanism, the next step is to determine if there have been any other events that were in some way connected to this attack Our correlation process will attempt to answer the following questions: ■ Were there any other successful and/or similar attacks within a threshold of time? ■ Was this the only event associated with this IP address? ■ Can you find any additional hits with this source address in your firewall or Web server logs? ■ Was this the only target address to receive this event type over the last few hours or days? ■ Have you noticed any rise or fall in trends related to this particular event type that would suggest a mounting risk to your organization? www.syngress.com 433 434 Chapter • Dealing with the Data Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com ■ Could this be a precursor to a new worm? We run this simple shell command to find out how many Snort alerts we received that match the teardrop attack (this sample was taken from a Full Mode Alert file): # grep –B '172.16.10.151' alertfile | grep '(spp_frag2) Teardrop attack' | sort -n | uniq -c 853 [**] [113:2:1] (spp_frag2) Teardrop attack [**] In this particular incident we find that there were 853 attacks in less than a minute from the same source IP to the same target No other logs from that IP address were present in our IDS or firewall logs OINK There are a number of places online to find correlation information Some of our favorites are: ■ ■ ■ ■ ■ http://isc.incidents.org/ http://aris.securityfocus.com/ www.mynetwatchman.com/ http://wormradar.com/ or the mailing list at incidents@securityfocus.com Conclusions This incident took place in less than a minute and there were no network defenses in place to stop this attack Go back to the attack mechanism portion of the analysis and formulate your defensive recommendation.There are a number of solutions to this problem First and foremost, pick a firewall and design a policy that can block many of the most popular fragmentation attacks As a second solution, you might want to look into a “traffic scrubber.”This device or software will “normalize” traffic as it enters your network If the fragments don’t align, the scrubber can be configured to correct the overlap or gap If the TTLs arrive at your network at a lower number than the maximum depth of your network, the scrubber can raise the TTL In fact, these traffic scrubbers are good defenses against the evasion and insertion attacks outlined in Tim Newsham and Tom Ptacek’s paper (www.snort.org/docs/idspaper/) www.syngress.com Dealing with the Data • Chapter Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Summary The ultimate goal of installing and using Snort is to help a security analyst mon­ itor and study intrusion attempts Currently, intrusion-related traffic on the Internet is high If your sensor is located on a busy network, it can generate megabytes of data each day Obviously, you need some tool to automate the pro­ cess of monitoring and alerting, because it is impossible for a human to browse such a huge amount of data and come to any meaningful conclusions A variety of tools are available for this purpose We covered a number of them, each with a different functionality Swatch is a tool for real-time log file monitoring and alerting; SnortSnarf provides features for generation of static HTML reports from log files; and Snort_Stat.pl is a simple Perl script to extract event data summary reports from your Snort alert files ACID is a Web-based interactive console for exploration and management of Snort alert database It can also use data from other intrusion detection engines, provided that they are somehow imported into the same database A script pro­ vided in Snort distribution is able to import some of these alerts ACID provides the means to perform database queries (from metasignature level to the packet contents) and database management—trimming and archiving of selected alerts and various graphing tools It also allows an analyst to group selected events into logical alert groups for further study or e-mail reports to specified persons Finally, SGUIL is on of the most powerful Snort event database front ends out there It is a graphical tool that has been designed to be intuitive to an ana­ lyst From the GUI, an analyst can analyze event data and packet logs, populate reports, and send abuse e-mails These tools merely scratch the surface of the vast number of data analysis tools that are available to analysts Whether you choose these free solutions, go with a commercial solution, or end up coding your own IDS analysis suite, these tools and the functionality they provide will give you the basis from which to build your analysis suite www.syngress.com 435 Optimizing Snort • Chapter 10 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com You have numerous methods to minimize resources and time during the initial setup process Installation and configuration scripts can quickly help auto­ mate numerous manual tasks such as system rebooting, log analysis, and user man­ agement In addition to automation scripts, the method by which you initially set up your sensor will play a huge role in the flexibility of and future reuse of your sensor configuration Creating reusable configuration and variable files plays a sig­ nificant role in getting the most out of your installation and development time Furthermore, the ability to tweak your preprocessors and output plug-ins can dra­ matically decrease the burden of the CPU load Lastly, there is always the option to clone the drive; however, this only works if you want the sensors to be exactly alike, which is not always a viable option for distributed networks The following references serve as a quick refresher if you would like to get detailed information about any of the topics previously mentioned ■ Installation tweaks—Chapter 3, “Installing Snort” ■ Creating portable configuration and variable files—Chapter 5, “Playing by the Rules” ■ Flexible preprocessors—Chapter 6, “Preprocessors” ■ Flexible output plug-ins—Chapter 7, “Implementing Snort Output Plug-Ins” The Initial Decision Most analysts would consider it unheard of to analyze network intrusion attempts in anything except real time or very near real time, but it is a considera­ tion that has been made by several global and small enterprises Real-time intru­ sion detection is an around-the-clock constant process of protection for your organization and its environment Believe it or not, a small number of companies have implemented hybrid approaches to monitoring their intrusion detection infrastructures, which can have grave effects on system speed, organizational maintenance time, and upfront deployment costs Now you might be asking yourself, how would the decision of when to monitor the devices affect the speed at which they operate? The answer is quite simple: Snort has numerous features that you might have become familiar with, including its output modules—specifically, the alerting and logging modules If you were to select a logging mechanism that did the upfront packet formatting by the Snort executable, it would impact the overall performance of your www.syngress.com 487 488 Chapter 10 • Optimizing Snort Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com installation and configuration Conversely, if you elected to implement Barnyard, it would post-process the captured data and conduct formatting via another pro­ cess or even another system The major question your organization needs to pose to itself when deciding on the timeframe for analysis is, when will the data be read by a human analyst? If you don’t plan to monitor your IDS constantly or have an analyst sit in front of the monitor 24/7, it probably doesn’t make sense to log your alerts in such a way A very common practice for organizations that implement their IDS infrastructures in this manner is to simply review the logs once a day, first thing in the morning In addition to determining when the logs and alerts will be analyzed, you also have to determine the architecture or infrastructure design of your imple­ mentation Inline versus passive, log storage for 30 or 180 days, and real-time analysis are all questions that have to be answered Deciding Which Rules to Enable Snort’s ruleset is the most critical asset of your intrusion detection sensor In addition to being the most complex and time-intense aspect of the setting up Snort, it is also the most configurable For that reason, it is very easy to improp­ erly configure your system We have seen both extremes—sensors with only 10 rules because the administrator thought he only needed rules for current vulner­ abilities and threats and sensors with over 1500 rules that created a 10 to 35 per­ cent packet loss ratio on normal to peak traffic periods One of the most popular and effective methods for determining appropriate rulesets adopts two key principles: ■ Identifying key protocols and services that are used on your network If NetBIOS and HTTP services are the only services used on a particular network segment, only rules referencing those services need to be applied An additional general rule that defines external sources attempting to connect to a nonutilized network service should be cre­ ated to log the traffic ■ Determining the level of granularity required for your evidentiary logs For example, if the network is merely a development network, the attack details and rules might not need to be as stringent as for a finance or publicly facing network Figure 10.1 is a tool that you can use to assist in ensuring the proper catego­ rization for Snort rules and rulesets.The tool requires a bit of subjectivity in the www.syngress.com Optimizing Snort • Chapter 10 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com definition for the threat’s threat level We view critical threats as any automated exploit or tool that assists in exploiting a vulnerability Figure 10.1 Categorizing Rules Critical Threat & 15-35% Network Impact Critical Threat & > 35% Network Impact Moderate Threat & < 15% Network Impact Moderate Threat & 15-35% Network Impact Moderate Threat & > 35% Network Impact Minimal Threat & < 15% Network Impact Threat Level Critical Threat & < 15% Network Impact Minimal Threat & 15-35% Network Impact Minimal Threat & > 35% Network Impact % of Affected Systems Key: Disable Log Alert Critical threats are proliferating on the Internet at a fast pace, such as most email–borne viruses, popular new exploits, and vulnerabilities that allow administrator-level access to system resources or data and in most cases are easy to leverage For an enterprise organization, these critical threats are where you want to spend the majority of your company’s time and energy A moderate threat is one that requires more than one step to complete and usually requires an ade­ quate amount of technical ability to exploit from a malicious user perspective Other moderate threats include vulnerability proof-of-concept code and vulnera­ bilities that affect popular software products Finally, minimal threats are consid­ ered more difficult attacks that leverage system information or any other noncritical pieces of information Minimal threats are those that require a consid­ erable amount of technical “know-how,” a highly specific scenario to exploit the vulnerability, or numerous manual procedures that must be sequenced together in a specific order.The following are some well-known threat examples categorized in our schema: ■ Critical threats SQL Slammer worm, CodeRed, IIS Unicode attacks ■ Moderate threats MDAC remote buffer overflow, Wu-FTP buffer overflow, OpenSSL bugs www.syngress.com 489 490 Chapter 10 • Optimizing Snort Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com ■ Minimal threats Bind TSIG, “obscure” CGI vulnerabilities, SMTP VRFY vulnerability Network impact refers to the number of systems within your environment that are affected by the threat A network with 500 nodes—servers, workstations, and network devices—that has 25 IIS servers would have an impact of percent for a threat such as a Microsoft self-propagating Web server worm We realize that our tool is not perfect since it does not account for percentage of private, production, or transaction systems; however, it can be used to help create your baseline.You might determine that you want to only determine the threat level pertaining to externally facing systems or production-status systems Both are commonly analyzed scenarios and can add value if presented to “decision makers” or administrators in a timely fashion Notes on Pattern Matching Pattern matching is frequently a problem within intrusion detection deployments because it is very CPU resource intensive Realizing this level of intensity is dras­ tically important when creating Snort rules that leverage this type of function­ ality We recommend sparsely using pattern-matching algorithms in your rules and never launching pattern-matching rules from a pattern-matching rule.This type of execution tree could bring your Snort installation to a halt if these rules were triggered by an automated attack or worm More information on pattern-matching specifics can be found in Chapter Configuring Preprocessors for Speed Introduced in Snort version 1.5, preprocessors provide an API for administrators and developers to define sets of instructions to be interpreted and executed on captured traffic.The preprocessor’s unique value is derived from the fact that it analyzes the data before potentially passing it to the Snort ruleset.This feature adds many technical benefits, especially in the realm of identifying more complex network attacks that are obfuscated and/or divided between multiple packets Explicit preprocessor features within Snort include TCP packet reassembly, decoding HTTP, fragmentation alerts, portscan identification, and stateful inspec­ tion protocol support As with most of the features within Snort, it is recommended to ensure that the ROI exists before implementing any preprocessors However, preprocessors present a unique problem because, if configured improperly, it is quite easy to www.syngress.com Optimizing Snort • Chapter 10 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com create a potential infinite looping or denial-of-service (DoS) anomaly that would bring your sensor to a screaming halt The conversation preprocessor takes in a number of parameters, but most importantly, it provides a user the capability to set the timeout value and the number of simultaneous sessions that can be monitored.The preprocessor relies on human knowledge during configuration time because it allows you to mon­ itor the entire range of 65,535 ports A timeout value of 60 seconds could easily allow an attacker to take down the sensor by flooding packets for 30 seconds and then send an attack that would go unnoticed It is difficult to pinpoint recommendations for configuring your preproces­ sors while maintaining acceptable levels of performance Our recommendation is to use your common sense, and hopefully that sense in combination with our previous recommendation to buy a powerful machine will ensure that your plugins will serve as intended Some rules to live by include: ■ Don’t monitor more than 10,000 connections with any single prepro­ cessor ■ Multiple portscan preprocessors are not needed ■ HTTP decoding is only needed for systems that receive inbound HTTP connections; in other words, your Web servers ■ Use the new Stream4 for packet reassembly and inspection ■ Similar to HTTP decoding,Telnet decoding for Telnet and FTP should only be used on systems with corresponding Telnet and FTP servers (in most cases, ports 23 and 21) It was not our intent to scare you away from using preprocessors, since some of them were designed to be more accurate and efficient than their commercial counterparts Learn them, consider their ROI, design them to correlate on data from pertinent and relevant systems, and implement efficiently OINK! For more in-depth information on preprocessors, please refer to Chapter www.syngress.com 491 492 Chapter 10 • Optimizing Snort Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Using Generic Variables Generic variables can and should be used wherever possible Why, you ask? Well, generic variables allow users, administrators, and intrusion detection engineers to quickly pull and reuse Snort rulesets in different environments Instead of the rules being tied to specific IP addresses, whether internal or external, the rules are tied to variable names For example, if a Snort rule were to detect a certain type of Web-based attack, then naturally you would only want it to analyze packets destined toward internal Web servers Snort provides users the ability to create stand-alone configuration files or numerous smaller configuration files that are linked to one main configuration file that Snort analyzes during execution.This is a perfect method for creating reusable sets of rules, since the only areas that would require modification are the variable definitions Consider the time savings for changing 15 to 50 variable names instead of changing 1000 or more Snort rules A collection of the most common generic variables declarations include internal network ranges, external networks, DMZ or transaction zone addresses, Web servers, DNS servers, mail relays, routers, client networks, and so forth These variable names and types are seen throughout Snort documentation and current Snort rules in formats such as $HOME_NET or $DMZ OINK! More detailed examples of using generic variables can be found in chapter Choosing an Output Plug-In Snort output plug-ins are excellent for modifying and presenting log and alert data in a customizable fashion During the installation and configuration process of your sensor, you have the ability to enhance Snort’s reporting features without using any additional add-on tools such as ACID or SnortSnarf to assist in log analysis Just as a quick recap: Plug-ins allow you to define files to use for storage in addition to the format of the data that goes into those files When selecting an output plug-in, you should determine the business and technical factors of your selection For example, the projected traffic rate should www.syngress.com Optimizing Snort • Chapter 10 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com be taken into consideration when designing the sensor In addition, you need to run through the plug-ins and what we refer to as a common sense test A common sense test is just verifying that you are not trying to output to syslog on a Windows 2000 system or write to C:\Snort\logs on an OpenBSD sensor There are additional factors in selecting output plug-ins that will potentially affect the overall choice and functionality of the system: ■ Too many plug-ins can hinder system performance ■ Individual rules that output data to multiple files can also impede per­ formance ■ Data format defined within the plug-ins should be streamlined; complex data formatting should be completed outside the Snort engine, such as that in a Perl parsing program ■ Only pertinent data should be included in the plug-ins It is important to note that selecting a specific output plug-in is not always necessary Depending on the type of installation and configuration your environment requires, it may prove beneficial to implement the unified logging option and leverage a post-process application similar to Barnyard Barnyard ana­ lyzes and correlates packets after they have been saved off in their storage file while its main goal is to minimize CPU cycles directed towards reporting uti­ lized by the Snort executable.This allows the Snort application to focus on packet capture and analyze instead of data parsing and formatting We also recommend only selecting one output plug-in, specifically we highly discourage “stacking” or using multiple output plug-ins within a single instance of Snort.This also puts a significant burden on the application which could lead to dropped packets and lost attack analysis OINK! Output plug-in paths, locations, and references might have to modified if declared statically, especially if different platforms were used We rec­ ommend creating a logging structure that is not only type-fully named, but also consistent across your entire intrusion detection network www.syngress.com 493 494 Chapter 10 • Optimizing Snort Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Benchmarking Your Deployment In the business world, benchmarks serve as a tool to help an organization improve its business processes.Technically, benchmark tests can serve as an excel­ lent resource to aid in identifying strengths and weaknesses in test subjects, sys­ tems, and cases In our case, proper Snort benchmark testing will identify current and potential configuration-related bottlenecks due to improper configurations, lackluster hardware, or software inefficiencies Keys to conducting a high-quality benchmark are proper comparison systems, one-off configuration modifications, repeatable results, and documentation It might seem like a great deal of specific information and, to be honest, conducting a commercial-grade benchmark con­ sumes a considerable amount of time and resources.Therefore, for the remainder of this section, we will refer to benchmarks in two ways Both will be related to Snort tests, but one will be referred to as commercial-grade benchmarks (CGB) and the other as ad hoc benchmarks (AB).The first is self-explanatory, and the other simply means that you are executing a less formal test in search of one or two advantageous outcomes An example would be implementing a new rule and seeing the impact that rule has on your sensor and if the performance impact is worth the gathered data If you are asking yourself, “Do I really need to conduct a benchmark test, since I only want to use Snort as an additional resource in my environment in the case of an emergency or one-off scenario?” the answer might be “no.” In general, benchmarks are used in commercial organizations for commercial-grade applications; however, Snort stands apart from the crowd as a publicly available tool that has the quality of any other private product Whatever your decision, expect to spend 40 to 80 engineer hours for system preparation and testing Benchmark Characteristics Benchmarks, either good or bad, have certain distinguishing characteristics Numerous factors can lead up to or directly contribute to the success or failure of a test Such factors range from inadequate resources or time allocation to improper tool automation Subsequent sections detail some of the disastrous pit­ falls that should be avoided, in addition to vital elements that should be included in the benchmark www.syngress.com Optimizing Snort • Chapter 10 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Attributes of a Good Benchmark ■ Strong benchmarks result from a combination of solid documented business requirements and functional test plans It is key to understand the business drivers for conducting the benchmarks, even if the driver is to simply “create a leaner, faster, more efficient Snort intrusion detection platform.” In addition to creating the vision of a benchmark, docu­ mented goals and milestones should also be included in the require­ ments For example, if your goal is to determine if it is better to place Snort on an old Linux system or relatively new Win32 system , then the milestones in achieving this goal would be: Create identical Snort con­ figurations on production-ready test systems ■ Determine and specify a test set of intrusion detection rules to imple­ ment on both test systems ■ Identify and gather required assessment tools (for example, vulnerability scanners, port scanners, etc.) ■ Develop process and procedure automation via scripting or manual pro­ cedures ■ Develop a benchmark test plan ■ Conduct the benchmark ■ Analyze the results and determine future action items Snort benchmarks coincide with most other types of technical benchmark assessments in reference to test methodology In practice, it is purely another technology-enabled management tool As a rule of thumb, the more automation, the better! Attributes of a Poor Benchmark At the risk of sounding sarcastic, we must say that most of the attributes of a poor benchmark can be derived by taking the inverse of the attributes of a good bench­ mark in the previous section With that said, there are a few exceptions.The most widespread flaw when conducting a benchmark is to permit uncontrolled variables and factors the ability to construe test results For example, Snort benchmarks should be tested in controlled cells, or environments, so that only network traffic that is sent from other controlled systems is captured and analyzed by the sensor www.syngress.com 495 496 Chapter 10 • Optimizing Snort Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Therefore, running your tests in a production environment is probably a very bad idea Another common mistake is modifying more than one element between the two test cases It would provide very little insight into the true performance differ­ ences of an OpenBSD versus Windows 2000 Snort install if both rulesets were completely different.The last aspect often overlooked is running multiple tests during the benchmark; not only running multiple types of different tests, but also multiple identical tests for verification purposes To recap, avoid these three common flaws: ■ Conducting benchmarks in an uncontrolled environment ■ Measuring and comparing dissimilar systems ■ Being satisfied with the results of one test run What Options Are Available for Benchmarking? The options for benchmarking an IDS in today’s market are few, and if you are counting viable enterprise solutions, then the answer is “None.” Minus the sur­ plus of vulnerability and port scanners and chained exploit scripts, six tools are commonly used to aid in benchmarking Of the six, the only one that is close to commercial grade and that has a graphical interface is IDS Informer.The remainder of the options are command-line tools and, in most cases, scripts.The technical abilities range from stateful attacks to blind CGI requests IDS Informer is our top recommendation for consulting and enterprise orga­ nizations that require easy installs, graphical interfaces, and good reporting If you simply require a freeware tool or comprehensive script, it is a toss-up between IDS Wakeup and Ftester (Firewall Tester) IDS Informer Blade Software’s IDS Informer (www.gui2000.com) is the current industry stan­ dard for testing IDS features and implementations.The product’s graphical inter­ face and configurable features far surpass any other available IDS testing tool or application With offices in the United States, the United Kingdom, and India, Blade also publishes application bug fixes and attack updates on a regular basis The GUI provides an easy-to-understand and easy-to-use interface for con­ figuring IDS Informer As shown in Figure 10.2, the user can specify the source IP and MAC address for all the attacks and define the destination IP address If the destination IP address is unreachable, the destination MAC will be forced to www.syngress.com Optimizing Snort • Chapter 10 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com use a broadcast address of FF-FF-FF-FF-FF-FF Otherwise, the engine will use the retrieved, corresponding MAC address of the defined destination IP address IDS Informer can also configure the transmission rate and Time-to-Live (TTL) for the attacks Each of these provides greater flexibility in case the tool is being executed in a production environment Informer also provides the capability to graphically select any of the network cards found on the system Figure 10.2 Blade IDS Informer Configuration The other beneficial option open to the user configuring IDS Informer is the ability to create manageable groups of attacks.The Successful HTTP group created in Figure 10.3 contains the following three successful attack sequences: HTTP IIS htr access, HTTP IIS Index htw Cross-Site Scripting, and HTTP IIS asp showcode Group creation allows an administrator or consultant to predefine small and manageable subsets of attacks www.syngress.com 497 498 Chapter 10 • Optimizing Snort Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Figure 10.3 IDS Informer Attack Groups The prime disadvantage of this product is that it has a price tag; however, at the affordable price of $5000 per license, it will prove a valuable addition to any consultant and developer shop In the past, Blade Software offered specials that allowed extended trial periods for auditors and consultants Besides the attack reports being a little weak on technical content, the only other considerable downside of the product is the inability to create custom attack simulations Granted, the ability to quickly configure the attacks Blade creates does exist, but it would be nice if an open API existed to allow end users the ability to create and run additional attacks After the settings and preferences have been configured for the test environ­ ment, you are one step away from running Informer As explained previously, Informer provides the user with the flexibility to determine what attacks should and should not be executed on the network Informer also has the capability to launch all the attacks against the predefined target, as shown in Figure 10.4 All 10 default attack groups were included in Figure 10.4, and over 7000 packets were transmitted in total www.syngress.com Optimizing Snort • Chapter 10 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Figure 10.4 Running IDS Informer At the bottom of Figure 10.4 is the space that is provided to view the attack log of the most recent set of tests Each attack comes with a corresponding entry in the attack log so that the attacks can be correlated to the IDS sensor logs in search of false positives, false negatives, and other poor configurations.The fol­ lowing is an attack log dump after a complete test was run with All Predefined Attacks enabled As you can see, source and destination information is included, along with protocol and transmission specifics Unfortunately, no attack strings and content are logged Such information would assist administrators looking to test their systems and enhance those systems with new rules and signatures Sending attack Trace route ICMP from 0.0.0.0 to 10.0.9.100 Attack sent, 3:19:16 PM, 2/8/2003, packets sent TCP 0, UDP 0, ICMP 96 Source MAC address 00-00-00-00-00-00, Destination MAC address FF-FF-FF-FF- FF-FF Sending attack Finger user S from 0.0.0.0 to 10.0.9.100 Attack sent, 3:19:18 PM, 2/8/2003, packets sent TCP 12, UDP 0, ICMP Source MAC address 00-00-00-00-00-00, Destination MAC address FF-FF-FF-FF- FF-FF Sending attack DNS Zone transfer S from 0.0.0.0 to 10.0.9.100 Attack sent, 3:19:19 PM, 2/8/2003, packets sent TCP 16, UDP 0, ICMP www.syngress.com 499 500 Chapter 10 • Optimizing Snort Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Source MAC address 00-00-00-00-00-00, Destination MAC address FF-FF-FF-FF- FF-FF Sending attack Nmap UDP scan from 0.0.0.0 to 10.0.9.100 Attack sent, 3:19:22 PM, 2/8/2003, packets sent TCP 2, UDP 1475, ICMP 1457 Source MAC address 00-00-00-00-00-00, Destination MAC address FF-FF-FF-FF- FF-FF Sending attack Nmap TCP scan from 0.0.0.0 to 10.0.9.100 Attack sent, 3:19:26 PM, 2/8/2003, packets sent TCP 3122, UDP 0, ICMP Source MAC address 00-00-00-00-00-00, Destination MAC address FF-FF-FF-FF- FF-FF Sending attack HTTP IIS unicode S from 0.0.0.0 to 10.0.9.100 Attack sent, 3:19:27 PM, 2/8/2003, packets sent TCP 9, UDP 0, ICMP Source MAC address 00-00-00-00-00-00, Destination MAC address FF-FF-FF-FF- FF-FF Sending attack Backdoor Back orifice S from 0.0.0.0 to 10.0.9.100 Attack sent, 3:19:28 PM, 2/8/2003, packets sent TCP 0, UDP 45, ICMP Source MAC address 00-00-00-00-00-00, Destination MAC address FF-FF-FF-FF- FF-FF Sending attack RPC Linux statd overflow S from 0.0.0.0 to 10.0.9.100 Attack sent, 3:19:29 PM, 2/8/2003, packets sent TCP 25, UDP 5, ICMP Source MAC address 00-00-00-00-00-00, Destination MAC address FF-FF-FF-FF- FF-FF Sending attack HTTP IIS htr overflow S from 0.0.0.0 to 10.0.9.100 Attack sent, 3:19:30 PM, 2/8/2003, packets sent TCP 7, UDP 0, ICMP Source MAC address 00-00-00-00-00-00, Destination MAC address FF-FF-FF-FF- FF-FF Sending attack DOS Smurf from 0.0.0.0 to 10.0.9.100 Attack 10 sent, 3:19:33 PM, 2/8/2003, packets sent TCP 2, UDP 0, ICMP 1000 Source MAC address 00-00-00-00-00-00, Destination MAC address FF-FF-FF-FF- FF-FF www.syngress.com Optimizing Snort • Chapter 10 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com IDS Wakeup IDS Wakeup (www.hsc.fr/ressources/outils/idswakeup) is a command-line tool that uses a collection of other tools and attack strings to test intrusion detection sensors By far one of the most comprehensive freeware utilities of its kind, it is distributed by its creators, Herve` Schauer Consulting.The simulated attacks range from malicious FTP requests to protocol-based DoS sequences and Web server buffer overflow strings One of the key differentiators of this tool com­ pared to the other freeware programs is the TTL feature Modifying the TTL field within a packet allows you to send attacks that might trigger IDS rules but not affect the production servers.This has proven to be an excellent feature for consultants and administrators who want to take advantage of this tool’s capabili­ ties during production hours without fear of disrupting business IDSWakeup is a UNIX-based tool that can be executed locally It requires that you pass it a source and destination IP address.There is no need to specify a port, since the attacks come with corresponding port assignments Another useful feature of the tool is the ability to define how many cycles should be completed before exiting: IDSWakeup usage: /IDSWakeup The program has two dependencies First, you must install and configure HPing2, which can be downloaded from www.kyuzz.org/antirez/hping.The second dependency is a program released with IDSWakeup called IWU IWU is another command-line utility created to quickly send datagrams; it requires that you install Libnet Libnet is a set of libraries that can be used to streamline the pro­ cess of developing network-based applications.The frameworks and structures for implementing and using protocols are the best Libnet and other security projects can be downloaded from the Packet Factory Web site at www.packetfactory.net/ The following is an example of a test that was run on an internal network with a source address of 10.1.1.1 and a destination address of 10.0.2.130.The tool will run twice before exiting and should not disturb the target system due to the defined TTL value of # /root/IDSW/./IDSwakeup 10.1.1.1 10.0.2.130 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=­ - IDSwakeup : false positive generator - Stephane Aubert - Hervé Schauer Consultants (c) 2000 www.syngress.com 501 ... 16:52:06.029368 1 72 .16 .10.151.1025 > 1 72 .16 .10.200.135: [no cksum] udp 28 (frag 242:36@0+) (ttl 3, len 56) 16:52:06.046302 1 72 .16 .10.151 > 1 72 .16 .10.200: (frag 242:4@24) (ttl 3, len 24) Snort and the... directives in an oinkmaster.conf file: Snort 2.1. x url = http://www .snort. org/dl/rules/snortrules-snapshot-2_1.tar.gz Snort 2.0.x url = http://www .snort. org/dl/rules/snortrules-snapshot-2_0.tar.gz This... spoofed? # snort –dvr teardrop_attack.cap 02/19-16:52:06.029368 1 72 .16 .10.151 -> 1 72 .16 .10.200 UDP TTL:3 TOS:0x0 ID:242 IpLen:20 DgmLen:56 MF Frag Offset: 0x0000 Frag Size: 0x0024 04 01 00 87 00 24

Ngày đăng: 13/08/2014, 12:21

Từ khóa liên quan

Mục lục

  • Snort 2 1 Intrusion Detection, Second Edition

    • Cover

  • Contents

  • Foreword

  • Chapter 1 Intrusion Detection Systems

    • Introducing Intrusion Detection Systems

      • What Is an Intrusion?

        • Legal Definitions

        • Scanning vs Compromise

        • Viruses and Worms-SQL Slammer

        • Live Attacks-Sendmail Buffer Overflow

      • How an IDS Works

        • What the IDS Is Watching

        • How the IDS Watches Your Network

        • How the IDS Takes the Data It Gathers and Finds Intrusion Attempts

        • What the IDS Does When It Finds an Attack Attempt

    • Answering Common IDS Questions

      • Why Are Intrusion Detection Systems Important?

      • Why Doesn't My Firewall Serve as an IDS?

      • Why Are Attackers Interested in Me?

        • Automated Scanning/Attacking Doesn't Care Who You Are

        • Desirable Resources Make You a Target

        • Political or Emotional Motivations

      • Where Does an IDS Fit with the Rest of My Security Plan?

      • Where Should I Be Looking for Intrusions?

        • Operating System Security-Backdoors and Trojans

        • Physical Security

        • Application Security and Data Integrity

        • Correlation of All These Sources

      • What Will an IDS Do for Me?

        • Continuously Watch Packets on Your Network and Understand Them

        • Read Hundreds of Megs of Logs Daily and Look for Specific Issues

        • Create Tremendous Amounts of Data No Matter How Well You Tune It

        • Create So Much Data that If You Don't Tune It, You Might as Well Not Have It

        • Find Subtle Trends in Large Amounts of Data that Might Not Otherwise Be Noticed

        • Supplement Your Other Protection Mechanisms

        • Act as a Force Multiplier Competent System/ Network Administrator

        • Let You Know When It Looks Like You Are Under Attack

      • What Won't an IDS Do for Me?

        • Replace the Need for Someone Who Is Knowledgeable about Security

        • Catch Every Attack that Occurs

        • Prevent Attacks from Occurring

        • Prevent Attacks from Succeeding Automatically (in Most Cases)

        • Replace Your Other Protection Mechanisms

        • What Else Can Be Done with Intrusion Detection?

    • Fitting Snort into Your Security Architecture

      • Viruses, Worms, and Snort

      • Known Exploit Tools and Snort

      • Writing Your Own Signatures with Snort

      • Using an IDS to Monitor Your Company Policy

    • Analyzing Your IDS Design and Investment

      • False Positives versus False Negatives

      • Fooling an IDS

        • IDS Evasion Techniques

      • Return on Investment-Is It Worth It?

    • Defining IDS Terminology

      • Intrusion Prevention Systems (HIPS and NIPS)

      • Gateway IDS

      • Network Node IDS

      • Protocol Analysis

      • Target-Based IDS

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Chapter 2 Introducing Snort 2 1

    • Introduction

    • What Is Snort?

    • Understanding Snort's System Requirements

      • Hardware

        • Operating System

        • Other Software

    • Exploring Snort's Features

      • Packet Decoder

      • The Preprocessors

        • Example: HTTPInspect

        • Example: flow-portscan

      • The Detection Engine

        • Flow-Portscan as Example Feature

        • Rules and Matching

        • Thresholding and Suppression

      • The Alerting and Logging Components

        • Output Plug-Ins

        • Unified Output

    • Using Snort on Your Network

      • Using Snort as a Packet Sniffer and Logger

      • Using Snort as a NIDS

      • Snort and Your Network Architecture

        • Snort and Switched Networks

      • Pitfalls When Running Snort

        • False Alerts

        • Upgrading Snort

    • Considering System Security While Using Snort

      • Snort Is Susceptible to Attacks

        • Detecting a Snort System on the Network

        • Attacking Snort

        • Attacking the Underlying System

      • Securing Your Snort System

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Chapter 3 Installing Snort

    • Introduction

    • Making the Right Choices

      • Linux over OpenBSD?

      • Stripping Linux

        • Stripping out the Candy

    • A Brief Word about Linux Distributions

      • Debian

      • Slackware

      • Gentoo

        • A Word about Hardened/Specialized Linux Distributions

    • Preparing for the Installation

      • Installing pcap

        • Installing libpcap from Source

        • Look Ma! No GUI!

        • Installing libpcap from RPM

        • Installing libpcre

        • Installing MySQL

        • Installing from RPM

        • Installing from Source

    • Installing Snort

      • A Brief Word about Sentinix GNU/Linux

      • Installing Snort from Source

        • Enabling Features via configure

      • Installing Snort from RPM

      • Installing Snort Using apt

      • Configuring Snort IDS

      • Customizing Your Installation: Editing the snort conf File

        • Installation on the MS Windows Platform

        • Command-Line Switches

      • Installing on OpenBSD

        • Option 1: Using OpenBSD Ports

        • Option 2: Using Prepackaged OpenBSD Ports

        • Option 3: Installing Snort from Source

      • Installing Bleeding-Edge Versions of Snort

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Chapter 4 Inner Workings

    • Introduction

      • The Life of a Packet Inside Snort

        • Decoders

      • The Detection Engine

        • The Old Detection Engine

        • The New Detection Engine

        • Tagging

        • Thresholding

        • Suppression

        • Logging

    • Adding New Functionality

      • What Is a Detection Plug-In?

      • Writing Your Own Detection Plug-In

        • Copyright and License

        • Includes

        • Data Structures

        • Functions

        • Setup

        • Initialization

        • Parser

        • Detection Function

        • What Do I Add to the Rest of the System?

        • Testing

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Chapter 5 Playing by the Rules

    • Introduction

    • Dissecting Rules

      • Matching Ports

      • Matching Simple Strings

      • Using Preprocessor Output

    • Using Variables

      • Snort Configuration

    • Understanding Rule Headers

      • Rule Actions

        • When Should You Use a Pass Rule?

        • Custom Rules Actions

        • Using Activate and Dynamic Rules

    • Rule Options

      • Rule Content

        • ASCII Content

        • Including Binary Content

        • The depth Option

        • The offset Option

        • The nocase Option

        • The session Option

        • Uniform Resource Identifier Content

        • The stateless Option

        • Regular Expressions

        • Flow Control

      • IP Options

        • Fragmentation Bits

        • Equivalent Source and Destination IP Option

        • IP Protocol Options

        • ID Option

        • Type of Service Option

        • Time-To-Live Option

      • TCP Options

        • Sequence Number Options

        • TCP Flags Option

        • TCP ACK Option

      • ICMP Options

        • ID

        • Sequence

        • The icode Option

        • The itype Option

      • Meta-Data Options

        • Snort ID Options

        • Rule Revision Number

        • Severity Identifier Option

        • Classification Identifier Option

        • External References

      • Miscellaneous Rule Options

        • Messages

        • Logging

        • TAG

        • dsize

        • RPC

        • Real-Time Countermeasures

    • Writing Good Rules

      • What Makes a Good Rule?

      • Action Events

      • Ensuring Proper Content

      • Merging Subnet Masks

      • What Makes a Bad Rule?

      • The Evolution of a Rule: From Start to Finish

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Chapter 6 Preprocessors

    • Introduction

    • What Is a Preprocessor?

    • Preprocessor Options for Reassembling Packets

      • The stream4 Preprocessor

        • TCP Statefulness

        • Session Reassembly

        • Stream4's Output

      • Frag2-Fragment Reassembly and Attack Detection

        • Configuring Frag2

        • Frag2 Output

      • Flow

        • Configuring Flow

        • Frag2 Output

    • Preprocessor Options for Decoding and Normalizing Protocols

      • Telnet Negotiation

        • Telnet Negotiation Output

      • HTTP Normalization

        • Configuring the HTTP Normalization Preprocessor

        • HTTP Decode's Output

      • rpc_decode

        • Configuring rpc_decode

        • rpc_decode Output

    • Preprocessor Options for Nonrule or Anomaly-Based Detection

      • Portscan

        • Configuring the Portscan Preprocessor

      • Back Orifice

        • Configuring the Back Orifice Preprocessor

      • General Nonrule-Based Detection

    • Experimental Preprocessors

      • arpspoof

      • ASN1_decode

      • Fnord

      • preprocessor fnordPreprocessor fnordportscan2 and conversation

        • Configuring the portscan2 Preprocessor

        • Configuring the conversation Preprocessor

      • perfmonitor

    • Writing Your Own Preprocessor

      • Reassembling Packets

      • Decoding Protocols

      • Nonrule or Anomaly-Based Detection

      • Setting Up My Preprocessor

      • What Am I Given by Snort?

        • Examining the Argument Parsing Code

        • Getting the Preprocessor's Data Back into Snort

      • Adding the Preprocessor into Snort

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Chapter 7 Implementing Snort Output Plug-Ins

    • Introduction

    • What Is an Output Plug-In?

      • Key Components of an Output Plug-In

    • Exploring Output Plug-In Options

      • Default Logging

      • SNMP Traps

      • XML Logging

      • Syslog

      • SMB Alerting

      • PCAP Logging

      • Snortdb

      • MySQL versus PostgreSQL

      • Unified Logs

        • Why Should I Use Unified Logs?

        • What Do I Do with These Unified Files?

    • Writing Your Own Output Plug-In

      • Why Should I Write an Output Plug-In?

      • Setting Up Your Output Plug-In

      • Creating Snort's W3C Output Plug-In

        • myPluginSetup (AlertW3CSetup)

        • myPluginInit (AlertW3CInit)

        • myPluginAlert (AlertW3C)

        • myPluginCleanExit (AlertW3CCleanExit)

        • myPluginRestart (AlertW3CRestart)

        • Running and Testing the Snort W3C Output Plug-in

      • Dealing with Snort Output

    • Tackling Common Output Plug-In Problems

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Chapter 8 Dealing with the Data

    • Introduction

    • What Is Intrusion Analysis?

      • Snort Alerts

        • Snort Packet Data

        • Examine the Rule

        • Validate the Traffic

        • Attack Mechanism

        • Intrusion Data Correlation

        • Following Up on the Analysis Results

    • Intrusion Analysis Tools

      • Database Front Ends

        • ACID

      • Installing ACID

        • Prerequisites for Installing ACID

      • Configuring ACID

      • Using ACID

        • Querying the Database

        • Alert Groups

        • Graphical Features of ACID

        • Managing Alert Databases

      • SGUIL

        • Installing SGUIL

        • Step 1: Create the SGUIL Database

        • Step 2: Installing Sguild, the Server

        • Step 3: Install a SGUIL Client

        • Step 4: Install the Sensor Scripts

        • Step 5: Install Xscriptd

      • Using SGUIL

      • Summary Scripts

        • snort_stat pl

      • Using SnortSnarf

        • Installing SnortSnarf

        • Configuring Snort to Work with SnortSnarf

        • Basic Usage of SnortSnarf

        • Swatch

    • Analyzing Snort IDS Events

      • Begin the Analysis by Examining the Alert message

      • Validate the Traffic

      • Identify the Attack Mechanism

      • Correlations

    • Conclusions

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Chapter 9 Keeping Everything Up to Date

    • Introduction

    • Updating Snort

      • Production Choices

        • Compiled Builds vs Source Builds 2

        • Patching Snort 3

    • Updating Rules

      • How Can Updating Be Easy?

        • Using Variables

        • Using the Local Rules File

        • Removing Rules from the Ruleset

        • Using Oinkmaster

        • Using IDSCenter to Merge with Your Existing Rules

      • The Importance of Documentation

        • Why a Security Team Should Be Concerned with Rule Documentation

    • Testing Snort and the Rules

      • Testing within Organizations

        • Small Organizations

        • Large Organizations

    • Watching for Updates

      • The Importance of Security Mailing Lists and Web Sites

      • Chain-of-Command and Outside Management for CIRT Organizations

      • Use in Events-of-Interest, 0-Day, and Other Short-Term Use

        • Short-Term Rules

        • Policy Enforcement Rules

        • Forensics Rules

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Chapter 10 Optimizing Snort

    • Introduction

    • How Do I Choose the Hardware to Use?

      • What Constitutes "Good" Hardware?

        • Processors

        • RAM Requirements

        • Storage Medium

        • Network Interface Card

      • How Do I Test My Hardware?

    • How Do I Choose the Operating System to Use?

      • What Makes a "Good" OS for an NIDS?

      • What OS Should I Use?

      • How Do I Test My OS Choice?

    • Speeding Up Snort

      • The Initial Decision

      • Deciding Which Rules to Enable

      • Notes on Pattern Matching

      • Configuring Preprocessors for Speed

      • Using Generic Variables

      • Choosing an Output Plug-In

    • Benchmarking Your Deployment

      • Benchmark Characteristics

        • Attributes of a Good Benchmark

        • Attributes of a Poor Benchmark

      • What Options Are Available for Benchmarking?

        • IDS Informer

        • IDS Wakeup

        • Sneeze

        • TCPReplay

        • THC's Netdude

        • Other Packet-Generation Tools

        • Additional Options

      • Stress Testing the Pig!

      • Stress Tests

      • Individual Snort Rule Tests

      • Berkeley Packet Filter Tests

    • Tuning Your Rules

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Chapter 11 Mucking Around with Barnyard

    • Introduction

    • What Is Barnyard?

    • Understanding the Snort Unified Files

      • Unified Alert Records

      • Unified Log Records

      • Unified Stream-Stat Records

    • Installing Barnyard

      • Downloading

      • Building and Installing

    • Configuring Barnyard

      • The Barnyard Command-Line Options

      • The Configuration File

        • Configuration Directives

        • Output Plug-In Directives

    • Understanding the Output Plug-Ins

      • alert_fast

      • alert_csv

      • alert_syslog

      • alert_syslog2

      • log_dump

      • log_pcap

      • acid_db

      • sguil

    • Running Barnyard in Batch-Processing Mode

      • Processing a Single File

      • Using the Dry Run Option

      • Processing Multiple Files

    • Using the Continual-Processing Mode

      • The Basics of Continual-Processing Mode

      • Running in the Background

      • Enabling Bookmark Support

      • Only Processing New Events

      • Archiving Processed Files

      • Running Multiple Barnyard Processes

      • Signal Handling

    • Deploying Barnyard

      • Remote Syslog Alerting

      • Database Logging

      • Extracting Data

      • Real-Time Console Alerting

    • Writing a New Output Plug-In

      • Implementing the Plug-In

        • Setting Up the Source Files

        • Writing the Functions

        • Adding the Plug-In to op_plugbase c

      • Finishing Up

        • Updating Makefile am

        • Building Barnyard

      • Real-Time Console Alerting Redux

    • Secret Capabilities of Barnyard

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Chapter 12 Active Response

    • Introduction

    • Active Response vs Intrusion Prevention

      • Active Response Based on Layers

      • Altering Network Traffic Based on IDS Alerts

        • Snortsam

        • Fwsnort

        • Snort_inline

        • Attack and Response

    • Snortsam

      • Installation

      • Architecture

        • Snort Output Plug-In

        • Blocking Agent

      • Snortsam in Action

        • WWWBoard passwd txt Access Attack

        • NFS mountd Overflow Attack

    • Fwsnort

      • Installation

      • Configuration

      • Execution

      • WWWBoard passwd txt Access Attack (Revisited)

      • NFS mountd Overflow Attack (Revisited)

    • Snort_inline

      • Installation

      • Configuration

      • Architecture

      • Web Server Attack

      • NFS mountd Overflow Attack

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Chapter 13 Advanced Snort

    • Introduction

    • Network Operations

      • Flow Preprocessor Family

      • Perfmon Preprocessor

      • Unusual Network Traffic

    • Forensics/Incident Handling

      • Logging and Filtering

      • Traffic Reconstruction

      • Interacting with Law Enforcement

    • Snort and Honeynets

      • Snort-Inline

        • Countermeasures and Logging

    • Really Cool Stuff

      • Behavioral Tracking

        • Patch/IAVA Verifications

        • Policy Enforcement

    • Summary

    • Solutions Fast Track

    • Frequently Asked Questions

  • Index

  • Team DDU

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan