iThemes rewriting .htaccess rewrites?

Take a look at Wordfence it does not write out to the .htaccess file the same say iThemes Security does.

https://www.ads-software.com/plugins/wordfence/

Hey @bhammondcvl,
iThemes Security uses comments in the htaccess as delimiters and only writes content inside of those (essentially remove the content from open to close delimiter and then writing new, when the situation calls for it).

# BEGIN iThemes Security - Do not modify or remove this line
...
# END iThemes Security - Do not modify or remove this line

Make sure that both those lines are there just in case, and check for duplicated (I had someone the other day that had copy/pasted some things in their file and ended up with several of the “# BEGIN” tags and only one end tag, and it was messing things up — although not rewriting the WordPress rules)

Thanks for your replies. We have not been able to pin down the source of the problem. The best we can come up with is that perhaps Bluehost is rewriting the htaccess file in a misguided attempt to “correct” some non-standard rewrite rules. We’ve moved some files around so our rewrites can be plain vanilla, and since then haven’t had any more problems.

i have had the same issue, and i tracked it down to the
“Banned Users” feature.

It was causing our .htaccess file to go over 1.6MB, and it was erasing ALL other rules (not security) > breaking websites. 4x this happened and the same issue every time (1 week ago at regular daily intervals).

we are running Multisite (100+) on Amazon EC2 with 2GB RAM for WP, and 2GB RAM for DB.

We disabled the “Banned Users” feature and we have not had this issue again, and the .htaccess file is back down to 18KB from 1.6MB.

maybe store the banned IPs in an external file so it is not in such an important file that can break websites

@slavo7 – The banned users go into the .htaccess file (or nginx.conf if you run nginx) because anything else would cause the entire WordPress stack to load before we could block a user. That’s extremely memory intensive, especially when the site is user active attack. Blocking at the server level can help a site stay up during attacks like that.

Having said that, I have never seen someone’s .htaccess get that large from this feature. I just ran some tests, and I had to ban 7,000 IPs to get my .htaccess up to 1.6m (from the 4k is was at). Those were all individual IPs, banning ranges takes up far less space in the htaccess. Even so, my site continued to function normally even with an htaccess of that size.

Since IPs are re-issued to new people all the time, banned IPs should only be banned for a while, then cleared from the list. If you’re collecting in the neighborhood of 7,000 banned IPs there might be something else going wrong.

Here is the huge htaccess file 1.6MB.
https://www.dropbox.com/s/mt02cp75066mn84/htaccess_1.6?dl=0
well that is what the plugin did when i had the banned users feature turned on, and did not monitor it.

maybe add some feature that deletes old IPs?
that install is a Multisite, and we do get a lot of attempts to login.

and another issue i had is that the code block are repeated.
# END iThemes Security – Do not modify or remove this line
# BEGIN iThemes Security –
xxx
# END iThemes Security – Do not modify or remove this line
# BEGIN iThemes Security –
https://www.dropbox.com/s/v6o7c6jo9an1ael/htaccess_repeating-blocks?dl=0

is that normal?
it still does it in our current .htaccess

Should i start fresh?