Tag Archives: rbltracker

What are Blacklists and How Do They Work? (Part 1)

Originally Posted on RBLTracker Blacklist Check Service

Real-Time Blacklists (RBL) are a simple but effective way for organizations around the world, to share the location (in this case, the IP addresses) of email systems that are reputed to send email SPAM.

The most common implementation of these lists are distributed via DNS, and referred to as DNS-based Blacklists (DNSBL). Distributing this data via DNS makes perfect sense; it’s a technology that already exists, and servers all already have access to. It’s fast, and the data (IP addresses and domains) is well suited for DNS.

Types of RBLs

There are hundreds of RBLs available worldwide, managed by hundreds of organizations and individuals. Most RBLs are free to use, some are pay-to-use, and they all have their own methodologies for compiling their databases, and their own processes for being delisted.

Two of the most common and reliable methodologies for collecting data for RBLs, are based on user input, or something they call a “honey pot”.

Crowd Sourced

RBLs based on user input are the most common, and often most reliable. This data is effectively crowd sourced. When an email recipient receives a SPAM message (assuming their system supports it), they can “flag this message as SPAM”. If enough recipients flag the same message as SPAM, the IP address of the sender will be added to the RBL database.

This is common in free email services like Hotmail and Gmail.

Honey Pots

Another common source for RBL data is something called a honey pot. These are basically email addresses that are never used for any legitimate email purposes, and aren’t owned by any end users. They simply exist out on the Internet in places where robots and SPAM aggregators collect email addresses.

Any email that comes to these addresses is by definition unsolicited, and considered SPAM, and will land you on an RBL.

URIBLs

Another type of RBL is the URI Blacklist (URIBL). This is used for distributing domain names of websites that are reputed to send SPAM or to be involved in phishing schemes. So this doesn’t just affect organizations that run their own mail servers, but anyone that has a website as well.

There are definitely RBLs that are more reputable than others; there are some that have no process for being delisted, and others where you have to pay to be delisted. In my opinion, the pay-to-delist RBLs should not be considered reputable, and should not be used by mail system administrators.

Stay tuned for Part 2 of this series, where I’ll talk about how these RBLs are used by organizations, and give you some real-world examples of how RBLs can help you combat SPAM.

RBLTracker.com: Now with DNSSEC and TLSA

The RBLTracker domain is now signed with DNSSEC, and we’ve published the website certificate fingerprint via a TLSA record (also known as DANE), so that you can be 100% sure you’re interacting with the RBLTracker servers. dnssec

This can be validated through the Verisign Labs Test Tool.

What is DNSSEC, and why do I care?

The point of DNSSEC is to provide a way for DNS records to be trusted by whoever receives them. The key innovation of DNSSEC is the use of public key cryptography to ensure that DNS records are authentic.

DNSSEC not only allows a DNS server to prove the authenticity of the records it returns. It also allows the assertion of “non-existence of records”.

What about DANE, what’s that all about?

DANE, or “DNS-based Authentication of Named Entities”, is a way for domain and website owners to publish SSL certificate fingerprints, so that visitors can validate that the certificate being used on a website is valid for that site.

Over the last few years, there have been several security breaches with Certificate Signing Authorities (CA’s)- companies that sign certificates that you use for your secure website- allowing the issuance of certificates for domains, not owned by the domain owners.

Using DANE, you can define exactly which certificate or CA is valid for your website, restricting the ability for a would-be hacker to masquerade as your website, by gaining access to your CA.

This obviously only makes sense in tandem with DNSSEC, as you need to validate that the DNS information providing the certificate fingerprint is valid, and not modified along the way.

How can I tell if a site is using DNSSEC/DANE?

Until there is more mainstream support for DNSSEC/DANE- for example, building support for it directly in the OS layer and in web browsers- there is a great browser plugin by cz.nic, that will show you when a site is protected with DNSSEC and DANE.

PagerDuty Support and Expanded API Functionality

In today’s ever-connected world, integrations are key to realizing the full value of any product. At RBLTracker, we know that organizations have established support, alerting, escalation, and provisioning procedures already in place, and we want to work directly with these processes- not against them.

The newest release of RBLTracker includes two new features, which make integrating RBLTracker into your existing processes, that much easier:

PagerDuty Support

pagerduty_logo_greenPagerDuty provides alerting, on-call scheduling, escalation policies, and incident tracking to increase up time of your apps, servers, websites, and databases.

Customers using the PagerDuty service can now integrate RBLTracker directly into their existing escalation process, by following this simple integration guide.

PagerDuty support is available to all paid RBLTracker accounts. Sign up Today!

Expanded API Functionality

Previous releases of the RBLTracker service provided a limited, read-only API, which let customers integrate RBLTracker into their existing monitoring systems. Today’s release expands that functionality, to allow both read and write functionality, giving customers the ability to manage both Hosts and Contacts, through a simple web-based API.

This functionality allows customers to integrate RBLTracker into existing provisioning processes, to ensure that all hosts that should be monitored- are.

When a new IP address is allocated to a customer in your system, make a simple API call to RBLTracker to enable monitoring:

# wget --post-data="type=rbl&name=Test&host=10.10.10.10" -qO- https://rbltrack.com/api/host/add.json?api_token=x

{
    "status_code": 200,
    "status_message": "Hosts added successfully.",
    "data": [
        {
            "id": "37c46a725dd8adab28d35b9f200c198d",
            "host": "10.10.10.10",
            "name": "Test"
        }
    ],
    "version": "2.0"
}

When an IP address is reclaimed, remove it from our system:

# wget --post-data="id=37c46a725dd8adab28d35b9f200c198d" -qO- https://rbltrack.com/api/host/delete.json?api_token=x

{
    "status_code": 200,
    "status_message": "Host deleted successfully.",
    "version": "2.0"
}

It’s that simple. Only pay for hosts that need to be monitored, and nothing more.

Write functionality is automatically enabled for all customers that currently have access to the RBLTracker API service.

RBLTracker: Pushover Notifications and Temporary Manual Hosts

The RBLTracker service was upgraded to v1.13 today, which includes the following new features:

Pushover Notifications

Pushover makes it easy to get real-time notifications on your Android device, iPhone, iPad, and Desktop. Once you have your Pushover client installed, simply copy and paste your user key into the contacts section of the RBLTracker portal.

pushover

Many companies are already using Pushover for system event notifications; this lets you consolidate all your notifications in one simple application.

Temporary Manual Hosts

Customers on the Ultimate package can now add temporary hosts from the Manual Check section of the web portal.

manual_host

 

These temporary hosts will persist for the life of your session, and will disappear as soon as you log out. This feature is handy for customers that would like to do a quick check on a host not currently listed in your host list.

RBLTracker: Custom Check Frequency, API Changes, and Twitter Support

The RBLTracker service was upgraded to version 1.12 today, which includes the following new features:

Custom Check Frequency

Customers subscribed to the Ultimate package can now adjust the frequency of their host checks, using a simple drop-down list from the Profile -> Settings section:

custom_frequency

 

At the moment, customers can select from a 6 hour window, to a 48 hour window. Finer grained controls will likely be added in future releases.

API Updates

We’ve made some very basic changes to the API service:

  • Replaced all instances of the term “blocked” with “listed”. The “blocked” terminology is still available, but customers should migrate to the new terminology as soon as possible, as it will be deprecated in future releases.
  • The matched RBLs have been added to the response data. This includes the RBL matched, the RBL website, and the RBL output from DNS.
  • The API version number is now included in the response object.

An updated API document is available from the API Access section of the RBLTracker portal.

Twitter Notifications

Customers can now add their Twitter screen name to their account as notification contacts. RBLTracker will send a direct message to your Twitter account anytime a host matches (or based on your scheduling settings:

notify_twitter

 

Customers must follow the @rbltracker Twitter account with the same Twitter handle in order to received direct messages. We also cannot send URLs in direct messages, due to limitations on the Twitter platform- hopefully this is something they will correct in the future.

If you have any questions or comments about any of these new features, please let us know @ info@rbltracker.com