メールサーバのSPF(Sender Policy Framework)対応化

送信元アドレスを偽称した迷惑メール、フィッシングサイトへの誘導メールなどの被害を軽減できる仕組み。

【送信側の設定】
送信側がSPFに対応するメリットは、自分の管理ドメインになりすまされたメールの送信をSPFチェックによって判定できるようになる。(受信側が対応されていれば、自分の管理ドメインによるなりすましメール被害を軽減できる)

DNSサーバにSPFレコード(TXTレコード)を登録しておく
IN TXT v=spf1 +ip4:(送信元IPv4アドレス) -all”

MyDNSの場合には自動的にSPFレコードが追加される。
SPFレコードの詳細は送信ドメインを認証するためのSPFレコードに詳しくなろうが詳しい。

併せて、DMARCレコードにも対応しておくことが望ましい
_dmarc IN TXT v=DMARC1; p=none; rua=mailto:(集計レポートの送付先)
DMARCレコードは、MyDNSを使っている場合には、個別にレコード定義する必要がある。

【受信側】
受信側がSPFに対応するメリットは、SPFレコードが登録されたドメインにてなりすましされたメールを受信しないようにできることで、なりすましメールの被害を軽減できる。

Postfixの場合には、「備忘録」 Postfix(CentOS)でSPF対応しちゃう。に従って実装するとSPF対応できるようになる。

SPF対応するとメールヘッダに
Received-SPF: Pass (sender SPF authorized) …
のようなヘッダが付加されるようになる。

また、
$sudo grep ‘policyd-spf’ /var/log/maillog
とすることで正常に動作していることを確認することが出来る。

また、SPFチェックに引っかかる場合には、
Received-SPF: Permerror (SPF Permanent Error: Void lookup limit of 2 exceeded)
Received-SPF: Softfail (domain owner discourages use of this host)
Received-SPF: Neutral (access neither permitted nor denied)
Received-SPF: Fail (SPF fail – not authorized)
のようなヘッダが記録される。

SPFレコードが登録されていないドメインからのメールを受信した場合には、
Received-SPF: None (no SPF record)
のようなヘッダが記録される。

Received-SPF の内容については、postfix で postfix-policyd-spf-python ( or postfix-policyd-spf-perl ) を使ってSPF認証する(CentOS/ScientificLinux編)に詳しく記載されているので、参考になる。

Zabbixで拡張MIB情報を取得する

Zabbixを使ってSNMP情報を取得するとき、OIDを指定することになる。

標準MIBを例にすれば、

インタフェースで受信したパケットの総バイト数

を取得しようとする場合、OIDは、.1.3.6.1.2.1.2.2.1.10 となるが、代わりに IF-MIB::ifInOctets と指定することが出来る。

なぜこんなことが出来るかというと、

/usr/share/snmp/mibs/IF-MIB.txt

の中に

IF-MIB DEFINITIONS ::= BEGIN

(省略)

ifInOctets OBJECT-TYPE
 SYNTAX Counter32
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION
 "The total number of octets received on the interface,
 including framing characters.

Discontinuities in the value of this counter can occur at
 re-initialization of the management system, and at other
 times as indicated by the value of
 ifCounterDiscontinuityTime."
 ::= { ifEntry 10 }

の記述があるからである。下記コマンドにて検証することが出来る。

$ snmptranslate -On IF-MIB::ifInOctets
.1.3.6.1.2.1.2.2.1.1

監視対象とするネットワーク機器の拡張MIB情報を監視対象とする場合、MIBファイルを入手し、Zabbixサーバ上の /usr/share/snmp/mibs/ にMIBファイルをコピーしておけば、OIDを調べなくても上記のように設定することが出来る。

下記にYAMAHA RTX1210の例を示す。

RTXシリーズのMIBは、http://www.rtpro.yamaha.co.jp/RT/docs/mib/ よりダウンロードできる。yamaha-private-mib.tar.gz 等を入手し、解凍の上、

/usr/share/snmp/mibs/ へコピーする。

