「Server」カテゴリーアーカイブ

特定サーバーからメールが届かなくなった（TLSv1.1廃止の影響）

投稿日時: 投稿者:
返信

CentOS7,8あたりでpostfixによるメールサーバーを運用中。
最近いくつかのサーバーからメールが届かなくなったということで調査したら、TLSv1.1以前が廃止された影響だったようです。

受信サーバーのpostfixは smtpd_tls_security_level = mayとしているので、STARTTLSしなければ平文のSMTPでメールが受信できます。

問題は送信元がSTARTTLSしてしまうけれどもTLSv1.1以下だった場合。バージョンアップされていないメールサーバー（今回は某レンタルサーバーのqmail）がSSL3で通信しようとしてきて、STARTTLS→失敗・切断という流れだったようです。

相手からreturn mailが来たと連絡をもらったときの内容は以下↓

TLS connect failed: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version; connected to XXX.XXX.XXX.XXX.
I'm not going to try again; this message has been in the queue too long.

受信側postfixをsmtpd_tls_log_level = 2 にして様子見したときのログ↓

connect from mxXXX.example.com[XXX.XXX.XXX.XXX]
setting up TLS connection from mxXXX.example.com[XXX.X.XXX.XXX]
mxXXX.example.com[XXX.XXX.XXX.XXX]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
SSL_accept:before SSL initialization
SSL_accept:before SSL initialization
SSL3 alert write:fatal:protocol version
SSL_accept:error in error
SSL_accept error from mxXXX.example.com[XXX.XXX.XXX.XXX]: -1
warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:ssl/statem/statem_srvr.c:1661:
lost connection after STARTTLS from mxXXX.example.com[XXX.XXX.XXX.XXX]
disconnect from mxXXX.example.com[XXX.XXX.XXX.XXX] ehlo=1 starttls=0/1 commands=1/2

SSL3 alert writeって出てますね。

解決策としては、先方のバージョンアップをお願いするか、手元のサーバーで半端にTLSさせないように、そもそもSTARTTLS非対応にしてしまうか。
今回はレンタルサーバーということで先方が即時に対応できないため、postfixで smtpd_tls_security_level = none としました。
master.cfでsubmissionポートの場合はTLSになるようにしておいたし、不正リレーもないことをあらためて確認。
受信メールサーバーだからある程度は開いておかないといけないということで may だったのですが、このパターンは今後結構出てきそう…

nginx webサーバーをIPv6対応にするときSSLでハマった

投稿日時: 投稿者:
返信

CentOS8 + nginxの環境で、もともとIPv4のみ対応だったサーバーをIPv6対応にすることにした。
OSレベルでのIPv6有効化は結構環境というかそのときのバージョンに左右されているので随時資料を見ることにする。（さくらのVPSではデフォルトでIPv6無効だが、有効にする手順も提供されていた。「再起動してください」とか雑な感じではあったが）

nginxではconfのserverディレクティブ内で listen [::]:80; listen [::]:443 ssl;を追加すればすぐ動く。ファイアウォールもfirewalldでサービス単位で通しているのでIPv4/IPv6を意識しなくても良い。

しかし、動かなかった…。

正確に言えば、ポート80でのIPv6通信はOKだったが、443でのSSLがダメ。ERR_CONNECTION_RESETやERR_CONNECTION_CLOSEDが返ってくる。

これ、IPv6かつ443 SSLのなかでのdefault_serverが決まっていないと起こる。
適当なserverディレクティブにdefault_serverを書くと期待通りに動いた。IPv4では既にdefault_serverが設定されていたので、増設分が必要だったわけだな。

sambaがアップデートしたら動かなくなったので修復

投稿日時: 投稿者:
返信

CentOS7でずいぶん触ってなかったサーバーをyum updateしたらsambaが止まってしまった。
systemctl status smbで見てみると、WBCLIENT_0.13が見つからないとか、バージョン違いが原因のようだ。
/etc/samba/smb.conf をコピー退避してから、sambaを入れ直す。
yum remove samba
yum install samba
systemctl start smb
systemctl status smb
で起動確認。
configを書き戻してもそのまま起動した。
たまにライブラリ違いみたいなのが出てくるなぁ。

nginxでalias下のfastcgiへのパスの渡し方

投稿日時: 投稿者:
返信

nginx + php-fpm の環境。
最近はドメインのトップからWordpressのようなシステムを置くことが増えたので
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
で良かったのですが、
URI上の一部分を別のディレクトリに置いていたりするパターンでは、rootの定義し直しではなくてaliasを使ったほうがよさげらしい。
しかしaliasにしてしまうと不都合もあるようで

server {
  server_name example.com;
  listen 80;
  root /var/www/example.com/;
  location /somepath/ {
    alias /var/www/somepath/;
    index index.php index.html;
    location ~ \.php$ {
      fastcgi_pass unix:/run/php-fpm/www.sock;
      fastcgi_index index.php;
      # fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_param SCRIPT_FILENAME $request_filename;
      fastcgi_param PATH_INFO $fastcgi_path_info;
      include fastcgi_params;
    }
  }
}

example.com/somepath/hoge.php をリクエストすると
$document_root$fastcgi_script_nameの場合 /var/www/somepath//hoge.php が渡されちゃう。スラッシュが2重になってしまうのでalias下では使えないことに。
$request_filenameの場合 /var/www/somepath/hoge.phpが渡る。こちらは望み通りの結果。

じゃあalias下じゃなくても$request_filename使えば良いのでは？と思って試した結果、
example.com/fuga.php のリクエストに対してどちらも /var/www/example.com/fuga.php となった。

大本がどこからのコピペだったか忘れたが、$request_filenameで良さそうだ。ただしrootとかaliasとかindexがしっかり定義されている文脈に限る。
rootのときは最後の/を調整してくれるけどaliasではしてくれないあたりからの違いってことか

参考
■落とし穴とよくある間違い | NGINX 日本語訳
■nginx $document_root$fastcgi_script_name と $request_filename の違い – Qiita

特定ドメインからのメールをチェックなしで通すテスト postfix

投稿日時: 投稿者:
返信

CentOS＋postfixの話。
SPAMはなるべく受け取りたくないのでFromのチェックを厳しくしてます。
main.confで

smtpd_sender_restrictions =
        permit_mynetworks, # 信頼できるネットワークからは許可
        reject_non_fqdn_sender, # FQDNじゃない人は拒否
        reject_invalid_hostname, # ホスト名がおかしい人は拒否
        reject_unknown_sender_domain #ドメインのDNSレコード見ておかしかったら拒否

しかし世の中にはメールサーバーが正しくないけど受け取りたい相手というのもあるもので、特定ドメインからのメールだけは身元が怪しくても受け取っておきたいという場合もあります。
そんな場合は check_sender_access を入れると良いらしい。

smtpd_sender_restrictions =
        permit_mynetworks,
        check_sender_access regexp:/etc/postfix/sender_access.regexp,
        reject_non_fqdn_sender,
        reject_invalid_hostname,
        reject_unknown_sender_domain

sender_access.regexpでは、正規表現に合致したらOKと返すようにする

/^.+@example\.com$/i        OK

これでFromがexample.comドメインだったら、他の身元チェックをする前にOKになるのでメールが受信できるようになる。はず。
テストしようにも「身元が怪しい送信元」がすぐ手配できないので、一旦は様子見。
postfix checkしてreload。