Scribble at 2026-04-14 11:14:52 Last modified: 2026-04-14 11:24:44

このスクリーン・ショットは、ローカル・マシンで運用している Apache + PHP を使って、ブラウザのスタート・ページとして表示しているページの一部だ。JavaScript でパスワード文字列を生成したり、あるいはページを表示する際にベーシック認証の設定を勝手に生成したりしている。もちろん、ふだんはこれらを使って、オンライン・サービスのパスワードを設定したり、業務でウェブ・サーバを構築している。

これまで電通や博報堂、あるいは関西だと ADK やら JR 西日本コミュニケーションズや大広などといった、中堅から大手の広告代理店案件として、ナショナル・クライアントやグローバル企業、それから地方自治体のウェブサイトを構築したり運営してきた。いちばん近い事例だと、NDA があろうから具体的なことは言わないが、大阪関西万博に参加した地方自治体の公式サイトのサーバも運用してきた（というか、現在もクロージングに向けて運用している）。これは、もちろん自慢話をするのが目的ではなく、それだけ大手のサイトを手掛けるとなると、それだけ人々の注目を集めるのだから、攻撃にも晒されやすいということだ。いまでは大半の処理が自動化されているため、中小企業のサイトでも簡単かつ大規模に攻撃される恐れはあるが、やはりインパクトから言っても大企業や官公庁などのサイトは、そもそも複数の攻撃者から狙われやすいのであって、やはりいまでも高リスクであり強い脅威にさらされていることに違いはない。そして、これはもちろん自慢だが、前職から合計すると25年くらいにわたって、僕が運用しているサーバへ侵入されたり、ファイルを改竄されるといった被害を受けたことは一度もない。これは、ひとまず実績の一つとして数え上げてもよいのだろう。（厳密には常にブルートフォースの攻撃はあるし、前職では一回だけ TCP/IP を偽装した SYN-Flood 攻撃を受けたことがある。コンテンツの被害はないが、サーバがアクセス不能になったわけだから、これはこれで被害を受けた数少ない事例になる。）

最初にはっきり言っておくと、これはもちろん良いこととは限らないが、僕は実務で SELinux を有効にしたことは一度もない。それだけ脆弱なウェブ・サーバを構築し運用してきたという自覚なり反省はあるが、SELinux は有効にするべきと言われながら殆どまともなドキュメントも書籍も存在していないのに、取り扱いを間違えた際に特権ユーザすらサーバへアクセスできなくなるという致命的なリスクがある以上は、こういう危険なものは導入できない。皮肉なことだが、「わたし、ミスしないので」などと称する RPA や生成 AI や東大の新卒ですら無自覚に深刻な間違いを犯すのであるから、そのたった一度が取り返しのつかない結果になるからには、業務に導入することは逆に可用性レベルがゼロになるリスクを高めるだけだ。

そして、僕はおおよそウェブ・サーバのエンジニアを始めた頃からずっと、パスワード認証では文字列を24桁以上にする習慣を維持してきたし、例の「定期的な変更」というアドバイスも昔から無視してきた。たったこれだけが原因かどうかは分からないが、最初に強力なパスワード文字列を設定すれば、５年でも10年でも解析なんてされやしないというのが実感としてあったからだ。加えて、サーバに対して過剰な回数のブルートフォース攻撃があれば、OSSEC などの機構によって、最も長い設定をした事例では一ヶ月くらい同じ IP アドレスからのアクセスを遮断するようなこともやってきた。１秒間に１回の認証エラーであろうと、それが繰り返して実行されていれば不正アクセスの疑いを判断できる。よって、ブルートフォース攻撃で解析できる高性能なマシンやクラウドを使った一斉アクセスがあろうと、現実的な有限時間で24桁のパスワードを解析することは難しい。おまけに、相当な数の国の IP アドレスは最初からアクセスを遮断している。ナミビアの人間が日本語で運営されているサイトへアクセスできなくても問題ないし、ナミビアに旅行している日本人がアクセスできなくても知ったことではない。そういう割り切りをしてきたのが、サーバの強さの理由の一つでもあろう。上場企業や地方自治体のサイトだからといって、「開かれている」などという自己目的化した観念しか指標がない、インチキな民主主義やグローバリゼーションを採用する必要はない。