/

問題文

仮想機密伝送路課では、ルータの検証中に疎通が取れないトラブルにぶつかっており、現在在室している社員では解決できないらしい。
代わりにこの問題を解決し、社員に対して説明してほしい。
ただし、疎通先のルータは他部署が管理しているものであり設定を書き換えることができない。

トラブルの概要

この問題はciscoルータをブロードバンドルータとして使えるように設定する際に問題が発生したという設定であった。
configを読み解くと、一般的なISPで使用されるPPPoEを使用してWAN側のIPアドレスを取得し、ローカル側にはプライベートIPアドレスをDHCPで配布してNAPTを行うことで割り当てられた一つのアドレスでWAN側へ接続していることがわかる。

解説

この問題の場合PPPoEを利用しているため、NAPTのWAN側インターフェースはdialerであるのに対し、NATのoutsideが物理配線のインターフェースに設定されていた。
この個所を特定し、正しいconfigに書き換えることでISP側に設定したIPアドレスに対し疎通が取れるようになっていた。

解答例

ip nat inside source list 11 interface dialer 11 vrf vrf11 overload
interface Dialer 11
ip nat outside
exit
ip route vrf vrf11 0.0.0.0 0.0.0.0 dialer 11 permanent

採点基準

この問題は以下のポイントを押さえていれば部分点が与えられるようになっていた。

  • NAPTが原因であることを指摘できているかどうか
  • 正しく設定を変更しPCから指定のアドレスにpingで疎通を確認できる

講評

この問題を解くためには、参加者はPPPoEやNATに関する知識が必要な問題であった。
参加者の中には何度も関係のない解答を送ってきたチームもあったが、落ち着いて問題を切り分けることでより問題に気付きやすくなるだろう。
また、今回のコンテストで初めてPPPoEを知った参加者がいるのであれば、少し複雑ではあるが一般的な家庭とISPの間で接続を確立する手段としてよく利用されるプロトコルであるため、これを機に理解を深めるのもいいだろう。
本問題はコンテスト向けに一部の設定を省略しているため、本問題の状態で運用するとセキュリティ面などに問題がある。
そのため、実際に家庭に導入する際は正しくDNSやACLを設定しなければならない。

 /

問題文

この部署ではAS番号を持たない組織に対して、プロバイダのルータと組織内のルータの間に境界ルータを設置し、プロバイダのルータと境界ルータの間で双方向にStatic Routeを書くことで対応している。
ある組織は複数のIPアドレス(192.168.23.0/24)を持っており、組織内では独自でルーティングしている。
組織内では、割り当てられた中で使ってないIPアドレスがあり、その箇所に対しpingを行うと余計な帯域を食われてしまう問題が発生しているという苦情が届いた。
この問題に対して組織側のネットワークに影響が出ないようこの問題を解決し、原因を報告してほしい。

トラブルの概要

この問題はプロバイダ側が使用していないアドレス帯があることを想定しておらず双方向にStaticを書いたことで発生したトラブルであった。

解説

この問題はプロバイダ側が使用していないアドレス帯があることを想定しておらず双方向にStaticを書いたことで発生したトラブルであった。
この場合、未使用アドレス帯にパケットを投げた場合、組織内では、自身のルーティングテーブルに情報が乗っていないため、Default Routeである境界ルータに転送する。
境界ルータはStaticRouteより、プロバイダのルータにパケットを送るが、プロバイダは組織内のIPアドレスであると判断し境界ルータにパケットを送る。その結果、境界ルータとプロバイダのルータ間でループが発生しパケットのTTL倍の帯域を無駄に消費していた。
この問題を解決するためにはパケットを破棄するNullInterfaceを設定しNullRoutingの設定を行う必要があった。

解答例(一例)

ip route 192.168.23.128 255.255.255.128 Null 0

講評

この問題はPCからpingを実行した際のエラー文からループが発生していることを見抜けるかどうかを問う問題であった。
解答方法はチームごとに異なり、Nullを使用していない場合でも現状のネットワークに支障の出ないACLを書いているチームにも等しく点数を与えていた。
しかし、ACLを使用する場合既に書かれてある場合もあり導入が困難なケースや、設定次第で新たなトラブルの原因になりやすいため扱いには十分注意が必要である。
参加者の中にはdenyが一行書かれたACLを解答として送ってきたチームもあった。これでは全てのパケットが対外に出ることができなくなるため、暗黙のdenyに関する知識やaccess-listに関する理解を深める必要がある。
ルーティングプロトコルが集約されるときには常に、集約内のすべての IPアドレスに対するトラフィックをルータが受信する可能性がある。
しかし、すべてのIPアドレスが常に使用されているわけではないので、集約対象のトラフィックを受信するルータでデフォルトルートが使用されている場合にはパケットがループする危険性があるので注意する必要がある。

 /

