まとめICTSC2019の二次予選にご参加いただいた皆さん、本当にお疲れ様でした。本選に出場が決定した皆さま、おめでとうございます!本選でお会いすることを楽しみにしています。残念ながら本選出場ラインに到達できなかった皆さまはぜひ経験をバネとし、次回以降のICTSCにご応募いただければと思います。今回出題した全8問の問題文、及び問題解説を公開します。過去の問題を解いた上で学習し、ぜひ今後の研鑽にご利用いただければと思います。グループ」の4つを1番セキュアな組み合わせになるよう選択ください。Header」の略であり、認証機能を持っています。Payload」の略であり、ペイロード部に対して暗号化を行うことができます。危殆化している状態であると専門家の間では認識されおり、数分程度の探索でコリジョンが発見できるとの報告がなされている。等の記載からSHAの「G」が正答となります。ビット上の表より共有鍵が最長となる5の「J」が正答となります。Q2正しいMTUの計算を選択ください。」を使用しているものとします。1336上の表より1336byteの「c」が正答となります。Kernelのメインラインにマージされることが決定したものは以下のうちどれか。WireGuardです。OpenVPNは共に楕円曲線DHを用いて鍵交換を行いますが、Linuxのメインカーネルにマージされておらず、利用する場合にはカーネルモジュールに追加するなどの追加作業が必要となります。VXLANはL2ネットワークを延伸するためのプロトコルであり、DH鍵交換を行いません。Q44G/LTEパケット交換網において、ユーザプレーンとコントロールプレーンで利用されるトンネリングプロトコルの組み合わせとして正しいものは次のうちどれか。GTPv0-UとGTPv1-Cはそれぞれ3G時代に利用されていたユーザプレーンとコントロールプレーンのプロトコルであり、4G/LTE時代に利用されていたものとは別のプロトコルです。ユーザプレーンとコントロールプレーンそれぞれが正しく4G/LTE時代に利用されているDが正解となります。MySQLサーバを立てて、新しく運用を開始したらしい。そのサーバを利用するため、rootパスワードを教えて貰ったため、今までどおりのログインコマンドを試してみた。192.168.0.100だが、なぜかログインエラーが出てしまい先輩のサーバにアクセスできない。先輩はサーバ上で正しく動いているらしいので、トラブルシューティングのためにそのサーバへのアクセス権限をもらった。クライアントサーバから上記のコマンドを実行し、rootユーザがログインできるように変更を加え、下記の内容を報告してほしい。8系から導入された認証形式であるcaching_sha2_passwordが古いMySQLクライアントでは対応していないために発生しているエラーでした。クライアントサーバから実際にログインしてみようとコマンドを実行すると以下のようなエラーが出ていたかと思います。directoryこのエラーメッセージからなんらかの認証回りでエラーが起きており、回答に気づくシナリオでした。5.7.21のパッケージがインストールされていました。具体的な回答としては以下のものを想定していました。クライアント側のサーバにインストールされているMySQLクライアントのバージョンをcaching_sha2_passwordに対応したものをインストールする5.7系であれば5.7.23以上、8系であればどのバージョンでも対応していますrootユーザのログインに用いる認証形式を古い形式に変更するmysql_native_passwordに変更する事で古いMySQLクライアントでもログインすることが可能になりますちなみに、問題文の中で「先輩がMySQLサーバを立てて運用を開始した」という文面がありましたが、実際にMySQLサーバ側からmysqlコマンドを用いると特にエラーが出力されないままログインに成功します。8系のパッケージがインストールされており、MySQLクライアントも8系のものがインストールされているためcaching_sha2_passwordに対応しておりログインが可能であった、というシナリオでした。この問題を通して新しいMySQL認証プラグインであるcaching_sha2_passwordについて知っていただければ幸いです。sbtest3;を実行してsbtest3テーブルのデータを削除してしまいました、復旧をお願いします!!」と緊急の連絡を受けました。このクエリの実行後、すぐに間違いに気づいたデベロッパーはサービスをメンテナンス状態にし、アプリケーションサーバを停止したそうです。HH:MM:SSのフォーマットで報告してください。どのようにこの日時を特定したかを説明してください。sysbench.sbtest3;の結果を報告してください。データの復旧に必要な手順を説明してください。...を実行してしまったから、その直前の状態までデータ復旧してほしい!!」というデータベースの復旧問題でした。想像して楽しくなる状況ではありませんが、ソフトウェア開発をする上でデータベースのデータの復旧方法を知っておいても損はないと思います。そこで、MySQLを例にバックアップと更新ログを利用して任意のタイミングまでデータを復旧する問題を出題しました。DBMSごとの際はありますが、基本的にデータベースの復旧方法(特にロールフォーワードリカバリ)の概念は同じですので、今後使うDBMSでこういった状況に対応できるかを考えてみてください。具体的な解法を説明する前にMySQLにおけるリカバリ方法、バイナリログ、バックアップについて説明します。(PITR)データベースのバックアップを定期的に取得するだけでは、その時点のデータを復元することしかできないため、バックアップ以降の更新データを失うことになります。そこで、データの永続化を保証する多くのデータベースでは、バックアップとは別にデータの更新情報を保持しておき、バックアップとそれ以降のデータ更新を復元することで任意の時点のデータをリカバリできるようにしています。このようなリカバリ方法をポイントインタイムリカバリ(PITR)と言います。バックアップ以降のデータ更新情報をどのように保持するかはDBMSによって異なりますが、MySQLでは後述するバイナリログを利用することで取得できます。serverで実行された更新がイベントという形で出力されています。イベントには直接実行されたクエリが出力されているわけではなく、行ごとの変更分が特定のフォーマットにしたがって出力されています。この他にもバイナリログそのもののバージョンやサーバの設定などのメタ情報も含まれており、これを利用してリカバリやレプリケーションを行うことができます。...を含むDDLはSTATEMENTが直接書かれていたり、推奨されませんが、DMLを直接STATEMENTに出力したりも出来ます。-vvなどのオプションをつけることで、実際に実行されたSQL文とは異なりますが、SQL文として復元されたものを確認できます。クエリはコメントアウトされているので、このオプションをつけた結果をリカバリに使うことは出来ません。--start-position,--stop-positionを利用することをおすすめします。(秒間1クエリしか実行していない、なんてサービスはほとんどないはず)バックアップMySQLにおけるバックアップ方法はいくつもあり実際は要件に合わせて選択しますが、今回はMySQL標準の論理バックアップクライアントのmysqldumpを利用してバックアップしました。databaseの完全バックアップが取得されていました。MASTER...)がコメントアウトされて出力されます。この出力を見ることで、バックアップ以降の更新がバイナリログのどこから始まっているかをバイナリログのオフセットとして確認できます。復旧手順それでは実際に今回の問題環境でPITRを実施してデータを復旧する方法を説明します。sbtest3;の実行直前までの更新をバイナリログから抽出して適用することで復旧します。mysqldumpによるダンプファイルの22行目に以下の出力があることからバックアップ以降の更新はbinlog.000018の34626719byte目以降ということがわかります。table...を実行を表すイベントのオフセットを取得します。問題環境ではデータの更新が記録されているのはbinlog.000018だけなので、このファイルについてだけ考えれば良いです。byte目から始まるイベントとわかります。(問1)問1としてあえて秒単位でしかない実行時刻を解答してもらったのは、実際にこういった問題が起こった場合には似たようなクエリがアプリケーションの正常な処理として実行されていたり、実は何回も間違った後だったりするため確認作業を必要とすることが多いからです。ここまででわかったbinlogの状況を図1に整理してみます。binlogの状況バックアップを適用することで2の直前の状態にまでデータが復旧されるため、2から3までの更新情報を適用する必要があります。1から2の部分も適用したチームも見られましたが、この部分の更新分はバックアップに含まれているので、重複した更新を適用してしまうことになります。...の結果を利用するつもりでしたが、問題環境ではバイナリログからの抽出位置を正しく指定しなくてもchecksumが同じ値になってしまうことがありました。table文まで(図1の2~3部分)の更新分を抽出、適用していることを確認して正解としました。あなたはローカルネットワーク上にwebサーバを構築し、IPv6アドレスを使用してwebページに接続できるようにセットアップをしています。webページへはhttp://nginx.icttoracon.netでアクセスできるようにしたいです。nginxのホストには、すでにnginxのパッケージをインストール済みです。CSR1000Vとnginxのホストには固定でIPv6アドレスを割り当てました。Server)にIPv6アドレスが自動設定されるように、CSR1000VにはSLAACの設定を行いました。Nginxのページを表示させることができません。Nginxのページを表示させてください。クライアントが増えても自動でアクセスできるよう、設定変更はCSR1000Vとnginxホストのみとしてください。DNSサーバはCSR1000Vを使用します。各ノードにはssh/telnet用にIPv4アドレスが設定されていますので必要に応じて使用してください。予選終了後に実環境で採点されるので、スコアサーバでの解答は不要です。本問題には3つの原因があります。順を追って調べてみましょう。疎通性確認まずはクライアントマシンからnginxホストまでIPv6で疎通性があるか確認してみます。簡単な確認ではありますが、トラブル原因のレイヤをある程度限定できます。できるかどうか試してみましょう。ドメイン名からIPv6アドレスを取得するにはAAAAレコードを参照します。例としてAAAAレコードを取得するコマンドを以下に示します。49ubuntu@ICTSC-VNC:~$AAAAレコードは取得できていません。問題文でDNSサーバはCSRとされていますが、クライアントはどこを参照しているのでしょうか。IPv4でDNSサーバを受け取っているようですが、CSRのIPアドレスではありません。1つ目の原因はDNSサーバ(CSR)が参照できていないことです。問題文からクライアントの設定変更ではなくルータの設定変更で対応する方針であることがわかります。クライアントの設定とCSRの設定を確認すると、クライアントのIPv6アドレスはRAを用いた自動設定であることがわかります。DNSサーバのアドレスが配布されていません。RAでIPv6アドレスが設定されている場合は、以下の2つの方法でDNSサーバを配布することができます。ステートレスDHCPv6RAを用いたDNS配布(RFC8106)例としてRAのみでDNSの配布を行います。IOS-XEのコマンドリファレンスを参照すると、以下の設定でDNSの配布が行えそうです。fc00::1クライアントで確認してみます。77ubuntu@ICTSC-VNC:~$DNSサーバとしてfc00::1が設定され、AAAAレコードが正しく参照できています。nginx設定IPv6の疎通性があり、名前解決も行えているので一旦クライアントの作業を終え、nginxホストを確認してみます。80ポートの使用状況を確認してみます。(LISTEN)typeを見るとIPv4となっており、nginxがIPv6アドレスで待ち受けていないことがわかります。2つ目の原因はnginxはIPv6アドレスで待ち受けていないことです。nginxがIPv6アドレスで待ち受けるよう、設定を変更します。(LISTEN)フィルタリング設定nginxがIPv6で待ち受ける状態となりました。クライアントからアクセスができません。nginxホストのディストリビューションを確認してみます。~]$CentOS6.10であるため、フィルタリングはiptablesで行っていると予想されます。iptablesのルールを確認してみましょう。Nginxのページにアクセスできません。それもそのはず、iptablesはIPv4のフィルタリング設定だからです。Nginxのページを表示させることはできてました。IPv6のフィルタリングはip6tableで行います。ip6tableのルールを確認すると、80ポートのアクセスを許可しているルールが無いことがわかります。3つ目の原因はIPv6の80ポートが拒否されていることです。問題文には恒久的な設定ではなくて構わないとしか記載されていないので、80ポートを許可する方法か、プロセスを停止する方法があります。問題としてはどちらで行ってもいいですが、望ましいのは80ポートを許可する方法です。ip6tablesで80ポートを許可します。Nginxのページが表示されます。