bookmark_borderPrometheusで外部監視(External Monitoring)を行う

研究の実験環境の整備を行う一貫で,Prometheusで外部監視(External Monitoring)を行うことにした.最終的なゴールはHTTPリクエストをあるURLへ送信し,レイテンシ(応答時間)やステータスコードを監視することである.

Blackbox Exporter

外部監視のPrometheus Exporterで有名な実装の1つにBlackbox Exporterがある.このExporterはICMPやTCP, HTTPでヘルスチェックを行い,その結果をエンドポイントでPrometheusに公開する.Blackbox ExporterでHTTPによる外部監視を行うには,アプリケーションにメトリクスを公開するエンドポイント(例: /metrics)を実装する必要となる.今回はアプリケーションへの変更なくヘルスチェック用のHTTPリクエストに関するレイテンシを取得したいため,Blackbox Exporterでは要件を満たせない.

syepes/network_exporter

Prometheus Exporterを探していた際にX(旧Twitter)で@naa0yamaさんに要件を満たせるPrometheus Exporterとしてsyepes/network_exporter (以下Network Exporter)を教えていただいた.実際にUbuntu 22.04.3にインストールした手順を紹介する.このマシンには既にPrometheusを導入済みとする.

インストール手順

(1) Network Exporterをダウンロードする.debパッケージが公開されているためこれを使う.

https://github.com/syepes/network_exporter/releases

$ wget https://github.com/syepes/network_exporter/releases/download/1.7.5/network_exporter_1.7.5_linux_amd64.deb

(2) インストールされたか確認する.

$ which network_exporter
/usr/bin/network_exporter

(3) 起動オプションを確認する.オプション --config を使うと設定ファイルを指定できるとわかる.

$ network_exporter -h
usage: network_exporter [<flags>]

Flags:
  -h, --[no-]help          Show context-sensitive help (also try --help-long and --help-man).
      --web.listen-address=":9427"
                           The address to listen on for HTTP requests
      --config.file="/app/cfg/network_exporter.yml"
                           Exporter configuration file
      --[no-]profiling     Enable Profiling (pprof + fgprof)
      --log.level=info     Only log messages with the given severity or above. One of: [debug, info, warn, error]
      --log.format=logfmt  Output format of log messages. One of: [logfmt, json]
      --[no-]version       Show application version.

(4) 設定ファイル network_exporter.yml を作成する.

conf:
  refresh: 15m
http_get:
  intervals: 1m
  timeout: 5s
targets:
  - name: endpoint1
    host: "https://www.koyama.me/"
    type: HTTPGet

(5) Network Exporterを起動する.

$ network_exporter --config.file="$PWD/network_exporter.yml"
ts=2023-11-19T09:37:08.798Z caller=main.go:56 level=info msg="Starting network_exporter" version=1.7.5
ts=2023-11-19T09:37:08.799Z caller=main.go:58 level=info msg="Loading config"
ts=2023-11-19T09:37:08.799Z caller=main.go:147 level=info msg="Configured default DNS resolver"
ts=2023-11-19T09:37:08.799Z caller=main.go:140 level=info msg="Starting ping exporter" version=1.7.5
ts=2023-11-19T09:37:08.800Z caller=main.go:141 level=info msg="Listening for /metrics on :9427"
ts=2023-11-19T09:37:08.800Z caller=monitor_http.go:104 level=info type=HTTPGet func=AddTargetDelayed msg="Adding Target: endpoint1 (https://www.koyama.me/) in 0s"

(6) CurlでHTTPリクエストを送信して動作を確認する.http_getをプレフィクスにもつメトリクスを返すようになっている.これをPrometheusからポーリングでPullできればよい.

$ curl -s http://localhost:9427/metrics | grep '^http_'
http_get_content_bytes{name="endpoint1",target="https://www.koyama.me/"} -1
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="ContentTransfer"} 0.000182125
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="DNSLookup"} 0.00397042
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="ServerProcessing"} 0.151319333
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="TCPConnection"} 0.150696674
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="TLSEarliestCertExpiry"} 1.705613539e+09
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="TLSHandshake"} 0.154100303
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="TLSLastChainExpiry"} 1.705613539e+09
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="Total"} 0.460375409
http_get_status{name="endpoint1",target="https://www.koyama.me/"} 200
http_get_targets 1
http_get_up 1