問題文

我社では、新しい部署の開設に伴い新たなネットワークレンジを割り当てることになった。

担当者はメールで渡された情報に従ってコンフィグを作成し、新しく導入した機材に流し込んだ。
しかし、いざ設定してみると他部署のネットワークとの疎通が取れないことが分かった。
各担当者に問い合わせたが原因は特定できなかったという。

そこで、この問題を解決し、原因およびその根拠、また修正したコンフィグを報告してほしい。

担当者に送られたメール:

件名: ○○部署開設に伴うネットワーク情報まとめ

本文:
お疲れ様です。
○○部署で使うネットワーク情報についてのまとめです。
192.168.38.0/24、デフォゲは192.168.38.1
ipv6アドレスの割り当てなし。

新しく使うアドレス
192.168.39.0/24
ipv6アドレスの割り当てなし。

新しく導入した機材で192.168.38.39を介して192.168.39.0/24を接続し、RIPで社内LAN向けに経路情報を投げてください。

制約・情報

routerAの192.168.39.0/24のネットワークにPCを接続して192.168.37.1にPingが飛ぶように設定を修正してください。

PCは、2960Bのfa0/1に接続してください。

routerAは1941です、routerBは操作できません。
enable password : ZWKKEFzV

この問題に関係のあるIP及びvrfは192.168.37.0/24,192.168.38.0/24,192.168.39.0/24,vrf05です。それを除く他のIP,vrfは当問題とは関係ありません。

回答していただく項目は以下の通りです。

  • トラブルの原因とその根拠(使用したツールやコマンド等も明記して)
  • 修正したコンフィグ

問題のスタート

192.168.39.0/24に接続されたPCから192.168.37.1にPingが飛ばない

問題のゴール

問題を解決し、192.168.39.0/24に接続されたPCから192.168.37.1にPingが飛ぶように設定を修正する。

トラブルの概要

RIPのバージョン指定を忘れたときに経路情報は見えてるのにPCからPingが飛ばなくなる

解説

routerAではripのバージョンを指定せず、routerBのみripにversion2を指定した。

ciscoルーターの場合ripのバージョンを指定しなければversion1で動作するが、version2の経路情報も受け取るため、routerAでは192.168.37.0/24を受け取ることができる。しかしrouterBはversion2で固定しているため、version1の経路情報を受け取らない。

そのため、routerBには192.168.39.0/24が伝わらないため疎通が取れなくなる。

この問題はルーター2台のコンフィグを見比べて問題を特定することができない為、流れているパケットを読む(debugなど)必要がある。

routerAでdebug ip ripコマンドで自分はversion1をsend、相手からはversion2をreceiveしていることが分かる

手元のRIPのバージョンを2に変更すると正しく疎通できるようになる。

回答例

1941でdebug ip rip コマンドを使用したところ、手元がRIPv1、対向がRIPv2を使っていることが分かりました。

そこで
router rip
address-family ipv4 vrf vrf05
version 2
と入力したところ、PCから正しくPingが飛ぶことを確認しました。

最低限これだけの情報が書かれていたらOKです。

 /

どうも、作問者のnasuと言います。

問題文

今回ある学校のL2部分をalaxala製のL2SWで構築することになった。
そして回線障害、機器障害が起きても通信を問題なく行えるように、alaxalaの独自プロトコル(リングプロトコル、GSRP)で冗長化をする。
しかし検証環境で設定を入れて、ALA-CとALA-Bを繋いでいるケーブルの障害試験を行なった際に、正常に切り替わることができず検証用のホスト(192.168.19.200/26)へ一切疎通が取れなくなってしまった。
またコンソールにはたくさんのログが流れており、状況がつかめずにいる。
あなたは疎通が取れない原因の報告と、そして障害が起きた状態で疎通が出来るように対処をしてもらいたい。

制約

  • ALA-B,ALA-C,2960-B間は必ずgsrpを使った冗長設定、またALA-A,ALA-B,ALA-Cはリングプロトコルを使った冗長設定にしてください。プロトコルを使わないという解答は点数になりません。

トラブルの概要

  • 両方のスイッチのgsrpにno-neighbor-to-master direct-downと設定が入っている為、障害時に両方のスイッチがお互いに障害が発生したと判断してパケットが両方のスイッチでフォワードされるようになり無限ループする構成となってしまった
  • リングプロトコルのhealth-checkの値が間違っている

解説

