Go to Qiita Advent Calendar 2024 Top
LoginSignup
756
743

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@yangci(Y I)inスターフェスティバル株式会社

AWS EC2 Amazon Linuxインスタンス起動後、最初にやることまとめ（SysVinit編）

Last updated at Posted at 2014-12-17

最新のソフトウェアにアップデート

インスタンスの起動直後は、インストール済みソフトウェアのバージョンが古い場合があります。
まとめてアップデートしましょう。

$ sudo yum update -y

タイムゾーンの変更

サーバを日本時間で運用する場合は、タイムゾーンを日本時間に設定します。

/etc/localtimeの設定変更

$ sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

/etc/localtimeの設定前と設定後でタイムゾーンの設定が変わっていることを確認できます。

/etc/localtimeの設定前と設定後
$ date
2014年 12月 16日 火曜日 09:03:29 UTC
$ sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
$ date
2014年 12月 16日 火曜日 18:03:38 JST

/etc/sysconfig/clockの設定変更

$ sudo vi /etc/sysconfig/clock
/etc/sysconfig/clockの中身
ZONE="Asia/Tokyo"
UTC= true

※UTC=true ハードウェアクロックはUTCとしています。

コピペで楽する用
cat << EOL | sudo tee /etc/sysconfig/clock
ZONE="Asia/Tokyo"
UTC=true
EOL

サーバを再起動し、全てのプロセスが新しいタイムゾーン設定を利用するようにします。

サーバの再起動
$ sudo reboot

rebootできない場合は、crondをrestartしておきましょう。

crondの再起動
$ sudo service crond restart
Stopping crond:                                            [  OK  ]
Starting crond:                                            [  OK  ]

※2016-03-07追記
/etc/sysconfig/clockの変更をせずとも、/etc/localtimeを設定すれば日本時間で動作しますが、/etc/sysconfig/clockのタイムゾーンがデフォルトのUTCのままだと、glibcのアップデート時にタイムゾーンがUTCに戻ります。
glibcをアップデートする機会があったので、実験してみました。

$ date # 日本時間になっている
2016年  3月  7日 月曜日 10:19:47 JST

$ more /etc/sysconfig/clock # タイムゾーンはUTCの設定
ZONE="UTC"
UTC=true

$ sudo yum update glibc -y

$ date # 再度時刻を確認するとタイムゾーンがUTCに…
2016年  3月  7日 月曜日 01:20:37 UTC

不要なサービス（デーモン）の停止

最低限必要なサービスだけがサーバの起動時に自動起動されるように設定します。その後、必要に応じてサービスの起動設定をしましょう。

最低限必要と思われるサービス
cloud-final
crond
irqbalance
network
ntpd
ntpdate
rsyslog
sshd

chkconfig --listでサービス起動設定がONになっているサービスを探し、不要なサービスをsudo chkconfig off サービス名で停止しても良いのですが、ntsysvコマンドを使うと設定が楽にできます。

$ sudo ntsysv

ntsysv.png

ランレベル3で設定がONになってるサービスの確認
$ chkconfig --list | cut -f1,5 | grep 3:on
cloud-final    	3:on
crond          	3:on
irqbalance     	3:on
network        	3:on
ntpd           	3:on
ntpdate        	3:on
rsyslog        	3:on
sshd           	3:on

不要なコンソールの起動を無効にしてサーバ資源を節約

/etc/sysconfig/initの編集
$ sudo vi /etc/sysconfig/init

ACTIVE_CONSOLES=/dev/tty[1-6]
の部分をコメントアウトし、
ACTIVE_CONSOLES=/dev/tty1
を追加します。

#ACTIVE_CONSOLES=/dev/tty[1-6]
ACTIVE_CONSOLES=/dev/tty1

サーバを再起動すると、mingettyプロセスの数が減っていることを確認できます。

