Re: ICMP Type:8 Code:137
Valdis.Kletnieks_at_vt.edu
Date: 10/29/05
- Previous message: Christine Kronberg: "Re: SSH bruteforce on its way..."
- In reply to: Allan Kjeldbjerg (Acom Internet ApS): "Re: ICMP Type:8 Code:137"
- Next in thread: mutiger_jh_at_yahoo.com: "Re: Re: ICMP Type:8 Code:137"
- Maybe reply: mutiger_jh_at_yahoo.com: "Re: Re: ICMP Type:8 Code:137"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: "Allan Kjeldbjerg (Acom Internet ApS)" <allan@acom-net.dk> Date: Fri, 28 Oct 2005 19:56:58 -0400
On Fri, 28 Oct 2005 21:18:27 +0200, "Allan Kjeldbjerg (Acom Internet ApS)" said:
> Hi _mutiger_jh,
>
> Yes I have notice the increase of the same packets. They could be spoofed
> but the one I currently
> notice originate from China and is distributed via ISP's in New York.
>
> Concurrently with these packets we expirence non terminating TCP connections
> on our Windows platform.
> - Could there be a connection between the two? Anyone noticed the same
> pattern?
Out of curiosity, are these fragged packets? I'm wondering if the first frag
is getting lost and something's misinterpreting a 2nd or following frag - remember
that the *real* TCP/UPD/ICMP header is only in the first frag. So if your
monitoring tool looks at a subsequent frag, it could be minsinterpreting the
payload as header (similar to the tool that misinterpreted an ICMP as UDP and got
a port number instead of a ICMP type/code).
- application/pgp-signature attachment: stored
- Previous message: Christine Kronberg: "Re: SSH bruteforce on its way..."
- In reply to: Allan Kjeldbjerg (Acom Internet ApS): "Re: ICMP Type:8 Code:137"
- Next in thread: mutiger_jh_at_yahoo.com: "Re: Re: ICMP Type:8 Code:137"
- Maybe reply: mutiger_jh_at_yahoo.com: "Re: Re: ICMP Type:8 Code:137"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]