わかったつもりになってない？

わかったつもり防止のために、日常で学んだことをもう少し深堀したいブログ

AWSで無料枠を利用し「Elastic IP」も全て解放済みのはずなのに料金が発生した件の原因と対応

AWS

先月からAWSを利用し、Linuxの勉強を行っているのですが、無料枠内の使用におさめているつもりが3月分の請求が3$程発生しました。

 

明細の詳細を見ると下記項目に料金が発生していたため調査したところ、EC2に紐づいていないElastic IPは解放しないと料金が発生してしまうとのこと。

 

$0.005 per Elastic IP address not attached to a running instance per hour (prorated)

 

この事象結構いろんな人が引っかかってるみたいです。

 

AWSで無料枠を利用していたつもりなのに請求が来ていた件 | Bamboo lath 日々の記録

【AWS学習記】無料枠なのに請求が発生してた。 - My Tracking

 

即座にElastic IPを開放し一安心と思っていたのですが、4月の請求にまたもや同様の項目に料金が発生していました。解放し忘れがあったかなと思い、EC2のダッシュボードを確認したがElastic IPの利用数は0。

 

f:id:gattsu09:20170428203436p:plain

 

＜原因と対応＞

結局いろいろ調べても同様の事態は見つからなかったので、AWSコンソール上でサポートに問い合わせたところ、以下回答がありました。

 

4月ご利用分に関しましては、 米国西部オレゴンリージョン（以下オレゴンリージョン）にお持ちのElastic IPアドレス(以下EIP)が 稼働中のインスタンスに紐付けられていないことが原因で料金が発生しておりました。 お送りいただきましたキャプチャ画像よりアジアパシフィック東京リージョンの EIPは解放済みであると存じますので、EIP料金の発生を停止いただくには、 以下手順で該当（オレゴンリージョン）EIPの解放をお願いいたします。

 

ダッシュボード上で確認できるのは、あくまで選択中のリージョン（自分の場合は東京リージョン）の利用状況が表示されるのみで、他リージョンでサービスを利用している場合はそのリージョンを選択しないと確認できない模様。（当たり前といえば当たり前ですが。。。）

 

AWSコンソール右上のリージョンからオレゴンリージョンを選択したところ、利用中のElastic IPを発見。そういや、最初のころは分からずにオレゴンリージョン利用してたなぁ。。。

 

f:id:gattsu09:20170428204016p:plain

 

あとはElestic IPの管理画面に移動し、解放。来月以降は料金発生しないはず。まぁ、少額だったし良い勉強料だったと思うことにします。

 

f:id:gattsu09:20170428204322p:plain

 

というわけで、なかなか無いかもしれませんが複数リージョンを利用している場合は、特に注意して利用しているサービスを管理する必要ありそうですね。

 

あと、正直無料で利用している身なのでAWSのサポートあまり期待していなかったのですが、迅速（Web上で問い合わせて１日後）で的確且つ丁寧な日本語で回答が来たことに驚きました。

 

サンキューAmazon。

DNSサーバの種類と特性

LPIC202 DNS

ども、前の記事が書きかけですが、別の記事を書いていきます。

 

AWS触ってLinuxの勉強するにあたり、基礎知識の再学習と並行してLPIC Level2の資格勉強も行っていたりします。で、資格範囲にDNS（主にBIND）の設定が含まれているのですが、学ぶ前に各種DNSソフトウェアについてザックリとどのような物があって特性は何なのかを調べたので自分用にメモしておきます。

 

 

djbdns

・D.J.Bernsteinさんが作ったDNSソフトウェアだからdjbdns。

・キャッシュサーバの機能を担うデーモンと、コンテンツサーバとしての機能を担うデーモンとに分かれている。
（BINDでは両機能はnamedデーモンが担っている。）
・BINDと比較し設定が用意で安全とされている。
・パッケージは　http://cr.yp.to/djbdns/install.html　から入手可能。

＜参考＞
http://cr.yp.to/djbdns.html　（公式）
http://djbdns.qmail.jp/
https://ja.wikipedia.org/wiki/Djbdns
http://www.asahi-net.or.jp/~AA4T-NNGK/djbdns.html

 

PowerDNS