(7) Prometheusの設定ファイルのscrape_configsセクションを編集し以下を追加する.その後,Prometheusへ設定を適用する.

scrape_configs:
  - job_name: 'network_exporter'
    scrape_interval: 15s
    scrape_timeout: 5s
    metrics_path: /metrics
    scheme: http
    static_configs:
      - targets: ['localhost:9427']

(8) Prometheusにメトリクスが格納されたか確認する.メトリクスが追加された.

クエリ言語PromQLを使いグラフを作成できた.

追記: 2023/11/19

Xで@Kawakami_KentoさんからBlackbox Exporterで出来ると教えていただいた.追試をしてみたところ,Blackbox Exporterだけで設定できた.メトリクスを上手く探せていなかっただけのようだった.

PrometheusのConfigの抜粋

  - job_name: blackbox_all
    metrics_path: /probe
    params:
      module: [ http_2xx ]  # Look for a HTTP 200 response.
    static_configs:
      - targets:
        - https://blog.koyama.me/
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: localhost:9115

  - job_name: 'blackbox_exporter'  # collect blackbox exporter's operational metrics.
    static_configs:
      - targets: ['localhost:9115']

Blackbox ExporterのConfig

modules:
  http_2xx:
    prober: http
    http:
      valid_status_codes: [200, 201, 202]
      method: "GET"
      preferred_ip_protocol: "ip4"

メトリクス probe_duration_seconds として保存されていた.

追試でのCurlした結果

おわりに

サードパーティのPrometheus Exporterをはじめて使ったが便利だった.Prometheusに比べてZabbixは公式でサポートしている機能が豊富であることを改めて感じた.使い慣れたソフトウェアを使うのもよいが,たまには使い慣れないソフトウェアを使う経験も必要だと思った.アウトプットすると理解が深まるだけでなく,フィードバックで知識の誤りに気づけてありがたいと改めて感じた.Prometheusの修行が足りないことを痛感した.

bookmark_border履歴書を支える技術

ギークなエンジニアであれば,履歴書を技術を駆使して作成する経験は一度はあると思います.転職を意識して履歴書をこの記事ではこれまでの履歴書を支えてきた技術を紹介しつつ,新たに作成した履歴書を支える技術を紹介していきます.

*最新のビルド済みの最新版の履歴書はこちらです.

背景:履歴書自作の変遷

v0. MarkdownをMacDownでビルド

Markdownで必要な項目を記述し,それをmacOSで動作するMarkdownエディタであるMacDownでPDF ファイルへビルドしていました.この方法の利点は慣れ親しんだMarkdown形式で履歴書を記述できることです.慣れ親しんだフォーマットであるMarkdownは書きやすく便利でした.

Markdown形式にともなう課題は,レイアウトの表現性が乏しいことです.組版システムではないためA4の1ページに収まるようにレイアウトするには,表現力が足りずCSSやTableを使う必要があります.そのため,新たに後述のv1に置き換えました.

v1. AsciiDocをビルド

asciidocで書いた履歴書をGitLabのCIで自動ビルド – koyama’s blog

Markdown形式でレイアウトの表現力にあった課題を解決するため,v1ではAsciiDocを記述形式に採用しました.AsciiDocはMarkdownより書き方は冗長であるものの,Markdownでは不足していたレイアウトの柔軟性が向上しました.AsciiDocはCLIツールでビルドできるため,GitLab CI上にビルドパイプラインを構築しました.スマホからでも履歴書を編集してビルドできるようになりました.

Asciidocで記述した履歴書にも課題がありました.履歴書は頻繁に更新する資料ではないため,履歴書を編集するたびにAsciiDocの文法を調べて記述していました.Markdownで記述していた際には気軽に更新できていた履歴書が,Asciidocに変更してから気軽に更新しにくい状況でした.また,細かな微修正をしたい場合の調整ができないことも課題でした.例えば,1行だけ次のページにはみ出てしまう際に,余白や行間を微修正するのが上手くいかず苦労しました.

