Ubuntuのインストール後にやるべきセキュリティ設定まとめ

から | |
このエントリーをはてなブックマークに追加

Ubuntuをインストールした後に行うべきセキュリティ設定をまとめます。サーバー版／デスクトップ版の両方に対応できるように書いたつもりです。もし、勘違いや記載ミスがありましたら、ご指摘いただけると幸いです。

本投稿で実施する事は下記。

  • 自動的にセキュリティアップデートをする設定
  • ユーザー毎のセキュリティ設定
  • SSHサーバのセキュリティ設定
  • カーネルのセキュリティ設定
  • MySQLのセキュリティ設定
  • iptablesによるパケットフィルタリング

自動的にセキュリティアップデートをする設定

Ubuntuの初期インストールの最後に、セキュリティアップデートを自動的に行いますか？と聞かれた覚えがあると思います。その設定を再度、下記コマンドで行う事が出来ます。構築後、放置してしまう事が多いので、もし、何かあったらすぐに対処できるような環境であれば、自動アップデートにしておくと良いかと思います。

sudo dpkg-reconfigure -plow unattended-upgrades

# 未インストールの場合には下記を実行する事でインストール可能。
# sudo apt-get install unattended-upgrades

ユーザー毎のセキュリティ設定

インストール直後の状態だと、他のユーザーのホームディレクトリのパーミッションが755になっているため、見るだけであれば、他のユーザーのホームディレクトリの中を見る事が出来ます。1人しかユーザーがいない場合には気にならないかもしれませんが、www-data等のウェブサーバ実行ユーザーから見れてしまうのもまずいので、パーミッションを変更しておきます。

sudo chmod 0750 /home/$USER
sudo sed -i "s/DIR_MODE=0755/DIR_MODE=0750/g" /etc/adduser.conf

SSHサーバのセキュリティ設定

Ubuntuの初期インストールの最後に、セキュリティアップデートを自動的に行い ますか？と聞かれた覚えがあると思います。その設定を再度、下記コマンドで行う事が出来ます。構築後、放置してしまう事が多いので、もし、何かあったらす ぐに対処できるような環境であれば、自動アップデートにしておくと良いかと思います。

sudo vi /etc/ssh/sshd_config

sshd_configの中で設定されている下記のオプションについて、設定を見直します。

PermitRootLogin
オプション セキュリティ強度 コメント
without-password △(○に近い) rootのみ公開鍵認証を強要する
yes × sshで直接rootログインを試行できるのはセキュリティ上問題がある
no ○ お勧め。rootになりたければ、sudoersグループのメンバ(初期インストールしたユーザーはデフォルトで所属)でログインしてから、sudo su – する事によって、rootになるまでに2段階を踏める

 

PasswordAuthentication
オプション セキュリティ強度 コメント
yes △ SSH経由でのパスワード認証によるログインを許可する。例えば、test/testuserpasswordみたいな感じで。
no ○ SSH経由でのパスワード認証によるログインを許可しない。noにしたとしても、SSHが関係ないコンソールからのログインはパスワード認証を使えます。設定を直す前に、sudoersグループに属するユーザー(デフォルトではインストール時に作った一般ユーザー)でssh-kengenで公開鍵を作っている事を確認する事。windowsの場合：ssh-keygenで作った鍵をputtyとWinSCPで使えるようにするLinux/Macの場合：Linux、macOSから対象サーバへパスワード無しで高速ログインする

sshによるログインを許可するグループを作成し、そのグループに所属するユーザーのみ、SSH経由でのログインを許可する。

sudo addgroup sshlogin
sudo gpasswd -a $USER sshlogin
echo "AllowGroups sshlogin" | tee -a /etc/ssh/sshd_config

 

カーネルのセキュリティ設定

/etc/sysctl.confに関するセキュリティ設定です。主にSYN FOODへの対策等です。

sudo vi /etc/sysctl.conf
net.ipv4.tcp_syncookies
オプション セキュリティ強度 コメント
0 △ SYN FLOODの予防。詳細はhttp://lwn.net/Articles/277146/参照。
1 ○ デフォルトで1になっているはず。cat /proc/sys/net/ipv4/tcp_syncookiesで確認可能。0になっているようだったら変更を検討する

 

net.ipv6.conf.all.disable_ipv6
オプション セキュリティ強度 コメント
0 – ipv6を有効にする場合に指定。
1 – ipv6を無効にする場合に指定。

 

net.ipv6.conf.default.disable_ipv6
オプション セキュリティ強度 コメント
0 – ipv6を有効にする場合に指定。
1 – ipv6を無効にする場合に指定。

MySQLのセキュリティ設定

MySQLをインストールしている場合の最低限のセキュリティ設定を下記のコマンドで実行できます。wordpress等を用いている場合にはやっておくと良いと思います。

# MySQLのセキュリティ設定を行う。
# 具体的には、rootのパスワード設定とゲストアカウントの無効化、
# それと、リモートからのrootログインの無効化。
# 最初は、mysqlをインストールした時と同じパスワードを回答し、
# それ以降はEnterキーを4回押すのみ。
sudo mysql_secure_installation

 

