Open tarunKoyalwar opened 2 weeks ago
Hey, thanks for this, I also wanted to add that if I select specific directory for templates, let's say "http" , then there won't be any errors.
thanks for feedback @amiremami , @dwisiswant0 we should also make sure that host skipping happens on address ( i.e host+port) and not on just hostname/ip ( from above snapshot it looks like when running tcp/js templates errors of those ports ( 22 etc) are being counted towards that of ip/host )
we did add support for this a while ago ^ but something might have changed in fastdialer logic or here in nuclei
The current implementation of the max-host-error mechanism needs to be reconsidered. During heavy scanning, it's common to experience up to 30 dropped requests, but skipping the target simply because 30 requests fail while sending 13,000 requests doesn’t make sense. The target should only be skipped if none of the requests are succeeding, or if 30 consecutive requests fail without a response. Otherwise, it leads to prematurely skipping targets before they are fully tested.
I've been using Nuclei for a while and noticed that I wasn’t getting meaningful results until I debugged this issue. I discovered that no target was being fully scanned due to this flawed error-handling logic. I suggest a different approach to handling target skipping, or at least give more control over this.
Update: I'm using -no-mhe
or -mhe 300
until a better fix is implemented (To be able to differ between a non-responsding target from a target that fails sometimes)
Is there an existing issue for this?
Current Behavior
due to a recent updates related to max-host-error and target skipping whenever we run nuclei with concurrency more than the default one nuclei actively skips that targets
The current implementation checks for 30 (fixed) permanent errors in a given time period ( 1 minute ) and if any targets satisfy this criteria then it is actively skipped,
when nuclei is run with default values there is no max-host-error or skipping but this can be seen as soon as concurrency is increased. so instead of hardcoding it to 30 we should set its value to the value of concurrency flag and timeperiod can also be set to 1.5 x -timeout flag value
Expected Behavior
no skipping of targets when its intentional / expected to have some errors
Steps To Reproduce
Relevant log output
No response
Environment
Anything else?