Author Archives: mike

Net_DNS2 v1.4.2 – SMIMEA and AVC Resource Records and SHA-256 SSHFP

I’ve released version 1.4.2 of the PEAR Net_DNS2 library- you can install it now through the command line PEAR installer:

pear install Net_DNS2

Or, you can also add it to your project using composer:

composer require pear/net_dns2

Version 1.4.2

  • changed the role for the README.md file to doc.
  • parse the resolv.conf options line; right now I just support the timeout and rotate options.
  • the options values only work if you set the new option use_resolv_options to true; this is to keep backwards compatibility.
  • added support for RFC 6594; support for SHA-256 and ECDSA in the SSHFP resource record.
  • added the SMIMEA resource record; this just extends the TLSA record.
  • added the AVC resource records; this just extends the TXT record.
  • added error and EDNS0 defines for DNS Cookies (RFC7873).
  • added EDNS0 defines to the lookup class.
  • dropped the Net_DNS2_Packet::formatIPv6() function; this was deprecated in v1.1.3.
  • re-wrote the Net_DNS2::expandIPv6() function. Based on testing, the new version is about twice as fast.

Blacklist Monitoring for Cloud Hosting

Originally Posted on Blacklist Monitoring with RBLTracker.

Since our inception, we’ve helped thousands of companies and individuals, from all around the world, stay on top of day-to-day threats related to their email and websites. Recently, with the addition of our Facebook Threat Exchange monitoring, we’re helping those same customers battle social media related threats.

Some of our earliest customers have been cloud hosting and cloud computing companies- companies that provide the backbone of the Internet as we know it today.

Cloud Hosting Providers

One specific challenge with this type of company, is the sheer number of IP addresses and domains to monitor, and the regular re-use of these IP addresses. The last thing you want, is a brand new customer getting an IP address that is already blacklisted because of something the last owner did.

Another key challenge, is making sure that resources are used “only as needed”. Let’s face it- you don’t want to pay to monitor hosts that aren’t being used- and you shouldn’t have to.

We offer a few key features that makes blacklist monitoring for cloud hosting providers, easier and more affordable.

IP Range Host Type

Normally customers add IP addresses and domains (aka “Hosts”) to the RBLTracker portal individually. If you have 10 to 15 Hosts, this isn’t really a big deal. You can add hosts using our bulk loader, or individually. You can also add Hosts as a range or CIDR block (x.x.x.x/y).

But what if you have thousands of Hosts to monitor? At some point it’s going to become unwieldy to provision, and impossible to manage.

To support this, we built a custom “IP Range” Host type. This lets you add IP addresses as a range or CIDR block, but rather than thousands of IP addresses showing under your account, a single Host entry is shown. Our system will still monitor every single IP address individually– but the full block of IP addresses can be managed as a single entry.

ip_range_add

So whether you have a few /24’s or a whole /18- you can easily manage the full IP block with ease.

ip_range_view

API Provisioning

Loading all your IP addresses into the system is great, but what if you only want to monitor a sub-set of those hosts? Or if you only want to enable monitoring for hosts that are currently in-use?

Several of our customers have opted to integrate with our web-based API, to provision monitoring on IP addresses as they’re allocated to their customers. That way only active IP addresses are being monitored. This ensures that you’re only paying for monitoring that matters- that will actually impact your business or your customers.

The RBLTracker API is easily integrated into any provisioning or monitoring platform, with just a few simple lines of code:

# 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"
}

Easily enable monitoring on a Host when it’s allocated to a customer, and then disable it when it’s de-allocated- it’s a simple as that.

Contact Groups

When we identify an issue with any of your Hosts, we’ll immediately notify you via several different notification methods. These contacts can be broken down into custom contact groups, and assigned to Host. The end result, is that you can have a unique contact for every host under your account:

contact_group_add_host

Cloud Hosting companies can optionally send alerts directly to their customers, notifying them about issues with their IP addresses and domains, and alleviating some of the burden from their network operations staff.

We regularly add new features and tools to make managing and provisioning monitoring services, easier and more effective for our customers.

What Is DMARC and Why Is It Important?

Originally Posted on the RBLTracker Blacklist Monitoring Blog.

dmarc_blogDMARC, or “Domain-Based Message Authentication, Reporting, and Conformance”, allows a domain owner to publish policies in DNS, telling remote mailers what to do with messages that do not align with these polices. DMARC is built on top of two existing technologies: SPF, or “Sender Policy Framework”, and DKIM, or “DomainKeys Identified Mail”.

By publishing a DMARC policy via DNS, domain owners can instruct remote mailers on what to do with messages that do not pass either a SPF or DKIM test. It also provides a mechanism for reporting under those policies. This gives remote mailers a channel for letting domain owners know that they received messages that did or did not align with those policies.

Why Is This Good?

