立ち話

興味があることを書いてます。正確な内容は公式ドキュメントや参考文献を確認してください。ブログに示された意見はすべて個人の見解であり、所属する組織の公式見解ではありません。

Proxmox の VLAN まわりの設定に関するメモと検証

はじめに

Proxmox の VLAN まわりの設定があまりわからなかったので、調査しつつ手元で試して理解を深めたいと思います。

色々確かめていたら少し長くなってしまいました。読みにくいかもしれませんが、ご容赦いただけますと幸いです。

また、十分調査・検証しながら書いているつもりですが、誤った記載や誤解を招く記載があるかもしれません。誤りを発見した場合は修正いたします。

簡単なまとめ

  • VLAN Aware 機能を使うと VLAN のトランクポートの設定ができる
    • アクセスポートを設定する1つの方法として、『Linux VLAN で Name に [bridge name].[tag] を設定する』方法がある
  • VLAN 対応のスイッチングハブを使うときは、VM の仮想NICスイッチングハブのアクセスポートの VLAN ID を揃える

VLAN 設定の方法

いくつか方法があるようですが、今回は『物理NICに VLAN-aware の Linux Bridge を作る』方法で設定します1

方法

以下動画を参考に設定します。

www.youtube.com

トランクポートの設定

Linux Bridge の "VLAN aware" にチェックを入れます。このように設定した場合、この Linux Bridge は VLAN のトランクポートに相当します。

VLAN トランクポートの設定

アクセスポートの設定

Create: Linux VLAN で Name に [bridge name].[tag] を設定すると、Vlan raw device が [bridge name] で VLANタグが [tag] の VLAN を設定できます。

VLAN アクセスポートの設定

上の図では、vmbr1 に対して VLANタグ 200 の VLAN を設定しようとしています。

検証

(1) VLAN の動作検証

ここでは Proxmox のクラスタを構成する2つのノードに対して VLAN の設定をして、同一の VLAN タグを持つアクセスポートに接続する VM 同士 (異なる物理ノードに存在) で疎通できることを確認します。

構成

Proxmox の Node 1 (uranus) および Node 2 (venus) で、以下のように VLAN を設定します。ここでは、vmbr1 という Linux Bridge の下にVLANタグが100と50のVLANを設定しました (vmbr1.100vmbr1.50)。

Proxmox の Node 1 のネットワーク設定

Proxmox の Node 2 のネットワーク設定

実験のため、以下3つの仮想マシンを図のように接続します。

VM 物理ホスト 補足
IDS uranus パケットキャプチャ用
Workstation uranus
Kali venus

検証 (1) ネットワーク構成

VM (IDS, Workstation, Kali) の仮想NICとVLANの対応を以下の表で示します。

NO VLAN VLAN 100 VLAN 50
IDS ens19 ens20 ens21
Workstation - ens19 ens20
Kali - eth1 eth2

検証項目

以下のようにIPアドレスを設定したときに、疎通可能であるか、また、IDSの各仮想NICでキャプチャするとどのようなパケットが採取できるかを確認します。

  1. Workstation も Kali も VLAN 100 に対応する仮想NIC192.168.100.0/24 に属するIPアドレスを割り当てる。
  2. Workstation の VLAN 100 と Kali の VLAN 50 に対応する仮想NIC192.168.100.0/24 に属するIPアドレスを割り当てる。
  3. Workstation の VLAN 100 に対応する仮想NIC192.168.100.0/24 に属するIPアドレスを割り当て、Kali の VLAN 50 に対応する仮想NIC192.168.50.0/24 に属するIPアドレスを割り当てる。

ただし、IDSでキャプチャ可能にするために、vmbr1 ではポートミラーリングと同等の設定をしています。

seekt.hatenablog.com

検証 (1)-1

Workstation と Kali の VLAN 100 に対応する仮想NICに対して、以下のIPアドレスを割り当てます。

VM device IP
Workstation ens19 (VLAN 100) 192.168.100.85/24
Kali eth1 (VLAN 100) 192.168.100.99/24

この状態では、Kali と Workstation の疎通が確認できます。

(1)-1 疎通確認

IDS の各仮想NICでキャプチャした結果を以下に示します。今の環境では DNS サーバをデフォルトで動かしているので DNS パケットが流れていますが、見やすさのために DNS のパケットは除外しています。

  • ens19 (NO VLAN: トランクポートに対応) には、タグ付けされたパケットが流れる
    • ping request も ping reply も VLAN ID 100
  • ens20 (VLAN 100) には、VLAN ID 100 のパケット (タグが外されたもの) が流れる
    • ping request も ping reply も ens20 で取得される
  • ens21 (VLAN 50) には、VLAN ID 50 のパケット (タグが外されたもの) が流れる
    • ICMP パケットは流れない

ens19で取得されるパケット

ens20で取得されるパケット

ens21で取得されるパケット

検証 (1)-2

Workstation の VLAN 100 と Kali の VLAN 50 に対応する仮想NICに対して、以下のIPアドレスを割り当てます。

VM device IP
Workstation ens19 (VLAN 100) 192.168.100.85/24
Kali eth2 (VLAN 50) 192.168.100.99/24

この状態でも、Kali と Workstation の疎通が確認できます (後述の物理スイッチを用いたときの通常の挙動と異なる)。

(1)-2 疎通確認

IDS の各仮想NICでキャプチャした結果を以下に示します。見やすさのために DNS のパケットは除外しています。

  • ens19 (NO VLAN: トランクポートに対応) には、タグ付けされたパケットが流れる
    • ping request は VLAN ID 50 で ping reply は VLAN ID 100
  • ens20 (VLAN 100) には、VLAN ID 100 のパケット (タグが外されたもの) が流れる
    • ping reply が ens20 で取得される
  • ens21 (VLAN 50) には、VLAN ID 50 のパケット (タグが外されたもの) が流れる
    • ping request が ens21 で取得される

ens19で取得されるパケット

ens20で取得されるパケット

ens21で取得されるパケット

