sshd_configによる接続制限

接続元のIP制限を行うとき、一番お手軽なのはやはりTcpWrapperによる制限

しかしこれだとTCPレベルで一括制限され、ユーザ別の判定はできないので、ユーザ別やグループ別に制限したいときはsshdで制限するのがよろしいかと。

1.sshd_configを編集

2.sshd再起動

以上。

 

参考URL)

 

TcpWrapperによるSSHのIP制限

・環境はCentOS5.5および7.2

1.設定ファイルバックアップ

2.許可する接続元を指定

“hosts.allow”に許可する接続元を指定。”hosts.deny”で全接続を拒否。

3.許可されていない接続元から接続できないことを確認

OK.

 

参考URL)

SSHのIPアクセス制限 まとめ

 

社内用プロキシサーバの作成

複数のサーバを運用している場合、それぞれのサーバにどこからでも接続できる状態だと、セキュリティやスタッフ管理の面でよろしくないので、プロキシサーバを使用してセキュリティを高める。

 

1.プロキシ用サーバ作成

まずプロキシ用のバーチャルサーバを立ち上げ、NICや必要なIP(最低限グローバルとローカル1つずつ)を割り当てる。
やり方については各ベンダーでマニュアルなど用意していると思うので割愛する。

なおスペックについては、SSHトンネルするだけなので、最低限のリソースでOKかと思う。
今回はCentOS7.2 Xen 64bitを使用した。

 

2.ユーザ作成

弊社の場合は某社のクラウドなので最初はVPN接続してログインユーザ作成

ちなみにAWSであればec2-userなどで最初からログインできるので上記は不要

 

3.rootログイン禁止

使いやすいPuttyやPoderosaなどのSSHクライアントで接続

・sshのrootログイン禁止

 

4. ファイアウォールの設定

今回はポート10022(ssh用)だけを許可する。

やり方はこちらを参照。

 

5. sshのポート番号変更

攻撃回避のためssh用のポートを22から10022に変更する。

やり方はこちらを参照。

 

6. 不要サービスの停止

・必要最低限のサービスだけで動かしたいので不要なものは停止する。

判断はこちらとほぼ同じ
違いはcron停止、firewalld残し。

・SELinuxも無効に

 

7. スタティックルーティングの設定

弊社の場合ローカルネットワークのセグメントがもう1つあり、そちらのセグメント(172.18.0.0/16)にも接続できるようにするためスタティックルーティングの設定を行う。

・ローカルネットワークのデフォルトルーティング設定ファイルを無効化(デバイス名をeth1とした場合)

⇒ No such file or directoryとなっても、もともと無いのでそのままでOK

・別セグメント(172.18.0.0/16)へのルート設定追加

・ネットワーク再起動

(service network restartでも一応いける)

ちなみにCentOS7から採用されたnmcliで行うときは、

のようなコマンドを打つが、ベンダーの仕様の関係なのか、eth1もeno1もnmcliでは認識されていなかった。
ただNetworkManagerは動いてるのでipコマンドは通る。昔の名前(eth**)でデバイス名が認識されていた。
やり方あるのかもしれんがネットワークは疎通してるのでまあいいか。

nmtuiで行う方法もあるらしいが、TUI画面は起動したがなぜかうまく動かなかった、、、。

・ルート確認

ちなみにベンダー側のコンソールでネットワークの再構築を行うとどうなるか。
→案の定スタティックルーティングの設定が初期化された
→ネットワーク再構築をしたら、再度スタティックルートの設定を行う必要あり。

・疎通確認

OK。

 

以上で基本的なプロキシ構成は完了。

プロキシを使用するスタッフ数分、useraddしてユーザを作成し、それぞれ接続して使用する。
あとは必要に応じて鍵認証にしたり、IP制限したり、トンネルするときのやり方を社内で決めてあげればOK。

スタッフが辞めた場合は、userdelしてそのスタッフ用のユーザを削除してやればOK。

 

参考URL)

 

CentOS7でSSHのポート変更

  • 現在の状態を確認

  • sshd_configの修正

  • sshd再起動

  • firewalldの設定からSSHを削除

  • firewalldの設定にssh-10022を追加

既存のssh.xmlをコピーしてssh-10022.xmlを作成する

ssh-10022.xmlファイル内のポート番号を22から10022に変更する

ファイアウォール設定に追加

 

  • firewalldをリロード

  • 変更後の状態を確認

 

参考URL)

CentOS7でファイアウォールの設定

  • サービス状態確認

※”…/firewalld.service; disabled;”になっているので自動起動無効

  • 自動起動するように設定

  • サービス起動

  • 現在の有効な設定を確認

  • sshの設定を追加(22番ポートを許可)

  • mysqlの設定を追加(3306番ポートを許可)

  • 削除する場合

  • 設定一覧を表示(必要に応じて)

  • 再度設定を確認

