COVID-19の蔓延によりテレワークが推進されています。外出して罹患したり、気付かないうちに誰かを感染させてしまわないためにも重要な取り組みです。
ですが、悪いことを考える人間はこんな状況下でも構わず活動しています。
テレワークを支える基本インフラとして、従業員宅と社内システムを繋ぐ回線には多くの場合、従業員宅のインターネット回線を使用することになるでしょう。しかしながら、その回線は多くの場合安全ではない。会社貸与PCではなく、私物を使用する場合は端末自体の安全性も担保されない。といった基本認識をもってテレワーク環境を構築しないと危ないですよ*1。
※本投稿は単なる参考情報で、情報セキュリティの完全性や網羅性を担保するものではありません。
前提
以下の観測値は、私が契約している国内大手プロバイダの一般個人向けの普通のインターネット回線の場合のものです。特殊なインターネット回線ではなく、おそらくあなたの回線でも似たような状況となっていると考えられます。
自宅ルータのログを収集してデータベースに集約後、データを整理して図表化したものです。ほとんどの人は(ログを見たりしないから)気付かないだけで、インターネット環境は危ないところだという基本認識を持つための情報です。
2020年4月時点の1日辺りの不審な接続試行回数
左軸の棒グラフが回数ベース、右軸の折れ線グラフが前年比を表していますが、今年は明確に増えてます。さすがに4月の伸び率はおかしいような気がしますが、後述の異常値を除外したとしても今年4月は一日平均5498.4回、前年比173.2%となります。
今年4月に1日辺り100回以上の不審な接続が試行されたポート
4/6のSSDP(UDP#1900)が92890回と突出しています。他のポートの状況が見えないので、最大値を10000に絞って同じグラフをプロットします。
4/6のSSDPに次いで多く試行されたのが4/7と8のTCP#58742です。このポート何なんでしょうかね、Well-knownなポートでも無さそうですし、軽く調べてみても既知の有名な攻撃で使用されてそうでもありません。Appleの「Xsan ファイルシステムアクセス」で使用するのかもしれませんが、家には常時稼働してるMacOS/iOS端末はありませんし。
Apple ソフトウェア製品で使われている TCP および UDP ポート - Apple サポート
その次が、4/8のmDNS(Multicast DNS)で使われるUDP#5353です。これを悪用する例は数年前から確認されているようです。機器やOS情報を調べて、攻撃/侵入方法が明らかなら実際に攻撃/侵入しようとしているのかもしれません。
JVNVU#98589419: マルチキャスト DNS (mDNS) 実装が外部からのユニキャストクエリに応答する問題
その次、ほぼ毎日telnet(TCP#23)が200～600回程度狙われています。軽自動車に軽油を入れてしまう人が存在するように、「テレワークだからテルネット使えるようにしなさい！」みたいなアホなことを指示する上司は居ませんよね。COVID-19が終息するまでの暫定対応だからといって、社内システムと従業員宅間をインターネット経由でtelnetアクセスできるようにするような行為は絶対にしてはいけません。パスワードを含むアカウント情報が盗まれる可能性があります、それを使ってサーバー内の情報が盗まれたり破壊される可能性があります。
その次、TCP#445はWindowsファイル共有が使うポートです、一日に200回前後も狙われています。社内のファイルサーバーに従業員宅からアクセスできないからと言って、何も考えずにインターネットに公開してはいけません。パスワードを含むアカウント情報が盗まれる可能性があります、それを使ってサーバー内のファイルが盗またり破壊されたりする可能性があります(SMBv3なら暗号化設定もできるようですが)。
その次、TCP#80はHTTPですが、一般のホームページが公開されてると思ってアクセスしてきているのではないでしょう。ルーターなどの機器管理画面にアクセスできないか試行し、ログイン画面が表示されたら機器出荷時のデフォルトパスワードなどで不正アクセスを試みるのだと考えられます。
その次、TCP#1433はSQLサーバーが使います。DBサーバーをインターネットに公開することは通常ないはずですが、従業員宅からメンテできないと困るとか言ってインターネットに公開してはいけません。
このグラフには載っていませんが、Windowsのリモートデスクトップで使用するTCP#3389も一日50回前後は狙われています。今だけだからインターネット経由で会社のPCにアクセスできるようにしちゃえ、みたいな安易な行動は大変危険です。
4月の異常値
前述の4/6のSSDP(UDP#1900)が92890回というのは流石に多すぎます*2ので、少し調べてみました。SSDP refrection attackと呼ばれる攻撃に利用されているようです。
UPnPに対応したネットワーク機器を踏み台としたSSDPリフレクター攻撃に対する注意喚起について - 警察庁(PDF)
ルーター等のUPnP対応機器に対して、SSDPのM-SEARCHというメッセージを送信元を偽装して送信し、そのレスポンスが偽装されたホストに送信される。偽装されたホストには大量のレスポンスが殺到し、DoS攻撃を受けた状態に陥らせるという攻撃手法のようです。ですから、不正アクセスやデータ漏洩など自分に実害は生じなくても、偽装されたホスト(被害者)に対しての攻撃に加担していることになってしまいます。
4/6に1000回以上SSDP(UDP#1900)で通信を試行してきたIPアドレス(偽装されていると考えるなら、これは被害者のIPアドレスで本当の攻撃者のIPアドレスは不明)を集計すると、単独のIPアドレスだけで7万回近くになることが解りました*3。
このIPアドレスがSSDPで通信を試行してきた時間帯を集計すると、13時から17時にかけて13時と16時台は3万回前後、すなわち約1分で500回も通信を試行してきたことが判ります。
単純計算すると毎秒8回、(自分の集計方法がおかしかったりDBが壊れてる可能性も考慮して、)念のため生ログを確認したら、本当に同一ホストから毎秒10回前後UDP#1900に対する通信があった(が切り捨てた)ことが記録されていました。
2020-04-06T16:05:29 router kernel: DROP IN=ppp0 OUT= MAC= SRC=180.188.***.*** DST=MY.IP.AD.DR LEN=118 TOS=0x00 PREC=0x00 TTL=242 ID=33872 PROTO=UDP SPT=22852 DPT=1900 LEN=98 2020-04-06T16:05:30 router kernel: DROP IN=ppp0 OUT= MAC= SRC=180.188.***.*** DST=MY.IP.AD.DR LEN=118 TOS=0x00 PREC=0x00 TTL=242 ID=14460 PROTO=UDP SPT=15657 DPT=1900 LEN=98 2020-04-06T16:05:30 router kernel: DROP IN=ppp0 OUT= MAC= SRC=180.188.***.*** DST=MY.IP.AD.DR LEN=118 TOS=0x00 PREC=0x00 TTL=242 ID=27904 PROTO=UDP SPT=18675 DPT=1900 LEN=98 2020-04-06T16:05:30 router kernel: DROP IN=ppp0 OUT= MAC= SRC=180.188.***.*** DST=MY.IP.AD.DR LEN=118 TOS=0x00 PREC=0x00 TTL=242 ID=10077 PROTO=UDP SPT=24145 DPT=1900 LEN=98 2020-04-06T16:05:30 router kernel: DROP IN=ppp0 OUT= MAC= SRC=180.188.***.*** DST=MY.IP.AD.DR LEN=118 TOS=0x00 PREC=0x00 TTL=242 ID=27384 PROTO=UDP SPT=39327 DPT=1900 LEN=98 2020-04-06T16:05:30 router kernel: DROP IN=ppp0 OUT= MAC= SRC=180.188.***.*** DST=MY.IP.AD.DR LEN=118 TOS=0x00 PREC=0x00 TTL=242 ID=38526 PROTO=UDP SPT=5587 DPT=1900 LEN=98 2020-04-06T16:05:30 router kernel: DROP IN=ppp0 OUT= MAC= SRC=180.188.***.*** DST=MY.IP.AD.DR LEN=118 TOS=0x00 PREC=0x00 TTL=242 ID=15004 PROTO=UDP SPT=10013 DPT=1900 LEN=98 2020-04-06T16:05:30 router kernel: DROP IN=ppp0 OUT= MAC= SRC=180.188.***.*** DST=MY.IP.AD.DR LEN=118 TOS=0x00 PREC=0x00 TTL=242 ID=42226 PROTO=UDP SPT=12539 DPT=1900 LEN=98 2020-04-06T16:05:30 router kernel: DROP IN=ppp0 OUT= MAC= SRC=180.188.***.*** DST=MY.IP.AD.DR LEN=118 TOS=0x00 PREC=0x00 TTL=242 ID=40660 PROTO=UDP SPT=26085 DPT=1900 LEN=98 2020-04-06T16:05:31 router kernel: DROP IN=ppp0 OUT= MAC= SRC=180.188.***.*** DST=MY.IP.AD.DR LEN=118 TOS=0x00 PREC=0x00 TTL=242 ID=31727 PROTO=UDP SPT=46091 DPT=1900 LEN=98
ログからはパケット内容までは判りませんので、これがSSDP reflection attackで使われるM-SEARCHメッセージなのかは断定できません。
この攻撃を試行した側では送信元を偽装しているため、(私のルーターが実際にはこの通信を切り捨てているが)レスポンスがあったか無かったかを識別することができないため、偽装したIPアドレスに私のルーターからのレスポンスが殺到していることを期待してM-SEARCHパケットを送り続けているのではないかと想像されます。
テレワーク環境構築に向けて
今からゼロトラストネットワークの思想で社内の全アプリケーションを改修して、一般のインターネットからでも安全にWebアクセスできるようにする。なんてことは短期間では不可能です。社内の各種サービスを外から安全に使えるようにしたければ、社内N/WにVPN経由でアクセスできる環境を整備するのが、最も現実的なソリューションとなるでしょう。ただし、VPNでセキュリティを担保できるのは通信経路のみですから、VPNアクセス用の認証情報が漏洩して悪用されれば社内システムは危機にさらされます。
また、VPNアクセスする端末が会社貸与PC以外の場合、クライアント端末のセキュリティ確保も必要です。マルウェアやウイルス感染した個人PCから社内N/WにVPN接続されたなら、社内N/Wにマルウェアやウイルスが侵入したも同然です。個人PCの使用を許可した場合、業務内容や社内情報システムによっても事情は異なるでしょうが、業務データや業務上扱う個人情報が従業員の私物PCに保存される可能性があることも注意が必要です。たとえマルウェアやウイルスに感染していなくても、悪意や不注意で外部に流出したり複製を作られる可能性もあります。これらのことから、会社貸与PC以外の使用を認めないのが最も安全性が高いと考えられます。それでも、個人PCの使用を認めざるを得ず、個人情報保護法や社内情報保護規定などに照らして問題ない情報だけを扱う業務であれば、会社貸与PCと同等のセキュリティポリシーを徹底するためのツールや手順書の準備、あるいは会社貸与PCと同一のセキュリティソフト(アンチウィルスの類だけではなく、USBポートや記憶デバイスの使用制限等)を導入するためのソフトウェアライセンスなどが必要になるかもしれません。
元々VPN接続を想定して機器やマニュアルを準備している企業なら混乱は少ないでしょう。そうではない企業で、特に情報システム専任者がいないような企業は、たとえ機器購入費の金銭的な補助だけがあっても、全社員が使えるようになるまでのフォローアップがかなり大変かもしれません…。
蛇足ながら、VPNで会社にアクセスしている従業員は、VPN使用中は会社の回線でインターネットアクセスしていることになることに注意しましょう。うっかりVPN経由で変なサイトを見たりすると、会社がインターネットアクセスをモニタリングしていればバレますので真面目に仕事しましょう。
以上。
