Turning off Ping after upgrades

[uselessinfoguru]

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

[williamconley]

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 ...

On some versions:

Code: Select all

/etc/sysconfig/SuSEfirewall2

change

Code: Select all

FW_ALLOW_PING_FW="no"

We also recommend:

Code: Select all

FW_ALLOW_FW_SOURCEQUENCH="no"

[uselessinfoguru]

Apologies, its ViciBox_v8.x86_64-8.0.1.iso I used to install, and yes both of those are set in SuSEfirewall2..
installation method Vicibox-install

[williamconley]

If you've restarted the firewall after those changes, ping should be off.

[uselessinfoguru]

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.

[williamconley]

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.

Just to be funny: Are you trying to ping from a whitelisted IP? lol

[uselessinfoguru]

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.

[williamconley]

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.

[uselessinfoguru]

Ping works... grr... lol, really don't want to rebuild, even tho it is only a single server

[williamconley]

Ping works... grr... lol

iptables-save

Post the results here. (remove anything you would find personally identifiable ... or change to xx.xx.xx.xx to represent IP addresses)

Also verify your GOOD file doesn't have the IP of the server that Pinged ...

[uselessinfoguru]

Code: Select all

WhateverIWant:~ # iptables --help
iptables v1.4.21

Usage: iptables -[ACD] chain rule-specification [options]
       iptables -I chain [rulenum] rule-specification [options]
       iptables -R chain rulenum rule-specification [options]
       iptables -D chain rulenum [options]
       iptables -[LS] [chain [rulenum]] [options]
       iptables -[FZ] [chain] [options]
       iptables -[NX] chain
       iptables -E old-chain-name new-chain-name
       iptables -P chain target [options]
       iptables -h (print this help information)

Commands:
Either long or short options are allowed.
  --append  -A chain            Append to chain
  --check   -C chain            Check for the existence of a rule
  --delete  -D chain            Delete matching rule from chain
  --delete  -D chain rulenum
                                Delete rule rulenum (1 = first) from chain
  --insert  -I chain [rulenum]
                                Insert in chain as rulenum (default 1=first)
  --replace -R chain rulenum
                                Replace rule rulenum (1 = first) in chain
  --list    -L [chain [rulenum]]
                                List the rules in a chain or all chains
  --list-rules -S [chain [rulenum]]
                                Print the rules in a chain or all chains
  --flush   -F [chain]          Delete all rules in  chain or all chains
  --zero    -Z [chain [rulenum]]
                                Zero counters in chain or all chains
  --new     -N chain            Create a new user-defined chain
  --delete-chain
            -X [chain]          Delete a user-defined chain
  --policy  -P chain target
                                Change policy on chain to target
  --rename-chain
            -E old-chain new-chain
                                Change chain name, (moving any references)
Options:
    --ipv4      -4              Nothing (line is ignored by ip6tables-restore)
    --ipv6      -6              Error (line is ignored by iptables-restore)
[!] --protocol  -p proto        protocol: by number or name, eg. `tcp'
[!] --source    -s address[/mask][...]
                                source specification
[!] --destination -d address[/mask][...]
                                destination specification
[!] --in-interface -i input name[+]
                                network interface name ([+] for wildcard)
 --jump -j target
                                target for rule (may load target extension)
  --goto      -g chain
                              jump to chain with no return
  --match       -m match
                                extended match (may load extension)
  --numeric     -n              numeric output of addresses and ports
[!] --out-interface -o output name[+]
                                network interface name ([+] for wildcard)
  --table       -t table        table to manipulate (default: `filter')
  --verbose     -v              verbose mode
  --wait        -w              wait for the xtables lock
  --line-numbers                print line numbers when listing
  --exact       -x              expand numbers (display exact values)
[!] --fragment  -f              match second or further fragments only
  --modprobe=<command>          try to insert modules using this command
  --set-counters PKTS BYTES     set the counter during insert/append
