Its a note that many of us have received. If were unlucky, its a note that your (not-a-packet-expert) boss has received and weve had to explain it.">We recently received 1 complaint(s) regarding the article below. This issue appears to have originated from your domain (IP address: x.x.x.x).
Please take the appropriate action with your customer or the account in question, enforcing your Acceptable Use Policy.
Regards,
">
Please include your original email to SOMEISP.com in any replies.
">-
A note like this takes a fair amount of explanation when discussing it with your client (or manager), who usually isnt a packet guru. Usually the narrative goes something like this:
While (maybe) its a good thing that an ISP is looking at traffic to find malicious patterns, unfortunately, in this case the ISP just plain gets it wrong. Their entire conclusion is based on the source port. Unfortuntately, the source port in most TCP communications is what is called an ephemeral port - its either the next free port available after 1024, or a random free port above 1024.
Add to that, in outbound communications, most TCP sessions are run through a firewall that NAT each session ( NAT = Network Address Translation), so that each of these ephemeral ports is mapped to yet a different ephemeral port.
As you can see, from the outside networks perspective, the source port could be just about anything. So if you are looking for a suspicious port, youll find it as a source port on any corporate firewall most days.
OK, so should the abuse@ folks look at the port at the other end? Umm- sort-of. Say someone is sending you an email or browsing to your website - in this case, the ephemeral port is at their end, and the target port is at your end.
Really, what you want to do is look at the ports at both ends - but not to make a final determination. You might use that method to narrow down your search, before you then look at the contents of the actual packets. An even better approach is to *start* by looking at the contents of the packets - but if youre an ISP that adds up to a lot of packets which needs a corresponding amount of CPU and disk to deal with it.
If you are an organization who needs to get a handle on outbound traffic (which is just about every organization), consider implementing an IPS on the traffic to/from the inside interface of your firewall - at that location you can see the true IP addresses and ports of all traffic, both source and destination.
Another great thing to look at implementing is a Netflow collector (or sFlow or jFlow or IPFIX, depending on your gear) - a tool like this helps you to slice and dice your network traffic statistics to get quick answers, or in many shops netflow graphical display is the most used feature, allowing a quick, visual way to identify odd traffic or trends.
Also an egress filter goes a long way to containing problems - if you only allow permitted traffic and have a default deny policy for all mystery traffic, youll find that your problems are more likely to stay contained within your network, and if you are looking at your logs youll be alerted much earlier in the process.
What youll find with proper monitoring like this (IPS, Netflow, egress filtering and log monitoring) is that very likely you *do* have infected machines here and there. For instance we did the log check thing last week at a client site and found 1 station trying to infect the neighbors with shellshock. The difference between your logs and the ISPs logs though is that your logs will properly identify the problem workstation, and the alerts in your logs will be a lot less likely to be a false positive.
The sad thing that Ive found is that once you get a false positive note like this from an ISP, youre generally in for a few weeks of them before you can escalate to a support person who understands enough to know that theyre getting it wrong, and has the clout to fix the ISPs process.
Please, use our comment form to let us know if youve gotten a note like this, and if it was a false positive or not.
===============
Rob VandenBrink
Metafore
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Source: https://isc.sans.edu/diary.html?storyid=18785&rss