View Issue Details

IDProjectCategoryView StatusLast Update
0003256unrealircdpublic2019-12-30 18:26
ReporterdjGrrrAssigned Tosyzop 
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Platform*OS*OS Version*
Product Version3.2.7 
Target VersionFixed in Version5.0.1 
Summary0003256: maxperip exception block
Descriptioncurrently, as far as i know, the only way to add an exception for certain hosts to bypass the maxperip setting in the allow block, is to create a totally new allow block just for a specific host.

I think this is a really bad way to do this, and there should be a much easier way via an except block.

my idea is to have something along the lines of...
except maxperip {
    mask *@localhost;
    limit 20;
};

this should be relatively easy to implement (i think)
TagsNo tags attached.
3rd party modules

Activities

syzop

2007-03-07 11:35

administrator   ~0013279

My opinion: the allow block is perfect for this. I don't see why to create yet another method to do the same. If you start doing that for this, you can keep going on and on.

Reminds me of the ircnet days, which had tens if not hundreds of I lines :)

Perhaps sts/aqua can comment on this as well.

djGrrr

2007-03-07 11:44

reporter   ~0013280

Last edited: 2007-03-07 12:12

well, the point of this is, it allows a simple maxperip bypass of multiple allow blocks at the same time.

on my network i have all the leafs configured with 2 allow blocks.
one is the standard allow block, and the other requires ssl and a password, and gives a different user class to have nofakelag.

it would be a big pain to try and have multiple allow blocks per special ip exception, just imagine if i had even more general allow blocks....

i honestly think this would be a good addition, as the allow block is definetly not suited for this, and its not another method to do the same...

edit: maybe i need to be a little clearer in my description :P

aquanight

2007-03-24 10:53

reporter   ~0013328

Reasons allow block is better for this:

- You can limit by hostmask and/or ipmask (though it's an either-or match if you use both). And yes, you can use CIDR.
- You can require a password for it to be effective (nopasscont, for example).
- You can require SSL (and possibly an ssl client cert).
- You can assign the user to a different class, with a different user limit, etc.

As syzop said, more than one way to do the same thing isn't really needed. Allow block is perfect for this. And it doesn't take that much more than making an except block.

djGrrr

2007-03-24 11:16

reporter   ~0013329

Last edited: 2007-03-24 11:23

aquanight, you obviously read nothing that i wrote, if you did you would see that the allow block is crap for this

just think of this...
i have 5 different general allow blocks (ones that allow *@*) all with different requirements, like ssl, password, etc....

now, i want to add 1 ip/host to be exempt from maxperip, that means, i need to add 5 more HUGE allow blocks... correct me if i'm wrong but.... I would have thought that writing 1 line is a lot easier than writing 25+.

Just because YOU would have no use for such a feature doesn't mean that 100s of other people wouldn't

stskeeps

2007-04-18 05:33

reporter   ~0013507

Could we stirr up a little more conversation on this? Perhaps some examples of use and such?

djGrrr

2007-04-18 07:32

reporter   ~0013517

ok, lets say you have 3 allow blocks, 1 is the general *@* allow block, matching any clients, second matches the same except ssl, third, matches *@* with ssl and a password that uses a class that gives fake lag excemption


allow {
  ip *@*;
  hostname *@*;
  class clients;
  maxperip 2;
};

allow {
  ip *@*;
  hostname *@*;
  class clients_ssl;
  maxperip 3;
  options { ssl; };
};

allow {
  ip *@*;
  hostname *@*;
  class clients_flood;
  maxperip 3;
  password "fl00d";
  options { ssl; };
};

now, i think, it would be a lot better if you could simply just add this..
except maxperip { mask *@172.16.*; limit 20; };
rather than having to add 3 more huge allow blocks

syzop

2007-12-30 11:32

administrator   ~0014945

I'm fine with adding this, but am not willing to code it. I'm taking it off the todo list, but if anyone comes with a decent patch it will be added :)

syzop

2019-12-30 18:26

administrator   ~0021180

With the new exception infrastructure and ELINE, the following was added in 5.0.1 which allows you to achieve the same:

commit fccb3b2f5bc8f845db4cee9d4e88512ccedb881b (HEAD -> unreal50, origin/unreal50)
Author: Bram Matthys <syzop@vulnscan.org>
Date: Mon Dec 30 18:19:09 2019 +0100

    Add /ELINE exception type 'm' to bypass allow::maxperip.
    
    In the configuration item you can now achieve the same via:
    except ban { mask 1.2.3.4; type maxperip; }
    Or even:
    except ban { mask { 1.2.3.4; 8.8.8.8; }; type maxperip; }
    etc.

Issue History

Date Modified Username Field Change
2007-03-07 11:21 djGrrr New Issue
2007-03-07 11:35 syzop Note Added: 0013279
2007-03-07 11:44 djGrrr Note Added: 0013280
2007-03-07 12:12 djGrrr Note Edited: 0013280
2007-03-24 10:53 aquanight Note Added: 0013328
2007-03-24 11:16 djGrrr Note Added: 0013329
2007-03-24 11:21 djGrrr Note Edited: 0013329
2007-03-24 11:23 djGrrr Note Edited: 0013329
2007-04-18 05:31 stskeeps Status new => acknowledged
2007-04-18 05:33 stskeeps Note Added: 0013507
2007-04-18 07:32 djGrrr Note Added: 0013517
2007-07-18 07:27 stskeeps Relationship added child of 0003454
2007-12-30 11:32 syzop Note Added: 0014945
2007-12-30 11:32 syzop Relationship deleted child of 0003454
2019-12-30 18:26 syzop Assigned To => syzop
2019-12-30 18:26 syzop Status acknowledged => resolved
2019-12-30 18:26 syzop Resolution open => fixed
2019-12-30 18:26 syzop Fixed in Version => 5.0.1
2019-12-30 18:26 syzop Note Added: 0021180