Squid 経由で 8443ポートの https サイトにアクセスした際にユーザ認証が通らなかった件

先日、Mac にSquidをインストールしプロキシを構築しました。

http://k2-ornata.com/mac_squid_install/

その後、通常の https 443ポートへの通信はSquid経由で問題なくアクセスできていたのですが、8443 ポートのWebサイトでユーザ認証を行おうとすると、いくらやっても認証が通りませんでした。

443以外のSSLポートは追記が必要

しばらくなぜだろうと考えていたのですが、あるサイトを見て Squid はデフォルトでは SSLポートとして 443しか認識してくれないことがわかりました。

そこで以下の通り、acl SSL_ports port の行に 8443を追加して Squidを再起動してみたところ、ユーザ認証が通るようになりました。

#
# Recommended minimum configuration:
#

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
# acl localnet src 0.0.0.1-0.255.255.255        # RFC 1122 "this" network (LAN)
acl localnet src 10.0.0.0/8             # RFC 1918 local private network (LAN)

・・・

acl SSL_ports port 443 8443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http

#
# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
http_access deny !Safe_ports
・・・

しかし、ユーザ認証が通らなかった時にもログイン画面までは表示されていたのが不思議です。もしかしたらあればキャッシュデータだったのだろうか?

参考サイト

(Squid)Proxy経由だとHTTPSが403になる(情弱エンジニアだいありー)
https://www.lab.ocean-cloud.org/2021/12/22/squidproxy%E7%B5%8C%E7%94%B1%E3%81%A0%E3%81%A8https%E3%81%8C403%E3%81%AB%E3%81%AA%E3%82%8B/

CentOS の firewalld にて特定の送信先のみにアウトバウンド通信を制限してみた

インターネットにアクセスする際に特定のプロキシサーバ経由でないとアクセスできないことを想定し、CentOS の firewalld にてアウトバウンド宛の通信を特定のアドレス(Proxyサーバ)のみに制限してみました。

なお、アウトバウンドの通信を制限するには、ダイレクトルールというものを利用しなければならないようです。

1.特定のIPアドレス宛のアウトバウンド通信を許可する

10.XX.XX.XX宛の通信を優先度1で許可します。この時、制御するNICのインターフェイスを “-o”オプションで指定しています。

$ sudo firewall-cmd --permanent --direct  --add-rule
ipv4 filter OUTPUT 1 -d 10.XX.XX.XX/32 -o enp0s5 -j ACCEPT

ちなみにACCEPTはすべて大文字にする必要がありそうです。
小文字にしていると、リロードするときにエラーが発生します。

2.それ以外の宛先のアウトバウンド通信をブロックする

それ以外の通信をどう表現するのか少し悩みましたが、”0.0.0.0/0″で良さそうでしたので、優先度2として下記のとおり設定しています。

$ sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 2 -d 0.0.0.0/0 -o enp0s5 -j DROP

3.設定を確認する

1.2.の設定は “/etc/firewalld/direct.xml”に書かれるので確認してみます。

$ sudo  vi /etc/firewalld/direct.xml

ちなみに直接このファイルを編集してみましたが、うまくいかなかったことがあるので、1.2.のようにコマンドで設定するのがようさそうです。

4.設定を有効化(リロード)する

3.で確認した設定を”–reload”オプションで有効化します。

$ sudo firewall-cmd --reload
success

5.有効化された設定を確認する

“–get-all-rules”で有効化されているルールを確認することが可能です。

$ sudo firewall-cmd --direct --get-all-rules
ipv4 filter OUTPUT 1 -d 10.XX.XX.XX/32 -o enp0s5 -j ACCEPT
ipv4 filter OUTPUT 2 -d 0.0.0.0/0 -o enp0s5 -j DROP

Macに Squidを導入してゲストOSから経由させようとしたときにHTTP 403エラーが発生した件

先日、MacにSquidをインストールしました。

http://k2-ornata.com/mac_squid_install/

その時は、Parallels Desktop上に構築したゲストOSからもその Squidを経由してインターネットにアクセスできていたはずなのですが、再度、Squidを起動してゲストOSからアクセスしたところ、以下のエラーが発生してインターネットに接続できませんでした。

$ curl https://www.google.co.jp/ http://(SquidのIPアドレス):3128
curl: (56) Received HTTP code 403 from proxy after CONNECT

そこでいろいろ調べてみたところ、squid.conf の localnet まわりの設定を変更しないといけないことがわかりましたので、その方法を記載しておきます。

