Causing the website to stop pinging

Network access to my WordPress site is not reliable even after disabling the iptables with:

/etc/init.d/iptables stop

The site is hosted on a 1and1 dynamic cloud server.

When the server is rebooted, the firewall junk is enabled and somehow it is causing the website to stop pinging.
How can I turn off this firewall stuff permanently so the server reboots with nothing in the iptables?

Is it a wordpress plugin or some external hacker that's causing this firewall junk?

Can someone please help!

Thanks in advance

Paul

Are you saying that you can't ping the server and the site works, or that the site doesn't work?

Either way don't turn off iptables. What are the current rules? If you're not sure you can use iptables-save.

The site works and the server doesn't respond to pings. The ISP says my firewall is causing the server to stop pinging. I don't know what is causing these firewall settings that I did not setup. That's why I want to turn off these firewall settings. I entered the following 2 commands

/etc/init.d/iptables stop
service iptables save

The firewall rules were cleared up. But when I rebooted the server the firewall rules came back. I copied some of the firewall settings below. It feels like someone has hacked my site. I don't even know what these firewall settings mean.

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
REJECT tcp -- anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN reject-with tcp-reset
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:8447
ACCEPT tcp -- anywhere anywhere tcp dpt:12443
ACCEPT tcp -- anywhere anywhere tcp dpt:11443
ACCEPT tcp -- anywhere anywhere tcp dpt:11444

Not responding to pings is perfectly fine. It's more secure that way.
Is there any reason you want to make it respond?

A WordPress plugin would not have the access level required to change firewall settings.

An external hacker would not bother configuring your Firewall for you.

iptables reloads the rules from its config file every time you reboot. Those rules exist because whoever set up the server image originally configured it with those rules. Just running a save on iptables doesn't change anything because you didn't actually remove any of the rules.

Messing around with iptables when you don't understand it is dangerous. It is not difficult to accidentally block yourself from connecting via SSH, and recovering a remote server that you cannot connect to is not usually simple.

If the rules are not causing any actual problems, I wouldn't mess around with it.

If they are causing problems, someone can help you add a new rule that allows pings. You should not disable iptables completely because firewalls serve a very important purpose in protecting your server.

If you are making money off your site, it sounds like you need to hire a sysadmin. If you're not, you might want to become friends with one or switch to shared or managed hosting.

The site is not accessible to any visitors. People will think the website is down because their requests time out. Sometimes the site is up and sometimes it's down.

Pinging was just a simple test to confirm the site was up. Maybe it wasn't a great test. But when the site becomes inaccessible, I can't even login using a secure shell. Only a remote console utility provided by 1and1 lets me login to run iptables -L.

It all started about 5 days ago with an email I received about Googlebot not getting access to the site. Two days later, the site was down. After many phone calls to 1and1 dedicated server support, they recommend I don't implement the firewall. The problem is I didn't consciously implement any firewall. My attempts to disable the iptable settings (/etc/init.d/iptables stop) are not effective after I reboot the server.

Since any changes I make do not take effect after a server reboot, I don't know what to do.

Thank you for your responses.

Then why did you just say


Ping is one way to check if the box is at all accessible, provided iptables doesn't drop the packets. According to what I have here at home, the command you need is

When this problem is solved you should go back to dropping them.

Another more obvious test is trying to connect to it on port 80. If you can then there's probably something wrong with the site itself, and if not then you've started narrowing it down.

Also, if they told you to not use a firewall then that's horrible advice. If they told you to disable it while troubleshooting, that's still not great but it's okay temporarily.

Sorry if I miscommunicated the problem.

Somehow, the iptables were setup with some firewall rules. I never setup any firewall. Maybe some hacker planted this into my virtual machine. Bottom line is the website is not accessible to visitors.

The ISP company acknowledged the strange behavior and offered to move the virtual machine to a more up-to-date hosting server. I'm using their cloud computing service and will have to endure the down-time.

Thanks for your input. I'll also look for a service administrator.

Unless there were weird rules in there, probably not. Likely the ISP did it, or used a version of the operating system that included those rules, or used a packaged version like that, or something that's probably not hackers.

We can help a lot more if we can see those iptables rules.