iptablesによるパケットフィルタリング

ufw等、他にもやり方はあるのですが、一番基本的なiptablesで記載しておきます。iptablesによるパケットフィルタリングは奥が深く、聞くエンジニアによってもお作法と言うかポリシーがあり、どんな設定方法が良いかは明確には言えません。

ただ、駄目な設定だけは解ります。『○○の攻撃をブロックする為に、ググって拾ってきた○○の攻撃を拒否する設定を行って、それ以外は許可する』と言う設定だけはダメです！！『この世界に存在するネットワークを介したあらゆる攻撃手法と、今後生み出される攻撃手法を網羅できていますか？』と言う問いに『YES』と自信を持って答えられる人はいないはずです。よって、本投稿でお勧めすするのは『最小限の手間でコストパフォーマンスの良いファイアウォール設定』です。

適当なディレクトリにでも、iptables.shとして保存しておき、sudo iptables.shとして実行してください。ルールを書き換えたくなったら毎回sudo iptables.shすれば良いだけで、OS再起動時にも勝手にルールを読み込んでくれます。

#! /bin/sh

# ルール設定中のみ一時的に許可する
iptables -F
iptables -P OUTPUT ACCEPT
iptables -P INPUT  ACCEPT

# lo(ループバック)は無条件で許可
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# 拒否するルールを入れるのはここ。
# ○○のIPから踏み台にされている等、あからさまな攻撃元IPを指定する。
# 注意してほしいのは、下記はVPS上でグローバルIPを持っている環境下での設定。
# NATの下(ルータの配下)のサーバには下記の設定をする必要は無く、
# 水際のインターネットに晒されているLinuxルータ等で設定されていれば良い。
# 192.168.1.1/24等を使っているようなLAN内のLinuxサーバに指定してしまうと、
# ここのフィルタルールで全パケットを拒否してしまうので注意。
iptables -A INPUT -i eth+ -s 127.0.0.0/8 -j DROP
iptables -A INPUT -i eth+ -s 192.168.0.0/16 -j DROP
iptables -A INPUT -i eth+ -s 172.16.0.0/12 -j DROP
iptables -A INPUT -i eth+ -s 10.0.0.0/8 -j DROP

# ログを取ってDROPしたいような設定があれば、ここに記載するのが良いかも。

# クライアント用途で許可するポート（一例です）
# eth+と言う指定は、eth0,eth1...にマッチします。
iptables -A INPUT  -i eth+ -p udp -m multiport --sport 53,123 -j ACCEPT
iptables -A OUTPUT -o eth+ -p udp -m multiport --dport 53,123 -j ACCEPT
iptables -A INPUT  -i eth+ -p tcp -m multiport --sport 22,25,53,80,443,465,587 -j ACCEPT
iptables -A OUTPUT -o eth+ -p tcp -m multiport --dport 22,25,53,80,443,465,587 -j ACCEPT

# サーバー用途で許可するポート
# 一例として、開けているのは下記の通り
# 80 : http（Apacheやnginx）
# 443 : https（ApacheやnginxでSSL設定を行っている場合）
iptables -A INPUT  -i eth+ -p tcp -m multiport --dport 80,443 -j ACCEPT
iptables -A OUTPUT -o eth+ -p tcp -m multiport --sport 80,443 -j ACCEPT

# 管理目的で利用しているssh等
# ポート番号は22から2222等へ変更して、sshdの待ち受けポートを変更しても良いかも。
iptables -A INPUT  -i eth+ -p tcp -m multiport --dport 22 -j ACCEPT
iptables -A OUTPUT -o eth+ -p tcp -m multiport --sport 22 -j ACCEPT

# icmp。--icmp-typeでタイプ指定も出来ます。その辺はお好みで。
iptables -A INPUT -i eth+ -p icmp -j ACCEPT
iptables -A OUTPUT -o eth+ -p icmp -j ACCEPT

# 最後に全部DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# /etc/iptables.rulesに保存。
# OS起動時には、/etc/network/interfacesに指定した
# pre-up iptables-restore < /etc/iptables.rulesを使って読み込む
iptables-save > /etc/iptables.rules

後、大事なことですが、ipv6が間違って上がってしまっていた場合に、『ipv6経由はファイアウォールを設定していなくてフルオープンでした（てへｗ』と言う事が無いように、下記の設定もしておいてください。使っていないのであれば、全部DROPで！！

sudo ip6tables -P INPUT  DROP
sudo ip6tables -P OUTPUT  DROP
sudo ip6tables -P FORWARD  DROP
ip6tables-save | sudo tee /etc/ip6tables.rules

/etc/network/interfacesには、下記のように設定しておきます。pre-up iptables-restore < /etc/iptables.rulesで、OS再起動時にルールを読み込みます。このやり方はIptablesHowToに書かれています。

auto lo
  iface lo inet loopback

auto eth0
  iface eth0 inet static
  address 192.168.1.252
  netmask 255.255.255.0
  network 192.168.1.0
  broadcast 192.168.1.255
  gateway 192.168.1.1
  dns-nameservers 192.168.1.1
  pre-up iptables-restore < /etc/iptables.rules
  pre-up ip6tables-restore < /etc/ip6tables.rules

