はじめに 2023年12月に「cURLの"--cacert"オプション利用時の挙動がmacOSとLinuxで異なる」という内容のissueが立ち、2024年3月にcURLの開発者であるDaniel Stenberg氏が「THE APPLE CURL SECURITY INCIDENT 12604」というタイトルで記事を公開しました。 この記事では本件に関する詳細の説明と検証、また独自の掘り下げを行い、macOS版cURLとオリジナルのcURLの違いについて解説します。ただし、本件は明らかになっていない部分が多くあるため、本記事には推測や仮説が含まれます。ご了承ください。 --cacertオプションにおけるmacOSのcURLとオリジナルのcURLの違い まずはDaniel Stenberg氏の記事で述べられた内容を元に、"--cacert"オプションにおけるmacOS版cURLとオリジナル

はじめに こんにちは。 2022年の4月から、さくらインターネット株式会社に新卒入社し、7月よりSRE室という部署に配属されました、菅原大和(@drumato)と申します。 本記事では、7月の配属から今日(記事執筆時点では2022/10/31)にかけての3ヶ月間、社内のKubernetesクラスタ運用状況を調査し、現状の課題を明確にした上で、社内のKubernetesクラスタ運用状況を改善する基盤の設計と開発に取り組んできましたので、その内容をご紹介します。 その過程で得られた知見や、今後必要になってくるであろう、不足している機能についても合わせて共有します。 また、本プロジェクトの背景として、SRE室という部門の目的や今後実現したい世界観についてもお話しできればと思います。 本記事の全体を通して、技術的な側面よりもプロジェクトの背景や目的を重点的にお伝えします。 本プロジェクトの概要 本

はじめに 仲亀と申します。さくらインターネットでエバンジェリストやインフラエンジニアをしています。エンジニアとしてはシステムの監視まわりの仕事をしています。最近は、今回もご紹介するPrometheusとかGrafana Lokiとか、あの辺が結構好きで触っています。 この記事では、監視について興味をお持ちの皆さんに向けて「Observabilityをはじめよう！」ということで、Observabilityの概念や、それが必要となる背景を少し説明した上で、Observabilityを実現するための要素となる、MetricsやLogsやTracesなどをどこから始めていけばいいんだろう、といったところをご紹介していこうと思います。 この記事のゴールとしては、皆さんに「Observability完全に理解した」と言っていただけたらいいかなと思っています。しかし、この記事を読んだだけですぐに皆さんの

この記事は2020年10月28日に行われたさくらの夕べ Tech Night #3 Onlineにおける発表を文章化したものです。 ダーシノと申します。さくらインターネットでフロントエンドエンジニアをやっています。この記事では、発生したバグをプログラマーに的確に伝えるためのバグ報告の書き方について説明しようと思います。 バグ報告にはコツがある！ プログラマをされている方で、過去にこんなバグ報告をもらった経験はないでしょうか。例えば「動きません」とだけ送られてきたりとか、イラッとした感情も含めた「使えねぇな！」みたいな報告、「アレもコレもソレもおかしいよ」みたいな、いろんなものが書かれた報告もあると思います。バグを残してリリースしてしまったプログラマーとしては非常に申し訳なくて今すぐ対応をしたいのですが、さすがに先ほどのようなバグ報告を受けても、我々プログラマは対応のしようがありません。「申

Docker 1.12では新たにコンテナのヘルスチェック機能が実装されており、コンテナやコンテナ内のサービスが正しく動作しているかをDockerだけで監視することができる。現時点では用途が限られているものの、同じくDocker 1.12で導入されたSwarmモードではこれを使ってサービスの再起動が可能だ。本記事ではこの監視機能について紹介する。 Docker 1.12に実装されたヘルスチェック機能概要 Docker 1.12で実装されたヘルスチェック機能は、一定間隔で指定されたコマンドを実行し、その終了コードが1だった場合が一定回数継続したらコンテナに問題が発生したと判断するものだ（図1）。 図1 Dockerのヘルスチェック機能概要 ヘルスチェック機能を利用するよう設定したコンテナでは健康状態（health）というステータスが設定され、問題が発生したコンテナは「unhealthy」、問題

オープンソースのパケット監視ツールとしてはWiresharkが有名だが、常時パケットを収集して異常を検出する、といった用途にはWiresharkはあまり適していない。そこで今回は、大規模なネットワークパケット監視向けに開発されているパケット収集・分析ツール「Moloch」を紹介する。 常時パケットをキャプチャして分析する用途に向いている「Moloch」 ソフトウェアが外部とどのような通信を行っているのかを調べたり、不正な通信が行われていないかといった調査を行ったりする際には、ネットワークに流れるパケットを取得・記録して分析できるパケットキャプチャツールが利用される。パケットキャプチャツールとして有名なものとしては、以前にも紹介したWiresharkやtcpdumpなどがある。 Wiresharkやtcpdumpは指定したネットワークインターフェイスが受信したパケットを表示したり保存したりで

