Newman
Member
- Joined
- May 11, 2021
- Messages
- 106
- Reaction Score
- 0
- Points
- 23
- #1
I just wanted to get this out there, just in case anyone else experiences the same set of events that I did this morning. Okay, yesterday or the day before, I was attempting to update a few of the widgets I have installed on some forum software I’m running on one of my domains. I actually have quite a few installations of this forum software on multiple domains, but I’ve never encountered this type of situation on them. I’ve experienced 503 error codes, but never a 403. Here’s what happened.
As I was pasting some ad serving code into a widget to display on the website, I received an error that told me the page couldn’t continue loading. I wondered why this was and then I remember back to the same thing happening on one of my other domains. This typically happens when suspicious looking code, such as ad serving code, tries to get uploaded to a website. Firewalls don’t like this at all and stop it from happening. The last time this occurred, I placed a support ticket with my host and told them my IP address. They looked at the log files, found the mod_security rule that was triggered and then whitelisted that rule. This was back when I was getting 503 errors. Since this error seemed familiar to me, I went ahead and submitted a new ticket, telling the host the same information as last time. The strange thing is, this time, the host replied informing me that no firewall rules were triggered on the server. “That’s strange,” I thought. So I logged into the server and I turned Apache’s (I think) mod_security function off in cPanel. I attempted to upload the code once more to no avail.
Okay, that didn’t work. It was time to move onto the next best guess of what was causing me issues. I turned mod_security back on and looked at Cloudflare. I have my sites running through that and they have their own firewall. I turned that off too. Nothing. The problem persisted. Okay, moving on.
I then submitted a support ticket with the forum software developer and asked them if my issue sounded familiar. Unfortunately, it didn’t, so they couldn’t help. I was ready to give up, when I decided to look at the error page in Google Chrome’s console. I saw the title and that said, “403 Forbidden,” which was nothing new. I then continued to scroll down the page when I finally found the culprit. I saw a line that read, “Something, something, something Wordfence.” Ah ha! I recently installed Wordfence security software for WordPress and have been letting it run for some time now. I assumed that it only protected the blog software and was surprised to see that it protected the entire domain. I went into Wordfence and turned off the firewall. Then, I tried to install that ad serving code once more and bam, it worked perfectly. So now I know that I have three firewalls running. One on the server itself, one at Cloudflare and one from Wordfence. Of course, when I was finished uploading the code, I turned the firewall back on.
So what’s the moral of this story? When you’re receiving 403 and 503 Forbidden error codes on your website, think about how many firewalls you have running. Then, check each one of them to see if one could be the problem. Or, you can read the page in the console all the way through, like I should have from the beginning. Lesson learned.
As I was pasting some ad serving code into a widget to display on the website, I received an error that told me the page couldn’t continue loading. I wondered why this was and then I remember back to the same thing happening on one of my other domains. This typically happens when suspicious looking code, such as ad serving code, tries to get uploaded to a website. Firewalls don’t like this at all and stop it from happening. The last time this occurred, I placed a support ticket with my host and told them my IP address. They looked at the log files, found the mod_security rule that was triggered and then whitelisted that rule. This was back when I was getting 503 errors. Since this error seemed familiar to me, I went ahead and submitted a new ticket, telling the host the same information as last time. The strange thing is, this time, the host replied informing me that no firewall rules were triggered on the server. “That’s strange,” I thought. So I logged into the server and I turned Apache’s (I think) mod_security function off in cPanel. I attempted to upload the code once more to no avail.
Okay, that didn’t work. It was time to move onto the next best guess of what was causing me issues. I turned mod_security back on and looked at Cloudflare. I have my sites running through that and they have their own firewall. I turned that off too. Nothing. The problem persisted. Okay, moving on.
I then submitted a support ticket with the forum software developer and asked them if my issue sounded familiar. Unfortunately, it didn’t, so they couldn’t help. I was ready to give up, when I decided to look at the error page in Google Chrome’s console. I saw the title and that said, “403 Forbidden,” which was nothing new. I then continued to scroll down the page when I finally found the culprit. I saw a line that read, “Something, something, something Wordfence.” Ah ha! I recently installed Wordfence security software for WordPress and have been letting it run for some time now. I assumed that it only protected the blog software and was surprised to see that it protected the entire domain. I went into Wordfence and turned off the firewall. Then, I tried to install that ad serving code once more and bam, it worked perfectly. So now I know that I have three firewalls running. One on the server itself, one at Cloudflare and one from Wordfence. Of course, when I was finished uploading the code, I turned the firewall back on.
So what’s the moral of this story? When you’re receiving 403 and 503 Forbidden error codes on your website, think about how many firewalls you have running. Then, check each one of them to see if one could be the problem. Or, you can read the page in the console all the way through, like I should have from the beginning. Lesson learned.