The GPF DNS Block List

Frequently Asked Questions

What is the GPF DNS Block List?

The GPF DNS Block List is a database of IP addresses that have been caught directly attacking one of the servers owned and operated by the owner of GPF Comics, Jeffrey T. Darlington. Like other block lists, it provides a means of sharing data on known malicious hosts to other webmasters and network administrators who wish to protect their systems from compromise and attack.

Why was this block list created?

It was created primarily out of frustration. Jeff got sick and tired of seeing his logs fill up with hack attempts, code injection attacks, and vulnerability probes, so he started banning IPs caught in the act. This was largely a manual process for a long time, where Jeff added each individual IP to his iptables configuration. After a while, this became cumbersome and he thought automating the process would be smart idea. At the same time, he also thought this data would be useful to other webmasters and network administrators, so he started to combine both tasks into a single database where he could add data, export lists in various useful formats, and publish it for others to potentially use.

Who determines what IPs go into the list and why?

Every IP added to this database has been caught actively attempting to probe, scan, or compromise one of our servers. We've seen suspicious activity in our log reports or we've been notified by our spam filters that a spamming attempt has been blocked. We then investigate each IP using a number of online resources to see what its reputation might be. After the IP has been thoroughly researched, we decide whether or not it should be considered a threat. IPs that are determined to be malicious are then added to the database and banned from further accessing our servers.

As for who makes this determination, that's largely Jeff's call. He does his best not to be arbitrary in his decision and he only adds an IP if he has sufficient evidence to prove or, barring this, strongly believes that a malicious attack occurred.

What are the reasons an IP may be listed?

For a detailed list of every reason category, see the Reason Key page. For a quick summary, however, we usually only ban an IP if has been caught spamming or attempting to spam our forum or blogs, actively attempted to compromise one of our servers, probed our sites for vulnerabilities to exploit, automatically scraped content, acted as a malicious or poorly constructed bot or spider that did not observe our access rules, or otherwise generated traffic so outside the norm for typical human users that it seems highly suspicious.

Why did you pick these specific reasons?

Firstly, the reason list should be considered somewhat dynamic. It's not entirely set in stone yet, so we may be adding reasons and expanding explanations over time. It's unlikely that we'll remove a reason, but we may break off a new, more specific reason from a more generic one if we encounter lots of attacks of that specific type.

That said, the reasons chosen, with the exception of the catch-all "unclassified", were ones we saw specific examples of. We saw lots of forum spammers attempting to create forum accounts, so we created a forum spammer classification. We saw bots attempting to inject code into one of our server-side scripts, so we created a code injection classification. As we see more diverse attacks come in over time, we will likely add more reasons to cover them.

Why are so many IPs listed as "unclassified"?

If you see any IP listed as "unclassified", this IP was added during Jeff's original manual process. While he made comments for every batch of IPs added, he usually lumped most of those together as a single group and put a single comment describing them all at the top. Thus, there may have been several IPs in a given batch that were added for a variety of reasons, but since the comment didn't specify which IP was added for which reason, it's now impossible to go back and say with any certainty why the IP was added. While we're trying to go back and reclassify old IPs when we can, the vast majority fit in this catch-all category. You can, however, rest assured that every IP in the database was added because it attacked one of our servers and for no other reason. While we may not be able to say with 100% accuracy why it was added, we can say without question that it belongs in the list.

Can I submit IPs to be included in the database?

Sorry, but no. We have no plan or desire to accept user submissions. We want to keep this list exactly the way it was originally created: to list IPs that actively attacked our servers. Accepting user submissions opens the list up to potential abuse. The only way to get an IP added is to make sure it launches an attack against us. ;)

Can I use your this list to protect my own sites?

Certainly. You can export our database in a number of formats, which can then be used wherever you wish. Ultimately we plan to launch the DNS query system (thus the DNS in the name) where you can use DNS queries to dynamically test whether or not an IP is in our system.

My IP is listed. How can I get it removed?

Short answer: You can't. If you didn't want your IP listed, you shouldn't have used it to attack our servers.

Long answer: There is always the possibility, however slim, that an IP may be used to attack us without the owner of the machine using it being aware of it. You may have been innocently assigned IP by your ISP which was used by another customer of the same ISP to attack us. Your system may be infected with malware or viruses that may spam or launch attacks without your knowledge. While these situations are unfortunate, there's not a lot we can do to help you. It is your responsibility to keep your operating system, software applications, and anti-virus/anti-malware protection up-to-date and malware free. If your ISP willingly allows spammers and malicious users or turns a blind or apathetic eye toward such activities, you way wish to search for a more reputable service. Sometimes, the simplest solution of all might be to log off and shut down your computer, unplug it from the network for a while, and plug back in and reboot. You should be assigned a new IP which may not be in the list.