$ snmptranslate -On YAMAHA-RT-HARDWARE::yrhInboxTemperature
.1.3.6.1.4.1.1182.2.1.15

と変換されるようであれば、Zabbix上でSNMP OID指定する際には、

.1.3.6.1.4.1.1182.2.1.15 の代わりに YAMAHA-RT-HARDWARE::yrhInboxTemperature が利用できるということになる。

参考サイト)
追加Mibを読み取らせる方法(Ver3.0)
第5回 図解で知るSNMP――MIB情報のすべて
【NET-SNMP】ベンダーMIBファイル追加設定
ネットワーク機器のSNMP MIB/OIDまとめ

FortigateVM

FortigateVMは、Fortigate製品の仮想アプライアンスになっているのだが、ちょっと構成が分かりにくい。

技術仕様によれば、モデルによって性能差異が記述されており、製品機能一覧の4ページ目によれば、ハイパバイザーによって利用できる機能は制限されるが、原則的には、FortiOSの機能をすべて利用でき、期待しているスループットが出るかどうかは別として、割と何でもできる万能型のUTMとして使えるように見える。

ところが、下記のようにライセンス形態が構成されており、オプションになっているものがあり、本体(ベース)ライセンスでは、利用できる機能が制限されている。

  • 本体
  • アンチウィルス(オプション)
  • UTMバンドル(オプション)
  • Enterpriseバンドル(オプション)
  • NGFW(オプション)
  • Webフィルタリング(オプション)

本体ライセンスで使用できる範囲がよくわからないので、FortiVMを採用する場合には、よく気をつけた方がよさそうだ。Amazon EC2でも15日間お試しできる(ただし、仮想マシン費用は掛かり、無料枠の対象にはならない)ので、ちょっと調査をしてみようと思う。

参考)株式会社データコントロール社での販売価格表

SOAPとRESTの違いについて

PI のプロトコルの選択

SOAPは最近はやってないね。でも個人的に分かっていない。おそらく実装もした経験もないし、メリットが見出しづらいから?SOAPといえば、発想がCORBAに近いのかな?

かといって、CORBAをちゃんとわかっているのか!と先輩方からお小言を頂けそうで。。。。

こんなのが最近の記事ですかね?3年前の記事からすれば、API連携においては、もはやSOAPは重たすぎるプロトコルなのかもしれないですね。

今さら聞けないWebAPIの実装方式RESTとSOAPの違い

ZabbixでHDDのS.M.A.R.T.を監視

ZabbixでHDDのS.M.A.R.T.を監視してみるを参考に設定してみた。
ハードウエアRAIDでミラーリングされているディスクは監視できなかったが、SATAで接続しているディスクは監視できた。
4.Zabbixエージェントにユーザパラメータを設定する の箇所は、
UserParameter=hdd.smart[*],smartctl -A /dev/$1 | grep $2 | awk ‘{print $$10}’
ではなく
UserParameter=hdd.smart[*],sudo smartctl -A /dev/$1 | grep $2 | awk ‘{print $$10}’
とすることで値を取得できるようになる。
ただ、1点気になる点がある。zabbix_agentd.confには、

### Option: UnsafeUserParameters
# Allow all characters to be passed in arguments to user-defined parameters.
# The following characters are not allowed:
# \ ‘ ” ` * ? [ ] { } ~ $ ! & ; ( ) < > | # @
# Additionally, newline characters are not allowed.
# 0 – do not allow
# 1 – allow
#
# Mandatory: no
# Range: 0-1
# Default:
# UnsafeUserParameters=0

があり、*を使うなら、UnsafeUserParameters=1にしないといけない記述があるが、0でも動作している。
バグなのか、英語の語学力が足りないかのどちらかかなぁ?

ZabbixでIPMIを使用したハードウエア監視について

