[rt-users] RTIR Blocks

[pjaramillo at kcp.com]

Why would you want to block an IP before a problem occurs? And how would 
you know that the IP is going to be problematic before a problem occurs?

Let me explain better. An a IP or domain doesn't have to cause YOU an 
incident for it to be blocked. For your business's sake, you should 
proactively block malicious IPs/Domains. There are variety of sources that 
provide information on bad IPs and domains. If your not using these and 
relying on waiting for something bad to happen, I'm very sorry.

The logic is flawed for this reason. It REQUIRES an incident to occur 
before a block can happen. That is flawed in any scenario. A better logic 
flow would allow for blocks to be tied to either Incident Reports or 
Incidents.

Thanks,
Paul J



From:
"Maxwell A. Rathbone" <mrathbone at sagonet.com>
To:
pjaramillo at kcp.com, rt-users at lists.bestpractical.com
Date:
12/03/2009 11:36 AM
Subject:
Re: [rt-users] RTIR Blocks



Paul,

Why would you want to block an IP before a problem occurs? And how would 
you know that the IP is going to be problematic before a problem occurs?

We utilize RTIR for our Abuse handling. External sites email us to 
abuse at sagonet.com, which drops into RTIR's Incident Reports queue. From 
there, our Abuse Admins verify the issue, then proceed to open an 
Incident & Investigation(outbound ticket to our customer) 
simultaneously. If the customer does not correct the problem within ___ 
amount of time, our Abuse Admins will then open a Block, blocking the 
customer IP until they fix the issue.

It may just be how you are using it that causes you to feel the logic is 
flawed. As from my example above, it fits perfectly in the logical 
workflow.

Max

pjaramillo at kcp.com wrote:
> Has anyone modified RTIR to allow Blocks to be linked to Incident 
Reports 
> instead of Incidents? If so, how?
>
>  I don't like the fact that I have to create an Incident Report and then 

> an Incident to create a Block. That logic is flawed. It assumes it takes 

> an actual incident to put a block in place, where as you should want to 
be 
> proactive and block prior to an incident.
>
> Thanks,
> Paul J
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
>
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
> Buy a copy at http://rtbook.bestpractical.com
>