arashi1977さんの助け合いフォーラム投稿一覧

助け合いフォーラムの投稿
2024/10/14 コメント
VPCのデフォルトのセキュリティグループのルールについて
考慮すべきポイントがいろいろ混ざっているようなのでひとつずつ整理すべきかなと言うところではあります。 前提として、ご質問の冒頭にあるように > VPCのセキュリティグループのデフォルトのルールでは「インバウンドは全て拒否、アウトバンドは全て拒否」かと思います。ルールも許可設定しかできないはずです。 ですので、基本的には許可制であり、許可されていないものは通さないわけです。そして同様に冒頭でご認識されている通り > デフォルトだとアウトバンドは許可されている ので、ここをきちんと「不許可」とすれば良いわけです。 また、「本来この通信のみが自発かつ想定される通信パターン」と言う前提でセキュリティグループの設定をするわけですから、それ以外のトラフィックが通らないように「デフォルト許可」を編集して意図しない自発トラフィックが出て行かないようにするのも大事な対応かと思います。 さらに言えば「そのような想定外の自発トラフィックを発生させるプロセス」が存在しないようにサービスを作り込む、と言うのも必要なことかなと思います。不正プロセスが組み込まれるとしたら EC2 インスタンスがありそうですが、その場合は検知して即インスタンスをイメージから作り直すことで不正プロセスが稼働していない状態にするとか、インスタンスの元イメージの改ざんをさせないことでインスタンス生成後即時不正プロセス起動といったことが起こらないようにするとか、いろんな観点で「そもそも意図しないアウトバウンドトラフィックが発生しない」ように対策するというのが必要になる、と言うことではないかなと思います。
2024/10/14 返信
問題文誤り?

これ、誤解しやすいんですよねぇ…と思いつつ、

正しくはログレベル以上ではないでしょうか。

このように判断された根拠となる情報もつけていただけると、相互理解が進みやすくなるのでありがたいです。

参考に

それぞれのレベルはその下の全てのレベルを含みます。レベルを低くする程、より少ないメッセージがログに送られます。

とあるので、「以上=より多いメッセージ」を意味しますので、解説は正しいですよ。
レベルの数字についてはこちらにも記載があります。

Wikipedia「syslog」の「重大度」
https://ja.wikipedia.org/wiki/Syslog#%E9%87%8D%E5%A4%A7%E5%BA%A6%E3%83%AC%E3%83%99%E3%83%AB

3(Error)を指定すると、よりレベルの低い2(Critical)/1(Alert)/0(Emergency)が出力されるが、より高い4(Warning)や5(Notice)は表示されない、と言うことです。またこのことから、最もレベルの大きい7(Debug)を指定すると、syslogに送られる全て(7以下)のメッセージがログ出力されるようになる、と言うことでもあります。

2024/10/13 コメント
VPCのデフォルトのセキュリティグループのルールについて
> ということは、セキュリティグループのみを使って通信をフィルタしきることは難しいのでしょうか? 具体的にどのようなことをイメージされているかがわからないのでコメントできません。お役に立てずすみません。
2024/10/12 返信
VPCのデフォルトのセキュリティグループのルールについて

どの問題IDに関するご質問かがわからないので、ご質問の意図を読み違えていたらすみません。

例えば、インスタンスから意図しない通信が開始してしまった場合、デフォルトだとアウトバンドは許可されているので、それがインターネット宛に出ていってします。ステートフルなので、この通信は帰ってきてセキュリティグループでフィルタ出来ないということでしょうか。

そうですね、基本的には「許可されたアウトバウンドトラフィックに対する戻りのインバウンドトラフィックは許可」される認識で良いかと思います。

