---
# System prepended metadata

title: 'ICTSC 1日目：11:00 - 18:00(17:00解答提出締切)'

---

# ICTSC 1日目：11:00 - 18:00(17:00解答提出締切)
URL: https://contest.ictsc.net
チーム名: 味処まるたか
パスワード: qz3Rsntl

2日目: https://hackmd.io/um16F-dqRxeV6kotdQp2Tg

## 1日目スケジュール
- 10:30-11:00
    - 開会式 ライブ配信あり（開会挨拶、ルール確認、接続確認)
- 11:00-17:00
    - 競技時間

## 問題
|問題番号|問題種類|担当|確認|
|----|----|----|----|
|1|レッツアウトプット|kamekame||
|2|pingが飛ばない!|yas-nyan||
|3|中二病でも繋げたい|skyline||
|4|SSHできなくなっちゃった2|skyline||
|5|DM-VPNをつなげてください|yas-nyan||
|6|世は大コンテナ時代!!!|takanori||
|7|生き返れMariaDB|kamekame||
|8|メールを送りたい!(1)|alt||
|9|メールを送りたい!(2)|alt||
|10|適当に俳句投稿サービス作ったらXSRF脆弱性孕んでた件。|takanori||


## 1:レッツアウトプット:kame
### 問題概要：SQL
### 解答

お世話になっております。味処まるたかの亀井です。
以下のSQLを実行することで、依頼されたCSVを出力することが可能です。
```
USE Business
SELECT
  Worker.ID, Worker.Name_f, Worker.Name_p, Sales.DepartmentID, Sales.Date, Sales.Money
FROM
  Worker
INNER JOIN
  Sales ON Worker.ID=Sales.WorkerID
INNER JOIN
  Department ON Sales.DepartmentID=Department.ID
WHERE
  Department.Name="営業部" AND Sales.Date BETWEEN '2019-01-01' AND '2019-12-31' ORDER BY Sales.Money DESC
INTO OUTFILE '/tmp/re.csv'
  FIELDS TERMINATED BY ','
  OPTIONALLY ENCLOSED BY '"';
```
以上のコマンドはSQL.txtとしてまとめてあり、以下のコマンドを利用することで実行後は/tmp/re.csvにCSVファイルが作成されます。
```
$ mysql -uroot -p < SQL.txt
```
以上、 ご確認よろしくお願いいたします。




## 2:pingが飛ばない:yas-nyan
### 問題概要
bgp
### 解答

お世話になります．味処まるたかの豊田です．
「pingが飛ばない」に関して問題解決を行いましたのでご報告いたします．

#### 問題①： vyos6のdummy interfaceとBGP広告
vyos6に付随しているIF(dum0)に以下のアドレスが付いていました．

user@VyOS6# show | commands | grep dum0
set interfaces dummy dum0 address '192.168.2.65/29'

これは， 対外接続組織(AS65001)が広告するべきプレフィックス`192.168.2.64/28`と重複しています．
vyos6は以下のようにvyos4,vyos6とIBGPコネクションを確立し，当該プレフィックスを広告しています．

```
user@VyOS6# show | commands | grep bgp

# vyos5とiBGPネイバー
set protocols bgp 65000 neighbor 192.168.2.33 remote-as '65000' 
# vyos4とiBGPネイバー
set protocols bgp 65000 neighbor 192.168.2.49 remote-as '65000'

# dum0に付随するアドレスをBGPで広告中
set protocols bgp 65000 network '192.168.2.64/29'
```

以下がvyos5がvyos6よりBGPで受信した経路です． `192.168.2.64/29`宛の経路をvyos6から受信しており，そのとおりにルーティングテーブルが更新されていることがわかります．

```
VyOS5# show  ip route 192.168.2.64/29
Routing entry for 192.168.2.64/29
  Known via "bgp", distance 200, metric 1, best
  Last update 00:05:57 ago
  * 192.168.2.34, via eth1
```

一方で，対外接続組織(AS65001)のBGPスピーカー(vyos3)からも重複する経路`192.168.2.64/28`が広告されています．

```
VyOS5# show  ip route 192.168.2.64/28
Routing entry for 192.168.2.64/28
  Known via "bgp", distance 20, metric 0, best
  Last update 15:05:33 ago
  * 192.168.2.113, via eth0
```

インターネットプロトコルではロンゲストマッチ原則により，よりプレフィックスが長い経路が優先されます．
そのため，vyos4またはvyos5から送信されたVM1(192.168.2.66)宛の通信は， vyos6がiBGPで広告した経路(192.168.2.64/29)を選択して配送されるため， 対外接続組織(AS65001)のルータではなく，vyos6宛に送信されることになり，VM1に到達しません． vyos6に到達した192.168.2.66宛の通信はdum0に送信され，破棄されます．

