SNORT: AN INTRUSION-DETECTION SYSTEM
| | ||
We've talked about intrusion-detection systems (IDSs) throughout this book. At its core , an IDS is a sniffer, but one that has specialized filters to identify malicious activity. A good IDS can find anything from a buffer overflow attack against an SSH server to the transmission of /etc/password files over FTP. Network architects place IDS hosts on strategic points in the network where they can best monitor traffic. 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 2.3.3.
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/ 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 threatsas 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.
A fourth mode, inline, was introduced in version 2.3.0. This mode enables snort to work with a firewall ruleset (iptables) in real-time to block attacks. This enables snort to complement a firewall by reacting to port scans , buffer overflows, or other malicious activity for which the firewall isn't prepared.
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 interestetc 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 hosteven 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 sfPortscan" to check them out. The syntax for an example preprocessor is shown here:
preprocessor flow: stats_intercal 0 hash 2 preprocessor sfPortscan: proto { all } watch_ip { $HOME_NET } ignore_scanners { [192.168.1.150/32 192.168.1.151/32] } logfile portscan.log The first statement sets up a flow directive, which is required for sfPortscan. The second rule tells snort to log an alert to portscan.log in our log directory whenever it detects activity on our HOME_NET (previously defined as 192.168.1.0/24). The rule also instructs snort to ignore port scans that appear to originate from two DNS serversmany times normal DNS activity might be mistakenly identified as a UDP port scan. 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 (plus an additional three that are specific to inline mode):
-
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 information 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 tells snort to pass (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 there is still a subtle 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/. 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 bidirectional), 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 bits in the netmask. This allows you to specify networks and single hosts in the same syntax (single hosts have a netmask of 32 bits). 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.
| Keyword | Description | Example |
|---|---|---|
| msg | Prints a message in alerts and packet logs. | msg: "Exploit X |
| 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: |
| rev | Unique identifiers for rulesan ID and a revision number. | sid:596; rev:3 |
| classtype | Common classes of activity as defined in the classification.conf file. Classes also have a corresponding priority that signifies their potential security impact. | classtype:bad-unknown |
| priority | The severity associated with the rule. High values correlate to high severity. | Priority:5 |
| pcre | Applies a Perl-compatible regular expression to the packet. | pcre: "\/etc\/passwd" |
| ipopts | Matches packets with particular IP options set. These options are part of the protocol. | ipopts: lssr; |
| flags | Matches packets with particular TCP flags set. | flags: SF; |
| logto | Packets that trigger this rule should be logged to a special file other than the default output file. | logto: |
| session | Records all data or only printable data from an entire session upon matching this rule. This option can negatively impact snort's performance. | session: printable; |
| resp | When a packet matches this rule, respond with traffic to reset the TCP connection or send an ICMP unreachable message. Snort must be configured to support flexible response. enable-flexresp | resp: rst_all, icmp_all; |
| react | When a packet matches this rule, respond with traffic to close the TCP connection and send a message to the source IP address that triggered this rule. Typically used for web-based services. Snort must be configured to support flexible response. enable-flexresp | react: block, msg; msg: |
| tag | Replacement for dynamic and activate rulesrules 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, |
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-activity; 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-activity; 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 logfile 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.3).
| Preprocessor | Options | Description |
|---|---|---|
| http_inspect | (Lots! Refer to snort's documentation.) | This preprocessor provides the capability to examine HTTP traffic. Many aspects of HTTP can be examined, including URLs, parameter strings, cookies, and character encodings. This preprocessor can identify scans from tools like Nikto or Nessus. |
| sfPortscan proto | <protocol> scan_type <scan_type> sense_level <n> watch_ip <IP [list]> ignore_scanners <IP [list]> ignore_scanned <IP [list]> logfile <file> | This preprocessor supersedes the older Portscan and Flow-Portscan preprocessors. It provides good heuristics for identifying different scan types and methods. |
| Frag3 | max_frags <n> memcap <n> prealloc_flags <n> | Perform IP packet defragmentation on up to max_frags fragments , using no more than memcap bytes of memory to prevent resource exhaustion. Defragmentation is often necessary to properly examine packets and TCP sessions. |
| stream4 | noinspect keepstats enforce_state detect_state_problems | Allows snort to handle TCP streams (or sessions) and do stateful inspection of packets. It has several options, among which is log session information to a file or alert for state problems, such as misordered sequence numbers . |
| flow | memcap <n> stats_interval <n> | This preprocessor provides the core of snort's ongoing state management mechanism. It must be defined if sfPortscan is to be used. |
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.
| Module | Options | Description |
|---|---|---|
| alert_fast | <file> | 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 | <file> | Same as alert_fast , except it uses the default snort full log mode for alerts. |
| alert_syslog | <facility><priority> | Similar to the -s option, allows you to send snort alert messages directly to syslog using the facility and priority you specify. |
| alert_unixsock | Establishes a Unix socket from which alerts can be read. | |
| log_null | Useful when defining rule types when you want to output the alert but don't care about logging the packet data. | |
| log_tcpdump | <file> | Identical to running snort in binary logging format ( -b ) and specifying a different filename for the tcpdump logfile ( -L ). |
| alert_unified | <file> | An efficient logging method that saves data in binary format. Other programs, such as Barnyard, are required to parse and analyze these files. |
| Database | <rule_type> | Log either snort log rules or snort alert rules (depending on <rule_type> )toanexternaldatabase. The <database_type> indicates what kind of SQL database it is ( mssql , mysql, postgresql, oracle, odbc) and the parameter list contains necessary information like database host, username and password, database name , and so on. |
| CSV | <file> <format> | Choose from available items to log in the < format> string and log snort output into a commaseparated values file named <file> . |
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.snort.org/dl/ contrib /data_analysis/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 port scan logs. SnortSnarf will generate a detailed HTML report based on those logfiles. SnortSnarf's relative simplicity, however, can be offset by the fact that there are 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/user/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. BASE (http://secureideas.sourceforge.net/) is an improvement on ACID. It provides tools to analyze Snort reports. Sguil (http://sguil. sourceforge .net/) is yet another, somewhat lighter, option for real-time IDS monitoring using a back-end database. Sguil is actively developed by the IDS community. 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. Experiment with inline mode if you desire this functionality.
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.
You've seen a lot of ways sniffers can be used for unethical activities, such as invading others' privacy and stealing information. On the other side of that coin, sniffers can actually be used to debug network communications and make your network safer.
Bob works as a network administrator for a small company that has two offices: one in Washington, DC, and another in London. The long-distance phone charges for calls between the two offices are beginning to pile up. In an attempt to save money, Bob's boss decides that voice over IP (VoIP) is the answer.
Bob meets with the VoIP tech folks to discuss how to implement their solution. They will be installing two devices at the DC location to handle the VoIP. Because IP phones at both the DC and London offices are going to need to access these devices, they tell Bob that the devices will need public IP addresses. Currently everything on both the DC and London networks is NATed behind a single firewall (see Chapter 13 for more on NAT and firewalls), and Bob would like to keep it that way. The VoIP folks say they won't support the solution through a firewall, especially one that does NAT. They give Bob some technical documents on the devices and wish him luck.
The first thing Bob needs to do is determine exactly what happens when an IP phone boots up. How does it find the VoIP device? What ports does it use? Bob grabs a hub, two IP phones, one of the VoIP devices, and his laptop. After plugging them all into the hub, he starts tcpdump on his laptop and boots the phone.
He first sees BOOTP and DHCP requests as the phone attempts to acquire an IP address. Because there is no DHCP server on this hub, the phone never completes the bootstrap and errors out. Knowing this, Bob programs the phone with a static IP address and tries again.
This time, Bob sees broadcast UDP traffic on port 6678. The VoIP device responds on the same port. Bob notices that shortly after the VoIP responds, the phone appears ready to be used. Bob does the same with the second phone, and he then makes a call from one phone to the other. He sees a jumble of traffic pass on the screentoo much to analyze. He restarts his tcpdump command using the w option to write the output to a dump file. After the call finishes, he can break down the dump more easily by loading the dump file into Ethereal. Upon examining the dump, he notices the following types of traffic during the call:
Bidirectional UDP traffic from phones to VoIP device on port 6115 Bidirectional UDP traffic from phones to VoIP device on port 6116 Bidirectional TCP traffic from phones to VoIP device on port 6677 Bidirectional UDP traffic from phones to VoIP device on port 6678
Bob has isolated the ports. Now, he's ready to test his setup through the firewall. He places the VoIP device on a private IP behind the firewall. He sets up the appropriate port forward from the firewall to the VoIP device and opens the ports on the firewall. After hooking his hub into the public network switch, placing the phone outside the firewall temporarily, and configuring it with a public address, Bob is ready to test the phone's functionality through the firewall NAT. He sets up a tcpdump sniffer laptop on his hub as well as behind the firewall so that he can watch the traffic as it passes from one end of the firewall to the other. He boots the phone, and nothing happens. What's going on?
Bob checks his sniffers. He doesn't detect any activity on port 6678 behind the firewall, so he surmises that it must not have gotten through. He checks his other sniffer and discovers the problemall he sees is unanswered UDP broadcasts on 6678. Now that the VoIP device isn't on the same subnet as the phone, the UDP broadcasts won't reach the device. The phone needs to know where to find the VoIP device. Bob explicitly programs the phone with the public IP address of the firewall and reboots the phone. This time, traffic passes as expected.
There's still one more problem, though. Bob has two VoIP devices he needs to place behind his firewall in DC. He's already used up the ports on his only public IP address, so now what does he do? By going into the phone setup, he finds a way to change the 6678 port to something else. He chooses simply to increment it by two. He sets up a port forward from UDP port 6680 on the firewall to UDP port 6678 on the second VoIP device. He doesn't see any other port changes to make on the phone, so Bob hopes that by incrementing this port by two, it will increment all the other ports by two as well. He sets up the appropriate "plus two" port forwards for the second VoIP device, and gives it a shot.
The phone boots, but it never grabs an extension or gets a dial tone. Obviously, something is missing. Bob takes a closer look at his Ethereal dumps. He sees that the phone is correctly talking on the 6680 port to the second VoIP device through the firewall, but it's still using the default port numbers for everything else. The phone is confused because its initial communication goes to the second VoIP, but all other communications go to the first VoIP.
Bob decides to examine the contents of the packets passing on 6680. To his surprise, he sees the numbers 6677, 6115, and 6116 inside one of the packets coming from the firewall's port 6680 (meaning the second VoIP device's port 6678) to the phone. He deduces that the VoIP device must tell the phone which ports it should use for the rest of the communication; that's why it wasn't working. Lo and behold, Bob checks the second VoIP device and finds options for changing the other communication ports sent to the IP phones. He makes the changes on the second VoIP device, reboots the phone, and has success.
Using his trusty sniffer, Bob has been able to figure out how to get his VoIP solution working without using any additional public IP addresses or exposing any additional machines. Because the only remote IP phones that will be using these devices are coming from a single NAT firewall IP in London, Bob can keep access to these somewhat obscure (but nevertheless open) holes restricted. Had Bob not gone to the trouble, he would have had to change his network architecture to support a DMZ or site-to-site VPN type setup, requisition new IP space, or worse leave the VoIP devices unprotected on the public network. This would be a horribly bad idea, because both VoIP devices have telnet and web services running on them for configuration and management purposes. By using sniffers, Bob was able to add functionality with minimal cost, minimal structural change, and maximum security.
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 403Forbidden." 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 the perpetrator is. 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 http://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- kiddie 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.
| | ||
EAN: 2147483647
Pages: 175