通常は VLAN ID が異なると疎通できないと思うのですが、今回の設定では疎通できています。おそらく1つの物理NIC に VLAN のトランクポートとアクセスポートが割り当てられているからと考えられますが、断言はできません。こちらについても確認する必要があるかと思います。

検証 (1)-3

Workstation の VLAN 100 と Kali の VLAN 50 に対応する仮想NICに対して、以下のIPアドレスを割り当てます。

VM device IP
Workstation ens19 (VLAN 100) 192.168.100.85/24
Kali eth2 (VLAN 50) 192.168.50.99/24

このときは (当たり前ですが) Kali から Workstation への ping は通りません。

検証 (1) のまとめ

  • トランクポートから出ていく (に入る) パケットにはVLANタグが付与されている
  • 物理スイッチ側でVLANの設定がなされていない場合、同一セグメント内のホスト間は、仮想NICのVLANタグが異なっても疎通できる (通常の挙動とは異なる)
    • これは今回の設定 (1つの物理NICにトランクポートとアクセスポートが割り当てられていること) に起因する?

(2) L3スイッチを使った検証

ここでは、タグVLANを設定可能なL3スイッチを用いて、VLANタグを付与したポートに接続した物理マシンと疎通可能かを確認します。

L3スイッチとして、以下製品を用いました。

www.netgear.com

構成

検証 (1) 環境にL3スイッチを追加し、VLAN 100 のアクセスポートにノートPC (Windows 11) を接続しました。

検証 (2) ネットワーク構成

ただし、L3スイッチは以下のようにVLAN設定をしました。

L3スイッチ VLAN設定

L3スイッチ ポート VLAN ID 設定

なお、上記設定は NETGEAR タグ VLAN を設定したスイッチ同士の接続 を参考にしています。

検証項目

以下のようにIPアドレスを設定したときに、疎通可能であるか、また、IDSの各仮想NICでキャプチャするとどのようなパケットが採取できるかを確認します。

  1. Workstation の VLAN 100 に対応する仮想NICと、L3スイッチの VLAN 100 のアクセスポートに接続したノートPCに 192.168.100.0/24 に属するIPアドレスを割り当てる
  2. Kali の VLAN 50 に対応する仮想NICと、L3スイッチの VLAN 100 のアクセスポートに接続したノートPCに 192.168.50.0/24 に属するIPアドレスを割り当てる

検証 (2)-1

Workstation の ens19 とノートPCの有線LANに以下のIPアドレスを割り当てます。

VM device IP
Workstation ens19 (VLAN 100) 192.168.100.85/24
ノートPC (VLAN 100) 192.168.100.111/24

この状態では、Workstation とノートPCの疎通が確認できます。

(2)-1 疎通確認

IDS の各仮想NICでキャプチャした結果を以下に示します。見やすさのために DNS のパケットは除外しています。

  • ens19 (NO VLAN: トランクポートに対応) には、タグ付けされたパケットが流れる
    • ping request も ping reply も VLAN ID 100
  • ens20 (VLAN 100) には、VLAN ID 100 のパケット (タグが外されたもの) が流れる
    • ping request も ping reply も ens20 で取得される
  • ens21 (VLAN 50) には、VLAN ID 50 のパケット (タグが外されたもの) が流れる
    • ICMP パケットは流れない

ens19で取得されるパケット

ens20で取得されるパケット

ens21で取得されるパケット

検証 (2)-2

Kali の eth2 とノートPCの有線LANに以下のIPアドレスを割り当てます。

VM device IP
Kali eth2 (VLAN 50) 192.168.50.99/24
ノートPC (VLAN 100) 192.168.50.111/24

この状態では、Kali とノートPCは疎通できません。

(2)-2 疎通確認

IDS の各仮想NICでキャプチャした結果を以下に示します。見やすさのために DNS のパケットは除外しています。

  • ens19 (NO VLAN: トランクポートに対応) には、タグ付けされたパケットが流れる
  • ens20 (VLAN 100) には、VLAN ID 100 のパケット (タグが外されたもの) が流れる
    • VLAN 100 のアクセスポートに接続するノートPCは、Kali (のIPアドレスを持つホストのMACアドレス) を探そうと ARP Request を投げる
    • しかし、VLAN 100 には Kali のIPアドレスを持つホストが存在しないので、ARP Reply が返ってこない
  • ens21 (VLAN 50) には、VLAN ID 50 のパケット (タグが外されたもの) が流れる
    • VLAN 50 のアクセスポートに接続する Kali は、ノートPC (のIPアドレスを持つホストのMACアドレス) を探そうと ARP Request を投げる
    • しかし、VLAN 50 にはノートPCのIPアドレスを持つホストが存在しないので、ARP Reply が返ってこない

ens19で取得されるパケット

ens20で取得されるパケット

ens21で取得されるパケット

検証 (2) のまとめ

  • VLAN ID を揃えると VM と物理マシンの間で疎通できる
    • VM 側では、該当する VLAN ID を持つ仮想NICに接続する
    • 物理マシン側では、該当する VLAN ID のアクセスポートに接続する

まとめ

Proxmox の VLAN まわりの設定を確認しました。実際使うときは、VM の仮想NICと L3スイッチに接続した物理機器の VLAN を合わせるのが良いのかなと思いました。


  1. 他の方法として、『物理インタフェースにVLANインタフェースを作ってその上にブリッジインタフェースを作る方法』があります。参考:Proxmox VE 7.x(3)- VLANの使い方

社会人2年目に作った自宅環境と在宅勤務環境について語りたい

はじめに

新居に引っ越してから4か月ほど経過し、自宅インフラ(自宅ラボ)環境も在宅勤務環境もだいぶ整えられました(まだまだ成長の余地はあると思っています)。今回は、社会人2年目の12月までに構築した自宅環境と在宅勤務環境について語りたいと思います。

また、今年買ってよかったものと微妙だったものについても紹介します。

関連記事へのリンク

在宅勤務環境

在宅勤務環境は、前回記事から変えておらず、L字デスク + ゲーミングチェア + モニター×2 + モニターアーム + キーボードです。

在宅勤務環境(再掲)