また， vyos6のdum0につけられているアドレスは`192.168.2.65/29`であり，VM1のアドレス`192.168.2.66`とサブネットが重複しているため，VM2から送信されたVM1宛の通信は，BGP経路の広告の是非に関わらず，同じくdum0に送信され，破棄されます．


まとめると，本設定によって，vyos4・vyos5からVM1宛の通信が配送されない問題が生じていることがわかります．

#### ソリューション①： vyos6から当該経路のBGP広告を止める．
本案件では新しく対外接続組織(AS65001)とのBGPピアリングを行い，VM1宛の通信を疎通させる要件が挙げられています．
したがって，vyos6でdum0につけられているアドレス(192.168.2.65/29)を削除または変更し，当該するプレフィックス(192.168.2.65/29)の広告を停止させる必要があります．

vyos6に以下の設定を投入します．

```
user@VyOS6:~$ configure
^P[edit]
user@VyOS6# delete protocols bgp 65000 network '192.168.2.64/29'
user@VyOS6# delete interfaces dummy dum0 address 192.168.2.65/29

[edit]
user@VyOS6# commit

```

それにより，vyos4・vyos5からVM1宛の通信が正しく配送されることがわかります，

```
#### vyos4からVM1宛のパケットを送信した例． vyos2(192.168.2.129 vyos1(192.168.2.97)を経由しVM1に到達していることがわかる
user@VyOS4:~$ mtr 192.168.2.66 -r -c 2
HOST: VyOS4                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.2.129                 0.0%     2    0.5   0.5   0.5   0.5   0.0
  2. 192.168.2.97                  0.0%     2    0.9   1.0   0.9   1.1   0.1
  3. 192.168.2.66                  0.0%     2    1.2   1.2   1.2   1.3   0.1

#### vyos5からVM1宛のパケットを送信した例． vyos3(192.168.2.113 ) vyos1(192.168.2.81)を経由しVM1に到達していることがわかる
user@VyOS5:~$  mtr 192.168.2.66 -r -c 2
HOST: VyOS5                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.2.113                 0.0%     2    0.5   0.6   0.5   0.7   0.2
  2. 192.168.2.81                  0.0%     2    0.9   0.9   0.9   0.9   0.1
  3. 192.168.2.66                  0.0%     2    1.5   1.4   1.2   1.5   0.2

```

#### 問題②： vyos6がBGP経路を受信しない問題
ソリューション①を実施後，vyos4/vyos5からはVM1宛の通信が行えることがわかりました．しかしながら依然としてVM2からVM1宛の通信を行えません．

以下がvyos6のBGPネイバー(vyos5)の情報です．

本来，vyos5がAS65001から受信した経路がvyos6にも広告されるはずですが，現状ではvyos5から全く経路を受信していないことがわかります．


```
user@VyOS6:~$ show ip bgp neighbors
BGP neighbor is 192.168.2.33, remote AS 65000, local AS 65000, internal link
  BGP version 4, remote router ID 192.168.2.114
  BGP state = Idle
  Last read 12:21:59, hold time is 10, keepalive interval is 3 seconds
  Message statistics:
    Inq depth is 0
    Outq depth is 0
                         Sent       Rcvd
    Opens:                  3          1
    Notifications:          2          0
    Updates:                7          0   ##################### ここが
    Keepalives:         18900      18898
    Route Refresh:          0          0
    Capability:             0          0
    Total:              18912      18899
  Minimum time between advertisement runs is 5 seconds

 For address family: IPv4 Unicast
  Inbound soft reconfiguration allowed
  Community attribute sent to this neighbor(both)
  0 accepted prefixes

  Connections established 2; dropped 2

```

また，以下がvyos6のルーティングテーブルです． 当該プレフィックス(192.168.2.64/28)宛の経路がルーティングテーブルに載っていないことがわかります．

```
user@VyOS6:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

C>* 127.0.0.0/8 is directly connected, lo
O   192.168.2.0/28 [110/10] is directly connected, eth2, 15:37:21
C>* 192.168.2.0/28 is directly connected, eth2
O   192.168.2.32/28 [110/10] is directly connected, eth0, 15:37:21
C>* 192.168.2.32/28 is directly connected, eth0
O   192.168.2.48/28 [110/10] is directly connected, eth1, 15:37:21
C>* 192.168.2.48/28 is directly connected, eth1
O>* 192.168.2.112/28 [110/20] via 192.168.2.33, eth0, 15:35:24
O>* 192.168.2.128/28 [110/20] via 192.168.2.49, eth1, 15:35:22


```


この事象の原因は，vyos4/vyos5にて誤ったフィルターが行われているところにあります． vyos6宛に送信する経路情報からVM1を含む経路がフィルターされていることがわかります．


