MR.HARIKIRI-INSIGHTS

[Synology] NAS/Router ログ・センターは、毎日1回は見るべし – サーバーへの総当たり攻撃を発見、システムのログイン制限の適切な設定と自動ブロック- [2021/08/01]

Written by

harikiri

in

,

ID16720

はじめに

この2021/07/27から8/1にかけて「brute-force attack」によるUID/PW情報を破る試行行為が静かに行われていました。Synology NASおよびRouter製品のセキュリティの話です。

前回、2020/06に気が付いたケースでは、Mail Serverへのattackを3ヶ月間、もしかすると半年間許してしまったことに焦りを感じました。それ以来、Log Centerの確認は1日に1回は無理でも1週間に数日は確認するようにしていたため、このコロナ禍の7/30には、そのattack (DSMへのログイン試行)を認識することができました。数日後の8/1まで対策に時間を要したのは、対策方法を見つけるまで時間がかかったためです

Warning Logの内容は以下の通りです。

User [admin] from [xxx.xxx.xxx.xxx]failed to log in via [DSM] due to authorization failure.

以下、今回のケースの対策方法についても、この記事にまとめておきたいと思います。

前回(半年以上のアタックを受けていたケース)の対策を施してからは、Log Centerの日常な監視を強化して、追加の設定等により、その有効性を高めていたつもりでした。Log Centerの確認では、表示したいグループを、接続(Connection)にして、黄色で表示されるWarning情報に記録されている怪しいIPアドレスはブロックリストに登録し、更に、効果的な自動ブロックはアクセス制限の設定値を熟慮して設定しています。

NASやRouterには、必要なセキュリティ機能が装備されています。ローカルネットワークの外からのアクセスを許可している場合は、適切に設定しておかなければ、不正アクセスの踏み台になったり、データを失ったりすることもあり得ます。NAS/Routerには、それぞれで、何らかのサーバーが構築されているはずです。これらのサーバーへのattackを受け難くするために、Synology製のNAS/Routerには、不正ログインやアタックを阻止する強化された機能があるので、適切に設定することでよりセキュリティを高めることが可能です。

前回のケースは、MailPlus Serverに対する不正ログイン試行 (frute-force-attach)を偶然に発見しました。その日まで半年の間、四六時中、ログイン試行を許していたのでした。

以下に紹介した方法は、外部からのアクセスを許しているサーバー全般に対して、ログイン試行 (brute-force-attack)を共通に自動ブロックして阻止することができます。この自動ブロックは、特定のIPアドレスに対してのものであり、一定期間で解除される仕組みとなっています。しかし、今回のように、Synology DSMに対して、特定のポート番号を知られて、毎回、IPアドレスを変更してくるattackには完全に遮断することができておらず、Log Centerの記録に警告(warning)として残ることになりました。このケースの場合、基本設定というよりは、対処療法となります。その都度対処することが対応策の基本ということです。

今回のケースではDSMへのLog in試行でしたが、IDは[admin]固定でIPアドレスを変化させながら、また、PWは色々と試行していると考えられます。以下に解説している基本設定のままでは、警告「ログインの失敗」(failure to log in)が4分おきに記録されていました。この状態を良しとしておいてもしばらくは良いと思いますが、その内、ヒットされる危険性もあります。でもadminは無効にしておけば、ヒットされることはありませんが。でも、ログに残ってくるattackは鬱陶しいですね。

ログセンターをまだインストールしていない場合は、パッケージセンターからインストールを済ませておきます。インストールできていれば、下図のように「ロクセンター」が表示されるはずです。

Mr.Harikirの環境の場合、Routerのログは、NASに転送して一元管理しています。RouterとNASにLog Centerをインストールしてあり、ログが集まってくるNASのLog Centerを定期的に確認しています。

DSM
図1. ログセンターは毎日確認

Log Center

