またブログがダウンしていました。原因は、アタックでもなんでも無く、
以前から時々発生しているSSL証明書バッチサーバから取得出来ず、落ちているといった状況です。

対策

これは、対策して、スクリプトを少し改編しつつあって、改善出来る様にバージョンアップをしています。
ブログサーバは、最新の資材であるMasterからデプロイされていますが、今コミットしているのはDevrelopブランチなので
そっちの資材をMasterにマージして、先ほどデプロイしました。
これで、少しましになるか？ちょっと様子見ですね。

GitLabがメモリーが足りず、スワップさせながら使っているのが原因なのは分かってるのですが
インスタンスタイプをあげると、コスト高になってしまうので、スワップサイズを大幅に拡大し
スワップ前提で動かしているので、バッチサーバから応答がかなり遅い時があって
その時、取得側で待ちきれず、処理落ちになって、そのままNginxを再起動すると
本日の状況に陥る訳です。

本日最新の資材に入れ替えたので、これで証明書が取得出来ない場合は、翌日に処理持ち越しになり
翌日RETRYします。ただ、SSL証明書の期限が1日しかないと、証明書エラーがでてしまうので
その場合は、その場でRETRYするように現在プログラム修正を行っています。
現段階としては、取得はスキップして翌日RETRY方式としています。

どうなるか！？

毎朝5時に処理が走っているので、明日朝また確認しようと思います。
ブログが見れない時は、少し待って頂けると手動回復しておきます。
引き続き、よろしくお願いします。

2024/08/14追記

本日のバッチ処理は無事成功しており、問題無く稼働継続出来てます。
これでしばらく様子をみてみようと思います。

The post むむむ！Blog Down💦 first appeared on ～下町物語～.

本当にやめて！勝手にブロックするの

はい！ノートンは別のPCにはいっていて、そのPCでブログを編集しようと思ったらなんと！！
上記の様にブロックされてしまった

当ブログは、マルウェアスキャンを毎日スキャンをかけており、
さらに管理画面も隔離しており、外界から接続することが難しい状態にしております。

また、ファイルの改変もオーディットをつかって監視していることから
何らかの方法でクラッキングされて、マルウェアが仕組まれた等の形跡はありません。
考えられる事としては、AdSenseでマルウェアが入っている広告がたまたま
流れているときにスキャンされたのか？
別のURLのサブドメインのサイトについても、同様にブロックされてしまっているので
そちらは、もっと簡易なフレームワークを使っており、Wordpressは一切使って居ないが
同様にブロックされてしまっていたので、2つのサイトの繋がりについては
AdSense配下にいるって事の共通点があるのみでした。

ブロックされたら？

はい。これを検索されてどうしたらよいか？でたどりついた場合
ブロックされた理由をある程度当たりをつけて、解析する必要があります。
その手順を下記に記載しますので、参考していただければと思います。

まずは、サイトチェック

ここ重要ですが、まずは、ブロックされたサイトが本当にマルウェアに感染していないか？を
チェックする必要があります。Wordpressなどでしたら、まずは、プラグインを使って
サイト全体をスキャンするプラグインがあるので、そちらを下記手順にてインストールしてみてください。

Anti-Malwareをインストールする

メニューからプラグイン－＞新規プラグインを追加－＞プラグイン検索窓に【Anti-Malware】を入れる
下記の画像の様にヒットしてくるので、インストールして有効化してください。

つづいて、このツール設定が必要なのでそちらの設定をやって行きます。
左ナビメニューにAnti-Malwareがでていると思うので、そちらをクリックすると、
右端に下記右の表記がでていると思います。バージョン等の情報は画像を採取したタイミングの画像なので
別の表記になっていると思います。無料でキーをゲットをクリックしてください。

下記画像の画面になるので、必要事項を入力してください。
入力後、Register Now!をクリックしてください。

問題無いとレジストされるので、次の操作で新しい定義ファイルをダウンロードしてください。
新しい定義ファイルをダウンロードしよう！をクリックする。

最新の定義ファイルがあたって、いよいよスキャンができる状態になる。
下記画面の右にある【完全なスキャンを実行する】をクリックする。
ファイルが多いと、結構時間がかかるので気長に待ちます。

スキャンがおわったら、問題があるファイルが無いことを確認して
もし、何らかの問題があるファイルが見つかったら対応を行います。

