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

助け合いフォーラムの投稿
2024/10/21 コメント
PrivateLinkでのS3接続可否について
birdpixy様 回答頂き、有難うございます。 PrivateLinkも使用できることが理解できました。
2024/10/19 投稿
PrivateLinkでのS3接続可否について

この問題の誤りの選択肢
「EC2インスタンスのあるVPCに、PrivateLinkを作成する。エンドポイントへのルーティングをルートテーブルに設定し、S3バケットへアクセスする」に対して、解説では、「PrivateLink(インターフェース型VPCエンドポイント)でも、EC2インスタンスからプライベートネットワーク経由でS3バケットへアクセスできますが、利用料金が発生します。」とされています。

一方、AI Assistantで確認したところでは、S3への接続にPrivateLinkは使用できないので
ゲートウェイ型のVPCエンドポイントの利用が必須であるとの情報が返ってきました。

AI Assistantの情報が誤りの可能性は十分にあると思うのですが、上記の解説の方が正しいか否かに
ついて、ご存じの方は、おられますでしょうか。
もしおられたら、教えて下さい。

また、もし、解説が誤っている場合には、記載内容を修正して頂けますと、有難いです。

宜しくお願いします。

2024/10/14 返信
VPCのデフォルトのセキュリティグループのルールについて

ご質問の「デフォルトだとアウトバンドは許可」は
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/security-group-rules.html
によると、セキュリティグループを作成するときに、その様な設定が最初から入っているだけで、インバウンド、アウトバウンドともに、許可のみ設定でき、設定していない通信は拒否になる様です。

(上記urlから引用)
セキュリティグループを最初に作成するとき、リソースからのすべてのアウトバウンドトラフィックを許可するアウトバウンドルールが設定されます。ルールを削除し、任意の発信トラフィックのみを許可するアウトバウンドルールを追加できます。セキュリティグループにアウトバウンドルールがない場合、アウトバウンドトラフィックは許可されません。

上記から、ご質問にある
「インスタンスから意図しない通信が開始してしまった場合、デフォルトだとアウトバンドは許可されているので、それがインターネット宛に出ていってしまいます。」
への対処はセキュリティグループの機能で可能で、「アウトバウンドルールを全て削除」もしくは「ルールを削除し、任意の発信トラフィックのみを許可するアウトバウンドルールを追加」で対処できるかと思います。

2024/10/12 投稿
インターネットからの戻り方向の通信用のルートテーブル設定について

この問題の解説にある図はマスク長は記載されておりませんが、仮に
以下として、質問させてください。
パブリックサブネット 172.16.0.0/24
ファイアウォールサブネット 172.16.1.0/24
プライベートサブネット 172.16.2.0/24
VPCのアドレス 172.16.0.0/16

図では下から上への通信が矢印で描かれていますが、その逆の
上から下への通信について、質問させてください。

他の問題のVPCの解説などの例では、パブリックサブネットのルートテーブルの例として
以下とされるていることが多いと思います。
送信先 ターゲット
0.0.0.0/0 インターネットGWのid
172.16.0.0/16 local

しかし、この問題の構成で、パブリックサブネットのルートテーブルが
上記の場合、インターネットからパブリックサブネットからプライベートサブネットのEC2に
通信が流れ、戻りの通信がNetWork Firewallを経由しない様に思われました。

このため、この問題の例でのパブリックサブネットのルートテーブルは
以下の様に、★の行が追加された状態(利用者が★を設定しておかないといけない状態)
と推測したのですが、正しいでしょうか。
送信先 ターゲット
0.0.0.0/0 インターネットGWのid
★172.16.2.0/24 ファイアウォールエンドポイントのid
172.16.0.0/16 local

AI Assistantで確認したところでは、★がなくとも、VPCが自動的に制御するので
★の設定はいらないと言っている様な、言っていない様な微妙な情報までしか得られなかった
ため、ここで、質問させて頂いております。

ご存じの方がおられましたら、教えて下さい。
宜しくお願いします。

2024/09/11 コメント
auto scalingと問題の解答との関係について
lucie9n様 ご回答、有難うございます。 おかげさまで理解できました。
2024/09/09 投稿
auto scalingと問題の解答との関係について

この問題の問題文「Auto Scalingグループで実行されており、常時6台のインスタンスの稼働が求められている」は
auto scalingで、最小キャパシティ 6台、最大キャパシティ 6台と設定すればよい様に思えたのですが
解答からしますと、そうではないということになりますでしょうか。
私は
「auto scalingで、最小キャパシティ 6台、最大キャパシティ 6台」とすると、ひとつのAZが障害と
なった場合に、6台から不足した数のインスタンスを自動で、他のAZで起動できると思っておりました。
その様に考えた場合、正解は
「AZ-a内にインスタンスを2台、AZ-b内にインスタンスを2台、AZ-c内にインスタンスを2台」
になると思ったのですが、誤りの様なので、auto scalingの理解が誤っているとは思うのですが
どの様に誤っているかがわからないでおります。

上記の疑問点について、ご存じの方がおられましたら、教えて下さい。
宜しくお願いいたします。

