befs_anneの日記

インフラエンジニアとして多少マシになっていく記録(予定)

RXアクセラレーション(というかNICオフロード)が悪さをすることがあるらしい

概要

NICが持つRXアクセラレーション系の機能が、通信のパフォーマンスに悪影響を与えるケースがあるらしい。

RX アクセレーション (GRO、LRO、TPA など) を持つ NIC が、パフォーマンスが悪い TCP の影響を受ける場合がある - Red Hat Customer Portal

https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2090294

RXアクセラレーションとは

トラフィック受信時に発生するソフトウェア(CPU)処理を、ハードウェア(NIC)に肩代わり(オフロード)してもらっちゃおうという機能。「アクセラレーション」という言葉はよく出てくる(SSLアクセラレーションとか)けど、基本的にはハードウェア処理にすることを指すと思っておけばとりあえずよさそう。

LRO(Large Receive Offload)とは

セグメンテーションされたTCPパケットの構築をNICにやらせる。

Large receive offload - Wikipedia

GRO(Generic Receive Offload)とは

Red Hat Enterprise Linux 6 の低レベルネットワーク実装は、Generic Receive Offload (GRO) のサポートをその特徴の1つとして収納しています。 GRO システムは、CPU で実行されるプロセッシングの量を低減することにより来信ネットワーク接続のパフォーマンスを向上します。GRO は Large Receive Offload (LRO) システムと同じ技術を実装しますが、より広範囲のトランスポートレイヤープロトコルに適用できます。

解説だけ見ると、LROの上位互換に見える。

https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Release_Notes/networking.html#idp11696352

TX(送信)もあるでよ

TSO(TCP Segmentation Offload)やGSO(Generic Segmentation Offload)のように、TX(送信)オフロード機能も存在する。

TSO(TCP Segmentation Offload)の無効化 - Knowlege Database

オフロード系機能まとめ

Redhatのナレッジを見るのが話早そう。

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/network-nic-offloads.html

付き合い方

ネット上には送受信どちらにおいてもOFFにせよという記事が多い。

【CentOS7】オフロード機能まとめ – ZacoDesign

そんな中、以下のような情報もある。

uzy-exe.hateblo.jp

速さを追い求めるのでなければ、OFFが吉?

SRE Tech Talks #2に参加した

概要

「SREとか超かっけえ」という生半可な気持ちで「SRE Tech Talks #2」なるイベントに参加して思ったこと。

SREとは何なのか

TLに流れてくるSRE関連ツイートから「SRE=超できるインフラエンジニア、または彼らによるエンジニアリング」ぐらいの定義をしていて、あぁなんて高い山だろうと勝手につらみを感じていたんだけど、最初のセッションでメルカリの@cubicdiyaさんがSREのミッションをオペレーションとソフトウェアエンジニアリングの2つにシンプルに定義してくれて、SRE(する)とは?っていうモヤが少し晴れた。Googleが公開したドキュメントも読み込んでみようと思う。英語苦手だけど。

Google - Site Reliability Engineering

技術が資本

登壇者の方々や懇親会でお話しした方々は皆スキルフルで、やっぱりSREも技術があって、その上で何をするか、なんだなと思った。On-Call Engineeringは目から鱗。他の登壇者の方のセッションも、DBチューニング、サーバクラスタリング、バックアップ技術など、同じSREという括りの中で、裾野の広さを感じさせられた。

制度も大事

@cubicdaiyaさんのセッションの話ばっかりだけど、制度設計や会社の理解も重要だと思い知らされた。「皆電車乗ってたら困るから、On-Call当番は他のメンバーが出社した後に遅れて出社する」とか、On-Call対応期間中の手当とか。

ネットワークエンジニアから見たSRE

Site Reliabilityっていうぐらいだから、やはりWeb/DB/Appのウェブ系三銃士(人によってはリバプロが加わる)の話がメインだった。やっぱりまだまだサーバサイドの修行が足りない。特にMySQLの話なんかチンプンカンプンだった。

インフラエンジニアに囲まれて仕事をしているからなんとなく自分もインフラエンジニアという括りにいれてしまいそうになるけど、実際のところ未だにネットワークエンジニアしている。それも昔ながらのネットワーク屋って感じの。同じようなことをしている人達を貶めるつもりは一切ないし、ネットワークは好きだから、私はネットワークのためにコードを書いて、ネットワークのためにAPIを叩きたい。

