他社の作業代行費用調査その3

【 2017/08/09 現在の調査です 】

以前の調査はこちら
他社の作業代行費用調査その1
他社の作業代行費用調査その2

───────────────────────────────────

■Zenlogic(ゼンロジック)

───────────────────────────────────
レンタルサーバーのファーストサーバー Zenlogic のプランです。

https://zenlogic.jp/option/operation/price.html

継続型サービス
(フルマネージドオプション)

・Zenlogicホスティングフルマネージド    120,000円/年
・Zenlogic CDNフルマネージド             60,000円/年
・Symantec Email Security.cloud フルマネージド 60,000円/年

作業実施時間 9:00~18:00 ※時間外対応 30,000円

スポット型サービス
(作業代行(スポット型))

・WEBサーバー初期設定           1回 30,000円~
・メールサーバー初期設定        1回 30,000円~
・ネームサーバー設定            1回  5,000円~
・Zenlogic CDN 初期設定         1回 30,000円~
・Symantec Email Security.cloud 初期設定 1回 30,000円~

・各種WEBアプリケーションセットアップ 1回  5,000円~
(WordPress, Movable Type, EC-CUBE等)
・サイボウズ Office バージョンアップ  1回 20,000円~

・他社サービスからの移行        1回 100,000円~
・データバックアップ            1回  30,000円~
・データリストア                1回  30,000円~
・サイトデータ複製              1回  20,000円~
・ファイル一括削除              1回  10,000円~

※上記はオプションサービスで、Zenlogic ホスティングのサーバー契約の料金とは別のようです。

ざっくり概ねベリーキュートの5倍~10倍の料金設定だと思われます。
フルマネージド 120,000円/年となっていますが、ベリーキュートでは 24,000円/年、
WEBサーバー初期設定 1回 30,000円~となっていますが、ベリーキュートでは 3,000円~、
スポット作業に関しては概ねベリーキュートの10倍です。
基本やることは同じなので、サーバーをここで借りても保守だけベリーキュートにする手もあります。

お申し込みからの作業の流れ

注目

サーバー初期構築/各種設定/サーバーマネージメント(保守契約)に関して
お客様のお申し込みからの作業の流れは以下のとおりです。

(1)お申込みページからお申し込み頂きますと、まず控えのメールが自動送付されます。

(2)次にこちらから「環境確認から作業開始までの流れ」というメールが送られます。

お送りしたメールにはお客様のサーバー情報をご記入頂くフォーマットがあります。
ご記入頂く情報は以下の項目です。

・対象サーバーIPアドレス:
・接続用アカウント(ユーザー名):
・接続用アカウントパスワード:
・root パスワード:
・SSHポート番号:

※ユーザー名は、SSHユーザー名あるいはFTPユーザー名です。
※お送りしたメールに指定のフォーマットでご返信を頂きます。

(3)お客様のサーバー情報をお送り頂きますと、ログインして環境チェックをいたします。

これはお申し込みの作業が可能かどうかを判断する重要な作業になります。
特殊な環境になっている場合やインストール済みのミドルウェアバージョン等によって、稀にご依頼の作業ができないような環境もあります。それを判断するものです。
これはお申し込みから30分程度で完了することが多く、大抵1時間以内です。

(4)環境チェックで問題のない場合、ご請求書メールをお送りいたします。

ここで初めてお申し込み確定・ご成約となり、費用のお支払いへと進みます。

(5)ご請求書メールが届きましたら費用をお支払い(指定口座へお振り込み)頂きます。

(6)費用の着金を確認いたしまして、お申し込みの作業開始となります。

作業は数時間(1時間~半日)で完了することが多く、大抵1日以内です。

ご利用条件はこちら

サーバー設定・サーバー管理のご利用条件

 

サーバー設定・サーバー管理のご利用条件

注目

サーバー初期構築/各種設定/サーバーマネージメント(保守契約)に関して
当サービスのご利用条件は以下のとおりです。

・対象OS: CentOS 7(RHEL7系)/ CentOS Stream 8(RHEL8系)
・インターネット経由でSSH接続が可能であること
・root権限あり(SSHでログイン後 root で作業ができること)
・Parallels Panel, Plesk, cPanel がインストールされていないこと
・中継機器等のパケットフィルタリングでポートが閉じていないこと

