VmWareからの贈り物またはホスティングでサーバーをブロックする方法

土曜日の夜にキノコの散歩を楽しんで、ラップトップの奇妙な状態を発見しました。 -インターネットが機能しません。 -サーバーがインストールされ動作しているVPN。 VPNを切断すると、すぐにヘッツナーから「幸福の手紙」を受け取りました。 親愛なるサーまたはマダム 上記のIPアドレスを持つサーバーは、インターネット上の別のサーバーに対して攻撃を実行しました。 これにより、ネットワークリソースに大きな負担がかかり、その結果、ネットワークの一部が悪影響を受けました。 したがって、予防措置としてサーバーは非アクティブ化されています。 対応するログ履歴は、このメールの最後に添付されています。

robot.your-server.deのWebサイトでは、3つのIPのうち1つだけがブロックされ、メインサーバーの機能が動作しているため、タスクが少し簡単になったと述べています。

これは何ですか サーバーが壊れましたか？ 私のオープンリゾルバテストの予期しない効果は？ 私のラップトップはマルウェアやボットネットを拾いましたか？



添付のログファイル（以下を参照）から追加の質問が寄せられました。

-攻撃がグレーのIPに進む理由（私のネットワークでは他のアドレスを使用しています）。

-なぜnetbiosプロトコルが選択されているのか。

14:47:27.911048 IP 78.XYZ50189 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST 14:47:27.911098 IP 78.XYZ56865 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST 14:47:27.911448 IP 78.XYZ58051 > 172.16.96.1.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST 14:47:27.911453 IP 78.XYZ53676 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST 14:47:27.911502 IP 78.XYZ62404 > 172.16.96.1.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST 14:47:27.911548 IP 78.XYZ50392 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST 14:47:27.911598 IP 78.XYZ64778 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST 14:47:27.911698 IP 78.XYZ60961 > 172.16.96.1.137: NBT UDP PACKET(137): REFRESH(8); REQUEST; UNICAST
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

仮想化を使用しているため、最初にdom0のログとアクティビティをチェックしました。疑わしいものは見つかりませんでした。

新たに展開された仮想マシン（そのうちの1つはワードプレスのもの）、Windows仮想マシン、ラップトップにインストールされたWindows仮想マシンによって、さらに疑問が提起されました。

Linuxサーバーをチェックしても問題は明らかにならず、リモートのWindows仮想マシンはオフになっており、ローカルのWindowsにウイルス対策ソフトウェアがインストールされていました（それ以前にデフラグソフトウェアがインストールされ、疑念を引き起こしました）が、何も見つかりませんでした。

さらに、dom0では、netbiosパケットのフィルタリングルールを設定しましたが、それらは機能しませんでした（後で判明したように、そこでは適用しませんでした）。

診断によるロック解除に関するヘッツナーへの最初の手紙は、ネットワーク上のなりすましの場合ではなく、未回答のままでした。

念のため、tcpdumpを開始しました（そして、なぜすぐに実行しなかったのですか？）、そして、驚くべき結果を示しました：

 21:55:01.985310 IP XYWZnetbios-ns > 172.16.96.1.137.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 21:55:01.985472 IP XYWZnetbios-ns > 172.16.96.1.137.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 21:55:01.985557 IP XYWZnetbios-ns > 172.16.96.1.137.netbios-ns: NBT UDP PACKET(137): RELEASE; REQUEST; BROADCAST 21:55:01.987328 IP XYWZnetbios-ns > 172.16.96.1.137.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私のサーバーはそのようなリクエスト（1秒あたり200を超えるリクエスト）を受信し、リクエストはラップトップから送信されます。 ラップトップで実行されているTcpdump（Macbookを持っています）はこれを確認します。 ソースを特定するために、アプリケーションを1つずつ消すことにし、VmWare Fusion 5.04が最初に手に入ります。 奇跡的に、リクエストは消えます。 VmWare Fusionと仮想マシンのその後の起動では、同様の結果は得られません。 VmWare FusionとNetbiosの関係をすばやく探して、2012 VmWareコミュニティで素晴らしい投稿を見つけました。 2.5年以上にわたって、VmWareはこのバグを修正しなかったことがわかりました。 これは私の作業中のラップトップなので、常に会議に持ち込みます。 どうやら、どこかで、彼はIP 172.16.96.1でWINS設定をキャッチしました。

その後のHetznerとのやり取りは少し愚かでした（問題が解決したことを3回確認しなければならず、サーバーにアクセスできました）が、生産的です。 IPは約1時間後にブロック解除されました。

将来このような問題を防ぐために、追加のiptablesルールを確立します（今回は適切な場所にあります）：

 -A RH-Firewall-1-INPUT -p udp -m multiport --dports 137,138,139 -j DROP
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「攻撃」VmWareとの戦いで頑張ってください！