Ip Groups

This topic contains 6 replies, has 0 voices, and was last updated by  AtroposX 1 year, 7 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #42120

    AtroposX
    Member

    A way to create groups of ip’s, or ranges. This way it’d be easier to add a group of ips or group of subnets to a classifier.

    Lets say you have a school with multiple subnets, one for each room, this will be easier to narrow down bandwidth usage later on. But you don’t want to have to create a new classifier for each subnet as you do now, but able to create a list if you will, of the subnets you’d like, then able to apply to one classifier.

    This could shorten the classifier list by quite a bit, given that you are classifying a good amount of subnets.

    #49321

    AtroposX
    Member

    By this I mean something such as IPSet at “http://ipset.netfilter.org/”. Lets say you have multiple abusive ips, you can create a ip setlist of the ips, and apply to a classifier rather than having to create a separate classifier per ip.

    Lets say you have 30 ips abusing ftp, causing floods. Normally you’d need to create a separate classifier rule for each individual ip, causing a vary large list, each having the same L7 classifier for FTP, but you’d need 30 different classifier rules.

    With ipset you can create an ipset named “FTP Abusers”, then add all 30 ips to it, and then you can create 1 classifier, and point it to that ipset list, eliminating 29 other classifiers!

    #49322

    dshove
    Member

    I would also like to request this feature.

    I have some experience with IPSet, and the netfilter SET module. Where would I get started to try and implement/compile in this feature?

    Zeroshell looks promising, and I look forward to the stable release.

    Thanks

    #49323

    vpars
    Member

    Although I don’t understand a lot of the techy side of what you are saying the functionality would be a cool feature to have.

    #49324

    AtroposX
    Member

    Well, lets say you use the firewall alot for shaping, which i do. Lets say you have a large block of ips, /20 perhaps, and have a lot of abusers, spammers, viruses, etc. The classifier section will get filled up easily by having to put in each abusive ip individually. Especially since i think there’s a bug where the classifier section won’t display anything more than 60 rules, but any new ones still work, but can only be viewed by the console/ssh, etc..

    What if there was a way to incorporate ipset, to say, only 1 classifier, named “abusers”, and add all the abusive ips to the group, and also add on the fly, and delete on the fly. This way only 1 classifier is made, yet containing the same shaping parameters, but for a group of ips.

    Saves time and cleaning house at the same time. And if i am remembering it right from Netfilter documentation and ipset, it would technically be “faster” to shape against an ipset of 100 ips, than against 100 individual ip rules. Correct me if I am wrong though.

    Also groups of ports would be nice, or at least a way to incorporate multiple ports. Right now you can only do single ports, or a range. Lets say you want to have a /24 block for a school lab have access to only certain ports, 80, 53, 25, 995, etc… Right now, again you’d be cluttering up the classifer section with single port rules for the subnet. Same thing for the L7 as well. Right now you can view by groups, such as chat, p2p, web, etc. But, you can only classify using a signal signature.

    So, in 1 classifier you could says 192.168.1.x/24 gets only these certain ports, bam, one rule, done, not 20 or so, for only common ports. Then in another signal classifier, say ipset “abusers” get 64k of download traffic, and add/delete on the fly to the specified ipset. Then in a third classifier, state, L7 group p2p drop, which incorporates bittorrent, edonkey, etc… in the firewall section.

    Or mix it up and use the “p2p” ipset group in the firewall section and add/delete on the fly to drop the L7 group p2p. Or make another ipset named “spammers” and deny port 25 outbound in 1 single rule.

    Or it’d be great to add/delete your own L7 groups, named common, add http, mail, etc… and add an ipset to it, and those ips/subnet in the ipset, get only common L7 signatures, and can add classes to them, etc.. Many possibilities if ip groups, port groups, and L7 groups could work.

    #49325

    AtroposX
    Member

    Rda implemented this, and it works great. I’d like to see a drop-down menu option to list the different sets in the Firewall and QoS menu, rather than just command line.

    It is soo much easier to state certain “not” ports (! port #) such as 80,53,110,25 as a set, and add/delete the list with appropriate ips.

    This way, if you have a person that is spamming, you can state any ip in the set, that you can alter on-the-fly, that is NOT using 80,53,110, you can drop, yet still allowing web browsing, dns, and receiving of mail, but spammers can’t sent out, all with one rule in the firewall-manage, rather than 3 separate rules for each ip, cluttering it up, and the need to add separate comments to each rule.

    It’s faster too for the firewall to instate one rule and point to a set, rather than instate separate rules all the time.

    #49326

    AtroposX
    Member

    Has IPset been implemented yet? Also a drop down menu still would be great to have. rather than multiple single rules for the same thing.

    Such as spammers. Just create one single rule, drop port 25, point the rule to an ipset. Go to the menu section for the Ipset, add the offending ips to the Spammers Ipset.

    #49327

    reaperz
    Member

    I also support having Checkpoint or BSD style IP-groups and subnet groups. Much easier to create firewall rules that way.

    For example I want to allow some services only from my country IP subnets. But there is ton of then, Have to create and manage tens of firewall rules. Much easier to create one rule and then manage the group of subnets.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.