Log Centerが少しトリッキーなので、少し注意点と簡単な使用方法を以下に示しておきます。

  1. 注意点、概要とログのタグページがありますが、表示内容がなぜか一致していない。概要ページのログには記録されているログインの失敗情報がログページで接続(connection)表示させても、その情報が無い場合がある。
  2. 使い方、表示を一般から接続(connection)にして警告(warning)を確認する。
  3. 今回のケースでは、DSMへのログインの失敗が約4分間隔で記録されていた。以下に開設している今日までの設定では、Mail Serverへのattackには効果がありました。しかし、DSMへのattackに対しては、attack自体を許しており、そのため記録が残っている。

これまで2回のattackに対する設定概要

  1. 前回のケースであるMail Serverへのattackの対策は、以下の「基本設定」以降に詳しく解説しています。
  2. 今回のケースであるDSMへのLog in attackの対策は、追加事項として、ここに示しておきます。
    1. DSMへのログイン(log in)では、ポート番号が知られてしまっているため、attackを許していると考えて以下の対策で解決しました
    1. コントロールパネル→ネットワーク設定→DSM設定
    2. ポート番号の変更と適用。モグラ叩き的な対策ですが有効な対策の一つです(2021/08/01)。
    3. DSMのポート番号は、PhotoStationやCalenderなどに使われているので、クライアントからの接続設定も更新しておく必要もあります。

基本設定

前回のケースでは、attackを受けたのはMail Serverであったため、Mail Serverへのattackが無くなるように設定されています。今回の対応により、その設定内容の変更はありません。今回のDSMへのログイン試行の対処療法として設定すべき項目は、DSMのポート番号の変更のみです。

前回、MailPlus Serverへのattackを受けた時の状況

これまで、Log Center (ログセンター)のログは、時折確認していました。しかし、Warningに関しては、重要視していませんでした。

たまたま、今日(2020/06/05)、Warningをしっかり見てみたところ、3分間隔で、MailPlus Serverに対するログイン試行を繰り返していることに気づきました。しかも、3日間に渡ってです。Logを遡って見てみると、以下のことがわかりました。

  • 一回の攻撃は、約3日間をひとまとまりとして行われていた
  • その約3日間が数日間の間隔を置いて、同様の攻撃が行われていました
  • これを大きな「かたまり」として1つと勘定すると、まとまった攻撃の回数は半年間で、5回を確認できました
  • 3日間でのやり口は、約3分間隔でログインの試行をユーザー名を色々と変えながら行っていました。
    • ユーザーIDは、home、ad, user, user0など、よく使われるものでした(図1)

この攻撃を許していたことに冷や汗です。

図1. MailPlus Serverへのログイン試行ログ

基本設定による対策

DS918+のアクセス制限の適切な設定

アクセス回数によるログインの制限を、以下のような考え方によって適切に設定します。

  • 3分間隔のログイン間隔を前提にします
  • 3回のログイン・ミスが生じた場合にブロックするようにします
  • 3 x 3 =9 分間で、3回のミスが生じた場合をブロックできれば良いことになります
  • 時間に余裕を持たせて例えば、12分を設定します
  • 回数は、3回を設定します

コントロールパネル→セキュリティ→アカウント

図2. ログイン制限の設定

設定例

当初の設定では、時間の設定を1分にしていました。早めに検知できた方が良いと直感的に考えたからでしたが、その設定は間違いでした。1分以内で実行できるログイン試行数は、それほど多くありません。時間は、10分から60分程度が、検知するには必要です。更に、自分がログインしてすることと、不正アクセス者がログイン試行することを考えると、60分の時間内でのログイン試行数が設定の鍵になります。

例1

12分間の間で、3回~(最大4回)のログインを試行して失敗した場合、自動的にブロックします。4分間隔以下を検出できます。この場合、12分間で3回間違えるとブロックされます。自分がログインする場合も同様なので、少ない回数の3回については注意が必要です。

  • ログイン試行回数(Login Attempts) : 3 回
  • その時間範囲 (Within) : 12 分

