Infected hosts shows non internal IP

[ED]

Cyber Attack View

Infected hosts shows an IP address that is not internal. 

Example:

The log shows from IP-address 198.11.73.103 towards one of our external IP-addresses og security gateway. 

Why does the Cyber Attack View show addresses that are non internal? How should I interpret this? 

Hello Peppa

[Danny]

Check the definition of your internal network within your SmartEvent configuration.

[ED]

Thanks Danny. So I need to add the external IP's of the security gateways also there?

[Danny]

Jep.

[Vladimir]

Danny,

I'd like some clarification on this subject.

I too see occasional external host listed as "Infected":

"Internal Network" does not contain this IP or the network it belongs to.

Why is it being reported to me?

[Nik_Bloemers]

Did you ever find out the problem?
I'm seeing the same thing in a customer environment (it's actually the same malware-hunter.census.shodan.io host as well). Almost seems like a bug?
Internal network definition only includes RFC1918 addresses.

[Danny]

@Nik_Bloemers ,

just set a filter to show only traffic coming from your internal networks and you won't see infected external hosts. Looks like external hosts accessing your external firewall interfaces via the Internet are not filtered out by default in the reports.

[Trevor_Bruss]

I'm seeing the exact same thing in my environment. It's frustrating because it skews the numbers on reports, etc. given to management. It appears as if we have a larger problem because of all these external sources hitting us and being listed as an infected host. It really does seem buggy if Checkpoint can't step in and explain why this happens even with a properly defined internal network in SmartEvent. These external sources are not my hosts. There are several other threats that we prevent from external and they don't show up as infected hosts, so what gives?

Additional information from digging deeper: Looking at most of the reports, it appears that these non-internal hosts appear to all be related to various Backdoor malware that we are preventing. So does Checkpoint view that as being something that was requested from an internal host at some point? If I run scans against the hosts where these external sources were trying to go they come up clean. So I'm still struggling to determine what in the chain is considered infected or what triggered, if anything, this external source to initiate contact through our firewall.

Perhaps others are seeing similar things in their event views.

[Danny]

It's up to you as a trained and probably certified firewall admin to set the correct filters. You do the same when filtering logs, right? (src: dst:) It's the same database and technology.

[Tom_Hinoue]

I was working something similar to this in a SR while back.. and I believe we got a feedback from the TP team through TAC back then that there are typical signatures for Anti-Bot that is triggered for connections that are initiated from outside... Until then I believed Anti-bot is only triggered for outgoing connections.
This may explain why we are seeing external sources shown up in infected hosts since the connections are started by them.

Btw I'm more familiar with SMB devices; a similar behavior was fixed in R77.20.80 since it was also confusing especially for SMB customers.  [sk126374 - Threat Prevention infected hosts log shows hosts with external IPs in locally managed SMB appliances) ]

Maybe we need something similar in maintrain.. or discuss again why we have a Anti-Bot signature for connections coming from outside in the first place.

[Nik_Bloemers]

Is there at least a way to build an exclusion for this?
I've tried making an exclusion via the SmartEvent policy (just on source IP, every blade), but this doesn't seem to do anything at all.

[Mario_Polenz]

Hi Danny,

do you have an idea, how to do this in the Smart 1 Cloud? At the moment i stuck in opening the seetings in the smart1 Clound administration.

I found a note in the Quantum Smart-1 Clound Administration Guide, Section: Expected Behavior and Known Limitations, : "SmartEvent Policies are not supported. Consequently, it is not possible to configure custom events or
automatic reactions"

does that mean, that i can´t use your suggestion in Smart-1 Cloud?

Thanks Mario

[Chris_Atkinson]

Some items can be performed via a TAC ticket on your behalf, if not already this would be worth checking.

[FedericoMeiners]

Happened in one of our customers, after investigation we could identify that it was a false positive, it seems that Anti Bot engine inspects (by mistake?) the incoming traffic for certain cases.

To add more information here's an extract from Shodan malware services from https://malware-hunter.shodan.io/

Why did my security software raise an alert?

Malware Hunter doesn't perform any attacks and the requests it sends don't contain any malicious content. The reason your security product raised an alert is because it is using a signature that should only be used for traffic leaving the network (egress) but is incorrectly being applied to incoming traffic (ingress). In other words: the security product is using a signature that was meant to detect when a computer on your network was infected and reporting back to a C2. However, the signature is also being applied to all traffic going into your network which is why it's raising a false alert.

[Nik_Bloemers]

I get it for other public IP's / sources too aside from Shodan. Never got it solved and Global Exclusion in SE doesn't seem to work.

[MikeB]

Same behavor in several of my customers.

I hope it can be fixed in the future