※mysqlとsshが追加された

 

  • ちなみにiptables使う場合

インストール方法は割愛
※firewalldと併用でないのでiptablesを使う場合はfirewalldは停止する

 

参考URL)

apacheのバーチャルホスト設定

すでにバーチャルホスト無しで動いている環境で、バーチャルホストを追加する場合の設定。すぐ忘れるのでメモ。

以下条件。極力オリジナルのhttpd.confは触らない方針で。

  • OS:CentOS 5.5
  • WEBサーバ:Apache 2.2.3
  • apache設定ファイルを置くディレクトリ:/etc/httpd/conf.d

最初にまず、デフォルトのServerNameを無効化。

バーチャルホスト用の設定ファイルを作る。

 

以下のように記述。
ポイントは、デフォルトのドメインでアクセスしたときの設定も<VirtualHost>ディレクティブで改めてしなければならないということ。
つまりバーチャルで追加したいFQDNのバーチャルホスト設定をしただけではダメ。

 

参考URL)

またまたcerbot-auto renewでエラー

以前書いた記事とは異なる現象。

CRONで自動更新設定したはずなのに、なーんかまた更新案内メール来てるので、、。

どうやら今回は下記のエラーが発生している模様。

pipをアップグレードしろみたいなことが書いてあるが、、

最新版なんですけど。

 

調べた結果、cerbot-autoスクリプトのpycparserハッシュがおかしいとか。

※今回のcerbot-autoの更新では「pycparser==2.14」ではなく「pyparsing==2.1.8」となっている模様。

これで無事renewも通りました。

を忘れずに。

以下参考サイト)

Let’s Encryptが急に動かなくなった件(THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE.)

https://community.letsencrypt.org/t/certbot-auto-fails-while-setting-up-virtual-environment-complains-about-package-hashes/20529/24

cerbot-auto renew でpythonパッケージのインストールが進まない

letsencryptの証明書更新時に、「cerbot-auto renew」でpythonパッケージのインストールが進まない話。
→ 結果、待つしかない(笑)

導入編は、こちらを参照。

さてcronによる証明書の自動更新設定を行っていたはずだが、下記のような「期限が迫ってるよ~。早く証明書更新してね~。」的なメールが届く。
———————————————
Hello,

Your certificate (or certificates) for the names listed below will expire in
9 days (on 12 Mar 17 08:02 +0000). Please make sure to renew
your certificate before then, or visitors to your website will encounter errors.

hoge.jp

For any questions or support, please visit https://community.letsencrypt.org/.
Unfortunately, we can’t provide support by email.
(以下略)
———————————————

おかしーなーと思ってrootあてのメールを見ると、以下のメッセージが。
———————————————

FATAL: Amazon Linux support is very experimental at present…
if you would like to work on improving it, please ensure you have backups
and then run this script again with the –debug flag!

———————————————

debugフラグをつけてコマンドを実行せい!とのことなので、言われたとおりにやってみるが、、

———————————————
# /usr/local/src/letsencrypt/certbot-auto renew –debug
->
Bootstrapping dependencies via Amazon Linux…
yum is /usr/bin/yum
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main/latest | 2.1 kB 00:00
amzn-updates/latest | 2.3 kB 00:00
epel/x86_64/metalink | 6.0 kB 00:00
epel/x86_64 | 4.3 kB 00:00
epel/x86_64/updateinfo | 741 kB 00:00
epel/x86_64/primary_db | 5.9 MB 00:00
remi-safe | 2.9 kB 00:00
remi-safe/primary_db | 718 kB 00:04
991 packages excluded due to repository priority protections
Package gcc-4.8.3-3.20.amzn1.noarch already installed and latest version
Package augeas-libs-1.0.0-5.7.amzn1.x86_64 already installed and latest version
Package 1:openssl-1.0.1k-15.96.amzn1.x86_64 already installed and latest version
Package 1:openssl-devel-1.0.1k-15.96.amzn1.x86_64 already installed and latest version
Package libffi-devel-3.0.13-16.5.amzn1.x86_64 already installed and latest version
Package system-rpm-config-9.0.3-42.28.amzn1.noarch already installed and latest version
Package ca-certificates-2015.2.6-65.0.1.16.amzn1.noarch already installed and latest version
Package python27-2.7.12-2.120.amzn1.x86_64 already installed and latest version
Package python27-devel-2.7.12-2.120.amzn1.x86_64 already installed and latest version
Package python27-virtualenv-12.0.7-1.13.amzn1.noarch already installed and latest version
Package python27-tools-2.7.12-2.120.amzn1.x86_64 already installed and latest version
Package python27-pip-6.1.1-1.23.amzn1.noarch already installed and latest version
Nothing to do
Creating virtual environment…
Installing Python packages…
——————————————————————————-
この状態でうんともすんとも言わなくなった!
10分待とうが20分待とうが進まないので、再度コマンド発行して、一日放置してみるも、無操作によりsshクライアントとの接続が自動切断、、、