v2. 手書きのHTMLをHeadless Chromeでビルド

AsciiDocの表現力の問題を解決するには,細かく指定できるフォーマットや技術が必要だと考えました.LaTeXの採用も検討したものの,LaTeXの処理系が出すエラーへのトライアンドエラーは嫌いなため採用を見送りました.

HTMLは書式を細かく指定でライブラリもあるため表現力が豊富です.これまでHTMLやCSSを使った経験があり編集する際にも記法で困ることがなく適していると考えました.そこで下記のCSSライブラリやアイコンセットを使いHTMLで履歴書を作成しました.

HTMLファイルからPDFファイルをビルドする際にはHeadless Chromeを使いました.たまにFont Aresomeの読み込みに失敗するため,virtual-time-budgetを長めにセットしています.

chrome --headless --disable-gpu --run-all-compositor-stages-before-draw --virtual-time-budget=8000 --print-to-pdf resume.html

GitHub Actions上にCI/CDのパイプラインを構築したため,ビルドからデプロイまでが自動化されています.デプロイ先はGCP上の仮想マシンです.以下はGitHub Actionsの構成ファイルの例です.

name: Build and Deploy
on:
  workflow_dispatch:
  push:
    tags:
      - 20*
jobs:
  build-and-deploy:
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout Code
        uses: actions/checkout@v2
      - name: Setup Chrome
        uses: browser-actions/setup-chrome@latest
      - name: Build pdf with Chrome
        run: |
          chrome --headless --disable-gpu --run-all-compositor-stages-before-draw --virtual-time-budget=8000 --print-to-pdf output.html
          mv output.pdf resume.pdf
      - name: Upload artifacts
        uses: actions/upload-artifact@v2
        with:
          name: Upload CV
          path: resume.pdf
      - name: Install SSH key
        uses: shimataro/ssh-key-action@v2
        with:
          key: ${{ secrets.DEPLOY_SSH_KEY }}
          name: id_ed25519
          known_hosts: ${{ secrets.DEPLOY_SSH_KNOWN_HOSTS }}
          if_key_exists: fail
      - name: rsync over SSH
        run: rsync -avrz -e 'ssh -i ~/.ssh/id_ed25519 -p 2222' resume.pdf user@example.com:/path/to/www

v2ではCSSを使い細かなページのレイアウトや行間を調整できv1の課題が解消しました.一方で,v2で新たな課題が生じました.その課題とは,複数のHTMLタグの修正を手動で個々に行うことです.例えば,職歴リストのデザインの変更に伴いHTMLを変更する必要がある場合を考えます.このとき職歴の要素(職歴)が5件ある場合,5つすべての要素を手動で修正する必要があります.以下のコードは実際のHTMLコードの抜粋です.このように個々の要素の構造がシンプルなHTMLであれば問題ないものの,複雑なタグが入れ子になっている場合,修正に手間がかかりました.

  <div>
    <header class="space-between">
      <strong>ジョブタイトル1</strong>
      <span>2023年1月 - 2023年6月</span>
    </header>
    <span class="org">社名1</span>
    <p>概要</p>
  </div>
  <div>
    <header class="space-between">
      <strong>ジョブタイトル2</strong>
      <span>2023年7月 - 2023年9月</span>
    </header>
    <span class="org">社名2</span>
    <p>概要</p>
  </div>

v3. テンプレートエンジンで生成したHTMLをHeadless Chromeでビルド

v2の課題を解決するためにテンプレートエンジンを導入し,ViewとDataを分離しました.データ自体は設定ファイルに切り出し,テンプレートエンジンから設定ファイルを呼び出す実装としました.これにより,類似したHTMLタグを繰り返し修正する作業が不要になりました.

Go言語の練習する一環でGo言語を使って実装しました.テンプレートエンジンには標準ライブラリに含まれる text/template を使用しています.テンプレートへ割り当てる入力値はYAML形式のファイルから読み込むように実装しました.YAML形式のデータを扱うために gopkg.in/yaml.v3 を使いました.

