Archives

Most used wp-cli commands

Probably the most used wp-cli commands are the core, plugin, theme. We will discuss a little each one of them. Before running any wp-cli commands be sure to switch to the right directory:
cd /home/wp_directory

1. wp core – it installs, updates and manages a WordPress installation.
– to download the installation package
wp core download --locale=en_US

– to create the wp-config.php file needed for the installation process
wp config create --dbname=database_name --dbuser=wp_username --dbpass=wp_password

– to install WordPress
wp core install --url=domain.com --title=Example --admin_user=supervisor --admin_password=strongpassword --admin_email=name@domain.com

– to check if an update is available:
wp core check-update

-to update to the latest version:
wp core update

2. wp plugin – manages plugins
– to activate a plugin
wp plugin activate plugin-name

– to deactivate a plugin
wp plugin deactivate plugin-name

– to delete a plugin
wp plugin delete plugin-name

– to install and activate a plugin
wp plugin install plugin-name --activate

– to list all plugins
wp plugin list

– to update all plugins
wp plugin update --all

3. wp theme – manages themes
– to install the latest version of a theme and activate it
wp theme install twentynineteen --activate

– to activate a theme already installed
wp theme activate twentynineteen

– to get a list of the installed themes
wp theme list

– to update all the themes installed
wp theme update --all

Related articles:
How to install wp-cli on your server

References:
WP-CLI Commands

Share this post:

How to install wp-cli on your server

WP-CLI is a command-line interface for WordPress.  Through it, you can manage your installations from the command line.

Official requirements you should check prior to installing WP-CLI:

– UNIX-like environment (OS X, Linux, FreeBSD, Cygwin); limited support in Windows environment
– PHP 5.4 or later
– WordPress 3.7 or later. Versions older than the latest WordPress release may have degraded functionality

The first thing we must do is to download the wp-cli phar file. As root, use the command:
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

root@web [/]# curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5294k 100 5294k 0 0 8635k 0 --:--:-- --:--:-- --:--:-- 8637k
root@web [/]#

Now, let’s check the phar file is in good condition and to get some info about the wp-cli. Use:
php wp-cli.phar --info

root@web [/]# php wp-cli.phar --info
OS: Linux 2.6.32-042stab134.3 #1 SMP Sun Oct 14 12:26:01 MSK 2018 x86_64
Shell: /bin/bash
PHP binary: /opt/cpanel/ea-php73/root/usr/bin/php
PHP version: 7.3.4
php.ini used: /opt/cpanel/ea-php73/root/etc/php.ini
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.1.0
root@web [/]#

We want to use the wp-cli tool with the “wp” command so let’s run the commands:
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

The first command makes the file executable, the second one moves it to /usr/loca/bin/wp folder.

Everything is done now, let’s test it. Use:
wp --info

root@web [/]# wp --info
OS: Linux 2.6.32-042stab134.3 #1 SMP Sun Oct 14 12:26:01 MSK 2018 x86_64
Shell: /bin/bash
PHP binary: /opt/cpanel/ea-php73/root/usr/bin/php
PHP version: 7.3.4
php.ini used: /opt/cpanel/ea-php73/root/etc/php.ini
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.1.0
root@web [/]#

If you are running cPanel on the server, the wp-cli tool is already installed in /usr/local/cpanel/3rdparty/bin/wp. Many times, 3rd party apps are not updated frequently, so you may want to install wp-cli manually, as described above.

 

To update the wp-cli tool, use:
wp cli update

root@web [/]# wp cli update
Success: WP-CLI is at the latest version.
root@web [/]#

Thank you.

Related articles:
Most used wp-cli commands

Resources:
https://wp-cli.org/
https://wp-cli.org/#installing

Share this post:

The mysql_upgrade command [MySQL/MariaDB]

It is recommended to run this command every time to update your MySQL/MariaDB from one major release to another. For example when upgrading from MySQL 5.7 to MySQL 8; MariaDB 10 to MariaDB 11. It checks all the databases(with all the tables) for any incompatibilities. It also updates the system tables with new privileges or options that might have been added in the new version.

