An abuser and more on UDP/40810 traffic

March 19, 2010

On yesterday’s post, we mentioned an IP address that generated the most traffic. Today, the “External IP addresses – Top 50 by bandwidth use” report section indicated that the same IP was responsible for 25% of the total web traffic for March 18. For the same day, it initiated 252,128 connections. This means load both on the webserver and on the firewall. While our hardware is more than capable of handling this type of traffic, this IP address is clearly abusing our resources. Further investigation (the “Severity level 5 (Notification) details” report section) revealed through the %PIX-5-304001 type of log entries that this IP is trying to download every page from our website. We have other, proprietary mechanisms to prevent a brute force site download; however we decided to block all access for this IP address. So, on our firewall, we have added an ACL entry similar to this: 

access-list some_acl_name_here deny tcp host any

The “Warnings and notifications” section displayed a couple of “Bad TCP hdr length…” error messages, all for the external interface. Further investigation indicated that one can expect some messages like this (due to some hosts sending an incorrect TCP header) and as long as they are infrequent, there is no need to worry.

The “Denied connections” section again listed quite a few denials for UDP/40810, and again, nothing relevant found on Google. Most of the connections seem to come from US-based IP addresses. Just to see if we can get more information, we took the host that generated the most (144) of this type of connections ( or and ran an IP Forensics analysis against it. The IP Forensics report indicated that starting with 03:54:34 EST, this IP attempted to connect to one of our web servers (the same host) with both UDP/40810 and TCP/40810. The probes continued till 11:35:30 with roughly 20 connection attempts per hour. Those were the only connections to or from this IP. Just to confirm the pattern, we took the IP address with the second most connections ( – no reverse DNS but belonging to Charter Communications –, a telecom company in US). The IP Forensics report indicated a very similar pattern. The probes, 85 of them, started at 03:53:16 EST and ended at 07:10:03. No other type of traffic was recorded. Our guess is that this is some sort of program (maybe virus) installed on some PC (the user may be totally unaware) that scans a certain range of IP addresses. If anyone else sees this kind of traffic, we would appreciate a comment to confirm it.

Sample IP Forensics report:


Strange denials for UDP/48010 and UDP/48014

March 18, 2010

We continue to see quite a few TCP/135 (MS RPC) probes from China-based computers. Each IP address is recorded with just one probe on that port so most probably, these are PCs infected with various viruses, no determined hackers behind them. This is to be expected, however it is good to see that there are fewer and fewer US-based probes.

The bulk of the traffic is of course, HTTP, with approx. 7 GB. The top IP address generating web traffic is While there is no reverse host name configured for this IP, the organization is listed as Atrion Networking ( This IP alone, downloaded close to 600 MB of data and for a webserver with no big files to download, this is a very large amount of data. Atrion seems to be a telecom company so it is possible that this is a proxy server, actively downloading content from visited sites.

The typical Google, Yahoo, MS and bots are coming next and again, this is to be expected. For a public webserver this is good – it means that your website is getting indexed in all these search engines, increasing the visitors to the site. Even if they put a certain load on the server, one should not block them!

The traffic vs. denial graph, allows a quick check on any anomalies (i.e. unusual spikes in denials may indicate a concentrated attack against the server). So, a green “mountain” with a matching low profile, denials curve is just what you want to see.

 There are quite a few denied connections for UDP/48010 and UDP/48014 (and some TCP/48014 connection attempts). Searching Google and the SANS Internet Storm Center, did not reveal any useful information which is a bit strange. Could this be something specific to our server? For example, a whois query from our application may cause a reply on UDP/48010 from the targeted IP and all the UDP traffic is rejected by our firewall (and the denials would end up recorded in the logs). We will have to replicate a query to one of those IPs and monitor the traffic going back and forth outside the firewall between our server and that IP address. One can use Ethereal (a free network protocol analyzer) to perform this task. The past reports do not contain this type of denials so it could simply be a new vulnerability that we have to keep an eye on. Fortunately, our server has all the recommended patches and hotfixes.

For a sample FireGen for Pix Log Analyzer report go to

Easter log analysis

April 14, 2009

Here is a look at the logs for typical “holiday” day on a busy webserver. Here are the sections of the report created by FireGen:

1. Web traffic (HTTP/HTTPS) – Internal users (outbound connections) and Web traffic (HTTP/HTTPS) – visited sites

This is a webserver and normally there should be no users browsing the Internet from it and no websites visited. However, the report contained at least 30 connections, mostly towards IP addresses belonging to Microsoft. The IPs did not have a host name associated but the FireGen builtin Whois query identified them as being Microsoft IPs. So what happened? Well, in turned out that an administrator logged in remotely that day. Even though he did not make any updates or opened any websites, the Automatic Update option connected to Microsoft and looked for new hotfixes/updates for that version of Windows. All done in the background – if the automatic search/download of updates is a problem, it can be disabled.

2. Web traffic (HTTP/HTTPS) – incoming connections

This being a popular website, one can expect heavy traffic even during a holiday like Easter. A lack of traffic would indicate a problem. What should worry would be a large number of connections from the same IP. In this particular case, we could see many connections from various web crawlers (Yahoo, Google, Cuill, MSN) and this can be expected. One can control these web robots by configuring the proper robots files on the websites themselves (telling the robots what to search and what NOT to search). Given the emphasis on generating web traffic usually one would want to encourage this type of indexing. The number of connections would depend on the popularity of the website.

We found one IP, ( belonging to an ISP in France with a large number of connections. Usually this could indicate an abuse but IP itself, ending in .2 does not look like the typical IP assigned to an end user but, a network device. It is very possible that this is a proxy server trying to perform some proactive caching.

3. Email (SMTP) – Top 50 outbound connections

This webserver sends a certain number of emails on regular basis so seeing some traffic there is no surprise. Only a sudden increase in this type of traffic may indicate that somehow this server is used to relay spam but was not the case here.

4. Email (SMTP) – Top 50 inbound connections

This server is not accepting incoming SMTP traffic so there should be no connection here. However, two were listed in the report. The first one was from a server in Holland but it looked like an accidental connection (most probably our server sent an email to a recipient on that computer) and the second one from a server in Taiwan (an ISP). The IP was not dynamically assigned so chances are that again it was accidental. The question is why this SMTP traffic made past our firewall, so one question was sent to the firewall administrator to look into this.

5. Email clients (POP3/IMAP)

There were no entries under this section (a good thing!)

6. Custom protocol 1 – MS RPC (TCP/135)

We monitor this as the Microsoft RPC is a popular target for worms and other malware. It gives as an indication on how “hot” things are outside the firewall. Most of the connections listed under this section came from China. Were they just bots scanning the Internet for vulnerable hosts or attacks targeting directly our website? For most of them there was just one connection attempt so chances are it was just a scan. There were also several connections from US, probably just infected PCs.

7. Custom protocol 2 – NetBIOS (UDP/137)

Similar with MS RPC, NetBIOS is something one should keep his eyes on. Several connections were listed FROM our webserver against various IP addresses. We know actually that these were part of the FireGen attempt to reverse resolve the host name for various IP addresses. If there Whois does not return a host name, the reverse DNS module will attempt a NetBIOS query against that IP (sometimes the remote host responds with its name).

8. Custom protocol 3 – Whois (TCP/43)

This section shows the queries made by Firegen. Very few administrators would need this.

9. Other protocols

This is an interesting section as it shows all the other protocols that were not specifically entered in the Monitor Protocols FireGen configuration. We could see the following:

TCP/8010 – This is used by our Whois engine to determine the geographical location of various IP addresses

UDP ports higher than 1024 – Microsoft DNS sometimes uses these type of ports

UDP/123 – Network Time Protocol – used by the webserver to synchronize its clock

UDP/500 – Several probes from outside hosts, probably looking for VPN devices

So nothing really unusual in this section (and that is good).

10. Protocols – Top 50

This is the summary of protocols identified by FireGen. TCP/80 – http counted for 98.13%, as expected. In a normal day this would be even higher.

11. Internal IP addresses

This indicates the traffic generated from internal IP addresses. One should make sure that only the authorized IPs are listed there and that was the case in this report.

12. External IP addresses

This shows the traffic generated by external IPs. As expected, the web crawlers from Google, Yahoo and MSN are the top generators of traffic. Unless the bandwidth is limited, this is a good thing as the website gets published in the search engines. One should be worried if there is no traffic from such crawlers.

13. Total traffic by hour

This should indicate a smooth distribution of traffic, no sudden spikes.

14. Traffic and denials by hour

This graph can be used to see if there was a disproportionate number of denials compared with the regular traffic. They should be proportionate as the more traffic one gets, the more denials will be recorded. There will always be denials, some due to accidents, some due to attempts from bots and hackers.

15. Denied connections / Denied protocols / Denied IPs

This can be used to see the most persistent offenders. However, some connections are being denied due to the unreliable nature of Internet. if a legit but stray packet reaches the firewall too late, it will be denied – this type of denials are listed with “No service” as reason for denial.



TCP/135 (Microsoft RPC) traffic

September 29, 2008

One of the protocols monitored in FireGen ( 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…

September 12, 2008

One previous post was looking at the activity recorded by IP in our firewall logs. Since then we added this IP to the “Monitored IP addresses” section so now each entry containing 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 … 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

September 4, 2008

The traffic for our popular website that we analyze with FireGen contains quite a few connections from IP 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 ( 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 ( 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 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 to flags SYN on interface outside

Most probably, this IP (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 %).