Archive for September, 2008

TCP/135 (Microsoft RPC) traffic

September 29, 2008

One of the protocols monitored in FireGen (www.firegen.com) is TCP/135 used by Microsoft RCP (Remote Procedure Call). The reason for this is the fact that RPC had a few vulnerabilities exploited in large scale attacks against systems running Microsoft Windows. Every day we can see attempts to connect to this port, all of them from IP addresses coming from China (121.14.212.x, 122.224.5.x, etc…). The question is, are these just infected computers randomly checking remote hosts for “holes” or are they directed by people? One can add these IPs to the “Monitored IPs” list in FireGen and see if they keep showing up.

Bad TCP hdr length

September 12, 2008

In almost every report we can find 2-3 messages in the “Warnings and notifications” section of the FireGen report about “Bad TCP hdr length” from an external IP address against the firewall interface (Pix code 5-500003). This means that the length of the TCP header sent by the host mentioned in the message is not valid. For example, the remote host may indicate that the TCP header is larger than the entire TCP packet and obviously that is not possible. According to Cisco this may happen from time to time but it should be infrequent. Two or three messages out of a few million qualifies as infrequent!

More from 194.59.120.11…

September 12, 2008

One previous post was looking at the activity recorded by IP 194.59.120.11 in our firewall logs. Since then we added this IP to the “Monitored IP addresses” section so now each entry containing 194.59.120.11 is tagged in the report with a different color and a comment (we tagged it as Deutsches Patentamt – keeps connecting… – a very clear indication of what it does). So we noticed now that it connects on TCP/8088, a port commonly used by http proxies and TCP/3080. No idea what the TCP/3080 protocol can be used for, there are no “known” applications to rely on it. The similarity to TCP/8088 may be indicate that someone keeps mispelling either the IP address of their real http proxy or (seeing that it doesn’t work) they tried to change the actual port configured for it (3080 instead of 8088). It is not unusual to see different applications installing their own webserver service as a way to provide a management interface. Can this be the case here? Or, there could be an application that queries remote agents using that port and they are trying to “discover” the wrong subnet (where our firewall resides). Strange enough, the previous day indicates just regular TCP/80 HTTP requests, one every 60 seconds. Since we don’t deny TCP/80 the IP is shown in the regular “HTTP Traffic from external hosts” report section. Maybe the administrators of that device are starting to see that something is wrong with it šŸ™‚

Denied protocols

September 10, 2008

It is good to keep an eye on what protocols are currently denied by the firewall. New protocols may indicate a new vulnerability and you may want to be aware about it even though the protocol was denied. Put it this way, the firewall might try to make you aware of this new attack. So, let’s look at our report, the Denials section:

UDP/67 – This is just some DHCP broadcast received on the external interface. Normally you shouldn’t see this, what is a device doing sending DHCP requests on the public segment? If your ISP is ok, they should look into this.

UDP/2001 – This is a broadcast against 255.255.255.255 … not too much information about this (actually none). We will keep researching.

ICMP/8 – A regular ping. I guess one can expect a certain number of pings.

TCP/113 – Ident, used by several mail servers for an optional authentication. In our case it came from a known mail server so it’s ok.

ICMP/3 – Unreach – just shows that a host tried to use a certain protocol that is not serviced by the firewall so an “unreachable” message was returned. May indicate probes against the published IPs.

UDP/137 – A denied broadcast from an internal host. We know about this one, it’s ok.

TCP/25 – SMTP – we have blocked a list of nasty spam servers from even trying to contact our computers.

UDP/33435 and UDP/33436Ā – TheseĀ are used by traceroute. As with ping one can expect some traceroute traffic.

UDP/49153 – Not much about this one either. Maybe used by a game server? Conections came from 2 different servers so it must be something used on several computers, not just a custom app.

TCP/8080 – Commonly used by proxy servers. We see this computer trying this protocol every 5 seconds, most probably a misconfigured one.

UDP/1434 – UsedĀ for MSĀ SQL management, a broadcast indicates some computer looking for SQL servers.

That’s about it. We will keep an eye on those UDP ports.

What’s with IP 194.59.120.11?

September 4, 2008

The traffic for our popular website that we analyze with FireGen contains quite a few connections from IP 194.59.120.11. While this doesn’t resolve to a domain name, it appears that it belongs to Deutsches Patentamt or The German Patent and Trade Mark OfficeĀ (www.dpma.de). From the application-specific logs we can tell that is not actually using the site but it is up there, at the same level of traffic with various search engine crawlers (Yahoo, Google, etc…). To keep an eye on it, we added the IP in the “Monitored IP Addresses” list in FireGen so the next reports will tag any connections from this IP. In the mean time, we used the IP Forensics feature in FireGen (http://www.eventid.net/firegen/ipforensics_report.asp) to see what kind of traffic is generated by this IP. It turned out that every 5 seconds it makes and HTML request for the default page of www.eventid.netĀ and nothing else, as if it would monitor the availability of this website. We will keep an eye on it and if necessary block it at the firewall level.

%PIX-2-106001 Denied inbound

September 3, 2008

One of the most common critical messages appears to be the %PIX-2-106001 one, and it is recorded when an external IP is attempting to connect to a port that is not configured for inbound traffic. A network probe will often be detected this way. For example:

Inbound TCP connection denied from 219.84.2.38/nnnn to 208.76.111.142/25 flags SYN on interface outside

Most probably, this IP 219.84.2.38 (a dynamically assigned IP in Taiwan) probed for an open SMTP relay. This message will be listed in both FireGenĀ “Detailed messages” section and the “Denials” one. The Denials will also have the result of the reverse DNS resolution. There is little one can do these days to block this kind of probes. Unless there’s quite a large number of such probes they can be ignored. If anything, they are a constant reminder that obscurity is not a good security policy as people (or scripts!) will keep looking for you and your vulnerable spots. Keep an eye on the ports used in these probes, may indicate a new vulnerability.

%PIX-4-419001 – MSS exceeded

September 3, 2008

We haveĀ noticed in our daily log a few warning messages stating that the MSS was exceeded (and the packet dropped). The MSS (Maximum Segment Size) is basically the largest amount of data that the device can handle in just one piece (without being broken in several pieces and transmitted individually). By default this is the expected behaviour within a Cisco Pix firewall. In our case, the defined MSS is 1380 bytes but the incoming packet was 1444. Depending on the firmware version the firewall can be configured to accept packets with a larger MSS. We will probably configure this firewall to do this. Compared to the total number of messages there are very few “MSS exceeded” ones, practically they can be ignored (approx. 0.005 %).