このサイトでは、現在使っていないテーマのinfo用のphpが1件ヒットしました。
ただ、それはもう使っていないので、サクッと削除しておきました。
特に何も脅威がない場合は、サイト的には問題がないと判断出来るので
最後にWordpressのバージョンを最新にアップデートします。

次にノートンでどのcategoryに属しているか確認します。

ここにAccessをする　－＞https://safeweb.norton.com

サイトを検索しますの部分に、ブロックされているURLを入れる。

このブログなら、https://blog.rurineko.com と入れて虫眼鏡のアイコンをクリックする

ブロックされていると下記の様な画面になると思います。
このサイトも、URLは違えども現在のカテゴリーが【悪質なソース／マルネット】に分類されていました。

ここまで確認できたら、いよいよもう少し

上記画面の中に【異議を送信する】をクリックします。
下記の画面が表示されるので、メールアドレス、提案するカテゴリとコメントを入力し
私はロボットではありませんをし、送信するをクリックします。

コメントは、特に何を記載するというのはないのですが、筆者としては安全性の説明と解除されるべき内容を記載しました。

・外部インターフェースが公開されていないこと
・マルウェアスキャンが毎日走っていること
・マルウェアスキャンの定義ファイルのバージョンとそのスキャン結果
・Wordpressフレームワークのバージョン等等

送信後、数時間から数日・数週間と期間はまちまちですが、担当者が異議申し立てを受信し
内容を確認して問題が無ければ、提案したcategoryに変更されるのでブロックされなくなり通常運転に戻ります。

ブロックが解除された場合、下記の様なレポートが登録したメールアドレスに届くので
そちらも確認しておきます。

総括

ノートンのプラグインを入れないと、ブロックされていることすら気がついて無かったです。
このブログは、特にマルウェアやマルネットじゃないですし普通のブログサイトなのですが
何故、そんなカテゴリ分類になってしまったのか？理由は一切分かりません。

また、ノートンを使っている方がどのくらいいて、どのくらいの人に冒頭に載せた
ブロックメッセージが表示されたのか？全くわかりません。
これ商用サイトとかで、これやられると本当困っちゃいますよね。勝手に営業妨害ですよね。

そんな感じで、とりあえずは解決に至った訳ですが、いちおうサイトをお持ちの方がいらっしゃったら
上記ノートンセーフウェブからご自身のサイトをチェックされることをおすすめします。
勝手にブロックされている可能性もあるってことで。
せっかく本件ヒットしたので、出来高がないのはもったいないので
記事にさせていただきました。Nortonの基準でブロックされた時に
WordPressが古いバージョンで脆弱性があったのかも知れません。出たらすぐアップデートしているのですが。。。

ただ、Wordpressフレームワークを使っていないWebサイトも同様の理由によって
ブロックされていたので、AdSenseかな？といった結果となりました。
特にどちらのサイトも、ウイルススキャン（Wordpressフレームワークを使ってないサイトは、
Linuxのウイルスチェックツールにて）していますので、どちらも問題は出ていません。

結果、実際に対応した事項としてはスキャン結果を再確認したことと、一応サーバにログインして不正ログインなどの改竄がないかを確認したのと、オーディットログを精査して問題無いと判断出来た為、異議申し立てを行ったのみです。
結果は上記掲載したとおりであり、安全なサイトと言う表記に変更になってます。

過去アクセスされた皆様も、ご安心して頂ければと思います。
もしかしたら筆者の写真が・・・ぼそ
そういうこと？女子モードだったから？なわけないですよね？
今後ともどうぞ、よろしくお願いします。

The post Nortonに嫌われていた！ #safeWeb #block #Norton first appeared on ～下町物語～.

2024/07/29 早朝から数時間ブログがダウンしていました。

原因

アタックで落ちる場合もあるんですが、今回に限っては
毎日特定時間にSSL証明書を自動更新バッチが動いているのですが
そのバッチサーバがなんと！！なんと
OSアップデートがでかいのが来てtemporaryを使いつぶして
なんと、Nginxが動作不能に陥り、証明書をゲットできなくなったのが原因です。

