View previous topic :: View next topic |
Author |
Message |
kguske Site Admin
Joined: May 12, 2005 Posts: 876
|
Posted: Wed Jan 25, 2012 10:09 pm Post subject: nukeSPAM update |
|
|
nukeSPAM(tm) is currently in alpha release. It is in use on a few sites and being reviewed by several members of the RavenNuke(tm) team.
nukeSPAM currently has the ability to block user registration by optionally checking: - admin-specified combinations of username, email address and / or IP address against known spammer databases:
- BotScout
- fSpamList
- StopForumSpam
- DNS blacklists (by IP):
- Abuse.CH (Drone)
- Abuse.CH (HTTPBL)
- Abuse.CH (Spam)
- Abuse.CH (ZeusTracker)
- AHBL
- DroneBL
- EFNet
- Project Honey Pot
- Sorbs
- SpamHaus
- SpamCop
- Tornevall
- Tor
Each database / blacklist can be individually configured (enabled / disabled) with pop-up guidance on usage, and there are links for those that require database / API keys for use.
It also allows admins to manually test (for false positive resolution and eventual integration with RavenNuke(tm) Your Account - RNYA).
We're currently working on logging, whitelist functionality and documentation. Stay tuned... _________________
Last edited by kguske on Sun Mar 07, 2021 9:08 pm; edited 1 time in total |
|
Back to top |
|
|
kguske
|
Posted: Tue Jan 31, 2012 9:51 am Post subject: |
|
|
Logging is working now, and it has been moved from an admin function to the module.
This will allow non-admin users to view your spam log, but I wouldn't recommend that as giving access to this give access to email addresses and, depending on the volume of your log and the settings / configuration, could impact performance (i.e. you don't necessarily want everyone viewing thousands of records whenever they desire to).
The whitelist functionality is next, then more testing and documentation.
In short - it's coming soon...
Here's a screenshot of viewing the log (test data):
|
|
Back to top |
|
|
Guardian webmaster
Joined: Dec 25, 2005 Posts: 364 Location: Vsetin, Czech Republic
|
Posted: Wed Feb 01, 2012 4:20 pm Post subject: |
|
|
Really looking forward to using this great tool! |
|
Back to top |
|
|
kguske
|
Posted: Wed Feb 01, 2012 5:33 pm Post subject: |
|
|
G, you can appreciate this: the IP address is stored as an integer to save space and time (someone did an analysis comparing storing IP address as a string and an integer - it took less space - naturally, but also less time to store, retrieve, and convert IP addresses stored as integer). It uses built-in MySql functions to do the conversions.
Nice! |
|
Back to top |
|
|
montego webmaster
Joined: Dec 26, 2005 Posts: 254
|
Posted: Sat Feb 04, 2012 7:40 am Post subject: |
|
|
kguske, since IPV6 is already in use and is going to start growing more rapidly, are there going to be any provisions for this? I struggle with the same question around NukeSentinel™. With the conversion being a 128bit number, I am not looking forward to that addition - but isn't it necessary? _________________ Only registered users can see links on this board! Get registered or login!
Only registered users can see links on this board! Get registered or login! |
|
Back to top |
|
|
kguske
|
Posted: Sat Feb 04, 2012 8:35 am Post subject: |
|
|
Not yet. |
|
Back to top |
|
|
kguske
|
Posted: Wed Feb 08, 2012 12:19 am Post subject: |
|
|
Today's update: the whitelist maintenance function is completely working with modal dialogs for adding and deleting and inline editing of whitelist entries.
What remains:
- One logging bug to fix
- Some language definitions
- Configuration for the jQuery UI theme (possibly, thought this should really be defined outside this module)
- (finally) addressing the false positive possibility
- Code cleanup
- Packing / license notifications / etc.
Future releases:
- Purging of the log file
- Improved validation when adding / editing whitelist entries |
|
Back to top |
|
|
kguske
|
Posted: Thu Feb 09, 2012 6:49 pm Post subject: |
|
|
Ready for private Beta (notifications have been sent).
What remains:
- Configuration for the jQuery UI theme (possibly, thought this should really be defined outside this module)
- Minor code cleanup
- Packing / license notifications / etc.
Future releases:
- Purging of the log file
- Improved validation when adding / editing whitelist entries |
|
Back to top |
|
|
Palbin webmaster
Joined: Nov 28, 2007 Posts: 38
|
Posted: Fri Feb 10, 2012 1:32 pm Post subject: |
|
|
I have a few issues I have come across.
1. The table names are hard coded in log.php
2. Code: 1064 - Message: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'where config_type = "nukeSPAM"' at line 1
SQL was: SELECT 1 FROM `nuke_seo_config` LIMIT 1 where config_type = "nukeSPAM"
3. Code: 1062 - Message: Duplicate entry 'nukeSPAM-baseMatch' for key 'PRIMARY'
SQL was: INSERT INTO `nuke_seo_config` VALUES ('nukeSPAM', 'baseMatch', '');
4. In log.php you should be doing $sOrder = ''; not if (!isset($sOrder)) $sOrder = '';. If you leave it this way you nee to filter it.
5. A major issue is that if the module is activated the add/delete functions become indirectly "publicly" available. I know you do not intend this to be public, but these should not be available to anyone other than an admin at any time.
6. Also if the module is activated a person could query your db from a separate site via ajax the same way you are doing it. There is not really a way around this unless you use some kind of token. Again I know you do not intend this to be public, but I would only let log.php run if it is a user. Maybe display a message saying you must be logged in to view or something. The only reason I say this is that you know some person is going to make this public. |
|
Back to top |
|
|
kguske
|
Posted: Fri Feb 10, 2012 2:15 pm Post subject: |
|
|
1. I'll change it to use $prefix.
2. This is necessary for first-time installation of the tables.
3. Not sure if this is related to #1, but there is only one insert.
4. $sOrder cannot be initialized as it's passed into that function, so I'll addslashes.
5. It's public in the sense that any module can use it, but I'll look into securing this further.
6. The module security addresses this (i.e. if you make the module available to everyone, yes, anyone could retrieve it, just as they would if they went through modules.php). |
|
Back to top |
|
|
kguske
|
Posted: Fri Feb 10, 2012 2:28 pm Post subject: |
|
|
Correction: $sOrder is set based on other cleansed parameters, so it can be initialized. I'll test and confirm. |
|
Back to top |
|
|
Palbin
|
Posted: Fri Feb 10, 2012 2:45 pm Post subject: |
|
|
I get 2 & 3 on every page load of the admin section even after it installs.
What I mean by 5 is that any one that has access to view the module can add or delete entries even if the options are not vieable. They can submit a dummy form or do it via ajax. You need to be doing an is_admin() test before allowing these to continue. |
|
Back to top |
|
|
kguske
|
Posted: Fri Feb 10, 2012 3:01 pm Post subject: |
|
|
1, 4 and 5 have been corrected (same download link). I also made change that could resolve 2 & 3. I'm not seeing those errors in my version of WAMP, so please confirm and let me know.
Thanks! |
|
Back to top |
|
|
Palbin
|
Posted: Fri Feb 10, 2012 4:42 pm Post subject: |
|
|
You need to move the LIMIT to the end of the statement to correct 2 & 3.
Code:
$existSQL = 'SELECT 1 FROM `'.$prefix.'_seo_config` WHERE `config_type` = "nukeSPAM" LIMIT 1';
|
I have confirmed that this works. |
|
Back to top |
|
|
kguske
|
Posted: Fri Feb 10, 2012 4:57 pm Post subject: |
|
|
That's already there:
Code: $existSQL = 'SELECT 1 FROM `'.$prefix.'_seo_config` LIMIT 1 where config_type = \'nukeSPAM\'';
|
Must it be after the where clause? |
|
Back to top |
|
|
|