ホーム » スタッフ » 斉藤徹 » Computer

Computer」カテゴリーアーカイブ

2020年7月
 1234
567891011
12131415161718
19202122232425
262728293031  

最近の投稿(電子情報)

アーカイブ

カテゴリー

Teams 説明会のトラヒック

今日は、遠隔授業に備えて教職員対象の Teams などの説明会が行われた。遠隔授業のやりかたの方針や、すでにTeamsを実践しようと試している先生の説明。最大80名ほどの視聴であった。(視聴はほとんどの方が学内)
私もTeamsでの説明を行ったが、ブラウザ画面にペン書きをしても、説明の音と動画では10秒から30秒の遅延があったと視聴していた先生が教えてくれた。であれば遅延も頭に置いた説明が必要となりそう。Teamsの生アプリと、Webアプリでも遅延がかなり違うとのことだった。
あまりにも遅延が大きいので、今回のトラヒックの状況を確認してみた。目盛りが少し切れているが、Teams会議中の、対外接続の最大の瞬間値で260Mbpsほど。本校の対外接続のmaxが1GbpsのSINET接続なので、回線としては余裕のはず。となると、遅延の原因は、Teams のサーバ側の可能性が高い。

fukuikousen-bot の更新周期を短く

福井高専のホームページの最新情報を、つぶやく bot ( https://twitter.com/FukuiKousen )を動かしているけど、この連日、コロナウィルスのため重要な公式情報の流れる機会が増えている。

通常は、5時,9時,11時,15時,19時 としていたが、当面頻度を高めておこう。8時から22時まで2時間刻みとしておく。

 

払い下げPCへのddを使ったディスクイメージコピー

総合情報処理センターのパソコンの入れ替えにより、払い下げとなったパソコンのセットアップ中。

1台をWindows10などの環境を整えて、あとは、USBブートのUbuntuを使って、HDDを全コピー。

最初、SATA のケーブルを、コピー元=SATA0 と、コピー先=SATA1 につないでコピーをしたら、同一バスを使うからかな!?やたらと時間がかかり、1台あたり 290分かかった。

$ time sudo dd if=/dev/sda of=/dev/sdb
289min...

2度目からは、コピー元=SATA0で、コピー先=SATA1を、コピー先=SATA3に変更して、ついでにコピー単位を256kB に変更して行う。

$ time sudo dd if=/dev/sda of=/dev/sdb bs=256k
78min...

バッファーサイズが効果的だったのか、SATA3 にしたのが良かったのか…はよく判らないけど、コピー時間を1/3に短縮できた。

でも、残りあと10台以上セットアップは続く。卒業式が始まる前に、1ローテーション回してから、式に向かう。まだまだあるし、もう1つUbuntuのUSBを準備し、2台並行作業を開始。

ネットワークセキュリティのためのTips

usacloud

さくらのクラウド上のサーバを、実験・演習用に使っているけど、未使用時に起動していると課金も増えるので、極力電源を落としたい。調べると、さくらのクラウドであれば usacloud という CLI により操作ができるみたい。

同じネタを「機構管理の Azure のサーバでも極力電源を落とせ」と言われているけど、利用者のいるWebサーバなので困難。

APIキーの取得

usacloud の説明を見ているけど、API キーの取得画面の出し方が変更になっているみたい。さくらのクラウドホームにて、APIキーを発行

usacloud のインストール

usacloud のドキュメントには、

curl -fsSL https://releases.usacloud.jp/usacloud/repos/install.sh | bash

と書かれていたけど、debian の apt の GPG エラーでインストールに失敗したので、usacloud_0.31.1-1_all.deb をダウンロードし、dpkg -i *.deb でインストール。

先の手順で作ったAPIキーを登録

[root]# usacloud config
Setting SakuraCloud API Token => 
	Enter token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Setting SakuraCloud API Secret => 
	Enter secret: xxx...xxx 
Setting SakuraCloud Zone => 
	Enter zone[is1a/is1b/tk1a/tk1v]: is1b
Setting Default Output Type => 
	Enter default-output-type[table/json/yaml/csv/tsv]: json
Written your settings to /root/.usacloud/default/config.json

サーバの操作コマンド

設定が終われば、サーバの起動や停止もコマンド一発

((( サーバの起動 )))
$ sudo usacloud server boot 名前
$ sudo usacloud server wait-for-boot 名前
((( シャットダウン )))
$ sudo usacloud server shutdown 名前
$ sudo usacloud server wait-for-down 名前
((( サーバ一覧 )))
$ sudo usacloud server list
$ sudo usacloud server list -q
11xxxxxxxxxx
$ sudo usacloud server list --output-type table
+--------------+---------+-----+--------+------------+--------------------+--------+----------------+
|      ID      |  Name   | CPU | Memory | Commitment |     IPAddress      | Status |      Host      |
+--------------+---------+-----+--------+------------+--------------------+--------+----------------+
| 11xxxxxxxxxx | nitfcei | 2   | 2048MB | standard   | xxx.xxx.xxx.xxx/24 | up     | sac-xxxx-xxxxx |
+--------------+---------+-----+--------+------------+--------------------+--------+----------------+
$

VMware PlayerでLinux

授業の中で unix 環境を体験してもらうために、vmware player を使う準備

VMware Workstation Playerのインストール

Ubuntu 18 Desktop 版の起動イメージ

起動した状態のイメージを作っておきたかったが、Freeの環境では無理っぽいな。インストール作業を授業時間内にやるか…

Thunderbirdの送信時エンコーディングがJISじゃなかった

とある先生から、メールが文字化けで読めないとの連絡があった。古いメールソフトを使っているとのことだったけど、私はThunderbirdで極力プレインテキストで送っているからJISコードだろうし古いメールソフトでも読めるはず…と思っていたけど、確かめると @kosen-ac.jp が BASE64 で送られていたり、@gmail.com が quoted-printable だったり。

設定を再確認したら、設定のフォントと文字エンコーディングで、デフォルトエンコーディングがUTF-8になってた。古い人間なので、送受信もデフォルトエンコーディングが「JIS(iso-2022-jp)」、「可能な限り返信でもデフォルトエンコーディングを使用」に設定を行った。

うーむ、ちゃんとJISに設定したのに、@gmail.com のメールのタイトルが、”=?UTF-8?B?…”になってら。

nfsのソフトマウント

自室の Linux サーバでは、自分が管理している Azure 上のサーバのデータバックアップを取っているが、ハードディスク容量が巨大な訳でもないので、iMac に接続された Drobo (複数ディスクの改良RAID?) に保存させている。

このネットワーク越しのバックアップでのディスクアクセスになるが、iMac を時々再起動させると、その間に icinga のディスクチェック処理が走った際に、アクセスできないために df プロセスが大量に残るトラブルが発生していた。リトライするため CPU 負荷も高い状態で、一番簡単なのは サーバの再起動。(iMacを再起動したら、その後にLinuxサーバを再起動….無駄や…)

最初は、check_disk 処理で余計なところを見させないために、特定マウント先を無視するオプションを加えていたが、df がマウント先をしつこくアクセスをリトライするのが原因。

よく考えたら、ネットワーク越しのマウントだから、ハードマウント(ディスクアクセスに失敗したら何度もリトライ)ではなく、ソフトマウント(複数回リトライしたら諦める)にする必要がある。

ということで、automount オプションに、”soft” オプションを加えて解決。

福井高専のドメイン名

そろそろ前期期末の成績締め切り。学生さんがレポート課題提出で先生にメールを送ることも多いが、メールアドレスの書き間違いでメールがエラーになって届かないトラブルがちらほら。

メールアドレスをどう書き間違えているのか確認すると、hoge@fukui-nctac.jp と書いていたりする。高専機構のドメイン名は、hoge@fukui.kosen-ac.jp で、ac の前がハイフンに間違えてるんだろうな。

まずは結論

高専機構(福井)のメールアドレスは、hoge@fukui.kosenac.jp です。

福井高専のメールアドレスは、hoge@fukuinct.ac.jp です。

ということで、以下解説。

ドメイン名の一般ルール

ちなみに、日本のドメイン名は古くは、組織ドメイン.種別ドメイン.国ドメイン の形式。

組織ドメイン=fukui-nct , 種別ドメイン=ac(教育機関) , 国ドメイン=jp(日本)

種別ドメインには、.co.jp(会社) , .ne.jp(ネットワークサービス) , .or.jp(団体) , .go.jp(政府機関) といったものがあるが、企業のサービスだと、.co.jp なのか .ne.jp なのか曖昧だったりするので、最近は省略したものを申請できるようになっている。

国ドメインは、アメリカはネットを作った所なので、国ドメインは省略され、.us(アメリカ) を使うことはめったに無い。一方、国ドメインも、.jp(日本) , .uk(イギリス) , .ch(中国) とかあっても、世界中に拠点を持つ企業では、.jp なのかよくわからないので、国ドメインを持たない種別ドメイン .com (企業) を取得することも多い。

高専機構のドメイン名

日本では最近様々な形式の学校が出てきたため、.ac.jp のドメインを取る時の審査は厳しくなっている。

このため、高専機構では、kosen.ac.jp を取得したいが審査が通らずしかたがないので kosenac.jp を取得している。

組織ドメイン=kosen-ac , 種別ドメイン=なし , 国ドメイン=jp(日本)

ちなみに、”-ac.jp” といった変則的なドメイン名は、教育機関を偽装したドメイン名と勘違いされやすく、kosen-ac.jp のドメイン名を見て「怪しい…」と思う人も多い。

福井高専のドメイン名

一方、高専機構ができた後の福井高専の英語の正式名称は、“National Institute of Technology, Fukui College” であり、福井高専のドメイン名としては、本来 “nit-fukui.ac.jp” を取得したい。

組織ドメインの綴りのルールは無いので、大学でも 大学名-u.ac.jp だったり u-大学名.ac.jp など色々あるが、最近は後者が主流となっている。(福井大学も以前は、fukui-u.ac.jp だったが、最近は u-fukui.ac.jp に変更されている)

しかし、.ac.jp の審査が厳しく、高専機構の1組織っぽい nit-fukui.ac.jp は審査が通らない可能性が非常に高く、どの高専も以前のドメイン名をそのまま使用しているのが現状である。

ログ解析とSOC演習(in 石川高専)

高専機構の情報セキュリティ人材育成イベントK-SECにて、主管の石川高専さんにて、「ログ解析とSOC演習」の講習会がありました。

ログ解析

セキュリティ機器の設定や組織内のルールにて、防衛を行うことはできるが、完全に脅威を検知・防御することは難しい。通信ログやアクセス履歴などの取得・蓄積しログから脅威を検出することが重要。

ログ解析演習

Raspberry-Pi のサーバが学生1人毎に準備してあり、演習用のログデータから目的となる情報を探す演習を行なった。

$ ls -R
~pi/log/event1-5/pcap/sqlinjection.pcap
~pi/log/event1-5/web-log/access_log_yyyymmdd.log

まずは基本コマンド

$ cd log/event1-5/web-log/
$ ls -al access_log_yyyymmdd.log
$ cat access_log_yyyymmdd.log | more

ユーザーエージェントの確認

$ cat access_log_yyyymmdd.log | cut -d ' ' -f 12- | more
  # cut 特定の項目を抜き出すコマンド
  #   -d ' ' データの区切り文字は ' ' 空白
  #   -f 12- 12項目以降を出力
  # more 出力をページ単位で出力
  #   大量のLOGだと、長時間かかるよぉ…

ディレクトリパストラバーサルの確認

$ grep "¥.¥./" access_log_yyyymmdd.log
  # grep 特定の文字を含む行を抜粋して表示

# アクセス履歴のPATHを確認
$ grep "¥.¥./" access_log_yyyymmdd.log | awk '{print $7}'
  # awk '{print $7}' 各行の7番目を出力 ( cut -d ' ' -f 7 と同じ )

# アクセス成功の確認
$ grep "¥./" access_log_yyyymmdd.log | grep "¥" 200"
  # Webサーバのアクセスログには、データ取得成功=200 が記載されている行を抜粋

# 特殊なアクセスPATHを確認
$ grep /proc/cpuinfo access_log_yyyymmdd.log
  # 脆弱なphp,cgiだとアクセスのURLに、アクセスしたいPATHが含まれる
  # /proc/cpuinfo は、CPUの種別などの情報が取れる

# 攻撃者のIPアドレスを確認
$ grep -h "¥./" access_log_yyyymmdd.log | awk '{print $1}' | sort | uniq -c
  # アクセスログの先頭 $1 には、IPアドレスが書いてある。
  # sort 出力をソートする(同じ行を集めるためにソート)
  # uniq -c 同じ行が繰り返す行数をカウント

OSコマンドインジェクションの確認

脆弱性のあるメール送信ページへの攻撃の確認
# addressを含む行で@を含まないものを検索
$ grep -h address access_log-yyyymm*.log | grep -v @
  # grep
  #   -h 複数ファイルの処理で、ファイル名を出力させない
  #   -v 含まない行を出力する。

$ grep -h address access_log-yyyymmdd.log | grep -v @ ¥ | awk '{print $7}' | nkf -w --url-input
  # nkf 漢字などの文字コードを変換
  #   -w UTF-8 で出力
  #   --url-input %20みたいなURLエンコードを復号
この実行結果には以下のようなものがあるかもしれない。
"address=;/bin/echo Permit_RootLogin yes >> /etc/ssh/sshd_config"

SQLインジェクションの確認

  • 不正ログイン、情報漏洩、完全性損失、可用性損失 の可能性

SOC演習

大量のログでは、unixコマンドで解析するにしても、コマンド組み合わせを考えるのは大変。企業では、ログ解析専用ソフトを用いて解析を行う。ただし、専用の解析ソフトは高価。今回は、K-SEC事業で一時的な借り物で演習。