特に、インターネット経由でSSH接続が可能であることは重要です。
これは、OSインストールとネットワークの初期設定は請け負っていないことを意味します。

当サービスがサーバー初期構築/各種設定として想定しているのは、専用サーバーあるいはVPSあるいはクラウドのインスタンス生成後、Webサーバーとして機能するためのミドルウェア(Apache、MySQL、メール関連やFTP機能等)の設定がされていない状態からそれを初期設定していく作業の代行です。
サービス一覧はこちら
サーバー初期構築/各種設定のページ

また、当サービスがサーバーマネージメント(保守契約)として想定しているのは、サーバーをクリーンに保つための日々の目立たない地味な管理作業(各種サービスが正常稼働しているか、問題はないかのリアルタイム状態監視と不具合発生時の即対応)および、ユーザー作成、Webサイトのバーチャルドメイン設定(サイト開設時の初期設定)、メールのバーチャルドメイン設定、MySQLデータベース作業等々諸々の作業代行です。
サービス一覧はこちら
サーバーマネージメント(保守契約)のページ
 ◎フルマネージメントの作業代行サポート範囲参照

お申し込み方法はこちら

お申し込みからの作業の流れ

 

BINDの複数の脆弱性対策 (CVE-2017-3136他)

先日明らかにされたセキュリティアラート: CVE-2017-3136/3137/3138
ISC BIND に複数のサービス運用妨害 (DoS) の脆弱性

対策実施について

原文はこちら
CVE-2017-3136(英文)
https://kb.isc.org/article/AA-01465
CVE-2017-3137(英文)
https://kb.isc.org/article/AA-01466
CVE-2017-3138(英文)
https://kb.isc.org/article/AA-01471

JVNVU#97322649
ISC BIND に複数のサービス運用妨害 (DoS) の脆弱性
http://jvn.jp/vu/JVNVU97322649/index.html

本件の問題点と対策は以下の通りです。

続きを読む

総務省へ迷惑メール情報提供するプラグイン

総務省へ迷惑メール情報提供するプラグインのご紹介です。
ダウンロード http://plugin.antispam.soumu.go.jp/

迷惑メールとは
「特定電子メールの送信の適正化等に関する法律(平成14年法律第26号)」に違反していると思われる以下のようなメールです。

・送信に同意した覚えのない広告宣伝メール
・表示義務違反メール
・送信者情報(電子メールアドレス、IPアドレス、ドメイン名 等)偽装メール

総務省は迷惑メール対策に取り組んでいます。

総務省|電気通信消費者情報コーナー|迷惑メール対策
http://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/m_mail.html

特定電子メールの送信の適正化等に関する法律のポイント
http://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/pdf/m_mail_pamphlet.pdf

【主要な罰則】

送信者情報を偽った送信
1年以下の懲役または100万円以下の罰金
(法人の場合は行為者を罰するほか、法人に対して3000万円以下の罰金)
同意のない者への送信
総務大臣及び内閣総理大臣による命令。命令に従わない場合、
1年以下の懲役または100万円以下の罰金
(法人の場合は行為者を罰するほか、法人に対して3000万円以下の罰金)
同意の記録義務違反
総務大臣及び内閣総理大臣による命令。命令に従わない場合、
100万円以下の罰金
(法人の場合は行為者を罰するほか、法人に対して100万円以下の罰金)

続きを読む

SPF判定をパスするスパムメールの例(SPFは意味がない証拠)

前に、SPFレコードでドメインの正当性を判定する方法が逆にスパムを増長させる問題について書きましたが、今回は、実際に筆者に送られてきたスパムメールがSPF判定をパスしている例を示します。
SPF判定をパスするスパムメールは非常に多く、SPF判定は何の意味もないのが現実です。

■ 送られてきたスパムメールの例

From: 【ECショップ】ご注文の確認につきまして <zqtafc5pn5ww8umr0kew8d@virk.dj8eiidz78rxjk.site>
To: xxxxx@yahoo.co.jp
Subject: 【xxxxx@yahoo.co.jp】様 ご注文の確認につきまして

xxxxx@yahoo.co.jp 様


ご注文を頂きまして誠に有難う御座います。きゆおをにろつに

お取引終了まで短い間では御座いますが何卒宜しく御願い申し上げます。きゆおをにろつに

今回ご注文を致しました商品のご確認をお願い致します。きゆおをにろつに