The main goal of DMARC (and SPF and DKIM), is to detect and prevent email spoofing. For example, phishing scams that are designed to look like they’re coming from your bank or Paypal, prompting you to click on a link to reset your password or to give them your information.

Ultimately, SPF and DKIM are doing the hard work here. By designating email systems that are permitted to send email for a domain, and by cryptographically signing messages to avoid header modification en-route.

But DMARC ties the two technologies together, providing a single interface for instructing remote mailers on the domains policies, and actions to take when not met. It also opens up the possibilities of adding additional anti-spoofing or SPAM control software, which could also be handled under the DMARC umbrella.

For Example

As a domain owner of example.com, I can publish both SPF and DKIM records identifying my mail system (x.x.x.x) as the only authorized mail relay for my domain. I can then publish a DMARC record that tells remote mailers, that they should reject any messages that do not pass both a SPF and DKIM check, and that they should send reports to abuse@example.com to let me know if and when this happens.

A DMARC policy record, via a DNS TXT record, using the hostname _dmarc.example.com, would look something like this:

"v=DMARC1;p=reject;rua=mailto:abuse@example.com"

If a remote mail receives an inbound email from an email address @example.com, but not from my mail system (x.x.x.x), the SPF check should fail, and they should reject the email in accordance with my DMARC policy.

Technologies like DMARC, SPF, and DKIM are great tools in the seemingly never ending fight against email SPAM and spoofing.

For more information, see:

RBLTracker: Facebook Threat Exchange, New Website, and More!

After more than six month of design and development, we’ve launched a brand new version of the RBLTracker Blacklist Monitoring service and website. This release includes some long sought-after features, including a completely redesigned management portal, support for the Facebook Threat Exchange, and much much more.

New Management Portal

With a completely redesigned web portal, customers can easily manage all aspects of their RBLTracker account.

interface

Some key new features include:

  • Improved reporting and graphing features.
  • Additional payment options, including credit card payments, and auto-recharging account balances.
  • Easier management of accounts with large number of hosts.
  • Support for sub-accounts to split up account management roles for billing, development, and for read-only access users.
  • Support for contact groups by host, which allows custom alerting options by host.

Facebook Threat Exchange

threat_exchange_logosSupport for the new Facebook Threat Exchange service is now part of the standard RBLTracker monitoring process.

Facebook Threat Exchange is a shared network of malware and phishing attack targets, shared by a collaborative of social media and SaaS organizations, including Facebook, Pinterest, Tumblr, Dropbox, and Yahoo.

RBLTracker monitors your host IP addresses and domains, against data collected from sources like Facebook posts, Dropbox files, and Pinterest pins. If your domain or IP address was used to try and spread malware or viruses on any of the supported platforms, you’ll receive alerts from RBLTracker.

How Do RBLs Affect Me? (Part 3)

sbOriginally posted on RBLTracker

In Part 1 and Part 2 of our series, I talked about what RBLs are, how they work, and how RBLs are used by administrators to control the day-to-day onslaught of SPAM on their email systems. In this article I’m going to talk about how RBLs affect you, your business, and why you should care.

So Why Do I Care?

Getting listed on an RBL or URIBL is not uncommon- it happens.

  • Maybe you have a customer using your email platform that didn’t quite understand the rules against bulk email.
  • Maybe one of your employees downloaded some virus infested software that started sending SPAM to all the contacts in their email client.
  • Maybe your email administrator made a mistake when configuring your email system, and opened you up as an open relay.
  • Maybe the WordPress or Drupal installation on your website was compromised, and injected with phishing code.

We all do our best to ensure that these types of errors aren’t the norm, but human error happens.

As a mail recipient, RBLs protect you from these issues by rejecting these messages before they land in your inbox. As a mail sender, RBLs protect others FROM your issues- and limit your overall liability, by reducing the number of messages delivered.

By listing compromised mail servers and website domains, and using these RBLs and URIBLs in our mail systems, we effectively limit the spread of SPAM and phishing websites, which is good for everybody.

Sounds Great- What’s the Catch?

Once you’re listed- as the name indicates- you’re “black-holed”- much of your email won’t be reaching its destination, and traffic to your websites could be limited.

If your business relies on email communication- either as a tool, or a product- then the longer you’re listed, the worst it is for your bottom line, and your reputation. It looks really bad if your customers email you, and get a bounce message indicating that your email system has been blocked.

The sooner you know there is an issue, the sooner the issue can be resolved, and the sooner you can request delisting from the RBLs in question.

RBLTracker

RBLTracker provides a fully automated RBL monitoring service, which checks your IP addresses and website domains, against a customizable list of the top DNSBLs, and will alert you immediately if your system is listed.

Don’t wait days or weeks to find out that your email hasn’t been reaching your customers- click here to find out more!