ファイヤーウォールに不正アクセスを試みた形跡が24,945件もあった

 会社のファイヤーウォールのSYSLOGを日々細かく確認しているが、今回はSSHに対する不正アクセスを試みた形跡が24,945件も見つかった。幸いにして、不正アクセスは失敗に終わったようだ。

攻撃は2023/05/28 13:30:13から始まり2023/05/28 13:34:16まで間断なく続いた。この間、SSHD: login failed, 164.92.70.22が24,945件。不正アクセスを試みる件数としては過去最大。

これは一部のログ。

当然、該当IPアドレスはファイヤーウォールでブロックした。

日々のSYSLOGの監視は重要だ。

Visual Studio 2022 ツールボックスにアイテムを追加しようとすると異常終了してしまう

 Visual Studio 2022のツールボックスにアイテムを追加しようとして、[ツールボックス] → [アイテムの選択]でツールボックス アイテムの選択画面が表示されアイテムを読み込み始めるが、Visual Studio 2022が途中で異常終了してしまう。何度か試してみたが変わらなかった。

この画面の途中でVisual Studio 2022が異常終了してしまう。

仕方がないので、 Visual Studio 2022の修復を試してみたが、それでも変わらず。

最後の手段として Visual Studio 2022をアンインストールし、再インストールしてみた。

それでも変わらず。

ネットで検索して Visual Studio 2022のセーフモードでやったら上手くいったとの情報を得た。

操作方法は、

DOS窓を開いて、

"C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\devenv.exe" /SafeMode

でVisual Studio 2022をセーフモードで起動し、[ツールボックス] → [アイテムの選択]でツールボックスにアイテムを追加して終了。

その後、普通にVisual Studio 2022を起動するとツールボックスにアイテムが追加されていたし、[ツールボックス] → [アイテムの選択]でツールボックス アイテムの選択画面を表示しても正常にアイテムの読み込みが完了した。

JREインストーラーから.MSIファイルを抽出する方法

 オラクルがサン・マイクロシステムズを買収したことで、JREインストーラーから.MSIファイルを抽出する方法が変わった。

JREインストーラーをダウンロードし、セットアップを起動。

この状態で

.MSIファイルは以下のフォルダー内にある。

C:\Users\ユーザー名\AppData\LocalLow\Oracle\Java\jreバージョン番号

セットアップを中断すると.MSIファイルは削除されてしまうので、この画面を表示したまま取得。

VB.NETでSQL SERVERのSP(ストアドプロシージャ)からRETURN値を受け取る

 SQL SERVERを使ったプログラムを相当作っていたのだが、SPが返すRETURN値を受け取る方法を知らなかった。今回、初めて知ったのでメモ。

        Dim rc As Integer = 0 ' RETURN値
        Using connection As New SqlClient.SqlConnection(My.Settings.kntnkConnectionString)
            ' コネクションを開く
            connection.Open()
            'コマンドをコネクションから作成する
            Dim command As SqlClient.SqlCommand = connection.CreateCommand
            Try
                ' #ストアドプロシージャを実行する
                With command
                    ' SQLサーバーのタイムアウト時間
                    .CommandTimeout = 60
                    ' 実行するストアドプロシージャ名を指定
                    .CommandText = "SE050_対象品番抽出"
                    ' ストアドプロシージャのパラメータを設定
                    ' commandオブジェクトのパラメータを初期化する
                    .Parameters.Clear()
                    .Parameters.Add("@UserID", SqlDbType.VarChar).Value = G_UserID
                    .Parameters.Add("ReturnValue", System.Data.SqlDbType.Int)
                    .Parameters("ReturnValue").Direction = System.Data.ParameterDirection.ReturnValue
                    ' コマンドの種類をストアドに変更
                    .CommandType = CommandType.StoredProcedure
                    ' コマンド実行
                    .ExecuteNonQuery()
                    rc = CInt(.Parameters("ReturnValue").Value)
                    Debug.WriteLine("SE050_対象品番抽出 returnValue=" & rc.ToString)
                End With
            Catch ex As Exception
                QueriesTableAdapter.InsertQuery_TK_SYSLOG("", "", "SE050K01_原材料未登録部品登録", ex.Message & vbCrLf & GetCurrentLineNumber.ToString & "行目を実行中", G_UserID)
                MsgBox(ex.Message)
            End Try
            'コネクションを閉じる
            connection.Close()
        End Using

Windows 10 Proで再起動時はシャットダウンスクリプトが動作するが、シャットダウンするとシャットダウンスクリプトが動作しない件

Windows 7 Proの時代からエンドユーザーのPCのシャットダウン時にシャットダウンスクリプトを動作させていた。しかし、Windows 10 Proに同様のことをやると再起動時は正常にシャットダウンスクリプトが動作するのに、シャットダウンを選択してWindowsをシャットダウンさせるとシャットダウンスクリプトが動作しない。

何故なのか原因を調べるためにWindows 10 Proの動作を見ていたら、7に比べて10は異様にシャットダウン時間が短いし、起動時間も短い。ひょっとしてここに原因があるのではないかと思い、[高速スタートアップを有効にする]のチェックを外したら、希望通りの動作になった。

高速スタートアップはWindows 10の終了時にメモリーやCPUの状態を保持することによってWindows 10の起動を高速化する機能である。つまり、次回の起動時も、前回終了時と同じ環境でなければならない。その為に、シャットダウンスクリプトの動作が規制されている気がする。

