TFTPハニーポットの結果

私のTFTPハニーポットは1ヶ月以上、月額5ドルのVPSで常時、そして自宅のDell R530サーバーで断続的に稼働してきました。それがどのような驚きを捉えたのか、確認する時が来ました。 TFTPハニーポットが稼働しているとき、両方のサーバーは1日あたり20〜50のTFTPパケットを観測します。両方のサーバーは、ほぼ同じトラフィックを観測します。 UDPポート69のトラフィックを毎日、そのほとんどがTFTP形式で受信したときは非常に興奮しました。しかし、トラフィックのほとんどが7つのインフォセキュリティ企業からの定期的なスキャンであることに気づき、落胆しました。 インフォセキュリティ企業の スキャン Shadow Servers 5つのERRORパケット、約11秒に1つ コード4、メッセージ「Bad Filename」 コード0、メッセージ「Access violation」 コード4、メッセージ「4」、余分な1バイト「\x05\x00\x044\x00\x00」 コード5、メッセージ「Illegal TID」 コード4、メッセージ「Illegal TFTP operation」 RRQ（Read Request） for a.pdf, octet, ERRORパケットのバーストとは異なるスケジュールで Censys RRQ for /a, netascii Driftnet RRQ for 8つのランダムに選ばれた文字の名前のファイル, netascii ファイル名パターン "[a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z]" 時折IPv6経由で Shodan 16バイトの非準拠UDPペイロードの16進数表現: 00000417271019800000000000034925 約半分の時間はUDPポート18020から到着 2分以内に4〜6パケットのバースト、2つ以上のIPアドレスから Secretive Palo Alto Networks RRQ for /a, netascii、続いてRRQ for file, octet。 Netscout RRQ for ファイル名 ay9mfwq7xxmd4w6c7\xa0, octet Internet Census RRQ, ファイル名 /a, netascii 16バイトの非準拠UDPペイロード、2つとして全く同じものはない16進数: 000004172710198000000000xxyyzzww Shodanの非準拠UDPペイロードに表面的に似ている はい、3社が定期的にダウンロード用に「a」という名前のファイルをリクエストしています。 リクエストの区別を付けるのは面倒でした。コマンドラインwhoisは非常に規則的な出力を提供しません。私はwhoisから3社の各CIDRデータを取得し、grepcidrを使用してCIDRに基づいてログエントリを再抽出し、各社のログエントリをすべてキャッチしたかを確認し、ログエントリをそれらの会社に正しく割り当てました。 これらの7社は、ほとんどの場合、それ自体に登録されているIPアドレスを使用しています。ほとんどのIPアドレスにはDNSにAレコードがありません。whoisを通じてアドレスの所有者を見つけることができました。Shodanは例外で、時折自社のIPアドレスを使用し、時折Digital Oceanのアドレスを使用します。 これらの会社のプローブのほとんどについて、「約1日1回」というスケジュール以外は何も識別できません。 35日間で、私の常時稼働TFTPハニーポットは、Palo Alto NetworksのIPv4アドレスから35ペアのプローブを取得しました。ペアの各リクエストは約45秒間隔で到着します。ペアの最初のリクエストの平均到着間隔は24.09時間、最小14時間、最大33.65時間です。 Min Median Max Palo Alto 14 24.2 33.7 Netscout 31.9 72.7 260 Censys 0 24 60 上記は、3つのインフォセキュリティ企業からのプローブ間の間隔（時間単位）の例です。Palo Alto NetworksとCensysのプローブでさえ、プローブ間間隔の範囲を考えると、中央値24時間はほとんど意味がありません。 謎めいたプローブ：不規則または非常にまれ Count Name Type OACK pairs 5 RRQ 1 startup-config octet RRQ 1 masscan-test netascii RRQ 2 test.xxx octet RRQ 2 test octet RRQ 7 file_id.diz octet Nonconforming 11 hex: 000010000000000000000000 12バイトバイナリ RRQ 1 ..\..\..\..\boot.ini octet RRQ 2 test octet RRQ 6 pxelinux.0 octet RRQ 9 config octet, blksize:1428, tsize:0 options RRQ 6 a octet, Alpha Strike Labs RRQ 1 r7tftp.txt octet Nonconforming 1 hex: 68656c700d0a0d0a 8バイトバイナリ、「help」と2つのCRLF終端行 Nonconforming 3 hex: 00000417271019800000000012101111 16バイトバイナリ もう一つ、説明が容易でないもの： y000000000028.cfg, 000000000000.cfg, y000000000000.boot, ata192.cfg, spa504g.cfg, spa112.cfg のRRQの5つのバーストが、様々な組み合わせで、すべてtype octet、すべて199.115.115.137から。 これらのスキャンの目的は何でしょうか？ 第一に、UDPポート69でリッスンしているIPアドレスの識別が主な目的であるようです。Netscout、Internet Census、CensysはTFTPサーバーを探しているようです。ファイル名「/a」または8つのランダムに選択された文字でRRQを実行しても、TFTPサーバーが指定されたIPアドレスのポート69でリッスンしていることを識別すること以上にはつながりません。masscan-testという名前のファイルのRRQは、TCP専用のインターネット全体スキャナーであるRobert Grahamのmasscanの背後に隠されたサーバー存在プローブのようです。RRQの1つは、nmap TFTPサーバーIDモジュールによって要求されるファイルr7tftp.txtを要求しています。私はそのRRQがnmapによって生成されたとは信じていませんが、これらのスキャンの目的の1つは、どのTFTPサーバーがどのホストで実行されているかを識別することです。 Palo Alto Networksの「/a」とtype「netascii」のリクエストのペア、それに続いてtype「octet」のファイルのリクエストは、どのサーバーソフトウェアがリクエストに応答したかを識別しようとする試みのように見えます。「/a」も「file」も存在する可能性は低いため、サーバーはおそらくERRORパケットで応答するでしょう。Palo Alto Networksは、異なるサーバーソフトウェアを区別しているはずです。Shadow ServersのエラーパケットのバーストとOACKパケットのペアは、異なる手段で同じ目的を果たしていると私は仮説を立てています。 いくつかのパケットは、設定が不十分なサーバーをプローブしています。..\..\..\..\boot.iniという名前のファイルの単一のリクエストは、明らかにWindows TFTPサーバーがディレクトリトラバーサルを許可するかどうかを確認しようとしています。pxelinux.0と199.115.115.137からのすべてのファイルのリクエストは、このカテゴリに分類されます。 ShodanがTFTPに準拠していないパケットのバーストを送信することから何を得ているのか、私には全くわかりません。 TFTPサーバーのCVEはいくつかしかありません。私は、プローブのいずれかがTFTPサーバーの脆弱性を悪用しようとする試みであるとは考えていません。 この実験の皮肉の1つは、TFTPトラフィックのほとんどが「悪い連中」がニッチなソフトウェアを悪用しようとするのではなく、インフォセキュリティ企業から来ているということです。