SMTPSとIMAPSで安全なセキュアなメールサーバーを作る

AWSにメールサーバーを移設した際に、STARTSSLからSMTPSとIMAPSの環境に変更したので、そのメモ


環境:
AWS EC2 (Amazon Linux AMI 2017.09.1 (HVM), SSD Volume Type)

セキュリティグループ:
22/tcp , 25/tcp, 80/tcp(Let’s Encryptの認証用に一時的に開ける), 465/tcp, 993/tcp を開けておく。


必要なパッケージをインストール

yum install postfix dovecot cyrus-sasl cyrus-sasl-plain

LetsEncryptでメールサーバー用の証明書を発行
wordpress をELB+EC2でHTTPS通信させる
を参照


(SMTPSに必要な箇所のみ記載)
/etc/postfix/postfix.cf

smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination

smtp_tls_security_level = may
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.jhhk-family.net/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.jhhk-family.net/privkey.pem
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
tls_high_cipherlist = kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!RC4:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES
smtp_tls_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_mandatory_ciphers = high

/etc/postfix/master.cf

smtps     inet  n       -       n       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

smtpd_client_restrictionsは未設定。必要に応じて。

/etc/dovecot/conf.d/10-auth.conf

auth_mechanisms = plain
!include auth-system.conf.ext

/etc/dovecot/conf.d/10-ssl.conf

ssl = yes
ssl_cert = </etc/letsencrypt/live/mail.jhhk-family.net/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.jhhk-family.net/privkey.pem
ssl_protocols = !SSLv2 !SSLv3 !TLSv1
ssl_cipher_list = HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!RC4:!3DES:!RSA

/etc/dovecot/conf.d/10-master.conf

service imap-login {
#  inet_listener imap {
#    port = 143
#  }
  inet_listener imaps {
    port = 993
    ssl = yes
  }

最後にpostfix、dovecot、saslを起動する。

service saslauthd start
service postfix start
service dovecot start

Apache Killerの対策

8/24に会社から連絡があり、取り急ぎ対策が必要なApacheには、アドバイザリ通りの記述行い対策しました。
おかげでエヴァ波の地上波の前半を見逃した・・・orz

# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (?:,.*?){5,5} bad-range=1
RequestHeader unset Range env=bad-range

# We always drop Request-Range; as this is a legacy
# dating back to MSIE3 and Netscape 2 and 3. RequestHeader unset Request-Range

あと、仕事上付き合いがある徳丸氏のブログにも本件について書かれており、MaxClientsのチューニングが重要だと。

ウチもApache2.2を使っているが、MaxClientsのデフォルト値は150だった。
Apache Killerの対策をしないと、MaxClients150×24MBで、3600MB(約3.5GB)のメモリをApacheだけで食う事になる。

契約しているVPSはメモリ1GBコースだから、無理www

つーことで、httpd-mpm.confのMaxClients数を25に落とす。
こんな寂れたブログを見に来る人もいないだろうからw

–2011.8.31 追記–
8/30に2.2.20がリリースされました。
http://archive.apache.org/dist/httpd/httpd-2.2.20.tar.bz2

apache2.0系はまだ未リリースみたい。
暫定対策が済んでいないapacheがあれば、至急アップデートを行いましょう。

Apache周りのセキュリティ

昨年末からいろいろあって、全てのWEBサーバのセキュリティ診断を行っています。

診断は、業界では有名なLAC社に委託をしているので、技術力は問題無いのですが、その指摘の細かさに驚きつつ、そんな穴誰も突付かないだろw(決してラックには言えませんが・・・)
とツッコミつつも、ミドルウェアの設定を変更したりバージョンアップを行っています。

で、その中では僕の認識が甘かった部分や、知らなかった物が何個もあったので、その対策とかのメモ。

【Apache】
 (1)ローカルユーザー情報の漏洩
    Userdir public_htmlとかなっていると、
    http://ドメイン/~存在するユーザー名   ・・・ Forbbiden
    http://ドメイン/~存在しないユーザー名  ・・・ Not Found
    となり、生きてるユーザーがいる事が分かってしまう。

    まぁ、会社のシステムでは使っていない機能なので停止。    
    Userdir disabled

 (2)エラーページからシステム情報の漏洩
    デフォルトだと400系や500系の時にApache情報が記載されるので、
    そこから脆弱性が漏れる可能性がある。
    ServerTokens Prod
    ServerSignature Off

【SSL】
 (3)脆弱な暗号化(SSLv2)のサポート
    SSLv2をサポートしている事自体がダメなんだって。
    SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:!SSLv2:+Exp:+eNULL
    SSLProtocol ALL –SSLv2

【PHP】
 (4)PHPトラッカー情報の漏洩
    これもシステム情報の漏洩系。
    expose_php = Off

FTPとSFTPの使用制限

会社の公開FTPサーバ。
何故かFTPユーザーにもbashが付与されており、さらに外部業者とのやり取りはインターネットを介して行われる為、パケットキャプチャされたらユーザー名とパスワードがバレバレな状況で稼動していました。
ディスクも8GBの物を使用していた為、ディスク増設を期にセキュリティを上げる事にします。
外部からの接続は、FTPからSFTPに。
さらに事業部毎でデータ容量が違うので、quotaを設けます。
・quota使用の宣言
fstab内の、容量制限を行なうパーティション欄に”usrquota”を追記する。
今回は、/homeに対してquotaを掛ける。
vi /etc/fstab
LABEL=/home /home ext3 defaults,usrquota 1 2
・/homeの再マウント
quota使用する為、パーティションの再マウントを行なう。
mount -o remount /home
・quota設定のデータベース作成
quotacheck -cumv /home/
・ユーザ毎のquota設定
edquota hogehoge
Disk quotas for user hogehoge (uid 501):
Filesystem blocks soft hard inodes soft hard
/dev/hda5 36 9961472 10485760 8 0 0
quotaの設定は、容量(blocks)と、ファイル数(inodes)に変われており、それぞれ警告表示(soft)と物理境界線(hard)に分類される。
今回は、容量を10GBまでと設定するので、blocksのsoftに9.5GB分、hardに10GB分の数値をキロバイトで入力。
ここまで完了したら、再起動を行なう。
再起動後、quotaが有効になる。
ためしに、ファイル数のhardを12とし、13個以上ファイルのアップロードを行なおうとしたら、
200 PORT command successful. Consider using PASV.
553 Could not create file.
とエラーが表示され、アップロード出来なかった。
さて、問題はココから。
社内から通常のFTPアクセスを行なわせ、社外からはSFTPにて接続させたと思っている。
その際の接続制限の方法が見当たらない。
単純に、/etc/hosts.allowに、
in.ftpd: 127.0.0.1 192.168.0. 192.168.1.
と記述しても、FTPの処理を行なうのはFTPデーモンになるので、ネットワークレベルの規制は無理なんじゃないか?
デーモンレベルでアクセスを制限する方法しか知らんので、別の制限方法を探して見るか。
・・・2007/07/28 追記・・・
どうも、SFTPはSSHポートのみしか使わないらしい。
つーことは、/etc/hosts.allowでの制限でいけるんじゃない?w
と思って、設定。
あれ?
制限が掛かんない。hosts.allowの設定が反映されない・・・。
おかしい!と思ってググってると、どうも記述フォーマットが変更されたらしい。
ftpd: 127.0.0.1 192.168.0. 192.168.1.
と、”in”を外したら上手く制限できましたw
定期的に勉強しないと過去覚えた事も、すぐに古くなって使えなくなるから困ったものだ。