何にしても、新しいOSに移行すると色々と問題が発生するのは世の常である。

ネットワークの速度が遅い

ある日、インターネットからファイルをダウンロードしようとした。ファイルのサイズは50MB。直ぐに終わるかなと思ってみていたら、何とダウンロードの時間は2時間と表示された。我が目を疑ったが確かに2時間と表示されている。そういえば、ここ最近、インターネット上のホームページを見たり、ファイルを転送するのに以前に比べて時間がかかるようになっていた。たかが、50MBのファイルをダウンロードするのに2時間もかかるようでは問題なので本腰を入れて調査をしてみた。

ルーターのRTX1210のトラフィック情報(PP)を確認してみる。

PP[01] INの最大値が5Mbps～10Mbpsの間で安定している。そして、LAN1のOUTの最大値がほぼ同じ値を示している。普通こんな事はあり得ない。通常のトラフィックは波があるはずなのにこれはどうしたことか。先ずはてっとり早くLAN1に接続してあるUTPを1番ポートから順に抜いてみて変化が起きるか見てみる。1番を抜く。暫く待っても変化無し。1番を戻して2番を抜く。これまた暫く待っても変化無し。これを全ポート実施。しかし、どのポートを抜いても変化がない。これは何か特定の機器が問題の原因ではなさそうだ。

今度は、RTX1210のポートミラーリングを使ってLAN1のパケットをLAN8にも出力するように設定し、LAN8に私のPCを接続してWiresharkでパケットを解析してみる。

暫く解析を続けていると、IPアドレス:210.143.147.137、210.143.147.162に対してパケットの送受信が多い。Whoisで組織名を調べると、フリービット株式会社。日本の企業の様だ。ホームページで企業情報を見るとネットワーク関連企業だが、どうもうさん臭い。何となくコーポレートサイトという感じが希薄だ。

このフリービット株式会社が保有しているIPアドレス210.143.146.0/23をRTX1210のIPパケットフィルターで廃棄してみた。その結果がこれ。

パケットを廃棄した瞬間から、見事なまでに占有されていた帯域が開放された。この後、先程ダウンロードした50MBのファイルを再度ダウンロードしたら、僅か2分で完了した。今後は、このフリービット株式会社に対して、どのPCの何のアプリがデータを送受信していたかを調査し、最終的な対策を講じるつもりだ。ひょっとしたらデータマイニングに使われていたりして。

2019/1/25 追記
これらのIPアドレスはマイクロソフトのONEDRIVE等で使用されていることが判明した。これらのIPアドレスへのパケットを破棄するとONEDRIVEが使えなくなる。仕方がないのでまたこれらのIPアドレスとの通信を許可した。しかし、今のところ以前の様にネットワークの帯域が占有されるという現象は発生していない。

Windows XPで動作していたアプリがWindows 7やWindows 10で動作しない

Windows XPで動作していた市販パッケージをWindows 7やWindows 10にインストールした際、設定ファイルが読み込まれなくて困った。何とか解決できたのでここに記す。

　市販パッケージのHogeをWindows XP SP3で使用していた。このご時世なので取り敢えずWindows 7で動作させようと思い、Windows 7のPCにインストールをしてみた。インストール先はC:\Program Files (x86)\Hoge\

　Hogeはプログラムのインストール先フォルダー内に存在するStockEnv.iniを実行環境ファイルとして読み込み動作する。7のPCにHogeをインストールし、XPのPCからStockEnv.iniを7のPCのプログラムのインストール先フォルダー内に上書きコピーしてセットアップ完了。早速Hogeを起動してみる。StockEnv.iniに指定したDBにアクセスされずデータが0件と表示されてしまう。もう一度StockEnv.iniファイルを確認すると指定のフォルダー内に存在しているし、ファイルの内容を確認してみたが問題ない。再度Hogeを起動してみる。やはり先程と同じ。因みに、ログインユーザーは標準ユーザー。

　試しに管理者として実行してみると、正常に動作する。権限が標準ユーザーだとダメ。何故だ？？

　この後、C:\Program Files (x86)\Hoge\のアクセス権を標準ユーザーに対してフルアクセスにしたり、プログラムをXP(SP3)互換にしたり、プログラムを再インストールしたが変化無し。何故だ？？

　ここで飛び出すのがSysinternalsSuiteのProcmon.exe。Hogeを起動しProcmon.exeでHogeがアクセスしているファイルを確認。すると、C:\Program Files (x86)\Hoge\StockEnv.iniにアクセスするが、その直後にC:\Users\xxxxxxxx\AppData\Local\VirtualStore\Program Files (x86)\Hoge\StockEnv.iniにアクセスし、そのファイルを変更している。インストール先フォルダー内のStockEnv.iniではなく、ローカル・セッティングフォルダー内に作成されたStockEnv.iniをアクセスしていたのか。だから、こちらが設定した内容でプログラムが起動してくれなかったのか。納得。

　そういえば、セキュリティ強化のため、Windows VistaからProgram Filesのアクセス権が厳格化されていたっけ。管理者の場合は問題なく動作したが、標準ユーザーの権限ではProgram Filesフォルダーにファイルを作成できず、それでローカル・セッティングフォルダー内にファイルが作成されていたのか。

　XPで動作していたアプリが7や10で期待通りに動作しないときはこの辺に原因があるかも。