Snort: An Intrusion-Detection System

---

We’ve talked about intrusion-detection systems (IDSs) throughout this book. IDSs are sniffers, too. Network architects place an IDS on a strategic point in the network where all traffic will pass. The IDS examines all packets that pass through the network, looking for particular signatures that are defined by the administrator. The IDS then reports on all traffic that matches those signatures. The point is to configure the IDS with signatures of undesirable packets, such as mangled nmap port scan packets or potential vulnerability exploits such as Code Red.

Snort is a robust IDS. It runs on several Unix variants as well as Windows. It is also completely free (http://www.snort.org/). In this section, we focus on version is 2.0.2.

Snort is not a simple program to learn. In fact, entire books have been written about snort. We’ll cover some of the basic concepts that make snort a superior IDS. You can view the online documentation for snort at http://www.snort.org/docs/writing_rules/ for full details.

Installation and Implementation

Snort is not difficult to install; you go through the typical installation steps. The difficult part is getting snort configured to log and alert only on actual threats—as opposed to false alarms. Many people who use IDSs don’t even look through their logs closely because they’re filled with so many false positives. We’ll talk about configuring snort’s rule file in “Snort Rules: An Overview.”

Snort Modes

Snort can run as a stand-alone sniffer, a packet logger, or an IDS. The first two modes really have no advantage over any other sniffer, except that snort’s packet logger can log the packets to disk in a nicely organized directory structure. Running snort with a rule configuration file (normally snort.conf) will have it log only the packets that match the rules specified in that file.

Exploring snort.conf

Let’s take a quick tour of the snort.conf file. In the Snort source directory, you’ll see two subdirectories of interest—etc and rules. The actual snort.conf file lives in etc. You may find it easier to create a separate system directory (say, /usr/local/snort) and copy the etc and rules directories to those directories. Just be careful of the permissions on those files. They should be readable only by the user running snort.

The first part of the snort.conf file lets you set some important global variables, indicating such things as your home subnet, your web servers, and your rule locations. Here are some global variable definitions:

var HOME_NET [192.168.1.0/24] var EXTERNAL_NET !HOME_NET var DNS_SERVERS [192.168.1.150/32,192.168.1.151/32] var HTTP_SERVERS [192.168.1.50/32] var HTTP_PORTS 80 var RULE_PATH ../rules

These variable definitions tell snort that it’s running on a 192.168.1.0 Class C network, with DNS servers at 192.168.1.150 and 192.168.1.151 and a web server on 192.168.1.50. The snort ruleset will reference these variables to help cut down on the amount of work it has to do. Rules that check for web attacks will watch only hosts defined in HTTP_SERVERS, instead of watching every host—even those that aren’t running web servers. Finally, the RULE_PATH points to the directory containing the actual rule files, which we’ll discuss later in the “Snort Rules: An Overview” section.

The second part of the file lets you configure preprocessors. The preprocessors handle such things as fragmented packets, port scan detection, and stream reassembly. Usually, it’s best to go with the default options and see how they work out for you. However, by default, port scanning detection is turned off. Currently two different methods can be used for detecting port scans. Simply search snort.conf for “preprocessor portscan” to check them out. The syntax for the original portscan preprocessor is shown here:

preprocessor portscan: $HOME_NET 20 5 portscan.log preprocessor portscan-ignorehosts: 192.168.1.150/32 192.168.1.151/32

The first statement tells snort to log an alert to portscan.log in our log directory whenever it detects activity across at least 20 different hosts/ports in less than five seconds on our HOME_NET (previously defined as 192.168.1.0/24). The second statement tells snort to ignore “port scans” from and to our two DNS servers—as many times normal DNS activity will be registered by snort as UDP port scans. See the “Preprocessors” section of “Snort Plug-Ins” for more detail on other preprocessors.

As we mentioned earlier, when snort is in IDS mode, you can tell it to log alerts and packets to a directory structure. However, this can be terribly time consuming. It can be so time consuming, in fact, that it might cause snort to miss packets. You can improve snort’s efficiency in IDS mode by running it in fast alert mode and logging packets in binary format.

# snort –c snort.conf –l ./logdir –b –L snort.dump –A fast

This command tells snort to use the snort.conf file for rulesets, log alerts and packets in logdir, log packets in binary format to logdir/snort.dump, and log alerts to the default alert file (logdir/alert) with only minimal details. Alternatively, leaving off the –A fast will have snort log alerts with complete details, including a decoded header. This will slow snort down a bit, but as long as you’re logging packets in binary format, snort should still be able to keep up unless you’re on a very congested network. You can examine the snort.dump file in detail using a tool like Ethereal.

The third part of snort.conf lets you configure other ways of logging output. You can have alerts sent to syslog. You can have both packets and alerts logged to a SQL database. The new and recommended way of logging packets and alerts is the “unified” format. The unified technique logs both packets and alerts to a binary file that can be analyzed later using the Barnyard processor (also available from snort.org). You can even configure specific rules to use specific output plug-ins. See the “Output Modules” section for more details on output plug-ins. Finally, the rest of snort.conf consists of include directives. The include directives point to all of snort’s rule files as well as some other configuration information for classification and reference of alerts. The rule files are all located in the rules subdirectory by default. They are separated into files by type. You can add your own rules in the local.rules file. If you find any rules that you don’t want to check for, you can comment out individual rules or entire rule files by placing a # in front of the rule or include directive. See the "Snort Rules Syntax" section for more details on snort rules.

Once you’re done setting up snort.conf, you can test the configuration by placing a –T at the end of your snort command line. Here’s an example:

# snort –c snort.conf –l ./logdir –b –L snort.dump –A fast –T 

If there’s anything wrong with the config file, snort will tell you. Once you have the kinks ironed out, you’re ready to run the IDS. But first, you should get a better understanding of the snort rules.

Snort Rules: An Overview

Snort rules are similar to the kind of packet-filter expressions that you create in tcpdump and Ethereal. They can match packets based on IP, ports, header data, flags, and packet contents. Snort has five kinds of rules:

• Alert rules   Packets that match alert rules are logged in whatever format you specified and an alert is sent to the alerts file.

• Pass rules   Packets that match pass rules are allowed through and ignored.

• Log rules   Packets that match log rules are logged, but with no alert.

• Dynamic rules   Dynamic rules are activated by activate rules, and then they merely act like log rules. These are great mechanisms for gathering more during an attack.

• Activate rules   Packets that match the rule trigger a mechanism that sets an alert and then activates a dynamic rule.

Snort comes with a standard ruleset that checks for such activity as nmap stealth scans, vulnerability exploits, attempted buffer overflows, anonymous FTP access, and much more.

By default, snort checks the packet against alert rules first, followed by pass rules and then log rules. This setup is perfect for the administrator who is just learning snort and plans on using the default config file and ruleset. Snort’s default ruleset doesn’t include any pass rules or log rules. However, running snort without performing any kind of customization or configuration is usually a bad idea, as you’ll no doubt be inundated with false positives.

As you become more familiar with the snort rule syntax, you’ll be able to write rules to ignore certain traffic. For example, on our network, anytime we had a flood of DNS queries forwarded to our DNS server from other DNS servers on the Internet, snort was detecting false UDP port scans and DNS probes. Obviously, we didn’t want our logs to get cluttered with all these false positives. So we set up our own rules file and defined a variable DNS_SERVERS that contained the IP addresses of all of our DNS servers. We then wrote the following snort rules and placed them in the local.rules file:

var DNS_SERVERS [192.168.1.150/32,192.168.1.151/32]     pass udp $DNS_SERVERS 53 -> $DNS_SERVERS 53 pass udp $EXTERNAL_NET 53 -> $DNS_SERVERS 53

This told snort to pass (or ignore) any DNS traffic between our DNS servers and pass all DNS traffic between our DNS servers and DNS servers on the external network (which is defined in the main snort.conf file). But we still had a problem. Because snort matches alert and log rules before it tries to match pass rules, the packets still triggered the alert first. We needed to be able to change the matching order. Thankfully, snort provides the -o option, which changes the rule matching order to pass, alert, log.

Tip 

Even though the -o order makes more sense, the author set up the default matching order the way he did because people were writing bad pass rules that were matching more packets than they should, and alerts were getting missed. You should use the -o option only if you feel comfortable writing rules.

Our second pass rule actually introduces a potential hole in our IDS. We were assuming that only external DNS servers would be talking to our DNS servers from a source port of 53. If an outsider were to know of this rule, he could shoot any traffic past our IDS by sending it through with a source port of 53. This is why you have to be extremely careful when writing snort pass rules.

Snort Rules Syntax

For details on the syntax of snort rules, you should go to http://www.snort.org/ or reference Chapter 5 in the book Snort 2.0 Intrusion Detection by Brian Caswell (Syngress 2003). We’ll give a quick summary of how rules are written.

Basic snort rules consist of two parts: the header and the options. The first part of the header tells snort what type of rule it is (such as alert, log, pass). The rest of the header indicates the protocol (ip, udp, icmp, or tcp), a directional operator (either -> to specify source to destination or <> to specify bidrectional), and the source and destination IP and port. The source and destination IP address can be written using the syntax aaa.bbb.ccc.ddd/yy, where yy is the number of network bytes (that is, the netmask). This allows you to specify both networks and single hosts. To specify several addresses, you can put them in brackets and separate them with commas, like this: [192.168.1.0/24,192.168.2.4,192.168.2.10]. Port ranges can be specified using a colon (so that :1024 means all ports up to 1024, 1024: means 1024 and above, and 1024:6000 means ports 1024 to 6000). Alternatively, you can use the keyword any to have all IPs and ports matched. You can also use the exclamation mark (!) to negate the IP or port (for example, 1:1024 and !1025: would be equivalent).

The rule options contain such things as the alert message for that rule and the packet contents that should be used to identify packets matching the rule. The options are always enclosed in parentheses and follow the syntax <keyword>: <value>, with each option pair separated by a semicolon. Several keywords are available. Table 16-4 contains a sampling of the more important keywords taken directly from the documentation.

Table 16-4: Snort Rule Options

Keyword	Description	Example
msg	Prints a message in alerts and packet logs	msg: "Exploit X attempt!";
logto	Packets that trigger this rule should be logged to a special file other than the default output file	logto: "criticalhax.log";
ipopts	Matches packets with particular IP options (like loose source routing) set	ipopts: lssr;
dsize	Matches packets with particular data size or length	dsize: 9;
content	Matches packets with particular content in their data	content: "cmd.exe";
flags	Matches packets with particular TCP flags set (SYN, FIN, etc.)	flags: SF;
session	Record all data or only printable data from an entire session upon matching this rule	session: printable;
reference	Links the rule to a particular reference point, such as a vulnerability database with information about the kind of attack suspected from matching this rule	reference: bugtraq,1459;
sid, rev	Unique identifiers for rules—an ID and a revision number	sid:596; rev:3
tag	Replacement for dynamic and activate rules—rules with this option will “tag” the traffic and record relevant subsequent traffic (either from that host or from that session) for a specified number of seconds or packets	tag: session, 400, packets;
resp	Tells snort to respond when a packet matches this rule by attempting to reset the TCP connection or send an ICMP unreachable message (requires snort to be configured with configure -–enable-flexresp at compile time)	resp: rst_all, icmp_all;
react	Tells snort to react when a packet matches this rule by blocking the connection and sending a message	react: block, msg; msg: "You shouldn't be doing this!";

Many more rule options go in-depth to byte characteristics of packets and protocols, but this gives you a sampling of some of the more standard options. Following are some sample snort rules that look for anyone trying to access cmd.exe through an IIS web server:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-IIS cmd.exe access";  flags: A+; content:"cmd.exe"; nocase; classtype:web-application-attack;  sid:1002; rev:2;)     alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-IIS cmd?  access";flags: A+; content:".cmd?&"; nocase; classtype:web-application-attack;  sid:1003; rev:2;)" 