サーバ再起動前のmingettyプロセス
$ ps alx | grep mingetty | grep -v grep
4     0  2343     1  20   0   4180   580 n_tty_ Ss+  tty1       0:00 /sbin/mingetty /dev/tty1
4     0  2345     1  20   0   4180   580 n_tty_ Ss+  tty2       0:00 /sbin/mingetty /dev/tty2
4     0  2347     1  20   0   4180   580 n_tty_ Ss+  tty3       0:00 /sbin/mingetty /dev/tty3
4     0  2349     1  20   0   4180   580 n_tty_ Ss+  tty4       0:00 /sbin/mingetty /dev/tty4
4     0  2351     1  20   0   4180   584 n_tty_ Ss+  tty5       0:00 /sbin/mingetty /dev/tty5
4     0  2353     1  20   0   4180   584 n_tty_ Ss+  tty6       0:00 /sbin/mingetty /dev/tty6
サーバ再起動後のmingettyプロセス
$ ps alx | grep mingetty | grep -v grep
4     0  2115     1  20   0   4180   580 n_tty_ Ss+  tty1       0:00 /sbin/mingetty /dev/tty1

ec2-userの削除

セキュリティを強化するのであれば、ec2-userのアカウント名をそのまま使うのではなく、ec2-userは無効にして、新しいユーザを作成しましょう。

newuserの追加
$ sudo adduser newuser

newuserにsudo権限を与えます。
wheelグループに所属するユーザはsudo権限があるので、wheelグループにnewuserを所属させることにします。
※2015/9/29追記
最近のEC2インスタンスで確認をしたところ、wheelグループに所属していてもsudo権限がない場合があるようでした。
（もしかしたら、昔から、初期設定ではwheelグループにsudo権限が無いかもしれませんが。）

newuserをwheelグループに追加
$ sudo usermod -G wheel newuser
wheelグループのユーザの確認
$ grep wheel /etc/group
wheel:x:10:ec2-user,newuser

※2015/9/29追記
/etc/sudoers.d/cloud-initにnewuser ALL = NOPASSWD: ALLの一行を追加します。

/etc/sudoers.d/cloud-initに設定を追加
$ echo 'newuser ALL = NOPASSWD: ALL' | sudo tee --append /etc/sudoers.d/cloud-init

/etc/sudoersの設定でnewuserにsudo権限を与えることもできます。
newuser ALL=(ALL) NOPASSWD: ALL
の一行を追加します。

/etc/sudoersの設定
$ sudo visudo

ec2-userのauthorized_keysをnewuserの.sshディレクトリにコピーし、適切なパーミッションを設定します。

authorized_keysのコピーと適切なパーミッションの設定
$ sudo rsync -a ~/.ssh/authorized_keys ~newuser/.ssh/
$ sudo chown -R newuser:newuser ~newuser/.ssh
$ sudo chmod -R go-rwx ~newuser/.ssh
.sshのパーミッション確認
$ sudo ls -al ~newuser/.ssh
合計 12
drwx------ 2 newuser newuser 4096 12月 17 13:27 .
drwx------ 3 newuser newuser 4096 12月 17 13:27 ..
-rw------- 1 newuser newuser  388 12月 17 13:16 authorized_keys
newuserにsudo権限があるか確認
$ sudo su - newuser
$ sudo -s
#

newuserがsshでログインできることと、sudo権限を持つことを確認できたら、最後にec2-userを削除します。

ec2-userアカウントの削除
$ sudo userdel ec2-user

ec2-userの削除ではなく、sshでのログインを禁止する場合は、
/etc/ssh/sshd_configの設定でec2-userのsshログインを禁止することもできます。
DenyUsers ec2-userの一行を追加します。

/etc/ssh/sshd_configの設定
$ sudo vi /etc/ssh/sshd_config

/etc/ssh/sshd_configを修正したら、設定を反映させます。

/etc/ssh/sshd_config設定の反映
$ sudo service sshd reload

awsコマンドを利用できるように設定

aws configureでawsコマンドが利用できるようにしておきます。

$ aws configure
AWS Access Key ID [None]: XXXXXXXXXXXXXXXXXXXX
AWS Secret Access Key [None]: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Default region name [None]: ap-northeast-1
Default output format [None]:

aws ec2 describe-instance-statusを実行すると、EC2インスタンスのスタータスの確認ができます。