2024/10/09 コメント
屁理屈かもしれませんが・・・
横から失礼します。 ホスト型でもハイパーバイザ型でも、tomomo1109さんのコメントに変わりはないです。 - Linux KVM(ハイパーバイザ) 上で、Linux / Windows / FreeBSD などといった異なるOSを稼働できるが、それらのOSは KVM を動かしている Linux OS を共有しているわけではなく、Linux OS が稼働するハードウェアリソースを共有している。 - Windows 上の VMware Workstation で Linux / Windows / FreeBSD などといった異なるOSを稼働できるが、それらのOSは VMware Workstation を動かしている Windows を共有しているわけではなく、Windows が稼働するハードウェアリソースを共有している。 と言うことになるわけですが、どちらも仮想環境のOSは実行環境のOSを共有していないです。OSを共有すると言うのは「そのOSの機能を使う」と言うことですが、ホスト/ハイパーバイザー型は仮想環境からOS機能を呼び出さず、逆になんとかしてハードウェアに直接アクセスできるようにします。(CPU の仮想化支援機能である VT-x とか、NICやらに対する SR-IOV とか) OSを共有するのはコンテナ型ですね。Docker とかで、仮想環境は実行環境の Linux カーネルの機能を直接使います。逆に言うと、共有しているので「どれかの仮想環境だけ異なるOSにする」「どれかの仮想環境だけ Linux カーネルをバージョンアップ(ダウン)する」と言うことはできないのですよね。共有して使っているので。
2024/10/07 返信
参考における、【チェイン】の図解が良く分からない

回答に対しての返信ではなく追加質問にされているので、別の回答としてぶら下げます。

Outbounding付近のルーティングについては、
複数のNICを使い、相手のipアドレスによって使用するNICを振り分けしている感じでしょうか。

102、201範囲の「ルーティング」に関するところをもう少し補強した方が良いのかもしれませんね。時間や余裕があればCCNAの学習で「ルーティング」に関する基本だけでも押さえると理解度が上がると思います。

ルーティングは

  • 自分が受信したパケットを自分が受け取るべきか別の誰かに転送(ルーティング)するべきか
  • パケットをどのインターフェースからどのアドレスに(ルーティング)送信すべきか

の2パターンで発動します。前者の場合は「転送すべき」となった時点で「どのインターフェースからどのアドレス向けに出力するか」が決まっているので FORWARD チェインの後では実行されません。対して OUTPUT の前の段階では、ローカルプロセスがパケットを生成しただけで、まだ「どのインターフェースからどのアドレス向けに出力するか」が決まっていません。OSはプロセスから「パケットを受け取ってから」ルーティング処理を行い、どのインターフェースから出すのかを決定します

複数の NIC は物理的なものに限りません。 veth とか lo とか br とかの仮想インターフェースでも同じことです。

2024/10/07 コメント
参考における、【チェイン】の図解が良く分からない
あ、「ホスト」が物理サーバかコンテナかは問わないことに注意してください。「自分自身(のアドレス)宛ではない」と言うことがポイントです。
2024/10/07 返信
CDPのメリットはなんなのでしょうか?

CDP(Cisco Discovery Protocol) はその名の通り「隣接しているCiscoデバイスの情報を確認」するためのシスコ独自のプロトコルです。
対してLLDP(Link-Layer Discovery Protocol) は IEEE 802.1AB で規定された「標準」プロトコルであり、シスコ以外のベンダーも実装して利用しています。

使い分けたいかどうかは環境によると思います。全部シスコ製品だから CDP 使う、でもいいですし、シスコも含むマルチベンダーで構成しているから LLDP を使う、とか。オールシスコだけど標準準拠でいきたいから LLDP ってのもありですね。

2024/10/07 返信
参考における、【チェイン】の図解が良く分からない

サーバ自身宛か、別のホストへ転送すべきものかを判断するための「ルーティング」ですね。サーバだからといって受け取る全てのパケットが「自分自身宛」とは限りません。

2024/10/05 コメント
バインディングデータベースとARPテーブルの違いについて
あれ?意図と違う伝わり方してしまいました。表現下手ですみません。 L2スイッチはARPテーブル持たないですよね、って言ってるつもりでした。
2024/10/04 返信
バインディングデータベースとARPテーブルの違いについて

ARPテーブルってARP(Address Resolution Protocol)によって解決した情報を記録してあるものですよね。で、ARPが何のためにあるかって、「あるIPアドレスを持つ装置のMACアドレス」を知りたいからですよね。その目的って「IPで通信するために、IPパケットの送信先になるMACアドレスを知る」ことです。

