arashi1977さんの助け合いフォーラム投稿一覧
ここで質問なんですが、「全ベンダーのネットワーク機器で使用できる」が解答になる場合、それはRFC____(←例です)というように標準化されているということですか？
基本的にはそうですね。たとえばNetFlow v5, v8は仕様は公開されておらず、NetFlow v9がRFC 3954として公開されていますが、Informationalなので標準化されているとはいえないですね。
で、標準化されていると言い切れるのはIPFIX(RFC 7011-7015)なので、そうではないNetFlowは「全ベンダーの…」とはいえないかなと思います。
興味があればこちらとか見てみるのも良いかもしれません。
https://www.janog.gr.jp/meeting/janog36/application/files/1414/3693/6268/janog36-xFlow-tutorial-ikuta-01.pdf
前者は www.example.com は同じでその後に続く /web1/ と /web2/ のように「パス」が異なるので、そこを識別に使っているものです。
後者は www1.example.com と www2.example.com のように「ホスト」が異なるので、そこを識別に使っているものです。
パスの意味はこの辺見ると良いかと思います。「ホスト」はこのリンク先でいう「ドメイン名」の部分ですね。
https://developer.mozilla.org/ja/docs/Learn/Common_questions/Web_mechanics/What_is_a_URL#%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E3%83%91%E3%82%B9
正解をそのままにするなら、問題文のタイトルにある部分は「3文字以上の文字列」等になるのではないでしょうか？
「aから始まる3文字以上の文字列」に「aから始まるアルファベット3文字」は含まれないのでおかしい、ということでしょうか？
他の選択肢では
「a」から始まるアルファベット3文字以上の単語のある行
を抽出することはできず、また正答選択肢であれば設問の要件を満たしているようですが、問題点として指摘したいのはなんでしょうか？
質問の元は
SB Creative出版のAWS認定ソリューションアーキテクト[アソシエイト]によるとDAXは下記のメリットがあるようです。
デメリットの記載がなく、この記載のみを鵜呑みにした場合
ということですので、SB Creativeに質問すべき内容ではないかなと思います。
R1とR2の間でeBGPを有効化するような設定をしていないから（？）でしょうか？
ちょっと悩ましい表現ではありますが、
- R1-R2はすでにOSPFで経路情報をもらっているので、R1-R2間に別プロトコルを設定して受け取る必要がない
- R1-R3がeBGPで直接接続されるようになった（だけ。それ以外考える必要はない）
- R1はR3が知っているBGPプレフィックスをeBGPで受け取った（ら、偶然R2のネットワーク情報
192.168.3.0/24があった） - R1はR2とR3それぞれからもらった経路情報をどう扱うかを考えろ
という状況だと理解するのが妥当かなと。
解説の表にはないですが「現在の時刻を取得する」関数として current_time が存在するので、「日付と時刻」を取得する関数とは明確に異なるという話かなぁと思います。
https://www.postgresql.jp/document/14/html/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT
※そういえば、参考URLとか設問では「システム情報関数」ってなってますが、 current_timestamp とかは「日付/時刻関数」じゃないのかなぁとか思ったり。
日本語難しいね的な話かもしれませんが、設問の
プライベートサブネット上のEC2インスタンスに、インターネット経由でOSのアップデートを実行したい。
は、解説や正答選択肢からすると
- 「EC2インスタンスにて」または「EC2インスタンスから」
- 「インターネット経由でOSのアップデートを実行したい」→「OSのアップデートをインターネットから取得させたい」
の意図なのではないかなと思います。
矛盾しないですね。
たとえば有線LANの環境をイメージしてもらいたいのですが
- ツイストペアケーブル（UTP/STP）と光ファイバーは互換性がない（＝周波数帯が異なる場合は通信できない）
- ツイストペアケーブルを使用する規格（Ethernet, FastEthernet, GigabitEthernet）には互換性がある
- カテゴリ5以上のツイストペアケーブルを使用して接続する場合、両端の装置で 802.3u や 802.3ab といった規格が一致しなければならない（＝同じ規格で通信する必要がある）
- GigabitEthernetのスイッチにFastEthernetのNICを持つ装置を繋いでも通信できるのは、GigabitEthernet（802.3ab対応）のスイッチが下位の規格であるFastEthernet（802.3u）にも対応しているため
というだけの話です。
参考）
802.3についてはこちら https://e-words.jp/w/IEEE_802.3.html
装置が単体で複数の規格に対応している例（Catalyst 9200）はこちら https://www.cisco.com/c/ja_jp/products/collateral/switches/catalyst-9200-series-switches/nb-06-cat9200-ser-data-sheet-cte-en.html#%E7%AE%A1%E7%90%86%E6%A9%9F%E8%83%BD%E3%81%8A%E3%82%88%E3%81%B3%E6%A8%99%E6%BA%96%E8%A6%8F%E6%A0%BC%E3%81%AE%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88
問題演習中はできないようになっていたかと思います。別ウィンドウで開いても現在演習中のセッションに復帰するので、そのやり方も多分ダメですね。
試験同様に「最後までやる」しかないですが、これも試験の練習だと思えば… (^^;
トラフィックが一致しているとアクションが実行されないのであれば、denyエントリは何のために存在するのでしょう？
シーケンス10では「アクセスリスト100にマッチしたら破棄」となっているので、「アクセスリストにマッチしないものは破棄しない」ということです。なので、明示的に「シーケンス10の処理対象としない（破棄させたくない）トラフィック」をdenyしておくことで、処理対象から外す、というのが存在する理由ですかね。
別の仕組みの名前を使うと「ホワイトリスト」「ブラックリスト」をどう実装しているか、です。
ACL100は拒否する対象を定義している「ブラックリスト」のように見えますが、VLANアクセスマップの中では「ACL100にマッチしたら破棄」となっており挙動としては「permitされたものが破棄される」ので、その逆の「denyエントリにマッチするものは破棄対象とならない」ことが確実になることから「ホワイトリスト」を定義していると理解されると良いのではないかと
これがわかりやすいかもしれません、。
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-tcp_wrappers_and_xinetd
「図2.4 ネットワークサービスへのアクセス制御」にあるように、まずはTCP Wrapperで仕分けたのちに ”さらに” xinetdで管理するサービスごとの設定を確認して（２段階目の）アクセス制御を行うという感じですかね。
こっちのドキュメントにも書いてありますね。
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-tcp_wrappers_and_xinetd-xinetd
クライアントが xinetd が制御するネットワークサービスへの接続を試みると、スーパーサービスはリクエストを受け取り、TCP Wrappers アクセス制御ルールを確認します。
アクセスが許可されると、xinetd は、そのサービスの独自のアクセスルールで接続が許可されていることを確認します。
確かに設問の通りであればおかしいですね。
ネットワークIPアドレスが192.168.10.0、サブネットマスクが255.255.128.0のとき、IPアドレスをCIDRで表記したもの
192.168.10.0をネットワークアドレスとする255.255.128.0なサブネットって存在しないですもんね。/25（255.255.255.128）ならあり得ますが。
単に「ネットワークIPアドレス」が「IPアドレス」の誤記かもしれませんが、その辺はPing-tさんの確認待ちですかね。
もう終わってるっぽいですが。
SSH接続できる環境でやってみましたが、 usermod -L するとまずそもそもログインできませんでした。
$ ssh testuser@192.168.64.2
testuser@192.168.64.2's password:
Permission denied, please try again.
testuser@192.168.64.2's password:
Permission denied, please try again.
testuser@192.168.64.2's password:
testuser@192.168.64.2: Permission denied (publickey,password).
で、正解となっている usermod -s /bin/false だと、アカウントは生きているもののシェルが利用できないので対話的ログインできず、すぐに追い出されます。
$ ssh testuser@192.168.64.2
testuser@192.168.64.2's password:
Welcome to Ubuntu 23.10 (GNU/Linux 6.5.0-26-generic aarch64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/pro
This system has been minimized by removing packages and content that are
not required on a system that users do not log into.
To restore this content, you can run the 'unminimize' command.
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
Last login: Wed Apr 10 16:08:19 2024 from 192.168.64.1
Connection to 192.168.64.2 closed.
この設問で求められているのは「対話的ログインの禁止」であって「アカウントのロック」ではないのはすでに他の方も言及されている通りです。その上であえていうなら
アカウントがロックされたら対話的ログインもできなくなるから
正解だと思ったのですが、違うのでしょうか。
と疑問に思われている通り「求められていることを達成せず別の操作の副次的な影響で達成（したように）するのをよしとするのか」というところでしょうけど、たとえば「 systemctl stop sshd したらリモートから対話的ログインできなくなるからこれもOK」とか「 passwd hoge2 してパスワード勝手に変えたらログインできなくなるのだからこれもOK」とはならないですよね。
この問題では「最も適切なコマンド」を「2つ」選ぶようになっているので、まずは「求められているもの」を主に考えて、あとは試験テクニック的にも「回答数に合う【より適切な】選択肢を選ぶ」というのが優先かなと思います。その上で、求められているものを達成できるものが回答数に満たない場合は次善の選択肢を検討する、という順番がより良いかと思います。
参考の「プライベートアドレスは以下の範囲内で自由に割り当てることができます（RFC 1918で規定）」の下の表を見るとわかりますが、 172.17.33.55 はクラスBプライベートアドレスの範囲に含まれるからですね。
そうですね。設問は
次のログインに関する設定について正しい記述はどれか。
なので、SSHの設定のような「ログインに関する設定以外」は「省略」の範囲に含まれていると考えるのが妥当かと思います。
設問からは
同社はデータセンターの自然災害時の影響を考慮して、AWSを利用した災害復旧（DR：Disaster Recovery）を計画している。
のですから、仮にデータ同期やオンプレミスのシステム停止時切り替えのためにDirectConnectで接続していたとしても、そもそもデータセンターが自然災害により使用不可能な（DirectConnectエンドポイントが機能しない）状態を想定しているので
障害時にAWSに切り替えるには、通常はDirect Connectでつないでいるのが一般的な構成かと思います。
だと、「どこのエンドポイントからAWSのバックアップ環境にDirectConnect接続するの？」って観点が不足しているのではないかなと思います。