サーバ技術の最近のブログ記事を表示しています。
過去のブログ記事については下部のリンクより参照ください。
TeraStationを使っていますが、同じPC上で大きなファイルをコピーしているときには動作が遅くなります。
フォルダを開いたり、小さなファイルを開こうにも待たされるので、少しストレスです。

SMBの仕様が正確に分かってるわけではありませんが、同じIPアドレスに対してはシリアルに処理されているように見えます。
となると、TeraStationにIPアドレスを複数振ればよいのですが、そうはいきません。

LANポートは複数あるのですが、LAN1とLAN2に同セグメントのIPアドレスを振るのはサポートされません。
また、LAN2を別セグメントとした場合にはスタティックルートを設定できず、使い勝手が悪いです。
(荒業でLAN2側と同じセグメントのIPアドレスを端末に振るという手はありますが...。)

TeraStation単体ではどうにもならないので、外部でNATしてどうにかしましょう。
今回はNATができるソフトウェアファイアウォールのpfSenseで設定してみました。

TeraStationに付与しているIPアドレスを192.168.1.11とした場合に、192.168.1.12でもアクセスできるようにしてみましょう。

Virtual IPの設定

192.168.1.12でアクセスできるようにするために、VIPをpfSenseに設定しましょう。

Type IP Alias
Interface LAN ※環境に合わせて設定
Address 192.168.1.12/32

これを設定すると、192.168.1.12にpingするとpfSenseが答えてくれるようになります。

NAT - Port Forwardの設定

192.168.1.12で通信してきたものを192.168.1.11にNATしましょう。

Disabled
No RDR(NOT)
Interface LAN ※環境に合わせて設定
Address Family IPv4
Protocol TCP/UDP
Source Any
Source port range Any / Any
Destination 192.168.1.12
Destination port range Any / Any
Redirect target IP Single host / 192.168.1.11
No XMLRPC Sync
NAT reflection Disable
Filter rule association None

これを設定すると、192.168.1.12に対する通信が192.168.1.11に転送されるようになります。
このままでは192.168.1.11から直接通信が帰ってきてしまうので、うまくいきません。

NAT - Outboundの設定

pfSenseでSNATさせて、戻りの通信が192.168.1.12からになるようにしましょう。

Disabled
Do not NAT
Interface LAN ※環境に合わせて設定
Address Family IPv4
Protocol any
Source Any
Destination Any
Address Interface Address
Port or Range (空欄)
No XMLRPC Sync

これでうまく通信ができるようになり、192.168.1.11と192.168.1.12の2つを使ってネットワークドライブを割り当てられます。
そうすれば、片方のIPアドレスで大容量コピーをしていても、もう片方のIPアドレスでアクセスすれば快適です。
共有ごとにIPアドレス割り当てて使うのが快適かなーと思います。

ブログが攻撃を受けました。

このブログを運営して10年ほどですが、初めてサーバのコンテンツが書き換えられました。
書き換えられたのは管理用のコンテンツだけだったので、特に影響はありませんでした。
現在は日次のバックアップからデータをリストアして復旧させています。

経緯

いつも通りに釣りブログの更新をしようと、管理ページを開きました。
そしたら、ESETさんが脅威を検出という不穏な画面を表示。
よく見ると、変なページにリダイレクトされているようです。
eset-alert.png

調査

サーバに入って、コンテンツを確認すると、中身が書き換えられていました。
[root@www01 cms]# cat index.html
<script>document.location.href="https://absolutelytowns.com/et3vdt36iy?key=b6a50f1c0af90b7aab7bf6ff89daf0f1";</script>

書き換えられた時刻は4/2 3:14のようです。
[root@www01 cms]# ls -la
(省略)
-rw-rw-r--  1 apache apache   118  4月  2 03:14 index.html
(省略)

secureログを見てもログインの形跡はありませんでしたが、Apacheのログには該当する時刻に不信なログがありました。
時刻的にはピッタリで、4/1 5:31から何度かアクセスがあるようです。
[root@www01 httpd]# cat * | grep /cms/mt-xmlrpc.cgi
107.189.10.254 - - [02/Apr/2023:03:14:25 +0900] "POST /cms/mt-xmlrpc.cgi HTTP/1.1" 200 2848 "-" "Mozilla/5.0"
107.189.10.254 - - [01/Apr/2023:05:31:17 +0900] "POST /cms/mt-xmlrpc.cgi HTTP/1.1" 200 1385 "-" "Mozilla/5.0"
107.189.10.254 - - [01/Apr/2023:05:31:17 +0900] "POST /cms/mt-xmlrpc.cgi HTTP/1.1" 200 1382 "-" "Mozilla/5.0"
107.189.10.254 - - [01/Apr/2023:06:39:05 +0900] "POST /cms/mt-xmlrpc.cgi HTTP/1.1" 200 2845 "-" "Mozilla/5.0"
107.189.10.254 - - [01/Apr/2023:09:16:30 +0900] "POST /cms/mt-xmlrpc.cgi HTTP/1.1" 200 2848 "-" "Mozilla/5.0"
107.189.10.254 - - [01/Apr/2023:20:51:01 +0900] "POST /cms/mt-xmlrpc.cgi HTTP/1.1" 200 2848 "-" "Mozilla/5.0"
[02/Apr/2023:03:14:25 +0900] 107.189.10.254 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "POST /cms/mt-xmlrpc.cgi HTTP/1.1" 2848
[01/Apr/2023:05:31:17 +0900] 107.189.10.254 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "POST /cms/mt-xmlrpc.cgi HTTP/1.1" 1385
[01/Apr/2023:05:31:17 +0900] 107.189.10.254 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "POST /cms/mt-xmlrpc.cgi HTTP/1.1" 1382
[01/Apr/2023:06:39:05 +0900] 107.189.10.254 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "POST /cms/mt-xmlrpc.cgi HTTP/1.1" 2845
[01/Apr/2023:09:16:30 +0900] 107.189.10.254 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "POST /cms/mt-xmlrpc.cgi HTTP/1.1" 2848
[01/Apr/2023:20:51:01 +0900] 107.189.10.254 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "POST /cms/mt-xmlrpc.cgi HTTP/1.1" 2848

