[netsa-tools-discuss] analysis pipeline alerting issues with EVAL block

Angela Horneman ahorneman at cert.org
Wed Nov 18 10:33:19 EST 2015 

The following will give you both B and C:

FILTER toWormPorts
  ...
  DPORT IN_LIST [135,136,137,138,139,444,445,995,996,997,998,999,8998,3127,3128,3129,3130,3131,3132,3133,3134,3135,3136,3137,3138,3139,3140,3141,3142,3143,3144,3145,3146,3147,3148,3149,3389,2,20,25,21,81,99]
END FILTER

EVALUATION ourNetworkSipsToLotsOfDipsWithManyFlows
  FILTER toWormPorts
  FOREACH SIP
  CHECK THRESHOLD
    DISTINCT DIP > 50
    TIME WINDOW 1 HOUR
  END CHECK
  CLEAR ALWAYS
  OUTPUT TIMEOUT 1 HOUR
  ALERT ALWAYS
  ALERT EACH ONLY ONCE
END EVALUATION

It would also give you E if this is its flows:

SIP|DIP|DPORT|FLOW_COUNT
E   |N    |135       |1
E   |M   |135       |1 
E   |L     |135       |1
E   |K     |135       |1
E   |J      |135       |1 
E   |I      |135       |1

Is that the behavior you are trying to get?

-----Original Message-----
From: asad [mailto:a.alii85 at gmail.com] 
Sent: Wednesday, November 18, 2015 2:25 AM
To: Angela Horneman <ahorneman at cert.org>
Cc: Timur D. Snoke <tdsnoke at cert.org>; netsa-tools-discuss at cert.org
Subject: Re: [netsa-tools-discuss] analysis pipeline alerting issues with EVAL block

In this case it be source IP (B).

