Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...DNN 6.2 and DNN 7.2 Hacked already... HELP ME....DNN 6.2 and DNN 7.2 Hacked already... HELP ME....
Previous
 
Next
New Post
10/9/2014 2:03 AM
 
Joe Brinkman wrote:

Armin,

  We appreciate the feedback, however Spam Registration is not a bug on our part. It is an epidemic that affects the entire internet community.  It is not as simple as saying, "I have identified the issue, now fix it in the next release please."  I would love it if this were no longer a problem for DNN, but the fact remains that it is a problem for any website (not just DNN sites) that accepts public registrations.  This problem is the reason that products like reCaptcha exist.  Given that Google with a dedicated team, led by some very brilliant computer scientists, is unable to solve the problem, then I am under no illusion that the DNN community or DNN Corp will suddenly solve the issue on a single release.

We will continue to work on improving the DNN Platform to deal with SPAM bots and already have some plans in the works for 7.4.0, but I only expect to get an incremental improvement in this area and not a magical cure all to a problem which has plagued the internet for the better part of 20 years.

 Thanks Joe, It was the best and clear answer about Spam Registration and I got it what's happen. and I'm sorry for my pressure about fix it in next issue.

Thank you very much again...

 
New Post
10/9/2014 2:05 AM
 
Todd S wrote:
It would seem to me that a random url for the login page could be generated so each dnn install would have a unique url for the registration page, therefore making it harder for bots to find.

 

Yes, I think it's grate Idea.... and good way to stop it.
 
New Post
10/9/2014 2:41 AM
 
I think I find very important thing and maybe can help you for fix this problem!

I have More than 50 Different DNN Website for mine or my clients.... in Arabic, Farsi, French, Cartoli, Russia and English languages.

The Spam Registration are happen on English Websites like www.kindcare.ae and I never get Spam Registration on Farsi Websites or Cartoli or Russian Language Website! 

In English Websites sometime I had 30 registration per day and sometime only 3 registration. But, After Upgrade it to DNN 7.3.3 it is really better and I had some days without registration. It's happen for first time in last 3 mounts!

I'm sure you will success to finish at all this outside attack.

Thank you for DNN Powerful Team, and Special Thanks from Cathal, Sebastian and Richard...
 
New Post
10/22/2014 4:25 AM
 

I finally solved the spambot attack of my DNN websites through the  Project Honey Pot (www.projecthoneypot.org)

It is very simple to add to your DNN website in simple three steps!

  1. Free register an account on www.projecthoneypot.org to obtain your free AccessKey
  2. Add the Honey Pot DLL on your bin folder (HttpBL.dll with right target framework 2.0 or 4.0 depending on your DNN installation)
  3. Add following setting to your web.config


<configuration>
  <configSections>
    <section name="HttpBL" type="HttpBL.Settings"/>
  </configSections>
...other stuff...
  <appSettings/>
...other stuff...
  <HttpBL
    Enabled="true"
    AlwaysAllow=""
    AlwaysDeny=""
    AccessKey="your access key"
    QueryDomain="dnsbl.httpbl.org"
    MaxAge="30"
    MaxScore="40"
    CacheTTL="3600"
    CacheWhite="true"
    RedirectOnHit="false"
    RedirectURL="/denied.aspx?ip=$IP&amp;result=$RESULT"
    Logging="true"
    LogPath="C:\YourLogDirectory"
    LogHits="true"
  />
...
  <connectionStrings/>
...
  <system.web>
    <httpModules>
      <add name="HttpBL" type="HttpBL.HttpBL"/>
    </httpModules>
...

Note: the above config may change depending from the version of IIS you're running and
      how you configured it (kudos to Brandi for the note !!); that is

<!-- If IIS 6 or IIS 7 running in Classic mode -->
  <system.web>
    <httpModules>
      <add name="HttpBL" type="HttpBL.HttpBL"/>
    </httpModules>

...

<!-- If IIS 7 running in Integrated mode -->
  <system.webServer>
    <modules>
      <add name="HttpBL" type="HttpBL.HttpBL"/>
    </modules>


Enabled             true = enable filtering

AlwaysAllow            pathname of a file containing IPs (one on each line) which will never
                    be blocked nor looked up; the IPs may be partial ones, so, for example
                    "192.0.2." will match all the IPs starting with the given three octets
                    while "198.51.2" will match the first two octets and any IP whose third
                    octed starts with "2"; the pathname may be an absolute one, a relative
                    one (not recommended) or a virtual path

AlwaysDeny            pathname of a file containing IPs (one on each line) which will always
                    be rejected (w/o any lookup); this list supports partial IPs as seen
                    for the allow one (path notes as for allow)

AccessKey           this MUST be a valid Http:BL key obtained from Project Honeypot (PHP)
                    for infos, please visit http://www.projecthoneypot.org

QueryDomain         the domain used for the DNS queries, change it ONLY if needed (as of
                    today, the default should be kept to allow the module to work)

MaxAge              bad IPs BELOW this age (days) will be rejected (see "PHP" for details)

MaxScore            bad IPs ABOVE this threat score will be rejected (see "PHP" for details)

CacheTTL            time (seconds) for which a given IP infos will be cached (good IPs will stay
                    in cache for 1/4 of this time, the default value of 3600, that is, 1 hour is
                    generally a good pick, change it only in case of problems); notice that the TTL
                    is "dynamic" that is, a given cached entry will only expire "TTL" seconds after
                    the last time it was requested, this helps further improving the caching and, in
                    turn, reducing requests to the Http:BL DNS servers

CacheWhite          true = also cache "good" IPs (helps avoiding too much queries), such IPs will
                    stay in cache for 1/4 of the TTL, so if using the default TTL of 3600 good IPs
                    will be cached for 15 minutes, this avoids the need to query the Http:BL DNS
                    servers for good IPs from regular visitors browsing your web site

RedirectOnHit       true = bad hosts will be redirected to the specified URL, (false = they will
                    be rejected using the default, built-in error page)

RedirectURL         bad hosts will be redirected to the URL specified here (it can be a relative
                    or absolute URL) the URL may contain optional parameters, the macros $IP and
                    $RESULT will be replaced with the visitor IP (the "bad IP") and the result
                    from the Http:BL lookup, this way you may setup some kind of custom "informative
                    page" if you want, which will explain why the access was denied and what to do

Logging             true = enable writing infos to log files

LogPath             path where the logs will be created, the path may be absolute or relative, just
                    ensure that the folder exists and that the IIS process has write rights on the
                    folder, otherwise no logging will take place, the log file names will have the
                    format HttpBL-MM.log where MM=month; older logs will be automatically replaced
                    by newer ones, this means that we'll have a max of 12 logs (one each month) so
                    we won't need to worry about mantaining older logs or filling up the disk; the
                    path can be specified as seen for the allow/deny lists

LogHits             true = logs the bad IPs hitting your site, false = only logs errors/warnings
                    notice that the hits and the errors/messages will be logged using different
                    logfiles (same naming approach as above)
 
New Post
10/22/2014 8:45 AM
 
Scippy, thanks for sharing your solution

Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
Previous
 
Next
HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...DNN 6.2 and DNN 7.2 Hacked already... HELP ME....DNN 6.2 and DNN 7.2 Hacked already... HELP ME....


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out