最もシンプルに「macOS High Sierra」をクリーンインストールする全手順

f:id:tmknom:20180429180639j:plain

Macクリーンインストールしたのでその全手順を公開する。 コンセプトは、極力余計な設定は入れないである。後追いで可能な、Apple IDの入力や、各種設定は全部スキップする。

データのバックアップ

データはすべて削除するので、データのバックアップは事前に行っておく

このあと、ディスクをフォーマットするので、あとで泣かないように。

macOSユーティリティの起動

PC起動中の場合は、一度電源を切る。次に command+ R を押しながら、電源を入れる。

f:id:tmknom:20180429163948p:plain

Apple ロゴが表示されたら、キーをはなして待つ。

f:id:tmknom:20180429170928p:plain

しばらくすると、macOSユーティリティが立ち上がる。

f:id:tmknom:20180429164901p:plain

繰り返しになるが、データをすべて消すので、必ずデータのバックアップをしてから先に進もう

ディスクフォーマット

まずは、ディスクをフォーマットして、全データを削除する。

「ディスクユーティリティ」を選択し、「続ける」ボタンをクリック。

f:id:tmknom:20180429164714p:plain

左側の「Macintosh HD」を選択し、上部にある「消去」ボタンをクリック。

f:id:tmknom:20180429161554p:plain

モーダルが立ち上がるので、名前が「Macintosh HD」、フォーマットが「APFS」になっていることを確認し、「消去」ボタンをクリック。

f:id:tmknom:20180501105235p:plain

ディスクフォーマットが始まるので数分待ち、完了したら、「完了」ボタンをクリック。

f:id:tmknom:20180429163105p:plain

左上の赤丸ボタンをクリックして、ディスクユーティリティを終了する。

f:id:tmknom:20180429164254p:plain

これでディスクがまっさらな状態になった。

macOS再インストール

続いて、OSの再インストールを行おう。

ディスクを初期化した影響で、Wi-Fiがつながらなくなったので、接続できるようにする。

f:id:tmknom:20180501104659p:plain

macOSユーティリティから「macOSを再インストール」を選択し、「続ける」ボタンをクリック。

f:id:tmknom:20180429165253p:plain

インストールを開始するため、「続ける」をクリック。

f:id:tmknom:20180429165558p:plain

使用許諾契約を読み、「同意する」をクリック。

f:id:tmknom:20180429165936p:plain

再度聞かれるので、「同意する」をクリック。

f:id:tmknom:20180430154136p:plain

インストール先として、先ほどフォーマットした「Macintosh HD」を選択し、「インストール」をクリック。

f:id:tmknom:20180429170554p:plain

するとインストールが始まる。30〜40分ぐらいかかるので、コーヒーでも飲みながら気長に待つ。

f:id:tmknom:20180430170617p:plain

OSインストールが完了すると、OSの初期設定を行う。

インストール後のOS設定

基本設定

「日本」を選択し、「続ける」をクリック。

f:id:tmknom:20180429171238p:plain

キーボード配列は「日本語」を選択。

f:id:tmknom:20180429171647p:plain

入力方法では「ローマ字」を選択し、「続ける」をクリック。

f:id:tmknom:20180429172501p:plain

使用するWi-Fiを選択し、パスワードを入力して、「続ける」をクリック。

f:id:tmknom:20180429172549p:plain

データとプライバシーについて読み、「続ける」クリック。

f:id:tmknom:20180430154406p:plain

情報の転送はここではしないので、「今は情報を転送しない」を選択し、「続ける」をクリック。

f:id:tmknom:20180429172829p:plain

Apple IDの設定は後から必要になったタイミングでやればいいので、「後で設定」をクリック。

f:id:tmknom:20180429173346p:plain

再度確認されるので、「スキップ」をクリック。

f:id:tmknom:20180430154730p:plain

利用条件を読んで、「同意する」をクリック。

f:id:tmknom:20180430154925p:plain

再度確認されるので、「同意する」をクリック。

f:id:tmknom:20180430155149p:plain

アカウント情報として「フルネーム」「アカウント名」「パスワード」を入力し、「続ける」をクリック。

f:id:tmknom:20180429230940p:plain

エクスプレス設定

Macに標準で搭載されているアプリケーションの設定を行っていくため、「設定をカスタマイズ」をクリック。

f:id:tmknom:20180430155430p:plain

Macで位置情報が不要なら、「このMacで位置情報サービスを有効にする」のチェックを外し、「続ける」をクリック。

f:id:tmknom:20180430155827p:plain

再度確認されるので、「使用しない」をクリック。

f:id:tmknom:20180430155946p:plain

時間帯の設定では、地図上で日本周辺をクリックし、最も近い都市から「Tokyo - 日本」を選択して、「続ける」をクリック。

f:id:tmknom:20180430160403p:plain

Mac解析の設定では、余計な通信を発生させたくないので、「Mac解析をAppleと共有」のチェックを外し、「続ける」をクリック。

f:id:tmknom:20180430160607p:plain

Siriを使わないなら、「"Siriに頼む"を有効にする」のチェックを外し、「続ける」をクリック。

f:id:tmknom:20180430160852p:plain

Macの設定が開始される。

f:id:tmknom:20180429174849p:plain

少し待てば、いつもの画面が表示される。

f:id:tmknom:20180429175125p:plain

これで、クリーンインストールは完了である。

参考情報 - Mac を売却または譲渡する場合

本記事では、OSをクリーンな状態で使うことが目的だったためやらなかったが、Macを売却・譲渡する目的でOSを初期化する場合は注意点がある。それは、Apple IDと各種ソフトウェアの連携の解除である

  1. iTunesの認証解除
  2. Macを探す」をオフする
  3. iCloudからサインアウトする
  4. iMessageからサインアウトする
  5. Apple IDの管理からデバイスを削除

これらの手順は、Macが手元にある状態でやらないと、あとでメンドウなことになるので、頭の片隅に入れておこう。

詳しくは、Macを売却する前にmacOSを初期化してクリーンインストール・復元をする3つの方法や公式のMac を売却または譲渡する前にを参考にしてほしい。

terraformのaws_default_network_aclリソースを素人が安易に使ってはいけない

最初組み込んでたんだけど、調べてみるとなんかキワイ。

公式ドキュメント