で、今回の話で言うと「L2スイッチ自体が誰かとIPで通信する」場合にはARPが必要ですしそのためのARPテーブルを持つわけですが、それがない前提ですよね?(スイッチは基本的にL2フレームをスイッチングするだけなので、IPで通信するものではない)
また、「(DHCPスヌーピング)バインディングデータベースがARPテーブルと同一視できるか」と言うお話であれば、DHCPどこいった?って話になりますよね。

と言うことで結局は

単に用途の違い

と言うことになるかなぁと思います。

2024/10/02 コメント
なぜレートベースが正解なのか
修正されたようですが&セキュリティ本職じゃないので今更かもしれませんが。 IPアドレスを頻繁に変更するのって「対策されたから」というのがモチベーションのはずであって、「頻繁に変更 **しながら** ちょっとずつリクエストを送る」というのは手間とか効果を考えると採用されにくい攻撃方法かなぁと思います。 なので、個人的には問題としても特におかしくないのではないかなと思っています。
2024/09/30 コメント
なぜレートベースが正解なのか
なるほど。 頻繁にIPアドレスを変更する不審な外部アクセスからの「過剰な」リクエストが - 変更した IP アドレスごとに「過剰」 - 頻繁に変更した IP アドレスからのリクエストの "合計が" 「過剰」 と考えた時に後者だったら IP アドレスごとのレートが閾値を超えないので効果が低いのでは、ということですね。 逆に前者の場合であれば適切と言えるという認識をお持ちだという理解で間違いないでしょうか?
2024/09/29 返信
なぜレートベースが正解なのか

攻撃元が異なるアドレスに切り替わったとしても、そのアドレスからの「過剰な」リクエストレートを判断基準にしているので特に問題ないと思うのですが…
もしよければ ksjym2 さんが「適切」と思われるこの問題の他の選択肢とその理由をお聞かせいただけないでしょうか?

2024/09/24 返信
なぜ宛先MACアドレスは「5555.5555.5555」ではないのか

宛先はSwitchBの「5555.5555.5555」だと考えたのですが

SwitchB の 5555.5555.5555 は「SwitchBそのもの」宛という意味になってしまうので違うんですね。SwitchB の向こうにいる RouterB に渡したいので、 6666.6666.6666 じゃないといけないのです。

なぜこのMACアドレスは「3」の位置ではなく、「4」の位置で使われるべきなのでしょうか。

ここはちょっと意図が読み取れなかったので、補足いただけるとありがたいです。

2024/09/23 返信
RB、RCはクラスフルネットワークの境界なのか

CCNAの問題ID: 6865の参考にも記載があります。抜粋すると

クラスBは第2オクテット(16ビット)までがネットワーク部なので「/16」となります。

です。

なので、128.0.0.0-191.255.255.255は

  • 128.0.0.0/16
  • 128.1.0.0/16
  • 128.2.0.0/16

のように、 /16 ごとがクラスフルの範囲です。クラスBのアドレス範囲だけではなく、ネットワーク部のサイズまで意識する必要があります。

2024/09/18 返信
問題文について

確かに。「または」ではなく「および」とかならわかります。

また、file.txtの中身が問題文に無い、行頭や行末の指定もないです。

ここはまぁそういうものです。どのような内容であったとしても設問の条件に合う行が抽出できる検索文字列を問われているので、 file.txt がどのような内容であったとしても設問の条件を満たすものを選べば良いので。

この問題はcatとcatsどちらも含むものを正解としていると認識しておりますが、いかがでしょうか?

ここは同じ認識です。

2024/09/18 返信
問題の改善

うーん…そもそも設問が

下図のSwitchに「switchport trunk allowed vlan add 110」を設定したときの動作について

なのですから、「設定が反映されたところまで」が表示されてたらそれはすでに問題として意味がないのではないでしょうか?「この状態にこの設定を入れたらどうなる?」という問題を「この状態のスイッチの動作として正しいものは?」に変えるべきということであれば、どの段階の図を表示するかではなく問題自体を変更するようにというお話になりますよね。
この問題と回答、解説に誤りがあるわけではないのであれば、問題の形式を変える必要性はないのではないかなぁと思います。

2024/09/14 返信
マルチAZ配置ではないAuroraでリードレプリカを使用

誤答解説のこの部分ですか?