社用ノートPCとあわせて3画面なので、ノートPCの内蔵ディスプレイをメモ・メール確認用、モニターのうち1つを作業用、もう1つを資料参照用、などのようにして使っています。この画面の使い方に慣れてしまうと、モニターが3つないと仕事ができなくなってしまう、という難点はありますが、作業効率はかなり上がっていると思っています。

また、前回記事の後にウォーターサーバーをレンタルしたので、仕事中にインスタントコーヒーを飲むのが楽になりました。

在宅勤務環境で特にこだわった点を以下に示します。こだわった主な理由は作業効率の向上です。

  • 大き目の机
  • モニターアーム

自宅環境

自宅環境は、(1) サーバ群、(2) 個人作業スペースから構成されています。それぞれの写真はこんな感じです。サーバ群は在宅勤務環境の隣(有線で届くところ)にあって、個人作業スペースは寝室にあります。

サーバ群

個人作業スペース(寝室)

サーバ群

サーバ群は、NAS、Proxmoxサーバ(仮想化鯖)×2、スイッチングハブから構成されています。

NAS は Synology さんのものを使っており、VM のストレージ用および写真やデータの保存用に活用しています。具体的には、NFS共有を使ってProxmoxのストレージに活用しています。

Proxmoxサーバ内では検証環境が動いています。私は Offensive Security に興味があるので、サイバー攻撃とそれを監視できる環境を仮想マシンで構築しています。また、検証環境内で検証したことをまとめるための Wiki サーバも立てています。

Proxmox

タワー型に uranus という名前を付けて、ミニPC に venus という名前を付けています。uranus は大学院の頃に購入したもので、最近メモリを64GBに増設しました。

今の検証環境はおそらくこんな感じだと思います。

検証環境

少し見にくいですが、以下のように動かしています。

  • uranus(ノード1)にはIDSやElasticsearch、サイバー攻撃の標的用マシンがあります
  • venus(ノード2)にはWikiサーバ、攻撃者マシン、Calderaサーバがあります
  • vmbr0 は自宅内のLANに接続しているNICで、vmbr1 はProxmoxサーバ間(内部で閉じた)ネットワークに接続しているNICです
    • 検証は vmbr1 で行っています

あとは諸々設定して Kibana に外部からアクセスできるように設定したり、Elastic Agent を使って仮想サーバの死活監視をしたりしています。このあたりについては気が向いたら書くかもしれません。

個人作業スペース

個人作業スペースにはデスクトップPC(自作)、ゲームのハード(Switch)、ブックスタンドなどが置かれています。

デスクトップPCは、サーバ群へのリモートアクセスやゲーム(Steam)などのために使っています。一度だけ深層学習のために使ったこともあります。

最近は、この本を読みながらいろいろまとめています。

www.oreilly.co.jp

たまに Switch でゲームをしています。最近はポケモンSVのDLCを進めようかなと思っていますが、気力がなくて進められていません。HDMIの切替器を使ってディスプレイにSwitchの画面を映してゲームをすることもあれば、布団にもぐりながらSwitchのゲームをすることもあれば、という感じです。

買ってよかったものと微妙だったものについて

今年購入したものと、評価ポイントを1点から10点の10段階で評価します。

買ったもの 価格 評価 評価理由
Echo Dot 5,643円(割引) 10 仕事の役にもプライベートの役にも立っている
Echo Pop 1,758円(割引) 2 ネットワークにつながらない等のトラブルが多い
Fire TV Stick 2,202円(割引) 5 モニターに接続しているが、音量調整ができなかった
ミニPC 19,000円程度(在庫切れ) 10 この値段の割にはかなり良い。LANポートが2つなのも良い
ロードバイク 約20万円 10 乗り心地がすごく良いです。最近残業が多くてあまり乗れてなくて少し辛い
スマートウォッチ 12,000円程度 8 時計としての機能のほか、運動の記録もできる

ロードバイクはこれです。

まとめ

環境を整えるためにお金を費やしていました。貯金はあまり意識できていなかったので、来年こそは貯金したいです。

自宅インフラを育てる (7) ElasticsearchとKibanaとElastic Agentを使ってIDS(Suricata)のアラートを可視化する

はじめに

前回、Proxmox 上に IDS(Suricata)を構築して攻撃を監視できるようにしました1seekt.hatenablog.com

この環境では、アラートをグラフィカルに表示することができていませんでした。今回は、Elastic Stack 2 を使ってIDSのアラートやリソースの使用率を可視化したので、備忘録を残します。

構築する環境

今回は、前回構築した IDS からログを集約して可視化することを目指します。そのため、前回構築した環境に情報集約/可視化用のVM(図中のElastic VM)を追加し、設定します。

構築する環境の論理構成

ログの集約と可視化のために、Elastic Stack を使います。ログ収集のための Elastic Agent と、それらを中央管理するための Fleet Server をインストールします。以下図はQiita記事3を参考に、今回の環境におけるイメージを示したものです。

Fleet Server と Elastic Agent のイメージ

また、今回インストールする機能とインストールするVMを以下表にまとめます。

使う機能 用途 インストールするVM
Elasticsearch データの検索 Elastic VM
Kibana データの可視化 Elastic VM
Fleet Server (+ Elastic Agent) データの集約 Elastic VM
Filebeat (+ Elastic Agent) データの収集 IDS VM

実現方法

クラスタを用いた実現

1台のProxmoxサーバで実現するにはリソースの限界があったので、Proxmox のクラスタを用いてリソースを分散することで実現しました。

Proxmox のクラスタ

クラスタの設定については、Qiita記事4などが参考になります(ここでは詳細な設定は書きません)。クラスタ設定中に Proxmox サーバにアクセスできなくなる事象が発生したので、そのトラブルシューティングについて付録に書きます。

物理構成

クラスタ構築後の物理構成を以下図に示します。「Proxmoxサーバ (1)」がもともと使用していたProxmoxサーバ、「Proxmoxサーバ (2)」が追加したサーバです。追加したサーバは、20,000円程度のミニPCです。

Home-net は、インターネット接続可能なネットワーク、Internal-net は、外部接続しないネットワークです。

物理構成

