Difference between revisions of "Atomicrbl"
m (→Software Installation) |
m (→Frequently Asked Questions) |
||
(6 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 155: | Line 161: | ||
This zone contains command control (C&C) malware servers. | 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 278: | 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 389: | 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? == | == Does Atomicorp provide support for rbldnsd? == |
Latest revision as of 17: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:
[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:
- Your use of the Atomicorp DNS RBLs is non-commercial*, and
- Your web traffic is less than 100,000 HTTP connections per day, and
- 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
- 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.
[edit] 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.
[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:
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:
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.