カッコ書きは、Google翻訳を使いながら、適当に翻訳したものである。(残念英語力なので、間違ってたらゴメンね

https://www.terraform.io/docs/providers/aws/r/default_network_acl.html

概要

Each VPC created in AWS comes with a Default Network ACL that can be managed, but not destroyed. This is an advanced resource, and has special caveats to be aware of when using it. Please read this document in its entirety before using this resource.

AWSで作成された各VPCには、管理可能なデフォルトネットワークACLがありますが、削除することはできません。 これは高度なリソースであり、使用時に注意すべき特別な注意点があります。 このリソースを使用する前に、この文書全体をお読みください。」

にじみ出る玄人向け感。初っ端から、初心者お断りオーラ出してきてる。

The aws_default_network_acl behaves differently from normal resources, in that Terraform does not create this resource, but instead attempts to "adopt" it into management.

aws_default_network_aclは通常のリソースとは異なる動作をします。Terraformは、aws_default_network_aclはこのリソースを作成せず、その代わりに管理下に置くことを試みます。」

繰り返される、aws_default_network_acl氏による、オレは特別だぞアピール

When Terraform first adopts the Default Network ACL, it immediately removes all rules in the ACL. It then proceeds to create any rules specified in the configuration.

「Terraformはまず、デフォルトネットワークACLすべてのルールを直ちに削除します 。 次に、設定されたルールを組み込みます。」

デフォルトのネットワーク ACLって影響が甚大なのに、なんとも思い切った動きをしやがる。か、漢だ…。

This resource treats its inline rules as absolute; only the rules defined inline are created, and any additions/removals external to this resource will result in diffs being shown. For these reasons, this resource is incompatible with the aws_network_acl_rule resource.

「このリソースは、そのインラインルールを絶対のものとして扱います。 インラインで定義されたルールのみが作成され、このリソースの外部で追加/削除が行われると、差分が表示されます。 これらの理由から、このリソースはaws_network_acl_ruleリソースと互換性がありません。」

漢は黙ってインライン定義のaws_default_network_aclパイセンの、aws_network_acl_ruleとは違いますからアピール。そろそろウゼーな、コイツ

デフォルトネットワークACLでのサブネット管理

Within a VPC, all Subnets must be associated with a Network ACL. In order to "delete" the association between a Subnet and a non-default Network ACL, the association is destroyed by replacing it with an association between the Subnet and the Default ACL instead.

VPC内では、すべてのサブネットをネットワークACLに関連付ける必要があります。 サブネットとデフォルト以外のネットワークACLとの関連付けを「削除」すると、サブネットの関連付けはデフォルトACLと差し替えられ、もとの関連付けが破棄されます。」

AWSの仕様上、すべてのサブネットはネットワークACLに紐付けないといけないから、関連付けが明示されないサブネットは、暗黙的にデフォルトネットワークACLに紐付けられるっぽい。そりゃ、そうかって感じである。

When managing the Default Network ACL, you cannot "remove" Subnets. Instead, they must be reassigned to another Network ACL, or the Subnet itself must be destroyed. Because of these requirements, removing the subnet_ids attribute from the configuration of a aws_default_network_acl resource may result in a reoccurring plan, until the Subnets are reassigned to another Network ACL or are destroyed.

「デフォルトネットワークACLを管理する場合、サブネットを「削除」することはできません。 別のネットワークACLに改めて関連付けるか、サブネット自体を破棄する必要があります。 これらの要件のため、subnet_ids属性をaws_default_network_aclリソースの設定から削除すると、サブネットが別のネットワークACLに再度関連付けられるか破棄されるまで、 繰り返し差分が出る可能性があります。」

なんつーか、スッゲーじゃじゃ馬感あるな、コイツ

aws_default_network_acl の設定を削除する

Each AWS VPC comes with a Default Network ACL that cannot be deleted. The aws_default_network_acl allows you to manage this Network ACL, but Terraform cannot destroy it. Removing this resource from your configuration will remove it from your statefile and management, but will not destroy the Network ACL. All Subnets associations and ingress or egress rules will be left as they are at the time of removal. You can resume managing them via the AWS Console.

「各VPCには、削除不可のデフォルトネットワークACLが紐付いている。 aws_default_network_acl を使用すると、このネットワークACLを管理できますが、Terraformは削除までは行なえません。 このリソースを設定から削除すると、stateファイルから削除され、管理下からは外れますが、ネットワークACLは破棄されません。 すべてのサブネットの関連付けとインバウンド/アウトバウンドのルールは、削除時のまま残ります。 その後も、AWS コンソールで管理を再開することができます。」

仕様上、デフォルトネットワークACLの削除はできないから、こんな振る舞いになるらしい。分かるっちゃあ、分かるけど、なんとも微妙な振る舞いである

結論

aws_default_network_aclはterraform上の挙動が複雑なので、安易に使わないほうが良さげ。そもそも、ネットワークACL自体が、AWSでは制約が大きく扱いが難しい。

ネットワークACLの設定を変更したい場合は、aws_network_aclリソースを使って、別途ネットワークACLを定義する。ちゃんと検証してないが、おそらく意図したとおりに動くと思う。少なくとも、aws_default_network_aclよりはマシな挙動をするはずだ。

Terraformのバックエンド用のS3バケットは、Terraformで管理してはいけない

新規にAWSアカウントを取得するにあたって、極力AWSリソースの管理はterraformに寄せようと思ったのだが、ふとterraformのtfstateファイルを置くS3は、terraform管理していいのか気になった。ので、調べてみた。

公式ソース

結論としてはタイトルどおりなわけだが、公式に言及されていた。

www.terraform.io

Terraform is an administrative tool that manages your infrastructure, and so ideally the infrastructure that is used by Terraform should exist outside of the infrastructure that Terraform manages.

雑にGoogle翻訳してみる。

Terraformはインフラストラクチャを管理する管理ツールです。したがって、Terraformで使用されるインフラストラクチャは、Terraformが管理するインフラストラクチャの外部に存在する必要があります。

というわけで、Terraformのバックエンド用のS3バケットを、Terraformの管理対象にするのはやめたほうがよさそう。

さらに読み進めると、次のように書いてある。

This can be achieved by creating a separate administrative AWS account which contains the user accounts used by human operators and any infrastructure and tools used to manage the the other accounts.

雑にGoogle翻訳してみる。

これは、人間のオペレータが使用するユーザアカウントと、他のアカウントを管理するために使用されるインフラストラクチャとツールを含む別の管理 AWSアカウントを作成することで実現できます。

Terraformのバックエンド用のS3バケットの管理をするためのアカウントを作れと言っている。AWS Organizationsと組み合わせればできそうである。

雑にS3バケットを作成する

AWS Organizationsを使えばできそうだが、それすらメンドウなら、雑にS3バケットを作ろう。もちろん、AWSコンソールから作ってもいいのだが、AWSアカウントを取得するたびにやることになるので、シェルスクリプト化しておく。

なお、これを動かすためには、事前にAWS CLIはインストールする必要がある。

#!/bin/sh

set -ex

BUCKET_NAME=$1
LEGION=${2:-ap-northeast-1}

# バケットの作成
# リージョンを指定しないとエラーになるので明示的に指定している
# https://dev.classmethod.jp/cloud/aws/jaws-ug-cli-1/
aws s3api create-bucket --bucket $BUCKET_NAME --create-bucket-configuration LocationConstraint=$LEGION

# バケットのバージョニング設定
# 何かやらかしたときに、復元できるようにしておく
aws s3api put-bucket-versioning --bucket $BUCKET_NAME --versioning-configuration Status=Enabled

# バケットのデフォルト暗号化設定
# http://tech.withsin.net/2017/12/05/s3-bucket-encryption/
aws s3api put-bucket-encryption --bucket $BUCKET_NAME --server-side-encryption-configuration '{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "AES256"
      }
    }
  ]
}'

