サーバからInternetへ自由に出さない #10｜内部SquidでOutbound通信を制御する

この記事で分かること

• ServerのOutboundをProxyへ寄せる理由

• 「侵入を防ぐ」だけではなく「侵入後の外向き通信」を見る考え方

• FortiGate NATでSource IPが同一に見えた時に何が起きたか

• TCP_DENIED/403 CONNECT をどう切り分けたか

• ip route get / tcpdump / Squid access.logを組み合わせる理由

⏪ 前の記事：#9 80/443を開けるだけでは守れない

#9では「外から入ってくる通信」を一段ずつ止めた。

でも、入口だけ守っても終わらない。

もしServerが侵害された後、外へ自由に通信できたらどうなるか。

C2、追加Payload、情報送信。

侵入後の出口も、攻撃経路になる。

もちろんServerはInternetへ通信する。

OS Update。

Package Repository。

GitHub。

外部API。

証明書。

時刻同期。

「中から外だから安全」とは限らない。

そこでServer系のOutboundも、可能な範囲で内部Squidへ寄せている。

目的は「全部禁止」ではない

ServerからInternetを完全に遮断すると運用できない。

必要なのは、

外へ出る理由を説明できる状態にすること

だった。

Server
↓
Internal Squid
↓
FortiGate
↓
UCG-Fiber
↓
Internet

こうするとProxy Logに、

• どのServerが

• どこへ

• いつ

• どのProtocolで

出ようとしたかを残しやすい。

侵入後の通信も考える

Firewallは侵入を防ぐためだけにあるわけではない。

もしServerが侵害された場合、

その後で外部へ自由に通信できれば、

• C2

• 追加Payload取得

• 情報送信

• 別SiteへのScan

などに使われる可能性がある。

だから、

入らせない + 入られた後も好きに出さない

の両方を見る。

家庭内でここまで必要かと言われると、普通はやりすぎだと思う。

でも公開Serviceと自宅Serverを同じ環境で運用するなら、Outboundを全許可するより観測可能な方が安心できる。

ただしProxyを置けば全部解決するわけではなかった

実際にハマったのがSource IPだった。

FortiGate側のPolicy NATを通した結果、Squidから見ると複数Clientが同じ送信元に見える状態になった。

すると、

「どのServerから来たのか」

をSource IP ACLで正しく判定できない。

Proxy側では、

TCP_DENIED/403 CONNECT

が出る。

最初は、

• c-icapか

• TLSか

• Upstreamか

まで疑った。

でも、TCP_DENIED/403の段階ならSquid自身が入口で拒否している。

後段を調べる前に、まずSquidへ到達した時点のSourceとACLを見るべきだった。

ip route get と tcpdump が効く

こういう時にGUIだけ見ても分からない。

実際に使うのは地味な確認だ。

ip route get <destination>

どのInterface / Gatewayから出る予定かを見る。

そして、

tcpdump -ni <interface> host <target>

で、実際にどのSource/DestinationでPacketが流れているかを見る。

さらにSquid access.logと突き合わせる。

OSが考えるRoute
↓
Wire上のPacket
↓
Proxyが認識したClient

この3つが一致しているかを見る。

NATは便利だが、観測情報を変える

NAT自体が悪いわけではない。

でも、NATするとSource Addressが変わる。

Security PolicyやACLがSource Identityに依存している場合、その影響を考えなければならない。

Network機器では正しく見えている。

Proxyでは全部同じClientに見える。

そういうことが起こる。

この経験から、

通信が通るかだけではなく、各Layerから「誰に見えているか」も確認する

ようになった。

Outbound制御はログ設計とセット

Proxyへ寄せてもLogを見なければ意味がない。

異常が起きた時に、

• FortiGate

• Squid

• c-icap

• OS

• DNS

のどこで止まったかを追える必要がある。

そこで次にやったのが、Network機器とServerのLog集約だった。

これも簡単にはいかなかった。

Log Serverは514で待っている。

なのにLogが来ない。

原因はrsyslogではなく、途中のRoutingだった。

⏩ 次回：侵入の気配に、どこで気づく？｜自宅ネットワークのSyslog・Fluentd・Elasticsearch・ElastAlert監視【番外編】