You’ll see that these are alert rule types for the TCP protocol. It first looks for traffic going from any port from the EXTERNAL_NET (defined in snort.conf) to port 80 on HTTP_SERVERS. Then it checks the content for the specified values and prints the corresponding message (msg) in the default alert log file if the rule is matched. You’ll also notice that the ACK TCP flag must be set, the content should be checked without case sensitivity, and packets matching rule sid 1003 revision 2 are classified as a web application attack.

Another special snort rule is the config rule, which allows you to specify some of the configuration options you’d normally put on the command line into the snort.conf file. For example, config dump_payload in snort.conf is the same as using a –d on the snort command line.

You can perform many other tasks using snort rules in the more recent versions. Snort allows you to define your own rule types (using the ruletype directive) that can log to different locations using different methods via output modules, which we’ll discuss later in the section "Output Modules."

Rules are the heart and soul of snort. If you can master these rules, you can fine-tune snort into an extremely powerful weapon against would-be hackers.

Snort Plug-Ins

We’ve briefly discussed some of the preprocessors and output plug-ins that snort uses to augment its functionality. Although it is not an easy process for a novice programmer, snort has an open API that permits the creation of custom plug-ins to include preprocessor and output plug-ins. The following sections will give examples of some of those plug-ins that are already created and freely available.