調べてみると、mt-xmlrpc.cgiには脆弱性情報がありました。(ちゃんと追いかけてないのがバレバレ...。)
JVN#41119755 Movable Type の XMLRPC API における OS コマンドインジェクションの脆弱性 緊急

OSコマンドインジェクションの攻撃を受けたようです。
mt-xmlrpc.cgiはapacheユーザーで動くので、書き換えられたのはapacheユーザーに権限があるものだけでした。
どうやら.htmlファイルや.phpファイルを検索して、中身を置き換えるコードを実行されたみたいです。

対応

バックアップからデータを復元するため、改ざんされる前のバックアップを確認します。
恐らく最初の攻撃は4/1 5:31なので、4/1 1:00に取得したバックアップに戻せばよさそうです。
[root@www01 httpd]# tar tvzf /opt/op/backup/www01.s1ncha.com_backup_wwwdata_20230402.tar.gz | grep /cms/index.html
-rw-rw-r-- apache/apache       118 2023-04-01 20:51 var/www/cms/index.html
[root@www01 httpd]# tar tvzf /opt/op/backup/www01.s1ncha.com_backup_wwwdata_20230401.tar.gz | grep /cms/index.html
-rw-rw-r-- apache/apache      8921 2014-12-16 08:20 var/www/cms/index.html

書き換えられる前のコンテンツが含まれていたので、このバックアップから戻すことにしました。

脆弱性情報に記載されている対策はバージョンアップですが、今回はワークアラウンドを実施しました。
とりあえず、mt-xmlrpc.cgiの実行権限を外して、外部から実行されないようにしました。
[root@www01 cms]# chmod -x mt-xmlrpc.cgi

インターネット公開サーバでバージョンアップをサボってはいけませんね。
サボるとしても脆弱性情報はしっかりと抑えておかなければなりません...。
Tera Station復活の備忘録、第2弾です。
TS5400のバックアップ用として、TS-XHLシリーズを使っています。
機種的にはこちらの方が古く、扱いづらい点があるのも事実です。
その分、より安く入手できる点がメリットかなと思います。

この機種はUSBブートで復活させたり、VGA出力があるわけではないので、少しだけ難易度があがります。
BUFFALOから提供されているアップデーターを使い、インストールする必要があります。
これについても少しだけコツがいるので、それについて記載したいと思います。

この機種はSMBv2が有効になっていないので、Win10からは使えません。
賢い人が使えるようにする方法を出してくれていますので、是非調べてみましょう。

用意するもの

  • Tera Station TS-XHL本体(この記事はTS-XH2.0TLで試しています。)
  • ハードディスクをスロット数分全て(TS-XH2.0TLの場合は4本)
  • リカバリ用ファームウェア(tsx-v176.exe)
  • TSUpdater.exe(TSX156.zip同梱のもの)
  • 作業用PC
  • LANケーブル

復旧手順

(1)作業用PCにてファームウェアアップデータを準備
まずは作業用PCにリカバリ用ファームウェアを展開します。
その後、展開したリカバリ用ファームウェアに含まれるTSUpdater.exeをTSX156.zipに含まれるものに置き換えます。
復活作業ではディスクのフォーマットが必要になりますが、tsx-v176.exe同梱のものはフォーマットができません。
色々と試した結果、TSX156.zip同梱のTSUpdater.exeはフォーマットオプションが使えるようです。

その後、TSUpdater.iniのFlagsを以下の通りに書き換えます。
[Flags]
VersionCheck = 0
NoFormatting = 0

(2)作業用PCとTera Station本体をLANケーブルで接続
作業用PCとTera Station本体をLANケーブルで接続します。
当たり前のようにAuto MDI-Xが働くので、クロスケーブルとか気にしなくても大丈夫です。
また、IPアドレスもAPIPAを使えばよいので、設定する必要はありません。

(3)TeraStationをEMモードで起動
空のハードディスクをセットして起動した場合、EMモードで起動します。
Nas Navigatorを使えば、EMモードで起動したか確認できます。
ts-xhl_pic1.png

(4)TSUpdater.exeを起動し、Updateを実行
作業用PCでTSUpdater.exeを起動します。
Tera Stationが自動で検索され、アップデート対象があればUpdateができます。
(くれぐれも別のTera Stationに対して実行しないように注意してください...。)

アップデートが始まると、ハードディスクのフォーマットとファームウェアインストールが実行されます。
ts-xhl_pic2.png

アップデートが終わると、インストールされたファームウェアにて起動されます。
と、実は意外と簡単なのです。
私はフォーマットできるTSUpdater.exeを探し出すのに非常に苦労しましたが...。

サーバ技術の過去のブログ記事