```
user@VyOS5# show | commands | grep bgp
set protocols bgp 65000 neighbor 192.168.2.34 remote-as '65000'
set protocols bgp 65000 neighbor 192.168.2.34 prefix-list export 'ictsc'
set protocols bgp 65000 neighbor 192.168.2.34 soft-reconfiguration 'inbound'

user@VyOS5# show | commands | grep ictsc
set policy prefix-list ictsc rule 1 action 'deny'
set policy prefix-list ictsc rule 1 prefix '192.168.2.64/28'

user@VyOS4# show | commands | grep bgp
set protocols bgp 65000 neighbor 192.168.2.50 remote-as '65000'
set protocols bgp 65000 neighbor 192.168.2.50 prefix-list export 'ictsc'
set protocols bgp 65000 neighbor 192.168.2.50 soft-reconfiguration 'inbound'

user@VyOS4# show | commands | grep ictsc
set policy prefix-list ictsc rule 1 action 'deny'
set policy prefix-list ictsc rule 1 prefix '192.168.2.64/28'
```


#### ソリューション②： vyos4/5から経路フィルターを消す．
以下のコマンドを実行し，vyos4/5が行っていた経路フィルターを除去します．

```
## vyos4で以下のコマンドを実行
user@VyOS4# delete protocols bgp 65000 neighbor 192.168.2.50 prefix-list export 'ictsc'
[edit]
user@VyOS4# commit

## vyos5で以下のコマンドを実行

user@VyOS5# delete protocols bgp 65000 neighbor 192.168.2.34 prefix-list export 'ictsc'
[edit]
user@VyOS5# commit

```


次に，vyos6でBGPピアからの情報の更新(ROUTE-REFRESH)するコマンドを実行します．
```
user@VyOS6:~$ reset ip bgp 192.168.2.33
user@VyOS6:~$ reset ip bgp 192.168.2.49

```

最後にvyos6でAS65001からvyos4/5が受信した経路が広告されていることを確認します．また，ルーティングテーブルにそれが反映されていることを確認します．
```

user@VyOS6:~$ show ip bgp
BGP table version is 0, local router ID is 192.168.2.34
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.2.0/28   0.0.0.0                  1         32768 i
* i192.168.2.32/28  192.168.2.33             1    100      0 i
*>                  0.0.0.0                  1         32768 i
* i192.168.2.48/28  192.168.2.49             1    100      0 i
*>                  0.0.0.0                  1         32768 i
* i192.168.2.64/28  192.168.2.129                 100      0 65001 i
*>i                 192.168.2.113                 100      0 65001 i
*>i192.168.2.80/28  192.168.2.129                 100      0 65001 i
* i                 192.168.2.113            1    100      0 65001 i
* i192.168.2.96/28  192.168.2.129            1    100      0 65001 i
*>i                 192.168.2.113                 100      0 65001 i
*>i192.168.2.112/28 192.168.2.33             1    100      0 i
*>i192.168.2.128/28 192.168.2.49             1    100      0 i

user@VyOS6:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

C>* 127.0.0.0/8 is directly connected, lo
O   192.168.2.0/28 [110/10] is directly connected, eth2, 16:02:44
C>* 192.168.2.0/28 is directly connected, eth2
O   192.168.2.32/28 [110/10] is directly connected, eth0, 16:02:44
C>* 192.168.2.32/28 is directly connected, eth0
O   192.168.2.48/28 [110/10] is directly connected, eth1, 16:02:44
C>* 192.168.2.48/28 is directly connected, eth1
B>* 192.168.2.64/28 [200/0] via 192.168.2.113 (recursive via 192.168.2.33), 00:17:00
B>* 192.168.2.80/28 [200/0] via 192.168.2.129 (recursive via 192.168.2.49), 00:00:35
B>* 192.168.2.96/28 [200/0] via 192.168.2.113 (recursive via 192.168.2.33), 00:17:00
B   192.168.2.112/28 [200/1] via 192.168.2.33, 00:17:00
O>* 192.168.2.112/28 [110/20] via 192.168.2.33, eth0, 16:00:47
B   192.168.2.128/28 [200/1] via 192.168.2.49, 00:00:35
O>* 192.168.2.128/28 [110/20] via 192.168.2.49, eth1, 16:00:45

```


#### 疎通確認

VM2からVM1宛にpingを送信します．正しく送受信出来ていることがわかります．

```
user@server:~$ ping 192.168.2.66 -c 1
PING 192.168.2.66 (192.168.2.66) 56(84) bytes of data.
64 bytes from 192.168.2.66: icmp_seq=1 ttl=60 time=1.88 ms

--- 192.168.2.66 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.885/1.885/1.885/0.000 ms

```

以上になります．ご確認のほど宜しくお願いします．

# 3:中二病でも繋げたい:skyline
### 問題概要
ルーティングでPPPoE：skyline
PPPoEをCSRでやって、Ubuntuからインターネッツにアクセス！！
### 解答

