2017/10/16(月)CGI に Python を利用し、PostgreSQL を使用する

2017/10/16 2:35 サーバ運営・管理
どちらかというと、自分メモ。 CGIというのは、環境変数からパラメータを受け取り、 標準出力へ HTTPヘッダ群とコンテンツを出力する、というのが基本的セオリーで特別なことは必要ないです。 しかし、昨今の Python3系では、WSGIインタフェースというものを意図してCGIを制作するのが普通になっており、これはパフォーマンスの点で有利とされています。 Apache に mod_wsgi 拡張モジュールをインストールする必要があります。 現在のところ、標準モジュールにはなっていないため、別途インストールが必要です。 FreeBSD11 における mod_wsgi インストールは、ソースコードから下記のように行うのが確実。 pip (後述しています) でのインストールは、環境判定を誤認識したり変にエラーを吐いたりすることが環境によっては発生するため、筆者は全くお勧めしません。
# cp mod_wsgi-4.5.20.tar.gz /usr/local/src 
# cd /usr/local/src
# tar xvzf mod_wsgi-4.5.20.tar.gz
# cd mod_wsgi-4.5.20
# ./configure --with-python=/usr/local/bin/python3.5 --with-apxs=/usr/local/apache2/bin/apxs
# make
# make install
--with-apxs を指定することで、お使いのサーバにおける環境に合わせた構築が出来ます。 通常、mod_wsgi は、上記の場合、/usr/local/apache2/modules/ 配下に動的リンクでインストールされます。 Apache への mod_wsgi に対する設定は、以下を参考にどうぞ:
LoadModule wsgi_module modules/mod_wsgi.so

WSGIDaemonProcess cgi-bin user=webadmin group=webuser processes=1 threads=5
WSGIScriptAlias /     /home/webroot/hoge/cgi/app.wsgi

<Directory "/home/webroot/hoge/cgi">
  WSGIProcessGroup cgi-bin
  WSGIApplicationGroup %{GLOBAL}
</Directory>
ちなみに WSGIインタフェース自体は、Python に特化する目的を持つものではありません。 この辺りは勘違いされている諸氏が結構多いようです。 Perl だと mod_perl という Apache に組み込む形での有名な高速化拡張モジュールがありますが、それと同じようなものでしょうか。 Python 以外では導入メリットが見えにくいです。 最近のPerl はそれ自身が高速化してきているので、mod_perl 導入のメリットが見えにくくなってきているのと、mod_perl を組み込んだ状態にてCGIをスレッド動作させると原因不明の不安定な動作になったり、Perl 5.26 にすると、静的モジュールでは何故かインストールできないなど、色々問題があり、筆者のサーバでは mod_perl の利用は見合わせている状況です。 次に、Python から、PostgreSQL インタフェースを扱うモジュールをインストールするのですが、このインストールに先立ち、pip というサポートツール(?)を導入する必要があります。 Perl で言うところの CPAN に該当するものですね。
# python3.5 -m ensurepip
あれ? と思った諸氏も居られるかもしれません。 多くのサイトには「Python 3.4 以降では、pip は同時にインストールされる」と説明されているからですが、FreeBSD11 にて Ports から Python を導入した場合、pip は導入されません。FreeBSD11 にて Ports から Python を導入した場合、pip は手動操作で導入しないと駄目らしいです。 でも、pip は今後のメンテナンスで必須になるものの、今回は使いません。 最後に Python の PostgreSQLインタフェースモジュールをインストールするのですが、これもpip では環境誤認識をするため、ソースコードを持ってきて、下記の手順が確実です。 事前に、PostgreSQL 本体をインストールしておくことは言うまでもありませんね。
# cp psycopg2-2.7.3.1.tar.gz /usr/local/src
# tar xvzf psycopg2-2.7.3.1.tar.gz
# cd psycopg2-2.7.3.1
# setenv PATH '/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/pgsql/bin'
# python3.5 setup.py build
# python3.5 setup.py install
ここで重要なのは、pg_config コマンドのパスを、環境変数 PATH に含めることにあります。 Python の psycopg2 は、Perl における DBI と DBD::Pg の組み合わせに相当します。

2017/10/13(金)はんかくさい日報を新システムへ移行しました。

2017/10/13 5:11 サーバ運営・管理
移行といっても、(adiary を)バージョンアップしただけです。
しかし、見栄えは以前よりシンプルになってしまいました。

移行が何故か上手く行かず、更にデータの一部を壊してしまったため、
移行そのものを全て手動操作でやる羽目になり、足掛け3日掛かってしまいました。

また、手動操作移行の故、記事番号・記事URLが変わってしまい、Google 等への反映は1カ月程度かかるものと思われます。

2017/10/07(土)メールサーバへの攻撃事情

2017/10/12 22:20 サーバ運営・管理
この1週間で「電子メールが送れない・受け取れない」という障害報告が4件ありました。
こういう障害は20年運用していて初めてのことでして・・・

どうも直接の原因は、これです。IPアドレスも晒します。 ↓
20171007_1.png

52.166. 系のIPアドレスの登録上の使用者は、皆が誰でも知っている企業です。
調べればすぐ判るので、ここでは敢えて言及しません。

なんと、概ね 10秒毎にSMTP認証を失敗しては繰り返しています。
文字列 'UGFzc3dvcmQ6' は、'Password:' を Base64エンコードして得られる文字列です。
SMTP認証も現在は数種類あって、これはセキュリティレベルが低いとされている LOGIN 認証と言われる種別。

サーバ負荷をこのようにして意図的に高くし、サーバ障害やサーバダウンを引き起こそうとする愉快犯か、何等かの意図を持っている連中の仕業です。

10/5 の 21:00 頃に、現在一緒に仕事をしている同業者がこのログを見て、 Twitter で呟いたそうです。
『○○社のネットワークから、メールサーバへの攻撃を受けている』と。
そうしたら、52.166. 系からの攻撃は「ピタッ」と止まりました。
これには余りの素早さに笑ってしまいましたね。勿論、対応された方々には感謝申し上げます。確信犯的にやっていたのであれば、逆に許せないですが。

で、今の攻撃主体はどうやら ↓ の模様。これもIPアドレスを晒しておきます。
20171007_2.png

間隔は4分毎ですが、攻撃と言えるレベルです。
時折「セキュリティ対策業者がセキュリティホール探しのためにやっている」なんていう話をする奴がいますが、ならサーバ負荷を意図的に上げるような行為を何故やる? という 疑問が必然的に湧きますね。

SMTP サーバ自体の接続拒否機能は、SMTP認証処理成功後に機能するようで、認証前にIPアドレスや接続元ドメインなどで強制切断するようにはなっていないようです。
これをするには、ファイアウォールを使わないと駄目ですね。
この手の設定は、微々たるものだとしても傘下ネットワーク全体のパフォーマンス低下を招くので、出来れば余計なことはしたくない。

SMTP サーバ単体で、接続そのもの自体を拒否できる機能が欲しいと考えるのは自分だけでしょうか。
ま、発信元で犯人の処分をしてくれるのが最も有益なわけですが・・・