DELLのサーバと言えば、iDRAC (デルリモートアクセスコントローラ)というもので昔はload averageが高くなりすぎてサーバが制御できなくなったの再起動に使用したり、ハードウエア情報を監視したりしていたが、今ではIntelligent Platform Management Interface (IPMI) という、標準化されたメッセージ・ベースのハードウェア管理インターフェースがあることを最近知った。
BMCという方式で実現されており、サーバ本体のIPアドレスとは別のアドレスを設定することで、iDRACがなくても、ipmitoolを使うことでサーバの再起動やハードウエアリソースを取得することが出来る。
「標準化された」というところがポイントで、サーバのメーカーが違っていても対応できるところが最大のメリットで、昔の記事ではYahoo JapanでもIPMIでの大規模サーバー管理をしていることが掲載されている。
ZabbixでIPMIアイテムを取得する方法は、Zabbix2.0.4でIPMIアイテムを収集する。 #Zabbix #自宅ラック勉強会が大変参考になる。
SoftLayer上でZabbixを動かしエージェントの自動登録やAuto Scaleとの連携を行うもハードコピーが多く非常に分かりやすい。
単位がdiscrete のセンサーの値はZabbixで非対応 という点がポイントで、ほとんどの値が取れないのはZabbixのバージョンアップを期待するしかない。
Zabbixを使ってIPMI監視(HP iLO編)で紹介されているように、ipmitoolを駆使して外部チェックすればほかの値も監視できるのかとは思うが、やっていない。。。。
ところで、ipmitoolでZabbixからハードウエア監視をしようと試してみたところハマったポイントがあったので紹介しておく。
ハマったこと1)Destination Host Unreachableで切り分けに手こずる
ローカル(-I lan -U -H オプションを指定しない)からは取得できるのに、BMCに設定しているIPアドレス宛では
No response from remote controller
Get Auth Capabilities command failed
Error: Unable to establish LAN session
と表示されてしまうという事象だ。
結論としては、Zabbix監視サーバ(ipmitoolで監視対象となっているサーバとは別)からは通信ができるので問題なく、
切り分けしようとしてハマったというオチなのだが、ipmitoolを実行しているサーバと同一サーバで設定しているIPアドレスは同一セグメントなのに
Destination Host Unreachable
となる。。。
これは仕様なのかもしれない。
ハマったこと2)IPフィルタリングで手こずる
623/udpなのだが、UDPパケットだけに戻りパケットをちゃんと通してあげる必要がある。
戻りパケットはdestination portが631ではなくsource portが631なので注意!
destination portが631だと勘違いしてこれまた手こずりました。。。。
参考)
BMC: 業界標準のシステム管理コントローラ
ipmitool のリモート操作に必要な設定
ホストOSのLinux側で、筐体のBMC(IPMI)に設定されているIPアドレスを調べる
ZABBIX Forums IPMI監視のセンサーについて
ZABBIX Forums IPMI Discrete Sensors

ApacheとTomcatを連携するにはどのモジュールを使うのがよいか???

案1)mod_proxy_http
案2)mod_proxy_ajp
案3)mod_jk?

Apache-Tomcat連携モジュールmod_jk/mod_proxy_ajp/mod_proxy_httpそれぞれについて接続が切れた時の挙動を比較・調査してみた

また、IISとTomcatを連携するには、ajp通信する場合には、ISAPIフィルタしかないみたい。

ところで、WebサーバとAPサーバを別マシンで稼働させる場合の優位性は何だろうか?

1.APサーバは重要なデータを保持しているため、APサーバとの通信は、Webサーバにのみ行うことで、セキュリティを担保しやすい。一方Webサーバはフロントエンドになるため、不特定多数と通信する。

2.Webサーバをロードバランサ(SSL通信を行う場合には、SSLオフロード)の役割を担わせることによって、APサーバをスケールアウトできる。

3.APサーバで処理する必要のない静的コンテンツをWebサーバ側で処理させることによって、オフロードできる。

DNSラウンドロビンについて考える