[!] --version   -V              print package version.
WhateverIWant:~ # iptables -save
iptables v1.4.21: no command specified
Try `iptables -h' or 'iptables --help' for more information.



[uselessinfoguru]

I do have all http directories whitelisted through httpd.conf that I wish 403 errored on port 80 and 81, and have all other ports closed to non-firewall whitelisted

[williamconley]

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.

[uselessinfoguru]

deleted12345

[uselessinfoguru]

lmao, you are 100% on all of that.

Code: Select all

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [234617:234538329]
:forward_ext - [0:0]
:input_ext - [0:0]
:reject_func - [0:0]
-A INPUT -m set --match-set geoblock src -j DROP
-A INPUT -m set --match-set badips src -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m conntrack --ctstate RELATED -j ACCEPT
-A INPUT -j input_ext
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-IN-ILL-TARGET " --log-tcp-options --log-ip-options
-A INPUT -j DROP
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "SFW2-FWD-ILL-ROUTING " --log-tcp-options --log-ip-options
-A OUTPUT -o lo -j ACCEPT
-A input_ext -m pkttype --pkt-type broadcast -j DROP
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options
-A input_ext -p tcp -m tcp --dport 80 -j ACCEPT
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 81 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options
-A input_ext -p tcp -m tcp --dport 81 -j ACCEPT
-A input_ext -s xx.xx.xx.xx/32 -p tcp -m conntrack --ctstate NEW -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-ACC " --log-tcp-options --log-ip-options
-A input_ext -s xx.xx.xx.xx/32 -p tcp -j ACCEPT
-A input_ext -s xx.xx.xx.xx/32 -p udp -m conntrack --ctstate NEW -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-ACC " --log-tcp-options --log-ip-options
-A input_ext -s xx.xx.xx.xx/32 -p udp -j ACCEPT
-A input_ext -s 192.168.1.0/24 -p tcp -m conntrack --ctstate NEW -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-ACC " --log-tcp-options --log-ip-options
-A input_ext -s 192.168.1.0/24 -p tcp -j ACCEPT
-A input_ext -s 192.168.1.0/24 -p udp -m conntrack --ctstate NEW -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-ACC " --log-tcp-options --log-ip-options
-A input_ext -s 192.168.1.0/24 -p udp -j ACCEPT
-A input_ext -s xx.xx.xx.xx/32 -p tcp -m conntrack --ctstate NEW -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-ACC " --log-tcp-options --log-ip-options
-A input_ext -s xx.xx.xx.xx/32 -p tcp -j ACCEPT
-A input_ext -s xx.xx.xx.xx/32 -p udp -m conntrack --ctstate NEW -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-ACC " --log-tcp-options --log-ip-options
-A input_ext -s xx.xx.xx.xx/32 -p udp -j ACCEPT
-A input_ext -s xx.xx.xx.xx/32 -p tcp -m conntrack --ctstate NEW -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-ACC " --log-tcp-options --log-ip-options
-A input_ext -s xx.xx.xx.xx/32 -p tcp -j ACCEPT
-A input_ext -s xx.xx.xx.xx/32 -p udp -m conntrack --ctstate NEW -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-ACC " --log-tcp-options --log-ip-options
-A input_ext -s xx.xx.xx.xx/32 -p udp -j ACCEPT
-A input_ext -m comment --comment "sfw2.insert.pos" -m pkttype ! --pkt-type unicast -j DROP
-A input_ext -p tcp -m limit --limit 3/min -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options
-A input_ext -p icmp -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options
-A input_ext -p udp -m limit --limit 3/min -m conntrack --ctstate NEW -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options
-A input_ext -j DROP
-A reject_func -p tcp -j REJECT --reject-with tcp-reset
-A reject_func -p udp -j REJECT --reject-with icmp-port-unreachable
-A reject_func -j REJECT --reject-with icmp-proto-unreachable
COMMIT


and from SuSEfirewall2

Code: Select all

# defaults to "yes" if not set
#
FW_ALLOW_PING_FW="no"

## 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"


[williamconley]

Turning off ping won't help much. You have port 80 open to the world.

Code: Select all

-A input_ext -p tcp -m tcp --dport 80 -j ACCEPT

Otherwise I don't see anything that would accept a ping packet except these if the source in question already has a connection:

Code: Select all

-A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m conntrack --ctstate RELATED -j ACCEPT

Consider removing

Code: Select all

-A INPUT -j input_ext

Temporarily (at the cli instead of configuration) with:

Code: Select all

iptables -D INPUT -j input_ext

To confirm that the problem is in the base INPUT chain. Then remove the ESTABLISHED and RELATED entries.

Of course, you can only do this if directly at the server's kbd or you'll lose contact (unless you add your own IP in the INPUT chain before you begin).

[uselessinfoguru]

TY! I will try this when I'm at the server.

[williamconley]

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).

[uselessinfoguru]

Good call Will, router is controlling ping, which never gets to the server unless connection is already established.

[uselessinfoguru]

And as Ping of death isn't the concern it was in the 90s and I have ports 80 and 81 open I suppose it doesn't really matter, I can control access very well through http.d config.

[williamconley]

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.

[uselessinfoguru]

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.

[williamconley]

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.

[uselessinfoguru]

ran iftop
It's showing no connections that shouldn't be there. Seems pretty secure regardless of port 80 being open.

[williamconley]

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]

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.

[williamconley]

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.

https://www.tipsandtricks-hq.com/wordpr ... all-plugin

[dspaan]

Wordfence is free too.

[williamconley]

lol: I looked at their site and it didn't mention the free option(s).

They also apparently have 30% more installs than AOIWPS and more reviews. Both, however have almost all 5 star review (which is impressive, actually).

I may try yours on a few honey pot sites and see how it behaves.

[uselessinfoguru]

Still going, vicidial/php7/wordpress integrated. 0 hackers. ports 80-81 open

[williamconley]

0 hackers

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.

[uselessinfoguru]

0 successful, China, Russia, India, especially India, I see the attempts, but they go no where.

[williamconley]

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.

Food for thought.

We have some nice honeypot sites for just such an occasion.

[uselessinfoguru]

The attempts are not making it to any login pages.
They simply check out every page of the website, can not get to /wp-admin, can not get to /phpMyAdmin, can not get to /vicidial ... they leave.

[williamconley]

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.