Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[stdin]

Well, as we all know, there's a bunch of script kiddies always connecting clones into our network's and doing shits, we could simply code something for give a random ascii numbers&letters on connect and the user must give it to server, but that would break ALL bots,auto identifiers and stuff, so i really think:

You guys should come back with your Open Proxy service, and make it better as in verify in more sites and stuff.

You guys should make an 'SecureServ', would help really much, as we know, there's a lot of IRC Addons like ClonesXs, and they all send the same version, so we could "Blacklist" some of "VERSION CTCPREPLY's".

And final .. you guys should make something like "FloodServ" as in, for exg., 20 users joins a channel in less then 5 secounds(IF NOT NETSPLIT, or if its hard to services "understand", if 20 users joins & parts*), Operserv should make the channel +miN, and kill/akill/warn[Admin option] them all.

Well its just my suggestion's, i'd like to see you guys agreeing' with it.
Post your reply's, everyone's welcome

[katsklaw]

Originally posted by stdin
Well, as we all know, there's a bunch of script kiddies always connecting clones into our network's and doing shits, we could simply code something for give a random ascii numbers&letters on connect and the user must give it to server, but that would break ALL bots,auto identifiers and stuff, so i really think:

Services doesn't know about a new user until after they are already connected. The negotiations are up to the ircd.

You guys should come back with your Open Proxy service, and make it better as in verify in more sites and stuff.

BOPM is far better than our proxy scanner ever was or will be. It's far easier for you to run another process.

You guys should make an 'SecureServ', would help really much, as we know, there's a lot of IRC Addons like ClonesXs, and they all send the same version, so we could "Blacklist" some of "VERSION CTCPREPLY's".

http://www.neostats.net/

It's not a good idea to make 1 program do everything. This is for several reasons:

1> it makes that 1 program lag when it's overly busy and laggy services aren't any good to anyone.
2> by consolidating all your needs into 1 program, you are left completely defenseless if it should fail so it's far better to have 3-4 programs doing the work than 1 even if for no other reason than redundancy. I deally the 3-4 programs should also be run from different computers and not on just 1 for the same reason.

And final .. you guys should make something like "FloodServ" as in, for exg., 20 users joins a channel in less then 5 secounds(IF NOT NETSPLIT, or if its hard to services "understand", if 20 users joins & parts*), Operserv should make the channel +miN, and kill/akill/warn[Admin option] them all.

Services doesn't see enough channel traffic to accurately know if there is a flood and even if id could, it's always best to remove a problem at the source, in this case the IRCd. The IRCd sees everything .. Services does not. Additionally services is the "last to know" about anything. Services can not prevent anything it can only respond and even when it does respond it's ultimately up to the IRCd to take action, so why not cut out the middle man and make the the ircd do it since the ircd is the one with all the power.

[stdin]

Thanks for your reply, but i think it isn't right.

Services doesn't know about a new user until after they are already connected. The negotiations are up to the ircd.

I know that, i was just giving an exg.

BOPM is far better than our proxy scanner ever was or will be. It's far easier for you to run another process.

The problem isn't if he's better or not, its just lag and amount, they all can check if an address is in X DNSBL, but if 20 try 2 DNSBL each, i'm sure there will be much more efficace or w/e it's spell'd, im not english.

http://www.neostats.net/

It's not a good idea to make 1 program do everything. This is for several reasons:

1> it makes that 1 program lag when it's overly busy and laggy services aren't any good to anyone.
2> by consolidating all your needs into 1 program, you are left completely defenseless if it should fail so it's far better to have 3-4 programs doing the work than 1 even if for no other reason than redundancy. I deally the 3-4 programs should also be run from different computers and not on just 1 for the same reason.

I'm using PTLink IRCd, and ANOPE services, so why is the solution use other services? (BESIDES PTLINK != NEOSTATS SUPPORTED) you guys are good enough to make it, and as i have seen, there's many guys asking what I am, why you guys dont make it? who doesn't want it, dont use, who want(70%) will use, also i do have a normal network(300 users avg), its like "friends only", but i do get attacks from turks and stuff, and believe me, it wont lag!

Services doesn't see enough channel traffic to accurately know if there is a flood and even if id could, it's always best to remove a problem at the source, in this case the IRCd. The IRCd sees everything .. Services does not. Additionally services is the "last to know" about anything. Services can not prevent anything it can only respond and even when it does respond it's ultimately up to the IRCd to take action, so why not cut out the middle man and make the the ircd do it since the ircd is the one with all the power.

If you guys can program something like.. when X join HelpChannel, if (access_nick(...)) ... if you guys can program on-join-notice and it wont lag, you guys could prefectly program join/part's flood, and theyr actions(+miN), I'd make it for PTlink if i knew how to =)

[Edited on 24-3-2008 by stdin]

[Jan Milants]

I have to disagree... while i won't deny that some of these things may be useful in anope to some people, it s my opinion none of them should be added to the core...

The anope proxy scanner was stripped in the first place because of its extremely poor performance. You mention DNSBL lookups, well the old anope proxy scanner didn't even do that, it merely did a basic port scan.
And a few other people have asked about the proxy scanner, but most are happy with using BOPM. katsklaw is right about this as well: it s much better to distribute the effort. even for BOPM it is recommended to use one scanner/server to avoid overloading the scanner... if anope were to do it, it would have to handle scans for an entire network, maybe a dozen servers.
Keep in mind that anope is single threaded, so when doing one thing it can't do another. (becomes especially obvious when you enable MySQL dumping).
I m not against the proxy scanner being reintroduced, but imo it should not be part of the core. Anope provides IRC services, not proxy scanning services. There should be enough multuthreading code left i think to allow for a third party proxy scanning module.