awsコマンド確認
$ aws ec2 describe-instance-status
{
    "InstanceStatuses": [
        {
            "InstanceId": "i-xxxxxxxx",
            "InstanceState": {
                "Code": 16,
                "Name": "running"
            },
            "AvailabilityZone": "ap-northeast-1b",
            "SystemStatus": {
                "Status": "ok",
                "Details": [
                    {
                        "Status": "passed",
                        "Name": "reachability"
                    }
                ]
            },
            "InstanceStatus": {
                "Status": "ok",
                "Details": [
                    {
                        "Status": "passed",
                        "Name": "reachability"
                    }
                ]
            }
        },
		...(略)...
	]
}

awsコマンドを利用するための環境設定がされていない場合は、エラーメッセージが表示されます。

awsコマンドを利用するための環境設定がされていない場合
$ aws ec2 describe-instance-status
Unable to locate credentials. You can configure credentials by running "aws configure".

aws configでの設定は、ホームディレクトリの.awsディレクトリ内に保存されます。

$ more ~/.aws/credentials 
[default]
aws_access_key_id = XXXXXXXXXXXXXXXXXXXX
aws_secret_access_key = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

$ more ~/.aws/config 
[default]
region = ap-northeast-1

sshdのLISTENポート変更

sshdのLISTENポートを標準の22から別の番号へ変えておくことで、第三者からの攻撃被害を防げる可能性が高くなります。

下記は、sshdのLISTENポートを22から22022※に変更を行う手順となります。
※22022の部分はRegistered Port Number(1024～49151)範囲内のポート番号に適当にかえてください。

/etc/ssh/sshd_configを編集し、
Port 22022
を追加します。
22022ポートへの接続確認ができるまで、22ポートのLISTENは残しておいたほうが安全なので、一旦、Port 22とPort 22022の両方を設定することにします。

/etc/ssh/sshd_configの編集
# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
Port 22
Port 22022

/etc/ssh/sshd_configの設定が完了したら、
sudo service sshd reload
コマンドを実行し、最新の設定を反映させます。

/etc/ssh/sshd_configの設定を反映
$ sudo service sshd reload
Reloading sshd:                                            [  OK  ]

問題が無ければ、netstatコマンドでsshdがポート22022をLISTENしていることの確認ができます。

sshdのLISTENポート確認
$ sudo netstat -anp | grep sshd
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      540/sshd            
tcp        0      0 0.0.0.0:22022               0.0.0.0:*                   LISTEN      540/sshd            
tcp        0      0 xxx.xxx.xxx.xxx:22          yyy.yyy.yyy.yyy:63916       ESTABLISHED 462/sshd            
tcp        0      0 :::22                       :::*                        LISTEN      540/sshd            
tcp        0      0 :::22022                    :::*                        LISTEN      540/sshd            
unix  3      [ ]         STREAM     CONNECTED     489675 462/sshd            
unix  2      [ ]         DGRAM                    489671 462/sshd            
unix  3      [ ]         STREAM     CONNECTED     489674 464/sshd

※netstatの-pオプションはroot権限が必要なので、sudoコマンドでnetstatを実行しています。

22022ポートでのssh接続を確認できたなら、ポート22のLISTENは不要ですので、
/etc/ssh/sshd_configのPort 22を削除し、sshdに最新の設定を反映させます。

/etc/ssh/sshd_configのポート22設定を削除
# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
Port 22022
/etc/ssh/sshd_configの設定を反映
$ sudo service sshd reload
Reloading sshd:                                            [  OK  ]
sshdのLISTENポート確認
$ sudo netstat -anp | grep ssh
tcp        0      0 0.0.0.0:22022               0.0.0.0:*                   LISTEN      32166/sshd          
tcp        0      0 xxx.xxx.xxx.xxx:22022       yyy.yyy.yyy.yyy:61530       ESTABLISHED 32358/sshd          
tcp        0      0 :::22022                    :::*                        LISTEN      32166/sshd          
unix  2      [ ]         DGRAM                    484858 32358/sshd          
unix  3      [ ]         STREAM     CONNECTED     484862 32358/sshd          
unix  3      [ ]         STREAM     CONNECTED     484861 32360/sshd

関連

以下もよろしければどうぞ。

756
743
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
756
743

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?