Gdriveの変更を確認しslackへ通知するbotを利用した話
概要
Gdriveの変更をGAS(Google Apps Script)から確認し、Webhookを用いてSlackへ通知するbotを利用した。
目次
背景
私の学校では週次で時間割がデータで配布される。配布された時間割は同クラスのslackへクラスメイトの誰かが転送(スクショやデータのDLを経由)していた。
配布手段は以前までメールであったが、最近からGdriveに変更になった。しかし、毎度毎度Gdriveへ時間割を確認しに行って転送したりというのも面倒なので、解決手段を探ることとした。
大まかな前提
実現した方法
↑こちらの記事様(超ありがたい)を参考にした。
Webhookは利用したことがあったため、動作確認を省略したが、同記事にWebhookの利用方法へのリンクが記載されていた。
しかしGASの利用手順は解説されていなかったのでここに記そうと思う。
GAS利用手順
GASの利用手順としては、
- https://gsuite.google.com/marketplace/?hl=jaに行く。
- https://gsuite.google.com/marketplace/?hl=jaで「Google Apps Script」を検索し、インストールする。
- 新しいタブを開き、画面右上にアイコンで表示された「Google アプリ」を開き、「Google Apps Script」をクリックする。
- 「Start Scripting」を選択しスクリプトを書ける状態にする。
- ダッシュボードから新規スクリプトを選択し、上記の記事から適宜改変しつつコピペする
- 5で作成したスクリプトのトリガーを設定する。
で利用できた。
1 https://gsuite.google.com/marketplace/?hl=jaに行く。
↓このような画面が表示される。
2 https://gsuite.google.com/marketplace/?hl=jaで「Google Apps Script」を検索し、インストールする。
↓スペースがないと検索にヒットしないため、注意が必要。
↓Google Apps Script
3 新しいタブを開き、画面右上にアイコンで表示された「Google アプリ」を開き、「Google Apps Script」をクリックする。
↓ もっと見るを押す
↓ 新しく追加されている「Google Apps Script」を選択する
4 「Start Scripting」を選択しスクリプトを書ける状態にする。
↓ Start Scriptを選択する
5 ダッシュボードから新規スクリプトを選択し、上記の記事から適宜改変しつつコピペする。
↓「新規スクリプト」を選択する
↓ 注意として、プロジェクト名、ファイル名は何でも良いが、functionの順番はupdateMissionSheetList()を上にする。作成後は保存しておく。
6 5で作成したスクリプトのトリガーを設定する。
↓ ダッシュボードからトリガーを設定したいスクリプトの右側にある点のアイコンを選択する。
↓選択したスクリプトのドロップダウンメニューから「トリガー」を選択する。
↓トリガーを追加を選択する
↓トリガーの条件を選択する
↓上と同じくトリガーの条件を選択し、最後に保存を選択する。
↓ 保存が完了されると新しく追加したトリガーを確認することができる。
課題
私の環境が原因かもしれないが、slackへURLが送信された際にプレビュー表示がされない。
まとめ
概ねやりたいことは実現できたので、暇があれば課題の解決にはあたろうと思う。 なにより都度確認しに行く手間が省けたのは今後の負担が減ると思うので嬉しい。 感謝です。
主に参考になった記事様
CentOSで複数ユーザのパスワードを一括で変更する方法。
概要
動作確認できたバージョン
・CentOS7.4.1708
前準備
16行目あたりに対象としたいユーザ分、
username=("${username[@]}" "追加したいユーザ名")
userpass=("${userpass[@]}" "追加したいユーザの新しいパスワード")
のコードを追加する。
実行手順
$ su -で管理者ユーザになる。
# vi pwResetCentOS.shを実行し、下記のコードをコピペ、保存する。
# chmod +x pwResetCentOS.shで実行権限を与える。
# ./pwResetCentOS.shでスクリプトを実行。
# rm pwResetCentOS.shでスクリプトを削除。
パスワードが変更されていることを確認する。
※変更されていない場合はpasswdコマンドを使用し、自力でパスワードを変更する。
pwResetCentOS.shの内容
#!/bin/sh
# -*- coding: utf-8 -*-
# This code run for CentOS7
# Operation checked with CentOS Linux release 7.4.1708 (core)
#Create for array target users
username=()
userpass=()
# You can add target user here
# !!! Pay attention to password restrictions !!!
# e.g) username=("${username[@]}" "scott")
# userpass=("${userpass[@]}" "tigertiger39")
username=("${username[@]}" "root")
userpass=("${userpass[@]}" "rootpassword")
username=("${username[@]}" "user1")
userpass=("${userpass[@]}" "tiger1")
username=("${username[@]}" "user2")
userpass=("${userpass[@]}" "tiger2")
username=("${username[@]}" "user3")
userpass=("${userpass[@]}" "tiger3")
username=("${username[@]}" "user4")
userpass=("${userpass[@]}" "tiger4")
username=("${username[@]}" "user5")
userpass=("${userpass[@]}" "tiger5")
username=("${username[@]}" "user6")
userpass=("${userpass[@]}" "tiger6")
username=("${username[@]}" "user7")
userpass=("${userpass[@]}" "tiger7")
username=("${username[@]}" "user8")
userpass=("${userpass[@]}" "tiger8")
username=("${username[@]}" "user9")
userpass=("${userpass[@]}" "tiger9")
username=("${username[@]}" "user10")
userpass=("${userpass[@]}" "tiger10")
username=("${username[@]}" "user11")
userpass=("${userpass[@]}" "tiger11")
#Password change loop
for((i=0;i<${#username[@]};i++))
do
echo ${userpass[$i]} | passwd --stdin ${username[$i]}
echo ${username[$i]} finish!!
done
echo "Password change all finish!!"
所感
シェルスク1つにまとめるよりもファイルを読み込んで使用した方がスマートな気もする。 一時的に使いたいだけならこの方法でもいいかも
ubuntuで複数ユーザのパスワードを一括で変更する方法。
概要
ubuntuで複数のユーザをまとめてパスワード変更したいときのやりかた。
動作確認出来たバージョン
・Ubuntu16.04.3 Server ※CentOS7では下記の手順ではできませんでした。
動作
ユーザのrootやuser1~11のパスワードをそれぞれrootpassword、tiger1~11に変更する。
前提
rootのパスワードが設定済みであること。
実行手順
$ su root # vi pw.txt # chpasswd < pw.txt # rm pw.txt
pw.txtの内容:
root:rootpassword user1:tiger01 user2:tiger02 user3:tiger03 user4:tiger04 user5:tiger05 user6:tiger06 user7:tiger07 user8:tiger08 user9:tiger09 user10:tiger10 user11:tiger11 #e.g.) UserName：NewPassword
所感
実行手順の部分はシェルスクリプトにまとめるといいかも
CTFdをビルドしてみる話
概要
CTFでよく問題サーバで使用されているCTFdというフレームワークを使用し自身で問題サーバをビルドしてみようかと思い、構築した話。
CTFdについて
構築の方法が2つ紹介されているので、どちらもやってみた。
目次
通常の構築手順
1: 構築したいサーバのホームディレクトリなどで CTFd用のディレクトリを作る。
今回はホームディレクトリ直下に作成する。(uouoCTFのところはCTFの名前にすると管理しやすいかもです。)
$ mkdir ~/uouoCTF $ ls ~
2: gitからCTFdをクローンする
$ cd ~/uouoCTF $ git clone https://github.com/CTFd/CTFd $ ls ~/uouoCTF
gitが入っていない場合は、aptでインストールする場合
$ sudo apt update $ sudo apt install git
などでgitをインストールしてください。
3: サーバの公開範囲を変更するために、CTFdの実行ファイルを編集する。
編集する実行ファイルは"~/uouoCTF/CTFd/"配下のserve.py。
$ vim ~/uouoCTF/CTFd/serve.py
を実行し、30行目の
app.run(debug=True, threaded=True, host="127.0.0.1", port=4000)
を編集する。
host="127.0.0.1"は問題サーバからしかアクセスできないので、
host="0.0.0.0"としてどこからでもアクセスできるようにする。
app.run(debug=True, threaded=True, host="0.0.0.0", port=4000)
こんな感じ。 portも変更できたりする。
4: CTFdサービスを起動する。
$ cd ~/uouoCTF/CTFd $ python serve.py
5: 動作を確認する。
webブラウザのアドレスバーに
[サーバのIPアドレス]:4000
でアクセスする。 CTFdの画面が表示されたら構築完了
このような画面が表示される
Dockerでの構築手順
1: Dockerをインストールする。
$ sudo apt install docker $ sudo apt install docker.io
2: Dockerコマンドを実行する。
$ sudo docker run -p 8000:8000 -it ctfd/ctfd
3: 動作を確認する。
webブラウザのアドレスバーに
[サーバのIPアドレス]:8000
でアクセスする。 CTFdの画面が表示されたら構築完了
ただし、ボリュームの永続化はされない。
Dockerでの構築方法でボリュームの永続化がしたい場合
1: Docker Composeをインストールする。
$ sudo curl -L "https://github.com/docker/compose/releases/download/1.24.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose $ sudo chmod +x /usr/local/bin/docker-compose
2: 通常の構築方法の手順1&2をやる。
3: DockerComposeで環境構築を自動で行う。
$ cd uouoCTF/CTFd $ sudo docker-compose up -d
4: 動作を確認する。
webブラウザのアドレスバーに
[サーバのIPアドレス]:8000
でアクセスする。 CTFdの画面が表示されたら構築完了
まとめ
少し触ってみたい(チャレンジなど登録したものが次回以降消えてもいいよ)って人ならDockerワンライナーのやつ、次回以降も使いたいって人は通常構築方法がおすすめです。 DockerComposeを使った方法は構築までに時間がかかるので、Dockerを使ってごにょごにょやりたい人なら使ってもいいかもしれません。
答えられる範囲であれば答えますので、質問などや間違ってるよ！等があればコメントにお書きください。
systemdにサービス登録したときの備忘録
概要
CTFdの自動起動のため、systemdにサービス登録した際に若干困った話。
CTFdについて github.com
※経過を書いているので、参考にしたい際はこの記事の最後まで読んで参考にした方がいいかもです。
目次
言いたいこと
serviceファイルの[Service]"WorkingDirectory"の項目に実行ディレクトリを指定しても、[Service]"ExecStart"の項目に相対パスでのファイル指定は出来ないぞい
うまくActiveに出来たファイル
ファイル名: hoge.service
[Unit] Description = hoge daemon #サービスの説明文です。内容は自由です。systemctl statusで見た際に１行目のサービス名の横に出る文章。 [Service] User = hogeuser #スクリプト実行時のユーザを指定します。 Group = hogeuser #スクリプト実行時のグループを指定します。(必須ではない) WorkingDirectory = /home/hogeuser/CTFd/ #スクリプト実行時の環境変数を記述したファイルのパスです。 ExecStart = /home/hogeuser/CTFd/serve.py #systemctl start [サービス名] を実行すると、ここに設定されたスクリプトをsystemdが実行します。 Restart = always #サービスが停止した際の動作を指定します。alwaysで常に再起動を実施します。 Type = simple #起動完了の判定方法です。simpleでコマンド実行時に起動完了と判断します。simple（フォアグラウンド処理。）、forking(起動後バックグラウンド処理)。 [Install] WantedBy = multi-user.target #enableでスタートアップ（？）に登録するときのrunlevel。（runlevel 5)
やったこと
まずはこちらのサイトを参考にserviceファイルを作ってみた。
[CentOS7] systemdにサービスを登録して、サーバ起動時に自動でサービスを立ち上げる – RE:ENGINES
以下抜粋
[Unit] # サービスの説明文です。内容は自由です。 Description = puma as service [Service] # スクリプト実行時のユーザを指定します。 User = testuser # スクリプト実行時の環境変数を記述したファイルのパスです。次項で説明します。 EnvironmentFile=/etc/systemd/env # systemctl start [サービス名] を実行すると、ここに設定されたスクリプトをsystemdが実行します。 ExecStart = /home/testuser/puma.sh # サービスが停止した際の動作を指定します。alwaysで常に再起動を実施します。 Restart = always # 起動完了の判定方法です。simpleでコマンド実行時に起動完了と判断します。 Type = simple [Install] WantedBy=multi-user.target
この項目だけの記載では
$ sudo systemctl daemon-reload $ sudo systemctl stop hoge $ sudo systemctl start hoge $ sudo systemctl status hoge
とした時、
* hoge.service - hoge daemon Loaded: loaded (/etc/systemd/system/hoge.service; enabled; vendor preset: enabled) Active: failed (Result: start-limit-hit) since Thu 2019-06-20 09:52:06 JST; 6s ago Process: 2979 ExecStart=/home/hoge/CTFd/serve.py (code=exited, status=1/FAILURE) Main PID: 2979 (code=exited, status=1/FAILURE) Jun 20 09:52:06 ctfd systemd[1]: hoge.service: Main process exited, code=exited, status=1/FAILURE Jun 20 09:52:06 ctfd systemd[1]: hoge.service: Unit entered failed state. Jun 20 09:52:06 ctfd systemd[1]: hoge.service: Failed with result 'exit-code'. Jun 20 09:52:06 ctfd systemd[1]: hoge.service: Service hold-off time over, scheduling restart. Jun 20 09:52:06 ctfd systemd[1]: Stopped hoge daemon. Jun 20 09:52:06 ctfd systemd[1]: hoge.service: Start request repeated too quickly. Jun 20 09:52:06 ctfd systemd[1]: Failed to start hoge daemon. Jun 20 09:52:06 ctfd systemd[1]: hoge.service: Unit entered failed state. Jun 20 09:52:06 ctfd systemd[1]: hoge.service: Failed with result 'start-limit-hit'.
のようなエラーが出力されるので、 別のサイトとも組み合わせてみる。
いい感じの記事 qiita.com を見つけたので、組み合わせる。
以下抜粋 ※【】はコメントです
# original write【コメント行なので適当です】 [Unit] Documentation=man:systemd-sysv-generator(8) 【systemctl statusで見た際にDocs: で表示される文章】 Description=Celery Service 【systemctl statusで見た際に１行目のサービス名の横に出る文章】 After=network.target 【このサービス起動時に事前にnetwork.targetが起動中であることを確認（Networkが上がってないとだめ。）】 [Service] User=celery 【サービスを起動するユーザの指定】 Group=celery 【サービスを起動するグループの指定】 WorkingDirectory=/var/www/celery 【実行ディレクトリの指定】 Type=forking 【Type=simple（フォアグラウンド処理。）、forking(起動後バックグラウンド処理)】 Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes ExecStart=/usr/local/bin/celery multi start w1 -A celery -l info --time-limit=300 --concurrency=8 --pidfile=/var/run/celery/%n.pid --logfile=/var/log/celery/%n.log 【起動コマンド】 ExecStop=/usr/local/bin/celery multi stopwait w1 --pidfile=/var/run/celery/%n.pid 【停止コマンド】 ExecReload=/usr/local/bin/celery multi restart w1 -A celery -l info --time-limit=300 --concurrency=8 --pidfile=/var/run/celery/%n.pid --logfile=/var/log/celery/%n.log 【restart時のコマンド】 [Install] WantedBy=multi-user.target 【enableでスタートアップ（？）に登録するときのrunlevel。（runlevel 5）】
この設定を反映したつもりが、実行に失敗した。 失敗したファイル名: hoge.service ExecStartの指定方法が間違っていた。相対パスではなく絶対パスで書く必要がある。
[Unit] Description = hoge daemon #サービスの説明文です。内容は自由です。systemctl statusで見た際に１行目のサービス名の横に出る文章。 [Service] User = hogeuser Group = hogeuser WorkingDirectory = /home/hogeuser/CTFd/ ExecStart = ./serve.py # ←この指定方法が間違い。ここは相対パスではなく、絶対パスで書く必要がある。 Restart = always Type = simple [Install] WantedBy = multi-user.target
$ sudo systemctl daemon-reload $ sudo systemctl stop hoge $ sudo systemctl start hoge $ sudo systemctl status hoge
を実行すると、
sudo: unable to resolve host ctfd * hoge.service - hoge daemon Loaded: error (Reason: Invalid argument) Active: inactive (dead) since Thu 2019-06-20 10:56:20 JST; 10s ago Main PID: 3072 (code=exited, status=0/SUCCESS) Jun 20 10:11:27 ctfd serve.py[3072]: * Debugger PIN: 170-688-146 Jun 20 10:55:01 ctfd systemd[1]: [/etc/systemd/system/hoge.service:8] Executable path is not absolute, ignoring: ./ Jun 20 10:55:01 ctfd systemd[1]: hoge.service: Service lacks both ExecStart= and ExecStop= setting. Refusing. Jun 20 10:56:12 ctfd systemd[1]: [/etc/systemd/system/hoge.service:8] Executable path is not absolute, ignoring: ./ Jun 20 10:56:12 ctfd systemd[1]: hoge.service: Service lacks both ExecStart= and ExecStop= setting. Refusing. Jun 20 10:56:20 ctfd systemd[1]: Stopping hoge daemon... Jun 20 10:56:20 ctfd serve.py[3072]: * Loaded module, <module 'CTFd.plugins.challenges' from '/home/hogeuser/CT Jun 20 10:56:20 ctfd serve.py[3072]: * Loaded module, <module 'CTFd.plugins.dynamic_challenges' from '/home/hogeuser/ Jun 20 10:56:20 ctfd serve.py[3072]: * Loaded module, <module 'CTFd.plugins.flags' from '/home/hogeuser/CTFd/CT Jun 20 10:56:20 ctfd systemd[1]: Stopped hoge daemon.
の様にエラーが吐かれる。 先のファイルを修正すると
* hoge.service - hoge daemon
Loaded: loaded (/etc/systemd/system/hoge.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-06-20 11:05:12 JST; 15s ago
Main PID: 3264 (serve.py)
CGroup: /system.slice/hoge.service
|-3264 /usr/bin/python /home/hogeuser/CTFd/serve.py
`-3269 /usr/bin/python /home/hogeuser/CTFd/serve.py
Jun 20 11:05:13 ctfd serve.py[3264]: * Loaded module, <module 'CTFd.plugins.challenges' from '/home/hogeuser/CT
Jun 20 11:05:13 ctfd serve.py[3264]: * Loaded module, <module 'CTFd.plugins.dynamic_challenges' from '/home/hogeuser/
Jun 20 11:05:13 ctfd serve.py[3264]: * Loaded module, <module 'CTFd.plugins.flags' from '/home/hogeuser/CTFd/CT
Jun 20 11:05:13 ctfd serve.py[3264]: * Serving Flask app "CTFd" (lazy loading)
Jun 20 11:05:13 ctfd serve.py[3264]: * Environment: development
Jun 20 11:05:13 ctfd serve.py[3264]: * Debug mode: on
Jun 20 11:05:13 ctfd serve.py[3264]: * Running on http://0.0.0.0:4000/ (Press CTRL+C to quit)
Jun 20 11:05:13 ctfd serve.py[3264]: * Restarting with stat
Jun 20 11:05:14 ctfd serve.py[3264]: * Debugger is active!
Jun 20 11:05:14 ctfd serve.py[3264]: * Debugger PIN: 170-688-146
という具合に正常に起動できる。
まとめ
エラーログ大事。
答えられる範囲であれば答えますので、質問などや間違ってるよ！等があればコメントにお書きください。
参考になった記事様
AITAC特別セミナーに参加しました
概要
AITACさん主催でCyberOPSの特別セミナーを3日間受講した話です。
目次
参加前
AITACさんが沖縄で特別にCyberOPSの内容を用いたセミナーを開催してくれるとのことで参加申請しました。
ありがたや〜🙌
— Nano (@uouock) 2019年4月2日
AITAC特別セミナー開催のお知らせ | ニュース | 一般社団法人 高度ITアーキテクト育成協議会（AITAC） https://t.co/aOXhqGL0yU
1日目
1日目ではCyberOPSの概要の説明と、情報セキュリティの基礎的な知識の学習、「PacketTracer」を用いた通信の分析を行いました。
CyberOPSの対象者としてSOCのtier1(アラートの監視や検証をする人。SOCの受け口の人。)に必要な知識を得ることが出来るとの事でした。
SOCについてはこれ見たらいいかも
1日目はマルウェアの種類や攻撃の名称など、学習済みの内容が多く復習するスタンスで受講しました。ただ、CCNA R＆Sで名前が出てきた「NetFlow」をPacketTracer上で触れられた事が新鮮でした。
AITAC特別セミナー1日目終了！ pic.twitter.com/Rw16uaqa9K
— Nano (@uouock) 2019年4月26日
2日目
2日目はSecurityOnionなどのセキュリティツールついての概要の学習とパケットアナライザの「Wireshark」の簡単な使い方についての学習などしました。
特にvirustotalは今後も有用だと感じました。
AITAC特別セミナー2日目終了！🦀
— Nano (@uouock) 2019年4月27日
3日目(最終日)
3日目は前日に続き、基礎的な攻撃手順やマルウェアの動作について、SecurityOnionなどを用いた攻撃の観測などを行いました。
クラウド上のラボ環境での実習では脆弱なサーバに対してKali linuxマシンからSQLインジェクションを行い、その通信を観測していたワークステーション(SecurityOnion)上でどのように攻撃が確認出来るのかを確認したり、DNSの名前解決を利用し攻撃者サーバに情報を送信する「DNSトンネリング」を実際にやってみて先と同様にワークステーション上で攻撃の確認・分析を行いました。
DNSトンネリングについて www.itmedia.co.jp
もくもくSQLインジェクションの会
— Nano (@uouock) 2019年4月28日
Wiresharkでは通信内のファイルを抽出する機能があると知れて目から鱗でした。
AITAC特別セミナー3日目（最終日）終了です！
— Nano (@uouock) 2019年4月28日
ありがとうございました！！ pic.twitter.com/mpIbrnzmHA
まとめ
今回のセミナーはCyberOPSの情報セキュリティにまつわる部分のみ抽出した内容となっておりましたが、なかなかに熱い3日間となりました。 CyberOPSの学習していない部分の学習に加え今回学習した部分も復習しつつ、ラボを有効に使いたいと思います。 AITACさん、特に講師の方には大変感謝しております。ありがとうございました！！m(＿ ＿)m