バッチサーバから証明書を上手く取得出来ない場合
取得側のシェルで、ある程度は旧証明書を使い翌日にRETRYするを
組み込んでいたのですが、今回は、中途半端に4つくらいある証明書の
3つだけゲットでき処理中に落ちたみたいで、残り1つの資材がゲット出来ず
処理落ちしてNginxを再起動した所、資材不足で立ち上がらず
ブログ自体が落ちてしまった経緯です。

対策

これは、全部が取得出来たかを確認した後にnginxを再起動するという
シェルに改変することで、バッチサーバが転けてもある程度は行ける
状況になると思うので、そちらを実装していきたいと思います。

何はともあれ、数時間のダウンで終わったので良かったです。
監視サーバも入れてますが、寝ずに見てるわけではないので
alertは事後対応になっちゃいますね。

The post ブログダウン💦 first appeared on ～下町物語～.

謎ですが、PVRankingに参加してて、今までデータが取れていたのですが
1週間ちょっと前にphp-fpmがおかしくなってから急に取れなくなって、
ちょっとタグを一掃して、今の最新をとってきて貼り付けました。

これで、復活してもらえたら良いなと思っています。
かなり全体でも2600位くらいにいたのに、データが取れなくなったので
だだ下がってどうしようもありませんね。

今日からまた取れる事を願って、勧めて行こうと思いますが
完全に取れない訳じゃなくて、20とか取れてるので意味が分からないんですよね。
とりま、これでいったん様子を見れたらと思います。

追記

多分旧ウィジェットのプラグインを廃止した際に設定が消えて締まったのだと思われます。
先ほどから数字が回復してきて、1時間足らずで310までふえているのでこれで問題ない気がします。

The post ブログRankingのPV数が取れなくなった件 first appeared on ～下町物語～.

先日から調子が悪く、今朝みたら落ちてました。

原因は、とりま先日発生したアップデートのバグのせいで
コアダンプをはきまくっていた件だと思っています。

その後の調べでは、ある特定のAPIが無限ループになってメモリーを要求しまくって落ちていたようです。
結局、それ見つけるまで結構時間掛かりました。

対処方法は、いったんそのAPIをなかったことにするです。
あえて、moveコマンドで、該当のAPIを作り出しているファイルの名前を変更し
いったんSiteにアクセスして、500番internal server errorを引き起こさせます。
次に、moveしたファイルを元のファイル名に戻した所復旧しました。

ここで、少し原因的なのも書きました。
あわせまして、みていただければと思います。

https://www.rurineko.com

ただ、これが本当に正しい解決方法だったか？どうかは分かりません。
というのも、再起動もかけたけど、processが残って発生していたなら
再起動かけると、それは絶対的に解決しそうなものですが
再起動かけたぐらいでは、全く復旧しませんでした。

となると？謎は深まる一方です。
ちょっと時間が空いたら、また調査をしてみようと思います。

とりま、これの引き金になったプラグインについては、もう使わない削除致しました。

2023/08/31追記

昨日、いったんPHP8.0系から8.2にアップデートいたしました。
php-fpmが壊れていたのかも知れません。
今日はプラグインをアップデートしても、該当の症状は出なくなりました。

php-fpmの該当バージョンのバグだったのかも知れません。
よく分かりませんが、これでいったん様子をみてみようと思います。
毎朝6時にパッチを自動適用しているので、php-fpmのバージョンが上がったことで
発動した可能性もありますね。

The post ブログが落ちてました！ first appeared on ～下町物語～.

今は、どこの案件に行っても、だいたい、Ansible使えますか？とか
Cloudformation使えますか？とかTerraform使えますか？って絶対聞かれます。
過去、Ansibleは使った事があって、結構なれてくると便利だとは思っていたけど
なんか、ymlファイルに癖があって、なかなかそれになれるまで凄く苦労しました。

で、最近Cloudが流行ってますよね？　手で構成を作る事ももちろん出来ますが
結局ですよ、同じ構成でVPC切ったつもりにしてても、ｔｙｐｏなどで
設定差異が発生したりするんですよ。

で？どうするのって？

そこで、でてくるのが冒頭にも書いた通りのTerraformとか、CloudformationとかAnsibleですね。
コードでかけば、例えば、本番のVPC定義をまるっとコピーして
VPC名やセグメントでバッティングする項目だけ変更すれば、基本的には同じ構成になりますよね？