また、ネットワーク構成について以下図に示します。この構成にすると、Attacker と Target の間の通信を IDS でキャプチャできます。

ネットワーク構成

環境構築

Elastic VM も IDS VM も Ubuntu22(Server)とします。

Elasticsearch のインストールと設定

Server World記事5を参考にインストールします。

# wget -O - https://artifacts.elastic.co/GPG-KEY-elasticsearch | gpg --dearmor -o /etc/apt/keyrings/elasticsearch-keyring.gpg
# echo "deb [signed-by=/etc/apt/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | tee /etc/apt/sources.list.d/elastic-8.x.list
# apt update
# apt -y install elasticsearch

インストールしたときに Elastic のパスワードが自動生成されるので、メモしておきます。

外部ホストから接続可能にする形で設定ファイル(/etc/elasticsearch/elasticsearch.yml)を編集します。ここでは、Elasticsearch のクラスタを作らない形で設定します6

network.host: 0.0.0.0
discovery.type: single-node

クラスタを作らない場合は、cluster.initial_master_nodesコメントアウトしないと起動時にエラーが出るので、注意します。

インストール確認

以下コマンドで Elasticsearch を起動します。

# systemctl daemon-reload
# systemctl start elasticsearch
# systemctl enable elasticsearch

起動した状態で、Elasticsearch にアクセスできるか確認します。

# curl -u elastic --cacert /etc/elasticsearch/certs/http_ca.crt https://127.0.0.1:9200

パスワードを入力して以下のような出力が得られれば問題なく起動しています。

{
  "name" : "kibana",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "lHm2fMPYSSedysg9mZjMKg",
  "version" : {
    "number" : "8.10.2",
    "build_flavor" : "default",
    "build_type" : "deb",
    "build_hash" : "6d20dd8ce62365be9b1aca96427de4622e970e9e",
    "build_date" : "2023-09-19T08:16:24.564900370Z",
    "build_snapshot" : false,
    "lucene_version" : "9.7.0",
    "minimum_wire_compatibility_version" : "7.17.0",
    "minimum_index_compatibility_version" : "7.0.0"
  },
  "tagline" : "You Know, for Search"
}

Kibana のインストール

Server World記事7を参考にインストールします。

SSL証明書を作成してからインストールします。ここでは、自己署名を用いる場合の手順をまとめます8

# nano /etc/ssl/openssl.cnf

末尾に以下を追加します。

[vis]
subjectAltName = DNS:vis.pve.uranus

ただし、セクション名([vis])は任意で、= の後は、DNS:[自分のホスト名] とします。

証明書作成のために以下コマンドを実行します。

# cd /etc/ssl/private
# openssl genrsa -aes128 2048 > server.key
# openssl rsa -in server.key -out server.key
# openssl req -utf8 -new -key server.key -out server.csr
# openssl x509 -in server.csr -out server.crt -req -signkey server.key -extfile /etc/ssl/openssl.cnf -extensions [セクション名] -days 3650
# chmod 600 server.key

証明書作成後、Kibana をインストールします。

# apt -y install kibana
# cp /etc/ssl/private/{server.crt,server.key} /etc/kibana/
# chown kibana:kibana /etc/kibana/{server.crt,server.key}

インストール後は Kibana 用のトークンを発行し、Kibanaをセットアップします。

# /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana
# /usr/share/kibana/bin/kibana-setup --enrollment-token \
[生成されたトークン]

また、Kibana の設定ファイル(/etc/kibana/kibana.yml)を以下のように編集します。

server.host: "0.0.0.0"
server.publicBaseUrl: "https://[hostname]:5601/"
server.name: "[hostname]"
server.ssl.enabled: true
server.ssl.certificate: /etc/kibana/server.crt
server.ssl.key: /etc/kibana/server.key

インストール確認

Kibana を起動し、http[s]://[IPアドレス]:5601 にアクセスします。

# systemctl enable kibana
# systemctl start kibana

Kibana

Fleet Server のインストール

qiita.com

Qiita記事を参考にインストールします。

Kibana で、Home > Management > Fleet に進み、Add Fleet Server に進みます。Fleet Server host に、http[s]://[IPアドレス]:8220 を指定します。Fleet Server をインストールするコマンドが表示されるので、このコマンドを(今回は Elastic VM で)実行してインストールします。

Fleet Server のインストール

Elastic Agent のインストール

Kibana で、Home > Add integration に進み、Suricata と検索して、Add Suricata に進みます。

Add Suricata Integration

このとき、② で New hosts を選択し、Save and Continue すると、Fleet に Agent policy が追加されます。追加された状態で、Home > Management > Fleet に進み、Add agent に進みます。① で agent policy を選択し、② で Enroll in Fleet を選択すると、③ にインストールコマンドが表示されるので、このコマンドを(今回は IDS VM)で実行します。

ただし、証明書のエラーが出るので、--insecure オプションを追加して実行します9

$ sudo ./elastic-agent install --insecure --url=[Fleet url] --enrollment-token=[token]

Add agent

動作確認

Fleet Server および Elastic Agent をインストール後、Kibana の画面でホストの監視ができています。

ホストの監視

また、Suricata のアラートの監視もできるようになりました。

Kibana を使った Suricata のアラートの監視

Kibana 上でアラートの管理

まとめ

今回は、Proxmox サーバのノードを増やして、Elastic Stack を使って IDS アラートを監視する基盤を作ってみました。今回詰まった部分は ChatGPT に質問しながら進めました。

今後は NAS を導入したいです。

付録:Proxmox サーバにアクセスできなくなったことに関するトラブルシューティング

事象

クラスタ設定中、Proxmox サーバ(uranus)にリモートからアクセスできなくなり、以下のようなログが出ていました。

r8169 0000:02:00.0 enp2s0: rtl_chipcmd_cond == 1 (loop: 100, delay: 100).
r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond == 1 (loop: 100, delay: 10).
r8169 0000:02:00.0 enp2s0: rtl_eriar_cond == 1 (loop: 100, delay: 100).

原因と解決策

カーネルのバージョンの問題らしいです10

/etc/apt/sources.list

deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription

を追加し、以下コマンドを実行すると解決しました。

# apt update
# apt install pve-kernel-5.15.108-1-pve
# proxmox-boot-tool kernel pin 5.15.108-1-pve
# reboot

自宅インフラを育てる (6) Proxmoxサーバ上に攻撃と監視をするための環境を構築する

はじめに

これまで Proxmox サーバ上に中間者攻撃で遊ぶための環境を作ったり1、模擬制御システム(GRFICS2)を導入したり3、自宅内ネットワークを構築して遊んだり4していました。

seekt.hatenablog.com

しかし、この環境ではサイバー攻撃を試すことはできても監視する(例:IDSを導入)ことはできていませんでした。今回は、Proxmox 上に IDS を構築して攻撃を監視できるようにしたので、備忘録を残します。

この記事で書いていること

  • Proxmoxでポートミラーリングする方法の一例
    • なぜか日本語記事が見つからなかった(検索の仕方が悪い?)
  • Proxmox 上に IDS(Suricata5)の VM を構築する方法

構築する環境と要求仕様

ここでは、今回構築する環境とその要求仕様について説明します。

検証環境

ここでは、下図に示す簡易的な環境を構築します。今後、複数の Target を考えたり、複数の IDS を考えたりするケースもあるかもしれませんが、今回は簡単のため Attacker、Target、IDS はそれぞれ1台ずつと想定しています。

構築する環境の論理構成

要求仕様

今回は、ネットワーク型の IDS を導入して Internal-net を監視することを想定します。監視して異常時にアラートを発報するためには、IDS は Attacker と Target の間の(ユニキャスト)通信をキャプチャすることができる必要があります。また、今回は1つの Proxmox サーバのノード内に VM を構築して実現しようとしていますが、今後クラスタを利用してノードを増やしたときも同様に監視できる必要があります。

以上を要求仕様としてまとめます。

  1. IDS は Attacker と Target の間の(ユニキャスト)通信をキャプチャ可能
  2. Proxmox のノードが増えても監視可能

実現方法

要求仕様 1、2 を実現するために、以下の (1)、(2) を実施します。なお、この方法はあくまで執筆者が思いついたものなので、より良い方法がある可能性があります。

要求仕様1を実現する方法が(1)、2を実現する方法が(2)です。(2)、(1)の順に説明します。

ブリッジポートの指定とネットワーク構成の変更

Proxmox 上でブリッジネットワークを作成してブリッジポート(物理ポート)を指定すると、ブリッジネットワークに流れる通信をブリッジポートに流すことができたり、ブリッジポートが受け取った通信をブリッジネットワークでも受け取ることができます(書き方が間違っていたらごめんなさい)。過去記事でも同様のことをしています。下図のように設定すると、vmbr1 に流れる通信が enx... のポートに流れます。

ブリッジポートの指定

この状態でネットワーク構成を変更します。下図はネットワーク構成後の構成図です。vmbr0 は物理NIC 1がブリッジになっていて、vmbr1 は物理NIC 2がブリッジになっています。物理NIC 1の先のスイッチはルーターとつながっていて、物理NIC 2(enx...)の先のスイッチは Internal-net 用で外部と接続していません。

ネットワーク構成図

Proxmox でのポートミラーリング

VMware vSphere6 の分散仮想スイッチにはポートミラーリング機能があります7。ポートミラーリング機能を使うと、ある分散仮想スイッチに接続しているVM間で発生した通信を別の分散仮想スイッチに接続したVMに流すことができます。vSphere 上に構築した VM で実施した攻撃を監視するためには、ポートミラーリングを使って IDS の VM に通信を流せばよいわけです。

Proxmox は vSphere の分散仮想スイッチのようなものがない(調べたり使ったりした限りでは)ですが、vSphere と同様にポートミラーリングによって Attacker と Target の間の通信を IDS が受け取れるようにできれば、IDS で監視可能になります。

Proxmox サーバでポートミラーリングする方法について書いてくれていた記事8を見つけたので、この方法を踏襲してポートミラーリングします。

www.trisul.org

vmbr1 に接続した Attacker と Target の間の通信(パケット)を、物理NIC 2(enx...)に接続したすべてのアセットで受け取れるようにすれば良いというアイデアで実現します。

設定方法

Proxmox サーバのシェルに入って、/etc/network/interfaces を以下のように設定してネットワーク(またはサーバ本体)を再起動します。

auto vmbr1
iface vmbr1 inet manual
        bridge_ports [port]
        bridge_stp off
        bridge_fd 0
        bridge_ageing 0

これによって、bridge_ageing が 0 のブリッジが作成されるため、接続されている相手にすべてのパケットが転送されるそうです(このあたりがあまり理解できておらず上手く説明できませんが...)。

この状態で、監視したい VMDHCP off で IPアドレスを割り当てないようにすると、そのVMにパケットが転送されるはずです。

動作確認

Attacker(192.168.50.99)から Target(192.168.50.5)に ping を飛ばして、それを IDS の VM でキャプチャできるか確かめました。IDS の ens19 が vmbr1 に接続していて、IPアドレスは割り当てていません。

動作確認

確かに Attacker と Target と間の通信をキャプチャできていることが確認できました。

環境構築

ここでは、Attacker、Target、IDS の構築についてまとめます。

Attacker の構築

レッドチーム関連の書籍9を参考に、Ubuntu22 上に TrustedSec の PTF(The PenTesters Framework)10をインストールしました。

github.com

構築手順

PTF のダウンロードとプロンプトの表示するには以下コマンドを実行します。

$ sudo -s -E
# apt-get update
# git clone https://github.com/trustedsec/ptf.git /opt/ptf
# cd /opt/ptf && ./ptf

例えば、エクスプロイトツールをインストールするには以下コマンドを実行します。ほかにもインストールできるツールがあるので、オプションを参照すること。

ptf > use modules/exploitation/install_update_all

インストール後は msfconsole で Metasploit を起動できます。

Target の構築

ここでは Target は Metasploitable2 11にしました。

docs.rapid7.com

構築手順