そんななので、イベント中「ほとんど(と言うか全く?)ネットワークについて誰も話さないけど、ネットワークってSite Reliabilityには関わってないの?」と思ってしまう。ネットワークエンジニアの視点から見たSREもまたオツだと思うので、ぜひ聞きたいし、私も話したい(でも自社の事例を話せるようなフランクな会社でないのがつらいところ)。

Windows10のVagrantでJuniper Fireflyを動かすまで

概要

このQiitaの投稿を見て思い立った。一筋縄ではいかなかったので、手順を残しておく。VagrantVirtualBoxはインストール済み。

qiita.com

手順

boxをダウンロード

vagrant box add firefly121X47D154 https://atlas.hashicorp.com/juniper/boxes/ffp-12.1X47-D15.4

Vagrantfileの生成と編集

ディレクトリを作ってvagrant initする。vagrantディレクトリは作成済み。

cd vagrant
mkdir firefly01
cd firefly 01
vagrant init firefly121X47D154

記事で紹介されていた通りに編集。

vim Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
    config.vm.box = "firefly121X47D154"
    config.vm.define :firefly01 do | firefly01 |
        firefly01.vm.hostname = 'firefly01'
        firefly01.vm.network "private_network",ip: "192.168.33.1",netmask: "255.255.255.0"
    end
end

VMを起動

vagrant upでVMを起動しようとしたら、プラグインをインストールするよう言われたので素直にインストール。

vagrant up # 以下プラグインのインストールを要求される
vagrant plugin install vagrant-host-shell
vagrant up # 以下プラグインのインストールを要求される
vagrant plugin install vagrant-junos
vagrant up # 成功

vagrant statusで確認すると、無事runningに。

Fireflyにログイン

ここで問題発生。記事ではvagrant sshでログインするが、Windows10にはデフォルトでSSHクライアントが入っていないためvagrant sshができない。bashからもSSHを試したがこれも不可(公開鍵認証しか許可されていないから?)。

①Git for Windowsをインストール

最初のトライでやった対応。以下の記事を参考にGit for Windowsをインストールする。

d.hatena.ne.jp

ホームに作成されたアイコンをダブルクリックして開いたプロンプトからVagrantfileがあるディレクトリへ移動し、vagrant sshする。インストール時にWindows標準のプロンプトを使用するよう指定したが、反応が非常に悪い。

bash on Ubuntu on Windowsからログイン

先ほど試したらうまくいったので併せて記載しておく。vagrant sshは公開鍵認証を利用してSSHログインするわけだが、前述の通りWindowsにはデフォルトでSSHクライアントはない。しかし、秘密鍵はしっかり作成してある。以下のコマンドで出力される「 IdentityFile」にその絶対パスが記載されている。

vagrant ssh-config

秘密鍵の所在を確認した後、以下を実行する。

  1. 秘密鍵bashの~/.ssh配下に格納(多分ここじゃなくても大丈夫)。
  2. ファイル名を「id_rsa」に変更。

以下を実行すれば、パスワード認証なしでログインできる。

ssh root@127.0.0.1 -p XXXX

1を実施しただけではログインできなかったのだが、秘密鍵のファイル名は「id_rsa」じゃないとダメなんだろうか?

※追記

秘密鍵の指定って方法もあるのか。

www.ellinikonblue.com

Fireflyの設定変更

SSHログインさえできれば、あとは新規のログインユーザを作るもよし、そのまま検証するもよし。

IOS-XRvをVirtualBoxとGNS3で動かすまで

概要

タイトルの通り。某所でアリスタ社の方が「SNMP古い!これからのテレメトリーはgRPCだ!!」とおっしゃっていて、gRPCとは何ぞ~と思っていたところに「IOS-XRvのデモ版がタダで使えて、gRPCが動く」なんてツイートを見たので飛びついてみた。まずはPC上(Windows10、VirtualBoxとGNS3インストール済)で動かして、pingで疎通確認するところまで。

参照

www.youtube.com

www.routingloops.co.uk

手順

Ciscoサイトからイメージをダウンロード

以下のサイトからISOイメージをダウンロードする(要Cisco ID)。最新リリース(6.1.1)はOVAファイルしかないようだったので、それを落とした。

https://upload.cisco.com/cgi-bin/swc/fileexg/main.cgi?CONTYPES=Cisco-IOS-XRv

以下参考。

itpro.nikkeibp.co.jp

VirtualBoxVMを作成

「ファイル」→「仮想アプライアンスのインポート」を選択して、先ほどダウンロードしたOVAファイルを選択する(画像の「iosxrv01」は練習がてら作成したもの)。