ALA-B,ALA-Cでつながっているインターフェースはgsrp-directlinkになっており、gsrpの切り替えがno-neighbor-to-master direct-downと設定されている為、障害時お互いがお互いに障害が起きたと判断して2台ともマスター状態で動いているためブロードキャストストームが起きた為パケットが正常に飛ばなくなるということです。
またringプロトコルのヘルスチェックの送信間隔時間及び保護時間が間違っている為

解答例

ALA-B,ALA-Cをどちらかのgsrpの設定をno-neighbor-to-master direct-downと設定しgsrpをリスタートさせることで片方がバックアップとなりパケットを流さなくなります。
これによってpingが正常に飛ぶようになります。
ALA-B or ALA-C

ena
conf t
gsrp 1
no-neighbor-to-master manual
exit
exit
restart gsrp

またリングプロトコルのヘルスチェックの値に不備がある為これもパケットがおかしくなるという言及、及び設定変更
ALA-A

enable
conf ter
axrp 1
health-check interval 500
health-check holdtime 1600

採点基準

pingが届くだけならgsrpの設定のみで済むので以下の配点となっています
1. gsrpの挙動への言及とgsrpの設定変更をしpingが正常に飛ぶ → 基準点
2. gsrpの解答をした上でaxrpのヘルスチェックの値に不備があることへの言及及び設定変更 → 満点

講評

先に講評から
15チーム中5チームからの解答があり4チームが基準点を突破しそのうち1チームが満点でした。
また満点のチームは外部のドキュメントを引用して何が起きているかの言及、また設定変更の手順を1つずつ丁寧に説明せれており芸術点も追加されています。
さて学生のみなさんはRS232cを使うネットワーク機器を扱ったことはありますでしょうか?
初めて見る学生さんは「なんだこのコンソールポートの口は?」と驚いたかもしれません
最近では比較的rj45を使う機器しか見ないと思いますが、ベンダーによってはちらちらと出しているところを私は見ます。
世間のネットワーク機器はcisco以外にもあらゆるベンダーで構成されています。
そして一度も触ったことがないのに突如上司から「ネットにドキュメントがあるから読んでやって」というのも大人の世界ではあるかもしれません(私のバイト先ではありました。)
今回出したalalaxaはコマンド体系がシスコライクなので学生でもcisco機器を勉強していれば、そこまで扱うのにはそこまで難しくないと思われます。
今回cisco以外の機器を触って「あ、おもしろいな」って思った学生のみなさんはこれを機にあらゆるのベンダーのネットワーク機器に触れてみるのもいいかもしれません。
次回も”出来ればですが”cisco以外のネットワーク機器を使った問題を作ってみたいと考えていますので楽しみにしてください。(確実に出るという保証は無いorz)

 /

問題文

社内にVyOSを導入することが決まった。
そこで、社内のインフラを構築する前に以下の図の様なテスト環境で検証を行った。
VyOSにDNSのキャッシュサーバとDHCPサーバを起動し、下に接続されているUbuntuにIPアドレスを割り当てた。
しかし、Ubuntuから外部のサーバにアクセスしようとしたが接続できずICMPを送っても応答がない。ところが、VyOSからICMPを外部のサーバに送ると応答が返ってくる。
なので、Ubuntuから外にアクセスできる様に解決してほしい。ただし、Ubuntuに直接接続することはできず、VyOSからはアクセスできるようになっている。

スタート

  • Ubuntuから外部のサーバにアクセスできない
  • VyOSからはアクセスが可能

ゴール

  • Ubuntuから外部にアクセスできる

情報

サーバ IP アドレス アカウント パスワード
vyos 192.168.20.80 admin PxZsMqycN4a4nzlk1Xg7
client 192.168.20.2 admin kopvVL3cT2tkALu4nQnD

トラブルの概要

この問題ではVyOSがNATをして下に接続されているUbuntu Server(以下clientとする)が外とアクセスできるような構成になっていました。しかし、何らかトラブルでclientが外と全く疎通が取れない状態でした。VyOSから8.8.8.8にpingをすると応答が帰ってくるという状態でした。

解説

問題文を読んだだけで大抵の人はVyOS側に問題があることに気づいたかと思われます。答えはVyOSのNATの設定に不備がありclientが外に繋げられなかったということです。

解答例

NATの設定を確認するためにshow natを打つと以下のように表示されます。

nat {
source {
rule 1 {
outbound-interface eth1
source {
address 192.168.20.0/26
}
translation {
address masquerade
}
}
}
}

今回の場合、VyOSが対外に接続しているインターフェースはeth0なのにoutbound-interface eth1となっています。これが原因な訳でこれを消すか上書きしてあげることで疎通が取れるようになるはずです。以下のような手順で上書きをしてみます。