aws s3api get-bucket-location --bucket $BUCKET_NAME
aws s3api get-bucket-versioning --bucket $BUCKET_NAME
aws s3api get-bucket-encryption --bucket $BUCKET_NAME

適当にinit_terraform_bucket.shとかってファイルに保存して実行する。

./init_terraform_bucket.sh my-cloudtrail-bucket

これで、毎回ポチポチしなくても済むようになった。

超速でCentOS6.6(さくらのVPS)をセットアップする俺史上最強のFabricスクリプトをさらす

f:id:tmknom:20150117151657g:plain

先日公開したはじめてでも爆速でCentOS6.6(さくらのVPS)をセキュアにセットアップする方法まとめの事実上の後編だ。本記事ではセットアップ手順をFabricのスクリプトにして公開する。

Fabricスクリプトのセットアップ

ダウンロード

GitHubで公開してるので、それを取ってこよう。

$ git clone git@github.com:tmknom/setup-centos.git
$ cd setup-centos

自分の環境用に設定を変更する

テキストエディタfabfile.py を開いて、設定を変更しよう。

以下の項目は必ず変更してほしい。

  • 作業用ユーザ名:USER_NAME
  • 作業用ユーザのパスワード:PASSWORD
  • 接続先のVPSサーバのIPアドレス:env.hosts

また、次の項目も変更をすることを推奨するぞ。(変えなくても動くけど)

  • rootのメールアドレス:ROOT_MAIL_ADDLESS
  • SSHのポート番号:SSH_PORT

こんな感じの記述が上のほうにあるので探してくれ。

$ vi fabfile.py

########  基本設定  ########

# 作成する作業用ユーザ
USER_NAME = 'your_name'            # ← 必ず変更する!
# 作業用ユーザのパスワード
PASSWORD  = 'your_password'        # ← 必ず変更する!
# rootのメールアドレス
ROOT_MAIL_ADDLESS = ''             # ← 変更推奨
# 設定するSSHのポート番号
SSH_PORT  = '50022'                # ← 変更推奨


########  fabric向け設定  ########

# 接続先のVPSサーバのIPアドレス
env.hosts = ["XX.XX.XX.XX"]        # ← 必ず変更する!

使用するにあたっての前提条件

このスクリプトは、以下の作業が完了している前提で使用する。

  • Fabricのインストール
  • SSH公開鍵の作成

未実施の場合は、(参考)事前準備の項目を参考に実施しておこう。

Fabricスクリプトの使い方

基本的な使い方

一番スタンダードなのは setup タスクだ。

$ fab setup

このコマンドを叩くと、ログ監視ツールの導入の部分まで一気にやってくれる。

fail2banなどのセキュリティ系のツールも一気に入れたい場合は、 setup_all タスクを使おう。

$ fab setup_all

ただこの setup_all タスク、本記事公開時点では、tripwireのパスフレーズ入力が自動化できていない。気が向いたら直すけど、とりいそぎは手入力で我慢してね><

ネットワークが遅い場合

全員が該当するかは不明だけど、さくらのVPSでネットワークが遅い場合がある。そんな時は sakura タスクも合わせて実行してみてほしい。

$ fab sakura setup
$ fab sakura setup_all

筆者の環境では遅かったので、スクリプト検証中はいつも sakura タスクを併用していた。

ちなみに sakura でやってることは、この記事のコマンドを実行しているだけだ。

その他のタスク

本記事の公開時点で提供しているタスクは全部で5つだ。

$ fab --list
Available commands:

    install_security_tools
    sakura
    setup
    setup_all
    setup_min

setup_min タスクでは、システムの最新化と自動更新までを実行する。logwatchとか勝手に入れんじゃねぇ!って人は試してみてほしい。

$ fab setup_min

install_security_tools タスクでは、セキュリティ系ツールのインストールのみを実行する。

$ fab install_security_tools

setup タスクでセットアップしたけど、あとからセキュリティ系ツールも入れたいなぁって時に使ってほしい。

ちなみに、↓の二つのコマンドはやってることは同じだ。

$ fab setup_all
$ fab setup install_security_tools

まとめ

setup タスクを使うと、まっさらな状態から1分程度でセットアップが完了するようになった!ヽ(´ー`)ノ

setup_all タスクでも5分程度で完了してとっても捗るぞ!

まだまだ発展の余地はてんこ盛りなので、好きなようにアレンジして活用してほしい。

最新のソース置き場

tmknom/setup-centos · GitHub

(参考)事前準備

Fabricのインストール

Fabricが必要なので、入れてない場合はインストールしよう。MacだとHomebrewでインストールできた。

$ brew install fabric
$ fab -V
Fabric 1.10.1

SSH公開鍵の作成

SSH公開鍵は作成されてる前提でスクリプトは作っている。ない場合は作成しておこう。

$ ssh-keygen -t rsa -C "your_email@example.com"

また、公開鍵は、デフォルトの ~/.ssh/id_rsa.pub を前提としている。違う公開鍵を使いたい人は、直接スクリプトを編集してほしい。

(参考)記事公開時点でのソースコード

今後、スクリプトの更新を行うかもしれないので、本記事公開時点でのソースコードを貼り付けておく。ぺたっとな。

https://gist.github.com/tmknom/f2a21f16f2098ce6933d

さくらのVPS(CentOS)のネットワーク通信が遅いよヽ(`Д´)ノウワァァン!! って場合の対処法

さくらのVPSをセットアップしていると、エラくモジュールのダウンロードに時間がかかることに気づいた。