Dockerなどのコンテナ技術を使ったクラスタ環境構築ツールとして広く使われているのが「Kubernetes」だ。しかし、Kubernetes環境を自前で構築するのにはやや骨が折れる。そこで今回は、仮想化技術を使って開発・テスト向けのKubernetes環境を構築するツール「Minikube」を紹介する。 Windows/macOS/LinuxでKubernetesのテスト環境を構築 Kubernetesはオープンソースで開発されているコンテナクラスタ構築ツールだ。Googleが積極的に推進していることもあり、昨今では広く使われるようになっている（図1）。 図1 KubernetesのWebサイト このKubernetesを使ったクラスタ環境の構築については以前の記事でも紹介しているが、Linux環境が必須であるほか、実運用環境に近い構成にしようとするとさまざまな設定が必要になる。Kube

サンプルサーバーのパケットフィルタは最初は以下の内容で設定し、セキュリティを確保しています。 tcp 22 はプライベートLANからの受信のみ許可 tcp 3306 は 153.127.195.113 のappサーバーだけに公開 tcp 80 は公開 tcp, udp の 32768-61000 はアウトバウンド通信の戻りパケット用に許可 ストリーミングのフラグメントパケットは公開 ip は基本拒否 また IP アドレスを打たずにホスト名でアクセス出来るように /etc/hosts に以下のエントリを追加しました。 153.127.195.113 app 153.127.203.176 db MySQLクライアントで接続して TCP の状態を観察 ここから実際にサーバーを動かして、その挙動を観察していきます。db サーバーに db1 データベースを作成し、アクセスユーザー user1 を追

ここで「ゾーン」はリクエスト中で検査対象となった部分を示しており、「ARGS」ならURLに与えられた引数（GETリクエストの引数）を示している（詳しいドキュメント）。また、この例ではidが1000、cscore0がSQL、score0が8となっていることから、IDが「1000」という検出ルールによって「SQL」というスコアが8に設定され、それによってブロックが行われていることが分かる。 NAXSIに対しWAF Testing Frameworkによるテストを実行する さて、続いてはデフォルト設定のNAXSIに対しWAF Testing Frameworkによるテストを実行してみよう。手順としてはnginx＋ModSecuriy構成の場合とほぼ同様で、nginx.confにリバースプロクシ設定（「proxy_pass http://localhost:8080/;」）を追加してnginx経由

オープンソースのWAF WAFとして利用できるソフトウェアは多数存在しており、その多くはセキュリティ企業などが提供する商用製品/商用サービスとなっている。しかし、数は少ないがオープンソースのWAFも存在する。オープンソースのWAFとしてよく知られているのが次の5つだ。 ModSecurityはApache HTTP ServerやNginx、Microsoft IISのモジュールとして提供されているものだ。このモジュールを組み込むことで、これらWebサーバーをWAFとして利用できるようになる（図1）。 図1 ModSecurityのWebサイト 活発な開発が続けられており、採用実績も多い。DebianやUbuntu、Red Hat Enterprise Linux（RHEL）およびCentOSといったその互換OSなどでは標準でパッケージが提供されており、導入も容易だ。検出用のルールセットは

前回は「Terraform for さくらのクラウド」を用いることでTerraformからさくらのクラウド上にインフラ構築を行いました。 今回は中規模～大規模な構成には不可欠なネットワーク関連のリソースについて扱います。 複数台による冗長構成でのサービス提供やスケールイン/アウト(負荷に応じて動的に台数を増減)できる構成にはネットワーク関連のリソースが欠かせませんので、しっかりと扱い方を押さえておきましょう。 前回の補足：データソースのバージョンアップ 前回データソースについて扱いましたが、2017年3月にTerraform for さくらのクラウドのバージョンアップを行い、より簡潔な書き方ができるようになりましたのでご紹介いたします。 前回はディスクのコピー元となるパブリックアーカイブのIDを参照するために、以下のようにデータソースの記述を行なっていました。 # データソース(パブリック

前回に引き続き、連載第2回である今回はTerraformにビルトインされている便利な機能を紹介していきます。 複数リソースの利用方法 リソースの依存関係 プロビジョニング 変数 アウトプット いずれの機能もTerraformを使いこなす上で重要な役割を持っていますので、着実に押さえておきましょう。 複数のリソース、リソース間の依存関係 前回は単一のEC2インスタンスを構成する例を取り上げましたが、実環境においては複数のリソースを扱うことが多いと思います。 ここではTerraformにおいて複数のリソースを扱う方法、リソースから他のリソースの情報を参照する方法について取り上げます。 また、複数のリソースを扱うことで、リソースとリソースの間に依存関係が生じることがあります。 Terraformがリソース間の依存関係をどう扱うかもここで見ていきます。 複数のリソース Terraformにて複数の

