During yesterday i have been making a number of optimizations to my nuke's mainfile.php file, mostly regarding to speed up the page load time.
One of those changes was to remove the ipban.php include if NukeSentinel is used (as it is on my site)
The result?... This morning i've received 200 e-mails about "ppl" trying to send crap through Feedback module (those mails does not comes from NS, it's something i've added myself to catch spammers..)
And as such, it makes me guess the NukeSentinel's Anti-Flood protection does not work at all (it worked before thanks to ipban), or?...
before someone asks, yes... i have sentinel properly configured to protect against flood (EMail Admin & Default Page).
By looking at the ab_flood() function i have to say i mostly saw strange sentences, and some things i can't even get to understand...
first of all, it looks like on my .ftaccess file i always have *one entry* only, for example:
and therefore, the $floodcount variable is always 1, which render the following code useless:
Code:
$floodopen = fopen($ab_config['ftaccess_path'], "w");
foreach($floodarray as $floodwrite){
//if(!strstr($floodwrite, $floodarray[$floodcount-10]))
if ($floodcount-10>=0) if(!strstr($floodwrite, $floodarray[$floodcount-10]))
fputs($floodopen, $floodwrite);
}
Well... the code isn't really useless... it purges/clear the .ftaccess file on each visit (!?!)
What i don't understand is what it is for the $floodcount-10 usage, since it's always -9 here and therefore if($floodcount-10>=0) is always FALSE. Furthermore, by the same reason, explode(' || ', $floodarray[$floodcount-3]); will always return nothing and block_ip($blocker_row); never reached therefore?????
Also note the .ftaccess file is opened two times but closed only once (and in wrong place), side effects from that? who knows from all those server configurations...
In the other hand, this function can be improved a lot to speed it up, mainly if the $floodcount-10 is really a way of doing things, most of the function code can be skipped if the result is empty..
I was about to modify/fix/improve that function to my understanding, but first i wanted to let you guys know about the issue as you're the current NukeSentinel maintainers, right?
Joined: Aug 28, 2003 Posts: 6373 Location: Vsetin, Czech Republic
Posted:
Mon Nov 09, 2009 9:43 am
Check the configuration again
It won't block it if it isn't set to block it and your setting is at 'Email Admin & Default Page' - does it have the option 'Email, Block & Default page' ??
You're right, i didn't had the '& Block' statement set as well.
However, note i didn't received any email with a Flood abuse report, and since I use 'Email Admin' i should have received a lot of emails coming from NS if Anti-Flood would work ok, don't you think?
If you are then I would be surprised if it was a bot because of the captcha.
It does not matter, because a captcha (or any other protection) does not forbid bots at all from sending/submitting forms.
Quote:
...not posting quick enough to trigger the Flood blocker.
Seriously, do you think the flood blocker can be triggered/achieved, considering the .ftaccess file is cleared with each visit?
hmm, i must be missing something...or just i can't understand how this thing work or it's supposed to work... (?)
hmmm...(4 minutes later) well... may i get it... may the flood blocker is triggered when a bot sends several http requests in such a way that all of them makes a collision into ab_flood(), specifically at the $floodappend = fopen($ab_config['ftaccess_path'], "a"); step - is that what you mean? i found this quite random but of course it can happen..
Joined: Aug 28, 2003 Posts: 6373 Location: Vsetin, Czech Republic
Posted:
Mon Nov 09, 2009 1:39 pm
I have never looked at this functionality within NS to be honest as I use RN and have never had the problem you describe (except when I originally used phpNuke).
To be perfectly honest, I don't think the flood blocker is supposed to impose a series of permanent bans, just slow down the attack a bit - attacks like that should really be dealt with at server level.
The right CAPTCHA, if implemented correctly does stop the sort of behavior you describe with regard to automated form submission. If the form is being targeted by automated bots, you could just as easily change the form input variables, or even use the module from RN and just comment out the CAPTCHA code (it's commented within the file).
I'm sorry I have to disagree, I bet if you were using the feedback module with a captcha you would not have a problem.
Guardian2003 wrote:
The right CAPTCHA, if implemented correctly does stop the sort of behavior you describe
no offense, but... are both you kidding??
I'm quite sure about what i said, again: a captcha DOES NOT forbid bots from SENDING forms(*)
hmm, i guess both you didn't understand me, and therefore i have to apologize by my bad english... it's not my mother language and sometimes i do not found the right words...
(*) OF COURSE a captcha forbids the form from being processed, but it does not forbid bots from actually sending it, as i said. - anyway this is becoming OFFTOPIC.
Guardian2003 wrote:
Sorry I can't help you any more on that this one.
No problem! I do not want to waste your time, there are more RN admins
Who is the actual NS Maintainer? just Raven?
BTW, reading this (your last) post i get a little confused, I'm reporting some bugs and/or security flaw (to my understanding) within NukeSentinel - it has nothing to do with RN, plain php-nuke, or whatever CMS I use, this is offtopic as well.
This morning i've received 200 e-mails about "ppl" trying to send crap through Feedback module (those mails does not comes from NS, it's something i've added myself to catch spammers..)
The emails i've received AREN'T Feedback submissions.
ARE reports from a protection i've added myself to the Feedback module.
Joined: Aug 28, 2003 Posts: 6373 Location: Vsetin, Czech Republic
Posted:
Mon Nov 09, 2009 2:45 pm
Your concerns and your comments are not off topic at all. I was just saying that I don't personally know enough about the Flood blocker to be able to give you an answer or a direction to go in, there are others here who might be able to.
Can you post your mailfile.php meotoo. I did somes changes too and added a very simple code which load the site litttle faster than normal. I think you should play a little bit with NS and then you can see if it is working or not. In my opinion it is working pretty good.
Can you post your mailfile.php meotoo. I did somes changes too and added a very simple code which load the site litttle faster than normal. I think you should play a little bit with NS and then you can see if it is working or not. In my opinion it is working pretty good.
Joined: Mar 30, 2006 Posts: 2456 Location: Pittsburgh, Pennsylvania
Posted:
Mon Nov 09, 2009 5:55 pm
meotoo wrote:
hmmm...(4 minutes later) well... may i get it... may the flood blocker is triggered when a bot sends several http requests in such a way that all of them makes a collision into ab_flood(), specifically at the $floodappend = fopen($ab_config['ftaccess_path'], "a"); step - is that what you mean? i found this quite random but of course it can happen..
That is the point of a flood.
You will only be added to the file multiple times if this code is true
Also note the .ftaccess file is opened two times but closed only once (and in wrong place), side effects from that? who knows from all those server configurations..
It is opened with a different parameter and you only close it once.
meotoo wrote:
In the other hand, this function can be improved a lot to speed it up, mainly if the $floodcount-10 is really a way of doing things, most of the function code can be skipped if the result is empty..
The bulk of this function is skipped if the result is 0.
meotoo wrote:
Quote:
If you are then I would be surprised if it was a bot because of the captcha.
It does not matter, because a captcha (or any other protection) does not forbid bots at all from sending/submitting forms.
You are correct that a CAPTCHA will not stop a bot from sending data to the server. No php coding can physically stop a user/bot from sending data to the server, but it does stop the data from being processed. If you are worried about bandwidth etc being wasted from the "flood" the flood blocker will block that.
wow... and such collision is guarantee to be reached in a safely way?... because i always had in mind the way IPBan's Anti-Flood is doing it, and it's why i saw that NS's code strange.. i still have wonders/doubts.. for example, what about if such collision is achieved from several different IPs? they will be written randomly to .ftaccess which makes the following code doubtfully valid, i guess:
I think the if($floodcount > 9) { is needed, but i'll move the fopen outside, or may isn't needed? (it is ok as is?)
at least i'll move fclose($floodopen); where it was before, at function's bottom. and i'll remove fclose($floodappend); then, if it's what is needed to the collision to happen..
View next topic View previous topic
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum