Syncly.it

Hi @wfgerald

All the websites that were giving this error are hosted on the same VPS and all share the same template, so the auto update is enabled in all cases. Some websites are actually updating wordfence but others are not. The message was visible after the update and not before.

For clarity this is the option im referring to:
https://share.creoweb.it/d00c311c.jpg

I’ll check if every website has auto update turned off for some reason.

• This reply was modified 4 years, 10 months ago by Syncly.it.

Hello @wfgerald,

All of the websites was updated today, on some of them Wordfence was already updated on others I had to manually update it, I’m not sure why. All the webistes are sharing the same template so I was supposing to have all on the same page, but it is not the case.

@mindctrl @rafarjonilla

I’m not sure how much this topic is of some interest to USA based dvelopers since they doesn’t have GDPR. For my websites I use newsletter provider custom forms and add it myself with a little CSS extra in some cases.

@piedro,

I think that this functionality is behid a pay wall.

Hi @wfphil

Sorry if I wasn’t too clear, I have set a rule to block IP that fail a given number of login and to block login using user names that doesn’t exists.

I thought that blocking an IP and henche refusing all the data sent from it, would be a smarter way to prevent further XSS attemps rather than filtering them one by one. If an IP performs any kind of attack, should be blacklisted and not even consider the data sent thought.

Hi @wfphil

You probably didnt read my last message, the firewall blocked 120+ attacks, this means that it is not correctly black listing the attacker IP but rather allow it to access the website and perform another attack. It should black list the attacker IP after the first XSS or other form of attack and prevent it to keep trying.

Hi @wfphil

I wanted to update you about this XSS attacks, it now correclty lookup the address IP of the attacker, yet it is allowed to perform multiple (120+) attacks without blacklisting the attacking IP, why it is not blocked after the first attack?

https://share.creoweb.it/9362a4bb.jpg

Hi @wfphil

It seems that the XSS attacks stopped, I’m not sure but possibly blocked at hosting provider level.

About my other ticket of some months ago, was you able to schedule a release date to make distinction between failed and banned login attemps when using a real user respect a common/missing user?

Hi @wfphil

Maybe canned was not the right term, I didn’t mean automated like from a bot but rather a copy/paste since I see the option with its full description.

However back to my former question I need to rephrase it; i was not generally asking why Wordfence failed detecting the IP, but rather why it failed only on XSS attacks while working fine with other login attemps.

Also was it a temporary bug of Let Wordfence use the most secure method to get visitor IP addresses option, that is now resolved or should I switch to Use the X-Real-IP HTTP header permanently due to having those websites hosted at Cloudways?

@wfphil

Hello,

Since you last reply was not answering my previous question but rather looked like a canned response, I was not sure how to consider it. However it seems XSS attacks have ended.

@wfdave

All good, I checked the logs and the cache isue was a separate, concurred issue. The lockout was due to logging-in using a missing user name. All good.

@wfdave

I sent the email to login, my point is that cache issue triggered this error, I entered 1 wrong 2FA and was loked out already?

Hi @wfdave,

I think it had to do with some cache issue:

https://share.creoweb.it/e1d20e12.jpg

This error is showing server wide while logging in and/or updating plug-ins I did not use all my login attemp as password is saved in the browser, perhaps I entered a wrong 2FA (external plug-in) once but should have triggered a warning not locking me out already.

@mindctrl,

Hi John,

In text regulation you will not find a direct mention of checkboxes, it is more broad.

However it says multiple times (and authority confirmed on phone) that the consent must be explicit and informed. This is translated into “user interaction required” (no default yes the checkbox for example) so that the user cannot say to have mistakenly (filled and) submitted a form, or not understood the real purpose (mailing) of it, even if the form consists of just one field and with clear reference to newsletter purpose.

If we don’t do this we are exposed to any random visitor to report us to the authority, and this will likely result in the above mentioned sanction. The same rule applies also to pop-up and other places where you can collect the data. You can look at my website which is fully GDPR compliant: https://www.kudosconsulting.it/ and to achieve this I had to manually customize the newsletter provider snippet.

While double opt-in helps to further make sure it is the actual mailbox owner to have requested the form submission; it is vital to have such mandatory checkbox in any submitted form that involves user data and especially sensible data such as mailbox and phone numbers.

• This reply was modified 5 years, 3 months ago by Syncly.it. Reason: typo, again

Hi @wfphil,

Do you have an idea on why only XSS and similar attacks are able to spoof their IP into 127.0.0.1 where normal brute force attacks doesnt?