Preprocessors

Preprocessors are set up in the snort.conf file using the preprocessor command. They operate on packets after they’ve been received and decoded by snort but before it starts trying to match rules. Table 16-5 describes the most popular preprocessors and their most popular options (as of Snort 2.0).

Table 16-5: Snort Preprocessors

Preprocessor	Options	Description
http_decode	<port_list>	Takes any web URLs that are snarfed from traffic passing on ports in port_list and decodes them into ASCII text. Since URLs can't contain some special characters (like spaces), you'll often see characters like %21 in the URL. This processor converts these characters to ASCII so that the rules will be able to detect URL-based alerts properly.
portscan	<network> <num_ports> <period> <logfile>	One of the more useful plug-ins, port scan watches network and logs alerts to logfile any time num_ports or more ports on your network are hit within an interval of period, in seconds.
portscan-ignorehosts	<host_list>	Think back to our DNS server example. We don't want to get port scan messages about some machines on our network because they're actually legitimate traffic. You can specify a list of IP addresses here (separated by spaces, not commas) that you want to ignore.
frag2	memcap <bytes> timeout <seconds>	Handles the defragmentation of any sniffed fragmented packets. Uses a default memory limit of 4MB and a 60-second timeout for defragmentation processing.
stream4	noinspect keepstats detect_scans detect_state_problems	Allows snort to handle TCP streams (or sessions) and do stateful inspection of packets. The available options tell it to disable stateful inspection, log session information to a file, alert for port scans, and alert for state problems (like misordered sequence numbers), respectively.
conversation	allowed_ip_protocols timeout <seconds> max_conversations <number>	Attempts to track sessions or conversations for other IP protocols, just like stream4 does for TCP.
portscan2	target_limit <num> port_limit <num>	Like the original portscan, but better. It uses the conversation preprocessor. You can control the number of hosts or ports a scan must hit before an alert is triggered. Use portscan2-ignorehosts to ignore certain hosts.

