tiskwさんの助け合いフォーラム投稿一覧
CA が自分の秘密鍵で実際に計算した 署名データそのものではないですか？
CAが証明書に署名する際に用いるアルゴリズムはsignatureAlgorithmではないのですか？
tbsCertificate の signature は「署名データそのもの」ではありません.
署名データそのものは signatureValue フィールドに格納されています
signatureAlgorithm と signature は, いずれも証明書に署名するために用いられるアルゴリズム（の識別子）を示すフィールドです.
両者は同じアルゴリズムを含まなくてはいけません
https://tex2e.github.io/rfc-translater/html/rfc5280.html#4-1-2-3--Signature
このフィールドには、シーケンス証明書(セクション4.1.1.2)のsignatureAlgorithmフィールドと同じアルゴリズム識別子を含める必要があります。
つまり, tbsCertificate（署名対象のデータ）の内部（signature）に署名アルゴリズムが記録され,
証明書全体の signatureAlgorithm にも同じアルゴリズムが記録され,
そのアルゴリズムで CA が生成した署名が signatureValue に格納される という構造です.
#アルゴリズムが2つある点については,改ざん検出用とか構造的な理由などかもしれませんが理由や背景まではわかりません
こちらの方がもう少しわかりやすいかもしれません.
https://www.trustss.co.jp/smnDataFormat410.html#Signature
同意見です
ここは生体認証だのと組み合わせたときの複数の段階を踏ませることによるセキュリティ向上について述べているだけでしょうね
BIOSパスワードの脆弱性がなくなったり軽減されるわけではないはずです
ただ，生体認証が組み込まれた機種ではTPMチップが搭載されてるケースもあって
ハードウェアそのもののセキュリティが強化されてることもあるので結果的にはBIOSパスワードの実効性が高まる可能性はありますね
まぁとはいえ試験とは関係のない部分であると思います
xはアーカイブを展開するオプションですが
hoge.tarを指定するために必要なオプションfの指定がないためエラーになります
$ tar x hoge.tar
tar: Refusing to read archive contents from terminal (missing -f option?)
tar: Error is not recoverable: exiting now
$ ls
hoge.tar
hoge.tarなど明示的にファイルを指定する場合はfの指定が必須です
$ tar xf hoge.tar
$ ls
a b c hoge.tar
公式の書式に則った記述のようです
https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslstaplingcache
Syntax: SSLStaplingCache type
typeに指定できるのはSSLSessionCacheと同じとのことですから, 以下も参考になるかと
https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslsessioncache
指定可能なtypeとしては下記のパターンと思います. sizeはオプションですね.
dbm:/path/to/datafile
shmcb:/path/to/datafile[(size)]
dc:UNIX:/path/to/socket
cipher は暗号化アルゴリズムの設定です
暗号化という観点では使用するかもわかりませんが cipher を設定しても
SSL/TLS が有効になるわけではありませんのでここでは不正解でよいかと思います
SSL/TLSを使う場合は ca,cert,key についてサーバ, クライアントともに各々の証明書や秘密鍵の設定が必須です
サンプルの server.conf, client.conf にも説明がありますのでセットで考えておくのが良いかと思います.
https://www.openvpn.jp/document/how-to
sample-config-files/server.conf
＃ SSL/TLS root certificate (ca), certificate
＃ (cert), and private key (key). Each client
＃ and the server must have their own cert and
＃ key file. The server and all clients will
＃ use the same ca file.
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
sample-config-files/client.conf
＃ SSL/TLS parms.
＃ See the server config file for more
＃ description. It's best to use
＃ a separate .crt/.key file pair
＃ for each client. A single ca
＃ file can be used for all clients.
ca ca.crt
cert client.crt
key client.key
-smpオプションは仮想マシンに仮想CPUを割り当てるオプションのようですが, 違うのでしょうか.
https://wiki.gentoo.org/wiki/QEMU/Options#Processor
-smp - Specify the number of cores the guest is permitted to use. The number can be higher than the available cores on the host system. Use -smp $(nproc) to use all currently available cores.
https://manual.geeko.jp/ja/cha.qemu.running.html#cha.qemu.running.gen_opts.basic
-smp CPU_数
仮想化環境での CPU 数を指定します。 PC プラットフォームの場合、 QEMU では最大で 255 個まで (KVM のアクセラレーション機能を使用 した場合は 64 個まで) の CPU に対応します。このオプションは、 ソケット の数や コア の数、およびコアごとの スレッド 数など、 その他の CPU 関連パラメータも受け付けます。
https://gihyo.jp/admin/serial/01/ubuntu-recipe/0592
-smp 2：CPUの数を2にしています。いくつでもかまいません。
SUAの後継機能としては WSL（Windows Subsystem for Linux）が該当するかと思います、
https://ascii.jp/elem/000/004/211/4211103/
https://atmarkit.itmedia.co.jp/ait/articles/2210/05/news006.html
この設問で問われているADとLDAPの連携については、最新の試験でどう問われるかはわかりませんが
軽く調べてみると、現在では特別なパッケージを必要とせずADドメインサービスに内包されているようにも見えます。
https://qiita.com/yes_dog/items/188b141f596400786137
https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server
一方で-Sオプションの説明には「デフォルト」は使われていないと思います。
デフォルトというのは、Windowsサーバ上でしか変更ができないWindowsサーバの静的なクォータ設定であって、
これは外部のSamba(Linux)サーバから書き換えることはできないが、-Fで見ることはできる。
デフォルト値は変更可能です。smbcquotas -S で変更できます。
https://www.samba.gr.jp/project/translation/4.1/htmldocs/manpages/smbcquotas.1.html
-> QUOTA_SET_COMMAND
共有のデフォルトの Quota 制限を設定する :
FSQLIM:/
-u で指定されたユーザーかカレントユーザー特有の Quota 制限を設定する :
UQLIM::/
実機が手元にないので検証できませんが デフォルト値は ulimit と同等の考え方です
新たに作成したユーザに対して適用されるsoftlimit/hardlimitが-Fで表示されるデフォルト値です
-Sオプションでデフォルト値の変更も可能ですし、ユーザ単位に上限を変更することもできます
この問題のACLなら、「* auth」としたところで実質的な動作としては要求者（who）はanonymousになるはずです。
誤りの選択肢の解説がピンと来ないのは同意です。
ここで* authが誤りの理由については、より適した選択肢があるのと、
以下マニュアルにあるように推奨される記述ではないというのが適切でしょう。
https://www5f.biglobe.ne.jp/~inachi/openldap/admin23/slapdconfig-ja.html#%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E6%A8%A9%E3%82%92%E4%B8%8E%E3%81%88%E3%82%8B%E5%AF%BE%E8%B1%A1%E3%81%AE%E6%8C%87%E5%AE%9A
access to * by self write by anonymous auth by * readこのディレクティブの利用例は、認証ユーザが自分のエントリを更新できるようにし、匿名ユーザが認証を行えるようにし、その他すべてのユーザが読み取れる(read)ようにします。一致する最初の by 節だけが適用することに注意してください。したがって、匿名(anonymous)ユーザには認証権(auth)が与えられ、読取り権(read)は与えられません。最後の節は "by users read" としたほうがよいでしょう。
スパム対策は、Postfixならmynetworksやrelay_domainのほかに
smtpd_{recipient|client}_restrictionsなどを使うと送信者/受信者を制限することができたはずです
（このあたりまでは試験には出なかったはずだと記憶していますが）
Postfixに関しては以下のサイトが参考になるかと
https://www.criterion.sc/sub_notes/Postfix_Security.html
２－２．SPAM用踏み台サーバーとならないための対策
また、外部・内部についてはネットワークの外部（インターネット）・内部（社内ネットワークなど）で合っているはずです。
基本的に攻撃者は外部のネットワークから攻撃してくるものですから
メールサーバーでは内部ネットワークからの接続と外部ネットワークからの接続を区別して扱うように設定するはずです。
試験に関しては試験の発行元に尋ねた方がいいかと思いますが
疑問点は以下のページで解決しないでしょうか
https://linuc.org/policies/recert.html
Q. レベル3の300、303、304の認定を取得済みなのですが、有意性の期限を延長するにはどうすれば良いですか？
2行目と3行目はアクセス制限している目的が異なるので、どちらも必要かと思われます。
2行目はポートの制限で、この行がないとFTP（21）やSSH（22）を使ったアクセスを弾けません
3行目はCONNECTメソッドの場合はSSLだけを許可しているので、トンネリングしない通信への言及はありません
例えば、2行目との複合で、HTTP(ポート80)で GETしようとするのは許可されるはずです。
①、②どちらも無線LAN pubcafe に接続するのコマンドで、①が事前準備とかではないはずです。
この問題は、無線LAN接続する際のiwconfigとiwコマンドの違いを学習するためのものと認識してます。
以下、iwconfigで接続している例が載ってます。
https://atmarkit.itmedia.co.jp/ait/articles/1506/17/news024.html
下記は、wlan0の無線LANインターフェースから、ESSID「Atmark2」に接続する場合の実行例です。
iwconfig wlan0 essid "Atmark2" key "s:password"
暗号化ありの実行例ですが、暗号化なしであれば key ～ がいらない
アクセスポイントへの接続
暗号化なし
iw dev interface connect "your_essid"