以下はYAML形式の設定ファイルの例です.必要に応じてYAMLファイルにデータを追加すると,履歴書が更新できます.

name_en: "Tomoyuki KOYAMA"
name_ja: "小山 智之"
github: "tomoyk"
email: "tomoyuki@koyama.me"
website: "www.koyama.me"
education:
  - school_name: "Graduate School of Computer Science, Tokyo University of Technology"
    title: "Master of Computer Science"
    date_begin: "Apr. 2021"
    date_end: "Mar. 2023"
    description: |-
      He belonged to <a href="https://www.tak-cslab.org/">Cloud and Distributed Systems
      Laboratory</a> (Supervisor: Prof. Takayuki Kushida). <br>His study proposes fast
      log search method for distributed tracing.

以下の構造体 ConfigSchemeはYAMLのスキーマをあらわしています.

type Education struct {
        SchoolName  string `yaml:"school_name"`
        Title       string `yaml:"title"`
        DateBegin   string `yaml:"date_begin"`
        DateEnd     string `yaml:"date_end"`
        Description string `yaml:"description"`
}

type ConfigScheme struct {
	NameEn                      string        `yaml:"name_en"`
	NameJa                      string        `yaml:"name_ja"`
	Github                      string        `yaml:"github"`
	Email                       string        `yaml:"email"`
	Website                     string        `yaml:"website"`
	EducationItems              []Education   `yaml:"education"`
	WorkItems                   []Work        `yaml:"work"`
	PublicationRefereedItems    []Publication `yaml:"publication_refereed"`
	PublicationNonRefereedItems []Publication `yaml:"publication_non_refereed"`
}

以下のようにテンプレートファイルで変数を展開するよう記述しました.テンプレートファイルはv2のHTMLファイルを再利用しました.

<section>
  <h2>Education</h2>
  {{ range .EducationItems }}
  <div>
    <header class="space-between">
      <strong>{{ .Title }}</strong>
      <span>{{ .DateBegin }} - {{ .DateEnd }}</span>
    </header>
    <span class="org"><i class="fas fa-university"></i> {{ .SchoolName }}</span>
    <p>{{ .Description }}</p>
  </div>
  {{ end }}
</section>

関連手法

LaTeXやWord, Google Docsを使うことが一般的なようです.YAMLで記述したデータをPDFにレンダリングする方法もありました.paper.cssを使った履歴書もありました.自作する人々は自分と考えることが似ていました.

bookmark_borderCloudflareの障害に関するポストモーテムを読んだ

Cloudflareの障害に関するポストモーテムが公開されていたので読んでみた.

Post Mortem on Cloudflare Control Plane and Analytics Outage

概要

  • DCの電力供給に原因で障害が発生した.
  • 17分間DC内の電力供給が停止していた.
  • 3箇所あるDCのうち残り2つでも継続動作するHAが組んであった.
  • 基本的に冗長構成を組んでいたが,当該DCに依存したサービスが残っていた.

感想

DCレベルで冗長化していても,実際にDC単位で落として試験しなければわからない問題があることに気付いた.カオスエンジニアリングで障害影響なくテストするかは難しいと思った.Disaster Recoveryの観点でどこまで設計するのか,どのようにテストするのかは課題の一つになると思った.このあたりは研究分野として面白いのかもしれない.

bookmark_borderCloudflare Tunnelで自宅のRaspiに外部からSSH

自宅のインターネットプロバイダでは,マンションであるためグローバルIPアドレスがルータに割り当てられない.そのため,グローバルIPアドレスの割り当てられたマシンとトンネリングが必要であった.今回は,Cloudflare Tunnelを使い自宅のネットワークにSSHする踏み台を構築した.

Cloudflare Tunnelの設定方法にはlocally-managed tunnel (CLI)とremotely-managed tunnel (dashboard)がある.今回は前者の方法を使う.基本的にはドキュメントやZennの記事を読みながすすめればよい.今回はアクセス先のエンドポイントのドメインとして remote.example.com を使う.

手順

