Future Tech Blog
フューチャー技術ブログ
Infrastructureカテゴリ

ローカルプロキシで認証プロキシの煩わしさを解消！

はじめに

多くの企業では、セキュリティ対策の一環として認証プロキシを導入しています。これは、社内ネットワークからインターネットへのアクセスを制御し、不正なアクセスや情報漏洩を防ぐための重要な手段です。しかし、この認証プロキシを利用する際には、ユーザ名とパスワードの入力が必要であり、ソフトウェアごとにプロキシ設定する必要があります。これが、日々の業務において非常に煩わしい作業となっています。

今回は、この問題を解決するために、自分専用のローカルプロキシをセットアップし、認証プロキシの設定を一元管理する方法についてご紹介します。

認証プロキシの課題

認証プロキシを利用する際の主な課題は以下の通りです。

  • 設定の煩雑さ：各ソフトウェアごとにプロキシ設定する必要があり、設定漏れや誤設定が発生しやすい。
  • 認証プロキシ非対応ソフトウェアの存在：使用したいソフトウェアによっては、プロキシには対応しているものの認証には対応していない物1がしばしば存在する。
  • 認証情報の管理：ユーザ名とパスワードを多くの設定ファイルや環境変数に記載する必要があり、セキュリティリスクが高まる。ファイルが漏出しないよう、またリモート会議などでうっかりそれらを映してしまわないよう気を配る必要がある。
  • パスワード変更の手間：パスワードポリシーによってはパスワードを変更する機会があり、その都度、多くの設定を更新する必要がある。
画像1.png

これらの課題を解決する方法として、手元のPCにローカルプロキシを立てて認証を肩代わりする方法をご紹介します。

画像2.png

ローカルプロキシのセットアップ

ローカルプロキシをセットアップすることで、認証プロキシの設定を一元管理し、上記の課題を解決できます。多くのオープンソースソフトウェアが利用可能で、例として「Squid」や「CNTLM」、「stone」などが挙げられます。ここでは例として「mitmproxy」を取り上げます。具体的な手順は以下の通りです。

1. mitmproxy のセットアップ

mitmproxy は Python プログラムです。インストール方法は複数あるので公式サイトを参照してください。

LinuxやWSL環境において最短でインストールするならパッケージリポジトリを（コミュニティ運営のため公式は積極的に推奨していませんが）使用して下記になります。

# aptでインストール
sudo apt update && sudo apt upgrade
sudo apt install mitmproxy
# pipでインストール
pip install mitmproxy
Python3環境構築からpipでインストールを実施するまでの手順はこちら 
sudo apt update
sudo apt upgrade
sudo apt install dirmngr ca-certificates software-properties-common apt-transport-https -y
sudo gpg --list-keys
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/deadsnakes.gpg --keyserver keyserver.ubuntu.com --recv-keys F23C5A6CF475977595C89F51BA6932366A755776
echo 'deb [signed-by=/usr/share/keyrings/deadsnakes.gpg] https://ppa.launchpadcontent.net/deadsnakes/ppa/ubuntu jammy main' | sudo tee -a /etc/apt/sources.list.d/python.list

sudo apt update
sudo apt install python3.8 -y
sudo apt install python3-pip

python3 -m pip install --upgrade pip setuptools
pip install mitmproxy

GitHub から clone して実行する手もあります。

Docker を使った簡単な導入方法もありますが起動方法込みになるので次章にて纏めて記述します。

2. mitmproxy の実行

導入形態によって変わりますので以下に列挙します。

※社内向け認証プロキシにありがちな独自証明書対策としてオプションに --ssl-insecure を使用したいケースもあります。

バイナリ単体の場合

mitmweb --mode upstream:http://[認証プロキシ]:[ポート]

Python スクリプトの場合（Windows）

.\venv\Scripts\activate
mitmdump --mode upstream:http://[認証プロキシ]:[ポート]

Python スクリプトの場合（Linux or WSL）

source ./venv/bin/activate
mitmdump --mode upstream:http://[認証プロキシ]:[ポート]

Docker の場合

