Difference between revisions of "Atomicrbl"

From Atomicorp Wiki
Jump to: navigation, search
m (Download the zones)
m (Frequently Asked Questions)
 
(21 intermediate revisions by one user not shown)
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
  
The Atomicorp RBLs are part of the Atomicorp Threat Intelligence system.  It provides information about potential sources of malicious activity that can be used to detect potential malicious activity from a source using DNS RBLs.
+
The Atomicorp RBLs are part of the Atomicorp Threat Intelligence system, in machine-readable security content.  It provides information about potential sources of malicious activity that can be used to detect potential malicious activity from a source using DNS RBLs.
 +
 
 +
Collecting data for the purposes of having data does no good and can actually detract from a security intelligence program by using up time and man power to analyze data that is most often noise rather than real indicators of threat.  Our system is designed to be instantly actionable, and does not require additional analysis.
  
 
== Enabling ==
 
== Enabling ==
Line 22: Line 24:
  
 
''2.0.0.127.test.atomicrbl.com''
 
''2.0.0.127.test.atomicrbl.com''
 +
 +
See this article for setting up a local DNS server to perform faster resolution if you are not going to be running a local copy of the RBL zones:
 +
 +
[[Local DNS resolver]]
  
 
=== Web ===
 
=== Web ===
Line 118: Line 124:
 
Zone file: threat3.rbl
 
Zone file: threat3.rbl
  
This zone contains sources that have been detected carrying out brute force attacks (e.g. password guessing).  This zone is used in [[ASL]], and sources on this RBL will have their traffic shunned by default.   
+
This zone contains sources that have been detected carrying out brute force attacks (e.g. password guessing) of services such as web applications, SSH, FTP, SMTP, POP, IMAP and others.  This zone is used in [[ASL]], and sources on this RBL will have their traffic shunned by default.   
  
 
Please see this article for additional information: [[WAF 350053]]
 
Please see this article for additional information: [[WAF 350053]]
Line 147: Line 153:
  
 
It may be used in [[ASL]] in the future.
 
It may be used in [[ASL]] in the future.
 +
 +
== Threat 8 (TI-8) ==
 +
 +
This zone contains spyware hosts and sources.
 +
 +
== Threat 9 (TI-9) ==
 +
 +
This zone contains command control (C&C) malware servers.
 +
 +
== Threat 10 (TI-10) ==
 +
 +
This zone contains Open Proxies.  Attackers sometimes use open proxies to hide their real IP and to carry out attacks anonymously.
 +
 +
== Threat 11 (TI-11) ==
 +
 +
This zone contains systems that have presented themselves as Search Engines such as google, bing, baidu but are not actually these search engines.  Attackers will sometimes use this method to try to trick software into believing it is a search engine, so as to not block access for indexing purposes.  They use this to bypass security measures, as some security products will blindly assume if a system claims its a search engine, such a google, that it must be.
 +
 +
== Threat 12 (TI-12) ==
 +
 +
This zone contains forum, professional and SMTP spammers.  There is a slightly higher chance of a false positive with this zone than TI-2.
  
 
= Local DNS mirror =
 
= Local DNS mirror =
 +
 +
== pros/cons ==
 +
 +
There are pros and cons to running your own Local DNS mirror of our zones.  We've tried to capture the biggest ones below to help inform you so you can make a decision about whats best for your needs.
 +
 +
=== Pros ===
 +
 +
# Faster.  A local mirror is going to be a lot faster than querying remote DNS servers.
 +
# Potentially more reliable:  See below in cons, this could also introduce a single point of failure if you one have one DNS server serving up the zones.
 +
# Potential customizations to the zones.  You could make your own modifications to the zones.
 +
# Privacy?  Only you will know what you look up in the zones.  DNS queries, even with DNSSEC, arent encrypted.  So everyone can see what you are looking up.  This probably isnt a big deal for a server, but if you're concerned about DNS privacy, this can help somewhat.  Keep in mind that if the bad guys can see your DNS queries, they can also see the traffic going to your server, and all they will see from the TI lookups are the IPs going to your server.
 +
 +
=== Cons ===
 +
 +
# Uses CPU cycles.  rbldnsd is fairly good about this, but no matter what it will use some CPU cycles on your system.  If you are squeeze for CPU cycles, then you probably dont want to do this.
 +
