| An incident can be a number of things; you need to define it for yourself. For example, an incident might be defined as an anomalous attempt to gain or escalate privilege or compromise the confidentiality, integrity, or availability of one or more systems. It is good practice to monitor your system log files, system-integrity reports, and system-accounting reports as a matter of habit. Even with minimal logging enabled, sooner or later you'll see something that your security policy dictates is important enough to report. With full logging enabled, you'll have plenty of log entries to ponder 24 hours a day. Some access attempts are more serious than others. Some will annoy you personally more than others. The following sections start by discussing reasons why you might want to report an incident and cover considerations concerning which types of incidents you might report. These are individual decisions. If you choose to report something, the remaining sections focus on the various reporting groups available and the kinds of information you need to supply them. Why Report an Incident? You might want to report an incident even if the attack attempt was unsuccessful. These are some of the reasons: To end the probes Your firewall ensures that most probes remain harmless. But even harmless probes are annoying if they occur repeatedly. Persistent, repeated, ongoing scans fill your log files. Depending on how you've defined the notification triggers in any log-monitoring software that you run, repeated probes can pester you with continual email notifications. However, in today's age of seemingly endless probes from bots owned by unaware broadband users, especially those in the United States, it would simply be too time-consuming for most people to report every probe. To help protect other sites Automated probes and scans are generally building a database of all vulnerable hosts in a large IP address block. When identified as potentially vulnerable to specific exploits, these hosts are targeted for selective attacks. Today's sophisticated analysis and cracking tools can compromise a vulnerable system and hide their tracks in seconds. Reporting an incident might put a stop to the scans before someone somewhere else gets hurt. To inform the system or network administrator Attacking sites quite often are compromised systems, host a compromised user account, have misconfigured software, are being spoofed, or have an individual troublemaker. System administrators are usually responsive to an incident report. ISPs tend to stop their troublemaking customers before other customers start complaining that remote sites have blocked access from their address block and that they can't exchange email with a friend or family at a remote site. To receive confirmation of the attack Sometimes you might simply want confirmation that what you're seeing in the logs is a problem. Sometimes you might want confirmation that a remote site was indeed leaking packets unintentionally because of a faulty configuration. The remote site also is often glad for the heads-up that its network isn't behaving as it had intended. To increase awareness and monitoring by all involved parties If you report the incident to the attacking site, the site hopefully will monitor its configurations and user activities more carefully. If you report the incident to an abuse center, the abuse staff can contact the remote site with more clout than an individual carries, keep an eye out for continued activity, and better help customers who have been compromised. If you report the incident to a security newsgroup, other people can get a better idea of what to watch out for.
What Kinds of Incidents Might You Report? Which incidents you report depends completely on your tolerance, how serious you consider different probes to be, and how much time you care to devote against what is a global, exponentially growing infestation. It comes down to how you define the term incident. In different people's minds, incidents can range anywhere from simple port scans to attempts to access your private files or system resources, to denial-of-service attacks, to crashing your servers or your entire system, to gaining root login access to your system: Denial-of-service attacks Any kind of denial-of-service attack is blatantly hostile. It's difficult not to take such an attack personally. These attacks are the electronic form of vandalism, obstruction, harassment, and theft of service. Because some forms of denial-of-service attacks are possible because of the inherent nature of networked devices, you can do little or nothing about some forms of attack other than to report the incidents and block the attacker's entire address block. Attempts to reconfigure your system An attacker can't reconfigure your servers without a root login account on your machine, but he could conceivably modify your system's in-memory, network-related tablesor try, at least. Exploits to consider include these: Unauthorized DNS zone transfers to or from your machine over TCP. For more information on zone transfers, see the book DNS & BIND, by Albitz and Liu (O'Reilly). Changes to your in-memory routing tables via ICMP Redirect or probes to UDP port 520 for routed or gated. (Remember, a firewall machine should not support dynamic routing.) For more information on routing table exploits, see the book Firewalls and Internet Security: Repelling the Wily Hacker, by Cheswick and Bellovin (Addison-Wesley). Attempts to reconfigure your network interfaces or routing tables via probes to UDP port 161 for snmpd.
Attempts to gain local configuration and network topology information Network information requests are mostly directed to UDP port 161 for snmpd. DNS queries over TCP port 53 provide network topology information, as do routing queries to UDP port 520 for routed or gated. Attempts to gain login account access Probes to telnet TCP port 23 and ssh TCP port 22 are obvious. Less obvious are probes to ports associated with servers known to be exploitable, either historically or currently. Buffer overflow exploits are generally intended ultimately to execute commands and gain shell access. The mountd exploit is an example of this. Attempts to access nonpublic files Attempts to access private files, such as the /etc/passwd file, configuration files, or proprietary files, show up in your FTP log (/var/log/xferlog or /var/log/messages) and in your web server access log (/var/log/httpd/error_log). Attempts to use private services By definition, any service you haven't made available to the Internet is private. These are the private services potentially available through your public servers, such as attempts to relay mail through your mail server. Chances are, people are up to no good if they're trying to use your machine instead of their own or their ISP's. Relay attempts show up in your mail log file (/var/log/maillog). Attempts to store files on your disk If you host an improperly configured anonymous FTP site, it's possible for someone to set up a repository of stolen software (WAREZ) on your machine. Attempts to upload files are recorded in your FTP log (/var/log/xferlog) if ftpd is configured to log file uploads. Attempts to crash your system or individual servers Buffer overflow attempts against CGI scripts available through your website are possibly the easiest to identify by error messages written in the CGI script's log files. Other reports of erroneous data will appear in your general syslog file (/var/log/_messages), your general daemon log (/var/log/daemon), your mail log (/var/log/maillog), your FTP log (/var/log/xferlog), or your secure access log (/var/log/secure). Attempts to exploit specific, known, currently exploitable vulnerabilities Attackers find new vulnerabilities with each new software release (and old ones too). Keep up-to-date with the newest advisories from http://www.cert.org and your Linux software vendor.
To Whom Do You Report an Incident? You have a number of options in terms of whom you report an incident to: root, postmaster, or abuse at the offending site The obvious place to lodge a complaint is with the administrator of the offending site. Informing the system administrator is often all that's required to take care of a problem. This isn't always possible, though, because many probes originate from spoofed, nonexistent IP addresses. Network coordinator If the IP address doesn't have a DNS entry, contacting the coordinator for the network address block is often helpful. The coordinator can contact the administrator at the offending site or put you in direct contact. If the IP address doesn't resolve through the host or dig commands, you can almost always find the network coordinator by supplying the address to the whois databases. The whois command is hard-wired into the ARIN database. Three major databases are available through the web: ARIN The American Registry for Internet Numbers maintains the IP address database for the Western hemisphere, the Americas. ARIN is located at http://whois.arin.net/whois/arinwhois.html. APNIC The Asia Pacific Network Information Centre maintains the IP address database for Asia. APNIC is located at http://www.apnic.net/apnic-bin/whois.pl. RIPE The Réseaux IP Européens maintains the IP address database for Europe. RIPE is located at http://www.ripe.net/db/whois.html.
Your ISP abuse center If scans are originating from within your ISP's address space, your abuse center is the place to contact. Your ISP can be helpful with scans originating elsewhere, too, by contacting the offending site on your behalf. Chances are good that your machine isn't the only machine being probed on the ISP's network. CERT The CERT Coordination Center is unlikely to have the resources to respond to general, run-of-the-mill incidents. CERT's priorities are more likely aimed at global issues, large institutions, and Internet security emergencies. Nevertheless, CERT welcomes incident report information for its tracking and statistical reporting efforts. CERT can be contacted at http://www.cert.org/_contact_cert/contactinfo.html or by email at cert@cert.org. Your Linux vendor If your system is compromised because of a software vulnerability in its distribution, your vendor will want to know so that a security upgrade can be developed and released.
What Information Do You Supply? An incident report must contain enough information to help the incident response team track down the problem. When contacting the site the attack originated from, remember that your contact person might be the individual who intentionally launched the attack. What you include out of the following list depends on whom you are contacting and how comfortable you are including the information, as well as whatever privacy and other policies may be in effect: Your email address Your phone number, if appropriate Your IP address, hostname, and domain name The IP addresses and hostnames, if available, involved in the attack The date and time of the incident (including your time zone relative to GMT) A description of the attack How you detected the attack Representative log file entries showing the incident A description of the log file format References to advisories and security notices describing the nature and significance of the attack What you want the person to do (fix it, confirm it, explain it, monitor it, or be informed of it)
Where Do You Find More Information? As network security comes increasingly to the public's mind, the number of security-related websites is growing quickly. CERT and COAST remain excellent sources for security information. The SANS Institute at http://www.sans.org/ and Security Focus at http://www.securityfocus.com/ both provide timely and in-depth information on security as well. The mailing lists on the Security Focus website are particularly good, and I encourage you to not only read the archives but subscribe and participate in the lists. Appendix A, "Security Resources," also contains suggestions with some other sites and locations for security information as well. |
