http://kimikodover.blogspot.jp/2016/07/2.html
船体とキャビンの基本構造部分をMesh化
Blenderはしばらく使っていなかったので、操作方法を忘れてる。。。。
床や外殻のPhysics部分を含めて、18LIのデーター量ね。
後部デッキのエンジンルーム上部をテンダー置き場にしたのは成功だわ。
（↑ 自己満足厨？）
あと艤装や家具類を14LIで済ませれるかな？ ^^)
2016/07/28
家出用のハウスボート（2）
（「家出用Houseboat 2作目」からの続きです）
http://kimikodover.blogspot.jp/2016/07/2.html
船体とキャビンの基本構造部分をMesh化
Blenderはしばらく使っていなかったので、操作方法を忘れてる。。。。
床や外殻のPhysics部分を含めて、18LIのデーター量ね。
後部デッキのエンジンルーム上部をテンダー置き場にしたのは成功だわ。
（↑ 自己満足厨？）
あと艤装や家具類を14LIで済ませれるかな？ ^^)
http://kimikodover.blogspot.jp/2016/07/2.html
船体とキャビンの基本構造部分をMesh化
Blenderはしばらく使っていなかったので、操作方法を忘れてる。。。。
床や外殻のPhysics部分を含めて、18LIのデーター量ね。
後部デッキのエンジンルーム上部をテンダー置き場にしたのは成功だわ。
（↑ 自己満足厨？）
あと艤装や家具類を14LIで済ませれるかな？ ^^)
2016/07/26
Ubuntu 16.04.1 LTSへのUpgrade
BXBT-2807へ「Ubuntu Server 16.04 LTS」をインストールして、StandaloneなHypergridのOpensimサーバーを稼働させているのですが、リモートアクセスしたときのオープニングで「16.04.1」の表記に気づきました。 ← 今更？
公式発表では「16.04.1 LTS」は7月21日リリースなので、４～５日前になりますね。
時々は「apt-get update、apt-get upgrade」の通常作業をしていましたが、大量にupgradeされた記憶はありませんでしたから、簡単にポイントを通過したみたいです。
BXBT-2807はヘッドレスでの運用ですが、OSも含めて順調です～^^)
公式発表では「16.04.1 LTS」は7月21日リリースなので、４～５日前になりますね。
時々は「apt-get update、apt-get upgrade」の通常作業をしていましたが、大量にupgradeされた記憶はありませんでしたから、簡単にポイントを通過したみたいです。
BXBT-2807はヘッドレスでの運用ですが、OSも含めて順調です～^^)
2016/07/22
ロシアからの気持ち悪いアクセス
昨日と今日、ロシアからこのブログへの、異常なアクセスが目立ちます。
以前には、ウクライナへロシアが侵攻したときに、ウクライナからのアクセスが増えた時期がありましたが、ロシアからは今回が初めてです。
この２年間ほどの記事を、一通り閲覧したみたい。
でも、ロシアの悪口は、怖いのでどこにも記載していませんよね。
ウクライナでジャーナリストが爆殺された事件との関係かな～。
共産圏の国って、気持ち悪いことをするのね～～ ＞＜
以前には、ウクライナへロシアが侵攻したときに、ウクライナからのアクセスが増えた時期がありましたが、ロシアからは今回が初めてです。
この２年間ほどの記事を、一通り閲覧したみたい。
でも、ロシアの悪口は、怖いのでどこにも記載していませんよね。
ウクライナでジャーナリストが爆殺された事件との関係かな～。
共産圏の国って、気持ち悪いことをするのね～～ ＞＜
2016/07/21
家出用のハウスボート（2作目）
2年前から途中で放置していたHouseboatの制作を、久しぶりに再開。。。。
まずは、全体バランスと色調を検討しています。
テクスはまだこれからですｗ。
う～～ん、、後ろのエンジンルームがちと目立ちすぎかな～？
キッチン、ベッド、トイレなどの家具類もすべて含めて、32LI縛り
さて、来年の夏までに進水させれるかな～～？
まずは、全体バランスと色調を検討しています。
テクスはまだこれからですｗ。
う～～ん、、後ろのエンジンルームがちと目立ちすぎかな～？
キッチン、ベッド、トイレなどの家具類もすべて含めて、32LI縛り
さて、来年の夏までに進水させれるかな～～？
2016/07/16
トレンドマイクロの迷惑アクセス（その３）
Opensim用の9010/tcpへ、相変わらず迷惑アクセスを寄こすトレンドマイクロです。
今日の発信元IPは、150.70.173.8
そこで、「トレンドマイクロによるWebサイト安全性評価」をかけてみました。
自社IPなので、誠実な調査結果が出ると思っていたのですが、「未調査」ですって。
他で調べてみると、数か所でブラックリストにアップされています。
http://whatismyipaddress.com/blacklist-check
cbl.abuseat.org
l2.apews.org
bl.mailspike.net
トレンドマイクロ社の資本系列を調べてみると、親元は隣国でした ← 今更？
「limit: avg 3/min burst 10」無視の強引さは、民族性から来るのかな？
それとも上記の、ufw標準が潔癖すぎるのかな？
今日の発信元IPは、150.70.173.8
そこで、「トレンドマイクロによるWebサイト安全性評価」をかけてみました。
自社IPなので、誠実な調査結果が出ると思っていたのですが、「未調査」ですって。
他で調べてみると、数か所でブラックリストにアップされています。
http://whatismyipaddress.com/blacklist-check
cbl.abuseat.org
l2.apews.org
bl.mailspike.net
トレンドマイクロ社の資本系列を調べてみると、親元は隣国でした ← 今更？
「limit: avg 3/min burst 10」無視の強引さは、民族性から来るのかな？
それとも上記の、ufw標準が潔癖すぎるのかな？
2016/07/04
トレンドマイクロの、Botな迷惑異常アクセスお断り（続編）
昨日の、「ufwで明示的にアクセス拒否」作戦は、あたしの思慮不足で失敗。
アクセスは拒絶できているのですが、[UFW BLOCK]がufw.logに残ります。
本来の目的は、トレンドマイクロの迷惑アクセスを拒絶して、ufw.logを見やすいものにすることでした。
そこで次に思いついたのは、ルーターでパケットフィルターを作動させる作戦です。
以下はルーターでのパケットフィルタでIPフィルター設定です。
動作：「WAN」側からのパケットを「無視」
宛先： Lan内すべて
送信元：150.70.0.0/16 ←Botが使用しているIP一括です
よく考えれば、これってIP-Banに使えるじゃん ← いまさら？
さて、これで完了すれば良いのだけれどね～ ^^)
でもトレンドマイクロさん、迷惑振り撒きながらもよくやるわね～～
----------------------------------------------------------------------------
（追記2016.7.5 7:50)
今朝ufw.logをみると、トレンドマイクロの迷惑アクセスの[UFW BLOCK]記録がありました。
今度は150.70.188.176ですが、ルーターのIPフィルターが効いていないじゃん。
google先生に聞くと、BBR-4HGのQ&Aで以下のような記載が見つかりました。
「ポート開放設定とパケットフィルタ（IPフィルタ）設定はどちらが優先されますか（BBR-4HG、BBR-4MG）」
『製品仕様によりポート開放（アドレス変換）設定が優先されます。
したがって、ポート開放設定で登録したポート番号を
パケットフィルタ（IPフィルタ）設定で閉じることはできません。
特定のIPアドレスに対し、パケットフィルタ（IPフィルタ）設定で
パケットの拒否を行った後にそのIPアドレスに対しポート開放を設定した場合、
パケットフィルタリングは無効となります。』
う～～ん、Raspberry_Pi2, XS35, Bxbt2807の3台にpacketを振り分けるため、アドレス変換を使用していましたので、これなしに設定するのは、相当に難しそう。
しばらくは、迷惑なLogが残るけど我慢するかな～。。。。
でも、自社の顧客の便宜をはかるために、他へは迷惑をかけてもかまわないというトレンドマイクロ社の姿勢には、疑問を感じます。
アクセスは拒絶できているのですが、[UFW BLOCK]がufw.logに残ります。
本来の目的は、トレンドマイクロの迷惑アクセスを拒絶して、ufw.logを見やすいものにすることでした。
そこで次に思いついたのは、ルーターでパケットフィルターを作動させる作戦です。
以下はルーターでのパケットフィルタでIPフィルター設定です。
動作：「WAN」側からのパケットを「無視」
宛先： Lan内すべて
送信元：150.70.0.0/16 ←Botが使用しているIP一括です
よく考えれば、これってIP-Banに使えるじゃん ← いまさら？
さて、これで完了すれば良いのだけれどね～ ^^)
でもトレンドマイクロさん、迷惑振り撒きながらもよくやるわね～～
----------------------------------------------------------------------------
（追記2016.7.5 7:50)
今朝ufw.logをみると、トレンドマイクロの迷惑アクセスの[UFW BLOCK]記録がありました。
今度は150.70.188.176ですが、ルーターのIPフィルターが効いていないじゃん。
google先生に聞くと、BBR-4HGのQ&Aで以下のような記載が見つかりました。
「ポート開放設定とパケットフィルタ（IPフィルタ）設定はどちらが優先されますか（BBR-4HG、BBR-4MG）」
『製品仕様によりポート開放（アドレス変換）設定が優先されます。
したがって、ポート開放設定で登録したポート番号を
パケットフィルタ（IPフィルタ）設定で閉じることはできません。
特定のIPアドレスに対し、パケットフィルタ（IPフィルタ）設定で
パケットの拒否を行った後にそのIPアドレスに対しポート開放を設定した場合、
パケットフィルタリングは無効となります。』
う～～ん、Raspberry_Pi2, XS35, Bxbt2807の3台にpacketを振り分けるため、アドレス変換を使用していましたので、これなしに設定するのは、相当に難しそう。
しばらくは、迷惑なLogが残るけど我慢するかな～。。。。
でも、自社の顧客の便宜をはかるために、他へは迷惑をかけてもかまわないというトレンドマイクロ社の姿勢には、疑問を感じます。
2016/07/03
トレンドマイクロの、Botな異常アクセスを正式にお断りしてみました。
SSはいつものトレンドマイクロからの迷惑アクセス記録です。
（Raspberry_Pi2でJOGへOpensimを接続しているサーバーのufw.logです）
今日の発信元は150.70.173.44
中国からの不正アクセスよりも頻度が高くなってきました。
トレンドマイクロの調査Botと思われますが、対象ポートは9010/tcpで、OpensimでJOGへ常時接続しているポートですから、どこへも解放しています。
しかし、ufwがブロックしているのは、異常な接続をしようとしているからですよね。
iptableの以下の記載部分で接続拒否をしているのだと思います。
limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "
連発の醜い接続は、会社の姿勢が問われるかもしれませんね～。。。。＞＜
ufwがブロックしない程度の、おとなしい(？)接続なら問題にしないのに。。。。
でも、このBotはアフォかも？
数時間前や昨日に調べた内容を覚えていないのかしら？？？
しかも、ufwの標準設定でも怪しまれてブロックされてるしね。
会社の悪名までたどれる足跡を残すのは、やっぱりアフォなBotだわ ＾＾）
残念ですが入口での接続拒否の処置をします。
sudo ufw deny from 150.70.0.0/16 to any port 9010
この会社のBotからの接続を拒否すると、ここの製品である「ウィルスバスター」から危険ホスト扱いされるかも知れないといううわさがあるのですが、どうなるんでしょうね～？
いあ、今までもufwでブロックしていたんだわ。
迷惑接続のLogに載らないようにしただけですね。。。。。^^)
--------------------------------------------------------------
（追記2016.7.3 21.50）
作戦失敗です。。。。＞＜
ufwで接続拒否はできるのですが、やっぱり SSのような"[UFW BLOCK]したLogが記録されます。
う～ん、次の作戦を考えます。。。。 ←楽しんでる？
（Raspberry_Pi2でJOGへOpensimを接続しているサーバーのufw.logです）
今日の発信元は150.70.173.44
中国からの不正アクセスよりも頻度が高くなってきました。
トレンドマイクロの調査Botと思われますが、対象ポートは9010/tcpで、OpensimでJOGへ常時接続しているポートですから、どこへも解放しています。
しかし、ufwがブロックしているのは、異常な接続をしようとしているからですよね。
iptableの以下の記載部分で接続拒否をしているのだと思います。
limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "
連発の醜い接続は、会社の姿勢が問われるかもしれませんね～。。。。＞＜
ufwがブロックしない程度の、おとなしい(？)接続なら問題にしないのに。。。。
でも、このBotはアフォかも？
数時間前や昨日に調べた内容を覚えていないのかしら？？？
しかも、ufwの標準設定でも怪しまれてブロックされてるしね。
会社の悪名までたどれる足跡を残すのは、やっぱりアフォなBotだわ ＾＾）
残念ですが入口での接続拒否の処置をします。
sudo ufw deny from 150.70.0.0/16 to any port 9010
この会社のBotからの接続を拒否すると、ここの製品である「ウィルスバスター」から危険ホスト扱いされるかも知れないといううわさがあるのですが、どうなるんでしょうね～？
いあ、今までもufwでブロックしていたんだわ。
迷惑接続のLogに載らないようにしただけですね。。。。。^^)
--------------------------------------------------------------
（追記2016.7.3 21.50）
作戦失敗です。。。。＞＜
ufwで接続拒否はできるのですが、やっぱり SSのような"[UFW BLOCK]したLogが記録されます。
う～ん、次の作戦を考えます。。。。 ←楽しんでる？
2016/07/02
Ubuntu-Sever 16.04 LTS のBug？、あるいは仕様変更？
前の日記で、「chkrootkitからの誤報＞＞Back_doorが仕込まれた？」って表現しましたが、どうもUbuntu-Sever 16.04 LTS のBugか、仕様変更のどちらかの原因だった感じがしています。
Linux/EburyやOperation Windigoを調べていて、以下の日本語の記事を見つけました。
「オペレーションWindigo：大量のLinuxサーバーの認証情報を盗むマルウェア活動を解き明かす」
http://canon-its.jp/eset/malware_info/news/140626/
記事内で、Windigoの検出方法が紹介されていますが、抜粋は以下の通りです。
「「Linux/Ebury」の場合、シェルから「ssh -G」というコマンドを打ってみる。「Linux/Ebury」は、本来「G」というオプションは存在しないため、感染していなければ、「ssh: illegal option -- G」とエラーが返される。「Linux/Ebury」が、「-Gオプション」を追加する特徴を逆手にとったチェック方法だ。
他の海外の記事でも、Windigo感染有無の見分けるには、以下の命令実行で済むと紹介されてます。
ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "System clean" || echo "System infected"
どちらの見分け方も、原理は同じですね。
chkrootkitも同様の判定手法を採用しているとのことです。
そこで、家で稼働している3つのlinuxで試してみました。
１）raspberry_pi2機 Linux raspi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l
２）XS-35機 Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-91-generic i686)
３）bxbt機 Ubuntu 16.04 LTS (GNU/Linux 4.4.0-28-generic x86_64)
「ssh -G」を実行してみますと、
１）では「ssh: illegal option -- G」
２）では「unknown option -- G」
３）「illegal option あるいunknown option」の返答なしです。
これで、chkrootkitが警報を出した原因が解ったような気がします。
でも３）のbxbt機で、Ubuntu-server 16.04 LTSのクリーンインストール直後の最初の立ち上げでも、「ssh -G」の実行結果は同じになります。まさか、最初からrootkit付きのimgファイルが配布されたとは思えませんし。。。
Ubuntu 16.04でopenssh-clientの仕様変更がなされたのか、それともバグなのかがはっきり解りません。
７月末リリース予定の16.04.01 LTSで元に戻るかな～？
---------------------------------------------------------------------
（追記2016.07.02 15:20）
仕様追加で-GがOKになっていますね。。。。
http://man.openbsd.org/ssh
「 -G Causes ssh to print its configuration after evaluating Host and Match blocks and exit.」
最初に表記される以下の部分に「-G」がないので、誤解していました。
ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file] [-L address]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-Q query_option] [-R address] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] [user@]hostname [command]
でも、rootkitが仕込まれたのではないことが判りましたので、一安心です^^)
Linux/EburyやOperation Windigoを調べていて、以下の日本語の記事を見つけました。
「オペレーションWindigo：大量のLinuxサーバーの認証情報を盗むマルウェア活動を解き明かす」
http://canon-its.jp/eset/malware_info/news/140626/
記事内で、Windigoの検出方法が紹介されていますが、抜粋は以下の通りです。
「「Linux/Ebury」の場合、シェルから「ssh -G」というコマンドを打ってみる。「Linux/Ebury」は、本来「G」というオプションは存在しないため、感染していなければ、「ssh: illegal option -- G」とエラーが返される。「Linux/Ebury」が、「-Gオプション」を追加する特徴を逆手にとったチェック方法だ。
他の海外の記事でも、Windigo感染有無の見分けるには、以下の命令実行で済むと紹介されてます。
ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "System clean" || echo "System infected"
どちらの見分け方も、原理は同じですね。
chkrootkitも同様の判定手法を採用しているとのことです。
そこで、家で稼働している3つのlinuxで試してみました。
１）raspberry_pi2機 Linux raspi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l
２）XS-35機 Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-91-generic i686)
３）bxbt機 Ubuntu 16.04 LTS (GNU/Linux 4.4.0-28-generic x86_64)
「ssh -G」を実行してみますと、
１）では「ssh: illegal option -- G」
２）では「unknown option -- G」
３）「illegal option あるいunknown option」の返答なしです。
これで、chkrootkitが警報を出した原因が解ったような気がします。
でも３）のbxbt機で、Ubuntu-server 16.04 LTSのクリーンインストール直後の最初の立ち上げでも、「ssh -G」の実行結果は同じになります。まさか、最初からrootkit付きのimgファイルが配布されたとは思えませんし。。。
Ubuntu 16.04でopenssh-clientの仕様変更がなされたのか、それともバグなのかがはっきり解りません。
７月末リリース予定の16.04.01 LTSで元に戻るかな～？
---------------------------------------------------------------------
（追記2016.07.02 15:20）
仕様追加で-GがOKになっていますね。。。。
http://man.openbsd.org/ssh
「 -G Causes ssh to print its configuration after evaluating Host and Match blocks and exit.」
最初に表記される以下の部分に「-G」がないので、誤解していました。
ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file] [-L address]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-Q query_option] [-R address] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] [user@]hostname [command]
でも、rootkitが仕込まれたのではないことが判りましたので、一安心です^^)
登録:
投稿 (Atom)