(1) Raspberry Piにログインしrootで作業する.(systemdのserviceを作成する都合からrootに昇格している.)

sudo -i

(2) cloudflaredをダウンロードしてインストールする.

wget https://github.com/cloudflare/cloudflared/releases/download/2023.10.0/cloudflared-linux-armhf.deb
sudo apt install ./cloudflared-linux-armhf.deb
cloudflared --version

(3) Cloudflare Tunnelを設定していく.

# トンネルを作成
cloudflared tunnel create shina-tun  
# 外部アクセスのドメインとトンネルをルートとして紐づけ
cloudflared tunnel route dns shina-tun remote.example.com
# 作成したルートの確認
cloudflared tunnel route ip show

(4) Configファイルを作成する.

ホームディレクトリのパス ~/.cloudflared/config.ymlに以下のファイルを作成する.

tunnel: <Tunnel ID>
credentials-file: /root/.cloudflared/<Tunnel ID>.json
ingress:
  - hostname: remote.example.com
    service: ssh://localhost:22
  - service: http_status:404

(5) 動作を検証とサービス化を行う.

# 動作の検証
cloudflared tunnel run shina-tun
# systemdのservice化
cloudflared --config /etc/cloudflared/config.yml service install

(6) Systemd Serviceの起動を確認する.

systemctl status cloudflared
systemctl enable cloudflared

(7) CloudflareのWebからアプリケーションを作成する.

Zero TrustのコンソールからSelf-hostedを選ぶ.

以下のパラメータを設定しておく.

  • Application name: Bastion
  • Application domain: remote.example.com
  • Accept all available identity providers: チェックを外す
  • Identity providers: GitHub (以前に設定済み)
  • <Next>
  • Policy name: Bastion Policy
  • Action: Allow
  • Configure rules > Include
    • Selector: Login Method
    • Value: GitHub
  • <Next>
  • Additional settings > Browser rendering: SSH

(8) エンドポイントにアクセスする.

Webブラウザでアクセスすると以下のような画面が表示されUser/PasswordでSSH出来る.

SSHする場合にはマシンにcloudflaredのCLIツールを導入し,~/.ssh/configに以下のような記述を追加する.今回はhomebrewでcloudflaredをインストールしたためドキュメントとパスが異なる.

Host remote.example.com
  User pi
  ProxyCommand /opt/homebrew/bin/cloudflared access ssh --hostname %h

SSHする際に ssh remote.example.com と入力すると自動でWebブラウザが起動し,認証に成功するとRaspberry PiにSSHできる.

感想

ドキュメントが豊富で設定方法が複数あるため少し混乱したものの設定できた.無料で利用できる点が使いやすく便利だと感じた.インターネットフェイシングなエンドポイントがManaged Service経由で利用できるのは便利だと思った.

参考資料

bookmark_borderRFC 7258 Pervasive Monitoring Is an Attackを読んだ

ネットワークのプライバシーに関する議論がなされていた。改めて気になりRFC 7258を読んでみた。

RFC 7258 – Pervasive Monitoring Is an Attack

Attackの定義

In particular, the term “attack”, used technically, implies nothing about the motivation of the actor mounting the attack. The motivation for PM can range from non-targeted nation-state surveillance, to legal but privacy-unfriendly purposes by commercial enterprises, to illegal actions by criminals.

技術面での攻撃という用語は,実行した人物の動機には意味を持たないと書かれている.Pervasive Monitoringを行う動機の例として,対象を限定しない国民の監視や,営利企業による合法でプライバシーに不適切な目的,犯罪者による違法行為があげられていた.

But those standards generally do not address PM, the confidentiality of protocol metadata, countering traffic analysis, or data minimisation.

Pervasive Monitoringとは位置づけられていない行為には,プロトコルメタデータの機密性やトラフィック分析,データの最小化が紹介されていた.

While PM is an attack, other forms of monitoring that might fit the definition of PM can be beneficial and not part of any attack, e.g., network management functions monitor packets or flows and anti-spam mechanisms need to see mail message content. Some monitoring can even be part of the mitigation for PM, for example, certificate transparency [RFC6962] involves monitoring Public Key Infrastructure in ways that could detect some PM attack techniques. However, there is clear potential for monitoring mechanisms to be abused for PM, so this tension needs careful consideration in protocol design.Making networks unmanageable to mitigate PM is not an acceptable outcome, but ignoring PM would go against the consensus documented here. An appropriate balance will emerge over time as real instances of this Making

