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を定期的に確認しています。

図1. ログセンターは毎日確認
Log Center
Log Centerが少しトリッキーなので、少し注意点と簡単な使用方法を以下に示しておきます。
- 注意点、概要とログのタグページがありますが、表示内容がなぜか一致していない。概要ページのログには記録されているログインの失敗情報がログページで接続(connection)表示させても、その情報が無い場合がある。
- 使い方、表示を一般から接続(connection)にして警告(warning)を確認する。
- 今回のケースでは、DSMへのログインの失敗が約4分間隔で記録されていた。以下に開設している今日までの設定では、Mail Serverへのattackには効果がありました。しかし、DSMへのattackに対しては、attack自体を許しており、そのため記録が残っている。
これまで2回のattackに対する設定概要
- 前回のケースであるMail Serverへのattackの対策は、以下の「基本設定」以降に詳しく解説しています。
- 今回のケースであるDSMへのLog in attackの対策は、追加事項として、ここに示しておきます。
- DSMへのログイン(log in)では、ポート番号が知られてしまっているため、attackを許していると考えて以下の対策で解決しました
- コントロールパネル→ネットワーク設定→DSM設定
- ポート番号の変更と適用。モグラ叩き的な対策ですが有効な対策の一つです(2021/08/01)。
- DSMのポート番号は、PhotoStationやCalenderなどに使われているので、クライアントからの接続設定も更新しておく必要もあります。