Guidelines for Reporting Port Probe Activity:

Created: 27-Apr-2001
Modified: 02-Apr-2002
By: Lawrence Baldwin

With the proliferation of broadband Internet connections many have taken the wise step of installing personal firewalls. Shortly after installation, you will inevitably begin receiving dozens of firewall alerts/day. These alerts are often difficult to interpret and firewall vendors provide little guidance regarding how (or if) you should respond.

This document explains:

• Why reporting security events to their source is important
• Which events to report and which to ignore
• Escalation e-mail format
• Locating the responsible party
• Timestamp synchronization techniques
• Automated tools for firewall log reporting

If my firewall blocked an event, should I care?

If your firewall is logging an event, it's usually because it successfully blocked the activity. Thus, regardless of the frequency of events, YOUR security is not impacted nor diminished. Although a logged event indicates that YOUR system is secure, it indicates that the SOURCE system may not be.

Why bother reporting events?

Many argue that since port scanning is not illegal in most states/countries, there is no point in reporting it. While the former may be true, it is irrelevant. In almost every case, port scans are NOT generated by a hacker sitting at a keyboard, but rather by automated scripts which have been installed on the source system often through infection by popular Internet worms (e.g. Code Red, Nimda, etc.). The purpose of responding to probes is NOT to prosecute hackers, but rather to inform innocent victims that their systems have likely been compromised.

Should I report every event my firewall logs?

Absolutely not!

Every security incident you report consumes a significant amount of an ISP's and/or system administrator's time. Reporting all events without the proper filtering, backtracing, and formatting is irresponsible and can do more harm than good because it distracts administrators from real or more serious issues.

What events SHOULDN'T I report?

• Events sourced from your own PRIVATE network
• IRC open proxy test probes originating from servers you connect to
• Proximity probes from web load-balancers (e.g. Cisco Distributed Director, 3DNS, Linkproof, etc..)
• Webcrawler probes
• Probes from your ISP's DNS server
• DHCP probes from your ISP's DHCP server
• Probes from your ISPs authorized scanning server (e.g. @Home)
• Probes most likely associated with peer-to-peer file sharing (e.g. Gnutella, Napster, Kazaa, etc..)
• Probes most likely associated with Internet gaming (e.g. Doom, Half-life, etc..)
• Port scans that you request from a port scan site (e.g. Shields UP, DSLreports, etc..)
• Wrong number scans

What information should be in the report?

• Event DateTime (UTC)
• Source IP
• IP Protocol
• Source Port
• Destination IP
• Destination Port

What should a security report look like?

Be non-confrontational, and non-accusatory...stick to the facts and the evidence that you've collected. This kind of tone is much more likely to get action and a response.

Provide all log information in the body of your message. Don't send logs as attachments or HTML links--many ISPs use ticketing systems that can't process attachments or HTML.

Only provide log events associated with ONE specific source IP address at a time. Don't send your entire firewall log expecting them to sort it out for you. If you need to report issues regarding multiple source IP addresses, then send a separate e-mail for each one.

Here's an example e-mail:

To: Abuse@sourceISP.net
From: Your e-mail address
Subject: Security issue - Source IP: 200.200.200.200

To whom it may concern:

The purpose of this e-mail is to make you aware of a potential
security issue appears to be originating from your network.

My firewall recently logged the following event which appears to have
originated from your network:


DateTime: 01-Dec-2001 23:01 UTC
Source IP: 200.200.200.200
IP Protocol: TCP
Source Port: 1234
Destination IP: 205.152.0.0 (masked)
Destination Port: 111

This connection attempt was unsolicited and therefore, may indicate that
the your host is compromised or is being used for unauthorized purposes.


If you have any questions or need further information, please
do not hesitate to contact me.

Regards,


John T. Wall

How should the event timestamp be reported?

Many ISPs utilize dynamic IP addresses, therefore a single address could be used by dozens or hundreds of subscribers within a single day. Usually, ISPs maintain a timestamped log entry whenever a dynamic IP address is assigned to a specific subscriber. Often these log timestamps are formatted using Universal Time (UTC) reference. Therefore, you should ideally report your event time in UTC format as this facilitates matching your events with ISP logs.

If it is not convenient to format your timestamps in UTC format, then make sure you report which time zone your event is referenced to.

For example:

01-Dec-2001 18:01 -0500 (EDT)

-0500 - Indicates the Time Zone Offset from UTC (-5 hours)
(EDT) - Indicates the time zone common name (Eastern Daylight Savings Time)