・オランダ企業の「PowerDNS.COM BV」が中心の開発コミュニティに生み出された。

・djbdnsと同様、キャッシュサーバと、コンテンツサーバのプロセスが分かれている。
・MySQLやOracle等のRDBをバックエンドデータベースとして使用できる。
・BINDと比較し設定が用意で安全で高機能とされている。
・yumコマンドで「pdns」を指定することでインストール可能。

＜参考＞
https://www.designet.co.jp/faq/term/?id=UG93ZXJETlM
http://takuya-1st.hatenablog.jp/entry/2016/07/14/202554

 

dnsmasq

・simon kelleyさんが作ったDNSソフトウェア。

・DNSキャッシュサーバ、およびDHCPサーバの機能をもつソフトウェア。
・単体ではDNSコンテンツサーバとしては使えない。
・軽量で設定が容易。
・小規模なネットワークでの使用を想定して作られている。
・yumコマンドで「dnsmasq」を指定することでインストール可能。

＜参考＞
https://wiki.archlinuxjp.org/index.php/Dnsmasq
http://server.etutsplus.com/dnsmasq-setup-internal-dns/

 

BIND

・Paul Vixieさんが作ったDNSソフトウェア。

・世界でもっとも利用されている。
・そのため、他DNSソフトウェアから色々比較の槍玉にあげられている。
・LPIC 202ではBINDの設定が試験範囲。
・yumコマンドで「bind」を指定することでインストール可能。

＜参考＞
https://ja.wikipedia.org/wiki/BIND

 

他にもいろいろあるんでしょうか。とりあえずこの辺で。

AWSにおけるある程度セキュリティ強度の強いサーバの構築について

AWS Security

というわけで、AWSでサーバを立てて、まずはユーザ認証周りのセキュリティについて学んでいきたいと思います。標準的なLinuxの設定について触りたいので、AWS特有のセキュリティ機能(IAMやVPC)については今後にまわします。

 

とりあえず、パッと思いつくユーザ認証のセキュリティ周りは以下くらいかなと思うので、実際に手を動かして設定していきます。

１．root直ログイン禁止／パスワードログイン禁止

rootユーザというのは、WindowsにおけるAdministratorみたいなもの（当然いろいろ違う）で、いわゆる何でもできてしまうユーザです。仮に悪意のある第三者にこのユーザを乗っ取られると詰みます。将棋でいうところの王にあたり、何が何でも死守する必要があります。

 

そのため、rootユーザの直接なログインは禁止してしまって、rootユーザ権限が必要な場合は、後述する「sudo」や「su」コマンドで間接的に使用するのが一般的です。

 

あと、パスワードログインを許可していると総当たり攻撃というパスワード解読攻撃の的になるため禁止し、後述する公開鍵認証によりログインするのが一般的です。総当たり攻撃、英語で言うとブルートフォースアタックと言うらしいです。ロボアニメとかの必殺技っぽいですね。

 

尚、AWSはデフォルト（初期設定）でrootユーザへの直ログインとパスワードログインは禁止されているので、今回はその設定をわざわざ解除したり、再度設定したりしてみます。

 

AWSを利用するまでの手順とかはまた今度書きたいと思います。結構公式ヘルプがしっかりしていて、登録からEC2インスタンス作成・ログインまで1時間もかかりませんでした。すごい時代ですね。余談ですが、AWSへの登録にはクレジットカードが必要になります。持ってない学生さんとかはVプリカとかを利用しましょう。今のところ(2017/4/16現在)Vプリカで登録可能みたいです。

 

前置きが長くなりましたが、EC2インスタンス(仮想サーバ)を作成しteratermというツールで自分のPCからログインしました。初期ログイン可能なユーザは「ec2-user」となります。

 

f:id:gattsu09:20170416181626p:plain

 

SSHログインの設定は「/etc/ssh/sshd_config」ファイルが担っているので、こちらの設定を以下の通りに変更していきます。

 

＜sshd_config変更前＞
　PermitRootLogin forced-commands-only

　　⇒特定のコマンド実行時のみrootへのログインを許可
　PasswordAuthentication no

　　⇒パスワードログインを禁止

 

＜sshd_config変更後＞

　PermitRootLogin yes

　　⇒rootへのログインを許可

