+g mode

[sprite]

There is a $decode spam line going around

This infecting line writes a script with an 'invisible' file name 
($chr(160) or alt-160 for us alt-keyboard people)
The line spams to 'get ops' in $currentchan, forces the user to join 
#manila or #sexEb on a timer, and puts people on /ignore if they see 
public chat.

It also sets the user to +R mode (restricted mode) meaning that the user 
has to have a registered nickname with services before you can message the 
user.

Once you see the spam, it means you have already been added to the
infected user's ignore list.

So, on Efnet or Undernet, I simply change to another nickname and give him 
the line to remove the spam, and un-ignore people, turn off timers, etc.
BUT, on DALnet, I can't change nicks from my registered one, because 
they will auto-ignore any that are not registered.

I once spent over half an hour trying to get information to the user to 
help him (including inviting him to a channel, then kicking him out with 
the help info)
It was more a research project to see how one actually -could- help 
someone in that situation.
The answer was, not well!

Just remember, for every thing we do to try to protect the users, and 
ourselves, the bad guys will twist what we have done to make it harder for 
us in other ways.

On Undernet they hide usernames, so how can the user report abuse to their 
provider? Opers are not allowed to give that info to the user. Either the 
oper has to accept the logs and report on his behalf, or the bad guys get 
away with it.

Some networks have pared the /whowas buffer to such a useless state, that 
an oper getting a report of a spambot may not get any info at all on a 
/whowas, or may get info on a new user who is totally innocent.

Remember how Time stamp and no_joins_on_split, and such other restrictive
features were going to make netsplits useless, and therefore not done?
yep!


On Thu, 17 Feb 2005, Lee H wrote:

> On Wed, Feb 16, 2005 at 06:59:39PM -0800, Sameer R. Manek wrote:
> > One thing that I would like to see added to the +g feature. If someone is in
> > +g they should not be able to send a message to someone that is not in their
> > accept list.
> > 
> > +g_person /msg friend something
> > friend /msg +g_person reply
> > 
> > Friend's message gets blocked by the +g, either sending a /msg to someone
> > should automatically add them to the accept list, or it shouldn't be
> > allowed.
> 
> Unrealistic, for multiple reasons.  Firstly, there is nothing stopping the
> client doing this itself.  You can easily hook into creation of a query
> window, or an outbound message, check against your internal lists and issue
> an ACCEPT if you dont see the nick there.  Whats the point in wasting cpu
> cycles on the server doing it when the client can easily do it itself?
> 
> Secondly, if I want to message a bot for ops why must I accept the bots nick
> first, or have it automatically done for me?  I dont need the bot on my
> accept list -- all im doing is asking it for ops, theres nothing it needs to
> do other than op me.
> 
> 

-- 
------------------------------------------------------------------------
    sprite at ntsource.com        A secure computer is a Patriot's Duty© 
------------------------------------------------------------------------