Output Modules

Output modules are also set up in the snort.conf file using the output command, which controls how, where, and in what format snort stores the data it receives. Any rule types you define can be specified to use a particular kind of output plug-in. Table 16-6 describes the most popular output modules (as of Snort 2.0) and their most popular options.

Table 16-6: Snort Output Modules

Module	Options	Description
alert_fast	<logfile>	As with the fast alert mode that can be specified on the command line with –A fast, you can specify a separate file here. Useful if you're defining your own rules and you want some to use the alert_fast module to log to one file while other rules use the alert_fast module to log to another.
alert_full	<logfile>	Same as alert_fast, except it uses the default snort full log mode for alerts.
alert_smb	<workstation_list_file>	Like the -M feature, sends WinPopup alerts to the Windows workstations listed in the file.
alert_syslog	<syslog_facility> <syslog_priority>	Similar to the -s option, allows you to send snort alert messages directly to syslog using the facility and priority you specify.
log_null	N/A	Useful when defining rule types when you want to output the alert but you don't care about logging the packet data.
log_tcpdump	<logfile>	Just like running snort in binary logging format (-b) and specifying a different filename for the tcpdump logfile (-L).
alert_unified, log_unified	<logfile>	A new, extremely efficient logging method that will soon become the default way snort handles logging. Both log formats will be done in binary, and separate programs (such as Barnyard) will be used to parse the binary files into more human-readable formats.
database	<rule_type> <database_type> <parameters>	Log either snort log rules or snort alert rules (depending on <rule_type>) to an external database. The <database_type> indicates what kind of SQL database it is (MySQL, Oracle, PostgreSQL, or UnixODBC) and the parameter list contains necessary information like database host, username and password, database name, and so on.
xml	<rule_type> <parameters>	Log either snort log rules or snort alert rules (depending on <rule_type>) to a file in Simple Network Markup Language (SNML) format. The <parameters> control the location and layout of the file.
CSV	<logfile> <format>	Choose from available items to log in the <format> string and log snort output into a "comma-separated values" file named <logfile>.
trap_snmp	<event_type> <sensor_id> <trap_type> <address> <community>	Send an SNMP alert to a network management station at address <address> in SNMP community <community>.

