More packetfilter --banning options?

Did you even consider reading the manual?

1. generate an time event (single, not an recuring)
2. define the source network you wanna block
3. define a new rule on top of your list, where you block the traffic from the defined source. 

So you nicley can generate a rule that says.

For the next year block any connection attempt from those bad networks toward my nice and friendly dmz servers.

Did your mother ever teach you how to behave with common courtesy?  Or to read enough to address the entire problem and not nonrepresentative subset?  Guess you read less than me...I'll cut it there--it's my fault for not being sufficiently detailed enough in originating post, and yours for biting when a reference would have done the task with civility.
  
Back to the point: (and for the record, I'm aware of the time rules--I didn't mention them because they weren't the primary concern)  item 2:  "define the source network...".  I did not and do not particularly want to do that because it strikes me as unmanageable.  I see no reason the Astaro needs 'definitions' of beijing and kentucky networks I'd rather forget about showing up in dropdowns every time I issue a certificate, punch a port through, configure a new host...  And a year later when these rules expire, those networks will still be there.

Yes, right now this will only add two networks to virtually every dropdown in the NAT/PF ruleset--but in the limit that renders the *local* administration I care about unusable.   I guess I could start everything in that family with ZZZ$name  (can you say, *yuck* ?).

Yes--that would work... as would me utilizing iptables and atq (admittedly your way would not void a warranty)--but it would clutter the interface to the point of unmaintainability eventually, and it doesn't strike me as a 'clean' approach to what I presume is a relatively common problem (just as iptables tends to result in some rather ugly scripts when you're done with it--I chose astaro because of the ease and presentation of most tasks).

So again...rephrased:  Does anyone know any simple, elegant way to fire and forget on bans that won't eventually leave me with an interface clogged up with network definitions that I don't really care about?

I've seen your posts nimm--it's clear to me you know that as a sysadmin your job is not just to keep the network working--but also to keep your tools maintainable for your ultimate replacement.  Help me find a *good* way to do this.

Did your mother ever teach you how to behave with common courtesy?  Or to read enough to address the entire problem and not nonrepresentative subset?  Guess you read less than me...I'll cut it there--it's my fault for not being sufficiently detailed enough in originating post, and yours for biting when a reference would have done the task with civility.
  
Back to the point: (and for the record, I'm aware of the time rules--I didn't mention them because they weren't the primary concern)  item 2:  "define the source network...".  I did not and do not particularly want to do that because it strikes me as unmanageable.  I see no reason the Astaro needs 'definitions' of beijing and kentucky networks I'd rather forget about showing up in dropdowns every time I issue a certificate, punch a port through, configure a new host...  And a year later when these rules expire, those networks will still be there.

Yes, right now this will only add two networks to virtually every dropdown in the NAT/PF ruleset--but in the limit that renders the *local* administration I care about unusable.   I guess I could start everything in that family with ZZZ$name  (can you say, *yuck* ?).

Yes--that would work... as would me utilizing iptables and atq (admittedly your way would not void a warranty)--but it would clutter the interface to the point of unmaintainability eventually, and it doesn't strike me as a 'clean' approach to what I presume is a relatively common problem (just as iptables tends to result in some rather ugly scripts when you're done with it--I chose astaro because of the ease and presentation of most tasks).

So again...rephrased:  Does anyone know any simple, elegant way to fire and forget on bans that won't eventually leave me with an interface clogged up with network definitions that I don't really care about?

I've seen your posts nimm--it's clear to me you know that as a sysadmin your job is not just to keep the network working--but also to keep your tools maintainable for your ultimate replacement.  Help me find a *good* way to do this.

Na, your problem is not realy a common one, and I have seen plenty of configrations. 

So what you want is something like in a personell firewall, where you click and block, if an alert is triggered? If so, then the answer is no, theres no way without voiding the warranty. Theres only the dirty way, either you block the subnets via the tables, or you just block all and only allow special subnets. 

Nope I'm no sysadmin (at least, not fulltime), we're just selling the product for 6 years now. 

And the worst tables I have seen had around 15000 lines.

There isn't any way to do it without creating network definitions.

What I do when I want to blackhole a host/network, is to create a rule like this:

Group-Blackhole Source-Blackhole Service-All Action-Drop Destination-Drop

Create the Blackhole source as a network group, then add network IPs/netblocks as appropriate to the group. Put a date in the comment so you remember when you added them to the group.

So what you want is something like in a personell firewall, where you click and block, if an alert is triggered? 



And the worst tables I have seen had around 15000 lines.

That pretty much describes it Nimm--not some sort of 'popup' on my desktop where I hit a deny button, but basically a way to throw in an address or range, hit 'ban for a year' and forget about it.  Of course I prefer the common option of banning everything and only allowing specific users--but that is not an option with the web services and ftp.  

I was actually planning on eventually automating the network ban (if there was a clean way) with a bit of scripting and help from fail2ban running on the DMZ hosts--that way the host based IPS can contribute their knowledge to the firewall (no way the astaro's IPS rules could detect X failed ftp attempts all using invalid accounts--but the host running the service can detect this and do something about it) about the attack, and initiate a network-wide ban.

Getting off topic now that at least two people have confirmed they know of no 'good' way to do this--but if there is no good way I'll settle for the ugly one.  May I ask how your clients manage 15000 network/host definitions?  

Drees--thanks for that thought.  It's not quite what I'd hope for, but at least it will keep the primary network that I care about 'minimally cluttered' with ranges I'd rather not even think about.

Regards,

-Jason-

FWIW, due to 'Nigerian' scams and stuff on our classifieds site, I ended up blocking many countries from accessing our sites using large address blocks which can be found online.
I've posted about it here before.

Barry