　PasswordAuthentication yes

　　⇒パスワードログインを許可

 

 ＜実行コマンド＞

①．sshd_configをバックアップしviエディタで編集

$ cd /etc/ssh
$ sudo cp -ip sshd_config sshd_config.20170416
$ sudo vi sshd_config 

 ②．編集結果をdiffコマンドで確認

$ diff sshd_config sshd_config.20170416
51c51
< PermitRootLogin yes
---
> PermitRootLogin forced-commands-only
82c82
< PasswordAuthentication yes
---
> PasswordAuthentication no
158c158
< # ForceCommand cvs server
---
> # ForceCommand cvs server
No newline at end of file

 ③．sshdを再起動

sudo /etc/init.d/sshd restart
Stopping sshd: [ OK ]
Starting sshd: [ OK ]

 ④．rootユーザのパスワードを適当に変更

$ sudo passwd root
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully. 

 

再度teratarmで今度はrootユーザでパスワードを入力しログインしたところ、正常にログインできました。セキュリティ強度がグンと下がったことになります。やりましたね！

f:id:gattsu09:20170416182502p:plain

 

怖いので、バックアップを戻して再度sshdを再起動します。 

$ sudo mv sshd_config.20170416 sshd_config
$ sudo /etc/init.d/sshd restart
Stopping sshd: [ OK ]
Starting sshd: [ OK ]

 

f:id:gattsu09:20170416184112p:plain

再度rootで同様にパスワードログインを試みたところ、上記エラーがにより失敗しました。よかったですね。

 

 

２．SSHによる公開鍵認証ログイン設定

引き続き、SSHによる公開鍵認証のログイン方法について学んでいきます。１つめの項目で該当サーバへのパスワードログイン禁止方法について書きましたが、ではどうやってログインするかというと公開鍵認証という方式をつかって、事前に作成・配布した鍵を持っているユーザ（PC）からのみログインを許可してあげます。

 

AWSはEC2インスタンス作成時、その鍵が生成され自動でダウンロードされ、初期ユーザであるec2-userはその鍵を使ってログインすることができます。

 

今回はEC2インスタンス作成・ログイン後、Linuxサーバ内でコマンド実行により、SSH鍵生成・配布し、その鍵を使ってログインできるか試していこうと思います。

 

とりあえず、１と同様にec2-userでログインし、ホームディレクトリ「/home/ec2-user」配下に「.ssh」ディレクトリが存在することを確認します。

 

$ ls -l .ssh
total 4
-rw------- 1 ec2-user ec2-user 388 May 1 10:58 authorized_keys

 

ec2-userは既にSSHの鍵設定が行われているので「.ssh」ディレクトリが存在します。新規ユーザ等で存在しない場合は作成しましょう。

 

「.ssh」ディレクトリが存在するので、次に「ssh-keygen」コマンドを使用して、SSH鍵を作成します。

 

$ ssh-keygen -t rsa　　　←鍵タイプに「rsa」を指定
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ec2-user/.ssh/id_rsa):　←「Enter」
Enter passphrase (empty for no passphrase):　←「パスフレーズを入力」（今回は省略）
Enter same passphrase again:　←「パスフレーズを入力」（今回は省略）
Your identification has been saved in /home/ec2-user/.ssh/id_rsa.
Your public key has been saved in /home/ec2-user/.ssh/id_rsa.pub.
The key fingerprint is:
2c:8d:29:ef:ee:9b:ee:0c:e2:0f:fb:cb:9f:85:4c:d9 ec2-user@ip-172-31-31-51
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
| B |
| . * E |
| = o |
| o . + . |
| . = + + |
| oo=B%. |
+-----------------+

 

すると、「.ssh」配下に、秘密鍵（id_rsa）と公開鍵（id_rsa.pub）の2ファイルが作成されます。接続する側は秘密鍵を使って対象のサーバに接続します。接続される側は、アクセスがあると公開鍵を使って認証を行います。細かくいうと長くなるので、どこかであらためてまとめたいと思います。

 

$ ls -l .ssh
total 12
-rw------- 1 ec2-user ec2-user 388 May 1 10:58 authorized_keys
-rw------- 1 ec2-user ec2-user 1679 May 1 11:07 id_rsa
-rw-r--r-- 1 ec2-user ec2-user 406 May 1 11:07 id_rsa.pub

 