お世話になります．味処まるたかの豊田です．
「中二病でも繋げたい」に関して問題解決を行いましたのでご報告いたします．

#### ソリューション①: Dialer InterfaceにIPアドレスを設定
現状，PPPoE interfaceであるDialer1の設定は以下のようになっています．
今回は固定アドレス情報がISPから共有されているため，静的にアドレスを設定します．

```diff
interface Dialer1
+  ip address 202.226.6.133 255.255.255.254
-  no ip address
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 ppp authentication chap callin
 ppp chap hostname user@ictsc.net
 ppp chap password 7 15220716272526211C3C1C0127343551510409
!
```

その後， Dialer1アドレスを利用して外部への疎通性を確認します．これでPPPoEを利用してインターネットに疎通可能なことがわかりました．

```
client#ping 1.1.1.1 source Dialer 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 202.226.6.133
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 15/15/15 ms

```

#### ソリューション②: NAT設定

outbound interfaceとしてPPPoE Interfaceとして，ルータの物理IF(GigabitEthernet1)が指定されています．これをPPPoEの仮想IFに変更します．

```diff
- ip nat inside source list 1 interface GigabitEthernet1 overload
+ ip nat inside source list 1 interface Dialer1 overload

interface GigabitEthernet1
- ip nat outside
! 

interface Dialer1
+ ip nat outside
! 

```

#### ソリューション③: Dialer-listに適用させるトラフィックの指定
Dialer-list 1(本件で利用するPPPoEに関連するもの)に適用させるトラフィックを静的に指定します．ここではIPトラフィックを対象として定義します．

```diff 
+ dialer-list 1 protocol ip permit
```

#### ソリューション④: MTUとMSSに関連する最適化
PPPoEに利用する物理IF(GigabitEthernet1)のMTUが1500の場合， DialerIFのMTUは1492になります．
現状のままでも外部との通信は行なえますが， フラグメントが発生するため快適な通信が行えません．
以下の設定を投入します

```diff 
interface Dialer 1
+  ip tcp adjust-mss 1452
!

interface GigabitEthernet2
+ ip tcp adjust-mss 1452
!
```




#### 疎通確認
最後にUbuntuからインターネットへの疎通確認を行います．

はじめに，pingでの確認を行います．
```
user@ubuntu:~$ ping 1.1.1.1 -c 3
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=51 time=15.7 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=51 time=39.6 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=51 time=55.1 ms

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 15.776/36.870/55.176/16.206 ms

```

次によくある通信の例として，HTTPでの外部接続が行えることを確認します．

```
user@ubuntu:~$ curl https://www.google.com
<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="ja"><head><meta content="&#19990;&#30028;&#20013;&#12398;&#12354;&#12425;&#12422;&#12427;&#24773;&#22577;&#12434;&#26908;&#32034;&#12377;&#12427;&#12383;&#12417;&#12398;&#12484;&#12540;&#12523;&#12434;&#25552;&#20379;&#12375;&#12390;&#12356;&#12414;&#12377;&#12290;&#12373;&#12414;&#12374;&#12414;&#12394;&#26908;&#32034;&#27231;&#33021;&#12434;&#27963;&#29
######## 以下省略 ###########

```


そのため，以下のように設定を変更し，クライアントであるubuntuからのインターネットへのアクセスが正しく動くことを確認いたしました。
ご確認のほどよろしくお願い申し上げます。


## 手順
### 1.dialer-list 1 protocol ip permit を投入



## 4:SSHできなくなっちゃった2:skyline
### 問題概要
### 解答
お世話になっております。味処まるたかです。
この問題でToo many authentication failuresとエラーが表示されるので、複数の鍵情報を登録していて、順番に見ていき認証の制限回数を超えたことが原因でトラブルが発生したと考えられました。
つまり鍵の登録数が多すぎるとこのエラーが出てしまう。
そのため，以下のように設定を変更し，公開鍵認証を利用したssh接続が正しく動くことを確認いたしました。
確認のほどよろしくお願い申し上げます。

## 手順
### 1./home/user/.ssh以下の使用しないファイルを退避
known_hostsを参照すると今回使用するサーバのみが登録されているため他のものを退避する事で解消した．

### 1."ssh-add -L"で現在ssh-agentに登録されている公開鍵の一覧を表示
今回利用する公開鍵以外の鍵が多く表示されたため、これが原因である事が確認できた。

### 2.~/.ssh/configに以下の設定を投入

```
Host 192.168.19.20
    User user
    Hostname 192.168.19.20
    IdentityFile /home/user/.ssh/pluto.pub
    Protocol 2
    Port 22

identitiesOnly

```
### 3."ssh 192.168.19.20"コマンドを打って、パスワードを聞かれたらhogeでログインを確認
確認できた。


