カテゴリー: ガジェット Page 1 of 101

「時代はIPv6」と呼ばれてから四半世紀。未だにIPv4が幅をきかせているという状態。

• DNSの都合上、IPv4でないと困る
• IPv6は管理で手に負えない

等の問題を抱えている運用者（つまり私）のため、「カーネルレベルでIPv4のみにする」手順のメモです。

環境

• Ubuntu 24.04

そろそろUbuntu 26.04が出るタイミングではありますが、おそらく大幅な変化はないでしょう。

さっくりとした手順

1. 現状を確認します。
2. sysctlでIPv6を無効化するファイルを作成します。
3. 作成したファイルを有効化してIPv6を無効化します。
4. (利用している方は)ufw側の設定でIPv6を無効化します。

作業の前に

• 本作業はカーネルをいじります。つまり、神経を使うという作業です。
• 念には念を入れてサーバ再起動も伴います。

構築作業であれば好きなタイミングでサーバ再起動ができる環境を祝いましょう。
本番運用であればタイミングを調整する政治交渉が必要な環境を呪いましょう。

現状の確認

• IPv6アドレス割当の確認

ip -6 addr

アドレスが返ってくればIPv6アドレスは有効化されています。何も表示されていなければ、ここからの作業は不要です。

ファイル追記

cat <<- __EOF__ | sudo tee -a /etc/sysctl.d/99-disable-ipv6.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
__EOF__

元々存在しないファイルなのでコマンドで流し込みます。

設定反映

• 設定反映

sudo sysctl --system

エラーがなければOKです。

• 設定反映確認

ip -6 addr

IPv6アドレスが無いことを確認します。

• 念のためのサーバ再起動

sudo reboot

サーバ再起動を行います。

• 再起動後にIPv6がないことを確認

ip -6 addr

link-local IPv6のみが見えていればOKです。（NICの中でのみ使えるv6アドレスです)

（オプション）ufwでIPv6の無効化

※この作業はufwをいじります。ufwを有効化しているという方は、下手にいじると自分自身がロックアウトされる怖さを知っていると思います。

慎重に、深呼吸をするなり飲み物を飲むなどして落ち着かせてから作業を行いましょう。もっと具体的に言うと

• 物理環境であればコンソール近くにいること
• vps環境はWebコンソールを開いて
• SSH接続しかない場合は新規セッションで接続を維持する

の作業を推奨します。（この場合の推奨は義務という意味です

• ufw設定ファイルのバックアップ

sudo cp -pi /etc/default/ufw /path/to/backup/directory/ufw.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

• ファイルのバックアップ確認

diff -u /path/to/backup/directory/ufw.$(date +%Y%m%d) /etc/default/ufw

差分が無いことを確認します。

• ファイル修正

以下のような形で修正します。

IPV6=yes

これを

#IPV6=yes
#yyyy/mm/dd IPv6無効
IPV6=no

という形です。

日付管理をしないと「万が一のことがあったときにどっからおかしくなったか」を管理しやすくなります。同様に、コメントin/outとすることで切磋の対応をしやすくします。

• ファイル修正確認

diff -u /path/to/backup/directory/ufw.$(date +%Y%m%d) /etc/default/ufw

-IPV6=yes
+#IPV6=yes
+#yyyy/mm/dd IPv6無効
+IPV6=no

• ufw再起動

三回ぐらい深呼吸をしましょう。

sudo ufw reload

最終確認

• IPv6無効化確認

ip -6 addr

link-local IPv6のみが見えていればOKです。

• LISTENがない

ss -lntup | grep :::  

v6 のLISTENがないことを確認します。

• ufw確認

sudo ufw status verbose

IPv6に関わるルールが無いことを確認します。

まとめ

以上、「IPv6無効」と簡単に言うけれど、言うほど簡単では無いという作業でした。

インターネットの通信は、単にIPアドレスだけで動いているわけではありません。
その裏側には ASN（Autonomous System Number） という仕組みがあり、これが世界中のネットワークをつないでいます。

本記事では、

1. ASNとは何か
2. なぜ存在するのか
3. セキュリティ運用でどう役立つのか

を順番に解説します。

ASNとは何か

ASNは：

インターネット上の「組織単位の番号」

です。

もう少し正確に言うと：

独立したネットワークを運用する組織に割り当てられる識別番号

です。

例えば：

IPアドレスが「端末の住所」だとすると、ASNは「プロバイダや企業の名前札」