f:id:befs_anne:20161214215044j:plain

f:id:befs_anne:20161214232449j:plain

初期設定は、名前とCPU、RAMだけいじっておく(8GBも食わせられないので)。

f:id:befs_anne:20161214225426j:plain

VMが完成。細かい設定をしていく。

f:id:befs_anne:20161214225657j:plain

起動時に読み込むメディアからフロッピーと光学を外す。

f:id:befs_anne:20161214225720j:plain

ネットワークアダプタMACアドレス以外全て同じ設定。

f:id:befs_anne:20161214225744j:plain

シリアルポートの設定。

f:id:befs_anne:20161214225805j:plain

GNS3でテンプレートを作成

「Edit」→「Preferences」→「VirtualBox VMs」を選択する。

f:id:befs_anne:20161214225927j:plain

「New」ボタンをクリックして新規テンプレートを作成する。

f:id:befs_anne:20161214230003j:plain

以下のように設定。

f:id:befs_anne:20161214230217j:plain

f:id:befs_anne:20161214230154j:plain

GNS3でVM配置、起動

画面左のルータの形をしたアイコンをクリックして、先ほど作成したiosxrv02を画面中央にD&Dする。

f:id:befs_anne:20161214230411j:plain

f:id:befs_anne:20161214230431j:plain

画面上部の再生ボタン(Start/Resume all devices)をクリックすると……こいつ、動くぞ!

f:id:befs_anne:20161214230700j:plain

ルータアイコンを右クリック→「Console」でコンソールを確認できる。

f:id:befs_anne:20161214230709j:plain

設定、結線、疎通確認

iosxrv01も起動して、もろもろ設定。

# iosxrv01
configure terminal
hostname iosxrv01
interface gigabitethernet 0/0/0/0
ipv4 address 10.0.0.1 255.255.255.0
no shutdown
commit
end

# iosxrv02
configure terminal
hostname iosxrv02
interface gigabitethernet 0/0/0/0
ipv4 address 10.0.0.2 255.255.255.0
no shutdown
commit
end

※まだ結線してないのに、no shutした段階でUp/Upになるのは……なぜ?

画面左のケーブルの形したアイコンをクリックして、各ルータアイコンをクリックしてケーブルを接続するI/Fを選択する(今回はEthernet0どうし)。

片方のiosxrvのコンソールから、対向のIPアドレスに向けてpingを送信する。

# iosxrv01
ping 10.0.0.2

無事通った。今日はここまで。

f:id:befs_anne:20161214231450j:plain

所感

はじめてIOS-XR触った。明らかに私がこれまで触ってきたIOSとは違うし、Junosとも違う。ハーフと言うとしっくりくる。本来の目的はgRPCの検証だけど、これを通してIOS-XRの習熟も図りたい。

あと概要を書いている時(「アリスタ社…」のところ)にアリスタのvEOSを思い出した。こっちでやればいいのでは……?gRPCできるか分からないけど。

VirtualBoxでAristaのvEOSを使えるようにする

……これはこれでやろう。

「転職しなきゃ」という病

主な症状

知り合いの転職をきっかけとして、現在の職場、キャリア、エンジニアとしての市場価値に対する漠然とした不安感に襲われ、直近のタスクが手につかなくなる。症状が重くなると、現職の業務が満足にこなせていないにも関わらず、転職活動を始める。

予防・治療

  • 自身のキャリアパスの具体化と微調整(月次、年次など)。
  • キャリアパスを具体化する過程で洗い出した必要なスキルや経験の習得計画の策定と実施。
  • 資格取得、勉強会参加などによる自己啓発(ただし、無闇に実施するとキャリアパスに悪影響を及ぼす可能性もあるため注意)。

所感

仲良くしてくれる同期が近々転職するという話を聞いて、久々に症状が出てきた。一番最初に発症したのは尊敬している上司が帰りの電車で「転職を考えている」と言った時。その時は結局私の方が早く転職した。

【資格】ネットワークスペシャリスト 平成26年 午後Ⅰ 問2のファイアウォールの仕様だとかを整理してみる

概要

ネットワークスペシャリスト 平成26年 午後Ⅰ 問2のファイアウォールの問題が何だかよくない気(俗に言う違和感)を発しているので、整理しながらこの気の発生源を突き止めてみる。

問題文から読み取れるFWの仕様