## 5:DM-VPNをつなげてください:yas-nyan
### 問題概要：DM-VPNをつなぎたい
### 解答

#### ソリューション①： MGREの設定
現状，Router-A, Router-D, Router-CのTunnelの設定は以下の点で誤りがあるので修正します．

- Tunnel IFのアドレス
    - オーバーレイとなるTunnel IFのアドレスは192.168.1.0/27のアドレスを利用します．
- Tunnel Source
    - 当該ルータがアンダーレイに利用するソースアドレスを指定します． ここでは，それぞれ192.168.1.65/27(Router-A), 192.168.1.67/27(Router-B), 192.168.1.98/27(Router-C)になります．

- NHRPの設定
    - NHRPを利用して，トンネル接続先アドレスの解決を行います．今回はRouter-AがNHSとなり，Router-DとRouter-CをNHCとなり相互に接続します．
    - その時IPsecを利用するため，IPsecパラメータも共通したものにする必要があります．


```diff
##### Router-A
interface Tunnel1
+ tunnel protection ipsec profile VPN
!

##### Router-D
interface Tunnel1
- tunnel source 192.168.1.3
+ tunnel source 192.168.1.67
+ tunnel protection ipsec profile VPN
!



##### Router-C

```diff
+crypto isakmp policy 1
+ encr aes 256
+ hash sha512
+ authentication pre-share
+ group 2
+ lifetime 21600
+crypto isakmp key hoge address 0.0.0.0
+crypto isakmp keepalive 30
!
!
+crypto ipsec transform-set IPSEC esp-aes esp-sha512-hmac
+ mode transport
!
+crypto ipsec profile VPN
+ set transform-set IPSEC
!


interface Tunnel1
- ip address 192.168.1.1 255.255.255.224
+ ip address 192.168.1.2 255.255.255.224
+ ip nhrp map 192.168.1.1 192.168.1.65
+ ip nhrp map multicast 192.168.1.65
+ ip nhrp network-id 1
+ ip nhrp nhs 192.168.1.1
+ tunnel protection ipsec profile VPN
end
```


本設定を行うことで，Router-AとRouter-D，及びRouter-AとRouter-C間でTunnelが確立出来ました．

以下のコマンドを用いてRouter-C/Router-Dでトンネルの確立を確認しました．以下がRouter-Cで確認した内容です．

```
Router-C#show tunnel endpoints
 Tunnel1 running in multi-GRE/IP mode

 Endpoint transport 192.168.1.65 Refcount 4 Base 0x7F2D76324AF8 Create Time 01:07:54
   overlay 192.168.1.1 Refcount 2 Parent 0x7F2D76324AF8 Create Time 01:07:54
   Tunnel Subblocks:
      tunnel-nhrp-sb:
         NHRP subblock has 1 entries
   overlay 192.168.1.3 Refcount 2 Parent 0x7F2D76324AF8 Create Time 00:02:36
   Tunnel Subblocks:
      tunnel-nhrp-sb:
         NHRP subblock has 1 entries

```

以下はRouter-DのトンネルIFからRouter-AのトンネルIF宛のpingを，行った結果になります．
```
Router-D#ping 192.168.1.1 source tunnel1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.3
!!!!!

```
また，以下はRouter-CのトンネルIFからRouter-AのトンネルIF宛のpingを，行った結果になります．

```
Router-C#ping 192.168.1.1 source tunnel1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

```
最後に，Router-DからとRouter-CにトンネルIF宛に行ったpingの結果です．
```
Router-D#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

```





#### ソリューション②： OSPFの設定
Router-AとRouter-DでOSPFによる経路交換を行えるように設定します．
> また、Router-Dの配下にはネットワークが追加される可能性があるので、Router-DはOSPFで経路を広報してください。

Router-Dに以下のような設定を投入します．今回，OSPFネットワークのDRはハブ・ルータであるRouter-Aに，Router-Dのpriorityを0にします．

```diff
#### Router-A
router ospf 1
+ network 192.168.1.0 0.0.0.31 area 0
!


#### Router-D
interface Tunnel1 
+ ip ospf priority 0 
+ ip ospf network broadcast

router ospf 1
+ network 192.168.1.0 0.0.0.31 area 0
!

```
以上の設定を投入することでRouter-AとRouter-D間でOSPFのネイバー関係が確立出来ました．

```
Router-A#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.1.161     0   FULL/DROTHER    00:00:39    192.168.1.3     Tunnel1

Router-D#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.1.65      1   FULL/DR         00:00:32    192.168.1.1     Tunnel1

```

加えて，後述するように，Router-C配下のServerも他のServerと疎通する必要があります． Router-CとRouter-Aの間でもネイバー関係を確立出来るように，Router-CにもRouter-Dと同様のOSPFの設定を投入します．

```diff
#### Router-C
interface Tunnel1 
+ ip ospf priority 0 
+ ip ospf network broadcast
+ ip ospf mtu-ignore
!