# set nat source rule 1 outbound-interface eth0
# commit
# save

この後に8.8.8.8に対してpingをすると以下のように接続できていることがわかります。

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=12.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=11.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=61 time=10.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=61 time=9.57 ms

採点基準

  • 外部に疎通できないことを指摘
  • 解決方法の提示
  • そのあとに疎通できることを提示

講評

この問題はウォームアップ問題として作成しました。なのでほとんどのチームが解答してくれました。実はVyOSは一回も触ったことがありませんでした。だそうにも難しくすることができないので実際に自分がミスしたところを出せばいいのではと思い出題しました。

 /

問題文

以下の図のようなDMZとLOCALの2つの空間が接続されている内部向けDNSサーバと、外部向けのwebサーバがあり、webサーバは8000番で待ち受けている。
LOCALからそのwebサーバの8000番に対しFQDNでアクセスしても表示されないと社内の各所から連絡があった。

そのため、内部からwebサーバにFQDNでアクセスできる様に解決してほしい。
ただし、既に構築してあるこのDNSサーバを使い、FQDNで正常にアクセスできることを証明してほしい。

制約

この問題での制約は問題文で指示されている通り、図にあるdns-serverを必ず使用することです。

スタート地点

  • DNSの問い合わせができない

ゴール地点

  • DNSの問い合わせができる
  • 正常に問い合わせができているかをコマンドを使用して証明する
  • 健全なDNSサーバを構築する

必要情報

  • ドメイン: ictsc.local
  • ホスト:
  • web-server: www.ictsc.local
  • dns-server: dns.ictsc.local

情報

サーバ IP アドレス アカウント パスワード
dns 192.168.4.70 admin e4EYoNiTlII4zEE7udxG
web 192.168.4.71 admin Eaa4mXBsgygxag934x3H

トラブルの概要

図のように各サーバは2つのNICをもちそれぞれDMZとLOCALに接続されていました。トラブルの概要としてLOCAL側からdns-serverに対して名前解決の問い合わせをしてもドメインと紐づけられているIPアドレスが帰ってこないというものでした。

解説

このトラブルは/etc/bind/以下にDMZとLOCALの空間から名前解決できるように定義されたzoneファイルが不適切のため発生していました。それがこの4つのファイルです。

  • 0.4.168.192.in-addr.arpa
  • 64.4.168.192.in-addr.arpa
  • ictsc.local-0.zone
  • ictsc.local-64.zone

トラブルの原因としてこの4つのファイル全てに共通して以下の3つがありました。

  • SOAレコードを定義する箇所で最初の@が抜けている
  • SOAレコードのhostmaster-emailの最後に.がついていない
  • SOAレコードを括弧で囲むときに最後が)ではなく}となっている

問題の初期状態は以上の3つが原因でDMZとLOCALから名前解決ができませんでした。なので適切な状態に書き直して名前解決ができることを提示すると基準点となります。満点にするためにはゴール地点に記載した通り健全なDNSサーバを構築するまで行うことです。実はこのdns-serverはDMZからictsc.local以外の名前解決をしてしまいます。つまりオープンリゾルバ状態でした。なので外部からはictsc.local以外は受け付けないように設定を変更する必要があります。それには以下のファイルを書き換える必要があります。

  • named.conf.default-zones

解答例

まず、/etc/bind/以下の0.4.168.192.in-addr.arpaを書き換えます。これはDMZの空間からの逆引きを解決するためのファイルです。

$TTL 3600
IN SOA dns.ictsc.local. root.ictsc.local (
2018022400
3600
900
604800
86400
}

IN NS dns.ictsc.local.
10 IN PTR dns.ictsc.local.
11 IN PTR www.ictsc.local.

これを先ほど指摘した3つの原因を以下のように修正します。

$TTL 3600
@ IN SOA dns.ictsc.local. root.ictsc.local. (
2018022400
3600
900
604800
86400
)

IN NS dns.ictsc.local.
10 IN PTR dns.ictsc.local.
11 IN PTR www.ictsc.local.

これを他のファイルも同様に修正し、サービスの再起動を行うことで名前解決ができるようになります。
次にオープンリゾルバを解決するためにnamed.conf.default-zonesを修正します。このファイルの中にinternalexternalのゾーンによって読み込むファイルを記述している箇所があります。そこにmatch-clientsを追加して適切な空間を記述することでオープンリゾルバを回避することができます。

採点基準

  • 上記のトラブルを指摘
  • 対策後にちゃんと名前解決ができていることを提示
  • オープンリゾルバとして動作してしまっているのでそれを指摘して対処(加点対象)

講評