さらに、AWSの既存構成をまるっとコードに落とせるOSSもある

AWSの構成全体を、定義するのは流行としては、Terraformが多いみたいです。
よって、まずは、テスト的に作成したAWSのVPC環境をTerraform形式のファイルに
設定を落とし込むTerraformerというツールがOSSで配布されているようなので
それをまず使って、まるっとAWS環境の定義ファイルをこっちに持ってきてみます。
まずは、そこまでを直近やってみます。

そして、構成図をサクッと自動生成するツールもOSSである

CloudmapperというOSSのツールがある。
下記の様な物を自動生成するツールみたいだ。
これも、さっきのterrformにあわせて自動生成するように設定しておきたい。
テスト環境でテストしてみようと思う。

だいたいこのような事が出来れば、まあ、インフラ運用は楽になるんではないかと思われる。

ただ、大前提は！？

何でもそうですが、仕組みを作る上で、要件がまとまっていることは大前提。
特にインフラは、通信要件や運用の為の要件がまとまっていないと
いくら良い物を作ろうとしても絶対に作れないし
付け焼き刃で作っても、それが意図した構成かどうか？全く分からない事態が発生する。
よって、例えば、プロダクトを会社ごと買ってきて、その内部仕様なんかが全く無い
状況に置いて、これをインフラを刷新して、新たな物を作り出すなんて事は
Terraformがいくらいいからといっても不可能な事という事になります。

例を出すと、サブネットどうやって切りましょう？
分からないので、こちらとこちら切っておきますね。
この時点で、もはやセキュリティホールにないうる構成の第一歩を踏み出します。

RDSってどこからアクセスされます？
普通は、バックセグメントをきって、そこはインターネット側からのアクセスは
遮断して作るが定説ですが、いやー、どうしてもね、端末からDBつつきたいんですよって
要件があるとするじゃないですか？

サービスを提供する上で、それは流石に脆弱性の固まりじゃないですかね？
結局、そうしなくていい方法を考えないと、結局これで作り出した場合でも
そこにインターネットゲートウェイをサブネットに入れて、外部通信させたり
しなきゃ運用がまわないってなると、なにやってるんだか？ってなりますよね？

今後は特に！？

今までが、インフラは手で構築するのが当たり前の世界だったが、
これからは、インフラもコード化の波が容赦なく押し寄せてきている。
同じ構成のインフラを手で作るのは難しい、コードで作るのは複製して
IPやセグメントなど、バッティングしないように修正して、
ドライランして、問題がないようならデプロイして終わりという事になるのだろうか？
とりあえずは、terrform使った事がないので、とりあえずはそこからですね。
手持ちのAWS環境でテストして行きつつ、動作の確認をしていこうと思います。

The post Terraformとかつかってみる！？ first appeared on ～下町物語～.

この前のメンテナンスで、よく見ると凄くエラーをはいてる事に気がついてはいたんですが、あまりにもエラーがでるので、ちょっとだけ調べて見ました。Accessログより、エラーログの方が大きい・・・。汗

まあ、エラー内容を確認すると、何何！

とりま、ソースコードを出すプラグインで、正規表現のお作法が変わった為、エラーをはきまくっている用ですね。これは、アップデートするしかないのですが、この作者は3年前からプラグインの開発をやめたのか？アップデートがありません。よって、最近phpのVerを最新にあげたので、そこから出始めたようですね。php7.2辺りまでのVerならこのエラーは出ない想定だったんですが、最新にあげた事で、お作法の差異に引っかかった模様です。

さてと、どうしましかね？

私は、インフラの技術者なので、phpなんてほとんど分からない・・・。このWordpress色々いじってますが、本当よくわからんわって感じでいじっています。まあ、なんとかやってはいるんですが、コア部分になると全然分からないので自分で修正するのは、ハードル高いんですよねぇ。

色々探した所、

あるじゃないの！有志の方が、修正した物を配布している様です。これを今回は使わせて頂く事にします。

作業としては、ダウンロードしてきて、サーバに上げて解凍して、オーナーを変更して、該当ディレクトリから削除して、同じディレクトリ名にして置き換えるだけです。後で、diffかけてどこを修正したか、勉強がてら見て見ようと思います。それを、我が社のｐｈｐのエンジニアにちょっと聞いて見ようと思います。