squid.conf を修正

上で記載したとおり、localnet まわりの設定を修正します。

まずは、squid.conf の先頭付近にある「acl localnet src」を修正します。
ここでは、Squidにアクセスする端末(今回はゲストOS)があるネットワークのセグメントをlocalnetとして設定しておきます。

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed

acl localnet src 10.0.0.0/8             # RFC 1918 local private network (LAN)

その後、同じsquid.confの65行目付近にある「http_access allow localnet」のコメントアウト(#)を外しておきます。

# For example, to allow access from your local networks, you may uncomment the
# following rule (and/or add rules that match your definition of "local"):
http_access allow localnet

これで、10.0.0.0/8 のネットワークにある端末からSquidにアクセスできるようになっているはずです。

再度、Squid経由でアクセス

以下の通り、今度は目的のサイトからデータを取ることができました。

$ curl https://www.google.co.jp/  http://(SquidのIPアドレス):3128
<!doctype html>
・・・
<title>Google</title>
・・・

Squidをインストールした日は特に squid.conf を修正しなくてもインターネットにアクセスできた気がしていて解せないなのですが、うまくアクセスできるようになったので良しとしておきます。

CentOS にWiresharkをインストールしてみた

CentOS にインストールしたアプリからのパケットの流れを確認したくて、Wireshark をインストールしてみました。

インストール

インストールは非常に簡単です。以下のコマンドを実行するだけです。

$ sudo yum -y install wireshark
・・・
完了しました!

インストールが完了したら、以下のコマンドでバージョンを確認してみましょう。バージョンが確認できたら、インスール は成功していると思われます。

$ tshark -v
TShark (Wireshark) 2.6.2 (v2.6.2)

キャプチャ対象インターフェイスの確認

そしてキャプチャ対象インターフェイスの確認です。以下のコマンドを実行します。

$ sudo tshark -D
Running as user "root" and group "root". This could be dangerous.
1. enp0s5
2. lo (Loopback)
3. any
4. virbr0
5. bluetooth-monitor
6. nflog
7. nfqueue
8. usbmon0
9. usbmon1
10. usbmon2
11. usbmon3
12. usbmon4
13. virbr0-nic
14. ciscodump (Cisco remote capture)
15. sshdump (SSH remote capture)
16. udpdump (UDP Listener remote capture)

このときに、sudo を実施しないと、すべてのインターフェイスが表示されないことがありますので注意してください。

キャプチャの開始

そして以下のコマンドで指定したインターフェイスのキャプチャを開始します。

$ sudo tshark -i enp0s5
Running as user "root" and group "root". This could be dangerous.
Capturing on 'enp0s5'
    1 0.000000000 fe80::c097:faee:3e33:5960 → fe80::21c:42ff:fe00:18 DNS 100 Standard query 0xd31d A adservice.google.com
    2 0.000033477 fe80::c097:faee:3e33:5960 → fe80::21c:42ff:fe00:18 DNS 100 Standard query 0x8f21 AAAA adservice.google.com
    3 1.595906174  10.211.55.8 → 13.225.165.40 TLSv1.2 93 Application Data
・・・

sudo で実行すると dangerous と言われますが、sudo をつけないと enp0s5 をキャプチャできないのでやむなしです。

Mac にプロキシ(Squid)をインストールしてみた

Parallels DesktopのゲストOS(CentOS)からプロキシ経由でのインターネットへのアクセスを確認をする為に、Macに Squidをインストールしてみました。

インストール

Macへの Squidのインストールは簡単です。
以下のとおりHomebrewを利用してインストールするだけです。

% brew install squid
Updating Homebrew...
・・・
Pruned 1 symbolic links and 7 directories from /usr/local
==> Caveats
==> squid
To restart squid after an upgrade:
  brew services restart squid
Or, if you don't want/need a background service you can just run:
  /usr/local/opt/squid/sbin/squid -N -d 1

Squidの起動

Squidの起動も簡単です。以下のコマンドを実行するだけです。
(インストール直後のメッセージに再起動の方法などが書かれていましたね。)

 % brew services run squid
==> Tapping homebrew/services
Cloning into '/usr/local/Homebrew/Library/Taps/homebrew/homebrew-services'...
remote: Enumerating objects: 2414, done.
remote: Counting objects: 100% (2414/2414), done.
remote: Compressing objects: 100% (1128/1128), done.
remote: Total 2414 (delta 1120), reused 2339 (delta 1098), pack-reused 0
Receiving objects: 100% (2414/2414), 658.87 KiB | 1.51 MiB/s, done.
Resolving deltas: 100% (1120/1120), done.
Tapped 1 command (45 files, 826.6KB).
==> Successfully ran `squid` (label: homebrew.mxcl.squid)

Squidの動作確認

Squidはデフォルトで 3128ポートで待ち受けするようですので、curl コマンドで試しにプロキシ経由で Googleに接続してみました。

% curl https://google.co.jp/ http://localhost:3128
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
・・・

Squidの設定変更

もしポート番号などを変えたければ以下の設定ファイルを修正すればよさそうです。

/usr/local/etc/squid.conf

Google AdSenseでようやく8,000円を達成したが、支払い情報設定にてこずった件

ブログを始めてからだいたい1年くらいかけて、ようやく支払い基準額の8,000円を達成したので、振込先の口座を設定しようとしたのですが、いろんな口座を設定してもまったく全く振り込まれませんでした。

原因がわからず困っていたのですが、ふとあるサイトを見ていたところ原因に気がついたのでここに記載しておきます。

もしかしたら、これが原因でなかなか振り込まれない人がいるかもしれません。

アカウントの種類は「普通」に変えよう

お支払い情報を追加する際に、銀行口座の名義の下に「アカウントの種類」を設定する画面があります。

ここ、デフォルトで「貯蓄」が入っているのですが、ここを「普通」に変えないといけませんでした。

人によっては当然でしょ、なのですが、私の頭の中では「貯蓄」=「普通」と思い込んでおり、また、ここを変える必要があるという発想がまったくなかったので気がつきませんでした。

Google AdSenseのお支払い情報設定画面

ここを「普通」に変えて再度登録したところ、2日後くらいには9円、Googleからお金が振り込まれており、それを確認金額として入力したところ、ついに8,000円とすこし、指定した口座に振り込みが行われました!

Googleから確認用の振り込みがおこわなれたところ

もし口座番号を何度変えても振り込まれない人がいたら、ここをチェックしてみるといいかもしれません。

銀行口座の名義について

なお、私が「アカウントの種類」の間違いに気がつくまでずっとここが原因ではないかたと疑っていたのが「銀行口座の名義」です。

この「銀行口座の名義」に設定する名字と名前の順番やその間にスペースがいるかどうかについては、

ミョウジ ナマエ

といった感じで、最初に名字(半角カタカナ)+半角スペース+名前(半角カタカナ)でうまくいきました。

銀行カードによってはアルファベットになっていると思いますが、その場合でも上の書き方で(たぶん)いけるのではないかと思われます。

SOARと連携させるActive DirectoryをWindows Server 2019上に構築してみた

SOARへのログイン連携や、SOARからのユーザ情報問い合わせの為に、MacにインストールしたParalleles Desktop上にWindows Server 2019をインストールし、その上にActive Directory機能をセットアップしてみました。

SOARと連携に必要なWin2019作業

SOARのAD連携用のインテグレーションと連携させるには、Windows Server 2019上に最低限、以下の機能を構築する必要があることがわかりました。

・Active Directory ドメインサービスのインストール
・DNSサービスのインストール
・AD上でのドメインユーザの作成
・DNSサービスでの前方参照ゾーンの設定(DNSをADと一緒に作成すると自動的に作成される。)
・DNSサービスでの逆引き参照ゾーンの設定

AD上でのドメインユーザ作成

SOARと連携させる際の認証ユーザを以下の通り作成しました。

ADでのユーザ作成(Microsoft Windows Server 2019)

MacのParallels Desktop上のWindows Server 2019にActive Directoryをインストールしようとしたらてこずった件

題名の通り、Mac OS上の Parallels Desktopに Windows Server 2019をインストールし、ADドメインサービスの機能追加をしようとしたところ、何度トライしてもインストールに失敗しました。

その後、いろいろ試したところ、Parallels Desktopの設定から、Mac – Windows間のファイル/アプリ共有の残らず無効にしたところ、正常にADドメインサービスがインストールできるようになったので、ここに記録しておきます。

Parallels Desktopの設定を変更

Parallels Desktopの設定画面1
Parallels Desktopの設定画面2
Parallels Desktopの設定画面3

Windows Server 2019の機能追加

Windows Server 2019

以下のように無事、ADドメインサービスの機能追加ができました。

Windows Server 2019

SentinelでService Principal Privilege Escalationのアラートが出た場合の対応方法をChatGPTに相談してみた

ChatGPT に以下の相談をしたところ、かなり的確に答えが返ってきたので、その回答も踏まえて対応方法を検討してみました。

SentinelでService PrincipalのPrivilege Escalationアラートが出た場合、誤検知かどうか判断する為に何を調べればいいですか?

以下、ChatGPTの答えとその考察です。

Step.1 ターゲットサービスプリンシパルのアクティビティログを調べる

ChatGPTの答え:
ターゲットのService Principalのアクティビティログを調べて、アラートが発生した時刻の前後のログを確認します。これにより、アラートが発生した原因を特定できる場合があります。

おそらく「Service Principalのアクティビティログ」とは「Azure Active Directory の監査ログ」のことを指しているのだと思います。

下記の「Azure Active Directory の監査ログ」のサイトを見ると、アプリケーション中心のビューを使用すると、「アプリケーションのサービス プリンシパルは変更されたか」に対する答えを得ることができると書かれています。

Azure Active Directory の監査ログ
https://learn.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/concept-audit-logs

Step.2 対象サービスプリンシパルのアクセス許可を確認する

ChatGPTの答え:
Service Principalに与えられたアクセス許可を確認し、アクセス許可が不適切なものがないかを確認します。アクセス許可の削除または変更が必要な場合は、それに従って対応を行います。

「アクセス許可が不適切なもの」とは、必要以上に権限が与えられていないか確認する、ということだと思います。

Spte.3 対象サービスプリンシパルの構成を確認する

ChatGPTの答え:
Service Principalの構成を確認して、異常があるかどうかを確認します。Service Principalの設定が不適切である場合は、それに従って対応を行います。

うーん、「Service Principalの構成」とはなんだろう?という感じですが、Step.2の「アクセス許可の削除または変更が必要な場合は、それに従って対応を行います。」と同義かなと思っています。

Step.4 ファイアウォールやセキュリティグループのログを調べる

ChatGPTの答え:
ターゲットサービスプリンシパルに対する不正なアクセスを防ぐために、ファイアウォールやセキュリティグループのログを調べて、アクセスがあったかどうかを確認します。

「ファイアウォールやセキュリティグループのログを調べて」とありますが、これは「Service Principal」によってファイアウォールやセキュリティグループ(ネットワークセキュリティグループ?)に変更が加えられていないか確認する、という意味じゃないかと思っています。

また実際にあやしいIPからアクセスがきていないかどうかも調べましょう、ということかなと思います。

ChatGPTにまた質問すれば、この疑問にも答えてくれるのかな?

参考:Azure のService Principalって何?

ちなみに最初、Service Principalってなんだろう?って感じだったのですが、以下の「SIOS TECH.LAB」さんのページにわかりやすく書かれており、大変参考になりました。

SIOS TECH.LAB
https://tech-lab.sios.jp/archives/23371

横浜国立大学の am I infected? で自宅のルータのセキュリティを調べてみた

色々な企業でVPNの脆弱性から社内ネットワークに侵入されている事例を見るにつれ、自分の家のルータは大丈夫かと心配しておりました。

そんな中、横浜国立大学さんの方からルータのセキュリティをチェックしてくれるサービスがあると聞き、さっそく試してみました。

1.感染チェック開始

DDoSを引き起こしてしまうようなマルウェアに感染していないかチェックするには、以下のサイトから3つの項目を入力して「感染診断をはじめる」のボタンを押すだけです。

am I infected?
https://amii.ynu.codes/

【入力項目】
・自分のメールアドレス(ここに検査結果がメールされる)
・現在の環境をプルダウンメニューから選択(自宅のルータかどうかなど)
・このサイトを知ったきっかけをプルダウンメニューから選択する

am I infected?(横浜国立大学)

2.チェック完了のメールが届く

感染チェックが完了すると、先ほど入力した自分のメールアドレスに届きます。

am I infected?からの検査結果メール

たしかWebには5分くらいかかりますと書いてあったと思いますが、実際には2〜3分くらいでメールが届きました。

3.チェック結果をWebで確認する

2.で届いたメールに書かれているリンクをクリックすると診断結果を確認できます。

我が家のルータは幸いにも安全な状態でした。ファームアップの連絡が届いたらすぐに適用しているので、それが幸いしているかもしれませんね。

診断結果(横浜国立大学)

みなさんも1度といわず、定期的にチェックしてみるといいと思いますよ。