この問題はウォームアップ問題として作成しましたが実際に解答を送ってくれたチームは半分ぐらいで想定と違う結果となり驚きました。その中でもちゃんと最後まで解けていたのは1チームのみでした。

 /
カテゴリー

問題文

電子通信網局 特殊物理装置課から構築中のトラブルを解決して欲しいと依頼が届いた。
社内IoTシステムの開発のためRaspberryPiにRaspbianをインストールしたが、SSH接続ができず何もセットアップができない状態らしい。
尚、初めからSSHを用いてセットアップを行う予定だったためディスプレイやキーボードは用意されていないようが、なんとかしてセットアップを完了させてほしい。

スタート

RaspberryPiにRaspbianをインストールした直後の状態

ゴール

指定されたIPアドレスがRaspberryPiに振られており、SSHでアクセスできる。

情報

  • 指定されたIPアドレス 192.168.0.88
  • ネットワーク・アドレス 192.168.0.0/24
  • デフォルトゲートウェイ 192.168.0.254
  • DNSサーバー 8.8.8.8
  • ユーザー pi
  • パスワード raspberry
  • イメージ 2017-11-29-raspbian-stretch-lite

トラブルの概要

Raspbian は 2016/11/25 以降のイメージではデフォルトでsshが無効化されていて、有効化するためには何らかの方法を取る必要がある。
Raspbian では、IPアドレスを固定する際に編集するファイルが、 /etc/network/interfaces から /etc/dhcpcd.conf に変更された。

解説

Raspbian では以下のいずれかの方法によって ssh を有効化する必要がある。

  • /boot パーティションに ssh という名前の空のファイルを設置してから電源を入れてブートを始める。
  • Raspbian の Linux ファイルシステムを手元のPCにマウントして、 /etc/rc.d などに起動時にsshを有効化するスクリプトを作成する。
  • UART などの何らかの方法でコンソールにアクセスして raspi-config からsshを有効化する、もしくは $ systemctl start ssh ($ systemctl enable ssh) を実行してsshを有効化する。

また、IPアドレスを固定するために /etd/dhcpcd.conf にIPアドレスの設定を追記する。

解答例

お疲れ様です。運営委員の源波です。「アップルパイが完成しない!」問題の作業報告を提出いたします。

まず、一度 Raspberry Pi の電源を抜いてから、Raspberry Pi に挿入されていたSDカードを手元のノートパソコンにマウントします。dfコマンドの結果、 /boot パーティションは手元PCの /Volumes/boot にマウントされていることがわかったので次のコマンドで空のsshというファイルを作成します。$ touch /Volumes/boot/ssh lsコマンドで正常にファイルが作成されていることを確認してから、SDカードを手元からアンマウントし、Raspberry Pi に挿入し直してから電源ケーブルを再度差し込みます。

これで Raspberry Pi のsshが有効化されたので、次にDHCPによって割り振られているアドレスを特定します。Raspberry Pi と同じLANに属しているインターフェイスを対象として、arp-scanコマンドを実行します。 $ arp-scan --interface en0 -l
Raspberry Pi に割り振られているIPアドレスが 192.168.0.8 であることがわかったので、sshで接続します。 $ ssh pi@192.168.0.8 sshで接続できたら、IPアドレスを固定するために、/etc/dhcpcd.conf に以下の設定を追記しました。

interface eth0
static ip_address=192.168.0.88/24
static routers=192.168.0.254
static domain_name_servers=8.8.8.8

networking を再起動して、変更を完了します。$ sudo systemctl restart networking

これでIPアドレスが固定されます。$ ssh pi@192.168.0.88

以上が作業報告になります。よろしくお願いします。

採点基準

採点の基準として、sshの有効化とIPアドレスの固定で、それぞれ50%を想定していましたが、どちらかしかできていないチームはなかった。IPアドレスの固定については、現在でも /etc/network/interfaces の編集による設定でも変更が可能であるが、/etc/network/interfaces の中には、/etc/dhcpcd.conf を編集しろという旨の記述がコメントアウトされており、そちらのほうが妥当であると考え、/etc/network/interfaces を編集していたチームには満点より10点低い点数をつけた。

 /

問題文

導入

仮想機密伝送路課から同時に2件のトラブルの解決を依頼された。
どうやら社内LANの変更工事を行ったところ、いくつか問題が発生しているようだ。
問題を解決し再発を防止するための作業を行って欲しい。
また、必要であれば上司への相談や提案を行うことが出来る。

トラブル1

