R: R: R: [jdev] about spim techniques

[Sander Devrieze]

Op zaterdag 27 augustus 2005 18:43, schreef Bart van Bragt:
> Sander Devrieze wrote:
> >> A spimmer would probably do the same as most spammers these days. Not
> >> set up their own server but use compromised computers all over the
> >> internet. These could either act as as mini servers
> >
> > This will cost money/time and make it not profitable.
>
> Is that so? Then why are there lots and lots of worms/viruses/trojans
> out there that turn PCs into zombie machines? Why wouldn't they use that
> to fetch the JID+password of this user and use that to send loads of SPIM?

He was talking about mini-servers. So semi-servers that send spam directly via 
s2s. A worm/virus/trojan that gets the JID+password (Remark that there are 
many different client that store passwords on different ways, even some 
encrypt them! This makes it a lot harder (and so more expensive!) for the 
spimmer to find this information on many computer.).

Remark that the spimmer also has not an unlimited set of Jabber IDs. Due to 
limits of the number of messages the spimmer can send on the server, and the 
fact that it will be very easy (and profitable, as his server might be 
blocked if he don't solve this problem soon) for the server admin to disable 
that account and contact the real account member why his account was 
disabled.

> > It would result that if spimmers discover the open registration, many
> > servers might be blocked for some time. But afterwards we will have at
> > least a better set of public servers left, and maybe a new version of the
> > registration JEP that blocks spimmers.
>
> If you ask me in-band registration should be disabled on public servers
> and it should be replaced by some kind of bot proof web page. This way
> it's also easier to get a (valid) email address of the user in case they
> forget their password etc. In-band registration is spimmers heaven...

In-band registration is quite useful:
* in private networks,
* as long as it is not yet abused.

Plus that it now might be possible to abuse in-band registration, does not 
mean we need to throw the baby out with the badwater. No one said it is not 
allowed the JEP to:
* use Data Forms to ask additional information including an email address,
* use xml:lang to internationalize the Data Forms,
* add some random question that only humans can answer,
* add other technologies so that a Jabber server implementation can be secure 
out-of-the-box (the problem with the web registration, is that it is up to 
the admin to implement a web registration form with good or bad protection 
against bots...especially the lazy ones, as they will choose the web form 
software that is the easiest to setup).

> IMO blocking people that are not on your roster is a very important way
> to combat SPIM,

IMO I don't think that is a good approach. :-s

<snip>
> Having:
> - Dialback and related mechanisms (ability to hunt the SPIMmer)
> - Karma limits on the server (important to keep zombie PCs relatively
> quiet)

...and so more expensive.

> Adding whitelists to that sounds like a (very) bad
> idea, it will reduce the openness of the Jabber network quite a bit.

Whitelisted server == Any server with a *free* or commercial certificate 
issued by one of the authorities voted by e.g. the JSF Members (Allow 
server?-->yes/no vote). This certificate is *not* the same as the one used 
for TLS and SASL between servers. Instead it is an additional certificate 
especially for the whitlisting (or you can call it "opt-in"). A server also 
can have more signatures (see blacklisted server)! All certificates used for 
whitelisting/blacklisting can be retrieved by other servers over XMPP: they 
are stored on the server from which the certificates are.

Blacklisted server == Any server with a *free* or commercial certificate 
issued by one of the authorities that *was* approved by the JSF but not 
anymore because of *permanent* and *important* problems with spimming. Or a 
certificate that is signed by an authority that was never approved by the 
JSF. Remark that all certificates issued by this authority will become 
blacklisted as it might be possible that the authority was not suspicious 
enough with other servers too (and might gave certificates to other spimmers 
or servers that can not offer a good enough protection against spimming). To 
protect you against this, you can opt to have a few more certificates to make 
it redundant: if one certificate is not good anymore, the others still are 
ok, and the outgoing connections will still be possible (though it will be a 
good idea for this admin to replace that certificate with another one to stay 
redundant).

<snip>

-- 
Mvg, Sander Devrieze.
xmpp:sander at devrieze.dyndns.org

ejabberd, the expandable Jabber daemon. --
http://ejabberd.jabber.ru/