http://xxxxx.yg58zymnjgh83.com/Q6a0d-NDc2-ODAxMTEy/NTAyMwQ6a0dQ6a0d/



尚、御発送に際しましては改めてメールにてご案内申し上げます。きゆおをにろつに
何卒宜しく御願い申し上げます。きゆおをにろつに






■配信停止
http://xxxxx.yg58zymnjgh83.com/Q6a0d-NDkz-ODAxMTEy/NTAyMwQ6a0dQ6a0d/

きゆおをにろつに
4374きゆおをにろつに

(ただし、xxxxx は伏せ字)

■ 送られてきたスパムメールのヘッダ解析

続きを読む

GoogleのGmailのIPv6逆引き判定が迷惑な問題

前に、SPFレコードでドメインの正当性を判定する方法が逆にスパムを増長させる問題について書きましたが、今回はさらに突っ込んでGoogleのGmailの厳しい判定が迷惑な問題について書きます。

参考)

一括送信ガイドライン – Gmail ヘルプ
https://support.google.com/mail/answer/81126

Googleだけに限ったことではないですが、Gmailはシェアが多いのでトラブルが目立ちます。

トラブルというのは【Gmailに送ると届かない】という問題です。
これはGmailが、迷惑メール対策として判定が厳しいためです。

Googleは最近、自分たちのガイドラインに【何が何でも従わせる】という強引なやり方をするようになりました。
事実、Googleのガイドラインに従わないメールはリジェクト(受信拒否)されるトラブルが多く、最近 Gmail / G Suite(旧 Google Apps)のメールに関して問い合わせが多いです。
仕事の取引先からの必要なメールでもGoogleのガイドラインに反していると届きません。
迷惑メールフォルダに振り分けられるならまだしも、勝手にリジェクトされて気付かないままになります。

続きを読む

SPFで迷惑メール判定が逆にスパムを増長させる問題

SPFレコードでドメインの正当性を判定する方法が逆にスパムを増長させる問題について書きます。

#SPFレコードとは送信ドメインを認証の一種で、詳しくはネットで調べてください。
#独自ドメインを持っている人はSPFを知らずに済ますことはできません。
(特にGoogleのせいで知らないでは済まなくなってしまいました)

参考)

SPF(Sender Policy Framework): 迷惑メール撲滅委員会
http://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/

SPF レコードについて – G Suite 管理者 ヘルプ
https://support.google.com/a/answer/33786?hl=ja

一括送信によるメール返送 – G Suite 管理者 ヘルプ
https://support.google.com/a/answer/168383

Googleだけに限ったことではないですが、メールをサービスするプロバイダの傾向として、SPFレコードの設定を(なにがなんでもやれと)強制するような動きがここ数年で強まっています。

続きを読む

fail2ban で不正アクセスをブロック

サーバーを運営していて気を付けることに、不正アクセスがあります。
特にパスワードクラッキングされてスパムメール送信の踏み台にされないこと。

自分のサーバーがいつの間にかスパムメール送信していたら大変です。
レンタルサーバー会社に通報あるいはスパムサーバーとしてブラックリストに登録されるかもしれません。

fail2ban は、不正アクセスと判定したら、一定時間アクセスをブロック(遮断)します。

■ fail2ban インストール

yum install fail2ban

続きを読む

Apache で大量アクセスが来たとき負荷を上げない設定

Apache で同時接続数の設定(2.2 では MaxClients、2.4 では MaxRequestWorkers)より大量アクセスが来たとき負荷を上げないためのちょっとした工夫について書きます。

MaxClients をいくら下げてもサーバー負荷が下がらないじゃないか!とお困りの諸氏に …

それはとても簡単で、ListenBacklog を少なめ(例えば 1 とか)に設定します。

Apache のマニュアルには、こう書かれていますが・・・
———-
ListenBacklog
保留状態のコネクションのキューの最大長です。 一般的には調整する必要はありませんし、調整は望ましくありません。 しかし、TCP SYN フラッドアタックの状況下におかれる場合に、 増やした方が望ましいシステムもあります。 listen(2) システムコールのバックログパラメータを ご覧下さい。
———-
これを読むと、ListenBacklog は調整不要、するとしても大きくする方向で、と思ってしまいますよね。
でも違います。逆です。
続きを読む