UEFI + GPT 環境でのデュアルブート(Windows 10 & Ubuntu16.04)
ここしばらく、Linuxをメインで使えるマシンがほしいなと思いながらいたのですが、ようやくデュアルブートに成功したので、その時のメモです。
ポイントとしては、
①インストールメディアをUEFIで起動する
②ブートローダをインストールする位置
の2点です。
ここを参考にしました。↓
・ 手順
- リカバリ
- パーティションの切り分け
- Windows 10 へアップグレード
- Ubuntu のインストールメディアの作成
- Ubuntu の起動
- Ubuntu のインストール
以上です。
かいつまんで、ポイントだけ。
1. 一度デュアルブートに失敗し、WindowsもUbunutu も起動しなくなったためにこれをする必要がありました。買ってすぐのPCでも、リカバリ用」のディスクなどはちゃんと用意しておきましょう。ちなみに私のPCは工場出荷状態ではWindows 7です。
2. パーティションは先にUbuntu をインストールする分を空けておく。Windowsでディスクの縮小をして、ハードディスクに空きの容量を確保しておきます。
3. 一度アップグレードしていたので、リカバリしても再度アップグレードができます。Windows 10のアップグレードですが、やるならUbuntu をインストールする前のほうが確実かと思います。Windows 10 はアップデートの際にリカバリ用のパーティションを作るそうで、それが原因でUbuntu が起動しなくなるというトラブルが起こり得るようです。回避方法や復旧方法もあるでしょうが、先にアップグレードはしておいたほうが無難かと思います。
4. ISOファイル( Ubuntuの入手 | Ubuntu Japanese Team )をダウンロードして、DVDなら適当なソフトで焼く。あるいはUSBにインストール。私は UNetbootin を使ってその辺に転がってた2GのUSBメモリにインストールしました。Ubuntuなら2Gでもぎりぎり入ります。
5. まず、Windows 10の「高速スタートアップ」を無効にしましょう。これをしないと、BIOSやブートデバイスの切り替えができません。
コントロールパネル
⇒ 電源オプション
⇒「電源ボタンの動作を選択する」
⇒「現在利用可能ではない設定を変更します」
⇒「高速スタートアップを有効にする」のチェックボックスを外す
⇒ 変更の保存
再起動して、ブート時に何かしらのキーを押してブートデバイスを選択します。
ここで、最初のポイントです。UEFI環境で外部デバイスからOSを起動しようとすると、起動するデバイスの選択肢が2つ現れます。
私の場合「UEFI : USB Reader」と「USB Reader」のような感じでした。ここでUEFIではないほうを選んでしまうと、場合によっては Windows も Ubuntu も起動しなくなります。UEFIからメディアを起動すると、Ubunut の場合、黒いGRUBのブートメニューが表示されます。
UbuntuTips/Install/UEFI - Ubuntu Japanese Wiki
Liveイメージで起動時にCUI画面で白文字のgrubメニューが現れる。(UEFIモードで起動している)
Liveイメージで起動時に紫のスプラッシュ画面で起動し、GUIとインストーラーが立ち上がる。(Legacyモードで起動している)
ちゃんとUEFIで起動していることを確認しましょう。
6. 最後にUbuntu のインストールです。普通にOSをインストールする手順通りです。「インストールの種類」で「それ以外」を選択し、パーティションをカスタマイズします。と言っても、2で開けておいたスペースにインストールするだけです。私は適宜「/」、「/boot」「/home」などにお好みで振り分けてください。
ここで重要なポイントはブートローダの位置です。デフォルトではディスクの先頭(「/dev/sda」など)が選択されていますが、これを、EFIタイプのパーティションの位置に変更します。(私の場合「/dev/sda1」。)
あらかじめ、GPartedでパーティションを確認すると「EFI System Partition」とラベルがついていました。あまり詳しくは知りません。
PCハードウェア強化ラボ:第4回 2Tbytes超ディスクをシステム用ディスクとして利用する (3/3) - @IT
先頭に「EFI システム パーティション」という100Mbytesのパーティションがあるが、これはGPT形式のディスクにおいて、ブート・コードを保存しておく場所である。
だ、そうです。
多くのデュアルブートの説明では「/boot」のパーティションに一緒にブートローダをインストールし、起動後MBRからそのパーティションを呼び出し、ブートメニューを開くような設定になっているようなのですが、GPTではそれができないため、今回の方法を取ることになりました。
私の環境では以上でデュアルブート環境が出来上がりました。
起動するとGRUBが立ち上がり、Ubuntu と Windows 10 が選択できるようになっています。(今のところ両OS問題なく動いています)
場合によっては参考に挙げたサイトで行っているような Boot Repair を使った修復作業などが必要になることもあるようです。
以上、個人的に一つ、悲願を達成できたので、メモとして残しました。デュアルブートは私のような「UEFI? GPT? 何それ、おいしいの?」というレベルの人は行わないほうがいいかと思います。
今は仮想化などの技術も進んでますし、「Windows Subsystem for Linux」なども出てきましたしね。まあ、一昔前の壊れてもいいやPCでハードディスク容量も余ってたので。
以上です。
cowrieでssh・telnetのハニーポット運用
ハニーポッター 第一弾
とりあえずSSHハニーポットのcowrieを立ててみました。
↓こいつです。
cowrieはコヤスガイという意味だそうです。Google先生が言ってました。
環境としては、Windows10のノートPCにVirualboxでCentOS 7をインストールし、その上のDocker上のCentOS 6でcowrieを動かしています。
低対話型のハニーポットを動かすのに、わざわざそこまで多重化する意味ないのでは、と思われるかもしれませんが、全くその通りです。
まあ、Dockerの操作の練習も兼ねてます。
インストールはそれほど難しくはありません。ググれば割と情報はあります。
↓この辺とか。
ハニーポットCowrieをCentOS7に入れてみた。 - Shioshishio
とりあえず、requrimentsをすべてインストールして、実行するだけのお手軽設計です。
少し詰まったのは、Docker上で動かしたContOSのイメージに入っていたのが、Python2.6だったことで、cowrieはPython2.7じゃないと動かないようです。まあ、何かしらの方法でアップデートすればいいんです。
最近telnetもサポートしたそうなので、せっかくですので、動かしてみます。設定ファイルをいじります。
# ============================================================================
# Telnet Specific Options
# ============================================================================
[telnet] # Enable Telnet support, disabled by default
enabled = true # IP addresses to listen for incoming Telnet connections.
#
# (default: 0.0.0.0) = any IPv4 address
#listen_addr = 0.0.0.0
# (use :: for listen to all IPv6 and IPv4 addresses)
#listen_addr = ::
# Port to listen for incoming Telnet connections.
#
# (default: 2223)
listen_port = 2223 # Source Port to report in logs (useful if you use iptables to forward ports to Cowrie)
reported_port = 23
これで起動すればsshはポート2222番、telnetはポート2223番で動いてくれます。
これをDockerのポートフォワードでそれぞれ22番、23番につなぎなおしました。
以上で、cowrieの起動は完了です。
この後、外からsshはつながるがtelnetがつながらないという事象が発生。なんだかんだ設定をごちゃごちゃいじってたら今はうまく動いてくれています(多分)。
確認した点としては、
- CentOS 7のfirewalld(デフォルトではsshは通すようになっている)
- WindowsのFirewall
- Windowsのほかプログラムが邪魔していないか
あたりですかね。結局何が問題だったかいまいちわかっていません。とりあえず、Windows 10はよくわからないものがいっぱい動いているので、サーバとか立てないほうがいいってことはよくわかりました。
とりあえずこれで動いてくれています。
2,3日動かしてみて、割と攻撃は来ています。ボット化するスクリプトを落として来たりとかですね。
ログがjsonで出てくるので、うまくパースして解析したいんですが、面倒くさい頑張ります。
面白い攻撃が来たら、(気が向いたら)ここにでも書きます。
追記・2016/0927
うまく動いてくれてると思っていたのですが、telnetの動作が怪しいです。ログを見ると、セッションを張ったログはあるのですが、その後の挙動がない……。
cowrieのtelnetはあまり情報がないので、どうすればいいか、ちょっとわからないです。
とりあえず試行錯誤してみます。sshは問題なさそうです。