Zip をダウンロードすると、中に vmdk ファイルが入っているので、Proxmox サーバに送ります。

scp *.vmdk root@[IP address]:/root/

サーバに送った後、記事12を参考に新しい VM を立ててハードディスクを detach して remove します。その後、送った vmdk ファイルをインポートします。

zarat.hatenablog.com

# qm importdisk [vmid] [import_disk] local-lvm -format raw

この状態では「未使用のディスク」という状態なので、追加します。追加時にはバスやデバイスSATAにする等して調整する必要がありそうです。

IDS(Suricata)の導入

IDS は Suricata を導入することにしました。Suricata はオープンソースの IDS で、ルールも充実しています。

構築手順

依存関係のあるパッケージのインストール:

$ sudo apt-get install libpcre3 libpcre3-dbg libpcre3-dev build-essential libpcap-dev   \
                libnet1-dev libyaml-0-2 libyaml-dev pkg-config zlib1g zlib1g-dev \
                libcap-ng-dev libcap-ng0 make libmagic-dev         \
                libnss3-dev libgeoip-dev liblua5.1-dev libhiredis-dev libevent-dev \
                rustc cargo libjansson-dev

ダウンロードとインストール:

$ sudo -s -E
# cd /opt
# wget https://www.openinfosecfoundation.org/download/suricata-6.0.10.tar.gz
# tar -zxvf suricata-6.0.10.tar.gz
# cd suricata-6.0.10
# ./configure --prefix=/usr/ --sysconfdir=/etc --localstatedir=/var
# make
# make install
# make install-full

設定

/etc/default/suricata の編集

RUN_AS_USER=[username]
LISTENMODE=pcap
IFACE=[interface]

/etc/suricata/suricata.yaml の編集

Target(192.168.50.5)のみを監視対象のネットワークとします。また、pcap のログを取得するように設定しました。

HOME_NET: "[192.168.50.5]"
EXTERNAL_NET: "!$HOME_NET"

- pcap-log:
    enabled: yes

pcap:
    - interface: [interface]

ルールの設定

# apt install python3-pip
# pip install --pre --upgrade pip
# pip install --pre --upgrade pyyaml suricata-update
# mkdir -p /var/lib/suricata/rules
# mkdir -p /var/lib/suricata/update
# touch /etc/suricata/update.yaml
# touch /etc/suricata/enable.conf
# touch /etc/suricata/disable.conf
# touch /etc/suricata/drop.conf
# touch /etc/suricata/modify.conf

suricata-update の docs 13 を参考に update.yamlenable.confdisable.confmodify.conf を編集する。

suricata-update.readthedocs.io

ルールの入手

# wget https://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz
# tar -zxvf emerging.rules.tar.gz
# cp -r rules /etc/suricata/rules

テスト

インストールした Suricata を起動し、アラートが出るかどうかを確認します。

シナリオ

Attacker(192.168.50.99)から Target(192.168.50.5)に ping を送ったときのアラートを見ます。

監視設定

# suricata -c /etc/suricata/suricata.yaml --pidfile /run/suricata.pid -i [interface]

で起動し、

# tail -f /var/log/suricata/fast.log

でアラートを確認します。

結果

外部ネットワークから監視対象のネットワークへのICMPのパケットのシグネチャに引っかかって、アラートが発報されました。

Suricata のアラート

まとめ

今回は、Proxmox サーバ内でポートミラーリングの設定を行い、攻撃および監視を行うための環境を構築しました。ポートミラーリングの設定はほとんど記事が見つからなかったのでかなり詰まりました。現在は1台のノード内で環境を構築しましたが、負荷が大きくなっているように思います。

今後の目標は、

です。

自宅インフラを育てる (5) 情報整理用サーバー (Webサーバー・Wikiサーバー・ファイルサーバー) の構築

はじめに

情報収集しやすくなるための基盤として、自宅サーバー (on Proxmox) 上に情報整理用サーバー (Webサーバー・Wikiサーバー・ファイルサーバー) を構築しました。情報整理は主に論文情報を整理することを想定しています。

この記事では備忘録として、手順書を残します。

ここまでの自宅インフラ関連の記事:

seekt.hatenablog.com

全体像

全体像はこんな感じです。

構築した情報整理用サーバー

仕様

今回構築する情報整理用サーバーの仕様は以下です。

  • WebサーバーとWikiサーバーをリンクさせる
  • Webサーバーでは、論文リストを可視化する
    • 具体的には、読んだ (OR 読む予定の) 論文と、その次に読む論文を結びつける
  • Wikiサーバーでは、手元で試したり調べたりした情報をまとめる
    • 論文メモはWikiサーバーに置く
  • 論文リストは、手元のPC等で編集する
    • 形式は JSON にした
    • ファイル自体はファイルサーバーに置く

ファイルサーバーの構築

手順

手順については、PC Watch記事1も参考にしている。

(1) samba のインストール

$ sudo apt update
$ sudo apt -y install samba

(2) 共有ファイルを置くディレクトリの作成

今回は、/srv/samba/public ディレクトリ以下に共有ファイルを置くことにします。

$ sudo mkdir -p /srv/samba/public

また、Samba 用のユーザとして samba を作成し、public ディレクトリの権限を変更します。

$ sudo adduser --system --group --no-create-home samba
$ sudo chown samba: /srv/samba/public/
$ sudo chmod 775 /srv/samba/public/

(3) samba を使用するユーザの作成

$ sudo pdbedit -a samba

ここでは、パスワードなしとしました。

(4) 設定ファイル(samba.conf)のバックアップと編集

$ sudo cp /etc/samba/samba.conf /etc/samba/samba.conf.bk
$ sudo nano /etc/samba/samba.conf

以下を追加します。

[global]
guest account = samba

[Public]
writeable=yes
path=/srv/samba/public
create mask=0644
directory mask=0755
force user=samba
force group=samba
guest ok=yes
guest only=yes

以下コマンドで書式が正しいか確認します。

$ sudo testparm

問題なければ、サービスを再起動します。

$ sudo systemctl restart smbd nmbd

また、自動起動の設定もしておきます。

$ sudo systemctl enable smbd nmbd

