(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
IBM FileNet Content Manager and Content Foundation Unspecified Cross Site Scripting Vulnerability
Debian 'apt' Package CVE-2014-7206 Insecure Temporary File Creation Vulnerability
IBM WebSphere Application Server CVE-2014-4770 Cross Site Scripting Vulnerability
IBM WebSphere Application Server CVE-2014-4816 Cross Site Request Forgery Vulnerability
BMC Track-It! CVE-2014-4874 Arbitrary File Download Vulnerabilitiy
BMC Track-It! '/TrackItWeb/Grid/GetData' SQL Injection Vulnerability

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.

Please include your original email to SOMEISP.com in any replies.

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 [email protected] 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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
RSyslog and sysklogd CVE-2014-3683 Incomplete Fix Denial of Service Vulnerability
HP Systems Insight Manager CVE-2014-2644 Unspecified Cross Site Scripting Vulnerability
LinuxSecurity.com: Security Report Summary
LinuxSecurity.com: Updated kernel packages that fix one security issue and several bugs are now available for Red Hat Enterprise Linux 6.4 Extended Update Support. Red Hat Product Security has rated this update as having Important security [More...]
[security bulletin] HPSBGN03108 rev.1 - HP Records Manager, Remote Cross-Site Scripting (XSS)
Multiple vulnerabilities in DrayTek VigorACS SI
[CERT VU#121036 / Multiple CVEs] RCE, domain admin creds leakage and more in BMC Track-It!
[security bulletin] HPSBMU03118 rev.2 - HP Systems Insight Manager (SIM) on Linux and Windows, Multiple Remote Vulnerabilities
Multiple Products 'parse_notify' Function Heap Based Buffer Overflow Vulnerabilities
Google Chrome Prior to 38.0.2125.101 Multiple Security Vulnerabilities
Schneider Electric ClearSCADA CVE-2014-5413 Weak Hashing Algorithm Remote Security Weakness
Schneider Electric ClearSCADA CVE-2014-5412 Remote Security Bypass Vulnerability
Siemens SIMATIC WinCC and PCS7 CVE-2014-4686 Privilege Escalation Vulnerability
Internet Storm Center Infocon Status