router ospf 1
+ network 192.168.1.0 0.0.0.31 area 0
!
```

これによりRouter-CとRouter-Aの間でのOSPFネイバー関係が確立されました．

```
Router-C#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.1.65      1   FULL/DR         00:00:34    192.168.1.1     Tunnel1

```




#### ソリューション③： OSPFで配下のネットワークを広告する

次に，Router-D配下のserver-3が接続されているネットワークをOSPFで広告する設定を投入します．このとき，このネットワークを利用して他にOSPFネイバーを接続する必要はないため，passive-interfaceにします．

```diff
#### Router-D

router ospf 1
+ network 192.168.1.161 0.0.0.31 area 0 
+ passive-interface GigabitEthernet2
!

```
以上の設定を投入することで，Router-Aから，server-3が接続されているネットワーク宛の経路情報をOSPFを介して受信することが出来ました．

```
Router-A#show ip route ospf
<----------省略-------- >
      192.168.1.0/24 is variably subnetted, 7 subnets, 2 masks
O        192.168.1.160/27 [110/1001] via 192.168.1.3, 00:00:56, Tunnel1

```

また，本案件では各Router配下のサーバー群が疎通可能であることが求められています．そのため，例えばServer-3がServer-1に疎通するためには，Router-DがServer-1宛の経路を把握している必要があります．
本ソリューションではRouter-A,Router-DにおいてもOSPFを利用して，配下のServerが所属するネットワークの経路を広告します．

以下の設定を投入します．

```diff
#### Router-A
router ospf 1
+ network 192.168.1.32 0.0.0.31 area 0 
+ passive-interface GigabitEthernet1
!
#### Router-D
router ospf 1
+ network 192.168.1.128 0.0.0.31 area 0 
+ passive-interface GigabitEthernet2
!

```

これによりRouter-AからRouter-CとRouter-D配下のネットワーク宛の経路情報がOSPF経由で受信出来るようになりました．
```
Router-A#show ip route | include O
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
O        192.168.1.128/27 [110/1001] via 192.168.1.2, 00:06:11, Tunnel1
O        192.168.1.160/27 [110/1001] via 192.168.1.3, 00:18:41, Tunnel1

```






#### 終了状態要件の確認：
以上の結果をまとめて以下に記述します．

##### Router-DがRouter-AとDM-VPNで接続している
ソリューション①で完了を確認しました．
##### Router-CがRouter-AとDM-VPNで接続している
ソリューション①で完了を確認しました．

##### Router-DとRouter-AがVPNを通してOSPFで経路交換をしている
ソリューション②，③で完了を確認しました．

##### 全てのServer同士がVPNを通して通信できる
下記検証作業で完了を確認しました．
###### Server-1: Server-2,Server-3へping
```
###### Server-2宛
user@Server1:~$ ping 192.168.1.130 -c 1
PING 192.168.1.130 (192.168.1.130) 56(84) bytes of data.
64 bytes from 192.168.1.130: icmp_seq=1 ttl=62 time=9.62 ms

--- 192.168.1.130 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.625/9.625/9.625/0.000 ms

##### Server-3宛
user@Server1:~$ ping 192.168.1.162 -c 1
PING 192.168.1.162 (192.168.1.162) 56(84) bytes of data.
64 bytes from 192.168.1.162: icmp_seq=1 ttl=62 time=1.98 ms

--- 192.168.1.162 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.987/1.987/1.987/0.000 ms

```
###### Server-2: Server-1,Server-3へping

```
###### Server-1宛

user@Server2:~$ ping 192.168.1.33 -c 1
PING 192.168.1.33 (192.168.1.33) 56(84) bytes of data.
64 bytes from 192.168.1.33: icmp_seq=1 ttl=62 time=2.13 ms


###### Server-3宛
user@Server2:~$ ping 192.168.1.162 -c 1
PING 192.168.1.162 (192.168.1.162) 56(84) bytes of data.
64 bytes from 192.168.1.162: icmp_seq=1 ttl=61 time=3.19 ms

```

###### Server-3: Server-1,Server-2へping
```
###### Server-1宛

user@Server3:~$ ping 192.168.1.33 -c 1
PING 192.168.1.33 (192.168.1.33) 56(84) bytes of data.
64 bytes from 192.168.1.33: icmp_seq=1 ttl=62 time=1.68 ms


###### Server-2宛
user@Server3:~$ ping 192.168.1.130 -c 1
PING 192.168.1.130 (192.168.1.130) 56(84) bytes of data.
64 bytes from 192.168.1.130: icmp_seq=1 ttl=61 time=12.3 ms

