My win 2002 SP2 server is periodically sending a ICMP on UDP port 1026 to
various IPS. Looking at TCP
view, the only process open on all IPS (about 9 of them) is LSASS.EXE,
specifically isakmp. I have not actually witnessed the UDP, so this may be
a wrong assumption.

Packet flag is 0x0, so this may be nothing more than a ping, not sure.

Virus and anti-spyware scans are negative. Any thoughts?

"ed" <xyz@yahoo.com> wrote in message
news:q23ef.96767$Hs.9720@tornado.ohiordc.rr.com...
Check the netstat -an output.
donnie

ed wrote:

Are you logging in at these locations?> Someone logging onto you?

Is there a pattern as to what type host those IPs belong to?

Winged

In the Usenet newsgroup alt.computer.security, in article
<q23ef.96767$Hs.9720@tornado.ohiordc.rr.com>, ed wrote:

That sentence makes no sense. ICMP is one IP protocol, UDP another.
Search for RFC0768 (UDP), RFC0791 (IP) and RFC0792 (ICMP) if interested.

UDP 1026 (and 1027) are primary targets of messenger spam - pop-up ads
targeting clueless windoze users. Late last month, I turned on logging
on the perimeter firewall at home (I normally ignore dropped packets)
for a week, and noted about 1000 messages a day, or about 450K of wasted
bandwidth per day. The few packets I investigated were all fake windoze
error messages, directing users to some spammers website for a "repair".
I'm in North America, so most of the packets were originating in China,
although the spamvertised web sites were all hosted at well known spammer
support domains in the US states of Washington Texas, or Florida.

Old guy

Actually ICMP is a layered protocol the UDP protocol in question is a
transmission protocol.

I am aware of the misuse of port 1026 and 1027, but since the routers do not
allow pinging from outside of the network, I am curious why a 0x0 reply is
sent (typical response to a ping).

There is no pattern to the machines it is responding/sending to.
Additionally, these machine IP's do not show up in my firewall as probing.



The 0x0 is normally a reply to a ping, but pinging is disallowed from
outside the local network.
"Moe Trin" <ibuprofin@painkiller.example.tld> wrote in message
news:slrndnkfei.k4d.ibuprofin@compton.phx.az.us...

Shows the same ports as previous.
"Donnie" <queyosepa@quetejodas.net> wrote in message
news:zpaef.55892$qk4.16896@bgtnsc05-news.ops.worldnet.att.net...

Reply in line.

ed wrote:
I have to agree with Moe, I think we are having a failure to
communicate. ICMPs are in the network layer of the OSI model. UDP and
TCP would be in the transport layer. But, in the payload of an ICMP
they can give information about the upper layer protocols they are
replying to.

Are you saying that your machine in question is sending an echo reply
with a payload indicating it was in response to a UDP packet? If so, do
you have a packet capture of the payload? It would make sense to send a
host unreachable/network unreachable etc, but not an echo reply. If
that is the case, it almost sounds like some malware is trying to
communicate using a covert channel.

Since they don't show up as probing, I'm guessing that machine is not
responding, just sending. Again, some malware trying to phone home?

Agreed, that is normally an echo reply, but why do you say it has
something to do with a UDP packet?

Mark

Here is what my firewall log is giving me (my address is xx.xxx.xx.151):

Issue Name:UDP_Probe_Other
Source IP:xx.xxx.xx.151
Victim IP:xx.xxx.xx.85
Parameters: port=1026&reason=ICMPsent

Not sure now about the UDP, here is the .enc file decode for one of the
packets:

Frame 6458 (70 bytes on wire, 70 bytes captured)

Arrival Time: Nov 28, 2005 08:47:36.022680000

Time delta from previous packet: 0.190274000 seconds

Time relative to first packet: 475.063108000 seconds

Frame Number: 6458

Packet Length: 70 bytes

Capture Length: 70 bytes

Ethernet II, Src: 00:02:b0:bc:69:47, Dst: 00:11:11:26:08:40

Destination: 00:11:11:26:08:40 (00:11:11:26:08:40)

Source: 00:02:b0:bc:69:47 (Hokubu_bc:69:47)

Type: IP (0x0800)

Internet Protocol, Src Addr: xx.xxx.xx.85 (xx.xxx.xx.85), Dst Addr:
xx.xxx.xx.151 (xx.xxx.xx.151)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

..... ..0. = ECN-Capable Transport (ECT): 0

..... ...0 = ECN-CE: 0

Total Length: 56

Identification: 0xa638

Flags: 0x00

..0.. = Don't fragment: Not set

...0. = More fragments: Not set

Fragment offset: 0

Time to live: 140

