Incident Handling/Reporting Script ---------------------------------- I have seen lots of attempted attacks and scans of networks for vulnerable services. Usually when I see this I try to report this attack to the admins and owners of the suspect IP(s). This is time consuming, and I realized much of this procedure could be automated. This program was written to do just that. It is based on what I consider good practice when reporting security incidents. It is highly tailored for my own environment, so it may be absolutely useless to you. I hope it is not :). Requirements ------------ The following PERL modules need to be installed: MIME-Base64 - For Mail-Sender Mail-Sender - For sending the incident report Net-Telnet - For probing of the attacker's machine Net-Rwhois - For domain whois querying You can get these from CPAN. However, Net-Rwhois is included in this tar. The latest is available at http://www.rwhois.net/ The following commands MUST be in your PATH. If you don't have these programs, get them: wget - For grabbing HTTP output whois - For generic WHOIS xwd - For attempting a screendump of attacker smbclient - For getting file share list of attacker finger - For fingering dig - For figuring out domains for non-resolvable IPs Setup ----- Copy incident.pl.cfg.example to either: ./incident.pl.cfg (in the current directory) or $HOME/.incident.pl.cfg Edit this file and make the proper changes. The values specified in this file will override any set in the script itself. Note that if you are upgrading, you should replace your old config file with the new one and make your site specific changes to it. Otherwise you may miss some new options. What it does ------------ I run snort on my firewall, which is configured to log attacks to a syslog server. For an example attack, I get logs similar to: Feb 10 13:15:11 fwml-off.mydomain.com snort[16526]: IDS278 - SCAN -named Version probe: 166.188.17.76:8300 -> 1.2.3.2:53 Feb 10 13:15:12 fwml-off.mydomain.com snort[16526]: IDS278 - SCAN -named Version probe: 166.188.17.76:46761 -> 1.2.3.64:53 Feb 10 13:15:12 fwml-off.mydomain.com snort[16526]: IDS278 - SCAN -named Version probe: 166.188.17.76:28931 -> 1.2.3.65:53 ... This information is then saved to a file and the script is run on it: ./incident.pl file.txt The file.txt is scanned for an IP that 'appears' to be an attacker. What this is basically looking for is the most number of occurrences of one particular IP. You may be saying that this would only 'find' portscans, and that is true. But from all of the attacks I've seen, portscans are pretty much 99% of them. If the script is incorrectly finding the attacker IP, you can override this behavior by providing the IP or just a string to isolate the logs: ./incident.pl file.txt 166.188.17.76 or ./incident.pl file.txt IDS278 (which would isolate the search to lines with the string 'IDS278') What if you are not using syslog like I am? Well this program may then be useless to you. It is parsing single lines, so for example the full snort packet capture log shouldn't be used with this script. I recommend sending your snort logs to a syslog server and using logcheck (http://www.psionic.com) on those logs. The script will then proceed to get as much information about the attacker possible, compose a message containing this info, figure out the contacts for the attacker, and optionally send the warning message out. Example ------- Suppose a file 'case' has syslogs similar to: Apr 14 23:11:08 blah-off.mydomain.com snort[86706]: MISC-WinGate-8080-Attempt: 211.191.28.13:1693 -> 1.2.3.2:8080 Apr 14 23:11:11 blah-off.mydomain.com snort[86706]: MISC-WinGate-8080-Attempt: 211.191.28.13:1693 -> 1.2.3.2:8080 Apr 14 23:11:13 blah-off.mydomain.com snort[86706]: MISC-WinGate-8080-Attempt: 211.191.28.13:1755 -> 1.2.3.64:8080 ... ./incident.pl case Using config /home/valankar/.incident.pl.cfg Analyzing input... Attack appears to be from 211.191.28.13 Reverse lookup: failed Isolating input for 211.191.28.13 Information Gathering Sat Sep 8 11:22:22 EDT 2001 WHOIS 211.191.28.13...ARIN redirect to APNIC...APNIC redirect to KRNIC...succeeded. Trying to figure out domain name after failed reverse lookup. Possible candidate: ns.shinbiro.com Looking up MX record for ns.shinbiro.com...failed. Looking up MX record for shinbiro.com...succeeded. RWHOIS shinbiro.com... redirect to whois://whois.networksolutions.com...succeeded. TCP CONNECT TO 211.191.28.13:21 failed TCP CONNECT TO 211.191.28.13:22 failed TCP CONNECT TO 211.191.28.13:23 failed TCP CONNECT TO 211.191.28.13:25 failed TCP CONNECT TO 211.191.28.13:79 failed TCP CONNECT TO 211.191.28.13:80 failed TCP CONNECT TO 211.191.28.13:139 failed TCP CONNECT TO 211.191.28.13:6000 failed TCP CONNECT TO 211.191.28.13:6001 failed Excerpt of logs: Apr 14 23:11:08 blah-off.mydomain.com snort[86706]: MISC-WinGate-8080-Attempt: 211.191.28.13:1693 -> 1.2.3.2:8080 Apr 14 23:11:11 blah-off.mydomain.com snort[86706]: MISC-WinGate-8080-Attempt: 211.191.28.13:1693 -> 1.2.3.2:8080 Apr 14 23:11:13 blah-off.mydomain.com snort[86706]: MISC-WinGate-8080-Attempt: 211.191.28.13:1755 -> 1.2.3.64:8080 Apr 14 23:11:13 blah-off.mydomain.com snort[86706]: MISC-WinGate-8080-Attempt: 211.191.28.13:1756 -> 1.2.3.65:8080 Add description of attack to message? y Enter description (ctrl-d on blank line to end): Scan of our network for vulnerable WinGate services. Email for 211.191.28.13 written to /home/valankar/incident/shinbiro.com/20010908112222/orig_email.txt View/edit message? n Possible admin contacts: ip@mgate.shinbiro.com jhk@shinbiro.com sylee@shinbiro.com root@shinbiro.com postmaster@shinbiro.com webmaster@shinbiro.com abuse@shinbiro.com security@shinbiro.com noc@shinbiro.com Send message? y For an example of an actual message sent out, see example_email.txt. Options ------- Process ALL IPs found in input, prompting before each IP: -a This option is useful when you want to process many IPs that are in the input file. All IPs will be gathered and processed in the order of their number of occurences (highest first). You will be prompted before processing each IP, as well as given a brief log excerpt for the IP. This is similar to calling the script many times, using something like 'grep -v' to remove already processed IPs. Process ALL IPs found in input, without prompting before each IP: -A Same as above, but does not prompt you before each IP. Batch mode: -b This mode can be used to automate reporting without prompting you for anything. Here is an example: ./incident.pl -b -d "Scan of our network for vulnerable SSH servers" case This assumes Yes to send mail. Note that if you do not specify -d, no description will be put in the message. Use description: -d If you do not want to be prompted for a description, you can use this option. See 'Batch mode' above for an example. Note you can use this without using batch mode. Email Followup Processing: -e If first argument of the script is -e, it assumes the standard input is a email followup. It will parse the input and store the email in the corresponding directory created when the incident was reported. The filename is determined by $FOLLOWUP_FILE in the config section. This makes it easier to store email related to an incident together with the report. Piping the message from your email client is usually the best way to use this feature. Note that all other arguments are ignored when -e is used. The email must have the same subject as the report (with 'Re:' or whatever else). Do not ignore 'Received:' lines: -r Normally lines with 'Received:' in them are mail headers and should be ignored. Use this option to not ignore them for some reason. Plain contact gathering: -x The -x option can be used to just find information on an IP, hostname, or domain name. It will dump out whois and possible contact emails and then stop. This is a very good way to find out all information on an IP or domain instead of using plain old WHOIS. Disable host probing: -H Probing an attacker machine may be considered retaliation by some. Use this option to disable it. Bugs and Suggestions -------------------- Please report them to valankar@bigfoot.com I am very interested in cases where the contacts or domains are not determined properly. This is in my opinion a very complicated part of analyzing attacks and unfortunately the non-standardization of WHOIS does not help. Most of the 'problems' handled in the code were added on a case-by-case basis, so if you come across any IP that is strange or requires more processing to get the real contacts please send it to me. Also if you have any suggestions or hacks you have implemented on the script that may be useful to others let me know. See the TODO for what is currently planned.