# Uses memory.  Again, rbldnsd is pretty good about this, but no matter what it will use up some of your memory.  Not a lot, certainly less than BIND, but some.  If your system is low on memory, you dont want to run your own local DNS mirror.
 +
# Single point of failure.  If your mirror is down, then lookups will fail, and apache doesnt handle this very well. 
 +
# Not real time.  Since you'll have a mirror, your zones will only be as up to date as the last time your downloaded them.  See the warning about how often you can access the rsync servers.
 +
  
 
== rbldnsd ==
 
== rbldnsd ==
Line 170: Line 215:
 
=== Software Installation ===
 
=== Software Installation ===
  
Note: These instructions are for Redhat and Centos based systems, please other operating systems contact your OS vendor for instructions for installing rbldnsd on your system, or if you need assistance from us please let us know and we'll put a quote together for your system.
+
Note: These instructions are for Redhat and Centos based systems, for other operating systems please contact your OS vendor for instructions for installing rbldnsd on your system, or if you need assistance from us please let us know and we'll put a quote together for your system.
  
 
Step 1)
 
Step 1)
Line 178: Line 223:
 
[[Atomic]]
 
[[Atomic]]
  
Step 2)
+
Step 2) Run the commands below to install the necessary software to run a local RBL style DNS
 +
 
 +
''su -''
  
 
''yum -y install rbldnsd''
 
''yum -y install rbldnsd''
  
Note: rbldnsd is not provided by Atomicorp.
+
''yum -y install rsync''
 +
 
 +
Note: rbldnsd and rsync are provided as a courtesy and are not supported software.
  
 
Step 3)  Configure rbldnsd
 
Step 3)  Configure rbldnsd
Line 198: Line 247:
 
Step 5) create the zone directory
 
Step 5) create the zone directory
  
mkdir /home/rbldnsd/zones
+
''mkdir /home/rbldnsd/zones''
 +
 
 +
''chown -R rbldnsd /home/rbldnsd/zones''
  
 
=== Download the zones ===
 
=== Download the zones ===
Line 213: Line 264:
 
''su - rbldnsd''
 
''su - rbldnsd''
  
