WordPressのauthorスキャン

某IPアドレスから?author=な連続スキャンを受けたので、ファイアウォールでブロックしてしてやった。 手動でブロックするのもアホらしいのでsuricataにルールを作ってあげてみた。

WiresharkとTCPのエラー

通常時のTCP通信の例 通常時の通信の一例です。 Node AからNode Bに対してデータを送信しています。 SEQは通信開始を基準として、送信しているデータが何バイト目に相当するのか、を表します。 ACKは受信済みのデータが、同様に通信開始を基準として何バイト目までであるか、を表します。 TCP Previous Segment Lost SEQとデータの長さから、次に受信するはずのパケットのSEQは推測できます。 推測したSEQと受信したSEQが異なれば、パケットが失われたか、もしくは順番が入れ替わった可能性があります。 以下の例は#2のパケットが失われたケースです。Node Bは#2の部分のデータを受け取れなかったため、Node Aに対して#2の部分(SEQ=100から始まる部分)を受け取っていないことを、ACK=100のパケットを送ることで表現します。 Wiresharkで見ると、#3がTCP Previous Segment not capturedと表記されています。直前のセグメント(部分)が見えていない、という意味で、つまるところ届いていないということです。(※) また、再送についてはTCP Retransmissionと表記されます。 ※ 実際にはWiresharkの処理が遅いために見えなかった可能性もあるため、not capturedと表記されます。 TCP Dup ACK TCP Dup ACKは、同じACK番号でのACKを2回以上送った場合に表示されるものです。 いくつかのパターンで出ますが、一番多いのはFast Retransmissionと呼ばれる機構に絡んだものでしょう。 通常、ACKは受信したすべてのパケットに対して出るわけではありません。パケットロスがまったくなければ、毎回ACKのためだけに通信するのは効率が悪いでしょう。たとえば本ページ最初の通常時の例では、3回のデータ受信に対して、1回でまとめてACKを伝えています。 ここで、パケットが失われたまま次を受信すると、1回目のACKが出ます。ACK番号は失われたパケットの推定SEQ番号です。これだけでは普通のACKです。 続けてその次を受信すると、2回目のACKが出ます。失われたパケットの再送を受けたわけではないですから、このときもACK番号は失われたパケットの推定SEQ番号のままになります。 このようにして同じACK番号のパケットが送出され、このようなDup ACKを受信した送信側は、ACK番号を元に再送を行います。 なお、パケットが失われず、受信順番が入れ替わるというケースもあります。この場合にも TCP Dup ACKが出ますが、1回だけ入れ替わったのであれば続いて(Dupでない)ACKが出るため、送信側は再送を行う必要がありません。 RFC 2581では、TCP Dup ACKを3回連続(通常のACKを含めれば4回連続)で受信したときに再送を行うべきであると定めています。

Wiresharkとゲーム

オンラインゲームをプレイしているとどうもおかしい。 Wiresharkで見てみると、なにやら変に見える。どうするか。 というページです。 当時の日記/記事にどういうわけかアクセスが多かったので、役に立たないことを承知の上で多少書き直したものです。 ログインできない、ラグがひどい(位置がずれる)などなど、オンラインゲームをプレイしていると大体一度は遭遇します。こんなとき、Wiresharkでキャプチャするといろいろわかります。 もう少し技術的に細かい話はWiresharkとTCPのエラーに書きました。 TCP Retransmission / TCP Previous Segment Lost / TCP Dup ACK 黒い背景に”TCP Previous Segment Lost”だの”TCP Dup ACK”と出たケース。 これはLANカード(NIC)から外側、ゲームサーバまでのどこかがおかしいケースです。 (1)PC – (2)HUB – (3)ルータ – (4)ONU – (5)回線 – (6)ISPとか – (7)ゲームサーバ 経験的にまず疑わしいのは(3)ルータと (7)ゲームサーバです。 (3)ルータについては再起動してみたり、ファームウェアを更新してみたりします。可能ならほかのルータを使ってみます。 あとはMTUの設定がおかしいケースも考えられるので、とりあえずそこそこ小さく(1200くらい)にしてみるとか。 (7)ゲームサーバについては……サーバ(運営会社)をどれくらい信用するかによります。 (2)は無さそうに見えて結構ある。これもとりあえず電源を入れなおしてみればよいでしょう。 2005年当時に遭遇したケースは、マビノギにログインはできるがキャラクタ選択ができないというもの。(本ページ末尾参照) 問題が発生するタイミングでMTU値を変更するという強引なことをやって解決していますが、その後キレてないところを見ると、きっとルータがポンコツで自然に直ったのでしょう。 RSTが出る 赤い背景で”RST”が見えるケース。しかしこれは通常時でも出るものなので異常とは限らない。 特定のサーバorポートへの接続だけができない、つまりゲーム内なら、フレンドのリストが見えないとか、一部の機能だけが使えないという形で見えてきます。 実際にあったケースとしてはDefiance(正しくはGlyph Client)にログインできないというもので、IP BANされていました。 当然IP BANされるようなことはしていませんので、VPNなんかを駆使してサポートに連絡、結局、別のIPアドレスから接続してくれと言われ、ルータを再起動して解決しました。     […]