Protocol: ICMP (0x01)

Header checksum: 0x9522 (correct)

Source: xx.xxx.xx.85 (xx.xxx.xx.85)

Destination: xx.xxx.xx.151 (xx.xxx.xx.151)

Internet Control Message Protocol

Type: 3 (Destination unreachable)

Code: 3 (Port unreachable)

Checksum: 0x8dbf (correct)

Internet Protocol, Src Addr: xx.xxx.xx.151 (xx.xxx.xx.151), Dst Addr:
xx.xxx.xx.85 (xx.xxx.xx.85)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

..... ..0. = ECN-Capable Transport (ECT): 0

..... ...0 = ECN-CE: 0

Total Length: 773

Identification: 0xa638

Flags: 0x00

..0.. = Don't fragment: Not set

...0. = More fragments: Not set

Fragment offset: 0

Time to live: 116

Protocol: UDP (0x11)

Header checksum: 0xaa45 (correct)

Source: xx.xxx.xx.151 (xx.xxx.xx.151)

Destination: xx.xxx.xx.85 (xx.xxx.xx.85)

User Datagram Protocol, Src Port: 26698 (26698), Dst Port: 1026 (1026)

Source port: 26698 (26698)

Destination port: 1026 (1026)

Length: 753

Checksum: 0x0000 (none)








probing.

On Mon, 28 Nov 2005, in the Usenet newsgroup alt.computer.security, in article
<36Gif.144735$tD4.55068@tornado.ohiordc.rr.com>, ed wrote:

So what that may be trying to say is that you received a UDP packet from
xx.xxx.xx.85 to your port 1026 (undoubtedly, windoze messenger spam), and
your system rejected it with an ICMP "FOAD" packet. But the stuff below
says otherwise.

Boy, they love to baffle 'em with bullshit, don't they. Well, lets cut
through all the useless crap...

Strange value - these normally start with a nice round figure, like 32, 64,
128, and occasionally 255, and gets decremented by every router between
source and destination. In most cases, nothing is more than 30 or 40 hops,
yet if this started with 255, it's 115 hops away - highly unlikely.

OK - xx.xxx.xx.85 is sending an error message to xx.xxx.xx.151 that
says "the number you have dialed is unreachable" The contents of the
packet that caused this is:

(That's more reasonable - 12 hops away)

xx.xxx.xx.151 appears to be trying to send messenger spam to xx.xxx.xx.85

Now above, you said "my address is xx.xxx.xx.151" - and if that's the
case, your box got 0wn3d and was sending spam. I'd be looking at WTF is
going on with this box. Yes, that looks like you are the one with the
problem, not the remote.

Old guy

On Mon, 28 Nov 2005, in the Usenet newsgroup alt.computer.security, in article
<slrndompl7.i77.ibuprofin@compton.phx.az.us>, Moe Trin wrote:

I should have mentioned, an ICMP Type 3 is supposed to carry the IP
header and first eight bytes of the packet that caused the error. Here,
it is:

If you can ping or traceroute to xx.xxx.xx.85, it might be nice comparing
the number of hops you get to this figure of 12 hops

Now it dawns on me a bit later, you may be the "victim" of back-scatter.
UDP is connectionless. The spammer sends the packet to the target, and if
his port 102x is open (running windoze with messenger enabled) he gets
the spam in a pop-up window. IF THE PORT IS NOT OPEN, it will send the
ICMP error we saw above. Thing is - there is no handshaking to establish
the connection, so the spammer can AND OFTEN DOES fake the "source"
address. I ran a test earlier this month, logging all UDP that was not
DNS received by my firewall and was seeing an average of 1000 a day. I
normally block such traffic, but doing stats on where the packets claimed
to be sourced, I noticed about 3 percent were demonstrably false, with
addresses that IANA hasn't even released to the Regional Internet Registries
never mind let out to ISPs.

I should not have said this, as this could be the result of a spammer
choosing your address at random to use as the source IP for his trash.
That way, if someone complains, it's not the spammer who gets blamed.

Sorry.

Old guy

Thanks,

That is what I am guessing, have located some form of QoS running as
aspnet.exe.



"Moe Trin" <ibuprofin@painkiller.example.tld> wrote in message
news:slrndompl7.i77.ibuprofin@compton.phx.az.us...

Moe Trin wrote:
Agreed, it looks like backscatter to me.
Nothing to worry about, and frankly, nothing you can do about it.

Unless you actually see your machine making connetion attempts to UDP
102X in the output of a netstat, I wouldn't worry about it.

Moe's suggestion of tracerouting to the .85 address is a good one.
Might give some more clues if you're still interested.

--
Mark