上記のiptablesの設定で、ウェブサービスを提供する80,443とSSHを提供する22以外に対する外部からのアクセスは無視するようになりました。内側から外側への通信もかなり厳しく制限してあり、UDPの53,123とTCPの22,25,53,80,443,465,587を宛先にするパケットしか許可していませんが、apt-getによる更新は出来るので問題ないと思います。

iptablesによって、サービスを提供する為に開けているポート、、、この例だと、HTTP(80)、HTTPS(443)、SSH(22)に対しては、ファイアウォールは全く守ってくれません。ですので、それらのポートを開けているサーバであるApacheやnginxのセキュリティ設定は別途詰める必要があります。もしも、ウェブアプリケーションを提供しているのであれば、そのウェブアプリケーションがセキュリティを意識して作られている事が前提です。

それとSSHサーバのセキュリティ設定は本投稿でもふれていますので、実施しておいてください。

最後に

ざっと、Ubuntuを初期インストールした後に実施すべきセキュリティ設定を紹介したつもりです。特に、ファイアウォールの設定については、ipv6を使っていない事を考慮した設定にしました。間違いや、『これも実施しておいた方が良いよ』等のご意見・ご指摘があればコメント頂けますと嬉しい限りです。

タグ , , , . ブックマークする パーマリンク.

Ubuntuのインストール後にやるべきセキュリティ設定まとめ への2件のフィードバック

  1. 匿名 の発言:
    @

    “unattended-upgrades”は、ソフトウエアサプライチェーン攻撃に対して無力なので、削除しておいたほうが良いのではと思うのですが、・・・。私は削除してしまいました。
    アップグレードは”apt upgrades”をcroneで動かして対応しています。インターネット用マシンです。
    記事を読んで、基本使わないので、設定するよりもopenssh-clientを削除してしまおうかと考えています。

    返信
    • lasas の発言:
      @

      コメントありがとうございます。
      誤記かもしれませんが、勘違いされている箇所があるようですので、下記の通り回答させていただきます。

      openssh-clientは、22/TCPでListenしません。22/TCPでListenするopenssh-serverを利用していないようでしたら、SSHサーバを止めてください。削除でも問題ありません。
      なお、openssh-clientは、SSHのクライアントかと存じます。外部にSSH接続するために利用しますが、内部に侵入を許した後に、他のマシンに攻撃する為利用されることも考えられるので、不要ならあわせて削除しても良いかと思います。

      ソフトウエアサプライチェーン攻撃は、SolarWindsの事例が有名ですね。ソフトウェアを導入した後、アップグレードしないまま運用していた為、たまたま攻撃を受ける前のバージョンを使っていて助かった等と言う笑い話も聞きます（と言うかその実例を目前にして安堵した事があります）。
      unattended-upgradesと、cronでapt upgradeを定期実行するのは殆ど変わらないことなので、cronでapt upgradeを回したからと言って、ソフトウェアサプライチェーン攻撃を防ぐことは出来ないかと思料します。

      ソフトウエアサプライチェーン攻撃の怖いところは、既に配布元が侵されている事に気付かぬまま、長期間それを信用して多くの人がパッケージのアップグレードをしてしまう点かと思います。
      この場合、人の目でアップグレードをしても、気付けることはありません。チェックサム等もあっているのですから。

      現在、そのような攻撃に対処するための予防策としては、「不正に内部に忍び込まれる」事を防止すれば良いかと推察します。そのためには、以下のようなことが出来るかと思います。他にもあったら教えてください。

      ■　予防策（間違って不正なバックドアが入ってしまった場合の活動防止方法含む）
      ・セキュリティ対策に力を入れているベンダ、ディストリビューションの製品を利用する＜配布元がきちんと対策しているか、対策費用を持っているか等、見切れない箇所も多い為、必然的に規模が大きく予算も多いベンダを採用することに
      ・IPレベルで関係のない国との通信はIN/OUT共に遮断
      ・外部へ出る通信はホワイトリスト方式とする。
      ・C＆Cサーバとの通信を不可とさせる（プロバイダ側で対策してくれていることも多い）
      ・次世代型アンチウイルス製品（実行ファイルの挙動で検知するタイプの製品）の導入とその適切な運用
      ・不審な挙動に気付けるよう、常日頃からマシン状態をログやトラフィック流量、接続ログから把握しておき、不審な点を気付けるようにしておく

      ＞“unattended-upgrades”は、ソフトウエアサプライチェーン攻撃に対して無力なので、削除しておいたほうが良いのではと思うのですが
      基本的に外部にさらしているサーバはソフトウェアの最新化がベストプラクティスです。
      ソフトウエアサプライチェーン攻撃は配布元への攻撃の結果発生する2次被害と言うべきものですので、「運よくパッケージが古すぎて良かった」を狙うのであれば、他の脆弱性更新をしないリスクを受容したうえで、ISOで配布されているOSイメージはある程度安心と信じ、そこから一切更新しないのも手かと思います。
      以上から、どちらに舵を切るかは環境ごとの特性を加味して、判断をお願いいたします。

      返信

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。