docker run --rm -it -v ~/.mitmproxy:/home/mitmproxy/.mitmproxy -p 127.0.0.1:8081:8081 -p 8080:8080 mitmproxy/mitmproxy mitmweb --web-host 0.0.0.0 --mode upstream:http://[認証プロキシ]:[ポート]

コンテナの /home/mitmproxy/.mitmproxy には mitmproxy が生成する証明書が格納されます。run するたびに新たに生成されるとその都度証明書のインポートが必要になるのでこの例では永続化させていますが、一度 run した後はコンテナを使い回して start する運用とする場合にはこの考慮は不要です。

3. mitmproxy に認証プロキシの認証情報を設定

http://localhost:8081/ を開いて、 Options -> Edit Options -> upstream_auth に本来の認証情報を [user]:[pass] 形式で記入します。保存ボタンは無く、フォーカスを外せば設定完了です。

mitmproxy の起動コマンドに認証情報を書く事が気にならない方は、起動時のオプションに --upstream-auth [user]:[pass] を加える事でこのステップは無視できます。またその場合は起動コマンドを mitmweb ではなく mitmdump にすればWeb UIが起動しないので省リソースです。

4. ソフトウェアのプロキシ設定をローカルプロキシに変更

各ソフトウェアのプロキシ設定を、ローカルプロキシのアドレス（通常はlocalhost:8080）に変更します。これにより、すべてのソフトウェアで共通のプロキシ設定を利用できるようになります。

HTTPS通信は mitmproxy を通る際に一旦復号され独自の証明書により再暗号化されるようになります。よって mitmproxy が使用する証明書のインポートが必要になります。ブラウザのプロキシを mitmproxy に設定した状態で http://mitm.it/ を開くと証明書をダウンロードする画面が開くので、プロキシのクライアントとなるOSごとに証明書のインポートを行ってください。
Windowsの場合は下記の手順になります。

  1. mitmproxy-ca-cert.p12 をダウンロード
  2. mitmproxy-ca-cert.p12を実行（ダブルクリック）
  3. 保存場所：「現在のユーザ」
  4. ファイル名：変更しない
  5. パスワード：変更しない（空欄のまま）
  6. 「証明書をすべて次のストアに配置する」を選択して「参照」->「信頼されたルート証明機関」
  7. 完了

他にも証明書の参照先が異なる物は対応が必要です。

# WSL
sudo mv mitmproxy-ca-cert.pem /usr/local/share/ca-certificates/mitmproxy.crt
sudo update-ca-certificates

# Java
keytool -importcert -alias mycert -file mitmproxy-ca-cert.pem -keystore $JAVA_HOME/lib/security/cacerts -storepass *****

# Git
git config --global http.sslCAInfo mitmproxy-ca-cert.pem

注意点

  • Windowsでローカルプロキシを起動する場合、Windowsホスト上でそのまま起動するか、WSL上で起動するかといった選択肢があります。Windows上でそのまま起動した方がオーバーヘッドも無くWSLの起動状態に関わらず使用できるので便利ですが、WSLからWindows上のホストを通すにはWSL側で幾つか追加の手順が必要になると思います（WSLから見たホストマシンはIPアドレスが毎回ランダムで、かつ Docker でいう host.docker.internal のようなホスト名も無いので名前解決方法を実装する必要がある）
  • 更に簡略化する方策として、ローカルプロキシを透過プロキシ化してプロキシの設定自体を無くしてしまう手もありますが、期待通りプロキシが空気のような存在となった頃に思わぬ不具合を踏んで原因追及に手間取ることも考えられるのでその点は留意が必要です

まとめ

認証プロキシの設定に伴う煩雑さは、多くの企業で共通の課題です。ローカルプロキシを導入することで、これらの課題を効果的に解決し、よりスムーズで安全なネットワーク環境を構築できます。ただし、導入にあたってはセキュリティ対策やネットワークポリシーの確認が必要ですので、注意が必要です。

今回ご紹介した方法が、認証プロキシの煩わしさに悩む多くの方々にとって、有効な解決策となることを願います。

  1. 1.例： AIエディタのCursorのインストーラ等 ↩