The command with options is:

mysql_upgrade [--force] [--user=# --password
--host=hostname --port=# --socket=#
--protocol=tcp|socket|pipe|memory
--verbose] OTHER_OPTIONS]

Simply run the command in shell:

root@www [/home]# mysql_upgrade

References:

https://mariadb.com/kb/en/library/mysql_upgrade/

https://dev.mysql.com/doc/refman/8.0/en/mysql-upgrade.html

Share this post:

Scan your server for PHP malware with findcrack0r.pl

The tool that we will present here is a regex-based PHP malware scanner (written in Perl). It will scan your server for PHP malicious files. In addition to cxs and maldet (links at the end of this post), this tool is very useful for ensuring your server security.

1. So, first of all, download the latest script version from https://repo.coydogsoftware.net/coydog/rxtools/blob/master/findcrack0r.pl and save it to your server.

2. Now, that you saved the script to your server, just run it with:

perl findcrack0r.pl -po /home -t $(date +%Y-%m-%d)

The command we use will scan the /home directory (including all subdirectories) only for *.php file. The script will create a directory with the current date in /home/root/support/ (like /home/root/support/2018-07-18). In this directory, the script will create two files – one for suspicious malware PHP files, the other one for the symlinks founded:

root@www [~/support/2018-07-18]# ls
./  ../  scan-20180718234534.txt  symlinks-20180718234534.txt
root@www [~/support/2018-07-18]#

 

You should adjust the command line per your needs. See below the script’s input options. You might also need to enter the full Perl path.

 

root@www [/]# perl findcrack0r.pl -h
Usage:
  -t    ticket number for output dir
  -a  account list, comma-delimited. Will search only public_html
  -b     Number of bytes per file to scan. Default is 500000
  -p    restrict searches to *.php (faster but may miss stuff)
  -S    Skip checking symlinks
  -d    grep for defacements
  -o    other directories to search, independently of -a docroots. May be needed for addon/subdomains
  -u    user homedir prefix (default /home)
  -D    Debug mode. Output a more detailed log which identifies signature matches.
  -N    Show files which do NOT match on stderr (debug feature only)
  -e       exclude files wth names ending in . Workaround if scan hangs on js
  -r    regex debugging
  -c    use cache
  -q    quiet
  -h    print this help message and quit
root@www [/]#
Please notice that the script will report many ionCube PHP encrypted files. Double-check them (and all other files) before taking any action, as they might be legit files. Make backups before deleting any files!
 
 
The script file as of July 19, 2018 – just for information –  findcrack0r.txt – download the latest version from the developer site!
 

Other security tools for your server:
https://configserver.com/cp/cxs.html
https://www.rfxn.com/projects/linux-malware-detect/

Related post: Disable dangerous PHP functions on your web hosting server

Share this post:

Secure SSH with Google Authenticator Two-Factor Authentication on CentOS

It’s a good idea to secure the SSH login with a two-factor authentication method. We will show in this article how to secure SSH with Google Authenticator.