仮想機密伝送路課から「帯域幅が不足している為、業務に支障をきたしている」という不満の声があり、「ネットワークで使用可能な帯域幅」を増やすこととなった。
以前この部署では上流回線を他の優先的なサービスと併用していた為、何らかの設定が残った可能性が考えられる。
しかし、先日の社内LAN変更工事により回線には次世代ブロードバンドを導入している為、上流の帯域幅のグッドプットは十分に確保されている。
どうやらネットワーク機器の設定変更を忘れてしまっているようだ。
この問題を解決し再発を防止するよう作業してほしい。

スタート

  • 参加者PCを2960BのFE0/9もしくはFE0/10に接続し適当なWEBページにアクセスすると通信速度が明らかに遅い

ゴール

  • 通信速度の問題が仕様(必要情報)通りに改善されている

情報1

  • 部署内のルータである892jの設定を確認し、帯域幅を適切に設定してください。
  • enable password : q0bC50xE
  • 帯域幅は、上流回線をベストエフォート100Mbpsとして業務に使用する帯域は約40%程度として調整して下さい。

トラブル2

電子通信網局でBYODを導入し、局内の端末を全てLANに接続することになった。しかし、一部の人から他の人の端末は繋がるのに自分は繋がらないという不満の声が上がっている。
この問題を“適切に”解決し、再発を防止してほしい。

スタート2

  • 自分“一部の端末”からまともに外部疎通ができない

ゴール2

  • 使用可能なIPアドレスを全て社員の端末に自動設定されるように解放されている。
  • 全ての端末が外部疎通ができる状態になっている

情報2

  • 部署内のルータである892jの設定を確認し、適切に設定を施してください。
  • enable password : q0bC50xE
  • 改善が必要だと思った設定は自由に変更してください。(動作に影響が無ければ減点はありません)

  • この問題に関係のあるIP及びvrfは192.168.17.0/26,vrf17です。それを除く他のIP,vrfは当問題とは関係ありません。

回答例

no ip dhcp excluded-address 192.168.17.31 192.168.17.62
ip dhcp excluded-address 192.168.17.62

shape average 40000000

access-list 1 permit 192.168.17.0 0.0.0.63

access-list 100 permit ip 192.168.17.0 0.0.0.63 any
access-list 100 permit ip any 192.168.17.0 0.0.0.63

コアの技術

  • クラスベースの帯域制御/シェーピング
  • NAT・DHCP・ACLの複合

トラブルの内容

  • シェーピングをかけて帯域制限をしようとしたが、意図した速度より通信速度が大幅に遅くなってしまった
  • BYODでスマホ等を導入したらネットワークに端末が増えて過ぎて(DHCPで)繋がらない
  • DHCPのレンジを拡張したらNATのACLとシェーピングのACLから外れたアドレスが不調になる

###スタート地点
通信速度がめっちゃ遅い
“一部の端末”からまともに外部疎通ができない

###ゴール地点
普通にインターネットができる

###採点基準(基準点160点)
– (計120点)原因の説明・理解
– (30点)ホストアドレスが足りないと気づきNWアドレスの拡張を提案する
– (30点)シェーピングのパラメータが適切な値で無いと気づく
– (30点)IPアドレスが足りない事に気づく
– (30点)ACLが不適切であると気付く

  • (計40点)リモートネットワークに快適に接続できる
  • (20点)スループットが改善されている
  • (20点)全員が適切に接続し自動アドレッシングが行われる

  • (計40点)いい感じで設定を直している

  • (10点)シェーピングの設定値を正しい値に修正出来ているか
  • (10点)PATのACLを変更している
  • (10点)DHCPのレンジ(ip dhcp excluded-address)をいい感じに変更しているか
  • (10点)シェーピングのACLを書き換えているか
  • (10点)アイデア(DHCPのリース期間を変更するなど)

問題解説

この問題はクラスベースの帯域制御、シェーピング、PAT・DHCP・ACLのに関する問題です。
ACLのステートメント条件が他の設定コマンドに影響する事が原因です。
また、ネットワーク管理者はシェーピングを定義する為に発行されているコマンドのサブコマンドパラメータの単位に注意する必要があります。
ネットワーク管理者はこのネットワークセグメントのホスト数を調査し、適切なアドレス設計を上長へ提案する必要があります。

 /

問題文

今まで使っていたサーバが老朽化してしまったため、新しくサーバのマイグレーションを行うこととなった。
現在はそのマイグレーション前の移行作業中なのだが、cronで動作させていたスクリプトが実行されない。

そのため、新しいサーバでcronが正しく実行されるように設定の変更を行ってほしい。

スタート

旧サーバで実行されているcronに登録されているスクリプトが新サーバで実行されない

ゴール

新サーバにて、全てのcronに登録されているスクリプトが正常終了するようにする

トラブルの概要

