Network scanning - high number denied attempts followed by a allowed traffic on firewall

[anil_ec21]

Hi Splunk Experts,

My team has below search to identify blocked scanning activity followed by another search via a join to see any src_ip that had been blocked was actually allowed on our firewall.

Here is search query -

index=firewall action=block* src_ip!=192.168.0.0/16 src_ip!=10.0.0.0/8 src_ip!=172.16.0.0/12
| iplocation src_ip
| fillnull value=null Country
| stats count by src_ip dest_port Country
| eval dest_port_bar="".count." attempts on port "+dest_port
| stats list(dest_port_bar) as "Ports" dc(dest_port) as "Number of Ports scanned" sum(count) as Total by src_ip Country
| sort - "Number of Ports scanned"
| join src_ip type=left
[| search index=firewall action=allowed src_ip!=192.168.0.0/16 src_ip!=10.0.0.0/8 src_ip!=172.16.0.0/12
| eval Allowed_Traffic=if(in(action, "allowed"),"Yes","No")
| table Allowed_Traffic src_ip]
| fillnull value=No Allowed_Traffic

This search is very much time consuming. Is it possible optimize the search for quicker results? Also, I have read somewhere that using join command is not wise. Please help! Thanks in Advance

Regards,
Anil A

[mydog8it]

I do not see any difference in time between the two searches. How are you assessing was denied vs is allowed? If you have more than one firewall sending logs to the index it could be permitted by the first to see the traffic and denied by the second, the overall effect would be the traffic was denied for your enterprise firewalls but the interpretation of your data would be once denied but now permitted. Or, the inverse could be true, it was once permitted but now is denied.
If I understand the objective of your search, you would need to perform the searches across to different time periods and look for src_ip dest_port "denied" in the earliest query and in the query of the newer data look for the absence of denied for the same pattern of src_ip dest_port. Then by combining the results you could measure the status of the present against the historical record.
Unless this search is isolated to an edge (or small number of edge) firewall(s) and a timeshift between the two searches is added, I do not see how this is manageable. Of course, I might be way off base too...