On 12/28/2011 05:05 PM, sylver_b wrote:
> Hello,
>
> I've just discovered SEC and it seems to be the perfect fit for what we
> are trying to do .
>
> Basically , we are running a voip peering service but have to face fraud
> on a daily basis. We tried to imagine all sort of ways to detect/stop
> fraudsters (ie: account age vs total active calls, account age vs
> purchase frequency, etc.. ) . SEC comes handy as adding rules should be
> a lot easier . However, we can only find active calls by connecting to a
> unix socket - this is an output sample :
>
> {'I_ENVIRONMENT': 1, 'B2BUA_TAG': '2', 'CLI': '0203xxx3749',
> 'I_CONNECTION': 5, 'CLD': '448000xxx202', 'CALL_ID':
> '[email protected]', 'DELAY': 2, 'DURATION': 12, 'CC_STATE':
> 'Connected', 'I_ACCOUNT': 15, 'ID': '968526', 'I_CUSTOMER': 1}
>
> How could we continuously listen to unix sockets with SEC as calls come
> in and achieve the following :
>
> *a)*alert (or run script) if the call limit per caller (I_ACCOUNT)
> and per period have been exceeded and CC_STATE:Connected
> *b)* alert and run script if same destination number (CLD) with same
> CLI is called more than once -- a "normal" user doesn't call the
> same number more than once
>
>
> Also what's the best way to define the following rule (input from a
> Postgres DB):
>
>
> Period : 15MIN
>
> Alert Conditions :
>
> Applies to : I_ACCOUNT
>
> Alert me when : DURATION -- % INCREASE >= 20 -- COMPARED TO
> : PREVIOUS 15MIN
>
>
> Email : XXX (or run script)
>
>
> We have many more rule combinations, but this will be a great start
> already..
hi,
I think the best way of getting data from UNIX socket would be a small
Perl program which would read the socket and print received events as
lines to standard output. If SEC starts this program at its startup with
'spawn' action, it will be able to receive events from the socket.
Another approach would be to let the program write into a file, and
configure the file as input source with --input option.
A question about case A -- how is the limit per caller configured, is it
a fixed number for the number of calls? If so, you can accomplish this
task with SingleWithThreshold rule. If the limit refers to the duration
of calls, then you would need to maintain a Perl hash table in memory
with call duration sums for each user. Case B is probably easiest to
crack with SingleWithThreshold rule, using the threshold 2. As for the
last task -- if you want to detect relative increase of 20% in call
durations, then you need to rely on Perl data structures again (but
these could potentially be shared with case A).
regards,
risto
>
> Thank you
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
>
>
>
> _______________________________________________
> Simple-evcorr-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