問題文から、FWの仕様に関する記述のみ抜粋する。私が想像したことはそれと分かるように記載している(つもり)。

  • Z社では、FW1を主系に設定し、FW2を副系に設定したActive-Standby冗長構成を採用し、運用を行っている。
  • 通常時、FWは、必ず主系がActive動作になり、副系がStandby動作になる仕様である。
  • FW間にはフェールオーバリンクと呼ばれる専用接続があり、設定情報の同期、管理情報の複製、及び対向FWのの動作状態の識別に使用されている。
  • FWの冗長化機能は、仮想アドレスを使用する方式ではなく、主系のIPアドレス及びMACアドレスを副系が引き継ぐ方式である。
  • 新たにActive動作となったFWは、切り替わったことを通知するフレームをFWはの各ポートから送信する。FWに接続しているスイッチは、このフレームを受信することで、レイヤ2機能で用いるテーブルを適切に更新することができる。
    • 疑問1: こんなフェールオーバ通知機構があってよいのだろうか?
      • 周囲の機器の実装に期待している?例えば、FWがフラッディングしたフレームを、ARPテーブルを持つノードが受信する→MACアドレステーブル上で、フレームを受信したポートに紐付いているMACアドレスを上書きする→MACアドレステーブル上で書き換えられたMACアドレスを、ARPテーブル上でも新しいMACアドレスに書き換える、的な……。そんなわけないか。問題中でもGrauitous ARPを引き合いに出しているということは、純粋にMACアドレステーブルしか更新しないんだと思う。
      • (追記)「FWの冗長化機能は、仮想アドレスを使用する方式ではなく、主系のIPアドレス及びMACアドレスを副系が引き継ぐ方式」だから、フェールオーバしてもゲートウェイとして提供するIPアドレスMACアドレスは変わらない。つまりフェールオーバした時にFWが通知する必要があるのは「自身のインタフェースの方向」だけだから、Gratuitous ARPはいらない、ということだと一晩寝たら気づいた。今回の障害は主系設定のFWを交換したからFWのMACアドレスが変わってしまったことによる、周囲のARPエントリとの不一致。「Gratuitous ARPだったらこんなこと起きなかった」だけであって、通常のフェールオーバにおいてもGratuitous ARPが必要だったかというと、そんなことはない(Gratuitous ARPのほうがベターだとは思う)。
  • Active動作のFWを副系から主系に切り戻すためには、手動設定が必要である(=プリエンプションしない)。
  • 起動時にフェールオーバリンクによって、他のActive動作中のFWを認識すると、主系又は副系であるかにかかわらずStandby動作に入る。このとき、FWは自己の設定情報を無視して、Active動作中のFWから設定情報を同期する。
    • 疑問2: 「起動時」とは「起動プロセス中」のことか?起動プロセスが終わった後のことか?それとも双方を含むのか?

障害発生の流れ

FW1が故障してから、U君がやらかして障害発生、解決するまでの一連の流れを、事後の調査で判明した原因も含めてまとめる。なお、問題文中では交換が済んだあたりから代替機をFW1と呼んでいるが、この記事では一貫して故障したFW1を「FW1」、代替機を「代替機」と呼ぶことにする。ただし、問題文を引用する際はその内容に準ずる。

  • FW1が故障したので、FW2にフェールオーバする。この時点でFW2は副系設定かつActive。
  • FW1の結線を外してからアンマウントする。
  • 代替機(工場設定のまま=主系設定)をマウントし、結線する(しかし、SW2との接続ができておらず)。
  • 代替機に電源投入。フェールオーバリンクが確立されていないので、現在ActiveのFW2の存在を認識できず、代替機もActiveでブートする。
  • 少し経ってからSW2のFW1接続ポートのLEDが消灯していることに気づき、挿し込む。リンクアップを確認(=FW間のフェールオーバリンクが確立)する。
    • 疑問3:「少し経ってから」とは、代替機の起動プロセス中か?それとも起動プロセスが終わった後か?
  • FW2は代替機の存在を認識し、Standbyへ移行する。同時に代替機の設定情報を自身に同期する(=Z社のフィルタリングルールを含む設定情報が失われていた理由)。
    • 疑問4: 代替機もFW2の存在を認識したのに、Standbyにならないのは何故か?
      • 他のActive動作中のFWを認識すると、「主系又は副系であるかにかかわらずStandby動作に入る」はずなので、代替機もStandbyにならなきゃおかしい。
      • 疑問1における「起動時」が「起動プロセス中」を指していて、この時点では代替機の起動プロセスが完了しているから?→だとしたらFW2も完了しているので、両方Activeのままなはず……。
      • 実はフェールオーバリンク上でアップタイムをやり取りしていて、Dual-Activeの場合は両機のアップタイムを比較して一定以上差がある場合短いほうはActiveのまま、みたいな裏設定が存在する?→問題文に書いとけよIPAナニコラタココラ。
  • 障害発生。苦情相次ぐ。
  • 代替機とFW2の設定を確認、Z社のフィルタリングルールを含む設定情報が失われていることを確認する。
  • FW1の設定情報を復元(とってあったFW1の設定情報のバックアップを代替機に投入?)し、FW2に設定情報を同期(手動?)するも、障害復旧せず。
  • 事故の原因を特定して通信を回復(=周辺機器のARPテーブルをクリア)した。障害復旧。

