After installing the latest ISO, then upgrading to php7, then installing wordpress, I can not turn off Ping. I've tried the firewallIPtables/proc/sys/net/ipv4/icmp_echo_ignore_all '1'-A ufw-before-input -p icmp --icmp-type echo-request -j DROPand still able to Ping... any thoughts?

Every installation .iso has a version (X.X.X). The word "Latest" does not supply this information.

Later, when a new installer has been released, the next person to see this post won't know you didn't mean "latest" for them, they'll think "8.4.2" or whatever the latest is at the moment they are reading it.

Had you supplied the installer you used, I'd be typing instructions right now ...

I know it should, but can still be pinged... I know it's odd.. I'm thinking the process of upgrading to php7 then installing wordpress did something to overwrite the firewall settings? Or make it so the Ping settings in the firewall are ignored? The whitelisted IPs for all unopened ports still works.

uselessinfoguru wrote:I know it should, but can still be pinged... I know it's odd.. I'm thinking the process of upgrading to php7 then installing wordpress did something to overwrite the firewall settings? Or make it so the Ping settings in the firewall are ignored? The whitelisted IPs for all unopened ports still works.

I've tried tunneling then pinging and it's still pingable, but great question lol. My tunneling program may only affect web browsers, not other programs, I should look into that. I was using tunnelbear.

Likely. Take one of your sites off the Good list and use putty to ping after using putty to ssh to that location. Then you're using another server that should NOT have access to ping the server in question.

you are not very good at copy and paste. I wrote iptables-save and you wrote iptables -save instead of using your copy-paste skills. This is a bad habit, I think. Especially if you don't see the difference between those two.

I also think you tried to apply 'common sense' to 'linux'. Another bad habit.

## Type: yesno## Allow hosts in the dmz to be pinged from hosts in other zones even# if neither FW_FORWARD nor FW_MASQUERADE is set## Requires: FW_ROUTE## defaults to "no" if not set#FW_ALLOW_PING_DMZ=""

## Type: yesno## Allow hosts in the external zone to be pinged from hosts in other# zones even if neither FW_FORWARD nor FW_MASQUERADE is set## Requires: FW_ROUTE## defaults to "no" if not set#FW_ALLOW_PING_EXT="no"

## Type: yesno## Allow ICMP sourcequench from your ISP?## If set to yes, the firewall will notice when connection is choking, however# this opens yourself to a denial of service attack. Choose your poison.## Defaults to "yes" if not set#FW_ALLOW_FW_SOURCEQUENCH="no"

Do note that if this server is on a private network, it's likely your router responding to ping. IE: If your server is in DMZ of a private network, the router is passing all traffic to the server, but not Really ... some decisions are still made by the router (like ... ping).

Live and learn. If the script kiddies get wind that your server is available on the net, you'll get more and more attempts. Ping of death (DDoS from Ping overload) is not prevalent, but there are a lot more kiddies out there who share IP addresses and then all check for openings. Regularly. If they find so much as a single login page to attempt, you'll have a party eventually. If you lock out fails: Eventually you'll have multiple rotating IP attacks, too. That gets annoying after a while, especially if they raise the bar and hit you so hard from enough IPs that you end up with DDoS again (it'll feel like that anyway, even though it's just Brute Force password hackers).

Whitelist, my friend: Whitelist.

But by all means, don't take my word for it. Leave 80 open and let us know how long it goes before you get annoyed enough to close it. Always interested in hearing how long it takes these days, even if it's different for everyone ... every vote counts.

I'll keep you updated lol, so far, nothing, oh the web directories are whitelisted, btw, through http.d so, the only access outside our internal network is to the wordpress website. All other web directories throw a 403 error.

uselessinfoguru wrote:I'll keep you updated lol, so far, nothing, oh the web directories are whitelisted, btw, through http.d so, the only access outside our internal network is to the wordpress website. All other web directories throw a 403 error.

Put the wordpress on the cloud. Those are some cheap servers and a DOS attack there won't affect dialing.

Be sure to password protect the admin folder on wordpress using the appropriate apache module. It's an attack vector. Same with phpMyAdmin. If you check your logs, both should have plenty of traffic that has nothing to do with actual humans browsing.

iftop shows "right now". So if you aren't being actively attacked, it will show nothing. Your iptables configuration, however, may have some system or firewall logging in effect to show dropped packets. Those have been know to show "2AM brute force attacks" that end before you open in the morning.

Apache logs (and error logs) have been known to be quite useful in this regard as well.

In any event: Good luck. Report back if/when you get an attack with how long you went without one. Good to know.

dspaan wrote:Don't install Wordpress on a vicidial machine, it's just asking for trouble. And no benefit.

Also, use Wordfence. You'll be amazed to see how many attacks your website is getting.

Concur, except we use All In One WP Security & Firewall which is free. We live and work in the Open Source Free world. I'm opposed to paying for the software or the service and most especially "licensing" fees.

What do you mean by that, exactly? Nobody has broken in, or there have been no attempts?

Cuz if you have NO attempts, it's not going to be this module. If you have NO successful hacks, beware of the empirical evidence trap. Just because you put your foot on the brake pedal 8500 times over 5 years doesn't mean try number 8501 will be successful.

We've never had a successful breakin either, and that includes before we added the module (zero protection, naked wordpress). But it has been very helpful in identifying and locking out IPs and Subnets to avoid even allowing brute force attacks to happen. We put the security module in place because we know that Eventually a user will have a simple password and a brute force May Succeed.

Define "go nowhere"? Do they make an attempt to log in? Do they "GET" or "POST" to the login page? How about the xmlrpc login page?

If so, then you're in empirical territory. Cuz they make attempts that fail. They can make a million failed attempts (or more) before they get a success. They only need that one success.

So the goal is: If they make ONE attempt, they don't get a chance to make another. No brute force capability. In fact, if they make ONE attempt (and fail) against ONE site, they should be blocked from ALL sites from that moment forward. If they make one attempt from a dozen IPs in a single subnet, the entire subnet should be blocked to avoid rotating IP brute force attacks.

i hope you're basing this on the access log as well as the error log. since the error log would ONLY show failures, and completely ignore successes. it can be a big problem if you don't know about login attempts in the various wordpress, phpmyadmin, ssh, ftp locations. if left to continue guessing they can become problematic. lol

more importantly: if someone is looking for the /vicidial folder, you have a non-standard attacker. NOBODY looks for /vicidial on a wordpress system. vicidial attackers usually look for phpmyadmin or attempt port 5060 registrations or calls, they rarely bother with web logins at all. unless you have vicidial on the same server and the logs are combined, of course, you shouldn't even have the word vicidial in your apache logs. we don't have Vicidial on the same server as wordpress anywhere.