2024/04/03 コメント
ebtablesのfilter/ACCEPTとbroute/ACCEPTの違いの有無について
質問を理解する能力がない場合に、無理にコメントするのは避けたほうがよい と思います。(立場上、やむを得ないのだとは思いますが) また、「自分がボランティアである」といった嘘はつかないほうがよいと思います。
2024/04/02 コメント
ebtablesのfilter/ACCEPTとbroute/ACCEPTの違いの有無について
iptablesは質問とは関係がなく、ebtablesにおいて ・テーブルbroute + チェインBROUTING + ターゲットACCEPT ・テーブルfilter + チェインFORWARD + ターゲットACCEPT の2つの設定は全く同じ動作で、条件に合致するethernetフレームを ブリッジングする様に思われたのだが、正しいのであろうかというのが 質問内容です。
2024/03/30 投稿
ebtablesのfilter/ACCEPTとbroute/ACCEPTの違いの有無について

この問題の解説で、ebtablesの解説として以下の記載があります。
・テーブルbroute + チェインBROUTING + ターゲットACCEPT:ブリッジ処理を行う

そのすぐ上に記載されている
「ebtablesにおけるテーブルは以下の3種があり、使用可能なチェインが決められています。」
の表の内容をみると、上記は
・テーブルfilter + チェインFORWARD + ターゲットACCEPT
と同じ動作の様に思えたのですが、その様な理解で正しいでしょうか。

もし、なんらかの相違がある場合には、相違の内容を教えて頂けると有難いです。

ご存じのかたがおられたら教えて下さい。
宜しくお願いします。

2024/03/25 コメント
chrootでのマウントとハードリンクの相違について
ojixii様 ご回答、有難うございます。おかげさまで理解できました。
2024/03/21 投稿
chrootでのマウントとハードリンクの相違について

この問題の解説の最後に、以下の情報があります。
①ハードリンクは使用できますが、攻撃者がリンクを辿れてしまうなど
chroot環境の外へ影響を及ぼすため推奨されません。
②デバイスファイルやprocfsを利用したい場合は、通常はホストマシン
の当該ディレクトリをchroot後の環境にマウントします。

上記①で例としてあがっている「攻撃者がリンクを辿れてしまう」は
マウントでも同じと感じるのですが、正しいでしょうか。

もし、上記が正しい場合、マウントの方が望ましいのは、どの様な
理由でしょうか。

ご存じの方がおられたら、教えて下さい。
宜しくお願いします。

2024/03/12 コメント
「BIOSパスワードが物理的に移動や分解が困難なサーバの場合に有効」の意味
ojixii様 ご回答、有難うございます。大変参考になりました。
2024/03/09 投稿
「BIOSパスワードが物理的に移動や分解が困難なサーバの場合に有効」の意味

この問題の解説にある
「ただし、BIOSのパスワードはCMOSクリア(BIOS初期化)で消去できてしまうので、物理的な紛失・盗難等の場合は役に立ちません。一方で、物理的に移動や分解が困難なサーバの場合などには有効性があるでしょう。」
は、「そのサーバが設置された場所ではCMOSクリアの操作ができない」と仮定されているから
であって、仮に、サーバの設置場所で攻撃者がCMOSクリア操作を行えるとすれば、「物理的な紛失・盗難」
と同じで、「BIOSパスワードは役に立たない」になるという理解であっていますでしょうか?
(もしかすると、他の意味もあるかもしれないと思い、質問させて頂いております。)

ご存じの方がおられたら、教えて下さい。
宜しくお願いします。

2024/03/09 投稿
コマ問「KSKで署名されるリソースレコードDNSKEYが公開鍵情報を持つ鍵は?」の解答が不正確ではないでしょうか。

コマ問「KSKで署名されるリソースレコードDNSKEYが公開鍵情報を持つ鍵は?」
の解答が「ZSK」とされていますが、正確には
「ZSK および KSK(KSKも該当する)」
ではないでしょうか?

上記理解が正しければ、コマ問の修正をお願いいたします。
宜しくお願いします。

2024/03/02 コメント
rkhunterの実行時の権限について
dandyleopon様 ご回答、有難うございます。大変参考になりました。
2024/02/29 コメント
rkhunterの実行時の権限について
dandyleopon様 ご回答、有難うございます。 私の環境(Rocky Linux release 8.8)では、一般ユーザで 実行しようとすると、以下で実行できませんでした。 $ rkhunter --check You must be the root user to run this program. rootの場合は、以下で実行できました。 # rkhunter --check [ Rootkit Hunter version 1.4.6 ] Checking system commands... Performing 'strings' command checks Checking 'strings' command [ OK ] --- 省略 --- 私の環境でのインストール先は、dandyleopon様と同じく /usr/bin/rkhunter でした。 もし、dandyleopon様の環境で rkhunterを一般ユーザで実行するために、なんらかの rootと異なる操作が必要だったという様なことがあれば 教えて下さい。 宜しくお願いします。
2024/02/29 コメント
Auditルールの設定順序について
ご回答、有難うございます。おかげさまで、理解できました。
2024/02/25 投稿
rkhunterの実行時の権限について