And imo also the antiflood measures don't belong in the core. why? simply because most commong ircd's (unreal, inspircd) these days have ways of dealing with it even before services see it. therefore the vast majority of people using anope have no use  for yet another core feature that would only slow anope down.
And while you keep saying it won't lag, anope is single threaded and therefore the longer it takes to something, the more other commans will be lagged. Just look at mysql.. when dumping the db to sql anope responds to nothing for several seconds, depending on DB size..
And unlike the complicated proxy scanner, this can be easily implemented by a third party module.

btw irc defender does support ptlink and has anti flood capabilities..

[Edited on 24-3-2008 by Viper]

[stdin]

Thank you very much for your reply.

The anope proxy scanner was stripped in the first place because of its extremely poor performance. You mention DNSBL lookups, well the old anope proxy scanner didn't even do that, it merely did a basic port scan.

ROTFL, thank you for the laugh, fo real! , and with your words, you made me change my mind, and now i'm in the same boat as you, it in anope would be useless, unless it was a 'simple' Module.

And imo also the antiflood measures don't belong in the core. why? simply because most commong ircd's (unreal, inspircd) these days have ways of dealing with it even before services see it. therefore the vast majority of people using anope have no use  for yet another core feature that would only slow anope down.
And while you keep saying it won't lag, anope is single threaded and therefore the longer it takes to something, the more other commans will be lagged. Just look at mysql.. when dumping the db to sql anope responds to nothing for several seconds, depending on DB size..

Yes, i know, but its not everyone, and i love PTlink, always used it, i know everything on it etc etc.. as many other ppl may do.. and I'm sure that won't be hard for you guys something like.. mass join/part, Operserv joins channel(Optional, show off coding) -> mode +miN, and after sometime it removes and everything comes normal, plus, block all registrations and commands from non registered users. as again, coded as a 'Simple' Module.

btw irc defender does support ptlink and has anti flood capabilities..

jeez... irc defender forum and site got hacked years ago for what i'v seen while i was searching for that before posting this here, and its EXTREMLY BAD, it have got the power as Anope ex Proxy detector in PTlink ircd, believe me also they dont update it years ago too lol ..

[Jan Milants]

there once was an antiflood module, but it dealt with floods against services (registrations, memo's etc)

for mass connecting network wide (ircd's gererally don't have anything against this) there already is an anope module that will kick services into defcon: http://modules.anope.org/viewmod.php?id=38
it doesn't deal with channel based floods though

irc defender has the ability to deal with channel floods and also has an anti-random module which can pick out bots as they connect. as far as hacking goes, i ve used it for years and am quite happy about it, even though it s not being actively developed anymore it still does its job pretty well.

[stdin]

Hey viper, i'v been trying again and configure better the IRC defender, and yes its really usefull, but i'm missing configs.. and it doesn't kill/ban no one! LOL

(16:23:42) (@Security) Rehashing...
(16:23:42) (@Security) Loading configuration file...
(16:23:42) (@Security) Re-initializing: Modules/Scan/fyle.pm...
(16:23:42) (@Security) Fyle: Wordlist open failed! at Modules/Scan/fyle.pm line 410.
(16:23:42) (@Security) Re-initializing: Modules/Scan/cgiirc.pm...
(16:23:42) (@Security) Missing cgiirc.conf file! at Modules/Scan/cgiirc.pm line 99.
(16:23:42) (@Security) Re-initializing: Modules/Scan/regexp_akill.pm...
(16:23:42) (@Security) Missing regexp_akill.conf file! at Modules/Scan/regexp_akill.pm line 220.


Can you tell me where can i get em or if you have, can you upload it please?

[Edited on 24-3-2008 by stdin]

[Jan Milants]

i dunno about cgiirc.conf as i ve never used that defender module...
as for regexp_akill.conf, just create an empty text file with that name. if you then add an akill to defender, it will be stored in that file.
dunno about the wordlist either

.. leaving on holidays in less then an hour and have more important things to do then look this up :p

[katsklaw]

I have always maintained that it's best to prevent things at the source. This does not only apply to IRC, but life it's self. There are several examples.

1> If you want to eat, you go to the kitchen .. not the toilet.
2> If you want to buy a car you go to a car dealership .. not a bakery.

The list goes on and on. Now for my point. If you want to prevent channel floods you go to your ircd. this is because ONLY your ircd can prevent anything, services can not prevent channel floods, services can not prevent join/part floods, services can not prevent proxy abusing users from connecting. Services can only REACT to these things .. not PREVENT them. Again ONLY the ircd can PREVENT them.

Additionally, for Anope to even react to a channel flood, a services bot MUST be in the channel! Anope does NOT see channel traffic unless a bot in IN the channel. That would mean that the usage of BotServ and/or Chanserv in every single channel would be mandatory. Not everyone likes that and it's very impractical. So why is it logical to expect Services, who is the least efficient as the task to be written to perform the task? It's far more logical to use/write an ircd that takes care of this AT THE SOURCE, being the users connection status.

If your IRCd does not do what you want it to do, then it's time to ask the ircd developers to add it, add it your self or pick a different ircd. There ARE ircds out there that already do most if not all of what you are asking. For example, Unreal can and does already prevent channel floods. Including text floods, join/part floods and more. See http://www.vulnscan.org/UnrealIRCd/unreal32docs.html#feature_antiflood

[Edited on 26-3-2008 by katsklaw]