If you truly believe your IP was added to our list erroneously, you are certainly free to contact us and plead your case. However, be prepared to be on the defensive and to provide hard evidence that you are not responsible for the attacks logged against us. We have server logs proving each attack; you should be ready to provide documentation to disprove it. We're not unreasonable, and we're certainly willing to discuss the issue with level-headed hosts and users that are willing to compromise. That said, hate mail, threats, and similar deconstructive comments won't get you anywhere and will likely get you banned elsewhere.

What gives you the right to determine who can and cannot access your servers?

The various sites in the GPF Comics family are provided as services to the Internet at large, in many cases for free. We do this under the good faith that our users will be respectful and courteous to us and to their fellow users and will generally follow the principles of good "netizenship". When someone violates this trust through careless or even malicious misuse of our resources, we take such acts as a breach of that faith. Users who cannot respect the freedoms of other users or who willingly seek to breach our customers' faith in us have no place here and are not welcome.

Most of the entries look like IPv4 addresses. Are you planning to list and block IPv6 addresses as well?

We do indeed list and block IPv6 addresses that actively attack our servers. That said, the overwhelming majority of IPs in use today are still IPv4 addresses, which explains why they dominate the list. As more attacks come in from the IPv6 address space, the number of IPv6 addresses that we ban will likely increase.

That said, blocking individual IPv6 addresses is, in many ways, a losing battle. The IPv6 address space is so large that individual users are often assigned entire blocks of addresses larger than the entire IPv4 address space itself. It is therefore trivial to switch IPv6 addresses within such a space, or to even acquire entirely new IPv6 blocks and thus avoid a simple ban. In the long term, banning individual IPv6 addresses will no longer be an effective means of stopping malicious attacks. As such, the Internet security community (ourselves included) will need to adapt and find new ways to protect ourselves and others. Until these new strategies are put in place, however, the current method of banning individual addresses will likely remain in place.

Since many users and Web hosts continue be IPv4 only, our export files are split into IPv4-only and IPv6-only lists. This is also a natural split as well since many firewalls like iptables use separate configuration files for each protocol stack. Our IPv6 exports do not currently list included IPv4-mapped versions of the IPv4 address list, but that is one feature we are considering adding.

Why are IPv6 addresses in the DNS block list returned with the funky address fdb4:6272:183f:95f2::*?

IPv6 doesn't have the same concept of "private networks" that IPv4 does. For IPv4 look-ups, we use the private address range, which is well known as private and non-route-able. For IPv6, things are a little different. IPv6 has the concept of "unique local addresses", which have a prefix of fc00::/7. This address space includes a 40-bit pseudo-random number that minimizes the risk of address collisions if sites merge or packets are misrouted. We simply accessed this handy private IPv6 address range calculator and randomly received the range fdb4:6272:183f:95f2::/64. Since IPs in the range fc00::/7 are consider non-route-able, any old sub-range would do, but this one seemed good enough.

Like the IPv4 block list addresses, the last set of digits is the reason code that explains why the IP was blocked. This code is technically in decimal, so there's no conversion to or from hexadecimal necessary. For example, if you look up an IP and receive back the result fdb4:6272:183f:95f2::7, take the last set of digits after the last colon (7) and look that up on the reason key. This tells you the IP was banned as a forum or comment spammer.

What is all this junk in some of the comments that looks like garbage? It contains IPs, URL bits, text like "Mozilla", "Windows", "Firefox", "Safari"...

We like to try and include evidence for each attack whenever possible, and the best place to put that data is in the free-form comments area. This "garbage" is often excerpts from our log files, which includes the IP, the date of the event, the actual suspicious request, HTTP response codes, referral information, and the user agent of the requester. Most of this data is beyond the scope of this FAQ, but you can learn more about it with some crafty Google searches. While we often included explanatory text with these log entries, sometimes the logs speak for themselves. For example, a request that includes the full path to a file on another site as one of the input parameters is likely trying to inject code into one of our scripts.

Why do some of these log comments include IP addresses other than the IP I'm currently looking at?

While we try to be as specific as possible and treat each attacking IP separately, sometimes we will add attacker IPs in batches, especially if we see many identical attacks coming from multiple IPs at once. For example, we may notice a suspicious series of identical 404 errors ("Not Found") and do a search on our logs for the requested file. This may return more than one IP making similar requests. When this is the case, we sometimes add them all in a batch at the same time so the same explanatory comment gets attached to each IP. As stated above, we also like to include evidence in the comments, so we'll add at least one log record per IP as proof of the attack.