VPSだし、こんなもんなのかなとも思ったが、対処法があったのでメモ。

VPSにログインして、suしてrootになった前提での手順だよ。

# ethtool -K eth0 tso off
# echo "ACTION==\"add\", SUBSYSTEM==\"net\", KERNEL==\"eth0\", RUN+=\"/sbin/ethtool -K eth0 tso off\"" > /etc/udev/rules.d/50-eth_tso.rules

以上だ。

場合によっては数倍ぐらい早くなるので、遅いなぁと思う人は試してみてほしい。

ちなみに、CentOS以外の場合についても、さくら公式ヘルプに情報があるのでこちらもどうぞ。

はじめてでも爆速でCentOS6.6(さくらのVPS)をセキュアにセットアップする方法まとめ

f:id:tmknom:20150116000843p:plain

爆速でセットアップを完了するため、極力コピペで設定できるようにしてみたよ(・∀・)

動作検証は、さくらのVPSで標準OSをインストールして行った。記事執筆時点ではCentOS6.6がインストールされたぞ。

# cat /etc/issue
CentOS release 6.6 (Final)
# uname -rs
Linux 2.6.32-504.3.3.el6.x86_64

お知らせ

本記事の内容をFabric化したスクリプトを公開!ぜひ試してみてね。

超速でCentOS6.6(さくらのVPS)をセットアップする俺史上最強のFabricスクリプトをさらす

rootのパスワード変更と作業用ユーザの作成

まずは、コンソールからSSHで接続しよう。

[localhost ~]$ ssh root@XX.XX.XX.XX

なお、サーバを起動してない場合は、事前に管理画面からサーバを起動しよう。詳しい方法はさくらのヘルプページを参考に。

rootのパスワード変更

さくらのVPSの場合、rootのパスワードはメールに直書きされて送られてくるので、最初に変更しておこう。

# passwd

作業用ユーザの作成

rootで直接作業をするとリスクが高いので、作業用のユーザを作成し、普段の作業はそちらで行うようにしよう。

後ほど、su/sudo権限をwheelグループに付与するので、ここで作成するユーザはwheelグループに所属させる。

# useradd <user_name> -G wheel
# passwd <user_name>

<user_name> の部分は、作成するユーザ名に置き換えてほしい。

設定ファイルの自動バージョン管理

これから色々な設定ファイルを弄るので、いつでも元に戻せるように、 etckeeper を入れておこう。

etckeeperはデフォルトで、/etcディレクトリ配下をgitでバージョン管理してくれるぞ。

etckeeperのインストール

# yum -y install etckeeper

管理対象外の設定

ほっとくと、etckeeperは/etc/shadowや/etc/passwdも管理対象にしてしまう。これらは対象外にしておこう。

# touch /etc/.gitignore
# echo "shadow*" >> /etc/.gitignore
# echo "gshadow*" >> /etc/.gitignore
# echo "passwd*" >> /etc/.gitignore
# echo "group*" >> /etc/.gitignore

バージョン管理の開始

では、初期状態を保存しておこう。

# etckeeper init
# etckeeper commit "First Commit"

etckeeperはyumなどのパッケージ管理のコマンドを実行した時や、cronで一日一回自動でコミットしてくれる。

ちなみに、etckeeper自体は単なるVCSのラッパーなので、/etcディレクトリで普通にgitコマンドが使えることを覚えておこう。

ファイルを前の状態に戻したりするときは、直接gitコマンドで操作したほうが簡単だ。

wheelグループにsu/sudo権限付与

wheelグループにsu権限付与

/etc/pam.d/su を修正するためのコマンドを叩こう。

# sed -i 's/^#auth\(\s\+required\)/auth\1/' /etc/pam.d/su

すると↓のように修正される。