この問題の参考情報で、「実行するにはroot権限が必要」の情報が
chkrootkitにだけ記載されており、rkhunterには記載されていません。

私は、rkhunterでも「実行するにはroot権限が必要」と思っているのですが
rkhunterは参考情報などにたまたま書いていないだけで、権限に関しては
chkrootkitと同じくrkhunterもroot権限が必要との理解で正しいでしょうか。
(参考情報の書き方から、rkhunterは、必ずしもそうではないという意図が
ある様にも見えるので、質問しております。)

ご存じの方がおられたら、教えて下さい。
宜しくお願いします。

2024/02/25 投稿
Auditルールの設定順序について

この問題の内容とコマンドラインの記載は、以下です。
Auditにおいて、「open」「close」を除くすべてのシステムコールの監視を行う。
①auditctl -a always,exit -S all
②auditctl -a never,exit -S open,close

①の方が上に記載されているため、上から順番に実行すると、open,closeも
①に合致するので、監査ログが記録されそうに思われます。

上記の記載順序で、「open」「close」が除かれるとすると、その理由は
設定順序に関わらず、alwaysよりもneverが優先されるからでしょうか。

上記設定順序で②が優先される理由について、ご存じの方がおられたら
教えて下さい。
宜しくお願いします。

2024/02/13 コメント
SSL/TLSを使用しない場合のセキュリティリスクとして「データの破壊」は誤りではないでしょうか?
ご回答、有難うございます。大変参考になりました。 宜しくお願いします。
2024/02/13 コメント
「PEM形式の証明書はテキスト形式であるため可読性がある」の可読性の意味について
ご回答、有難うございます。参考になりました。 DERとそれをBASE64エンコードしたもの(PEM)を比較した場合に 機械可読性が上がっているかというと、なんともいえない気がいたしましたが 試験でこの用語がでましたら、EVa0082様、ojixii様にご指摘頂いた 多面的な意味を検討して解答する様にしたいと思います。 宜しくお願いします。
2024/02/10 投稿
SSL/TLSを使用しない場合のセキュリティリスクとして「データの破壊」は誤りではないでしょうか?

SSL/TLSを使用している場合でも、データを破壊することは可能かと思います。
このため、この問題で「データの破壊」の選択肢を正解とするのは誤りではないでしょうか?

ご存じの方がおられたら教えて下さい。
宜しくお願いします。

2024/02/09 コメント
「PEM形式の証明書はテキスト形式であるため可読性がある」の可読性の意味について
ご回答、有難うございます。 ご指摘頂いたページの記載は私も目にしていたのですが PEM 形式の X.509 証明書が用いられる理由は (base64でエンコードされていることから) htmlページやメールなどで、テキスト形式で証明書を受け渡す ことができるからであり、これが「人と共有しやすい」ことの理由で これには「可読性の高さ」は関係がありません。このため 「理由のほとんどが可読性の高さと考えられます」は誤解と思っておりました。 バイナリファイルが「可読性がない」とすると、それをbase64エンコードした ものも「可読性がない」とした方が自然な気がするのですが、どうでしょうか。
2024/02/07 投稿
「PEM形式の証明書はテキスト形式であるため可読性がある」の可読性の意味について

この問題の解説にPEM形式の証明書は「DERをBase64でテキスト化したもの」とされて
おりますので、PEMは形式的にはテキストファイルではあっても、人間が読んで意味を
理解できる性質としてはDERのバイナリファイルと同じだと思います。

この問題の「可読性」が「人間が読んで意味を理解できる性質」だとすると
「PEM形式の証明書はテキスト形式であるため可読性がある」は誤りであり
この選択肢を正解とするのは、問題作成の誤りではないでしょうか?

あるいは、この選択肢を正解とするのが正しいとした場合、「可読性」とは
どの様な意味で使用されていますでしょうか?

ご存じの方がおられましたら、教えて下さい。
宜しくお願いします。

2024/01/27 返信
「443ポートを使った通信は、どのクライアントでもアクセスできる」が不正解の理由について

ping-t運営者様へのお願いです。

【LinuC Lv2-202(Ver10.0) 問題ID : 22831
「443ポートを使った通信は、どのクライアントでもアクセスできる」が不正解な件について】
で、全く同じ質問をされている方がいることに気がつきました。
そこでは、http_access allow eigyobiは、「平日9:00-18:00の間であれば」という
条件がつくために、「どのクライアントでもアクセスできる」の条件に該当しないのではないか
と推測されておりましたが、現状のこの問題、解説の文章の内容からは無理がある推測の様に感じます。

現在の解説部分の情報からは
「443ポートを使った通信は、どのクライアントでもアクセスできる」がなぜ不正解であるのかは
わからない状態だと思いますので、もし、「平日9:00-18:00の間であれば」という
条件があることが不正解とする理由であれば、その情報を解説の内容に付加する必要があるかと思います。
(もしくは、問題文を修正する必要があると思います。)

この指摘が妥当であれば、追加/修正をお願いいたします。

戻る