のようなものです。

なぜASNが必要なのか

インターネットは巨大なネットワークですが、実態は無数のネットワーク同士の集合体です。

各プロバイダ、クラウド事業者、大学、企業はそれぞれ独立したネットワークを持っています。

この独立した単位をAutonomous System（AS）

と呼びます。そしてその識別番号が ASNです。

郵便で例えると

• IPアドレス = 家の住所
• ASN = 市区町村

と考えていただくと分かりやすいでしょう。

郵便物はまず「市区町村」に届き、そこから各家庭へ配送されます。

インターネットでも：

1. まずAS単位でルーティング
2. その中でIP単位に配送

という仕組みになっています。

BGPとASN

ASNが本領を発揮するのは：

• BGP（Border Gateway Protocol）

というルーティングプロトコルです。

BGPは「どのネットワークがどのIPを持っているか」

を世界中で共有する仕組みです。

例えば：

このIPレンジはAS14618（Amazon）が持っています

という情報を各AS同士が交換しています。

これによって世界中のルータが最適な経路を選べる

ようになります。言い換えるなら、ASNとBGPがなければ、現在の規模のインターネットは成立しません。

セキュリティ運用でのASNの意味

サーバーログを見ると攻撃IPがどこから来ているかを知りたくなりました。

そこで、ASN単位でみることにしました。

なぜ運用者はASNを見るのか

筆者が運用しているVPSはONE OUTSという独自防御システムを敷いていますが、ここでの防御は

• IP単体BAN
• ASN単位防御

なぜなら、多くの攻撃者は海外の規制が緩いプロバイダ/組織を隠れ蓑にしています。

• 利用の際に厳格な身分証明がなく
• 当局の規制が緩い（どころかそういう行為を推奨している

（『鬼平犯科帳』で言うなら「盗人宿」の概念です。

実際の例

では、そういったASNをどのように調べるのか？

Linuxでは使いやすいコマンドが存在します。

whois -h whois.cymru.com " -v 8.8.8.8"

と打ってみます。（言わずと知れたGoogleのDNSです

AS      | IP               | BGP Prefix          | CC | Registry | Allocated  | AS Name
15169   | 8.8.8.8          | 8.8.8.0/24          | US | arin     | 2023-12-28 | GOOGLE - Google LLC, US

• ASN
• 国
• 事業者
• IPレンジ

が見えてきたという次第。これをサーバのログから調べるのはかなり困難なので、以下のようなワンライナーを組んでみました。

エラーログからIPを抽出し、一意にソートしてWHOIS情報（AS番号、国、事業者名）を取得します。

grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' /var/log/apache2/web_server_error.log \
| sort -u \
| while read ip; do
    whois -h whois.cymru.com " -v $ip" | tail -n1
  done

以下、無害化した解析結果テーブルです。（無害化に関してはAIの力を借りています

AS      | IP               | BGP Prefix          | CC | Registry | Allocated  | Info (Sanitized)
--------|------------------|---------------------|----|----------|------------|-------------------------------------------
58466   | 106.75.x.x       | 106.75.144.0/20     | CN | apnic    | 2011-03-23 | Major ISP / IDC Network (CN)
4837    | 123.139.x.x      | 123.138.0.0/15      | CN | apnic    | 2007-02-28 | China Network Backbone
8075    | 13.86.x.x        | 13.64.0.0/11        | US | arin     | 2015-03-26 | Global Cloud Service Provider (MS)
14061   | 144.126.x.x      | 144.126.208.0/20    | US | arin     | 2020-01-09 | Cloud Hosting / VPS Provider (DO)
212238  | 149.40.x.x       | 149.40.50.0/24      | US | arin     | 1992-01-28 | International Content Delivery Network
396982  | 162.216.x.x      | 162.216.150.0/24    | US | arin     | 2013-07-02 | Global Cloud Infrastructure (G)
51167   | 173.212.x.x      | 173.212.224.0/20    | DE | ripencc  | 2009-10-26 | European VPS/Dedicated Server Provider
211298  | 185.247.x.x      | 185.247.137.0/24    | GB | ripencc  | 2018-03-01 | Cyber Security Research Entity
213412  | 195.184.x.x      | 195.184.76.0/24     | FR | ripencc  | 2022-11-09 | Internet Scanning & Security Platform
398324  | 206.168.x.x      | 206.168.34.0/24     | US | arin     | 2022-10-26 | Global Threat Intelligence Scanner
14618   | 34.224.x.x       | 34.224.0.0/12       | US | arin     | 2016-09-12 | Global Cloud Services (AWS)
132203  | 43.153.x.x       | 43.153.0.0/18       | SG | apnic    | 1989-02-21 | Asia-Pacific Cloud Network (T)
6939    | 65.49.x.x        | 65.49.0.0/17        | US | arin     | 2007-10-04 | International Internet Backbone Provider
200593  | 91.202.x.x       | 91.202.233.0/24     | RU | ripencc  | 2008-03-03 | Eastern European Network Services