Steps:

  1. Install the Google Authenticator from Google Play
    google authenticator 1

     

  2. Install the Google Authenticator module:
    [root@cwp1 ~]# yum install google-authenticator
    Loaded plugins: fastestmirror
    Loading mirror speeds from cached hostfile
     * base: mirror.sesp.northwestern.edu
     * epel: mirror.beyondhosting.net
     * extras: bay.uchicago.edu
     * updates: mirror.math.princeton.edu
    Resolving Dependencies
    --> Running transaction check
    ---> Package google-authenticator.x86_64 0:1.04-1.el7 will be installed
    --> Finished Dependency Resolution
    
    Dependencies Resolved
    
    ========================================================================================================================
     Package                               Arch                    Version                      Repository             Size
    ========================================================================================================================
    Installing:
     google-authenticator                  x86_64                  1.04-1.el7                   epel                   48 k
    
    Transaction Summary
    ========================================================================================================================
    Install  1 Package
    
    Total download size: 48 k
    Installed size: 97 k
    Is this ok [y/d/N]: y
    Downloading packages:
    google-authenticator-1.04-1.el7.x86_64.rpm                                                       |  48 kB  00:00:00
    Running transaction check
    Running transaction test
    Transaction test succeeded
    Running transaction
      Installing : google-authenticator-1.04-1.el7.x86_64                                                               1/1
      Verifying  : google-authenticator-1.04-1.el7.x86_64                                                               1/1
    
    Installed:
      google-authenticator.x86_64 0:1.04-1.el7
    
    Complete!
    [root@cwp1 ~]#
    

     

  3. To configure the google-authenticator module use the google-authenticator command. Read the questions and ask according to your needs:
    [root@cwp1 ~]# google-authenticator
    
    Do you want authentication tokens to be time-based (y/n) y
    Warning: pasting the following URL into your browser exposes the OTP secret to Google:
      https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/root@cwp1%3Fsecret%3DC5ZIEY5TTOX3UNJXESKISMF2GQ%26issuer%3Dcwp1
    ssh qr code
    Your new secret key is: C5ZIEY5TTOX3UNJXESKISMF2GQ
    Your verification code is 604902
    Your emergency scratch codes are:
      92416476
      84187850
      96774355
      80714386
      19340003
    
    Do you want me to update your "/root/.google_authenticator" file? (y/n) y
    
    Do you want to disallow multiple uses of the same authentication
    token? This restricts you to one login about every 30s, but it increases
    your chances to notice or even prevent man-in-the-middle attacks (y/n) y
    
    By default, a new token is generated every 30 seconds by the mobile app.
    In order to compensate for possible time-skew between the client and the server,
    we allow an extra token before and after the current time. This allows for a
    time skew of up to 30 seconds between authentication server and client. If you
    experience problems with poor time synchronization, you can increase the window
    from its default size of 3 permitted codes (one previous code, the current
    code, the next code) to 17 permitted codes (the 8 previous codes, the current
    code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
    between client and server.
    Do you want to do so? (y/n) n
    
    If the computer that you are logging into isn't hardened against brute-force
    login attempts, you can enable rate-limiting for the authentication module.
    By default, this limits attackers to no more than 3 login attempts every 30s.
    Do you want to enable rate-limiting? (y/n) y
    [root@cwp1 ~]#
    

     

  4. Scan the QR code with the Google Authenticator app from your phone:
    google authenticator 2 
  5. Your root@server-name account will be added to Google Authenticator
    google authenticator 3 
  6. Now let’s configure PAM. Edit the file /etc/pam.d/sshd
    [root@cwp1 ~]# nano /etc/pam.d/sshd
    

    And add the line:

    auth required pam_google_authenticator.so
    

    So the top of the file looks like:

    #%PAM-1.0
    auth required pam_google_authenticator.so
    auth       required     pam_sepermit.so
    auth       substack     password-auth
    auth       include      postlogin
    

     

  7. Now we must instruct OpenSSH to permit two-factor authentications. Open the file /etc/ssh/sshd_config :
    [root@cwp1 ~]# nano /etc/ssh/sshd_config
    

    Add the line (or comment out the line if it already exists):

    ChallengeResponseAuthentication yes

     

  8. Restart the sshd server:
    [root@cwp1 ~]# service sshd restart
    Redirecting to /bin/systemctl restart  sshd.service
    [root@cwp1 ~]#
    
    Do NOT close the current SSH connection. Open another SSH connection and check if you are able to connect with the two-factor authentication. If you can’t connect, investigate the cause by checking the SSH log file – /var/log/secure . If you can’t fix the issue, undo the actions from 6.(editing the file /etc/pam.d/sshd) and 7.(editing the file /etc/ssh/sshd_config) to be able to connect only with the password.
  9. Everything is set up at this moment. On the next logins, the system will ask for the verification code.

Related KB articles:
How to install nano editor with yum
Change the default SSH server port number

Share this post:
Page 1 of 4
1 2 3 4