シングルAZ構成では高可用性やフェイルオーバーを実現できませんので、誤りです。

確かに「フェイルオーバー」はシングルAZ構成でもできますが、当該AZ障害の場合はフェイルオーバーする先ごとなくなるので「高い可用性を確保」しているとは言えないから、ということなのかなぁと思います。そういう意味では記述が明確ではないかなぁって気がしますね (^^;

2024/09/08 返信
interface FastEthernet0/1のネットワークアドレスについて

192.168.20.18のホスト部は第4オクテットの.18を2進数表記したときの00001011の「1011」

ここが間違いですね。18を2進数表記したら 0001 0010(16+2) になります。 1011 だと「11(8+2+1)」です。

2024/09/07 返信
リンクローカルアドレス生成の過程

経緯や何かはこちらが参考になるかなと思います。

Geekなページ:IPv6アドレスにおける「インターフェース識別子」という名称の謎とModified EUI-64によるIPv6アドレス生成
https://www.geekpage.jp/blog/?id=2020-7-21-1

EUI-64では、グローバルに一意な値である場合にはuniversal/localビットが0なので、 64ビットのうち、最下位ビットのみが1となるような値(注:インターフェース識別子部分が「::1」となるようなアドレスのこと)は、グローバルに一意という意味があることになってしまいます。

たとえば、2001:db8::1というユニキャストIPv6アドレスを手動で設定したとき、Modified EUI-64ではなく、通常のEUI-64を採用していた場合、 インターフェース識別子に含まれるuビットが0 となるので、 64ビットのうち最下位ビットのみが1というインターフェース識別子がグローバルに一意であるものを示すことになってしまう わけです。

しかし、 手動設定での2001:db8::1というユニキャストIPv6アドレスの下位64ビットは世界で一意となるようなユニークな値ではありません。 こういう設定を行いたい人が多そうなので、 Modified EUI-64では、uビットが0の場合はlocalで、1の場合がuniversalという風に、意味を反転させたのです。

2024/09/01 コメント
ACL、バケットポリシーの解説について
引用された解説の記述は「顧客に向けて S3 の機能を説明している」のではなく、学習のために当該選択肢が正答とならない理由を書いてあるだけですので、パブリックアクセスの記載の有無がないことの何が問題なのか、yamamotok6さんがどのような修正を求めているのかを理解しきれずにいます。 ただ、残念ながら認識の齟齬がないようにという意図でのお願いについては斟酌いただけず、こちらの見解についても「頓知のような不毛な議論」と一蹴されてしまっておりますので、建設的な会話が進まないと判断いたしました。 疑問を解決する一助となることができず申し訳ありません。本件会話にお時間をいただきありがとうございました。
2024/08/31 コメント
ACL、バケットポリシーの解説について
> Sier としての立場でいうと「仕様を正しく理解することは非常に重要」と思います。つまり設定できるか・できないかを正しく把握する必要があるということです。紛らわしい誤解を招くような案内は NG です。私はこの解説を初めて読んだ際、パブリックアクセスは不可能と理解しました。後になって可能であることが分かりました。Sier として仕事をしている方は要注意ですね。 ここが不思議なのですが、「仕様を正しく理解する」ことと「書いていないから利用できないと判断した(私はこの解説を初めて読んだ際、パブリックアクセスは不可能と理解しました。)」ことは別ではないですか? バケットやオブジェクトにパブリックアクセス「できない」とはっきりと記載があるのであればそのように理解されるのは納得できるのですが、できるともできないとも書かれていないものを「パブリックアクセスは不可能と理解」したのは記述の問題ではなく「記載がないのなら使えないのだ」と判断されたから、ではないでしょうか?「可否の記載がないので一次情報を確認した上で、設定可能であることを確認した」場合と「記述にないから使えないものと理解していたのに、後になって可能であることを知った」では少し話が違うように感じました。 また、少なくとも誤答解説という観点ではパブリックアクセスができるかどうか以前に誤答である理由を明確にすれば良いだけなので、関係ない情報を記載しないことで学習者に学習してほしいポイントを明確にする(「非公開設定されたAmazon S3のデータ」と条件がある以上パブリックアクセスについて言及する必要はない)というだけのことかと思います。 「ここがこういう表現なのは誤解を招くので、具体的にはこう記述すべきではないか」という具体的ポイントが示されないまま ・記載内容として正確性に欠ける ・パブリックアクセスが不可であるような内容となっている ・紛らわしい誤解を招くような案内 とだけ書かれていても想像だけで会話することになりかねないと思っています。 Sier としての立場とのことですので要件定義や設計書レビューの経験がおありだという認識でいますので、どの記述の問題点をどのように修正すべきとお考えなのかを記述修正例と合わせてご提示いただけると建設的な会話になるかと思いますので、ご検討いただけると幸いです。
2024/08/29 コメント
ACL、バケットポリシーの解説について
> 解説の内容として「ACL、バケットポリシー」はパブリックアクセスが不可であるような内容となっていること 間違ってたらすみません。「〜がアクセス権限設定の対象なので、」という表現が「パブリックアクセス設定ができるのにそこに言及していない」という意図であっていますか? もしそうであればやはり前述の通り、ここは「設問の条件」を満たさない(=当該選択肢が誤答である)理由を記述している部分ですので、パブリックアクセスが可能であることを明記する必要性がないということだと思います。 また、参考について明確に「パブリックアクセスの設定ができる」と書いていないのは「パブリックアクセスが非推奨であること」も理由かなと思います。 提示されたリンク1つ目には ーーー 警告 すべてのユーザー (パブリックアクセス)または認証されたユーザーグループ (すべての AWS 認証ユーザー) のグループへの書き込みアクセスを許可しないことを強くお勧めします。 ーーー の記述、2つ目には ーーー 種類にかかわらず、S3 バケットへの匿名書き込みアクセスは一切付与しないことを強くお勧めします。 ーーー と、「パブリックアクセスを使用する」ことを強く否定しているので、ベストプラクティス的にも言及していないだけかなと思います。 そもそも「パブリックアクセスのブロック」というドキュメントもあるぐらいですし。 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/access-control-block-public-access.html 上記を踏まえても「できることをできると書いていない(書いてないだけであって「できない」とは書いていないので不正確かどうかの判断は私にはできません)」ことと「この設問の正解を導くにあたって必要な情報か否か(正答を導くには条件の考慮と十分な判断材料があれば良い)」はやはり別なので、書いていないからと言って「不正確であるため訂正が必要」であり「設問の条件は関係ありません」ということにはならないのではないかなと思います。
2024/08/28 返信
ufw default ⇒ ufw reset 動作

①ポリシーのデフォルト値そのものを変えてしまう

ですね。 iptables でいう、 -P オプションのことです。

①の場合、ufw resetは、ufw defaultで変える前の標準のデフォルトに戻るのではなく、
①で変えた後のデフォルトに戻ることになりますか?

その通りです。実機でやるとそのようになりますね。

$ sudo ufw status verbose
Status: inactive   ←初期状態はinactive(ufwが動作していない)
$ sudo ufw --force enable
Firewall is active and enabled on system startup
$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)   ←incoming:deny, outgoing allow になっている
New profiles: skip
$ sudo ufw default allow incoming   ←incoming:allowにdefaultポリシーを変更
Default incoming policy changed to 'allow'
(be sure to update your rules accordingly)
$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: allow (incoming), allow (outgoing), disabled (routed)   ←incoming:allowになっている
New profiles: skip
$ sudo ufw --force reset
Backing up 'user.rules' to '/etc/ufw/user.rules.20240828_140215'
Backing up 'before.rules' to '/etc/ufw/before.rules.20240828_140215'
Backing up 'after.rules' to '/etc/ufw/after.rules.20240828_140215'
Backing up 'user6.rules' to '/etc/ufw/user6.rules.20240828_140215'
Backing up 'before6.rules' to '/etc/ufw/before6.rules.20240828_140215'
Backing up 'after6.rules' to '/etc/ufw/after6.rules.20240828_140215'

$ sudo ufw status verbose
Status: inactive
$ sudo ufw --force enable
Firewall is active and enabled on system startup
$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: allow (incoming), allow (outgoing), disabled (routed)   ←reset後もdefaultで設定した incoming:allow は変わっていない
New profiles: skip
戻る