翌週、気を取り直してもう一度試すと、、、え?通った!
——————————————————————————-

Installation succeeded.
Saving debug log to /var/log/letsencrypt/letsencrypt.log

——————————————————————————-
Processing /etc/letsencrypt/renewal/hoge.jp.conf
——————————————————————————-
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for hoge.jp
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0001_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0001_csr-certbot.pem

——————————————————————————-
new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/hoge.jp/fullchain.pem
——————————————————————————-

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/hoge.jp/fullchain.pem (success)
——————————————————————————-

最初はpipのミラーサイトがダメになったのかな?とも思っていろいろ調べたが、結局通信状態の問題もしくは一時的にミラーが落ちてたっぽい。
とりあえず待つしかなかったってことね。

参考サイト)

 

Amazon LinuxでletsEncryptを導入

今回使用したamazon linuxのバージョンは以下。
——————————-
# cat /etc/system-release
-> Amazon Linux AMI release 2016.09
——————————-
WEBサーバはapache2.4。なおWEBサーバの設定の詳細は割愛します。

githubからletsencryptインストール
——————————-
# cd /usr/local/src
# git clone https://github.com/letsencrypt/letsencrypt
# cd letsencrypt
# sudo ./letsencrypt-auto –help –debug
——————————-

※使用するドメインで外部から80番にアクセスできないと認証できないので、あらかじめファイアウォールの解放と、httpd.confの設定を行っておきます。

証明書作成
——————————-
# ./letsencrypt-auto certonly –standalone -d ドメイン名
——————————-

画面の案内に沿って進める。
完了後、サーバ証明書が作成されているか確認
——————————-
# ls -lat /etc/letsencrypt/live/
——————————-

作成した証明書を、ssl.confに指定
——————————-
# vi /etc/httpd/conf.d/ssl.conf
->
:
SSLCertificateFile /etc/letsencrypt/live/ドメイン名/fullchain.pem
:
SSLCertificateKeyFile /etc/letsencrypt/live/ドメイン名/privkey.pem
:
——————————-
※fullchain.pemを指定した場合は中間証明書(SSLCertificateChainFile)の指定は不要。

WEBサーバリロード
——————————-
# service httpd reload
——————————-

ブラウザなどでhttpsでアクセスして証明書が効いているかチェック

更新用コマンド
——————————-
# /usr/local/src/letsencrypt/certbot-auto renew
——————————-

自動更新設定
——————————-
# vim /etc/crontab
——————————-
->
# letsencrypt renew #####
5 4 * * * root /usr/local/src/letsencrypt/certbot-auto renew && /etc/init.d/httpd reload
#########################
——————————-
※ちなみにcerbot-autoが使えるのはpython2.7以降。それ以前の場合は「/usr/local/src/letsencrypt/letsencrypt-auto」を使う

 

参考リンク)

OpenSSLでPKCS12ファイルの解凍

主にSSLサーバ証明書の設置や更新のための1手段。

まず、対象のPKCS12ファイルを、WinSCPなどのFTPクライアントやSSHクライアントを使い、サーバのユーザホームディレクトリ等に転送。

ここでは、
転送したPKCS12ファイルの場所を、
/home/userdir/PKCS12.pfx
サーバ証明書と中間証明書の展開先を、
/etc/httpd/conf/ssl.crt/
秘密鍵の展開先を、
/etc/httpd/conf/ssl.key/
とする。

展開時にファイルは上書きされるので、過去のものがあれば念のため各ファイルのバックアップ取得
# cp /etc/httpd/conf/ssl.crt/clcert.crt /etc/httpd/conf/ssl.crt/clcert.crt.bak
# cp /etc/httpd/conf/ssl.crt/cacert.cer /etc/httpd/conf/ssl.crt/cacert.cer.bak
# cp /etc/httpd/conf/ssl.key/privatekey.key /etc/httpd/conf/ssl.key/privatekey.key.bak

#サーバ証明書解凍
# openssl pkcs12 -in /home/userdir/PKCS12.pfx -clcerts -nokeys -out /etc/httpd/conf/ssl.crt/clcert.crt

#中間証明書解凍
# openssl pkcs12 -in /home/userdir/PKCS12.pfx -cacerts -nokeys -out /etc/httpd/conf/ssl.crt/cacert.cer

#秘密鍵解凍
# openssl pkcs12 -in /home/userdir/PKCS12.pfx -nocerts -nodes -out /etc/httpd/conf/ssl.key/privatekey.key

上記各々のコマンドで、解凍パスワードを求められるので入力すると、目的の場所にファイルが展開される。

後は、必要に応じて、ssl.conf内の各ファイルのパスを指定し、WEBサーバのリロードまたは再起動。

# リロードする前に文法チェック
# service httpd configtest

# リロード
# service httpd reload