Spam propagation

Hi,

I am currently receiving around 180 UDP spam packets per day coming from
24.64.x.x sending to ports 1026 - 1028. This has been going on for
over 1 month now. When I contacted Shaw Communications, Canada about
them their response was that the packets were most likely spoofed and
then ignored them.

This got me thinking about how spoofed packets are propagated.

I would expect that packets with a sending address in the 24.64.x.x
range could only enter the network via one of the Shaw servers. An
attempt to insert the packet elsewhere should result in the sending
address not meeting the IP address range for that ISP and being
rejected.

If the sending address was from within the ISPs IP address range then if
the ISPs then checked the sending address on the packet against a list
of registered users and rejected all packets that weren't in the list
then the amount of spam would be reduced markedly.

If the sending address matched an address in the list then if the ISP
also checked that the session password matched the one on the list for
that ISP there would be a further reduction.

As the packets move along the path to the recipient there should be
checks that the packet is being delivered by the appropriate upstream
ISP, or ISPs, with the correct password otherwise the packet should be
rejected and a bounce message sent to the sender.

Does this make sense?

I don't expect that this is how things work as it would require the ISPs
to carry out a considerable amount of processing when handling the
packets and I doubt that they would want to do that.
--

Cheers . . . JC

Re: Spam propagation

JC wrote:
> I am currently receiving around 180 UDP spam packets per day coming
> from 24.64.x.x sending to ports 1026 - 1028.

What exactly are "UDP spam packets" supposed to be? And why are you
concerend about 180 packets per freakin' DAY in the first place?

[...]
> I would expect that packets with a sending address in the 24.64.x.x
> range could only enter the network via one of the Shaw servers.

Why?

> An attempt to insert the packet elsewhere should result in the sending
> address not meeting the IP address range for that ISP and being
> rejected.

Why?

Which RFC would require a router to check the source address of a packet
before passing it on?

> If the sending address was from within the ISPs IP address range then
> if the ISPs then checked the sending address on the packet against a
> list of registered users and rejected all packets that weren't in the
> list then the amount of spam would be reduced markedly.
>
> If the sending address matched an address in the list then if the ISP
> also checked that the session password matched the one on the list for
> that ISP there would be a further reduction.
>
> As the packets move along the path to the recipient there should be
> checks that the packet is being delivered by the appropriate upstream
> ISP, or ISPs, with the correct password otherwise the packet should be
> rejected and a bounce message sent to the sender.
>
> Does this make sense?

No.

Did you ever take a closer look at a (fishing) net? Did it look like a
tree to you? Well, the Internet has been named "Internet" instead of
"Intertree" for a reason.

> I don't expect that this is how things work

Well, that's a relief. Because they don't.

> as it would require the ISPs to carry out a considerable amount of
> processing when handling the packets and I doubt that they would want
> to do that.

"Considerable amount" as in "would kill any router existing".

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: Spam propagation

On Fri, 07 Dec 2007, in the Usenet newsgroup comp.security.firewalls, in
article , JC wrote:

>I am currently receiving around 180 UDP spam packets per day coming
>from 24.64.x.x sending to ports 1026 - 1028.

It's called messenger spam. It is a result of microsoft inventing
a service that UNIX had abandoned several years earlier due to abuse.

>This has been going on for over 1 month now. When I contacted Shaw
>Communications, Canada about them their response was that the packets
>were most likely spoofed and then ignored them.

Likely - look at the TTL field in the headers, as well as the source
port number.

>This got me thinking about how spoofed packets are propagated.
>
>I would expect that packets with a sending address in the 24.64.x.x
>range could only enter the network via one of the Shaw servers.

UDP does not require a response. It can be a "one-way" protocol.

>An attempt to insert the packet elsewhere should result in the
>sending address not meeting the IP address range for that ISP and
>being rejected.

You seem to think the the ISP where these packets originate actually
cares. You are wrong.

[snip remainder of uninformed guesses]

>Does this make sense?

No.

1. Fix your windoze box to ignore messenger service. Instructions to
do this have been available from microsoft for at least 5 years.

2. At your "firewall" (what-ever that may be) drop ALL incoming UDP
destined to ports 1025 - 1030. (The only legitimate service using
UDP is DNS [Internet name service] and NTP [Network Time Service]
and these should only be getting _replies_ to specific packets you
have sent out to well know IP addresses. DO NOT SET YOUR FIREWALL
TO REJECT - SET IT TO "IGNORE" OR "DROP" to avoid wasting further
bandwidth by sending rejects to the spoofed source address.

3. Scream at your own ISP, about the wasted bandwidth. A mere 180
packets a day per IP address (last time I bothered to look at home,
I was seeing well over 1000 such packets a day) is only about 40 kb
per address. Whether you ISP has enough addresses to where that
amount of waste is important is for them to decide.

For further thoughts, read RFC2827 (and the related RFC3704) which
you can find using your favorite search engine.

Old guy