最初に、この投稿内容に誤りがありました。それは、F2Bは四アマでは許可されないと思い込んで申請した内容となっていますが、本当は四アマでもF2Bは許可されるようです。詳しくはコメント欄を読んで下さい。

投稿内容は修正せず原文のまま残しますので、注意して下さい。

 

いつもQSOのお相手をして頂ける本庄のOMさんに影響を受け、JT65の申請をしました。5月16日の夕方5時過ぎ(記憶が正しければ)に電子申請して、その日の内に状態が審査中になったので、びっくり。普通、このタイミングだと受付処理中じゃね?とか思いましたが、審査中と言う事で期待が高まりました。

で、申請から9日後の本日、審査終了となりました。不備も無く順調に終了です。まぁ、JT65(F1D)のみの申請だったので当たり前?

最初はOMさんの助言通りデジタル全部申請しようとして、資料集めを開始しました。

でも当初から気になっていた、四アマで許可される電波型式。するとRTTYやPSKなどは四アマでは許され無い電波型式F2Bを使用する事が分かりました。

それならと、F2Bを使用しないデジタルを1.9MHzから430MHzまでの、四アマに許されたバンドで申請しようと、あのLiteで入力して行きました。

ところが、この入力作業が大変。どこがLiteだよ〜総務省。バンド数も電波型式も沢山あるので、入力中の時間切れが2回。途中から、これでスムーズに許可されるのか不安になったり、面倒にもなり…。

結局、JT65の運用が出来れば満足なのと、F1Dだけなら一括記載コードの変更無しで行けるので楽。それで、だいぶ縮小して電波型式F1DのJT65のみで、バンドは7、21、24、28、50MHzでの申請としました。

私はまだ四アマなので21MHzが中心になります。本当はJT65が盛んな14MHzがいいなぁ〜。

私がブログ投稿時に愛用するアプリが

  • Markee
  • TwinCollage
  • PressSync
  • WordPress

これはMarkeeでトリミング

2枚の写真を並べて1枚のシンプルな画像にしたい時は、TwinCollage

で、実際の投稿はPressSyncで行い、コメントの確認や返事はWordPress(iPhoneアプリ)でやっています。

私が利用するブログの環境は

  • サーバは自宅のMac mini G4(Ubuntu)
  • CMSはWordPress

ネギ圃場の雑草処理に役立ちそうな農具を使ってみる事にしました。

新魔法のカルチW(ねぎ用) SM-HS-1

カルチ使用前の草。えーと、縦に細く長いのはネギですよ。

写真の様に小さな草なら、カルチの調整が上手くいけば、いい感じに処理出来ます。ただ調整時に不満なのは蝶ネジが小さく、しっかり締めると手で緩まなくなりイラッとしました。ここは改善の余地有りかなと思います。

 
 

早速、ホームセンターで手に入れたイモネジ(六角レンチ付き)に変えました。

購入したホーローセット M6

左は変更前の蝶ネジ、右が変更後のイモネジ

今日は、午後の4時過ぎになってからハンディ機を持って赤城山に登りました。もちろん車です。

大胡赤城線(県道16号)の忠治温泉側から登ると、2ヶ所程で他の人達が移動運用をされていた様です。私はそのまま通り過ぎ牛石峠で車を止めました。そこは標高1422mで関東平野が開けて居る所。今日はあいにく曇りで視界が良く有りませんでした。

FT2Dでワッチすると、QUSの小林さんが移動運用していましたので、コールしました。結局この交信だけで私の移動運用は終了。時間も遅いし八木アンテナを使用した受信が目的だったので、目的以上を達成です。

帰り道は、覚満淵の写真を撮って前橋赤城線(県道4号)の一之鳥居がある側で下りました。数年ぶりの赤城山でしたが、乱開発は無く殆ど昔のままで懐かしく思いました。

私のホームQTHが赤城山の裾野なので、赤城山は直ぐに行ける絶好の移動運用地です。今後も利用して行こうと思います。

 
 

移動運用地 : 赤城山牛石峠

これは近くの覚満淵

私の自宅サーバもDDoS攻撃を受けている模様。

私のブログの表示が重く、なんか変。その内、サーバマシンのMac mini G4(Ubuntu)がファンの音で煩くなって来たり、ネットのアクセスも頻繁になっている。やっぱり変だと言う事で、Apache2のアクセスログを覗いて見ました。そしたら、同じIPからWordPressのxmlrpc.phpへ大量のアクセス。グーグル先生によると、これはDDoS攻撃らしいです。うちなんかのサーバにどうして攻撃?

システム負荷(load average)が36.09。この値、普段は0.04程なので高負荷みたいです。

対策前の状態

 
 

対策として、グーグル先生の記事を参考にとりあえず

xmlrpc.phpへのアクセスをローカルエリア内に限定する記述を.htaccessに書き込みました。

私はスマホでブログを書くので、この方法にしました。

その後、相変わらず攻撃は続いているけど、システム負荷は通常に戻りました。やれやれ。

対策後の状態

 
 

追記
翌日になってもxmlrpc.phpへのアクセスが続くので

ルーターを送信元のアドレスからのパケットを破棄する設定にしました。

そのアドレスは、185.130.4.xxxと他複数です。

この設定は、相手に返事のパケットを返さないので、相手にして見ればこちらが存在するかどうかが確認出来ない状態になります。よって攻撃を止める可能性が高くなる…かなぁ〜。

でも、こうやってご親切に対策方法をブログに書いていれば、相手にも分かってしまい、他の手段で攻撃されるとも限りませんがね〜。でも私のサーバを攻撃してもつまらない事なのにね。

勉強になりました。Thank You.

 
 

もう一度追記
この投稿をしてから1か月以上経った現在の状況

xmlrpc.phpへのアクセス制限を.htaccessに書き込むだけで充分効果がある。

と思います。相変わらず1日当たり数件アクセスがありますが、同じアドレスから大量のアクセスは無くなりました。