最近DNSラウンドロビンの構成になっているWebサーバを見かけなくなったのは、ロードバランサが仮想化されて稼働率が限りなく100%に近づいているからということなのか?
とあるサービスにて、複数のロードバランサをDNSラウンドロビンする方法があったのだが、ロードバランサに障害発生した場合に、DNSラウンドロビン登録しているAレコードのキャッシュ有効時間を限りなく短くしたうえで、ロードバランサ障害時にDNSレコードを動的に変更できる運用体制がないと可用性を下げる要因にしかならないのではないか?と思ってみた。
DNSラウンドロビンにおいては、
WindowsでDNSのラウンドロビン機能を利用するの文中にあるように
クライアント側の再試行機能(アクセスできない場合は、別のサーバIPアドレスへの接続を試行する)に”期待”したりする(アプリケーションによっては、アクセスできない場合は自動的に別IPアドレスへ再試行する機能を持っている)
とあり、アプリケーションの実装によっては、アクセスできない場合には別のAレコードの値を参照して再試行するというものがあるらしいが、アプリケーションが直接複数のレコードを使い分けるような実装をしているものがあるとは個人的には考えにくい。
参考)
Load Balancing
Azure Load Balancer の概要

CloudFrontを利用して静的コンテンツを高速化する

このブログサイトをCloudFrontを使って高速化してみた。
早くなったかどうかはちょっとわからないが、Googleからのリクエスト速度は間違いなく上がっているので、検索順位向上には寄与している(と思いたい)。
CloudFrontはCDN(Content Delivery Network)のサービスだが、EC2やLamdaなどのAWSのサービス以外にも利用できる。
昔はCDNなんてakamaiぐらいしかなく、個人が使えるようなサービスではなかった。
CloudFrontを独自ドメインで利用するメリットは下記が挙げられる。
1.全世界からのアクセスが高速化できる。(CDNの導入目的と同じ)
例えば、当ブログサイトのドメインに割り当てられているアドレスd2p33equgohrri.cloudfront.netを正引きすると以下のように8つのアドレスが返される。
このアドレスは、リクエスト元の地域(リージョン)によって変わることになる。
>nslookup -q=A d2p33equgohrri.cloudfront.net
権限のない回答:
名前: d2p33equgohrri.cloudfront.net
Addresses: 54.230.111.20
54.230.111.187
54.230.111.227
54.230.111.55
54.230.111.251
54.230.111.57
54.230.111.220
54.230.111.238
2.Webサーバへのリクエストを減らすことが出来る=負荷を軽減できる。(CDNの導入目的と同じ)
3.(D)Dos攻撃にも耐えられる。(CDNの導入目的と同じ/但し、リクエスト数が増大するので、課金がかさむことになる)
4.CloudFrontをSSL化しておいて、CloudFront→Webサーバ 間をHTTP通信にすることにより、昨今のセキュリティ要求に対応しながら、SSL通信にかかる負荷を軽減できる。
5.SSL証明書が無料で利用できる(CloudFront独自のメリット/但し、IPベースにすると毎月600ドル課金されるので注意)
6.AWSの無料枠の対象なので、気軽に試せる(CloudFront独自のメリット)
7.HTTP/2に対応できる。(CloudFront独自のメリット?/リクエストが高速になる)
SSL証明書はLet’s Encryptを利用する方法もあるが、CloudFrontを利用すると証明書の期限が13ヵ月になっているうえ、更新が自動で行われる点がビジネス目的に耐えられる点で優れている。
CloudFrontを利用するにはWebの画面だけで完結できるが、日本語化されておらず少しハードルは高い。
ただ、WordPressサイトをCloudFrontで配信するの説明が非常に分かりやすい。
上記サイトでは、WordPressサイトの登録を変更していたが、
Origin Domain Name には、CDN用のエイリアスFQDN(例:cdn.blog.development-network.net)
Alternate Domain Names には、オリジナルのFQDN(例:blog.development-network.net)
を登録し、cdn.blog.development-network.netのCNAMEに登録後に表示されるDomain Name(例:d2p33equgohrri.cloudfront.net)をDNSに登録すればよい。
SSL証明書の発行手順は、認証がメールベースになっているので、独自ドメインのメールエイリアスを登録できるようになっている必要がある。
SSL証明書を発行しても、すぐに独自ドメイン用のSSL証明書に切り替わらず、証明書エラーが表示されるので、少し焦るがCloudFrontのStatusがDeployedになるまでは待ってみることをお勧めする(焦った)