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

2023年5月
 123456
78910111213
14151617181920
21222324252627
28293031  

検索・リンク

mariadb の utf8mb4 への移行完了

自宅サーバで、mysqlからmariadbへの移行、内部文字コードが Latin1 になっていたものを utf8mb4 への変更がようやく上手くいったと思う。そこで、学科のWebサーバも同様に移行作業を行う。ただ、文字コードの移行などの際にデータベースの物理ファイルを壊してしまったようで、どこまで上手く治ったのかが不安。

mysql5.7でFROZNモード

先日、mysql-server-5.6 からのアップグレードに失敗し、mariadb, mysql 8 などを入れたり消したりのトラブルを発生させちゃったけど、今日 “aptitude safe-upgrade” を実行したら、アップグレード時にデータベースの互換性で問題ありと判定され、FROZEN モードになってしまい、データベースとつながらなくなった。おかげで WordPress が動かなくなる。

明日からの試験で、Webでの講義資料公開ができなくなると、学生さんからも不満が出そう。

早々に修正と思うけど、FROZEN ファイルを読むと、mysql-server-5.7 が入っているけど、mysql-server-5.6 からのアップグレードに問題があるから、一度 5.6 にダウングレードしてから、5.7 にアップグレードしろ…との説明。

でも、5.6 はインストール対象から外されている。ひとまず、その後に dpkg-reconfigure mysql-server-5.7 を実行せよと書いてあるので、dpkg-reconfigure を実行。データベースの更新やらチェックが行われて、若干エラーが出たけどうまく修復できたみたい。rm /etc/mysql/FROZEN して systemctl start mysql を実行。無事 WordPress が動き出す。

福井高専のドメイン名

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

メールアドレスをどう書き間違えているのか確認すると、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事業で一時的な借り物で演習。


WordPress4.9.2が出た

WordPress 4.9.2 が出てきた。日本語版”-ja” 付きではないけど、早々に入れておく。

2018/01/18 追記
お、今回は、4.9.2-ja 翌日には公開されたな。はゃっ…

oldstableをstableに

学科サーバやらアンケートシステムやらで、 Debianベースで色々なサーバを運用しているけど、 どれも5年近くの稼働。

きちんと更新はかけているけど、lenny から squeeze に 上げるのが面倒で、squeeze 登場の時に oldstable/lenny だけに sources.list を書いて運用していた。 しかし、さすがに oldstable のメンテナンス期間も過ぎ、 最近は、"aptitude safe-upgrade"かけても更新が無い。 限界。

ということで、メイン稼働でない oldstable なサーバで、 stable 切り替えを行う。ただ、大きな変更だけあって、 パッケージ間競合で、うまく自動更新スクリプトが止まらない。

何台か作業したけど、以下の手順だと競合が少ないかな。

aptitude install aptitude
aptitude install gcc g++
aptitude install apache2 php5
aptitude install xserver-xorg
aptitude install gnome
# kdeと競合が多いけど、ばっさりkdeを一時的にremove...

ああ、サーバなのに使ってもいない gnome , KDE なんか、 こんなに律儀にインストールしてるんだろう…>オレ。

PHPが一般ユーザで動かなくなる

更新をかけたら、一般ユーザでのPHPが動かなくなる。 でも、自分のホームでは、動く。さっぱり訳の分からない状況で、 userdir が原因と疑い、検索をかけたらようやく解明。 PHP 5.3 あたりから、安易にユーザがPHPコードを使えないように、 設定ファイルが、変更されてる。

自宅サーバでは、問題なく動いていたし、設定ファイルを比較しまくったのだが、 違いが見つからず、解明まで時間ががかった。 自宅では、mod-enabled/userdir.conf は触らずに、 conf.d/php5.conf で設定していたものだから、気付くまでに手間取ってしまった。

(( /etc/apache2/conf.d/php5.conf ))
<IfModule mod_php5.c>
<IfModule mod_userdir.c>
<Directory /home/*/public_html>
php_admin_flag engine on
</Directory>
</IfModule>
</IfModule>

システム

最新の投稿(電子情報)

アーカイブ

カテゴリー