''rsync -azv rsync.atomicrbl.com::atomicrbl/* /home/rbldnsd/zones''
+
''/usr/bin/rsync -azv rsync.atomicrbl.com::atomicrbl/* /home/rbldnsd/zones''
  
 
Note: Our zones are formated for rbldnsd, an fast and low memory footprint DNS server designed for RBLs.
 
Note: Our zones are formated for rbldnsd, an fast and low memory footprint DNS server designed for RBLs.
Line 264: Line 315:
 
These instructions are for organizations that want to provide a copy of the zones to their local systems, without installing local copies on those systems.
 
These instructions are for organizations that want to provide a copy of the zones to their local systems, without installing local copies on those systems.
  
Note: Do not run a public remote resolver.  If you would like to run a public resolver, please let us know, theres some additional software you will need.
+
Note: Do not run a public remote resolver.  If you would like to run a public resolver, please let us know, theres some additional software you will need and specific permission to run a public resolver.
  
 
=== Software Installation ===
 
=== Software Installation ===
Line 276: Line 327:
 
[[Atomic]]
 
[[Atomic]]
  
Step 2)
+
Step 2) Run the commands below to install the software
 +
 
 +
''su -''
  
 
''yum -y install rbldnsd''
 
''yum -y install rbldnsd''
  
Note: rbldnsd is not provided by Atomicorp.
+
''yum -y install rsync''
 +
 
 +
Note: rbldnsd and rsync are provided as a courtesy and are not supported software.
  
 
Step 3)  Configure rbldnsd
 
Step 3)  Configure rbldnsd
Line 301: Line 356:
  
 
''mkdir /home/rbldnsd/chroot/zones''
 
''mkdir /home/rbldnsd/chroot/zones''
 +
 +
''chown -R rbldnsd /home/rbldnsd/chroot/''
  
 
=== Download the zones ===
 
=== Download the zones ===
Line 314: Line 371:
 
''su - rbldnsd''
 
''su - rbldnsd''
  
''rsync -azv rsync.atomicrbl.com::atomicrbl/* /home/rbldnsd/chroot/zones''
+
''/usr/bin/rsync -azv rsync.atomicrbl.com::atomicrbl/* /home/rbldnsd/chroot/zones''
  
 
Note: Our zones are formated for rbldnsd, an fast and low memory footprint DNS server designed for RBLs.
 
Note: Our zones are formated for rbldnsd, an fast and low memory footprint DNS server designed for RBLs.
Line 369: Line 426:
  
 
= Frequently Asked Questions =
 
= Frequently Asked Questions =
 +
 +
== How can I test to make sure TI lookups are working? ==
 +
 +
Run this test from your system:
 +
 +
''nslookup 2.0.0.127.test.atomicrbl.com''
 +
 +
If your system is able to lookup TI records, you should get back the IP address:
 +
 +
127.0.0.1
 +
 +
 +
== Does Atomicorp provide support for rbldnsd? ==
 +
 +
Not at this time.  rbldnsd is provided as a courtesy.  The RPMS we provide in the free unsupported "atomic" yum repository, includin rbldnsd, are unsupported. If you require assistance with rbldnsd, please post your questions in the community forums:
 +
 +
https://www.atomicorp.com/forums/viewforum.php?f=11
 +
 +
Or contact support and we will put together a quote through our professional services group.
 +
 +
== yum says it cant find rbldnsd ==
 +
 +
This means you do not have the [[atomic]] yum repo enabled on your system.  Enable the atomic yum repo and try you install again.
  
 
== Why is an IP on a list? ==
 
== Why is an IP on a list? ==

Latest revision as of 16:59, 8 February 2017

Contents

[edit] Introduction

The Atomicorp RBLs are part of the Atomicorp Threat Intelligence system, in machine-readable security content. It provides information about potential sources of malicious activity that can be used to detect potential malicious activity from a source using DNS RBLs.

Collecting data for the purposes of having data does no good and can actually detract from a security intelligence program by using up time and man power to analyze data that is most often noise rather than real indicators of threat. Our system is designed to be instantly actionable, and does not require additional analysis.

[edit] Enabling

[edit] Atomic Secured Linux (ASL)

To enable the TI in ASL just enable this setting:

https://www.atomicorp.com/wiki/index.php/ASL_WAF#MODSEC_00_THREAT

[edit] Looking up Addresses

[edit] DNS

To look up an address on the Atomicorp Threat Intelligence via DNS the format is:

invertedIP.zone.atomicrbl.com

For example, if the IP is 127.0.0.2, and you wanted to check the "test" zone, you would look up the address in this format:

2.0.0.127.test.atomicrbl.com

See this article for setting up a local DNS server to perform faster resolution if you are not going to be running a local copy of the RBL zones:

Local DNS resolver

[edit] Web

Web access is available at the URL below:

http://www.atomicrbl.com/lookup

[edit] Terms of Use

If you are using the Atomicorp Threat Intelligence system to filter traffic to your system you need to know whether you qualify for free use or not.

Free Use is satisfactory for private systems with low traffic, but server administrators are responsible for ensuring their servers remain constantly below the free use limits. Commercial Use provides a completely different and dependable level of service, using your choice of either private dedicated servers, rsync data delivery direct to your network, or integration into ASL.

Caution: If your usage should exceed the free use terms your access to the public DNS servers is very likely to be cut off without warning.

NO WARRANTY OR LIABILITY: BY USING THE RBLs, ATOMICORP THREAT INTELLIGENCE SYSTEM, IT'S DATA, OR ANY INFORMATION CONTAINED ON, IN OR PROVIDED BY ATOMICORP OR ATOMICRBL SERVERS, YOU ACKNOWLEDGE AND AGREE THAT THE RBLs, ATOMICORP THREAT INTELLIGENCE SYSTEM AND IT'S DATA AND ANY INFORMATION CONTAINED ON, IN OR PROVIDED BY ATOMICORP OR ATOMICRBL SERVERS ARE PROVIDED "AS IS". ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE, ARE EXPRESSLY EXCLUDED. IN NO EVENT SHALL ATOMICORP, OR ITS OWNERS, OPERATORS, PARENT, SUBSIDIARIES OR LICENSORS, BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES OF ANY KIND ARISING OUT OF OR IN CONNECTION WITH YOUR USE OF THE ATOMICORP THREAT INTELLIGENCE SYSTEM, IT'S DATA, THE RBLs,ANY INFORMATION CONTAINED ON, IN OR PROVIDED BY ATOMICORP OR ATOMICRBL SERVERS, HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY.

[edit] Free Use

Atomicorp serves billions of DNS queries to the world every day, free of charge, from its public servers. This free public DNS service is sustained and backed financially by Atomicorp. To qualify for the free Atomocorp DNS query service, server operators must ensure they meet the criteria for free use.

Use of the RBLs via DNS queries to our public DNS servers is free of charge if you meet all three of the following criteria:

  1. Your use of the Atomicorp DNS RBLs is non-commercial*, and
  2. Your web traffic is less than 100,000 HTTP connections per day, and
  3. Your RBL query volume is less than 300,000 queries per day.

If you do not fit all three of these criteria then please do not use our public DNSBL servers, instead see 'Commercial Use'.

"non-commercial use" is use for any purpose other than as part or all of a product or service that is resold, or for use of which a fee is charged. For example, using our RBLs in a commercial filtering appliance that is then sold to others requires a feed license, regardless of use volume. The same is true of commercial filtering software and commercial filtering services.

If you are in any doubt as to whether you fit within our free use criteria, or think you may be likely to soon exceed our free use criteria, please switch to 'Commercial Use'.

Atomicorp monitors use of its public DNS servers to identify installations exceeding the free use criteria in order to prevent a minority of heavy users from degrading the quality of the service to all other users of our free public DNS servers.

[edit] Commercial Use

[edit] ASL

Use of the Atomicorp Threat Intelligence system is included with active ASL licenses.

[edit] ASL Reverse Proxy

Use of the Atomicorp Threat Intelligence system is included in active ASL Reverse Proxy licenses.

[edit] Rules only licenses

[edit] Local domains

If the Atomicorp Threat Intelligence system is used to protect domains hosted on the system where a licensed copy of the Atomicorp rules is installed, the use of the Atomicorp Threat Intelligence system is included in the rules only licenses.

[edit] Reverse Proxy

If the Atomicorp Threat Intelligence system is used to protect domains not hosted on the system where a licensed copy of the Atomicorp rules is installed or the rules are setup as part of a reverse proxy, the use of the Atomicorp Threat Intelligence system is not included in the rules only license. Please contact sales for a quote, or purchase an ASL Reverse Proxy license.

[edit] DNS Use

Use of the Atomicorp RBLS by organizations and networks with traffic likely to exceed the Free Use limits, or by ISPs or commercial filter services, requires a subscription to the Atomicorp RBL Datafeed Service, a service designed for users with commercial requirements.

This service provides two options of commercial use: RBL Query Service or the Rsync Service. Both of these deliver fast realtime responses for your servers and is both backed with support and a service contract.

If unsure, you can try either Service free for 30 days before deciding to subscribe to it. For more information contact sales@atomicorp.com.

[edit] Zones

[edit] test.atomicrbl.com

This is a test zone. It is not used by ASL to block anything (in fact its not even used by ASL). This zone exists solely so users can test to see if DNS resolution is working to the zone. There is only one address in the zone.

[edit] alert6

This zone is informational only. It is not used by ASL to block anything, it just records sources that have triggered a level 6 or higher event from systems running Atomicorp products.

[edit] scammers

This zone is informational only. It is not used by ASL to block anything, it just records sources that have a history of malicious behavior.

[edit] Theat 1 (TI-1)

Zone file: threat1.rbl

This zone contains sources that are currently launching DOS attacks. This zone is used in ASL, and sources on this RBL will have their traffic dropped by default. Shunning will not occur, by default, for these sources as that can induce additional load on the attacked system. Dropping traffic is the lowest effort method.

Please see this article for additional information: WAF 350051

[edit] Threat 2 (TI-2)

Zone file: threat2.rbl

This zone contains sources that have been detected spamming. This zone is used in ASL, and sources on this RBL will have their traffic dropped by default. Shunning will not occur, by default, for these sources as that can induce additional load on the attacked system. Dropping traffic is the lowest effort method.

Please see this article for additional information: WAF 350052

[edit] Threat 3 (TI-3)

Zone file: threat3.rbl

This zone contains sources that have been detected carrying out brute force attacks (e.g. password guessing) of services such as web applications, SSH, FTP, SMTP, POP, IMAP and others. This zone is used in ASL, and sources on this RBL will have their traffic shunned by default.

Please see this article for additional information: WAF 350053

[edit] Threat 4 (TI-4)

Zone file: threat4.rbl

This zone contains sources that have been detected carrying out attacks. This zone is used in ASL, and sources on this RBL will have their traffic shunned by default.

Please see this article for additional information: WAF 355504

[edit] Threat 5 (TI-5)

This zone contains sources that have been detected carrying out either attacks or a lot of suspicious activity that when combined means the source is attacking the destination. This zone is used in ASL, and sources on this RBL will have their traffic shunned by default.

Please see this article for additional information: WAF 355506

[edit] Threat 6 (TI-6)

This zone is currently informational only. It is not used by ASL to block anything, it just contains sources that have caused multiple firewall block events.

It may be used in ASL in the future.

[edit] Threat 7 (TI-7)

This zone is currently informational only. It is not used by ASL to block anything.

It may be used in ASL in the future.

[edit] Threat 8 (TI-8)

This zone contains spyware hosts and sources.

[edit] Threat 9 (TI-9)

This zone contains command control (C&C) malware servers.

[edit] Threat 10 (TI-10)

This zone contains Open Proxies. Attackers sometimes use open proxies to hide their real IP and to carry out attacks anonymously.

[edit] Threat 11 (TI-11)

This zone contains systems that have presented themselves as Search Engines such as google, bing, baidu but are not actually these search engines. Attackers will sometimes use this method to try to trick software into believing it is a search engine, so as to not block access for indexing purposes. They use this to bypass security measures, as some security products will blindly assume if a system claims its a search engine, such a google, that it must be.

[edit] Threat 12 (TI-12)

This zone contains forum, professional and SMTP spammers. There is a slightly higher chance of a false positive with this zone than TI-2.

[edit] Local DNS mirror

[edit] pros/cons

There are pros and cons to running your own Local DNS mirror of our zones. We've tried to capture the biggest ones below to help inform you so you can make a decision about whats best for your needs.

[edit] Pros

  1. Faster. A local mirror is going to be a lot faster than querying remote DNS servers.
  2. Potentially more reliable: See below in cons, this could also introduce a single point of failure if you one have one DNS server serving up the zones.
  3. Potential customizations to the zones. You could make your own modifications to the zones.
  4. Privacy? Only you will know what you look up in the zones. DNS queries, even with DNSSEC, arent encrypted. So everyone can see what you are looking up. This probably isnt a big deal for a server, but if you're concerned about DNS privacy, this can help somewhat. Keep in mind that if the bad guys can see your DNS queries, they can also see the traffic going to your server, and all they will see from the TI lookups are the IPs going to your server.

[edit] Cons

  1. Uses CPU cycles. rbldnsd is fairly good about this, but no matter what it will use some CPU cycles on your system. If you are squeeze for CPU cycles, then you probably dont want to do this.
  2. Uses memory. Again, rbldnsd is pretty good about this, but no matter what it will use up some of your memory. Not a lot, certainly less than BIND, but some. If your system is low on memory, you dont want to run your own local DNS mirror.
  3. Single point of failure. If your mirror is down, then lookups will fail, and apache doesnt handle this very well.
  4. Not real time. Since you'll have a mirror, your zones will only be as up to date as the last time your downloaded them. See the warning about how often you can access the rsync servers.


[edit] rbldnsd

We provide our zones in rbldnsd format. rbldnsd is a lightweight, fast DNS server designed for RBLs. From the rbldnsds project homepage:

rbldnsd is a small and fast DNS daemon which is especially made to serve DNSBL zones. This daemon was inspired by Dan J. Bernstein's rbldns program found in the djbdns package.

rbldnsd is extremely fast - it outperforms both bind and djbdns greatly. It has very small memory footprint.

The daemon can serve both IP-based (ordb.org, dsbl.org etc) and name-based (rfc-ignorant.org) blocklists. Unlike DJB's rbldns, it has ability to specify individual values for every entry, can serve as many zones on a single IP address as you wish, and, finally, it is a real nameserver: it can reply to DNS metadata requests. The daemon keeps all zones in memory for faster operations, but its memory usage is very efficient, especially for repeated TXT values which are stored only once.

[edit] Requesting Access

Access to the zones, for local DNS mirroring, is restricted. To request access, please send an email to support. We will need to know the IP address(es) of the systems that will be requesting access (or CIDR is this is a range), and will ask you to sign an confidentiality agreement to access the zones.

Access is restricted to existing customers only.

[edit] Local Only Resolver

[edit] Software Installation

Note: These instructions are for Redhat and Centos based systems, for other operating systems please contact your OS vendor for instructions for installing rbldnsd on your system, or if you need assistance from us please let us know and we'll put a quote together for your system.

Step 1)

Enable the free unsupported atomic rpm repository by following the instructions at the page below:

Atomic

Step 2) Run the commands below to install the necessary software to run a local RBL style DNS

su -

yum -y install rbldnsd

yum -y install rsync

Note: rbldnsd and rsync are provided as a courtesy and are not supported software.

Step 3) Configure rbldnsd

For a local resolver, all you need to do is add this single line to your /etc/sysconfig/rbldnsd file:

RBLDNSD="dsbl -u rbldnsd -b127.0.0.01/750 -a -v -f -c60 -r/home/rbldnsd/zones threat1.atomicrbl.com:ip4set:threat1.rbl atomicrbl.com:generic:atomicrbl.com threat2.atomicrbl.com:ip4set:threat2.rbl threat3.atomicrbl.com:ip4set:threat3.rbl threat4.atomicrbl.com:ip4set:threat4.rbl threat5.atomicrbl.com:ip4set:threat5.rbl test.atomicrbl.com:ip4set:test.atomicrbl.com"

By default, in Redhat and Centos, everything else should be commented out in this configuration file. If its not, comment it out, you will only need this line in that file.

Step 4) create the rbldnsd user

useradd rbldnsd

Step 5) create the zone directory

mkdir /home/rbldnsd/zones

chown -R rbldnsd /home/rbldnsd/zones

[edit] Download the zones

Step 1) Request access


See the top of this document for access. Access to the zones, for local DNS mirroring, is restricted and is restricted to existing customers only.

Step 2) Use rsync to download the zones

Caution: Do not run this more often than hourly at this time.

su - rbldnsd

/usr/bin/rsync -azv rsync.atomicrbl.com::atomicrbl/* /home/rbldnsd/zones

Note: Our zones are formated for rbldnsd, an fast and low memory footprint DNS server designed for RBLs.

If you have defined outbound firewall rules in ASL make sure you allow port 873 outbound to rsync.atomicrbl.com. If you are using fast mode, check this setting in ASL:

https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_OUTPUT_TCP_SERVICES

Step 3) Start rbldnsd

/etc/init.d/rbldnsd start

[edit] Configuring

This allows you to continue to use bind on your system, and rbldnsd in parallel for the RBL lookups.

Step 4) Configure your DNS server to forward to rbldnsd for atomicrbl.com

For bind, add this to your /etc/named.conf file:

zone "atomicrbl.com" {

       type forward;
       forward first;
       forwarders {
       127.0.0.1 port 750;
       };

};

Step 5) Restart named/bind

/etc/init.d/named restart

Step 6) Test resolution

nslookup 2.0.0.127.test.atomicrbl.com

If you have things setup correctly to use a local resolver on your system, you should see this:

Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	2.0.0.127.test.atomicrbl.com
Address: 127.0.0.1

[edit] Remote Resolver

These instructions are for organizations that want to provide a copy of the zones to their local systems, without installing local copies on those systems.

Note: Do not run a public remote resolver. If you would like to run a public resolver, please let us know, theres some additional software you will need and specific permission to run a public resolver.

[edit] Software Installation

Note: These instructions are for Redhat and Centos based systems, please other operating systems contact your OS vendor for instructions for installing rbldnsd on your system, or if you need assistance from us please let us know and we'll put a quote together for your system.

Step 1)

Enable the free unsupported atomic rpm repository by following the instructions at the page below:

Atomic

Step 2) Run the commands below to install the software

su -

yum -y install rbldnsd

yum -y install rsync

Note: rbldnsd and rsync are provided as a courtesy and are not supported software.

Step 3) Configure rbldnsd

For a local resolver, all you need to do is add this single line to your /etc/sysconfig/rbldnsd file, and you must change the IP address 1.2.3.4 to your servers IP address:

RBLDNSD="dsbl -u rbldnsd -b1.2.3.4 -a -v -f -c60 -r/home/rbldnsd/chroot -w zones threat1.atomicrbl.com:ip4set:threat1.rbl atomicrbl.com:generic:atomicrbl.com threat2.atomicrbl.com:ip4set:threat2.rbl threat3.atomicrbl.com:ip4set:threat3.rbl threat4.atomicrbl.com:ip4set:threat4.rbl threat5.atomicrbl.com:ip4set:threat5.rbl test.atomicrbl.com:ip4set:test.atomicrbl.com threat6.atomicrbl.com:ip4set:threat6.rbl threat7.atomicrbl.com:ip4set:threat7.rbl alert6.atomicrbl.com:ip4set:alert6.rbl -l +/logs/rbldnsd.log -s /logs/rbldnsd_stats"

By default, in Redhat and Centos, everything else should be commented out in this configuration file. If its not, comment it out, you will only need this line in that file.

Step 4) create the rbldnsd user

useradd rbldnsd

Step 5) create the rbldnsd directories

mkdir /home/rbldnsd/chroot

mkdir /home/rbldnsd/chroot/logs

mkdir /home/rbldnsd/chroot/zones

chown -R rbldnsd /home/rbldnsd/chroot/

[edit] Download the zones

Step 1) Request access

See the top of this document for access. Access to the zones, for local DNS mirroring, is restricted and is restricted to existing customers only.

Step 2) Use rsync to download the zones

Caution: Do not run this more often than hourly at this time.

su - rbldnsd

/usr/bin/rsync -azv rsync.atomicrbl.com::atomicrbl/* /home/rbldnsd/chroot/zones

Note: Our zones are formated for rbldnsd, an fast and low memory footprint DNS server designed for RBLs.

If you have defined outbound firewall rules in ASL make sure you allow port 873 outbound to rsync.atomicrbl.com. If you are using fast mode, check this setting in ASL:

https://www.atomicorp.com/wiki/index.php/ASL_firewall#FW_OUTPUT_TCP_SERVICES

Step 3) Start rbldnsd

/etc/init.d/rbldnsd start

Step 4) Test resolution

nslookup 2.0.0.127.test.atomicrbl.com

If you have things setup correctly to use a local resolver on your system, you should see this:

Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	2.0.0.127.test.atomicrbl.com
Address: 127.0.0.1

Step 5) Setup logrotation for the resolution logs


Add this file:

/home/rbldnsd/chroot/logs/*.log {
    rotate 30
    daily
    compress
    missingok
    notifempty
    create 0644 rbldnsd rbldnsd
    sharedscripts
    prerotate
	/sbin/service rbldnsd stop
    endscript
    postrotate
	/sbin/service rbldnsd start
    endscript
}

To this directory:

/etc/logrotate.d

[edit] Frequently Asked Questions

[edit] How can I test to make sure TI lookups are working?

Run this test from your system:

nslookup 2.0.0.127.test.atomicrbl.com

If your system is able to lookup TI records, you should get back the IP address:

127.0.0.1


[edit] Does Atomicorp provide support for rbldnsd?

Not at this time. rbldnsd is provided as a courtesy. The RPMS we provide in the free unsupported "atomic" yum repository, includin rbldnsd, are unsupported. If you require assistance with rbldnsd, please post your questions in the community forums:

https://www.atomicorp.com/forums/viewforum.php?f=11

Or contact support and we will put together a quote through our professional services group.

[edit] yum says it cant find rbldnsd

This means you do not have the atomic yum repo enabled on your system. Enable the atomic yum repo and try you install again.

[edit] Why is an IP on a list?

You can lookup an IP on the lookup page at the URL below:

http://www.atomicrbl.com/lookup/

[edit] How do I remove an IP from a list?

If the system was compromised and is no longer sending out attacks or spam it will be automatically removed from the list if no further malicious traffic is detected coming from the system.

If you are not sure, please contact us and we can investigate further.

[edit] You're blocking me!

Atomicorp doesnt block anything.

Atomicorp users use our blocklists freely and voluntarily. It is those users that are blocking you.

It is also important to understand that your traffic never touches Atomicorp's network, nor is it being intercepted or re-routed by us. The server you are connecting to (the one that is rejecting your traffic) is using a filter, set up by the owner of that server, that checks to see if the IP address you are sending from is listed on an Atomicorp list. If it is listed, depending on the policy of the server owner the server may accept, flag for further filtering, or reject your traffic. How Internet servers handle incoming traffic is governed solely by the server owners, not Atomicorp, we can only state whether an IP address has generated traffic that matches an lists criteria.

Personal tools