提供元URLは下記の通り
https://github.com/Crunchify/crayon-syntax-highlighter/releases

本当にありがとうございます。感謝感謝です。

The post 半端なくエラー出まくり　WordPress first appeared on ～下町物語～.

管理画面にログインする画面が化けてしまった（汗

この現象数ヶ月前から知ってはいたけど、いつかなおせばいいかなって感じで、放置してたのですが、いよいよ重い腰を上げる事にしました。といっても、結局確定申告をするのが嫌で、目が違う方を向いただけで、それがなければ、まだやってなかったでしょうね。

原因を考えて見る

色々考えられるけど、結局の所CSSが当たってないんだろうな？ってのは、容易に想像がつく話ではあるのだが、それが何故？問われるとこっちも困るって事で、想定される原因を探ってみる。

• モジュールのアップデートなどで不具合がある場合
• フレームワークを更新せず、モジュールをアップデートした場合
• 表示高速化の為、キャッシュモジュールをいれているのだが、それのCSSマージなどが悪さをしている場合

まあ、この辺りだと思われる。考えたくないけど、脆弱性を突かれて突入されていて、不正な改造をされている場合もまあまあ、あるかなって気がする。過去2万通のメールを送ってしまった事例も目の当たりにしているだけの！ただ、今回はそういうのはなさそう。リソースも毎日確認しているし、トラフィックもアクセス相当のトラフィックを維持しているといった所からの判断である。

上記、とりあえず辺りをつけて、全てのモジュールをいったんOFFにしてみる。
結果は、何も変わらずorg　色々みたけど、やっぱりなんだか分からない・・・。

負けた感が半端ないので、力でねじ伏せる作戦に出る。
ログインだけのCSSを別途設定して、強制的にカスタマイズしたCSSを当てる暴挙にでたｗ
トップのファンクションに、使用しているテーマのディレクトリにログイン用のCSSを配置して、それを読み込ませる作戦。

wp-includes/functions.php

function login_logo() {
echo ‘<link rel=”stylesheet” type=”text/css” href=”‘.get_bloginfo(‘template_directory’).’/login.css” />’;
}
add_action(‘login_head’, ‘login_logo’);

wp-content/themes/使用テーマ/login.css

これに、適当なCSSを作成して当てる。そうすると、CSSの微調整はまだまだで若干崩れていますが、それなりに出るようになりました。

ただ、これを修復するために、動いているサーバからホットでスナップショットをとって、別インスタンス立てて修正した感じですが、メインの方に同じ実装をしたら同じ挙動にならず・・・。結局、色々やってたらDBが壊れて締まったようで、サーバ毎replaceをしました。DNSを昨日の夜中にレコードを変更して、この後アクセスみて、何も来てないようならインスタンスを削除して終わりにします。

全く、たまにこういうことがあるんですよねぇ。何故か、同じ事をやっても同じ状況にならないんですよ。1日前のインスタンスから戻したので若干アクセスカウンターが200～300の間でしょうけど、戻っちゃってます。まあ、誤差の範囲なので、仕方が無いです。

そのうち、このログイン画面ももう少しちゃんとCSSを調整して枠とがちゃんとしたいと思います。Wordpressの画像は、別のに差し替える予定で今は出してません。

2020/05/04　追記

WordPressのフレームワークを最新化したら、また同じ状況になったので、コロナだし、気合いを入れて調べて見ました。
原因は、分かった。そして、対策も講じた。そして、ちゃんと出るようになった。これは、筆者のサーバ設定に起因する原因で、そのような対策をしてないWordpressはきっと発生しない。CONTENTSタイプがtext/css が普通だが、何故か管理画面のページだけ、text/htmlで認識されていて、CSSだとは思ってもらえなかった用です。上記CONTENTSを出しているCSSは3つあって、それらのCSSが読み込まれなかった為に、フォームが崩れて表示されていた用です。nginxで強制的にCSSはtext/cssで返すように設定をいれて、完了にしました。

The post 管理画面にログインする画面が化けてしまった（汗 first appeared on ～下町物語～.

アタック！！

久しぶりにブログ書いてますが、errorログにアタックを検出したのでネタにしたいと思います。

まず下記がアタックされている様子のスクリーンショットです。222.185.238.250のGIPからアタックされていることが分かります。

アタック元