```

##### Router-AとRouter-Bの既存の設定を上書きする変更もしくは削除していない
上記において、Router-AとRouter-Bに対して既存設定の上書き・変更・削除は行っていません。

#### 解説： DM-VPNでNAT越しにVPNが構築できる方法・理由について
通常、IPSecでは、通常NAPTを使用する場合にVPNを構築することはできません。
IPSecでは、暗号技術としてESPを用いて暗号化を行い、IKEで鍵交換を行って定期的に使用する公開鍵を変更しています。鍵交換にはUDPポート500を用います。
本来、ESPパケットの送信元アドレスは、NAPTによって変換されてしまうため、NATを行う機器がESPパケットのNAPT処理ができないと、そこで処理が失敗し通信が終了してしまう。

このような状況下においては、IPSecの拡張技術であるNATトラバーサルを用いることにより、NAT/NAPTが使用されるネットワーク環境においてもIPsec通信を問題なく実現する事ができています。
これは、ESPパケット全体ををUDPでカプセル化するものである。この付加されたUDPヘッダは暗号化の対象とならない事から、NAPT機器でポート番号の書き換えを可能にしています。




## 6: 世は大コンテナ時代!!!:kamekame

### 問題概要
https://hackmd.io/Xv032smKT6SaPNZuVUs73A
### 解答

## 7
### 問題概要
dockerで動作しているmariadbが動作しない。
docker imageを修復して、mariadbが正常に動作するようにする。

### 解答

お世話になっております。味処まるたか亀井です。
この問題ではmariaDBを起動するユーザが原因でトラブルが発生したと考えられました。
デフォルトではmariaDBはmysqlユーザでしか起動できないため、環境変数でmariaDBを作成するユーザにrootを指定してmariaDBを起動するようにしました。過去に作成していたdockerは一度、削除しましたが、docker volumeを利用していたため、データは永続化されています。
また、dockerの-pオプションでコンテナとホストのポートをオープンしました。
コンテナの削除・作成コマンドは以下の通りです。
```
$ docker rm mariaDB
$ docker run -v mariaVOL:/var/lib/mysql -e MYSQL_USER=root -p 3306:3306 -it mariadb 
```

以上、よろしくお願いします。



## 8: メールを送りたい!(1)：alt
### 問題概要
メールサーバ間の通信にISPがかんでおりOB25Bが実施されている
### 解答
お世話になっております。味処まるたかです。

今回の問題はOB25Bにより25番ポートでのSMTP通信ができないことが原因でメールが送れない状態になっていました。
clientとusermxの間の通信はISPを通っており、ISPでスパムメール対策のためにOB25Bを実施していると思われます。
OB25Bが実施されていると予測した根拠は、
1. clientからusermxの25番ポートにtelnetを行い接続できなかった(無応答)こと
2. clientから`mtr usermx.team03.final.ictsc.net`を実施したところ、下記のとおり外部IPアドレスを経由していたこと
```
1. 192.168.3.1                                                                                          0.0%     4    0.3   0.3   0.2   0.5   0.0
 2. 103.202.216.18                                                                                       0.0%     4    0.6   0.6   0.6   0.7   0.0
 3. 103.202.216.18                                                                                       0.0%     3    0.7   0.6   0.5   0.8   0.0
 4. 103.202.216.19                                                                                       0.0%     3    0.9   0.8   0.6   0.9   0.0
 5. ???
 6. ???
 7. 202.226.6.17                                                                                         0.0%     3    1.3   1.2   1.1   1.3   0.0