#auth        required    pam_wheel.so use_uid
 ↓ コメントアウト(#)を外す
auth        required    pam_wheel.so use_uid

wheelグループにsudo権限付与

/etc/sudoers を修正するためのコマンドを叩こう。

# sed -i 's/^# %wheel\(\s\+ALL=(ALL)\s\+ALL$\)/%wheel\1/' /etc/sudoers

すると↓のように修正される。

# %wheel ALL=(ALL)   ALL
 ↓ コメントアウト(#)を外す
%wheel ALL=(ALL) ALL

ちなみに、ここではsedコマンドを使って直接ファイルを編集しているが、普通に編集したい場合は visudo コマンドを使おう。

作業用ユーザの設定確認

一旦、VPSからログアウトし、先ほど作成した作業用ユーザでログインしてみよう。

[localhost ~]$ ssh <user_name>@XX.XX.XX.XX

ログインできればOKだ。

今度はsudoできることを確認しよう。

$ sudo whoami
[sudo] password for <user_name>: ←作業用のパスワードを入力
root

最後にsuコマンドが使えることを確認しよう。

$ su -
Password: ←rootのパスワードを入力

コピペミスがなければ、特に問題は起きないはずだ!

では、引き続きrootで作業を行っていこう。

SSHのポート番号変更とrootログイン禁止

SSHのポート番号変更

SSHのデフォルトポートはアタックを受けやすいので、変更してしまおう。

/etc/ssh/sshd_config を修正するぞ。

# sed -i 's/^#Port\s\+22/Port 50022/' /etc/ssh/sshd_config

すると↓のように修正される。

#Port 22
 ↓ コメントアウト(#)を外し、"22"を任意の番号に変更
Port 50022

ここでは、50022に変更しているが、ウェルノウンポート(0–1023)以外ならなんでもいい。

動的/プライベートポート(49152–65535)だと確実にポート番号の競合を回避できるので、この範囲で選ぶのが個人的には好みだ。

リモートからのrootログイン禁止の設定

作業用ユーザでログイン及び、su/sudoができれば、rootがログインが必要はなくなる。

このタイミングでリモートからのrootログインを禁止してしまおう。

先ほど同様 /etc/ssh/sshd_config を修正する。

# sed -i 's/^#PermitRootLogin\s\+yes/PermitRootLogin no/' /etc/ssh/sshd_config

すると↓のように修正される。

#PermitRootLogin yes
 ↓ コメントアウト(#)を外し、"yes"を"no"に変更
PermitRootLogin no

sshdの再起動

このまま再起動しても問題ないが、念のため記述ミスがないかチェックを行おう。

# sshd -t

何も出なければOK。

/etc/ssh/sshd_config の設定はしくじるといきなり接続できなくなったりするので、sshdを再起動する前にチェックするクセをつけよう。

なお、さくらのVPS以外の場合、22番以外の通信がiptablesによって制限されている可能性があるので事前に確認したほうがいい。さくらのVPSはデフォルトフルオープンという漢らしい設定になっているので、このまま進めてもらって構わない。

では、反映するためにsshdを再起動する。

# service sshd restart

SSHの接続確認

VPSからログアウトして、ログインを試してみよう。

[localhost ~]$ ssh <user_name>@XX.XX.XX.XX
ssh: connect to host XX.XX.XX.XX port 22: Connection refused

今まで通りのコマンドを打つと、拒否されるはずだ。

次にsshコマンドに -p オプションでポート番号を指定して、接続してみよう。

[localhost ~]$ ssh <user_name>@XX.XX.XX.XX -p 50022

今度はログインできたはずだ。

もう一度ログアウトし、rootでログインできないことも念のため確認しておこう。

[localhost ~]$ ssh root@XX.XX.XX.XX -p 50022

ちゃんと弾いてくれたね!

では、改めて作業用ユーザでログインしよう。

[localhost ~]$ ssh <user_name>@XX.XX.XX.XX -p 50022

公開鍵認証の設定

これまではSSH接続にパスワード認証を使ってきたわけだけど、よりセキュアになるよう、公開鍵認証を使えるようにしよう。

公開鍵用のファイルとパーミッションの設定

作業用のユーザのホームディレクトリに、公開鍵用の空ファイルを作成し、パーミッションを設定しておく。

$ mkdir ~/.ssh 
$ chmod 700 ~/.ssh
$ touch ~/.ssh/authorized_keys 
$ chmod 600 ~/.ssh/authorized_keys

ここまで終わったら、ログアウトしておこう。次の作業はVPSではなく、自分の端末での作業になるので注意してほしい。

公開鍵をサーバへ転送

もし、秘密鍵・公開鍵を作ってない場合は作成しておこう。

[localhost ~]$ ssh-keygen -t rsa -C "your_email@example.com"

次に、自分の公開鍵をVPSへ転送しよう。

[localhost ~]$ scp -P 50022 ~/.ssh/id_rsa.pub <user_name>@XX.XX.XX.XX:~/.ssh/authorized_keys

scpコマンドでは、 -P オプションで、先ほど変更したポート番号を指定することに注意してほしい。

公開鍵認証を有効にする

改めてVPSへログイン。suしてrootになっておこう。

で、またまた /etc/ssh/sshd_config を修正する。

# sed -i 's/^#PubkeyAuthentication\s\+yes/PubkeyAuthentication yes/' /etc/ssh/sshd_config

すると↓のように修正される。

#PubkeyAuthentication yes
 ↓ コメントアウト(#)を外す
PubkeyAuthentication yes

パスワードログインの禁止

公開鍵認証を使えるようにしたので、パスワードログインを禁止してしまおう。

もはやおなじみとなった /etc/ssh/sshd_config を修正する。

# sed -i 's/^PasswordAuthentication\s\+yes/PasswordAuthentication no/' /etc/ssh/sshd_config

すると↓のように修正される。

PasswordAuthentication yes
 ↓ "yes"を"no"に変更
PasswordAuthentication no

SSHを許可するユーザの制限

このタイミングでSSHに接続できるユーザを限定してしまおう。

/etc/ssh/sshd_config"AllowUsers"を設定すればOKだ。

# echo "AllowUsers <user_name>" >> /etc/ssh/sshd_config

<user_name> の部分は、作業用ユーザの名前に置き換えよう。

ユーザ名をタイポするとログインできなくなるので、ユーザ名はコピペで入力することを推奨するぞ!

公開鍵認証でのSSH接続の確認

先ほど同様に、設定に問題がないかチェックして、sshdを再起動。

# sshd -t
# service sshd restart

一度VPSからログアウトして、パスワード無しでログインできることを確認しよう。

[localhost ~]$ ssh <user_name>@XX.XX.XX.XX -p 50022

ログインできたら、suしてrootになっておいてね。

iptables(ファイアウォール)の設定

とりあえずSSHだけ許可する方針でいこう。

iptablesはviで直接ファイル弄ったほうが楽なんじゃないかという心の声を華麗にスルーして、愚直にコマンドでいくよ!( ・`ω・´)キリッ

接続済の通信は全て許可

これがないと詰む。

# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

ローカルループバックアドレスを許可

ローカルは西川貴教ばりにオールOKにしておく。

# iptables -A INPUT -i lo -j ACCEPT

ICMPを許可

pingとかできるようにする。

# iptables -A INPUT -p icmp -j ACCEPT

各種攻撃対策

手早くそこそこセキュアにするならこんな感じ。

もっと頑張りたい人は、ココとか見ながら、アレンジしてみよう。

IP偽装対策

プライベートIPアドレスとブロードキャストアドレスぐらいは拒否しておこう。

プライベートIPアドレス
# iptables -A INPUT -s 10.0.0.0/8 -j DROP
# iptables -A INPUT -d 10.0.0.0/8 -j DROP
# iptables -A INPUT -s 172.16.0.0/12 -j DROP
# iptables -A INPUT -d 172.16.0.0/12 -j DROP
# iptables -A INPUT -s 192.168.0.0/16 -j DROP
# iptables -A INPUT -d 192.168.0.0/16 -j DROP
ブロードキャストアドレス
# iptables -A INPUT -d 0.0.0.0/8 -j DROP
# iptables -A INPUT -d 255.255.255.255 -j DROP

フラグメントパケット攻撃対策

# iptables -A INPUT -f -j DROP

ステルススキャンの禁止

# iptables -A INPUT -p tcp -m state --state NEW ! --syn -j DROP

IDENT port probe対策

メールサーバ等のレスポンス低下につながるため、DROPではなくREJECTするのがお決まりらしい。

# iptables -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

Ping Flood対策

pingが1秒間に5回を超えたら破棄。

# iptables -A INPUT -p icmp --icmp-type echo-request -m hashlimit --hashlimit 1/s --hashlimit-burst 5 --hashlimit-mode srcip --hashlimit-name input_icmp  --hashlimit-htable-expire 300000 -j DROP

許可する通信

SSHの場合(必須)

これを忘れるとSSH接続できなくなる(笑)ので必ずやろう。

SSHのポート番号を変えてる場合は、忘れずにその番号を指定すること。

# iptables -A INPUT -p tcp -m tcp --dport 50022 -j ACCEPT 

この記事では50022をSSHのポート番号にしたので、それを指定している。

SSH以外の場合(任意)

<port_number> に許可したい番号を入れて、次のコマンドを叩けばOK。

# iptables -A INPUT -p tcp -m tcp --dport <port_number> -j ACCEPT

例えば、Webサーバを立てる場合、HTTP(80番)を許可にすればOKだ。

# iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

デフォルトポリシーの設定

送信は全て許可。受信と転送は全て破棄。受信と転送は明示的に設定した通信のみ許可する方針にした。

# iptables -P INPUT   DROP 
# iptables -P OUTPUT  ACCEPT
# iptables -P FORWARD DROP

ちなみに、何も設定していない状態で、 iptables -P INPUT DROP を実行すると、接続できなくなって詰むので最後に実行している。

確認と設定反映

設定した内容を確認してみよう。

# iptables -L --line-numbers -n

Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
3    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
4    DROP       all  --  10.0.0.0/8           0.0.0.0/0
5    DROP       all  --  0.0.0.0/0            10.0.0.0/8
6    DROP       all  --  172.16.0.0/12        0.0.0.0/0
7    DROP       all  --  0.0.0.0/0            172.16.0.0/12
8    DROP       all  --  192.168.0.0/16       0.0.0.0/0
9    DROP       all  --  0.0.0.0/0            192.168.0.0/16
10   DROP       all  -f  0.0.0.0/0            0.0.0.0/0
11   DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp flags:!0x17/0x02
12   REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:113 reject-with tcp-reset
13   DROP       icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 8 limit: up to 1/sec burst 5 mode srcip htable-expire 300000
14   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:50022
15   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80

Chain FORWARD (policy DROP)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

こんな感じで表示されたら、設定した内容を保存して、iptablesを再起動しよう。

# service iptables save
# service iptables restart

念のため再度ログインできることを確認しておこう。

[localhost ~]$ ssh <user_name>@XX.XX.XX.XX -p 50022

ログインできたら、suしてrootになっておこう。

システムの最新化と自動更新

システムの最新化

さくらの場合、だいたい最新だと思うが、念のためアップデートをかけておく。

$ yum -y update

システムの自動更新

手動でセキュリティパッチを当てるとかダルいので、自動で更新するようにしてしまおう。

まずはyum-cronをインストール。

$ yum -y install yum-cron

で、自動更新を有効にする。

# service yum-cron start
# chkconfig yum-cron on

これでほっといても、最新のパッケージを使ってくれるようになるぞ!

IPv6と不要サービスの停止

IPv6の無効化

さくらでは、IPv4同様、IPv6もフルオープンの設定になっている。

ホントは真面目に設定すべきところだが、メンドウなので、IPv6自体を止めてしまうのが楽。

/etc/sysctl.conf へそのための設定を追記しよう。

# echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf
# echo "net.ipv6.conf.default.disable_ipv6 = 1" >> /etc/sysctl.conf

追記したら、設定の反映をしよう。

# sysctl -p

最後に確認。 inet6 addr という行がなければOKだ。

# ifconfig

PostfixIPv6無効化

さくらではデフォルトでPostfixが有効になっている。コイツもIPv6を使う設定が入っているので、IPv4のみ使うよう修正しておこう。

では /etc/postfix/main.cf を書き換えよう。

# sed -i 's/^inet_protocols\s\+=\s\+all$/inet_protocols = ipv4/' /etc/postfix/main.cf

すると↓のように修正される。

inet_protocols = all
 ↓ "all"を"ipv4"に変更
inet_protocols = ipv4

不要サービスの停止

明らかに不要だと自分で判断できるサービスは止めてしまおう。停止するサービスはこのあたりを参考に検討するとよさげ。

自動起動するサービスの確認

さくらの場合、デフォルトで結構不要なモノが停止されてたりするので、あまり頑張る必要はなさそう。

# chkconfig --list | grep 3:on

acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
blk-availability    0:off   1:on    2:on    3:on    4:on    5:on    6:off
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
irqbalance      0:off   1:off   2:off   3:on    4:on    5:on    6:off
network         0:off   1:off   2:on    3:on    4:on    5:on    6:off
ntpd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
ntpdate         0:off   1:off   2:on    3:on    4:on    5:on    6:off
postfix         0:off   1:off   2:on    3:on    4:on    5:on    6:off
rsyslog         0:off   1:off   2:on    3:on    4:on    5:on    6:off
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
sysstat         0:off   1:on    2:on    3:on    4:on    5:on    6:off
yum-cron        0:off   1:off   2:on    3:on    4:on    5:on    6:off

サービスの停止と自動起動オフ

ここでは、先ほどIPv6を止めて不要になった、ip6tablesを停止してみよう。

# service ip6tables stop
# chkconfig ip6tables off

他にも停止したいサービスがあったら、同じ要領で止めてしまおう。

ログ監視ツールの導入

サーバの初期セットアップも大事だけど日々の運用も大事だよね!

毎日サーバのログを自分で覗きに行くのは大変なので、定期的にログを見て、自動でメールを送ってくれる logwatch を導入してみよう。

rootのメールアドレス設定

事前にroot宛のメールアドレスを設定しておこう。

/etc/aliases にアドレスを追記するだけでおk。 <your_address> には自分のメールアドレスを入れよう。

# echo "root: <your_address>" >> /etc/aliases

では、反映しよう。

# newaliases

最後に送信できるか確認。

# date | mail root

日時だけが書かれたそっけないメールが届けば設定完了だ!

logwatchのインストール

メールアドレスが設定できたので、 logwatchをインストールしよう。

# yum -y install logwatch

logwatchの動作確認

まずは、--printオプションをつけて実行してみよう。実行結果を標準出力してくれるぞ。

# logwatch --print

次に、オプション無しで実行してみよう。

# logwatch

先ほど設定したroot宛にメールが届くはずだ!

ブルートフォースアタック対策

何度も不正アクセスを試みてこられると鬱陶しいよね。

そこで、一定回数ログインに失敗したIPアドレスをBANしてくれる、 fail2ban を導入しよう。

fail2banのインストール

# yum -y install fail2ban

fail2banの設定

SSHのポート番号を変えていると思うので、fail2banの設定にも反映しよう。

/etc/fail2ban/jail.confSSHのポート番号の記述をまとめて書き換える。

# sed -i 's/port=ssh/port=50022/' /etc/fail2ban/jail.conf

すると↓のように修正される。

port=ssh
 ↓ port=sshになってる箇所を、指定したポート番号に変更
port=50022

サービスの起動

では、サービスを起動しよう。

# service fail2ban start
# chkconfig fail2ban on

デフォルトでは、SSHの認証に5回失敗した接続元をブロックしてくれる。

fail2banでは、SSHだけでなく、ApacheDOS攻撃対策などもできる。適宜 /etc/fail2ban/jail.conf を修正して、活用してほしい。

ウィルス対策ソフトの導入

数は多くないがLinuxでもウィルスは存在する。

ってなわけで、オープンソースで提供されている、 Clam AntiVirus(ClamAV) を導入してみよう。

Clam AntiVirusのインストール

# yum -y install clamd

設定の変更と定義ファイルの最新化

まず、root権限で実行するように設定を変更する。

/etc/clamd.conf を更新するコマンドを叩こう。

# sed -i 's/^User\s\+clam$/#\0/' /etc/clamd.conf

すると↓のように修正される。

User clam
 ↓ コメントアウト(#)する
#User clam

次にウィルス定義ファイルを最新化しよう。

# freshclam

サービスの起動と確認

準備が整ったら、サービスを起動しよう。

# service clamd start
# chkconfig clamd on

最後に、動作確認だ。

# clamscan --infected --remove --recursive

不正侵入を検知するツールの導入

ここまでは、不正侵入をされないための設定を色々してきたわけだけど、どれだけ頑張ってもくぐり抜けられる可能性をゼロにはできない。

そこで、万一に備え、不正侵入を検知するツールを導入してみよう。

Rootkit Hunter

Rootkit Hunterはその名の通り、rootkitを検出するためのツールだ。

Rootkit Hunterのインストール

# yum -y install rkhunter

rootkitデータベースのアップデート

# rkhunter --update
# rkhunter --propupd

Rootkit Hunterの確認

rootkitデータベースが最新になったら、検査してみよう。

# rkhunter --check --skip-keypress

Rootkit Hunterは以下のような観点でチェックしてくれる。

  • コマンドが改ざんされていないか
  • rootkitやワームが仕掛けられてないか
  • バックドアトロイの木馬が仕掛けられてないか
  • 起動ファイルに不審な仕掛けがないか
  • パスワードの設定されていないアカウントはないか
  • SSHでrootログインは禁止されているか
  • SSHバージョン1が禁止されているか
  • syslog/rsyslogデーモンは稼働しているか
  • /dev配下に不審なファイルがないか

Tripwire

Tripwireはファイルの改ざんをチェックするツールだ。

Tripwireのインストール

# yum -y install tripwire

サイトキーとローカルキーの生成

最初に、Tripwireを使用するための、サイトキーとローカルキーを生成しよう。

  • サイトキー:設定ファイルやポリシーファイルの暗号化に利用
  • ローカルキー:データベースファイルを使う時などに利用

当然だけど、サイトキーとローカルキーには異なるパスフレーズを設定すること!

何回も入力を求められるけど、頑張って入力してあげよう。

# tripwire-setup-keyfiles

・・・
Enter the site keyfile passphrase: ←サイトキーのパスフレーズを入力
Verify the site keyfile passphrase: ←サイトキーのパスフレーズを再入力
Generating key (this may take several minutes)...Key generation complete.

・・・

Enter the local keyfile passphrase: ←ローカルキーのパスフレーズを入力
Verify the local keyfile passphrase: ←ローカルキーのパスフレーズを再入力
Generating key (this may take several minutes)...Key generation complete.

----------------------------------------------
Signing configuration file...
Please enter your site passphrase: ←サイトキーのパスフレーズを入力
Wrote configuration file: /etc/tripwire/tw.cfg

・・・

----------------------------------------------
Signing policy file...
Please enter your site passphrase: ←サイトキーのパスフレーズを入力
Wrote policy file: /etc/tripwire/tw.pol

・・・

全体的な動作設定

ファイルの追加/削除時に、ファイルとディレクトリの両方で変更検知するのを防止しておこう。

/etc/tripwire/twcfg.txt を編集する。

# sed -i 's/^LOOSEDIRECTORYCHECKING\s\+=false$/LOOSEDIRECTORYCHECKING =true/' /etc/tripwire/twcfg.txt

すると↓のように修正される。

LOOSEDIRECTORYCHECKING =false
  ↓
LOOSEDIRECTORYCHECKING =true

完了したら、暗号化した設定ファイルを作成する。

# twadmin -m F -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key /etc/tripwire/twcfg.txt
Please enter your site passphrase: ←サイトキーのパスフレーズを入力

サイトキーのパスフレーズを聞かれるので、先ほど設定したパスフレーズを入力しよう。

ポリシーファイルの最適化

ポリシーのデフォルトの設定は /etc/tripwire/twpol.txt に書かれているが、これをそのまま使うと、

  • 存在しないファイルのチェックが有効
  • 存在するファイルのチェックが無効

になっている場合があり具合が悪いため、環境に合わせてポリシーを最適化する。

最適化のためのPerlスクリプトCentOSで自宅サーバー構築さんで公開されているので、そのまま拝借させていただく。

扱いやすいように事前にGistに置いておいたので、それを使うことにする。

# wget https://gist.githubusercontent.com/tmknom/035709050cf94ea512ce/raw/d397d9c81c09176413e44da29993841cf4b3bb45/twpolmake.pl -P /etc/tripwire

ダウンロードしたスクリプトを実行しよう。

# perl /etc/tripwire/twpolmake.pl /etc/tripwire/twpol.txt > /etc/tripwire/twpol.txt.new

完了したら、暗号化したポリシーファイルを作成する。

# twadmin -m P -c /etc/tripwire/tw.cfg -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key /etc/tripwire/twpol.txt.new
Please enter your site passphrase: ←サイトキーのパスフレーズを入力

ここでも、サイトキーのパスフレーズを聞かれるので、先ほど設定したパスフレーズを入力しよう。

テキスト版の設定ファイルの削除

tw.cfgとtw.polを生成したら、元になったテキスト版の設定ファイルを必ず削除しよう。

暗号化前のファイルが残っていると、暗号化した意味がなくなってしまうぞ!

# rm -f /etc/tripwire/twcfg.txt*
# rm -f /etc/tripwire/twpol.txt*

ベースラインデータベースの初期化

設定が完了したので、ベースラインデータベースを初期化する。

# tripwire --init
Please enter your local passphrase: ←ローカルキーのパスフレーズを入力

tripwireでは、ベースラインデータベースを基準にファイルの改竄チェックを行っていくことになる。

改ざんチェックの実行

最後に、チェック方法を紹介しておこう。

# tripwire --check

レポートは、 /var/lib/tripwire/report/ に格納される。

ファイルの更新の反映

当然ながらファイルの更新があると、tripwireはレポートに報告を上げてくる。

ほっとくと永久に報告してくるので問題ない更新と判断できたらtripwireに教えてあげよう。

まずは、 /var/lib/tripwire/report/ から最新のレポートを探しだそう

# ls -al /var/lib/tripwire/report/

次に、最新のtwrファイルに対し、次のコマンドを叩こう。

# tripwire -m u -r /var/lib/tripwire/report/xxxxxx.twr

Modified:
[x] "/var/lib/tripwire/xxxx.twd"

すると、viが起動し、行頭に [x] がついた行が途中に見つかるはずだ。これがついているファイルは、次回以降のレポートからは取り上げられなくなる。

なので、内容を確認し、問題がなければそのまま、viでファイルを保存終了(:wq)すればOK。

逆に、次回以降も警告してほしい場合は、"x"を削除し [] としてから、保存終了しよう。

まとめ

最終的にココに書いた内容をFabric化した記事を公開してるので良かったら見てね!

スクリプト化したことで、Vagrantでゴニョゴニョするのと変わらないレベルでセットアップができるようになって個人的には大満足w ∩( ・ω・)∩バンジャーイ

追記:SELinuxについて

SELinuxはさくらのVPSの場合、デフォルトで無効になっている。

# cat /etc/sysconfig/selinux
SELINUX=disabled

ホントは有効にしてちゃんと設定したほうがいいと思うけど、SELinuxの知識があまりないから日和っちゃったw

そろそろマジメに勉強しようかな〜(=゚ω゚=)

参考書籍

Linuxサーバーセキュリティ徹底入門

今回の記事と後編の記事は、この本を教科書にして書き上げた。ブログの記事なので実は省略した部分も多いんだけど、しっかり学びたい場合は一読をオススメするよ!

Macをセットアップしたら最初にやっておきたいオススメの設定

OS X Yosemiteを対象にしています。他のバージョンだと、多少設定方法が異なるかもしれないので、その点はご承知をm(._.)m

f:id:tmknom:20150108171247j:plain

OSのセキュリティアップデート

基本中の基本だが、セットアップ直後は明示的に実行しよう!

App Store→アップデート

セキュリティの設定

アップデートをしたとはいえ、設定的にはノーガード状態なので最低限のセキュリティ設定はしておきたい。

システム環境設定→「セキュリティとプライバシー」アイコンをクリックで設定可能。

ファイアウォール

ファイアウォールは全ユーザ必須だと思う。なぜデフォルトでオフなのか。。

1. 「ファイアウォール」タブ→「鍵」アイコン→パスワード入力
2. 「ファイアウォールを入にする」ボタンをクリック

FireVault

FireVaultを有効にするとディスク暗号化してくれる。特に頻繁に外出先に持ち出す人や、仕事でMacを使っている人はやっておいたほうが良い。

1. 「FireVault」タブ→「鍵」アイコン→パスワード入力
2. 「FireVaultを入にする」ボタンをクリック

キーボードの設定

システム環境設定→「キーボード」アイコンをクリックで設定可能。

Caps Lockキーの設定変更

オススメ。Caps Lock誤入力によるイライラから完全に開放される。

「キーボード」タブ→「修飾キー」ボタン→Caps Lockキーの設定を「Command」に変更

必ずしもCommandキーにする必要はないけど、使用頻度が高いのと、Caps Lockの位置のほうが 個人的にはキー入力をしやすいので、Commandキーを設定している。

ファンクションキーの設定変更

標準のファンクションキーとして振る舞ってくれたほうが便利なので、変更している。

「キーボード」タブ→「修飾キー」ボタン→「F1、F2などのすべてのキーを標準のファンクションキーとして使用」にチェック

トラックパッドの設定

システム環境設定→「トラックパッド」アイコンをクリックで設定可能。

タップしただけでクリック扱いにする

軽くタップしただけで良くなるので、トラックパッドにも指にも優しい。(気がする。)

「ポイントとクリック」タブ→「タップでクリック」にチェック

トラックパッドで右クリックを使えるようにする

普段Windowsも使ってる人は必須。

「ポイントとクリック」タブ→「副ボタンのクリック」を『右下隅をクリック』に変更

その他ジェスチャをいい感じに調教する

ここは完全に個人的な好みの設定だが、備忘録もかねて変更内容を晒しておく。

すべて「その他のジェスチャ」タブから設定可能。

・「ページ間をスワイプ」を「3本指でスワイプ」に変更
・「フルスクリーンアプリケーション間をスワイプ」を「4本指で左右にスワイプ」に変更
・「アプリケーションExpose」にチェック

Dockの設定

システム環境設定→「Dock」アイコンをクリックで設定可能。

自動的に隠す

オススメ。この設定をしておくと、画面を広く使える。

「Dockを自動的に隠す/表示」にチェック

アニメーションを有効にする

グリグリ動いてくれたほうがテンションが上がるので、設定しておく。

「拡大」にチェック

日付を表示する

意外と日付を知りたくなる時があるので、日付も表示しておく。

「日付と時刻」アイコン→「時計」タブ→「日付を表示」にチェック

サウンド音量の表示

サウンドをオン/オフを結構頻繁にやるので、音量を表示しておく。

「サウンド」アイコン→「メニューバーに音量を表示」にチェック

Mission Controlの設定

完全に個人的な好み。

「Mission Control」アイコン→「ホットコーナー」ボタン→右下に「Mission Control」を設定

Finderの設定

Finderの設定変更は、Finderを起動してから行うことができる。

Finderで拡張子を表示する

拡張子が表示されてないと夜も眠れない人は必須。

Finder→環境設定→「詳細」タブ→「すべてのファイル名拡張子を表示」にチェック

Finderの表示のカスタマイズ

いろいろ表示してくれといたほうが便利なことが多いので、設定しておく。

表示→「タブバーを表示」を選択
表示→「パスバーを表示」を選択
表示→「ステータスバーを表示」を選択

バッテリー表示を割合(%)表示に変更する

バッテリーのアイコンだけだと、どのくらいバッテリーが残ってるかよく分からないので設定しておく。

右上のバッテリーのアイコンをクリック→「割合(%)を表示」をチェック

おわりに

この記事を書いたあとにMacクリーンインストールしてみたけど、こういう備忘録があるとすぐに好みの状態に復活させられるので地味に便利。

まだ全然Macのポテンシャルを引き出せてるとは思えないので、オレの考える最強のMacの設定を教えてやんよ!って方はぜひご連絡を。本記事で紹介させていただきます!(・∀・)