これで、Windowsエクスプローラーもしくはブラウザからファイル共有できるようになります。

ファイルサーバー

Wikiサーバーの構築

1年くらい前に自宅用Wikiサーバーを構築しました。これと同様にWikiサーバーを構築します。

Wikiサーバーは Gollum を用いて構築しました。

github.com

構築の際にはGollumについてまとめられた記事2を参考にしました。

手順

(1) 依存関係にあるパッケージのインストール

$ sudo apt update
$ sudo apt install -y libicu-dev cmake libssh-dev libssl-dev \
 pkg-config make zlib1g-dev build-essential git asciido

(2) Ruby のインストール

$ sudo apt -y install ruby
$ sudo apt install -y ruby-full
$ sudo apt install -y rubygems
$ sudo gem install rubygems-update
$ sudo apt -y install ruby-dev libruby

(3) Gollum のインストール

$ sudo gem install therubyracer gollum org-ruby omnigollum \
 github-markup omniauth-github github-markdown

(1) - (3) まででインストールが完了するはずです。インストールできない場合は、依存関係のパッケージ等を調べるなどして対応しましょう。

(4) Wikiサーバーの起動

Gollum は Git と連携しているので、ディレクトリに空のリポジトリを作ります。.git があるディレクトリで gollum コマンドを実行するとWikiサーバーが起動します。

$ mkdir wiki
$ cd wiki
$ git init
$ gollum

ここまで実行すると、ブラウザから http://[サーバーのIPアドレス]:4567Wikiサーバーにアクセスできます。

Wikiサーバー

Webサーバーの構築

Apache2 をインストールするだけなので、インストール手順は省略します。

Webサーバー

Webサーバー上で、読んだ論文と次に読む論文をグラフで表すように可視化しています。可視化することで、自分の中でイメージがつきやすくなると思っています。具体的にはこんな感じのグラフを html と JavaScript で書いています。

論文ネットワーク

グラフのノードを選択すると、論文のリンクが出るようにしています。このグラフを生成するための JavaScript コードは、JSON ファイルの論文リストから Python で (無理やり) 作っています。コードは GitHub に置きました。

github.com

JSON ファイルはファイルサーバー上の /srv/samba/public/paper/ に置いていて、普段使いする PC からアクセスできるようにしています。また、cron を使って毎日論文グラフを更新するようにしています。

まとめ

情報整理用サーバーを構築しました。論文読むのがはかどるといいですね。

快適な在宅勤務環境の構築について語りたい

1. はじめに

会社の寮(1ルーム)から1LDKの物件に引っ越しました。自分なりに快適に在宅勤務ができ、日常生活を送れる環境を構築したので、どんな環境にしたかとどのくらい費用がかかったかを共有します。

1.1. 注意

執筆者は在宅勤務主体であり、快適に仕事をする/生活するためならいくらお金をかけても良いという価値観を持っている人間です。ですので、

  • 在宅勤務主体の人
  • 生活の質を向上させるためならある程度お金をかけても良いと考えている人

ではない人にとってはあまり参考にならないと思いますが、ご容赦ください。

2. 全体像

部屋の全体像はこんな感じです。LDK を仕事スペース兼食事スペースにして、洋室を寝室兼個人作業スペースにしました。

仕事スペース兼食事スペース

寝室兼個人作業スペース

LDKではL字デスクと本棚を使うことで、生活スペースと仕事スペースを分けています。

2.1. 部屋全体でこだわったポイント

  • 白基調の部屋なので、家具も白っぽい色で統一した
  • 家具の配置で仕事スペースと生活スペースを分けた
  • 仕事スペースと寝室で室内の香りを変えている

3. 仕事スペース

3.1. デスク・椅子

デスクまわりのイメージ図はこんな感じです。

デスクまわりのイメージ図

写真はこんな感じ。

在宅勤務環境 (1)

モニターアームでモニターを2つ固定しています。ノートPCとあわせて3画面で仕事しています。

在宅勤務環境 (2)

ノートPC はノートPC台に置いていて、キーボードは外付けのものを用いています(写真正面奥にあるのがノートPC台です)。このように配置することで、ノートPC内蔵のモニターとあわせて横にディスプレイが3つ並ぶ状態になっています。モニターはたくさんあればあるほど幸せになれます。

キーボードはデザインで選びました。好きなデザインの方が仕事もはかどるでしょう。

また、仕事用の椅子としてゲーミングチェアを使っています。長時間座って仕事するので、座り心地が良く疲れにくいものを使うのが良いと考えています。

SwitchBotも使っています。季節によっては、室温が条件を満たした場合にエアコンをつけたり消したりしても良いかもしれないなと思っています(今はエアコンつけっぱなしにしています)。

使用しているもの

価格は執筆時に調べたものです。

もの 価格 補足
デスク ¥16,999 引っ越してから購入
モニター(1) ¥14,480 大学院の頃から使っている
モニター(2) ¥11,280 引っ越してから購入
モニターアーム ¥3,119 引っ越してから購入
ノートPC台 ¥3,299 前の家から使っている
ケーブルトレー ¥2,977 引っ越してから購入
ドリンクホルダー ¥2,974 引っ越してから購入
キーボード ¥21,880 前の家から使っている
ゲーミングチェア ¥42,900 引っ越してから購入
実際の購入価格は¥18,680
SwitchBot ハブミニ ¥5,480 前の家から使っている
SwitchBot 温度計 ¥1,980 前の家から使っている

モニターアームを使うのであれば、ASUSはおすすめしません(VESA非対応なので)。こんなやつを買わなければいけないです。

3.2. ラック

ラック

ラックには Proxmox サーバーを置いています。仕事で使わない(使えない)個人利用マシンですが、寝室に置く場所がなかったのとLANケーブルが寝室に届かなかったので、ここに置いています。

seekt.hatenablog.com

この記事で仮想化した PC にはグラボを入れて普段使い用マシンにしたので、もともと使っていた Windows PC を Proxmox サーバーにしました。今後、ミニPCかラズパイを買ってクラスタリングを試したいなと思っています。NASも導入したいです。