根本原因

障害復旧後に作成された「表1 FW故障時の交換作業手順」を見るに、FW1が故障した場合の手順の最初に「代替機の主系設定が解除されていることを確認する」とある。障害復旧後の事実確認においては「FW1が主系設定であったので…」の文言があるため、そもそもの原因は「代替機が工場出荷状態のままであり、工場出荷状態では主系設定になっている」ことが原因であると言えそう。

L2SW(SW2)の存在意義

障害発生の契機はU君が半挿しのケーブルをカチッとしてしまったことだが、これはあくまで契機であって原因ではない。「あってよかったSW2!」ということにもなっていない。フェールオーバリンクが確立しているかどうかだけであればFW間を直接接続していても分かるわけで、やはりSW2の存在意義はフェールオーバリンクが落ちている時に、SW2のポート状態からどちらのFWのポートが落ちているか(=故障しているか)を判断できる、ということのみであると言えそう。そんなことのために障害ポイント増やすかね?

主系と副系、ActiveとStandby

主系「設定」という言葉が問題文中にあることから、主系と副系には何らかの設定差異があることが分かる。単なる呼び名(奇数系と偶数系的な)や、それに基づく「もともと」Activeであるノードかどうか、だけではなさそう。起動時に主系設定だったら他のActive機を探して、いなければ自身がActive機になる。いればStandby機になる。ただし、疑問2と疑問4で提起している通り「起動時」の定義はあいまい。一方、起動時に副系設定だった場合は、Active機が存在するかどうかに関わらずStandby機になり、Active機がいたらその設定情報を自身に同期する。たぶん。

所感

「起動時」の定義とか「Dual-Activeの時の挙動」の定義がグダグダなんだと思う。CiscoのASAの挙動と酷似しているという情報もいただいたが、ごめんなさいもう眠くて何も考えられません。

フェールオーバーの設定 - Cisco Systems

【資格】ネットワークスペシャリスト 平成26年秋期 午後Ⅰ 問3

概要

ネットワークスペシャリスト 平成26年度午後Ⅰ問3の復習。ネットワークセキュリティがテーマの問題。

設問1

穴埋め。正答数を稼ぎやすいので全問正解したいところだが、5問中2問間違った。

ひとつはDDoSについて。Distributed Denial of Serviceの略だが、この問題では「XXX型DoS攻撃」のXXX、すなわちDistributedを日本語で何と訳すかという問題だった。いやらしい、いやらしすぎる。答えは「分散型」だった。かなり悔しい思いをしたので忘れないだろう。

e-words.jp

もうひとつはDNSの攻撃手法(DNSXXX攻撃)。攻撃対象のホストのIPアドレスを偽装して脆弱性をほったらかしにしているオープンリゾルバにクエリを送り、攻撃対象のホストに対して大量のDNSレスポンスを食らわせるDDoSの一種は「DNSアンプ」と回答したのだが、RFC5358とやらの記述を引用し、今は「DNSリフレクター」というらしい。

技術解説:「DNS Reflector Attacks(DNSリフレクター攻撃)」について

JPRSでは公式文書における本攻撃手法の名称として「DNS Amp攻撃」を使用してきましたが、今後はRFC 5358[BCP140]における記述に従い「DNS Reflector Attacks(DNSリフレクター攻撃)」を使用します。

e-words.jp

設問2

(1)

「踏み台」が正答のようだが、これはあくまで俗語であって問題の正答とすべきではないのでは……(IPAの公式解答も見たけど同じく「踏み台」になっていた)。個人的には(NW機器間の配線を指す)「わたり」と同一線上に存在する表現なんだけど。

(2)

FWが大量かつ大きいサイズのICMPを利用したDDoS攻撃に対応するために必要な機能は?という問題。

www.atmarkit.co.jp