So Much More…

As you can see, snort is an extremely configurable and versatile IDS. You can update rules with the latest signatures from http://www.snort.org and create your own with relative ease. And you certainly can’t beat the price.

Using snort has a few drawbacks, however. One is that its log and alert files are natively hard to interpret, no matter what output facility you use. Thankfully, several third-party applications such as Sguil, ACID, and SnortSnarf allow you to create reports and parse through all your snort data. SnortSnarf, which is a Perl script from Silicon Defense (http://www.silicondefense.com/software/snortsnarf/), is probably the easiest tool to set up and configure and can be used with snort’s default alert logging format. In minutes, you can get SnortSnarf crunching away on your snort alert and portscan logs. SnortSnarf will generate a detailed HTML report based on those log files. SnortSnarf’s relative simplicity, however, can be offset by the fact that there’s no real-time monitoring capabilities. If you use a combination of Snort’s unified logs, Barnyard (mentioned previously) for importing logs into a database, and ACID (http://www.andrew.cmu.edu/~rdanyliw/snort/snortacid.html) to actually parse and display the logs, you can attain real-time monitoring capabilities over your IDS logs. The drawback here is that the setup and configuration of ACID and all its components can be a bit daunting, but ACID’s web site is filled with detailed instructions. Sguil (http://sguil.sourceforge.net/) is yet another, somewhat lighter, option for real-time IDS monitoring using a back-end database. Regardless of which route you choose, you’ll definitely need one of these applications to be able to keep up with your IDS activity on a daily basis.

You also might want your IDS actively to stop certain kinds of activity that it’s detecting (such as shut down a port or block an IP). Now, snort has built-in rule options that give you these capabilities (resp and react). However, some third-party applications are available (such as Guardian and Hogwash) to give you even more capabilities.

Administration of the rule files and setting up multiple snort sensors can be difficult for beginners. Don’t fret, though, because third-party applications are available to provide administrative front ends. All these applications can be downloaded from http://www.snort.org/dl/contrib/

As you can see, to get snort working at optimal efficiency, it can be quite a chore in the early going. And even after the initial setup is done, you’ll spend a few months tweaking and “training” snort to minimize false alarms. But once you get all the different pieces configured and set up the way you want, snort can’t be beat.

Case Study: Tracking Down the Insider

You receive a phone call from one of your users saying that he isn't able to access the SuperNews web site. You ask him what message his browser was showing him, and he replies, “Error 403—Forbidden.” As soon as you hear this, you tell him, “Well, if you got that message, then the browser is making a network connection to the server, but the server isn't sending back the web page it's supposed to.” You blame it on the folks at SuperNews and tell him to wait it out. As the day progresses, you continue to get calls about SuperNews's web site, and you continually tell callers that there's nothing you can do. Finally, one of your users calls and says she was able to access the web site from her dial-up account at home, but not from the office. That doesn't seem right. You try accessing SuperNews from an alternate site and discover that she's right; it appears that only traffic from this office is being forbidden.

You find the contact information for SuperNews's webmaster and e-mail him about the problem. You shortly receive a rather rude and terse response claiming that someone from your IP address has been abusing the SuperNews web server and network, running port scans, web worms, and even common gateway interface (CGI) exploits against the web server. Your IP has been banned until the person responsible ceases this activity.

Unfortunately, you have no way of knowing who is the perpetrator. Your firewall logs are set up to record any incoming traffic, but you're not currently monitoring outgoing traffic. You swallow your pride and admit to the SuperNews webmaster that you have no logs with which to find the perpetrator. You beg him to reinstate your IP address, with the promise that you will closely monitor the outgoing activity on your network so that the perpetrator can be found and disciplined. The webmaster grudgingly agrees to your proposal.

Your users are happy again, but now you need to get to work on your end of the bargain. The detective work begins: who's trying to hack super_news.com?

Tcpdump: Setting the Trap   Even though you're well aware that the inside perpetrator might be participating in nefarious activities with other web sites, your main concern is watching any activity directed toward the SuperNews web site. The easiest action for you to take is to set up a sniffer on your network that will watch all outgoing traffic for packets destined for the SuperNews web server's IP address.

Because you use network address translation (NAT) at the office, from the outside it appears that all your Internet traffic is originating from a single IP address. You'll need to put your sniffer before the NAT box to see the private IP addresses of the machines talking to SuperNews. Also, because your network runs on a switched environment, you'll need to make sure your sniffer box is attached to a switch port that is configured for port monitoring. You also need to check to make sure that the date and time on your sniffer box is accurate, so that you'll know the “when” and not just the “who” and “what.”

After you've done all that, your easiest option is to use tcpdump. You run the command line:

tcpdump –w perp.dump dst host www.super_news.com –s 512

This tells tcpdump to record only the first 512 bytes of outgoing packets destined for the SuperNews web server. By not limiting the request to port 80, you might pick up any other kind of port scan or hacking activity directed at SuperNews.

Because you're recording the packets to a binary file called perp.dump, you can analyze it later and filter on additional characteristics to help break things down. You leave it running as a background job and wait for the insider to strike again.

Ethereal: Identifying a Suspect   A few days after setting your trap, you get another call from one of your users saying that SuperNews is down again. You check and confirm that SuperNews has again blocked your IP address from accessing its site. You would have liked to have caught this before SuperNews did, but at least you know that you should now have enough information in your tcpdump dump file to find out who's responsible.

You stop your tcpdump job and first look over the perp.dump file using the tcpdump –r perp.dump command. At first, all you can see are hordes of port 80 requests that all appear normal and genuine. So you decide to see how many non-port 80 requests were made by typing

tcpdump –r perp.dump not dst port 80.

You see some Pings from several different IP addresses, but you see some port 21 connections from a local IP of 10.10.4.24. SuperNews might have an anonymous FTP service on this box, so that might be legitimate. But less than a second later you see a port 23 telnet connection attempt from that same IP. You have your first suspect!

You want to find out what this guy has been up to, but you know that using the tcpdump command line will be rough, even using the –X option. You load up the perp.dump file in Ethereal and prepare a display filter on the IP address of 10.10.4.24. Using Ethereal, you're able to point and click through every packet that was sent to SuperNews. By looking at the TCP ports and the timestamps, you notice that several different port scans were performed. You use the throughput graph feature to get an idea of when 10.10.4.24 was launching these attacks. Lo and behold, the most intense behavior occurred last night at 3 A.M. and was most likely the catalyst for SuperNews's second blacklisting of our IP.

Focusing in on that 3 A.M. period, you use the “Follow TCP Stream” tool to see what else the user was up to. You see several CGI exploit attempts that were obviously run from a script because of the large number of attempts made in a short time frame. You also see that the user was trying to brute force his way into a telnet account but was unsuccessful. You now have enough information to confront the perpetrator, but you worry that the perp might be up to more than just script-kiddy activities and Denial-of-Service attempts. You block 10.10.4.24 from sending any outgoing traffic to SuperNews in the meantime, but now it's time to set up a sniffer specifically targeted for his IP address to determine what else he's been up to.

Dsniff: Gathering Evidence   You check the privacy policy for your company to make sure you have the right to watch this user's activities while using company equipment and network resources. Since you do have the right, you decide to use the dsniff snarf utilities to capture such things as his e-mail messages (mailsnarf), chat conversations (msgsnarf), web site visits (urlsnarf), and NFS transfers (filesnarf).

You pick up e-mails and instant messages to a person with a screen name and e-mail address of SNSux. In the messages, your user is telling his friend that he's been launching a bunch of scripts he's found on the Internet against SuperNews's site, and he boasts that he's even brought down SuperNews's web server twice already. Obviously, the perpetrator knows only enough about hacking and networks to get himself in trouble, as he mistook the SuperNews blacklisting as a successful denial of service on the site's web server.

You intercept replies from SNSux saying that he never saw the web site go down, but that he still has a friend on the inside who might be able to get them a valid login on the SuperNews network. This could have serious implications. You quickly realize you're getting out of your league and will soon need to contact the authorities. You gather up all your information and contact the SuperNews webmaster with your findings. You then give your findings to your department manager, who assures you that the problem will be dealt with properly.

IDS: Learning a Lesson   After recent events, you realize you had been well prepared for any external attacks coming into your network, but you weren't at all prepared to catch anyone internal launching external attacks. You set up an IDS on your internal network that will look for such activities as outgoing port scans, CGI attacks, Denial-of-Service attempts, and other undesirable network behavior. This will help keep any future blacklistings from happening.

---