Providing an IP address without an associated timeframe often makes backtracing impossible.

How accurate do my log timestamps need to be?

Providing an inaccurate timestamp is actually worse than providing no timestamp at all. If your log timestamp is off by even a few minutes, you may be implicating the wrong subscriber.

Unless you know for certain that the IP address you're reporting is statically assigned, you shouldn't file security report until you can assure accurate timestamps to +- 5 seconds.

The most convenient way to accomplish this is by installing a Network Time Protocol (NTP) client and ensuring regular clock synchronization with an atomic clock source.

NTP clients are included with most Unix implementations.

Microsoft XP now includes an NTP client. For a free NTP client for other Windows versions see: Automachron NTP Client

Also make sure you've have your system configured in the correct time zone:

Verify system clock/time zone settings

Note: NTP clients only ensure that your system TIME is accurate...it's up to you to ensure that your system DATE is set properly.

What's the oldest event I should report?

Many organizations are only able to retain logs for a few days. Therefore, unless an incident is particularly serious, you should only report events that are no more than 72 hours old.

Should I reveal my full IP address?

Probably not.

If you have a static IP address, or a dynamic IP that doesn't change often, you should never report the entire Destination IP for privacy reasons. Instead mask the lower 2 or 3 octets (e.g. report 205.152.0.0 or 205.0.0.0).

Where do I e-mail security reports?

You need to send security reports to whoever has responsibility for the SOURCE IP address.

Do NOT send reports to YOUR ISP, unless the activity originated from one of your ISP's IP addresses

To backtrace a SOURCE address, perform the following steps:

• Find the responsible domain
• Find the appropriate mailbox for security issues

Step 1: Finding the responsible domain

• Reverse DNS
• Whois Records

For example, let's assume a Source IP of: 24.37.98.164 Next we need to lookup the Reverse DNS name associated with this IP and/or the Whois records for this IP. There are many client-based and web-based tools to gather this information. One popular one is SamSpade.org Click on the above link to backtrace the example Source IP.

The reverse DNS name is: cc1081191-a.gambrills1.md.home.com

Thus we now know that the responsible domain is 'home.com'.

If no reverse DNS name is available, which is often the case (especially for IP addresses outside the United States), we could determine the responsible domain from the Whois record:

@Home Network (NETBLK-BLTMMD1-MD-13)
   425 Broadway
   Redwood City, CA 94063
   US

   Netname: BLTMMD1-MD-13
   Netblock: 24.37.96.0 - 24.37.111.255

   Coordinator:
      Operations, Network  (HOME-NOC-ARIN)  noc-abuse@noc.home.net
      (650) 556-5599

   Record last updated on 19-Jul-2001.
   Database last updated on  2-Dec-2001 19:54:36 EDT.

In this case we'd select a responsible domain of 'home.net' (which is synonymous with 'home.com').

Step 2: Finding an appropriate mailbox for security issues

The following Internet standard indicates that all domains must provide a mailbox 'security@domain_name' for security issues:

RFC 2142 - MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS

Unfortunately, in practice far less than 10% of registered domains provide a 'security@' mailbox. Therefore, you'll have to check several sources to determine the preferred mailbox for a given domain:

Abuse.net Lookup: 'home.net'

Results:
abuse@home.com
abuse@home.net

Abuse.net maintains a database of the preferred mailboxes for reporting SPAM abuse, however, this if often the same mailbox that ISP's prefer to receive security reports

If a domain is not registered in Abuse.net's database, then you should examine the Whois records of the IP address. Sometimes the Whois record will contain a comments section that indicates the owner's mailbox preferences. If there are no comments listed, then you can try to route the e-mail to the contact mailbox listed. Unfortunately, these mail addresses are notoriously out-of-date and are often invalid. If you receive e-mail errors, you may also have to try sending your report to the 'postmaster@', 'root@', 'webmaster@' mailboxes for the responsible domain.

This all seems VERY time consuming, is there an easier way?

Yes. Instead of reporting port probes directly to the source ISP, report them to a security 'aggregator':

• myNetWatchman.com (free)
• Dshield.org (free)
• ARIS (fee-based)

The aggregators provide software to automatically relay your firewall events to their central database, and automatically handle backtracing.

Each aggregator supports different firewall and operating system combinations, take varying action on the data you submit, and provide different levels of reporting. So review their respective web sites carefully and decide which is best for your needs.

If you have any questions or comments regarding this document, please send email to:
Lawrence Baldwin
myNetWatchman.com