```
3. client, usermx双方のiptablesなどファイアウォールルールでSMTPの通信を阻害する設定がなかったこと
です。
## 9: メールを送りたい!(2):alt・kamekame
### 問題概要
問題8について、clientからictsscmxサーバのsubmission portにリレーしusermxにメールを送信するような設定をclientに書く
### 解答

お世話になっております。味処まるたかです。
以下のsmtpに関する設定をclientの/etc/postfix/main.cfに追記後postfixをreloadし、メールがusermxで受信可能なことを確認いたしました。
```
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = static:ictsc:ictsc
smtp_sasl_security_options = noanonymous
relayhost = ictscmx.final.ictsc.net:587
```

確認に利用したメールの送信コマンドには、以下のコマンドを利用しました。
```
$ echo "メール本文" | sendmail user@usermx.team03.final.ictsc.net
```

以上、よろしくお願いいたします。

## 10:適当に俳句投稿サービス作ったらXSRF脆弱性孕んでた件。:takanori
### 問題概要
### 解答
- goはいってねえ
```
sudo snap install go --classic
```
- とりあえず動かす
```
sudo make d/up
```

- sign upしようとするとクラッシュする
```
hike_app | [GIN] 2020/02/29 - 02:47:06 | 200 |    2.553403ms |     192.168.0.1 | GET      /signup
hike_app | [GIN] 2020/02/29 - 02:47:06 | 302 |      96.124µs |     192.168.0.1 | GET      /favicon.ico
hike_app | [GIN] 2020/02/29 - 02:47:07 | 200 |     1.49174ms |     192.168.0.1 | GET      /
hike_app | 2020/02/29 02:47:15 dial tcp: lookup hike_db on 127.0.0.11:53: no such host
hike_app | exit status 1
```
- dbが死んでる
```
hike_db | 2020-02-29 12:05:36+09:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.19-1debian9 started.
shike_db | 2020-02-29 12:05:36+09:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
hike_db | 2020-02-29 12:05:36+09:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.19-1debian9 started.
tat- hike_db | 2020-02-29T03:05:36.816515Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
hike_db | 2020-02-29T03:05:36.819139Z 0 [Warning] [MY-010101] [Server] Insecure configuration for --secure-file-priv: Location is accessible to all OS users. Consider choosing a different directory.
hike_db | 2020-02-29T03:05:36.819241Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.19) starting as process 1
lntphike_db | 2020-02-29T03:05:37.461616Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
hike_db | 2020-02-29T03:05:37.465506Z 0 [Warning] [MY-011810] [Server] Insecure configuration for --pid-file: Location '/var/run/mysqld' in the path is accessible to all OS users. Consider choosing a different directory.
hike_db | 2020-02-29T03:05:37.470605Z 0 [ERROR] [MY-000067] [Server] unknown variable 'aracter-set-server=utf8'.
hike_db | 2020-02-29T03:05:37.471739Z 0 [ERROR] [MY-010119] [Server] Aborting
hike_db | 2020-02-29T03:05:38.450609Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.19)  MySQL Community Server - GPL.
```

- 変なイメージになっていたためpullする
```
docker pull mysql:8.0

```
- エラーが変わったやったね
```
hike_app | [GIN] 2020/02/29 - 03:10:15 | 200 |    1.745039ms |     192.168.0.1 | GET      /
hike_app | 2020/02/29 03:10:17 Error 1049: Unknown database 'hike'
hike_app | exit status 1
```
```
user@server:~/ictsc2019-f21-xsrf$ sudo make d/up
Building app
Step 1/10 : FROM golang:1.12.6-alpine3.9
 ---> e04879bf1b7f
Step 2/10 : RUN apk add --update --no-cache ca-certificates git
 ---> Using cache
 ---> 4f6b51dad5ee
Step 3/10 : RUN mkdir /go-app
 ---> Using cache
 ---> a3e55086e022
Step 4/10 : WORKDIR /go-app
 ---> Using cache
 ---> 10756cc3c785
Step 5/10 : COPY go.mod .
 ---> Using cache
 ---> ef7e5072b699
Step 6/10 : COPY go.sum .
 ---> Using cache
 ---> 9c206bc1268f
Step 7/10 : RUN go mod download
 ---> Using cache
 ---> ca6c8731c8ed
Step 8/10 : COPY . .
 ---> Using cache
 ---> 15a91b8633ff
Step 9/10 : RUN CGO_ENABLED=0
 ---> Using cache
 ---> b674d13d4e4b
Step 10/10 : CMD go run server.go
 ---> Using cache
 ---> 5dc7624aed21

Successfully built 5dc7624aed21
Successfully tagged ictsc2019-f21-xsrf_app:latest
Starting hike_db ... done
Starting hike_app ... done
user@server:~/ictsc2019-f21-xsrf$ sudo make migrate/init
make[1]: Entering directory '/home/user/ictsc2019-f21-xsrf/db'
mysql -u root -h 127.0.0.1 -P 3306 --protocol tcp -e "create database \`hike\`" -p
Enter password:
make[1]: Leaving directory '/home/user/ictsc2019-f21-xsrf/db'
user@server:~/ictsc2019-f21-xsrf$ sudo make migrate/up
make[1]: Entering directory '/home/user/ictsc2019-f21-xsrf/db'
make[2]: Entering directory '/home/user/ictsc2019-f21-xsrf/db'
1/u ct_users (97.049399ms)
2/u ct_hikes (147.445325ms)
3/u ct_mos (201.996111ms)
4/u add_u (242.353714ms)
5/u add_h (336.904762ms)
make[2]: Leaving directory '/home/user/ictsc2019-f21-xsrf/db'
make[1]: Leaving directory '/home/user/ictsc2019-f21-xsrf/db'

```
https://gitlab.com/ictsc2019-team3/ictsc2019-f21-xsrf/-/merge_requests/1
- とりあえず動いた1

# 解答テンプレート
お世話になっております。味処まるたかです。
この問題ではXXXXXが原因でトラブルが発生したと考えられました。
そのため，以下のように設定を変更し，XXが正しく動くことを確認いたしました。
確認のほどよろしくお願い申し上げます。

## 手順
### 1./etc/hoge/hoo.barの編集