例2

例1は、4分間隔のログイン思考を前提にしましたが、不正アクセス者は検知をさせるためには、間隔を更に長くすることも考えられます。

そこで修正して、各値を約3倍にを考えてみます。60分間の間で、10回のログイン試行のブロックを考えます。この場合、60分間以内に、10回ミスするとブロックできます。自分がアクセスする場合、10もミスはしないと思います。また、不正アクセス者が、10回の限られた回数でID/PWを破れるとは考えられません。妥当な設定だと思います。ただし、この設定では、不正ログイン試行を6分に1以上のアタックに対しては、自動ブロックができません。

この自動ブロックができない状態がそのまま続いたとして24時間経過後には、240回のログイン試行がおこなわれてしまいます。

  • ログイン試行回数(Login Attempts) : 10 回
  • その時間範囲 (Within) : 60分
  • 自動ブロックができない最悪のケースでは、24時間後には、240回のログイン試行を許してしまう

例3

例2の、10回、60分の設定では、最悪の場合、24時間後には、240回のログイン試行を許します。

そこで、10回のミスは、自分もあり得ると許容して、時間をもう少し考えます。24時間以内に10回ミスしたら、自動ブロックするようにすればどうでしょうか。

自分がログインする時、1日の内に連続して10回もミスはしません。10回、24 x 60 =1440分の設定を最終案として考えてみましょう。

不正ログイン試行が、この設定を最悪逃れられた場合、1日(24時間、1440分)で10回を許すことになります。1日で10回ということは、1週間で70回の試行回数になります。

Log Centerの確認を毎日行えば、10回の試行回数で発見できます。1週間毎の確認であれば、70回の試行回数で発見できることになります。なかなか、リーズナブルな設定値になってきました。これを最終提案とします。

  • ログイン試行回数(Login Attempts) : 10 回
  • その時間範囲 (Within) : 1440分
  • 自動ブロックができない最悪のケースでは、24時間後には10回、1週間では70回ののログイン試行を許してしまいますが、それ以外は自動ブロックできます。
  • 妥当な設定であると判断しました。

設定の効果

ログイン制限の設定は、12分-3回に設定してみました。今、まだ、不正ログイン施工を実行中(bot)ですが、以下の様に、3回のログイン試行により、自動的にブロックされたことが、Log Centerのログから確認できました。

図3. 自動ブロックされたことを確認

メール通知

NASシステムの通知方法として、メールアドレスを設定しているなら、前述の設定で、自動ブロックされた時には、メールで通知がきます。

図4. 自動ブロックされたると携帯に通知がくる

永遠にブロックする

自分がブロックされることもあると思います。そこで、自動ブロック期間は、1日にしています。

自動ブロックの通知が届いた場合は、自分に関係しないIPアドレスは，設定から永遠にブロックしておきます。

コントロールパネル → セキュリティ→ アカウント→ブロックリスト

ブロックリストには、自動的にブロックしたIPアドレスがリストされていので、そのIPアドレスを控えておき、作成したブロックリストを改めて作成します。上書きするか聞いてきますが、気にせず上書きして、永遠にブロックします。

自動ブロックの通知が届いた場合は、設定から永遠にブロックしておきます。

図5. ブロックリストに永遠にリストしておく

まとめ

1回目の「Brute-force-attack」と思われる不正アクセスの心込みについは、新型コロナウイルスのため、自宅待機していたことで気が付けましたが、これまでの少なくとも6ヶ月間、不正アタックを放置していたことになります。

ざっくり計算してみると，3日間で3分間隔の不正ログイン試行では、その総試行回数は、3 × 24 × 60 ÷ 3 = 1,440回です。

それをこの半年間で、少なくとも5回行われていたので、1,440 x 5 = 7,200回の不正ログイン試行を許してしまったことになります。