続いて、公開鍵の情報を「authorized_keys」に格納します。先述したとおり、「ec2-user」はすでにSSH鍵設定済みなので、すでに「authorized_keys」ファイルが存在します。その場合は、以下の通りに公開鍵情報を追記します。

 

$ cd .ssh

$ cat id_rsa.pub >> authorized_keys 

 

既存の情報を消したりすると、先ほどまでログインできた既存の秘密鍵でもログインできなくなるので注意が必要です。

 

ちなみに「authorized_keys」が既に存在する場合は、以下の通りに設定します。

 権限までしっかり設定してあげないとログインできません。

 

$ cd .ssh

$ mv id_rsa.pub authorized_keys

$ chmod 600 authorized_keys

 

公開鍵の設定は済んだので、接続する端末（この場合自分のPC）に秘密鍵を転送します。今回はteratermのSCP機能を使って転送しました。

 

[ファイル]-[SSH SCP]を選択

f:id:gattsu09:20170501205007p:plain

 

下枠の「From」に秘密鍵をフルパスで記入。取得先に任意のフォルダを指定し、[Receive]ボタンをクリック。

f:id:gattsu09:20170501205036p:plain

 

指定したフォルダに「id_rsa」ファイルが存在することを確認します。その後、再度teratermを起動し、「ec2-user」ユーザを入力し、今回転送した秘密鍵を選択し[OK]ボタンをクリック。

f:id:gattsu09:20170501205233p:plain

 

無事ログインできました。エラーになる場合は権限設定などを見直しましょう。

f:id:gattsu09:20170501205343p:plain

 

公開鍵認証ログインの設定は以上です。余談ですが、SSH鍵はLinuxサーバ内だけでなくクライアント側でも作ることができます。

 