I notice a lot of "404", "301", and "403" HTTP response codes in these log entires. What's up with that?

HTTP response code 404 is "Not Found". This is probably the most common error message you'll encounter on the Web and means the URL you requested does not exist and has not been be redirected anywhere else. The most common reason you'll see 404 errors in the GPF DNSBL is from attackers randomly probing for vulnerable scripts to exploit. They don't bother doing any form of research to see whether or not a vulnerable module is actually installed on the given server. Instead, it's much faster for them to try likely known locations where a vulnerable file might be, sometimes trying several variations in the process. If they get a 404 error, they move on to the next possible target. If they get anything else, it's possible the vulnerable module is installed on the server and they can try additional tests to find an exploit. We see lots of probes for vulnerable software that we don't have installed on our servers, resulting in many 404 errors. Even though the attacker found nothing to exploit, we block their IP anyway because we know they've already exhibited malicious behavior and therefore they might try looking for something else that we do have installed.

HTTP response code 301 is "Moved Permanently". Over the years, the GPF site has had a lot of different canonical URLs for a lot of different pages, and many people have linked to those pages from their own sites. Of course, we've moved several times since some of those links were made, so we try to be nice and redirect these old links (at least the ones that we can remember) to keep them from breaking. Therefore, the GPF site generates a lot of 301 responses, informing the client to look for another, newer URL. Sometimes attackers hit these redirects when they randomly trawl for vulnerable scripts to exploit. When we include evidence of an attack (see above), we want to include the original attacking URL, which sometimes ends up being redirected with a 301 before being blocked elsewhere.

403 responses ("Forbidden") are generated by the user agent requesting a resource that they are not permitted to access. Most of the time, this comes from attackers trying to access our admin interfaces. On several of our sites, we use a combination of protection and authentication methods to protect these interfaces, including forcing HTTPS encryption, filtering to known safe IP addresses, and even client certificate authentication. Depending on which and how these schemes are layered, attacks against these resources produce different results. Some are harmlessly bounced to a "safe" publicly accessible URL, while others receive the dreaded 403 Forbidden response. Obviously, we take attacks against our admin interfaces very seriously, and blocking the offending IP is the most efficient solution.

Another possibility for a 403 may come from content scrapers attempting to access files they have been forbidden to access. For example, we may ban the user agent of a known popular scraping tool, resulting in a prolific user of that tool generating tons of 403s while attempting to harvest our content. Although the user agent has already been banned, we may then ban the IP itself since the user is particularly persistent in breaking our rules.

Why are some IPs listed as "whitelisted"? Can these IPs be trusted?

Sometimes known good and trusted IPs may exhibit behavior that might otherwise appear suspicious. For example, Google's spiders occasionally crawl through our sites, probing in the same areas that spammers like to go, such as the GPF Forum and Wiki. To prevent ourselves from accidentally blocking the IPs of known good clients, we whitelist them to prevent them from getting into the database. If we try to insert one of these IPs, an error gets thrown and it won't get through.

In the spirit of full disclosure, if you query for one of these IPs here, you'll see that the IP is whitelisted in the query result. There will be a "reason" attached to that entry, usually identifying who owns that IP. As for whether or not you should trust that IP, that's up to you. We have elected to trust these IPs for various reasons (we own the IP, it belongs to a known business partner (search engine, advertising supplier), etc.), but that doesn't mean you have to. As with any of our results, we can only tell you why we do or do not trust a given IP. It's up to you to decide whether our trust in a client applies to you as well.

Do records in the GPF DNSBL ever expire? Or is the ban permanent?

Originally our records did not expire. However, as our ban list continued to grow at a steady pace, it became readily apparent that performance issues could quickly become a problem. To mitigate this we introduced a "last seen" attribute to each record and now expire records after one year (365.25 days). Thus, once an IP becomes banned it will remain banned for one year, after which the ban will be lifted. That said, if an IP with an expired record attacks one of our servers again, we will not hesitate to update its record and ban it once again.

All of our export lists include only active records. However, all records, both active and expired, can be queried through the site.

Home | Bulk Query | FAQ | Worst Networks | Reason Key | Reason Rankings | Export

This site and its contents are © Copyright 2011-2020, Jeffrey T. Darlington. All rights reserved. It is provided as a service to the Internet community at large and is for informational purposes only. This site and its owner cannot be held responsible for any actions taken by others based on the data contained herein.