Log Centerは、週に2回は見ていましたが、今思えば、なんの基準もなく漫然と見ていました。今回は、それでも偶然見つけた訳ですが、大事になる前で良かったと思います。

Log Centerは、最初に設定した時や設定を変更した時には、しばらくは、できれば毎日見た方が良いですし、今回の教訓から特にWarningは、文字通り注意して見る必要があります。特に，同じIPアドレスが何度も記録されていることは要注意です。

前述した「例3」の設定では、24時間で10回以上、または、1週間で70回以上のログイン試行を同じIPアドレスからされた場合に自動ブロックできます。

もしも、自動ブロックが出来ない間隔で不正ログイン試行をされた場合でも、毎週1回のLog Centerの確認によリ、最悪でも70未満の試行回数で発見できます。もちろん、毎日のLog Centerの確認により、10回未満の試行回数で発見できます。

勿論、少ない回数で鍵を開けられない程度の複雑なPW設定を前提にしています。攻撃者に対して、決して、宝くじの当たる確率を上げないように運用していきたいものです。

Synology Routerの設定

以上の設定は、Synology Routerにも同様に設定できるので、それぞれがターゲットとなっても大事に至らないよう、同様に設定しておきます。

  • ネットワークセンター → セキュリティ → 自動プロック

まとめ

レンタルサーバーを使わず、自前のマシンを使っってBlogをしたり、ホームサーバーとして構築していたとしても、外部からのアクセスを許して運用している御同輩の皆さんは、一般ユーザーとは異なり、私もそうですが、茨の道を進んでいるのです。

防御能力は攻撃能力よりも重要です。しっかり「マイホーム」を守れるように日々精進したいと思います。

以上

編集履歴

2020/06/05 はりきり(Mr)
2020/06/06 追記(例3)
2021/01/22 文言整備、図の追加
2022/11/20 文言整備

関連記事:

[Synology] Router 「RT2600ac」- ネットワーク攻撃にも余裕でブロック – ET WEB_SPECIFIC_APPS ECSHOP user.php SQL INJECTION via Refererとは [Synology] NASのネットワークツールからWOLを発信してと思ったが、ルーターはRT2600acなので、iPhone用のアプリDS ROUTERの wake on LAN から自宅のPC/ビデオレコーダー等を起動する [2021/06/19] [Synology] グローバルなIP証明書である「 Let’s Encrypt 」取得 – 80, 443ポートが空いているNASでは自動更新は可能 – その他NASへの証明書のインポート方法 と運用方法 [2023/02/25] [Synology] Router / SRM 1.2.3-8017 Update 3にUpdateされた時から、RT2600acを守っているThreat Preventionからの警告e-mail連絡がなくなった件 [Synology] Threat Preventionが検知したWordPressへの連続Loginアタックは全てIPアドレスが異なっているBrute Force Attack – reCAPTCHAプラグインで対策する [2020/03/20] [Synology] NAS (DS918+/DS920+)の バックアップを考える – システム構成は「Hyper Backup」、「Snapshot Replication」および「Synology Drive」- Smartプラグによる外付けHDDケース電源の管理によるセキュリティ向上、最後にシステムコンフィグレーション /クラウドバックアップも考え [2023/11/15] [Synology] ITセキュリティ – ランサムウェア対策は，マルチバージョン・バックアップやスナップショットが良いと言われている – Synology NASに当てはめてみた [2020/03/28] [Synology] セキュリティ改善法 – Threat Preventionとファイヤーウォールの運用を連携する [2021/08/01] 36CF6F92-9A83-4A27-B301-25A96A970340[Synology] 自宅にNASを設置しWordPressを構築 – blogサイトを立ち上げる – DS918+/DS920+ — 動機編からDS1621xs+拡張序章編[2022/01/04] [Synology] Wi-Fiルーター RT2600ac/RT6600axをSoftbank Airに接続してワイヤレスAPとして使用する – 次世代ルーターRT6600についても解説 [2022/10/11]

More posts