Linuxディストリビューションにおいて一般的に利用されているタスクスケジューラである cron の実行時に発生する、ディストリビューション間での差異を利用したトラブルです。

一部のLinuxディストリビューションでは、/etc/cron.hourly/, /etc/cron.monthly/, /etc/cron.weekly/のように、ディレクトリ以下にスクリプトを設置するだけで一定の時間間隔でスクリプト群を実行するディレクトリが用意されています。
このディレクトリを実行している実態は /etc/cron.d に設置されていることが多いです。

[vagrant@node1 ~]$ cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)

[vagrant@node1 ~]$ ls -l /etc/cron.d
合計 8
-rw-r--r--. 1 root root 128  8月  3  2017 0hourly
-rw-------. 1 root root 235  8月  3  2017 sysstat

[vagrant@node1 ~]$ cat /etc/cron.d/0hourly
# Run the hourly jobs
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
01 * * * * root run-parts /etc/cron.hourly

/etc/cron.d/0hourly に、run-parts /etc/cron.hourly というコマンドを実行しています。
この際に実行されている run-parts というコマンドの実装が異なることが、今回の問題におけるキモとなります。

今回の大会の競技時間を考慮した場合、1時間に1回実行されるというシナリオは無用な時間の損失を産んでしまう可能性があったため、疑似的に /etc/cron.d/0minutely というファイルを生成し1分に1回実行されるようにしていました。

run-partsについて

実際に確認してみると、 run-parts というコマンドはディストリビューションによってそもそもファイル形式すら違う事が分かります。

[vagrant@node1 ~]$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)

[vagrant@node1 ~]$ which run-parts
/usr/bin/run-parts

[vagrant@node1 ~]$ file /usr/bin/run-parts
/usr/bin/run-parts: Bourne-Again shell script, ASCII text executable



vagrant@node2:~$ cat /etc/debian_version
stretch/sid

vagrant@node2:~$ which run-parts
/bin/run-parts

vagrant@node2:~$ file /bin/run-parts
/bin/run-parts: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=53e52d241c66c42300698ceec057edd3417be4b6, stripped

CentOS においてはBash ベースなシェルスクリプトとして実装されており、Debian においては実行可能なバイナリとして実装されていることが分かります。

CentOS におけるシェルスクリプトでは、以下のような記述がありました。

[vagrant@node1 ~]$ head -n 5 /usr/bin/run-parts
#!/bin/bash
# run-parts - concept taken from Debian

# keep going when something fails
set +e

つまり、元々debianutilsに実装されていたrun-partsをシェルスクリプトで実装したものを、CentOSは利用していると考えられます。

この実装時に差異が発生したのが今回のトラブルの原因となります。

今回の問題におけるトラブル

実際には、以下の差異を利用してトラブルを発生させました。

  • スクリプト名に . を含める (例: crawler.sh)
    • Debianでは . が含まれていても実行されますが、CentOSでは実行されません
  • Shebangがスクリプトに存在しない
    • DebianではShebangが存在しなくても拡張子で判別されますが、CentOSでは拡張子を削除するため記載が必要になります

また、今回は移行時に発生するトラブルとして、以下のトラブルも発生させました。

  • 移行先のディストリビューションにコマンドがあっていない
    • 移行先はDebianだったのですが、 yum update というコマンドを実行させていました
  • cronに登録されているスクリプトが移行先サーバに存在しない
    • WebAPIに対してリクエストを送信するスクリプトが移行元にはあるが移行先には配置していませんでした

採点基準

日本語でこの事象を説明しているブログも多く存在しており、cronという比較的利用者も多いプロダクトであることから、入門編と位置づけて出題しました。
そのため、「どこまで気づいているのか」を採点基準に採点を行いました。

まとめ

トラブルシューティングの基本として、「事象の切り分けを行う」という事があります。
実際にトラブルが発生している事象はどのように実行されていて、どのような箇所で実行されているのかを確かめるのがベターと言われています。

今回の回答を見てみると、「実行権限がなかったので付与しました」「内容が誤っていたため修正しました」などの回答が来ていたのですが、今回で言うなればファイル名を変更しない限り実行されていないため、cronを経由したファイルの実行を確認出来ていなかったのではないかと予測します。
実際にはどのような環境で、どのような方法で目の前のコマンドが実行されているのかを確かめるようにするようにしてみるのが重要だと改めて感じました。

なお、今回の記事中で検証のために利用したVagrantfileはこちらとなります。是非検証してみてください。

 /

問題文

障害対策調査課から依頼があった。
我社で運用しているサービスに初歩的なディレクトリトラバーサルの脆弱性が見つかってしまったらしい。

