以下の"XSERVERのWordPress管理画面へのアクセスが拒否されました"という画面が表示されました。先日有効にしたWAFの影響か?と思って調べたところ、下記メッセージに表示されているWordPressセキュリティ設定→ダッシュボード アクセス制限に引っかかりました。この設定は初期状態でONになっているため正しい動作のようです。
また、ついでに明らかに海外からのスパムコメントと分かる書き込みが続いていましたので表記の国外IPアドレスからのコメント・トラックバックを制限するように設定を変更しました。まれに国内IPでも制限に掛かる可能性があるようですけど国内大手ISPは問題ないと思います。
具体的に誤認の一例を挙げますと、Android端末のChromeで"データセーバー"機能をONにしていますと実際のアクセスが国内からでもGoogleの海外IPで判定され上記エラー画面となるようです。試しにデータセーバーONのZE520KLからこのサイトにコメントを書き込もうとすると403 Forbiddenになりましたので意図せずエラーになりました場合はデータセーバーが原因の可能性があります。
国外IPアドレスからのコメント・トラックバック制限ONへ変更しました
Zenfone3 ZE520KLアップデート(15.0410.1806.68-0)
Chrome68.0.3440.75へアップデート(HTTP警告)
Win10デスクトップのChromeを更新してChrome68へアップデートしました。(Chromebook C213NAのChrome OSはまだ67が最新とでてます)
新しいバージョン。
この更新であちこちで書かれている通りHTTPSで無い通常のHTTP接続全てに対して警告表示が出るようになりました。早速確認してみますと、旧サイトのd.hatena.ne.jpでは
“保護されていません"の警告表示。
警告がURLの左に出るようになりました。移行時点で常時SSL化(その後TLS1.0,1.1は停止して現在TLS1.2のみ)をしているこのサイトは
“保護された通信"の表示。
URL先頭のhttpsの色が緑色に変わり保護されていると表示されます。将来の更新でさらに表示に差がつく(HTTPSを標準にする)そうです。移行のタイミングがかなり厳しいのは分かっていたのですけど、7月目標で切り替えた甲斐があったと思いたいです。
Luxeritas 3.3.1.1へアップデート
気づかなかった3.3.1はスルーして3.3.0→3.3.1.1へのアップデートを行いました。3.3.1.1は3.3.1の不具合修正版のようです。Luxeritas 3.3.1.1 リリース(https://thk.kanzae.net/wp/release/t6002/)←リンクをdev(開発者サイト)からwp(WordPressテーマサイト)へ変えてみました。どちらが読んで面白いかというとdevの方なのですけど最新版ダウンロードへのリンクがwp側にあるからです。
編集機能について改善が入っているようなのですけど私はテキストでタグも手打ち入力している(ビジュアルにすると勝手に直されてしまう、特に行頭にある全角スペースU+3000が削除されるのが困る)ので恩恵はほとんどありません。HTMLの文法チェック的にはビジュアルエディタを使った方が自動修正もかかっていいのでしょうけど私が対応できていません。テキストエディタで書いた記事を貼り付けただけというのがバレバレな記事もかなりの数存在します。
XSERVER WAFすべてONに設定しました
本日このサイトを置いているレンタルサーバー運営会社から以下のお知らせが届きました。Webサイトのセキュリティを強化する「WAF設定」機能提供開始のお知らせ(https://www.xserver.ne.jp/news_detail.php?view_id=4601)というものでセキュリティを向上させる(ただし100%の保証は無し)らしいので以下のようにWAF(Web Application Firewall)全てONにしました。
XSERVERのWAF設定を全てONへ変更。
このサイトでは実質的にWordPressだけですので支障は無いはずです。元々実験的な要素を持っているのでアクセス激減などが発生した場合のみ見直します。まれに意味不明のアクセス(明らかに存在しないURLの要求など)をnginxのログで見ることがあるので減らせるかもしれません。それでもゼロデイ攻撃への対応は無理があるかと思います。
※このページが表示されているときには既に表記設定変更は完了しています。
イオンモバイルデータ専用SIM(タイプ2ドコモ回線用)追加購入
2年前のOCNモバイルoneからイオンモバイルへMNP完了(https://kadono.xsrv.jp/2016/08/01/3285)から音声SIMカード(タイプ1ドコモ回線)をMR05LNに入れてデータのみで使っていました。しかし、よく考えると音声用はZE520KLに入れてSMS/通話を可能にしておいた上でデータ専用SIMをMR05LNに入れた方が冗長度が上がるうえにコスパもいいのではないか?と思いました。ちょうどSIM代金1円(通常3000円)のキャンペーン中なのでダメなら廃棄して切り戻すことにして追加のSIMを購入しました。
日付 | できごと | コメント |
---|---|---|
2018/7/10 | イオンモバイルへデータ専用プラン申し込み | 通販でSIMカードを購入(送料は掛かる) |
2018/7/11 | 契約成立(書類上の利用開始日) | SIM発送の連絡あり |
2018/7/12 | イオンモバイルSIM(2枚目)が宅急便で届く | 早速SIM入れ替え実施、動作確認OK |
2018/7/13 | イオンモバイルサービスお申込み完了通知書が届く | 約1週間掛かった2年前からかなり早くなりました |
タイプ1,2両方契約することになりましたけど目立った違いはなさそうです。今日1日使ってみてタイプ1,2とも(vmobileもOCNも)昼時の速度低下は避けられませんでした。どちらもブラウザの読み込み時間の違いで分かるぐらい遅くなります。ZE520KLはSIM無しから脱出しましたけどデータ通信はオフのまま(SHF32ないしMR05LNがダウンしたときだけ稼働予定)です。
暫くの間はSIM 3枚体制(au MNO通話用SHF32、docomo IIJ MVNE音声/データバックアップ用ZE520KL、docomo OCN MVNEデータ専用MR05LN)で運用してみます。
Luxeritas 3.3.0へアップデート
忙しくて3.2.6はスキップして3.3.0へのアップデート作業を行いました。今の所CAPTCHAは設定していないので影響は無いと思います。
管理画面の速度向上は速いに越したことは無いですけど、XSERVERで動かしていて前のバージョンでも十分に高速だと思っています。どちらかというと"構造化データの修正"の方がこのサイトへの影響がありそうです。いまいちGoogleの挙動が分かりません。私はSearch Consoleの画面も見づらいと思いますし。今回のテーマ更新点の詳細は以下開発元URLを参照してください。管理画面の速度向上と要望追加と構造化データ修正 Luxeritas 3.3.0
(https://thk.kanzae.net/dev/wp-themes/luxeritas/t9886/
今回もアップデート作業中にアップデートテーマによる503画面を読み出した方はいないようです。
Python3で2の補数計算
全くの別件で検索していてでてきた18 I2c通信で気圧,標高を取得しよう.(LPS331AP気圧センサ)(http://lumenbolk.com/?p=814)というページではたぶんセンサからI2Cでデータを取り出すところが中心と思います。が、公開されているPythonスクリプト中の2の補数計算(符号付き整数16進→10進変換)をベタ書きしているのを見て妙に気になりました(ページの本筋からは外れます)。補数計算をPython3で関数化するとどうなるか?気になったので作ってみました。私が実際に必要になったときにはまず忘れているのでここにメモしておきます。標準関数でありそうなのに無いらしい。
符号をMSBから取り出すためにビット位置指定する方法はpythonのビット操作について(http://python-remrin.hatenadiary.jp/entry/2017/05/31/162927)を参考にしました。Pythonのビット演算は少し特殊?かと思いました。確認しながら組み立てていけば問題は無いと思いますが一度に長い処理を書くには慣れが必要かと思いました。
スクリプトは以下の通りです。全パターンチェックしているわけではありません。たぶん、64bitぐらいまでは大丈夫ではないか?と思います。
""" 2の補数計算 """ # -*- coding:utf-8 -*- #http://lumenbolk.com/?p=814 #http://python-remrin.hatenadiary.jp/entry/2017/05/31/162927 def calc_2s_complement(bitsuu, nyuuryoku): if nyuuryoku & pow(2, (bitsuu-1)): # MSB == 1 (負の数) nyuuryoku = -((nyuuryoku ^ (pow(2, bitsuu)-1))+1) return nyuuryoku if __name__ == '__main__': print(calc_2s_complement(8, 0x00)) print(calc_2s_complement(8, 0x01)) print(calc_2s_complement(8, 0x7f)) print(calc_2s_complement(8, 0x80)) print(calc_2s_complement(8, 0xff)) print(calc_2s_complement(16, 0x0000)) print(calc_2s_complement(16, 0x0001)) print(calc_2s_complement(16, 0x7fff)) print(calc_2s_complement(16, 0x8000)) print(calc_2s_complement(16, 0xffff)) print(calc_2s_complement(24, 0x00_0000)) print(calc_2s_complement(24, 0x00_0001)) print(calc_2s_complement(24, 0x7f_ffff)) print(calc_2s_complement(24, 0x80_0000)) print(calc_2s_complement(24, 0xff_ffff)) print(calc_2s_complement(32, 0x0000_0000)) print(calc_2s_complement(32, 0x0000_0001)) print(calc_2s_complement(32, 0x7fff_ffff)) print(calc_2s_complement(32, 0x8000_0000)) print(calc_2s_complement(32, 0xffff_ffff))
おまけめも)さらに脱線するとPythonでは数値や文字列がimmutableという点にも違和感があったりします。なかなか慣れません。
WordPress 4.9.7、Luxeritas 3.2.4→3.2.5へアップデート
大雨やらなんやらで詳細は見ていませんがとりあえずアップデートしました。こういう忙しい時に限って作業が増えるのはいつものことですけどどうしてでしょうか。
WordPress 4.9.7 Security and Maintenance Release(https://wordpress.org/news/2018/07/wordpress-4-9-7-security-and-maintenance-release/)
要望対応と細かい修正だけ Luxeritas 3.2.4(https://thk.kanzae.net/dev/wp-themes/luxeritas/t9785/)
とりあえず不具合や脆弱な部分は減ったと思います。雨が振り続けているし過去記事でも直そうか…と作業していたところ、
不具合 1 件修正(条件に該当する方はアップデート推奨) Luxeritas 3.2.5(https://thk.kanzae.net/dev/wp-themes/luxeritas/t9809/)がリリースされましたので2連続テーマ差し替えを行いました。今日は私以外503無いようです。
XSERVERのaccess_log内IPアドレス欄をFQDNへ変換(Python3+threading編)
先月書いたXSERVERのaccess_log内IPアドレス欄をFQDNへ変換(サクラエディタ+logresolve編)(https://kadono.xsrv.jp/2018/06/06/4658)では一々面倒なのでPython3.6で動くスクリプトを作成しました。Windows10およびCentOS6.9(VirtualBox)上のPython3.6 (CentOS6.9は後から入れる必要あり)で動いています。入力がログファイルで標準出力に逆引き後のログが出てきます。ファイル入力のみでlogresolveとは異なり標準入力からのストリーム動作(?)には対応していません。XSERVERのログが日毎なので私はこれで問題ありません。また、ファイルを2回読みすることで最初は重複削除と逆引きだけ(Max.100スレッド逆引き)行い、2パス目で逆引き結果の文字列置換を行います。仮想ホスト名はこのサイトのURLで決め打ち、変換後のログからは削除しています。
コードの大半はRuby, Pythonで並列に逆引きを行う(http://0xcc.net/blog/archives/000099.html)で公開されているPython用のマルチスレッド逆引きプログラムです。一部Python2向けの部分などを直しています。DNSの逆引き+タイムアウト待ち時間が処理時間の大半を占めるため、このマルチスレッド処理が無ければ普通にlogresolveを使ったほうが速いと思います。
マルチスレッド処理と結果を辞書で処理するアイデアはpythonでマルチスレッドで処理して各スレッドの結果を受け取る(https://qiita.com/komorin0521/items/c25cfcff89c0b1afe882)を参考にしています。
IPアドレスの重複削除についてはPython Tips:リストから重複した要素を削除したい(https://www.lifewithpython.com/2013/11/python-remove-duplicates-from-lists.html)を参考にしました。紹介されている内包表記など凝った書き方は勉強不足で十分理解できていないため使用していません。
また、IPアドレスの正規表現は5.2.3 IPアドレスのフォーマットチェック(正規表現)(http://www.geolocation.co.jp/learn/program/07.html)を多少変更(修正?)して使用しています。
ほとんどGoogleで検索して組み合わせるだけでスクリプトが完成しているので大変楽になったと思います。
""" mt-logresolver """ # -*- coding: utf-8 -*- # http://0xcc.net/blog/archives/000099.html # https://qiita.com/komorin0521/items/c25cfcff89c0b1afe882 # https://www.lifewithpython.com/2013/11/python-remove-duplicates-from-lists.html # http://www.geolocation.co.jp/learn/program/07.html import re import threading import queue import socket import sys def lookup(ip_address): try: return socket.gethostbyaddr(ip_address)[0] except socket.herror: return ip_address def resolver(queue, lock, resolver_dict): while True: ip_address = queue.get() if ip_address is None: break host_name = lookup(ip_address) lock.acquire() try: resolver_dict[ip_address] = host_name finally: lock.release() def logresolver(filename): queue1 = queue.Queue() num_threads = 100 re_pattern_1 = re.compile(r"^kadono.xsrv.jp ((([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])) (.*)") resolver_dict = dict() ip_address_list = [] fp = open(filename, 'r') for line in fp: pattern_1 = re_pattern_1.search(line) if pattern_1: ip_address = pattern_1.group(1) if ip_address not in ip_address_list: queue1.put(ip_address) ip_address_list.append(ip_address) fp.close() lock = threading.Lock() for i in range(num_threads): queue1.put(None) thread = threading.Thread(target = resolver, args = (queue1, lock, resolver_dict)) thread.start() thread_list = threading.enumerate() thread_list.remove(threading.main_thread()) for thread in thread_list: thread.join() fp = open(filename, 'r') for line in fp: pattern_1 = re_pattern_1.search(line) if pattern_1: print(resolver_dict[pattern_1.group(1)]+" "+pattern_1.group(5)) fp.close() if __name__ == '__main__': logresolver(sys.argv[1])
決め打ちにしている部分(最大スレッド数、仮想ホストURL)などまだまだ改良の余地はあると思います。しかし、先延ばしにしているといつ出せるかわからないので見切りで公開します。
※動作チェックはこのサイトのXSERVERログのみでnginxのログ全般で動くかどうかは未確認です。
後日追記)経験上100位ならば問題ないと思いますけど、num_threadsを大きくしてリソースが少ないマシンで走らせるとRuntimeError: can’t start new threadで止まることがあります。その場合はthread数を少なくすると動くようです。Python3.6デフォルトでの限界はPythonとRubyでthreadとfiberをいくつ作れるか検証して見た(https://qiita.com/yohm/items/32e5965cc7b561dc8e4e)によると2048のようです。