今使っているスイッチングハブがVLAN非対応なので、VLAN対応のスイッチを買っても良いかもしれないなと思っています。

使用しているもの

もの 価格 補足
ラック 大学生のときに購入。価格は覚えていない
デスクトップPC ¥72,360 大学院のときにCovid19の給付金で購入
スイッチングハブ ¥3,000 × 2 前の家から使っている

4. 個人作業スペース

個人作業スペース

個人作業スペースはこんな感じです。こちらもモニターアームを設置しています。仕事後はゲーミングチェアをこちらの部屋に移動させて使っています(ドアを通すのが少し大変)。

寝室にも SwitchBot を導入していて、時間の条件で電気をつけたり消したりしています。このおかげで寝坊を(ほとんど)しなくなりました。

使用しているもの

もの 価格 補足
デスク ¥4,990 引っ越してから購入
デスクトップPC ¥250,000 前の家から使っている。価格は大体
モニター(3) ¥14,480 前の家から使っている
モニター(4) ¥9,980 前の家から使っている
モニターアーム ¥3,299 引っ越してから購入
ケーブルトレー ¥2,977 引っ越してから購入
マイク ¥10,000 前の家から使っている
Webカメラ 大学院生のときに購入。価格は覚えていない
HDMI切替器 ¥3,999 前の家から使っている
収納トレー ¥2,798 引っ越してから購入
SwitchBot ハブ2 ¥8,980 引っ越してから購入

5. 回線

回線は基本的には前の家の構成を踏襲しています。

seekt.hatenablog.com

個人作業スペースのデスクトップPCには無線接続しています。無線接続のために、無線LANアダプタを買いました。

使用しているもの

もの 価格 補足
無線LANアダプタ ¥3,280 引っ越してから購入

6. その他

6.1. 香り

在宅勤務および生活をするうえで、香りは重要な要素と考えています。例えば、フローラル系の香りはリラックス効果があるとか、レモンの香りで集中力が増すとか言われていますね(論文調査等はしていないので、科学的に実証されているかはわかりません)。

仕事スペースでは集中するためにウッド系の香り(無印良品のディフューザー)を、寝室(個人作業スペース)ではリラックスするためにシトラス系の香り(SHIROのディフューザー)を使っています。

仕事スペースが LDK にあるので、料理をしたときは換気扇をしばらく回し続けないと仕事スペースも料理の匂いがしてしまうというのが最近の悩みです。

6.2. 論文

論文管理用アプリに課金し始めました。

paperpile.com

Google Drive と連携でき、iPad のアプリでメモを取るのも楽で良いです。個人利用は $2.99/month でそれなりに安いのも良いなと思っています。もともと Mendeley を使っていましたが、こちらの方が使いやすいです。

7. まとめ

快適に在宅勤務(および生活)するためにいろいろ買いましたが、生活が豊かになりました。なお、在宅勤務/生活環境を良くするために購入したものの合計額は ¥82,353 でした。ほかにもいろいろ購入しているので、引越しの総額は100万くらいかかったでしょうか。。。

今後自宅環境に対してやりたいことは、

  • Proxmox サーバーのクラスタリング
    • ミニPCかラズパイを購入
  • NASを購入してProxmox サーバーのストレージとして使う
  • SwitchBot で鍵開閉の自動化

あたりかなと思っています。

自宅インフラを育てる (4) Proxmox サーバを利用した自宅内部ネットワークの構築

はじめに

インターネット接続しない自宅内部のネットワークを Proxmox で構築して遊びました。

これまでの自宅インフラ系の記事

seekt.hatenablog.com

今回作った環境(一部抜粋)

構築した環境

内部ネットワーク(Internal Network:192.168.200.0/24)は、Proxmox の仮想サーバーでブリッジネットワークを作成し、ブリッジポートを割り当てたものです。

内部ネットワーク

Windows10 の PC に2つの NIC のうち、1つはホームネットワーク(Home Network:192.168.0.0/24)に、1つは内部ネットワークに接続しています。ホームネットワークはインターネットにつなぐことができるネットワークです。

物理構成

あまり配線が綺麗ではないですが、物理構成はこのような感じです。上が内部ネットワークに接続しているスイッチングハブ、下がホームネットワークに接続しているスイッチングハブです。

今回この環境を構築したお気持ち

そもそもなぜこのような環境にしたのか、ということについて触れておきます。

WindowsVM を使って実験をしたいと思っていたのですが、Proxmox 上に WindowsVM を立てようとしても私の環境ではなぜか動かない、ということが続いていました。どうしても解決策が思いつかなかったので、WindowsVM は Windows10 内の VirtualBox に構築し、Proxmox 上の VM からそれにアクセスできるようにする、という暫定的な解決策をとることにしました。

VirtualBox 上の VM を内部ネットワークに接続する

VirtualBox 側の設定

VirtualBoxVM を立てて、ネットワークアダプタにブリッジアダプターを割り当てます。割り当てるアダプターを間違えないように注意ですね。

VirtualBox 側の設定

VMWindows 7)側の設定

VM 側では、IPアドレスを固定します(DHCPサーバがないため)。サブネットマスクを間違えないように注意ですね。

VM側の設定

Proxmox 上の VM からアクセスできるかどうかの確認

Proxmox に立てた Kali の VM192.168.200.0/24 に Nmap スキャンをして、VirtualBox 上の Windows7 が検出されることを確認しました。

Proxmox 上の VM からアクセスできるかの確認

※ Proxmox 上の VM でのネットワークの割り当てについては過去の記事でも書いていた気がするので、省略します。

まとめ

インターネット接続しない内部ネットワークを構築し、Proxmox サーバの外から接続できるようにすることで、一気にできることの幅が広がると思いました。例えば、以下のようなことができそうかなと思います。

  • 内部ネットワークに接続した Windows 上 の VM に対する攻撃実験
  • 外部接続しない簡易ウェブサーバの構築
  • NAS 接続用ネットワークにする

今後の改良方針はまだ決めていませんが、いい感じに改良できたらまた書こうと思います。大幅な改良の前に引っ越したいですが。