2016年02月28日(日) - 22:17 | カテゴリ:
Linux
最近、メールを媒体としたランサムウェアが流行ったり、
SMTPサーバで如何にウイルスメールを遮断するかが一つの鍵になってきている。
まぁ、ns-labのSMTPサーバにも色々来ているから、今回動いた訳ですが(´・ω・｀)
そんな中、ns-labでは色々な所のRBLを使った上での重み付け計算、
OSSのアンチウイルスと市販のアンチウイルスを組み合わせつつ、
さらに独自生成したスパム辞書を使ってウイルスメールを遮断している。
先日、ふとした事からRBLの見直しを行っていた所、Spamhouseの判定が誤検知だらけで、
いつの間にか使い物にならなくなっていたので、移行先をどうした物かと考えていた。
そんな事もあり、色々と情報収集を行っていた所、
アンチスパムで有名なBarracuda社がRBLを公開している情報へ行き着いた為、
ns-labでも試しに導入してみた。
今回導入したのは、BRBLという↓のサービス
Barracuda Reputation Block List
動作としては、そこら辺のDNSBLと同じくスパム元と思われるグローバルIPを
Barracudaが判断した上でブラックリスト化する物。
使ってみた感覚としては『Spamhouseよりも安心出来る』という印象。
母体がアンチスパムのアプライアンスで食べているだけあって、
AS丸ごとブラックリスト化する暴挙は行わず、ある程度の決め打ちで登録している感じだった。
………
～ BRBLの使い方 ～
参考サイト様：STDMAN – バラクーダレピュテーションブロックリスト (BRBL)
BRBLを利用するには、自前のSMTPサーバを利用登録する必要がある。
適当だが、登録手段は↓の通り。
上記赤枠の"Request Access"をクリック
|
・Login Information
|
|
Email Address
|
ログイン用メールアドレス
|
|
Password
|
ログインパスワード
|
|
Confirm Password
|
ログインパスワード(再入力)
|
|
・Contact Information
|
|
Name
|
氏名
|
|
Company
|
会社名
|
|
Address 1
|
住所(番地)
|
|
Address 2
|
住所(町名)
|
|
City
|
住所(市区町村)
|
|
Country
|
国名
|
|
State/Province
|
住所(都道府県)
|
|
Zip/Postal Code
|
郵便番号
|
|
Phone Number
|
電話番号
|
|
Alternate Email Address
|
連絡用メールアドレス [※ログイン用と同じで可]
|
|
・Alternate Contact Information [※Contact Informationと同じで可]
|
|
Name
|
氏名
|
|
Phone Number
|
電話番号
|
|
Email Address
|
連絡用メールアドレス
|
|
Alternate Email Address
|
連絡用メールアドレス
|
|
・Access Information
|
|
IP Addresses
|
自前のSMTPサーバグローバルIP
|
情報を入力した後に"Submit"をすると、登録したメールアドレスにBarracudaからメールが飛んでくる。
そのメールの中に、登録情報を有効化する為のURLが載っているので、
リンク先にアクセスを行い登録情報を有効化する。これで、BRBLは使えるようになる。はず…
本当に使えるかテストを行うには、登録したグローバルIPを持つSMTPサーバでdigを打ち、
[user@smtp ~]> dig 2.0.0.127.b.barracudacentral.org +short
127.0.0.2
となれば登録されている。
登録されていない時はレコードが帰ってこない。
後は必要に応じて、SMTPサーバの設定にDNSBLの判定を組み込む。
Postfixの場合はsmtpd_client_restrictions等に、
reject_rbl_client b.barracudacentral.org
を追加してリロードすればBRBLが使えるようになる。
………
DNSBLは色々な所が運用していて、日本だとRBL.JPとかが有名だが、
色々あるからこそ、自鯖のスパムメール対策に合致した所を選択するのが重要になってくる。
今回はSpamhouseからBRBLへ移行してみたが、他にも判定に使っている所が数カ所あるので、
暇を見つけて色々な所を試してみたい所である。
« 続きを隠す
2016年02月19日(金) - 22:39 | カテゴリ:
Linux
前回：自鯖のSoftwareRAID-HDDを交換
そして、今回ダメになったのは交換していなかった1台のHDD。
前のようにSMART値が悪くなるのではなく、突然死をしてしまい、
OS・BIOS共にHDDを参照出来なくなってしまった(´・ω・｀)
という事で即時、秋葉原へダッシュしHDDを1つ購入してきた。
ちなみに、前回購入したHDDは健康なので、これからも頑張って貰う模様。
………
そして、地味に大変だったのがRAID-1の再構成だった。
今回の対象は仮想環境のゲストイメージを保存しているRAIDプールなので、
rebuildとresyncかけて、安全を確認するまでに1週間がかりだった。
その結果、1週間ほど自鯖を閉じる結果に(´・ω:;.:…
現在は復旧も終わり通常状態に戻っている。
ちなみに、ついでの作業としてSQLサーバの整理も行ったので、
DigiLoogのレスポンスも少し改善した模様。
何はともあれ、復旧して良かったε-(´∀｀*)
2015年12月12日(土) - 22:57 | カテゴリ:
Linux
入れると言ってもパッケージから入れたので楽だったのだが…
以前購入したNUCにopenSUSEを突っ込み、Windows機からRDPした時の負荷。
↑では解像度がXGAなので負荷は低い方。フルHDでやると、描画が追い付かなくてカクカクになる。
あと、描画をフルにやっている時は、画面を転送する為にNW帯域を100Mbps程度使う事もあったり。
なんでLinux機なのにGUI環境を構築したのかと言うと、
今まで使っていたLinuxノートPCを廃棄した為(´・ω・｀)
だけど、GUI環境が全く無いのは勉強とかするのに不便なので、
「RDP環境を作って、リモートGUIすれば良いじゃね～か」という結論に至った為。
普通、Linux機にGUI接続するのなら、VNCを使うべきなのだが、
クライアントを入れないとダメだったり動作遅かったりで、
VNCはあまり好きじゃなかった後押しもあり、今回真面目にxRDP環境の構築をやってみた。
だが、xRDPは内部的にVNCを飛ばしていたり、
ローカルリレー用のポートを全部使い果たす(普通使い果たせないが…)と新規で接続出来なくなったりするが。
本職で入れる事は、ほぼ無いと思うが「ま～、自鯖だし」というレベルでは結構好調に動いている。
残るはソースからのビルドインストールだが、どうやってもビルドが途中でコケてしまうので、
時間ある時にじっくりと取り組んでみよう。
« 続きを隠す