teratermの場合[設定]-[SSH鍵の設定から作成可能で、その場合は逆に公開鍵を接続先のサーバに配布し、同様に「authorized_keys」に公開鍵情報を登録すると、作成した秘密鍵で接続可能になります。どちらかというと、クライアント側で鍵を生成した方がセキュリティ的には良いみたいですね。

 

f:id:gattsu09:20170501205750p:plain

 

というわけで、公開鍵認証によるログイン設定について書きました。細かい認証の流れとか勉強してると、すごく複雑に見えて（実際複雑）うんざりするのですが、とりあえず動かしてみて、感じをつかんだ後に詳細について学ぶのも一つじゃないかなぁと思います。

 

３．SSH接続用のポート番号変更

ではSSH接続用のポート番号を変更していきます。

 

その前に、ポート番号とは何か？について自分自身のおさらいもかねて学んでいきたいと思います。軽くWebで調べたところ、個人的に以下の記事がしっくり分かりやすかったです。

 

ポート番号とは、TCP/IP通信において、 コンピュータが通信に使用するプログラムを識別するための番号です。
ポート番号は16ビットの整数であり、 0番～65535番まであります。

TCP/IP通信においては、 IPアドレスがあればネットワーク上のコンピュータを一意に識別することができますが、 該当コンピュータのどのプログラムに通信パケットを届けるかは、 IPアドレスだけでは決定できません。 どのプログラムに通信パケットを渡すのかを決定するために、 ポート番号を使用します。

 

引用元：日本ネットワークインフォーメーションセンター

 

IPアドレスは、よく住所にたとえられる（アドレスっていうくらいだし）のですが、PCやサーバが「家」でIPアドレスが「住所」だとすると、ポート番号は「郵便ポストの番号」というのが個人的にはしっくりくる例えになります。ただ、この郵便ポストめちゃくちゃ数が多く65536個(0～65535)あります。

 

送り元は手紙（データ）を送る際、どの住所（IPアドレス）のどの郵便ポスト番号（ポート番号）に手紙（データ）を送るかを指定する必要があるわけです。

 

そして、データを受け取る側（PC、サーバ）は、例えば「22」番の郵便ポスト（ポート番号）からの（データ）しか受け取らない設定もできます。これによって、他の郵便ポスト番号（ポート番号）経由の手紙（データ）は不審な手紙（データ）として破棄できたりします。

 

また、ポート番号は0番～1023番まではよく使うポート番号として予約されています。その内、今回話の対象とするSSHは「22」番を使って通信するとあらかじめ決まっています。

 

ここからが本題です。ポート番号は規約を統一することによって他PCやサーバとの通信を容易にするという役割が強いのですが、上記にあげたように受け付けるポート番号を絞ることでセキュリティ強度を上げる役割があります。

 

ただ、SSHの通信はデフォルトでは「22」番を使うということは全世界に知れ渡っているため、悪意のある第３者から攻撃を受けた場合、デフォルトのままだと受け付けるポート番号を絞ったところで無意味となってしまいます。

 

というわけで、SSHが使用するポート番号をデフォルト「22」から別のポート番号変えることで、セキュリティ強度を増そうという狙いになります。少なくとも、とりあえずポート番号「22」に対して攻撃してくる輩を弾くことができます。

 

果てしなく前置きが長くなりましたが、具体的な設定方法について触りながら書いていきます。

 

①ログインしrootユーザにスイッチする

$ id
uid=500(ec2-user) gid=500(ec2-user) groups=500(ec2-user),10(wheel)
$
$ sudo -s
# id
uid=0(root) gid=0(root) groups=0(root)

 

②sshd_configファイルを編集する

# cd /etc/ssh

# cp -ip sshd_config sshd_config.20170502

# vi sshd_config

※ 「# Port 22」の「#」を外し数字部分を「12345」に変更

# diff sshd_config sshd_config.20170502

17c17
< Port 12345
---
> #Port 22
158c158
< # ForceCommand cvs server
---
> # ForceCommand cvs server 

 

③sshdを再起動する

 # /etc/init.d/sshd restart
Stopping sshd: [ OK ]
Starting sshd: [ OK ] 

 

④AWS上で通信許可のポート番号変更

AWSでは「セキュリティグループ」というサービスで上記に記載した、「受け付けるポート番号を絞る」等の設定がされており、デフォルトで「22」ポート番号の通信のみ許可するようになっています。そのため、許可するポート番号を「22」から「12345」に変更します。

 

[EC2ダッシュボード]-[インスタンス]にて対象のインスタンスを選択。下枠のセキュリティグループをクリック。

f:id:gattsu09:20170502195038p:plain

 

[インバウンド]タブを選択し、[編集]をクリック

f:id:gattsu09:20170502195059p:plain

 

タイプに「カスタムTCPルール」を選択し、ポート番号に「12345」を入力し「保存」をクリック

f:id:gattsu09:20170502195107p:plain

以上で、SSHポート番号変更作業は完了しました。 

ログインできるか試します。teratermでポート番号12345を指定しログイン。

f:id:gattsu09:20170502195343p:plain

 

f:id:gattsu09:20170502195402p:plain

ポート番号12345でログインできました。よかった。

ちなみに、元のポート番号22番を指定するとログイン画面すらでず以下のエラーが返ってきます。

 

f:id:gattsu09:20170502195447p:plain

 

これで、「SSHのデフォルトポート22番をとりあえずアタックする」輩からの脅威からは逃れることができるようになりました。

 

４．ログイン用ユーザ設定

 

じゅんびちゅう

５．適切なsudo設定

じゅんびちゅう

ブログはじめました。まじめまして。

ブログ

ども、お勉強した内容をアウトプットする用にブログ作りました。

 

実際動かして理解するをモットーに、主にAWS(Amazon Web Services)の無料枠を利用したLinux学習についてメモレベルに残していきたいと思います。

 

とりあえず、読んでくれるかもしれない誰かに向けての自己紹介ですが、僕はUnix系OSを使用したシステムの運用・保守を数年経験しており、ある程度基礎的な知識は持っているかなぁと思っている感じの者です。

 

ただ、開発や構築経験が無く全般的に知識が浅い＆新人さんとかに質問されても答えにつまる「わかってるつもりなんだけど、実はわかってない」ことが結構あるなぁと感じる今日この頃。というわけで、基礎知識まわりからあらためて実際にLinux動かしながら再学習していこうというのが主なお勉強動機です。

 

飽き性なので、どこまで続くかわかりませんが、マイペースにやっていこうと思います。