[IRCServices] known services "abuse"?

[&quot]

This problem has already been identified and has been fixed in version 4.5.

Andrew

> -----Original Message-----
> From: owner-ircservices at Snow.shadowfire.org
> [mailto:owner-ircservices at Snow.shadowfire.org]On Behalf Of Samuel
> Graenacher
> Sent: 08 October 2000 11:45
> To: Andrew Church
> Subject: Re[2]: [IRCServices] known services "abuse"?
>
>
> Well we narrowed down the problem to them having *!*@* on their akick
> list, doing an akick enforce and then chanserv trying to set modes in
> the empty channel.
> [Oct 07 14:40:02 2000] debug: AKICK ENFORCE requested for #rena
> by AM-[mentalbreakdown]
> [Oct 07 14:40:03 2000] channel: MODE +b *!*@* for nonexistent
> channel #rena
>
>
> _______________________________
> [Sam](<A  HREF="mailto:sam at breakfree.com">mailto:sam at breakfree.com</A>)
>
> * Linux is like living in a teepee. No Windows, no Gates, Apache
> in house. *
>
> public pgp key: finger sam at breakfree.com
>                 or <A  HREF="http://www.xploded.net/fingerp.phtml">http://www.xploded.net/fingerp.phtml</A>
>
> ---
> original message:
> AC>      Replying to two messages at once:
>
> >>Hey,
> >>lately I've noticed this error message coming up quite often:
> >>
> >>Global -- from services.mircx.com:
> >>Warning: unable to set modes on channel #rena. Are your
> servers' U:lines configured correctly?
> >>
> >>The channel is known to have script-kiddies in it and when I started
> >>investigating about that a bit I heard they found a way to "abuse" the
> >>servs, most likely Chanserv.
>
> AC>      I suspect what's happening is that someone is
> deliberately changing
> AC> channel modes against a modelock.  The U-line error detection
> code works
> AC> by checking the number of times a MODE message is received for a given
> AC> channel in a given period of time; if it exceeds a built-in limit (I
> AC> think it's three messages in one second), the code assumes that the
> AC> server is cancelling its mode changes and displays the U-line error
> AC> message.  The code does check that the mode sender has a
> period in their
> AC> nickname, though; does your server allow nicknames with
> periods in them?
> AC> If so, it's in violation of the RFC and should be fixed; if
> not, I'd be
> AC> interested in seeing a debug log of this problem happening.
>
> >>A problem I have had with relation to Operserv and Chanserv.
> >>Chanserv can op a user on a channel but OperServ can't op the
> same person.
> >>Operserv complains about ulines not being configured correctly.
> AC> [...]
> >>For whatever reason, it has now stopped giving this error. I can't help
> >>much as to why it started working all of a sudden, but the only
> thing that
> >>comes to mind is that the system was rebooted, though i doubt this is
> >>related. Restarting services or the ircd had no effect whatsoever.
>
> AC>      This can happen if at some time in the past Services
> determined that
> AC> mode setting didn't work (as above).  Actually, OP/DEOP shouldn't work
> AC> then either; that's a bug.  Restarting Services ought to fix it,
> AC> unless/until Services has a problem setting modes again.
>
> AC>   --Andrew Church
> AC>     achurch at dragonfire.net
> AC>     <A  HREF="http://achurch.dragonfire.net/">http://achurch.dragonfire.net/</A>
>
> AC> ---------------------------------------------------------------
> AC> To unsubscribe, send email to majordomo at ender.shadowfire.org
> AC> with "unsubscribe ircservices" in the body, without the quotes.
>
>
>
> ---------------------------------------------------------------
> To unsubscribe, send email to majordomo at ender.shadowfire.org
> with "unsubscribe ircservices" in the body, without the quotes.
>


---------------------------------------------------------------
To unsubscribe, send email to majordomo at ender.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.