「echoデータ」フィールドには、ICMPエコー・メッセージを利用するアプリケーションが何らかの値をセットしておく(データの内容は何でもよい)。一般的には、バイナリ・データ(0x00~0xffまでを順番に1ずつ変更したもの)が使われることが多い。

ICMPはメッセージ部が可変長になっており、内容は送信者の任意である。受信者はリプライの際に全く同じメッセージをリプライするようで、メッセージ部のサイズが大きいと往路と復路の両方で帯域や機器に負荷がかかる。これらを踏まえて「一定以上のサイズのICMPエコーを破棄する機能」でも大丈夫そうだが、IPAの回答例を見ると「断片化されたICMPエコーを許可しない機能」となっている。でかい=(FWに到着する頃には)断片化されている、ということだろうか?

ちなみにICMPフラッドについてググっている時に「smurf攻撃」がひっかかったのでメモしておく。

e-words.jp

攻撃の経路としてはDNSリフレクタと同様か。

設問3

(1)

問題中では「DMZDNSサーバのキャッシュ機能を無効にする」設計になっており、これをしないことによるセキュリティリスクを答える問題。DNSキャッシュポイズニング絡みだろうと思ったが、うまく文に出来なかった。

正答は「DNSキャッシュが改ざんされる」とある。

www.atmarkit.co.jp

ここで、フルリゾルバのキャッシュに何らかの偽情報を注入することができると、エンドユーザーのクエリに対して偽情報を答えさせることができ、エンドユーザーを偽のWebサイトに誘導したり、エンドユーザーのメールなどを盗んだりすることができる。この行為を「DNSキャッシュポイズニング(キャッシュ汚染)攻撃」と呼ぶ。一度キャッシュへの注入が成功するとキャッシュでの生存期間、誘導が成功する。生存期間の長い情報を注入することで、汚染を長く継続することができる。

キャッシュ機能を無効にしておけば、悪意のあるDNSレスポンスがキャッシュされることはない。

(2)

DNSサーバの設計に携わったことがないので未知の世界だった。与えられた条件は以下の通り。

  • DNSサーバが管理するドメインDMZと内部セグメントに分けて、それぞれでゾーン転送を行う。
  • DMZDNSサーバはキャッシュ機能を向こうにしたセカンダリ(DNSサーバ)の冗長構成として、DMZに存在するグローバルIPアドレスを割り当てられたWebサーバの名前解決に使用する。
  • 内部セグメントのプライマリDNSサーバは、DNSの問い合わせを受けずにセカンダリDNSサーバにだけゾーン転送する。
  • 内部セグメントのセカンダリDNSサーバは、内部セグメントに設置されたデータベースサーバの名前解決に使用する。

ゾーン転送のおさらいをしておく。更新したゾーン情報をセカンダリに同期するための機能。

3 Minutes Networking No.68

www.atmarkit.co.jp

TSIG(Transaction Signature)は、なりすましセカンダリに対してゾーン転送することを防ぐための機能。

www.atmarkit.co.jp

(3)

内部から外部への不正な通信を発見、防止するためのFWでの対策を2つ挙げろ、という問題。これ、ネスペの不文律なのか知らないが、「XXまたは◯◯」かつ「2つ挙げよ」の場合、XXでひとつ、◯◯でひとつ回答するということらしく、それに則ると発見と防止それぞれのために必要な対策を答えることになる。

「通信の宛先が海外など不審なものでないかを確認する」「ペイロードが機密情報かどうかを確認する」と回答したのだが、前述の不文律もあるので「うーんそういうんじゃないんだよね」とバツ食らう気がする。正答は「内部から外部への通信に対する遮断ルールを設定する」(防止)「FWで遮断した通信の結果ログを監視する」(発見)ということらしい。一般的にはホワイトリストを用いると思うのだが、前者はあらかじめ某国宛の通信を遮断しておくとかそういうことだろうか……。あまり納得がいかない問題。

設問4

(2)

(インシデント)対処結果の報告の後、将来発生するインシデントへの対応として、セキュリティ担当者が実施すべき事項を述べよ、という問題。「恒久的な防止のための対策を検討する」と回答したのだが、どうやら「将来発生するインシデント」という文言があることによって「再度発生すること」を前提としているようで、次回同じことが起きた時により迅速に対応できるよう「対処結果の評価を行いインシデントの対処方法を見直す」が正答となっていた。

所感

セスペはネスペの部分集合のような気がしてきた。セキュリティ分野の問題でもあまり点を取れていないので、セスペの参考書を見直すのもいいかもしれない。通勤バッグが重たくなる……。