Pervasive Monitoringの定義に一致する攻撃に含まれない監視もある.例えば,ネットワーク管理機能が次のものを監視する場合は,Pervasive Monitoringに含まれないという.

  • パケットやフロー
  • メールのメッセージを閲覧する必要のあるアンチスパム機構

一部の監視は,Pervasive Monitoringの軽減策の一部になりうると書かれている.TCertificate Transparency [RFC6962] は一部のPervasive Monitoringの攻撃手法を検出できる方法で,PKIの監視が含まれている.

感想

監視がどのような目的でされているかが重要であることを改めて認識した.IPSやWAFに代表されるネットワークセキュリティのアプライアンスを正当な目的で使う分には,Pervasive Monitoringに含まれないように理解した.プライバシーへの配慮の重要性を改めて理解した.

参考資料

bookmark_border遅いアプリがビジネスに与える影響

入門監視(Mike Julian 著, 松浦 隼人 訳, オライリー・ジャパン, 2019)のp.77に記載のあった遅いアプリケーションがビジネスにあたえる影響を深掘りしてみた.ここではWebアプリケーションを対象としており,遅さはWebブラウザ上にコンテンツが表示されるまでを想定している.

ソースを探すのに苦労したため,備忘録のために残しておく.

Aberdeen Research

書籍の本文では,以下の記載があった.

Aberdeen Researchの2010年の研究によると、ページロード時間が1秒遅くなると、平均でページビューが11%、コンバージョンが7%、顧客満足度が16%下がると言われています。Aberdeenは最適なページロード時間は2秒以下で、5.1秒を超えるとビジネスに影響が出始めるとしています.

Mike Julian 著, 松浦 隼人 訳, “入門監視”, オライリー・ジャパン, 2019, p.77

2010年にAberdeen Researchから公開された資料のうち,確認できた資料に以下の記載があった.対応する箇所を明確に探すことができなかった.

100% of the best performing companies experienced an increase in year over year revenue growth compared with only 11% of Laggards

Chris Houpis, “Sales and Marketing Alignment Collaboration + Cooperation = Peak Performance”, Aberdeen Research (2010)

ShopzillaとAmazon

Shopzillaの事例を本文では次のように紹介している.

Shopzillaのページロード時間が6秒から1.2秒に短くなった(https://www.youtube.com/watch?v=Y5n2WtCXz48)ことで、売上げが12%増え、ページビューも25%増えたとしています。またAmazonはロード時間が100ms改善するごとに売上げが1%増えることを突き止めました(http://bit.ly/2y494hq)。

Mike Julian 著, 松浦 隼人 訳, “入門監視”, オライリー・ジャパン, 2019, p.77

Shopzillaに関するYouTubeにアップロードされた動画は以下にあった.動画内の1:21から説明しているスライドでConversion Rate(CVR)が7% – 12%増加したことが説明されており,本文の内容と一致している.スライドの中で6秒から1.2秒に短くなったことやページビューの25%増加は確認できなかった.

Amazonの事例はリダイレクト先のリンクが切れていた.同様の記述は以下の記事にあった.

bookmark_border監視/モニタリングで抑えておきたい記事

あの記事どこだっけ?を避けるためのメモです.

監視やログ,可観測性の一般的な話からKubernetesでの話までわかりやすく解説しています.

Kubernetes & Observability 入門 – Speaker Deck

Getting Started with Kubernetes Observability – Speaker Deck

外形監視を入門する人におすすめな資料です.

より意味のある監視を目指して、外形監視の有効活用 – Speaker Deck

監視設計に入門する人におすすめな資料です.

Re: ゼロから始める監視設計

*書籍「入門監視」がおすすめです.

bookmark_border新たに技術を学ぶ時に意識していること

技術をキャッチアップするときに意識していることを言語化しておくとよさそうだと思ったので残しておきます.

技術の特徴やメリット・デメリット

どんな領域や場面で使うのか,どんな特徴があるのか理解するように心がけています.

例)アプリケーションのデバッグに使うツールで,関連するデータ自動的にトレースできる.ただし,適用できるプログラミング言語の種類が少ないことが課題にある.