注意点

ログが数万行に及ぶ環境ではこの解析は膨大なものになります

head -50 /var/log/apache2/web_server_error.log | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' \
| sort -u \
| while read ip; do
    whois -h whois.cymru.com " -v $ip" | tail -n1
  done

とした方が良いでしょう。

まとめ

こうして、ASNを調べることができれば、先に示した「悪辣な攻撃を行うクローラー/攻撃者が潜む盗人宿」的な事業体/ASNという、「盗人宿」ごとの対策が容易に行えます。

悪を知らぬものが悪を取り締まれるか

という「鬼平」の言葉を元にログを調べていく手法について紹介しました。

aptitude(apt)で捕まったときのメモです。

発生した状況

Ubuntu 24.04 で sudo aptitude update を実行した際、Phusion Passenger リポジトリに対して以下のエラーおよび警告が発生しました。

• エラー:
  • 公開鍵を利用できないため、以下の署名は検証できませんでした: NO_PUBKEY D870AB033FB45BD1
• 警告:
  • Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

原因

GPG鍵の欠落:

システムが Passenger リポジトリのパッケージが真正なものであるかを確認するための公開鍵を持っていませんでした。

古い管理形式（非推奨）:

以前の Ubuntu で一般的だった apt-key による鍵登録を行っていましたが、Ubuntu 24.04 ではその管理方式がセキュリティ上の理由で非推奨（Deprecated）となっていたためです。

対処内容

以下の手順で、鍵を新しい推奨形式（個別のキーリング管理）へ移行させました。

鍵の抽出と個別保存

sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --export D870AB033FB45BD1 | sudo tee /usr/share/keyrings/phusion-passenger.gpg > /dev/null

古い管理リストから鍵を削除

sudo apt-key del D870AB033FB45BD1

リポジトリ設定の更新

/etc/apt/sources.list.d/passenger.list 内の記述に [signed-by=/usr/share/keyrings/phusion-passenger.gpg] を追記し、特定のリポジトリと鍵を紐付けました。

→ 筆者にしては珍しく.listのバックアップを取っていませんが（切り戻しを取れるようにしていません)、これは「切り戻したところで古い鍵形式だから」です。

解決確認

sudo aptitude update

でエラーがないことを確認します。

作業が必要だった理由（背景）

Ubuntu 22.04 以降、OSのセキュリティ設計が強化され、

「すべてのリポジトリで共通の鍵束を使う方式」から「リポジトリごとに専用の鍵を個別に指定する方式」

への完全移行が推奨されているためです。これにより、以下のメリットがあります。

• セキュリティ向上:
  • 万が一、一つのリポジトリの鍵が漏洩・悪用された場合でも、他のリポジトリの安全性に影響を与えない設計になっています。
• メンテナンス性の向上:
  • どの鍵がどのリポジトリのものかが明確になり、不要になった鍵の削除や更新が安全に行えます。

昨日運用を開始したzram。その効果を実感できる「単体テスト」にぶち当たりました。

• 必要に応じて動かし
• アップデートでメモリを恐ろしく消費する

Growiのアップデートです。

zram導入・運用環境 メモリ推移比較

数値から見る運用の要諦

• 導入直後はFreeが0.42GiBと心許ない数値でしたが、安定稼働時にはAvailableが2.9GiBまで回復しており、OSが自由に使える「机の広さ」が広くなっています。
• Growiアップデートという最大の難所においても、Disk Swapを0Bに抑え込めたことが、システム全体のレスポンス維持に直結しています。
• 安定稼働時に圧縮率が5.5倍まで向上しているのは、メモリ内の重複データやテキストデータが効率よく整理されているzstdの底力を見ました。

ここからのまとめ

「取り敢えず私のサーバには合っている」という形。他、気がついた事項は随時フィードバックしていきます。