New type of ICMP packets

Are you sure you don't mean UDP packets to ports 1026 and 1027. This is very common, and is most likely just Windows Messenger spam.

Reply to
Kerodo
Loading thread data ...

Hi,

I am seeing a new type, to me, of ICMP packets arriving here. At first it was one site sending but now a few sites are sending these packets.

The packets, as reported by my firewall, have the form:-

Source:63.188.36.251, 1026, WAN - Destination: a.b.c.d, 6284, WAN - Type: 1026 -

This sample comes from Sprint IP range but I am seeing them from other ranges as well.

From the earlier discussion on Destination unreachable packets these are Type

1026 Code 6284. The type numbers seen are 1026 and 1027 but there is a wide variation in the code numbers and the forewall may be reporting the port number attacked.

I couldn't see anything in either RFC 792 or 950 to explain them.

The firewall is dropping them so I am safe from whatever is being tried on. However, I am interested in what they are and what is being attempted.

Can anyone let me know what they are?

Reply to
JC

If your firewall is identifying those as ICMP, it is totally batshit, and should be reinstalled while you are disconnected from the world.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Kindly think how you get "1026" out of an eight bit binary field.

They can't be. Show a single raw packet dump - use Ethereal, tcpdump, sniffit, or any packet sniffer you have. Look at the IP header (here from RFC0791 paragraph 3.1):

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and look up the protocol number at

formatting link
ICMP is "1" decimal, and I strongly suspect you are seeing "17" decimal (0x11) which as noted by Kerodo is UDP.

Old guy

Reply to
Moe Trin

common, and is most likely just Windows Messenger spam.

Nope, these are definitely ICMP packets being reported by my firewall.

There aren't many at this stage but the number is rising. Of 2332 entries in my firewall log at 9AM this morning I have 787 ICMP packets of which the type under discussion amounts to only 42 - i.e. about 2% of all packets dropped.

I just noticed that type 1025 packets are also present.

Reply to
JC

Hi Moe.

That was my suspicion and why I asked about them.

It's a Sonicwall hardware firewall and I have written to them asking them about the identification of these packets as ICMP and await their response. I will probably have to decide if it is worth a few hundred dollars to avoid this or take the cheaper option and just accept the mis-identification. :-)

I agree.

I'll grab RFC791 and do some more reading.

I would love to be able to get samples of some of these packets but they are being dropped by a Sonicwall hardware firewall. Short of opening up a window to let them in, which is not a nice thought, I don't see how I can grab a sample packet.

Reply to
JC

If the firewall is mis-identifying the packets, I'd have extremely serious questions of what _else_ might be wrong.

0791 Internet Protocol. J. Postel. Sep-01-1981. (Format: TXT=97779 bytes) (Obsoletes RFC0760) (Updated by RFC1349) (Also STD0005) (Status: STANDARD)

about twice the size of 0792 (ICMP), and may not be all that informative.

That's the good news. The concern is why this mis-identification is occurring. Knowing something of the protocols, and programming, it _might_ be something as stupid as a mis-sized bit mask (the difference between seeing 0x11, which is 17 decimal and UDP, and 0x01 which is 1 decimal and ICMP), but... There are 138 of the 256 protocols defined, but just 4 are likely to be seen on the average network (1 = ICMP, 2 = IGMP, 6 = TCP, and 17 = UDP).

Depends on your setup - you could put in a rule to forward these packets to an unused address on your LAN, and put a computer there with a so-called personal firewall that drops everything, but logs the details.

Old guy

Reply to
Moe Trin

In article , JC wrote: :On Wed, 26 Oct 2005 14:52:23 -0500, snipped-for-privacy@painkiller.example.tld (Moe Trin) :wrote: : :>In the Usenet newsgroup comp.security.firewalls, in article :>, JC wrote: :>

:>>>On Tue, 25 Oct 2005 18:06:42 -0700, JC wrote: :>

:>>>> The packets, as reported by my firewall, have the form:- :>>>>

:>>>> Source:63.188.36.251, 1026, WAN - :>>>> Destination: a.b.c.d, 6284, WAN - :>>>> Type: 1026 - :>

:>If your firewall is identifying those as ICMP, it is totally batshit, :>and should be reinstalled while you are disconnected from the world. : :Hi Moe. : :That was my suspicion and why I asked about them. : :It's a Sonicwall hardware firewall and I have written to them asking them about :the identification of these packets as ICMP and await their response. I will :probably have to decide if it is worth a few hundred dollars to avoid this or :take the cheaper option and just accept the mis-identification. :-)

My best guess is that someone is spoofing your IP as the source in Microsoft Messenger spam to UDP ports 1026 and 1027. You are seeing ICMP type 3 (Destination Unreachable) packets from targets with firewalls set up to reject those UDP packets. Your own firewall sees those ICMP packets, looks inside them to find the original UDP packet they contain, can't match that up with anything you've actually sent, and generates a hopelessly confused report identifying the original UDP destination port number as an ICMP type.

Reply to
Robert Nichols

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.