しかし、不幸なことに担当者がバカンス中のため連絡を取ることが出来ない。
このサービスは担当者にバカンス直前に無理やり開発させたため、ソースコードは彼のPCの中のようだ。
ソースコードが無いのでプログラムの修正が出来ない。
だが、担当者が戻るまでサービスを落としたままにするわけにはいかない。

どうにかしてプログラムを修正せずに安全にサービスを動かしてほしい。

制約

  • サービスは80番ポートで動かす
  • 対外疎通無し
  • 新たにパッケージをインストールする等はできない

スタート

ファイルアップローダーがディレクトリトラバーサルの脆弱性を受けてしまう状態

ゴール

ファイルアップローダーがディレクトリトラバーサルの影響を受けずにサービスが動く状態

情報

  • 192.168.1.10:80 でサービスが動く
  • ユーザ: admin
  • パスワード: yasumikure
  • ファイルアップローダのバイナリ: /home/admin/uploader

Webサービスのパス

メソッド パス 動作
GET / アップロードされた画像一覧
GET /upload 画像をアップロードするページ
POST /upload 画像をアップロード

使用するディレクトリ

パス 用途
/var/www/templates/ レンダリングするテンプレート
/var/www/assets/ jsやcssなど
/var/www/images/ アップロードしたイメージの保存場所

サーバ動作確認例

# sshしてサーバを起動
ssh admin@192.168.1.10
sudo /home/admin/uploader

# 手元のブラウザもしくはcurlで 192.168.1.10:80にアクセス

# ディレクトリトラバーサルのサンプル
curl 192.168.1.10:80/upload \
-X POST \
-F "graphic=$(echo 'echo Hacked' | base64)" \
-F "filename=../../hacked.txt"

トラブルの概要

この問題ではディレクトリトラバーサルの脆弱性が発覚したファイルアップローダが用意されています。
これをroot権限で動作させるのはまずいので、どうにかしてある程度安全に動くようにして欲しいというのがこの問題の主旨です。

解説

この問題は「Linux Capability」を知って欲しいという意図で、少々無理やり作りました。
問題を解いていて、思うところがあったかもしれませんがご容赦ください。

さて解説に入ります。まず前提を以下に示します。

  • このファイルアップローダはLinuxで動くELFバイナリとして用意されてる。
  • サービスを動かすポートは80番で固定されているため変更はできない。
  • 80番ポートは、通常は一般ユーザではバインドできず、root権限が必要。
  • ディレクトリトラバーサルのあるアップローダをroot権限で動かすと意図しないファイルが書き換えられてしまう可能性が有ります(そもそもサービス止めろよって話ですが)。

この問題の想定解の方向性は「一般ユーザで80番ポートをバインドしてサービスを動かす」です。
その際に、一般ユーザで80番ポートをバインド可能にするのが「Linux Capability」です。
詳細は省きますが、簡単に説明するとケーパビリティとは「root権限を細分化し、部分的に適用できるようにしたもの」です。
今回はウェルノウンポートを一般ユーザでバイドできるようにするために、cap_net_bind_serviceをアップローダのバイナリに付与します。
こうすることで、このアップローダは一般ユーザで80番ポートをバインドできるようになります。
ちなみに、ケーパビリティを付与できるのはバイナリのみで、スクリプトには付与できません。

解答例

この問題の突破基準は以下の解答、もしくは以下と同等の効果が得られると判断した解答です。
以下はファイルアップローダにケーパビリティを付与し、一般ユーザ(admin)で実行する例です。

sudo setcap cap_net_bind_service=eip /home/admin/uploader
/home/admin/uploader

この解答だけでは、ディレクトリトラバーサルは完全には防ぎきれていませんが、この問題を出した意図は達成されているので良しとしました。
adminユーザのままで実行すると、/home/adminが書き換えられてしまうため、以下のようにするとなお良いです。

sudo --user=nobody /home/admin/uploader

お気づきの方もいると思いますが、この問題はケーパビリティを使わなくても、chrootAppArmorを使うことで解決できます(そのほうが良いケースが…)。
今回はそういった解答で、より堅牢で安全だと判断した解答にはボーナス点を付けさせていただきました。

講評

この問題は15チーム中9チームが基準を突破し、そのうち4チームがケーパビリティを使った解答を送ってくれました。(思ったよりケーパビリティ使ってくれなくてちょっと寂しい…)

先程「ケーパビリティを知ってほしい」なんていいましたが、正直ケーパビリティの実用的な用途ってあまり思いつかないんですよね。
ぱっと思いつくのはcap_dac_overrideを付与した、どこでも覗けるlsとか、なんでも読めるcatぐらいですね。

それでは、問題解説を終わります。

最近のコメント