ということでOpenFlow、なんですが、仮想化・抽象化されたネットワークにおけるサービスの提供といった、いわゆるSDNの手法として導入されるケースが一般的かと思います。 しかし本稿でご紹介するのはそうした事例とは全く異なるもので、OpenFlowならではのクリーンなAPIとハードウェアスイッチの処理能力を生かした、効果的なDDoSアタック防御の手法です。 以下の内容は、ネットワークエンジニア向け情報サイト、Packet Pushersのコミュニティブログに寄稿した3本の記事をさくらのナレッジ向けに書き直したものです。 お題目 大規模DDoSアタックが発生すると、さくらインターネットのネットワーク網（以下：当社ネットワーク）への複数の入口から攻撃パケットが一気に流入してきます。 こうした大量のパケット流入によるネットワーク帯域輻輳を防ぐために、以前から当社ではd/RTBHという手法で対応し

クラウドやコンテナ技術の進歩により、近年では動的にサービスを構成するホストを増減させるような構成を容易に取れるようになっている。このような構成の際に問題となるのが、動的に増えたホストをどうやってサービスに組み込むか、という点だ。今回はこういった問題を解決するために有用なツール「Serf」を紹介する。 管理するサーバーが増えると管理の手間も増える 複数台のサーバーを組み合わせてサービスを運用することは昔から行われていたが、かつてはサーバーの導入は大仕事であり、運用中のサービスにおいてサーバーを増やしたり、逆に減らしたりする、といったことは頻繁には行われないものだった。しかし、近年ではクラウドやVPSなど、低コストで迅速にサーバーの追加/削除を行えるサービスが増えており、それに伴ってサービスの運用途中に動的に構成サーバーの数を変動させることも珍しくなくなっている。 このように構成サーバーが頻繁

AnsibleはChefやPuppetと同様に冪等性（べきとうせい）に配慮した構成管理ツールです。YAMLで記述したプレイブックのファイルが1つあれば動き、SSHさえ繋がれば対象サーバーにクライアントは不要、といったシンプルさが支持され、近年ユーザーを増やしています。 そのシンプルさは仮想マシンを利用した開発環境の構築にもうってつけに思えます。と言うことで今回はAnsibleをVagrantのプロビジョナーに使って開発環境を構築しました。 Ansibleの公式サイト Ansibleのインストール Ansibleはコントロールマシンに入っていればよく、セットアップ対象のサーバにはAnsibleのクライアントなどは不要です。SSHで接続さえできればOKです。今回のケースでは開発マシンのMacをコントロールマシンとし、Vagrantによる仮想マシンをセットアップ対象とします。 Ansible自体

「--memory」（もしくは「-m」）オプションでは、そのコンテナが利用できる最大メモリ量を指定できる。指定の際は「k」や「m」、「g」といった単位および「b」（バイト）も利用可能だ。たとえばコンテナが利用できるメモリ量を最大256MBに制限するには、以下のオプションを指定してコンテナを起動すれば良い。 --memory=256mb なお、実際の制限値はOSのページサイズの倍数に丸められるため、指定した値がそのまま制限値になるわけでは無い。たとえば上記のように「--memory=256mb」を指定したコンテナについて「docker stats」コマンドでリソース使用状況を確認すると、メモリのリミット（MEM LIMIT）が「268.4MB」となっていることが分かる。 # docker stats CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/

「さくらのアイコンセット」とは？ 「さくらのアイコンセット」は、サーバやストレージなどインフラに関連したアイコンをセットにしたものです。当社サービスをご利用をされている方はもちろん、当社サービスをご利用でない方でも、ホワイトペーパー、システム構成図、プレゼンテーション資料など様々な用途にご利用いただけます。 >>こちらからダウンロードできます。 《ライセンス》 SAKURA internet Inc. クリエイティブ・コモンズの 表示 4.0 国際 ライセンスで提供されています。 《アイコンの紹介》 「さくらのアイコンセット」を含まれるアイコンについては、下記のアイコンとなります。 1 ： general 様々な用途でご利用できる汎用的なアイコン集です。 2 ： programming PHPやPythonなどのプログラミング言語のアイコン集です。 3 ： server-parts CPU

はじめに はじめまして、サイバートラストの坂田です。SSL サーバー証明書のサポートデスクでテクニカルサポートを主に担当しています。 このたび、さくらのナレッジに寄稿させていただくこととなりました。どうぞ、よろしくお願いいたします。 さて、今回は私がお客様からよく聞かれる、SSL/TLS (以降は、SSL だけに省略して記載します)に関するお話を以下の 2 本立てでご紹介します。 SHA-1 証明書の規制・影響の振り返りと最新動向 SSL 接続時によくあるセキュリティ警告・エラーとその対策 なお、SSL に関する基本的なお話は当社の坂本が寄稿している「改めて知ろう、SSLサーバー証明書とは？」シリーズをご一読ください。 第 1 部： SHA-1 証明書の規制・影響の振り返りと最新動向 SHA-1 証明書の規制の振り返り まず、SHA-1 証明書（署名アルゴリズムが SHA-1 の SSL