技術の目的

その技術は何を達成するため(目標/目的)に存在するのかを意識しています.また,技術が標準化されるまでの歴史や経緯を知ることも目的を意識するときに役立ちます.

例)アプリケーション開発者がデスクトップアプリケーションのログとサーバサイドのログを一貫して追跡するためにある.

他の関連技術との違い

先にあげたメリットやデメリットと似ていますが,他の関連する技術での実装や実現と比較して何が優れているのか意識しています.

例)既存SaaSであるXは,新しいSaaSに比べスケーラビリィが優れているが,SSOへ対応がなくパスワードレスログインの要件を満たしていない.

用語や概念の定義

新たな単語や概念がある場合は,理解する前に定義を明らかにしておきます.これは,コンテクストによって単語が意味する内容が異なるためです.

例)日本語での「認証」と対応する英単語

bookmark_borderNginxでCVE-2021-44228(Apache Log4j 2)を狙った攻撃を簡易的にブロック

Apache Log4j 2に深刻な脆弱性 CVE-2021-44228 が見つかりました.アクセスログから管理するサーバへもこの脆弱性を狙った攻撃を観測しました.

Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた – piyolog

今回はNginxで簡易的に攻撃をブロックしてみます.本質的にはペイロードを任意のヘッダへ追加された場合の対処にはならないため注意が必要です.

環境:

  • Nginx v1.20.1
  • Ubuntu 20.04.3 LTS (Focal Fossa)

設定例

以下は,設定を追加したNginxのConfigの抜粋です.mapを使い攻撃リクエストのペイロードが含まれるURLとUserAgentをパターンマッチでブロックしています.ブロックにはHTTPのステータスコード 444を使いました.

http {
    map $http_user_agent $block_ua_request {
        default 0;
        "~*\${jndi:" 1;
    }
    map $request_uri $block_request {
        default 0;
        "~*\$%7Bjndi:" 1;
    }

    server {
        if ($block_ua_request = 1) {
            return 444;
        }
        if ($block_request = 1) {
            return 444;
        }
    }
}

実際にcurlでリクエストを発行するとリクエストが拒否されていることがわかります.

$ curl "https://blog.koyama.me/$%7Bjndi:xx"
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)

余談

Qiitaへ記事を投稿しようと試みたところ,WAFにブロックされました.

参考資料

過去のISUCONで知ったNginxのmapを活用できてよかったです.

bookmark_border2020年に買ってよかったもの3選

2020年も終わるので買ってよかったものを3つ紹介します.

会議用スピーカー・マイク

会議用スピーカー・マイクのJabra SPEAK 510です.オンラインでの授業やミーティングが多く重宝しました.特に集音性能に満足しています.Bluetoothに対応しているのでiPadと接続して使えるのも便利です.

ディスプレイアーム

Amazon Basicのディスプレイアームです.今までディスプレイアームを使ったことが無かったので試しに買ってみました.ディスプレイの位置を上下や前後に移動できるメリットを実感しています.立ちながら作業するときもアームがあると自由にディスプレイが移動でき最高です.

ディスプレイ

Dellの34インチ ウルトラワイドディスプレイ P3421Wです.Twitterでりっちゃさんがオススメしていたツイートで見つけました.割引率が高く欲しい条件(Type-C対応, 30インチ以上)が揃っていたので衝動でポチりました.ディスプレイアームと組み合わせて使っています.

Dell 34インチ曲面USB-Cモニター:P3421W | Dell 日本

予定では1/7の到着でしたが12/23に届きました.とにかく最高で進捗が爆上がりです.


今年はコロナもあり生産性を向上するためにデスク周りを強化しました.来年はM1搭載のMacBook Airを買う予定です.来年も素敵なガジェットに出会える1年でありますように~!!