On 11/18/15, Angela Horneman <ahorneman at cert.org> wrote:
> If we reduce the volumes for an example and say:
> -same source IP seen communicating with common worms ports provided in 
> the filter block 5 times over -across more than 6 destination IP 
> within 5 minutes
>
> If we see flows like this in 5 minutes:
> SIP|DIP|DPORT|FLOW_COUNT
> A  |Z  |135  |3
> A  |Y  |136  |2
> A  |X  |80   |1
> A  |W  |53   |1
> A  |V  |443  |1
> A  |U  |21   |1
> B  |T  |135  |1
> B  |S  |136  |1
> B  |R  |137  |1
> B  |Q  |138  |1
> B  |P  |139  |1
> B  |O  |444  |1
> C  |Z  |135  |5
> C  |Y  |136  |5
> C  |X  |137  |5
> C  |W  |138  |5
> C  |V  |139  |5
> C  |U  |444  |5
> D  |N  |135  |5
> D  |M  |22   |1
> D  |L  |80   |1
> D  |K  |53   |1
> D  |J  |443  |1
> D  |I  |21   |1
>
> Which SIPs do you want to see in the alert?
>
> From: asad [mailto:a.alii85 at gmail.com]
> Sent: Tuesday, November 17, 2015 10:28 AM
> To: Angela Horneman <ahorneman at cert.org>
> Cc: Timur D. Snoke <tdsnoke at cert.org>; netsa-tools-discuss at cert.org
> Subject: Re: [netsa-tools-discuss] analysis pipeline alerting issues 
> with EVAL block
>
> Hi Angela,
> Thanks for your ongoing support.
> I tried the config you shared with me, but it was not firing ,I 
> noticed that with SIP DIP combo doesn't constitute record count greater then >2.
> In current state, I'm looking for config to identify a situation where 
> the same source IP has matched top filter condition at least N times. 
> For e.g same source IP seen communicating with common worms ports 
> provided in the filter block 5 times over.
> The rest of logic is as it ... "across more than 50 destination IP 
> within 5 minutes."
> I want to know using the earlier config you share would just removing 
> DIP from 'SIP DIP' do the trick As for complete example, A -> X1 : 135 
> A -> X2.: 136 To show here for source IP (A) if it communicates with 
> 135,136 (common worms
> ports) at least x5 times over in 5 minutes with at least x2 distinct 
> IP addresses (x1,x2) fire an alert.
> Hope this help. Please let me know I can provide better example.
>
> On Tue, Nov 17, 2015 at 2:15 AM, Angela Horneman 
> <ahorneman at cert.org<mailto:ahorneman at cert.org>> wrote:
> Statistics do not let you create output lists or do thresholding, so 
> you do need the first EVALUATION block. I'm not sure I understand the 
> second part of your question. Can you provide an example and what you 
> want to see in the alert?
>
> -----Original Message-----
> From: asad [mailto:a.alii85 at gmail.com<mailto:a.alii85 at gmail.com>]
> Sent: Friday, November 13, 2015 7:07 AM
> To: Angela Horneman <ahorneman at cert.org<mailto:ahorneman at cert.org>>
> Cc: Timur D. Snoke <tdsnoke at cert.org<mailto:tdsnoke at cert.org>>;
> netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org>
> Subject: Re: [netsa-tools-discuss] analysis pipeline alerting issues 
> with EVAL block
>
> Angela,
>
> Here is the update, after like 6 hours of SILK i realized the reason 
> this won't work is because on checking the rwfilter results the 
> records count are never greater then 5. See this,
>
> rwfilter   --sensor=S0   --type=int2int   --saddress=10.10.81.74
> --daddress=1.1.1.1  --start-date=2015/11/13T12:15   --dport=137
> --pass=stdout  | rwuniq --field=sip --values=dip-distinct,records
> rwfilter: Warning: start-date precision greater than hours ignored
>             sIP|dIP-Distin|   Records|
>     10.10.81.74|         1|         2|
>
> So, I checked the original rule defined in Qradar this time for your 
> understanding I'm coping it as it is Below
>
> "
> and when any of these BB:PortDefinition: Common Worm Ports with the 
> same source IP more than 5 times, across more than 50 destination IP 
> within 5 minutes.
>
> "
> What I want is a same source IP communicating using the common worm 
> ports at least x5 times. Its reputation. So , I changed the config as 
> follows
>
> FILTER non-local-to-remote
> TYPENAME IN_LIST [int2int,outnull,innull] SIP NOT_IN_LIST 
> "/root/silkydata/DMZ.set"
> SIP NOT_IN_LIST "/root/silkydata/voip.set"
> DPORT IN_LIST
> [135,136,137,138,139,444,445,995,996,997,998,999,8998,3127,3128,3129,3
> 130,3131,3132,3133,3134,3135,3136,3137,3138,3139,3140,3141,3142,3143,3
> 144,3145,3146,3147,3148,3149,3389,2,20,25,21,81,99]
> END FILTER
>
> EVALUATION ourNetworkSIPDIPsMultiFlows FILTER non-local-to-remote 
> FOREACH SIP CHECK THRESHOLD RECORD COUNT > 5 TIME WINDOW 360 SECONDS 
> END CHECK CLEAR ALWAYS OUTPUT LIST SIP CommonwormPORTSMultiflow_list 
> OUTPUT_TIMEOUT 360 SECONDS DO NOT ALERT END EVALUATION
>
> FILTER CommonwormportsMultiflow_list
> SIP IN_LIST CommonwormPORTSMultiflow_list END FILTER
>
> EVALUATION Common-worm-ports
> FILTER non-local-to-remote
> FOREACH SIP
> CHECK THRESHOLD
> DISTINCT DIP > 50
> TIME WINDOW 360 SECONDS
> END CHECK
> CLEAR ALWAYS
> OUTPUT_TIMEOUT 360 SECONDS
> ALERT ALWAYS
> ALERT EACH ONLY ONCE
> END EVALUATION
>
> It is working now, do you think a STATISTICS block can be used instead 
> of first EVAL block.? Also, when the condition matches with unique 
> destination ip greater then 25 then in backlog memory pipelines 
> outputs value of dip that was present at time of match. What about I 
> want to see all the list of distinct IPs I need ALERT EVERYTHING.
>
>
> On 11/12/15, Angela Horneman 
> <ahorneman at cert.org<mailto:ahorneman at cert.org>>
> wrote:
>> It sounds like what you want to do is track SIPs with 250 different 
>> DIPs and SIP DIP pairs with 10 flows and alert when a SIP matches 
>> both. If so, try something like (explanation below the blocks):
>>
>> FILTER ourNetwork
>>   SIP == 193.0.0.0/8<http://193.0.0.0/8> END FILTER
>>
>> EVALUATION ourNetworkSIPDIPsMultiFlows
>>   FILTER ourNetwork
>>   FOREACH SIP DIP
>>   CHECK THRESHOLD
>>     RECORD COUNT > 10
>>     TIME WINDOW 1 HOUR
>>   END CHECK
>>   CLEAR ALWAYS
>>   OUTPUT LIST SIP DIP ourNetworkSIPDIPsMultiFlows_list  OUTPUT 
>> TIMEOUT
>> 1 HOUR
>>   DO NOT ALERT
>> END EVALUATION
>>
>> FILTER ourNetworkSipDipManyFlows
>>   SIP DIP IN_LIST ourNetworkSIPDIPsMultiFlows_list END FILTER
>>
>> EVALUATION ourNetworkSipsToLotsOfDipsWithManyFlows
>>   FILTER sipDipManyFlows
>>   FOREACH SIP
>>   CHECK THRESHOLD
>>     DISTINCT DIP > 250
>>     TIME WINDOW 1 HOUR
>>   END CHECK
>>   CLEAR ALWAYS
>>  OUTPUT TIMEOUT 1 HOUR
>>   ALERT ALWAYS
>>   ALERT EACH ONLY ONCE
>> END EVALUATION
>>
>> This will take all flows where the source is “ourNetwork” and track 
>> how many flows are between each SIP DIP pair. As soon as a pair has 
>> at least 10 flows, they get added to a list. Then we filter new flows 
>> to get only flows that are between SIP DIP pairs have 10+ flows 
>> between them. Of all those flows, we track the count of the unique 
>> DIPs each SIP has had 10+ flow with.
>>  Once a SIP has at least 250, it becomes a success and alerts.
>>
>> Angela
>>
>>
>> From: asad [mailto:a.alii85 at gmail.com<mailto:a.alii85 at gmail.com>]
>> Sent: Thursday, November 12, 2015 8:56 AM
>> To: Angela Horneman <ahorneman at cert.org<mailto:ahorneman at cert.org>>
>> Cc: Timur D. Snoke <tdsnoke at cert.org<mailto:tdsnoke at cert.org>>;
>> netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org>
>> Subject: Re: [netsa-tools-discuss] analysis pipeline alerting issues 
>> with EVAL block
>>
>> Hello Angela,
>>
>> Yes, your last statement is true, i thought RECORD COUNT would be 
>> used for that but I'm failing to understand how I can ADD the two 
>> operations I cannot used RECORD COUNT in single CHECK statement.
>>
>> On Thu, Nov 12, 2015 at 6:51 PM, Angela Horneman 
>> <ahorneman at cert.org<mailto:ahorneman at cert.org><mailto:ahorneman at cert.
>> org<mailto:ahorneman at cert.org>>>
>> wrote:
>> Good morning Asad,
>>
>> The way it is currently set up, it will become a success as soon as a 
>> SIP has at least 10 flows and contacts 250 or more unique DIPs in an 
>> hour.
>>
>> -          The TIME WINDOW of each CHECK block is independent.
>>
>> -          The threshold values for each CHECK block must be met for each
>> key (in your case SIP, since you are using FOREACH SIP), before the 
>> key becomes a success (i.e. available for alerting or inclusion in 
>> lists).
>> In this case, the RECORD COUNT > 10 is unnecessary as by definition, 
>> if there are at least 250 unique DIPs there are at least that number 
>> of flows.
>>
>> Are you trying to detect where a SIP contacts at least 250 different 
>> DIPs and where it has a flow to each DIP at least 10 times?
>>
>> Angela
>>
>> From: asad
>> [mailto:a.alii85 at gmail.com<mailto:a.alii85 at gmail.com><mailto:a.alii85
>> @gmail.com<mailto:a.alii85 at gmail.com>>]
>> Sent: Thursday, November 12, 2015 8:40 AM
>>
>> To: Angela Horneman
>> <ahorneman at cert.org<mailto:ahorneman at cert.org><mailto:ahorneman at cert.
>> org<mailto:ahorneman at cert.org>>>
>> Cc: Timur D. Snoke
>> <tdsnoke at cert.org<mailto:tdsnoke at cert.org><mailto:tdsnoke at cert.org<ma
>> ilto:tdsnoke at cert.org>>>; 
>> netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org><mai
>> lto:netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org>
>> >
>> Subject: Re: [netsa-tools-discuss] analysis pipeline alerting issues 
>> with EVAL block
>>
>> Angela, I need your advice
>>
>> FILTER ourNetwork
>>     SIP == 193.0.0.0/8<http://193.0.0.0/8><http://193.0.0.0/8> END 
>> FILTER
>>
>>
>> FILTER ourNetwork
>>     FOREACH SIP
>>     CHECK THRESHOLD
>>         DISTINCT DIP > 250
>>         TIME_WINDOW 1 HOUR
>>     END CHECK
>>     CHECK THRESHOLD
>>         RECORD COUNT > 10
>>         TIME_WINDOW 1 HOUR
>>     END CHECK
>> END EVALUATION
>>
>> I'm looking for match which happens more then 10 times  in second 
>> CHECK block do I need to specify TIME WINDOW separate or will it AND 
>> the results for e.g more then 250 IPs in 1 hour and PLUS generates / 
>> matches at least
>> 10
>> times. Thanks.
>>
>>
>> On Wed, Nov 11, 2015 at 9:12 PM, Angela Horneman 
>> <ahorneman at cert.org<mailto:ahorneman at cert.org><mailto:ahorneman at cert.
>> org<mailto:ahorneman at cert.org>>>
>> wrote:
>> For statistics, the values are directly related to the time window, 
>> not state based on successes. This means that the alert amount (e.g. 
>> ALERT SINCE LAST TIME) doesn’t apply. The UPDATE statement is all 
>> that is needed to tell Analysis Pipeline how often to send the 
>> alerts.
>>
>> From: asad
>> [mailto:a.alii85 at gmail.com<mailto:a.alii85 at gmail.com><mailto:a.alii85
>> @gmail.com<mailto:a.alii85 at gmail.com>>]
>> Sent: Wednesday, November 11, 2015 9:34 AM
>> To: Angela Horneman
>> <ahorneman at cert.org<mailto:ahorneman at cert.org><mailto:ahorneman at cert.
>> org<mailto:ahorneman at cert.org>>>
>> Cc: Timur D. Snoke
>> <tdsnoke at cert.org<mailto:tdsnoke at cert.org><mailto:tdsnoke at cert.org<ma
>> ilto:tdsnoke at cert.org>>>; 
>> netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org><mai
>> lto:netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org>
>> >
>>
>> Subject: Re: [netsa-tools-discuss] analysis pipeline alerting issues 
>> with EVAL block
>>
>> Hi Angela,
>> Thanks for fast response.
>> Here I want to add earlier you told me to try this construct 
>> STATISTIC checkCountsDistinctDIPs
>>   FILTER non-local-to-remote
>>   FOREACH SIP
>>   DISTINCT DIP
>>   TIME WINDOW 6 MINUTES
>>   SEVERITY 7
>>   UPDATE 5 MINUTES
>> END STATISTIC
>>
>> I somehow missed it from equation today, I m wanting to try this 
>> since going by the logic in it I should know if in 6 minutes what be 
>> count of the distinct destinations IP.
>> Trying this , I want to know do I need any ALERT clauses as well, 
>> unlike EVAL block I don't see any alerting conditions will it default 
>> to ALERT SINCE LAST TIME.
>> Thanks for support.
>>
>> On Wed, Nov 11, 2015 at 6:55 PM, Angela Horneman 
>> <ahorneman at cert.org<mailto:ahorneman at cert.org><mailto:ahorneman at cert.
>> org<mailto:ahorneman at cert.org>>>
>> wrote:
>> Hi Asad,
>>
>> Did you make sure that the address you are checking with the rwfilter 
>> is not in either the DMZ.set, voip.set, or rns.set file?
>>
>> There is not really a way with SiLK to mimic the TIME WINDOW of 
>> Analysis Pipeline. Even if you recursively run rwfilter over short 
>> intervals, that does not match the Analysis Pipeline's sliding time 
>> window. For testing, you might want to use TIME WINDOW 1 DAY if you 
>> are comparing with an rwfilter.
>>
>> Try this:
>>
>> FILTER toWormPorts
>>   TYPENAME == int2int
>>   DPORT IN_LIST [135, 136, 137, 138, 139, 444, 445, 995, 996, 997, 
>> 998, 999, 8998, 3127, 3128, 3129, 3130, 3131, 3132, 3133, 3134, 3135, 
>> 3136, 3137, 3138, 3139, 3140, 3141, 3142, 3143,3146, 3147] END FILTER
>>
>> EVALUATION sipsToManyDipsOnWormPorts
>>   FILTER toWormPorts
>>   FOREACH SIP
>>   CHECK THRESHOLD
>>     DISTINCT DIP >= 5
>>     TIME WINDOW 1 DAY
>>   END CHECK
>>   ALERT ALWAYS
>>   ALERT EVERYTHING
>>   CLEAR ALWAYS
>> END EVALUATION
>>
>> If it works, you can try decreasing the time window in the check 
>> threshold part of the evaluation, then adding in the "whitelist" set 
>> files to the filter.
>>
>> Angela
>>
>> -----Original Message-----
>> From:
>> netsa-tools-discuss-bounces+ahorneman=cert.org at cert.org<mailto:cert.o
>> netsa-tools-discuss-bounces+rg at cert.org><mailto:cert.org at cert.org<mai
>> netsa-tools-discuss-bounces+lto:cert.org at cert.org>>
>> [mailto:netsa-tools-discuss-bounces+ahorneman<mailto:netsa-tools-disc
>> uss-bounces%2Bahorneman><mailto:netsa-tools-discuss-bounces%2Bahornem
>> an<mailto:netsa-tools-discuss-bounces%252Bahorneman>>=cert.org at cert.o
>> rg<mailto:cert.org at cert.org><mailto:cert.org at cert.org<mailto:cert.org
>> @cert.org>>]
>> On Behalf Of asad
>> Sent: Wednesday, November 11, 2015 5:34 AM
>> To: Timur D. Snoke
>> <tdsnoke at cert.org<mailto:tdsnoke at cert.org><mailto:tdsnoke at cert.org<ma
>> ilto:tdsnoke at cert.org>>>
>> Cc:
>> netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org><mai
>> lto:netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org>
>> >
>> Subject: Re: [netsa-tools-discuss] analysis pipeline alerting issues 
>> with EVAL block
>>
>> Here is the result of the filter
>>
>> farhan at netflow:~$ rwfilter --sensor=S0 --type=int2int
>> --saddress=10.10.81.74 --start-date=2015/11/6  --dport=137 
>> --pass=stdout
>> |
>> rwstats --fields=sip,dip --values=records --top
>> --count=5
>> INPUT: 142555 Records for 2944 Bins and 142555 Total Records
>> OUTPUT: Top 5 Bins by Records
>>             sIP|            dIP|   Records|  %Records|   cumul_%|
>>     10.10.81.74|  192.168.33.74|        96|  0.067342|  0.067342|
>>     10.10.81.74|  192.168.172.1|        96|  0.067342|  0.134685|
>>     10.10.81.74| 192.168.181.45|        96|  0.067342|  0.202027|
>>     10.10.81.74| 192.168.172.17|        96|  0.067342|  0.269370|
>>     10.10.81.74|   10.10.232.21|        96|  0.067342|  0.336712|
>>
>>
>> Now, I'm not sure why the ALERT will not still be seen.
>>
>> The auxLog.log shows
>>
>> "
>> 2015-11-10
>> 05:22:08|Memory_Reset|5|Systems_using_many_different_protocols|130396|Common-worm-portS|0|Excessive-firwall-accepts-From-Multiple-Sources-to-a-Single-Destination|0|"
>>
>>
>> My update pipeline.conf says
>>
>> FILTER non-local-to-remote
>> TYPENAME IN_LIST [int2int]
>> SIP NOT_IN_LIST "/root/silkydata/DMZ.set"
>> SIP NOT_IN_LIST "/root/silkydata/voip.set"
>> SIP NOT_IN_LIST "/root/silkydata/rns.set"
>> DPORT IN_LIST [135, 136, 137, 138, 139, 444, 445, 995, 996, 997, 998, 
>> 999, 8998, 3127, 3128, 3129, 3130, 3131, 3132, 3133, 3134, 3135, 
>> 3136, 3137, 3138, 3139, 3140, 3141, 3142, 3143,3146, 3147, 31$ END 
>> FILTER
>>
>>
>> EVALUATION  Systems_using_many_different_protocols
>> FILTER outgoing-flows
>> FOREACH SIP
>> CHECK THRESHOLD
>> DISTINCT DPORT > 25
>> TIME_WINDOW 3600 SECONDS
>> END CHECK
>> SEVERITY 7
>> ALERT JUST_NEW_THIS_TIME
>> ALERT ALWAYS
>> CLEAR NEVER
>> END EVALUATION
>>
>>
>> EVALUATION  Common-worm-ports
>> FILTER non-local-to-remote
>> FOREACH SIP
>> CHECK THRESHOLD
>> DISTINCT DIP > 5
>> TIME_WINDOW 300 SECONDS
>> END CHECK
>> SEVERITY 7
>> ALERT ALWAYS
>> CLEAR NEVER
>> END EVALUATION
>>
>> On 11/10/15, Timur D. Snoke
>> <tdsnoke at cert.org<mailto:tdsnoke at cert.org><mailto:tdsnoke at cert.org<ma
>> ilto:tdsnoke at cert.org>>>
>> wrote:
>>> Asad,
>>>
>>> The more information you provide the better our ability to help you 
>>> work through what your configuration will need to be.
>>>
>>> It is good to be using TYPENAME as a limiting factor at the start of 
>>> your FILTER, often we see that at least half of the traffic by 
>>> volume is web traffic so excluding that from your EVALUATION will 
>>> provide a performance improvement.
>>>
>>> The INT2INT traffic usually reflects an incomplete site definition, 
>>> it would be good to fix that because you might find that you have to 
>>> make special accommodations in your FILTER composition.
>>>
>>> I  hope this helps,
>>>
>>> --
>>> Timur Snoke
>>> Network Defense Analyst
>>> CERT/CC - Network Situational Awareness Software Engineering 
>>> Institute
>>> (SEI)
>>> O: (412) 268-7806
>>>
>>> From: asad
>>> <a.alii85 at gmail.com<mailto:a.alii85 at gmail.com><mailto:a.alii85 at gmail
>>> .com<mailto:a.alii85 at gmail.com>><mailto:a.alii85 at gmail.com<mailto:a.
>>> alii85 at gmail.com><mailto:a.alii85 at gmail.com<mailto:a.alii85 at gmail.co
>>> m>>>>
>>> Date: Tuesday, November 10, 2015 at 9:32 AM
>>> To: timur snoke
>>> <tdsnoke at cert.org<mailto:tdsnoke at cert.org><mailto:tdsnoke at cert.org<m
>>> ailto:tdsnoke at cert.org>><mailto:tdsnoke at cert.org<mailto:tdsnoke at cert
>>> .org><mailto:tdsnoke at cert.org<mailto:tdsnoke at cert.org>>>>
>>> Subject: Re: [netsa-tools-discuss] analysis pipeline alerting issues 
>>> with EVAL block
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 10, 2015 at 6:56 PM, Timur D. Snoke 
>>> <tdsnoke at cert.org<mailto:tdsnoke at cert.org><mailto:tdsnoke at cert.org<m
>>> ailto:tdsnoke at cert.org>><mailto:tdsnoke at cert.org<mailto:tdsnoke at cert
>>> .org><mailto:tdsnoke at cert.org<mailto:tdsnoke at cert.org>>>>
>>> wrote:
>>> Hello Asad,
>>>
>>> This is an interesting question but I am not sure I understand from 
>>> your description what you are trying to capture.
>>>
>>> Thanks Timur,
>>>
>>> Let me re-explain it in a clear way.
>>>
>>>
>>>
>>> You are using type and defining SIP in your filters but do not 
>>> really explain it in your use case.
>>>
>>> In my case I want the source IP which is involved in communicating 
>>> with common worm ports to at least x5 different destinations IP.
>>> Further I want this to match as much as 5 times. I think I need 
>>> RECORD COUNT >5?
>>>
>>>
>>> Are you looking for outside hosts that are trying to scan these 
>>> ports on multiple hosts inside your network?
>>> If this is the case you should just use IN for your TYPENAME, there 
>>> are no web ports or icmp traffic that you are concerned with in your 
>>> port list. If the initiating host is outside then you wouldn’t want 
>>> INT2INT, OUT or OUTWEB. This change will potentially limit the total 
>>> number of flows being evaluated.
>>>
>>> In my current system which is SIEM the rules are firing for traffic 
>>> direction which is int2int.
>>>
>>>
>>> Can you show example flows that should match but doesn’t?
>>>
>>> I will prepare an rwfilter results for you and get back to you. I 
>>> have evidence of its using traffic logs from cisco asa I can show 
>>> that If you want.
>>>
>>> --
>>> Timur Snoke
>>> Network Defense Analyst
>>> CERT/CC - Network Situational Awareness Software Engineering 
>>> Institute
>>> (SEI)
>>> O: (412) 268-7806
>>>
>>> From:
>>> <netsa-tools-discuss-bounces+tdsnoke=cert.org at cert.org<mailto:cert.o
>>> rg at cert.org><mailto:cert.org at cert.org<mailto:cert.org at cert.org>><mai
>>> lto:netsa-to<mailto:netsa-to><mailto:netsa-to<mailto:netsa-to>>
>>> ols-discuss-bounces+tdsnoke=cert.org at cert.org<mailto:cert.org at cert.o
>>> ols-discuss-bounces+rg><mailto:cert.org at cert.org<mailto:cert.org at cer
>>> ols-discuss-bounces+t.org>>>>
>>> on behalf of asad
>>> <a.alii85 at gmail.com<mailto:a.alii85 at gmail.com><mailto:a.alii85 at gmail
>>> .com<mailto:a.alii85 at gmail.com>><mailto:a.alii85 at gmail.com<mailto:a.
>>> alii85 at gmail.com><mailto:a.alii85 at gmail.com<mailto:a.alii85 at gmail.co
>>> m>>>>
>>> Date: Tuesday, November 10, 2015 at 8:30 AM
>>> To:
>>> "netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org><mailto:netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org>><mailto:netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org><mailto:netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org>>>"
>>> <netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org><m
>>> ailto:netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.o
>>> rg>><mailto:netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss@
>>> cert.org><mailto:netsa-tools-discuss at cert.org<mailto:netsa-tools-dis
>>> cuss at cert.org>>>>
>>> Subject: [netsa-tools-discuss] analysis pipeline alerting issues 
>>> with EVAL block
>>>
>>> Hello,
>>>
>>> I have a very simple alerting requirement
>>>
>>> "
>>> when a destination ports matches ports which are considered as 'worm 
>>> ports'
>>> traffic is send to 5 different unique ips in 5 minutes time.
>>>
>>> "
>>>
>>> I know on traffic level i'm getting required data since using 
>>> traffic logs from the cisco asa (same device is also sending 
>>> netflows) and it works as expected. I'm suppose to see an ip address 
>>> but on alert.log I see nothing.
>>> Below is the logic.
>>>
>>> Any help?
>>>
>>>
>>>
>>> FILTER outgoing-flows
>>> TYPENAME IN_LIST [in,int2int,out,outweb,outicmp] SIP NOT_IN_LIST 
>>> "/root/silkydata/DMZ.set"
>>> SIP NOT_IN_LIST "/root/silkydata/voip.set"
>>> SIP NOT_IN_LIST "/root/silkydata/rns.set"
>>> END FILTER
>>>
>>> FILTER non-local-to-remote
>>> TYPENAME IN_LIST [in,int2int,out,outweb,outicmp] SIP NOT_IN_LIST 
>>> "/root/silkydata/DMZ.set"
>>> SIP NOT_IN_LIST "/root/silkydata/voip.set"
>>> SIP NOT_IN_LIST "/root/silkydata/rns.set"
>>> DPORT IN_LIST [135, 136, 137, 138, 139, 444, 445, 995, 996, 997, 
>>> 998, 999, 8998, 3127, 3128, 3129, 3130, 3131, 3132, 3133, 3134, 
>>> 3135, 3136, 3137, 3138, 3139, 3140, 3141, 3142, 3143,3146, 3147, 31$ 
>>> END FILTER
>>>
>>>
>>> EVALUATION  Systems_using_many_different_protocols
>>> FILTER  non-local-to-remote
>>> FOREACH SIP
>>> CHECK THRESHOLD
>>> DISTINCT DIP > 25
>>> TIME_WINDOW 3600 SECONDS
>>> END CHECK
>>> SEVERITY 7
>>> ALERT JUST_NEW_THIS_TIME
>>> ALERT ALWAYS
>>> CLEAR NEVER
>>> END EVALUATION
>>>
>>>
>>
>>
>>
>>
>
>

More information about the netsa-tools-discuss mailing list