という事なので、これは中国からのアタックだという事が分かりますね。ウザイのでそろそろ対策を講じて行きたいと思います。方向性はアタックされるIPがある特定のルールに基づき自動BANされる仕組みをつくって行きます。

ブログを書きながら構成変更完了

○まずは、必要なツールをインストールをする。
sudo yum install fail2ban fail2ban-systemd

○次に、今回閉め出したいアクセスを検出するフィルターを作成する
sudo vi /etc/fail2ban/filter.d/wordpress_filter.conf

[Definition]
failregex = ^<HOST>.*POST.*(wp-login\.php|xmlrpc\.php).*$
            ^<HOST>.*"(GET|POST).*" (404|403) .*$
ignoreregex =

○フィルターを使っての動作を記述する
sudo vi /etc/fail2ban/jail.d/wordpress_jail.conf

[DEFAULT]
bantime  = 43200
findtime  = 3600
maxretry = 3
#banaction = firewallcmd-ipset
banaction = iptables-multiport
backend = gamin
action = %(action_mwl)s
ignoreip = 127.0.0.1/8

[recidive]
enabled = true
bantime = -1
findtime = 259200
maxretry = 2

[sshd]
enabled = true
port = 2345

[wordpress]
enabled = true
filter = wordpress_filter
logpath = /var/log/nginx/*access.log

この辺りで設定した正規表現で該当アクセスを検出できているか？確認
今回で言うと、下記の問題中国からのアタックを閉め出したい訳なので、該当アクセスにヒットしている事を確認

fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wordpress_filter.conf –print-all-matched

|  222.185.238.250 - - [06/May/2019:03:31:21 +0900] "GET /123131/index.php HTTP/1.1" 404 548 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)" "-"
|  222.185.238.250 - - [06/May/2019:03:31:21 +0900] "GET /program/index.php HTTP/1.1" 404 548 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)" "-"
|  222.185.238.250 - - [06/May/2019:03:31:21 +0900] "GET /shopdb/index.php HTTP/1.1" 404 548 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)" "-"
|  222.185.238.250 - - [06/May/2019:03:31:21 +0900] "GET /phppma/index.php HTTP/1.1" 404 548 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)" "-"
|  222.185.238.250 - - [06/May/2019:03:31:22 +0900] "GET /phpmy/index.php HTTP/1.1" 404 548 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0)" "-"

下記で動作をprocessをスタートして状況を確認する

systemctl start fail2ban
systemctl enable fail2ban.service
systemctl status fail2ban

動作確認

[hogehoge@vaaabbb-daada-gfgfldnfkjdbafndsanfdaslnfasdl　]# tail -f fail2ban.log
2019-05-06 16:02:54,087 fail2ban.server         [19532]: INFO    Exiting Fail2ban
2019-05-06 16:09:17,749 fail2ban.actions        [20201]: NOTICE  [wordpress] Ban 106.72.132.224
2019-05-06 16:09:18,066 fail2ban.actions        [20201]: NOTICE  [wordpress] Ban 66.249.71.52
2019-05-06 16:09:18,781 fail2ban.actions        [20201]: NOTICE  [wordpress] Ban 66.249.71.50
2019-05-06 16:09:31,315 fail2ban.actions        [20201]: NOTICE  [wordpress] Unban 106.72.132.224
2019-05-06 16:09:31,524 fail2ban.actions        [20201]: NOTICE  [wordpress] Unban 66.249.71.52
2019-05-06 16:09:31,736 fail2ban.actions        [20201]: NOTICE  [wordpress] Unban 66.249.71.50
2019-05-06 16:09:34,038 fail2ban.actions        [20367]: NOTICE  [wordpress] Ban 106.72.132.224
2019-05-06 16:09:34,462 fail2ban.actions        [20367]: NOTICE  [wordpress] Ban 66.249.71.50
2019-05-06 16:09:34,979 fail2ban.actions        [20367]: NOTICE  [wordpress] Ban 66.249.71.52
2019-05-06 16:22:53,371 fail2ban.actions        [20367]: NOTICE  [wordpress] Ban 126.247.226.253

後は、zabbixで上記BANされたIPの数とUNBANされた数をカウントしてグラフ化するかな！

cat fail2ban.log | grep Ban | wc -l　この辺りをZabbixに叩かせてでた数字をグラフ化すると可視化できる。後ついでにslackにプッシュする設定を行う感じで外に出ている時に知る事が出来ますね。まあ、知った所で何もないんですがｗひとまず、張り付いて見張っている訳にはいかないので、これでいったん自動運転をしようと思います。

という事で、ひとまず、実装はできたのでこれで様子をみようと思います。
それでは、何か参考にして頂ければ幸いです。

その後

いいですねぇ。順調にブロックされているGIPがキャッチ出来ています。ブロックされていても、パケットカウントが増えているので、おそらくクラックツールとかで、プログラム的にRETRYを繰り返しているのかなと思われます。まあ、ぶっちゃそんなツールを入れて直にクラックする奴なんて滅多にいないので、クラックされて侵入されてどこかのサーバやらPCやらの中で動いて居るのだと思いますけどね。まあ、ひとまず、不審な行動をするとBANされて一定時間くると開放されるけど、ある回数BANを繰り返すと、そのIPは永久にBANされたままになる様に設定をしています。とりあえず、他の寄生先を見つけて、違うGIPからアタックをするくらいしかないですが・・・。同様の状況になるので、あまり意味はなさげかなと思います。

 pkts bytes target     prot opt in     out     source               destination
   23  2261 REJECT     all  --  *      *       203.81.114.124       0.0.0.0/0            reject-with icmp-port-unreachable
   19  4476 REJECT     all  --  *      *       153.181.242.38       0.0.0.0/0            reject-with icmp-port-unreachable
   22  3400 REJECT     all  --  *      *       210.188.25.185       0.0.0.0/0            reject-with icmp-port-unreachable
   51  3387 REJECT     all  --  *      *       180.198.72.160       0.0.0.0/0            reject-with icmp-port-unreachable
   16   916 REJECT     all  --  *      *       60.149.92.77         0.0.0.0/0            reject-with icmp-port-unreachable
   16  4926 REJECT     all  --  *      *       118.241.130.248      0.0.0.0/0            reject-with icmp-port-unreachable
   12   552 REJECT     all  --  *      *       115.28.245.132       0.0.0.0/0            reject-with icmp-port-unreachable
  198 11928 REJECT     all  --  *      *       80.250.82.41         0.0.0.0/0            reject-with icmp-port-unreachable
   15  5122 REJECT     all  --  *      *       153.172.130.235      0.0.0.0/0            reject-with icmp-port-unreachable
   69  4140 REJECT     all  --  *      *       66.249.71.52         0.0.0.0/0            reject-with icmp-port-unreachable
   79  4740 REJECT     all  --  *      *       66.249.71.50         0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       126.247.226.253      0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       123.217.103.91       0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       106.72.132.224       0.0.0.0/0            reject-with icmp-port-unreachable

The post アタックするの辞めてくれないかな！ first appeared on ～下町物語～.

ブログの更新をするときに最近ホワイトアウトして何もできなくなるので、昨日ちょっと調べました。
Webserverであるnginxの書き出すログを見るも、若干エラーもあるものの該当事象にヒットしない。そこを修正しても、やはりホワイトアウトしてしまう。本当にいきなり出来なくなるので、まだ何やらクラックされたりしてたらいやだなぁと思いつつ調査を進める。

おそらく、あやしいのはモジュールだと当たりをつけて、モジュールを全部無効化してテストする。結果、全くホワイトアウトしない。やっぱりなぁ。って、その時点で１つ心あたりがあったんですが、徐々に有効化して絞り込んだ。

最後にそれを抜いて更新してみる。ホワイトアウトしない。やっぱりなぁ。ってことで、更新時にインスタグラムに自動で記事を共有しているモジュールがガンでした。更新時にインスタグラムに情報を送って自動投稿しているところで、インスタAPIの仕様が変わったりなんかして、正常に動かなく鳴ったのだと思います。

それにしても、あまりいいインスタグラムへの投稿モジュールが、今ないんですよね。有料ならあるんですが、無料のはほぼほぼないです。とはいえ、自動では無いけど、昨日別のモジュールを入れたのでもう大丈夫ですね。今日から改めて更新してインスタグラムにも投稿したいと思います。この記事も、この後インスタにアップします。

The post ブログの更新時にホワイトアウト first appeared on ～下町物語～.