DDOS-атака на WordPress - решение проблемы CVE-2018-6389

На большинстве новостных порталов по веб-разработке и WordPress уже анонсировали DOS уязвимость во всех версиях WordPress ( CVE-2018-6389 ), при которой можно сравнительно небольшим числом запросов организовать атаку вида “отказ в обслуживании”.

То есть любой любознательный хулиган может с одного небольшого сервера или домашнего компьютера “положить” блог на WordPress, отправляя определенные запросы к одному из двух скриптов: wp-admin/load-scripts.php и wp-admin/load-styles.php. Проблема возникает в тот момент, когда WordPress пытается склеить большое число файлов в один общий (это такая оптимизация). Более подробно можно прочитать на сайте журнала “Хакер” или на The Hacker News .
В статье написано, что патча не существует и сам WordPress не считает данную проблему своей. Но это не значит, что проблему нельзя решить для своих блогов. Есть как минимум два варианта, как защитить WordPress сайт от данной атаки:

1. Ограничить доступ к скриптам через .htaccess файл.
   1. Ограничить доступ по IP, если у вас статический IP, разместив код в wp-admin/.htaccess
      
      <Files load-scripts.php>
      Deny from All
      Allow from 1.2.3.4
      </Files>
      <Files load-styles.php>
      Deny from All
      Allow from 1.2.3.4
      </Files>
   2. Ограничить доступ с помощью basic-авторизации, если у вас не статический IP.
      Причем, варианты а и можно лучше сделать сразу для всего каталога Например, код файла может выглядеть так (разместить в wp-admin/.htaccess)
      AuthType Basic
      AuthUserFile /home/……../wp-admin/.htpasswd
      require valid-user
      
      <Files admin-ajax.php>
      Satisfy Any
      Order Deny,Allow
      Allow from All
      <Files *.css>
      Satisfy Any
      Order Deny,Allow
      Allow from All
      </Files>
      <Files *.js>
      Satisfy Any
      Order Deny,Allow
      Allow from All
      </Files>
      
      Во второй строке нужно указать путь до .htpasswd файла с паролем от бейсик-авторизации. Сгенерировать логин/пароль для файла и хэш-строку можно, например, на нашем сайте https://revisium.com/tools/ht.php или с помощью утилиты командной строки https://httpd.apache.org/docs/2.4/programs/htpasswd.html .
      
2. Пропатчить исходники WordPress. Например, один из пользователей предлагает такой вариант (скрипт нужно запустить в корневом каталоге сайта в командной строке):
   https://github.com/Quitten/WordPress/blob/master/wp-dos-patch.sh
   

Вариант №1 более предпочтительный, так как он убивает сразу несколько зайцев, в частности, защищает админку от несанкционированного доступа за счет двухфакторной аутентификации. А вариант №2 потребует запуска скрипта после каждого обновления.
Есть еще пара экспериментальных и быстрых фиксов проблемы:

1. Добавить в wp-config.php константу
   define( 'CONCATENATE_SCRIPTS', false );
   Она отвечает за склейку файлов скриптов. При установленном значении false – отменяет данную возможность.
2. Добавить следующий код в корневой .htaccess файл (если у вас сервер Apache с поддержкой ModRewrite)
   
   RewriteEngine on
   RewriteCond %{HTTP_COOKIE} !wordpress_logged_in_
   RewriteRule /wp-admin/load-scripts.php - [F, L]
   RewriteCond %{HTTP_COOKIE} !wordpress_logged_in_
   RewriteRule /wp-admin/ load-styles.php - [F, L]
   

Последний вариант можно обойти, если атакующий выставит Cookie wordpress_logged_in_ в запросе. Но от ботов скорее всего защитит.
Если совсем никак не получается решить проблему самостоятельно, напишите нам, в рамках услуги “ Превентивная защита ” или “ Сайт под наблюдением ” надежно защитим сайт от взлома и веб-атак.