Traffic being dropped by Anti Malware

[Steve_Pearson]

I'm troubleshooting a problem with users unable to log into the backblaze website. It reports an issue fetching the account however if I switch to a broadband connection it works fine!

Checking the logs I see nothing being blocked, however when I run a zdebug I see the following:

@;1564707902;[cpu_6];[fw4_2];fw_log_drop_ex: Packet proto=6 10.110.0.10:62707 -> 62.0.58.94:443 dropped by fw_handle_first_packet Reason: Anti Malware;

The first confusing thing is the destination IP appears to belong to Checkpoint.

The Threat prevention policy is set to Optimised but the IPS blade is not enabled (in fact at present only the anti-bot and anti-virus blades are enabled. (not idea I know but this is a temporary measure) Also note that HTTPS inspection is not enabled at present either)

I've tried creating a new rule for the machine in question, disabling all threat prevention, but the issue remains.

Any assistance would be appreciated!

Thanks in advance.

[_Val_]

Can you find the corresponding logs? It might be, for example, the GW is checking SNI for that server and founds it a malware site. What do the AB logs say?

[Steve_Pearson]

Hi Val,

There are no logs that I can find for this, I've checked in the main logs, and also logs for the AB and the AM blades, I'm only seeing the drops when running a zdebug.

Out of interest, if I try to login from my laptop running the full Harmony Endpoint suite connected to broadband, there are no problems, which indicates that the site is ok. So the issue is only when the connection is going via the gateway.

[the_rock]

Ok, I know this may sound extreme thing to try, specially during work hours, but to be 100% sure, are you able to disable anti-bot and install policy? If that works, then we are positive something within that blade is causing it. 

[Steve_Pearson]

That is extreme, but it would certainly prove that the AB blade is the culprit!

I'll try this later tonight if I can.

[the_rock]

I agree, BUT, here is good news...even if you disable the blade and install policy, it would NOT wipe out any existing settings, rules, si easy to put it all back after, just re-enable the and install the policy again.

Personally, I would still make sure I have screenshots of all the existing things related to AB...better be on the safe side.

Andy

[Steve_Pearson]

I agree 100%, record the settings first!

[_Val_]

Look at the raw logs, search by source and destination. It is extremely unlikely there are no logs at all.

[Steve_Pearson]

I've never tried viewing the raw logs, are you able to advise how I do this please? (I know where they are stored!)

[_Val_]

Search either via SmartView or in SmartViewTracker. The latter is a legacy application available with your SmartConsole installation package. You will need to go to the SmartConsole program folder and find it.

[Steve_Pearson]

Sorry, I didn't realise that you were referring to SmartView when you said to look at the raw logs.

I can't find Smartview Tracker in the SmartConsole folders at all.

SmartView runs but returns an error - Query failed. This is before I even type a query, and for anything I type. I suspect that this may relate to SmartEvent not being enabled? The reason for this is that we are recovering from an incident, so currently running with on box management on a 5800 applicance, and disk space is limited.

[_Val_]

While you are fixing your SmartLog, here is the SmartView Tracker

[Steve_Pearson]

Thanks for that!

Running this and filtering by the users IP I see nothing more that the logging in Smartconsole unfortunately, but zdebug still shows the drops.

[the_rock]

Thats odd, as normally, when someone has issues with log indexing, logs show perfectly fine from old school SV tracker, as @_Val_ pointed out in his screenshot.

So, you dont see anything more from there either?

Andy

[Steve_Pearson]

No I don't, there is just some http and https traffic in the logs, but nothing going to the address that zdebug is showing, which I beleive is a Checkpoint IP address!

I've now also tried an fwmonitor for a short time whilst I tested the login process, but it only sees the packets that zdebug is dropping.

[the_rock]

Maybe not related to you directly, but I would give this a go

https://support.checkpoint.com/results/sk/sk123075

fw ctl set int mal_conns_dep_limit 0

[the_rock]

Hey mate,

Did you end up disabling AB blade to see if it makes any difference?

Andy

[Steve_Pearson]

Hi, sorry for the slow reply, I work remotely and had no connection all day yesterday (drunk driver hit a telegraph pole!)

I did disable the AB blade an Monday night, and it resolved this issue, so that was a good move.

I then re-enabled it and tested again and it still worked!

I cleared the cache and rebooted the test pc, it still worked.

Couldn't do anything yesterday, tested again today and it's stopped working again!

[_Val_]

It's a good time to open that support request with TAC

[the_rock]

Sorry to hear about the incident. I think that based on all the testing you did, this definitely warrants TAC case. Keep us posted how it goes.

Andy

[Steve_Pearson]

It's with TAC now, they are investigating. I'll let you know the outcome, but will be out of the office for a few days now!

[the_rock]

Sounds good, hopefully it gets sorted out, Im positive.

Andy

[Steve_Pearson]

TAC have come back to me and said "it seems that the URL api002.backblazeb2.com was blocked in TC due to one of our automatic feeds"

They have whitelisted it at their end and it has resolved the issue!

Regards, Steve

[Lloyd_Braun]

The default value for DNS trap IP is 62.0.58.94

more detail here:

https://support.checkpoint.com/results/sk/sk74060

It may be a query from your DNS server that is triggering anti malware/anti bot blade to return the DNS trap IP, instead of the real backblaze IP address.

[Steve_Pearson]

Thanks for this, I was unaware of this default address.

I've changed this in the config and sure enough it now reports the same error against the trap address that I set, so it thinks that there is a problem with the DNS lookup I assume.

What bothers me is that this gateway is a temporary solution whilst we rebuild the original one with its original policy. I have access to this and there are no exceptions for this site, and it always used to work fine. It suggests that the site may have been compromised, so I'm hesitant about putting an exception in for it.

As Val suggests, I'm going to raise a ticket with TAC to see what their view on this is.

[_Val_]

@Steve_Pearson That's odd. I advise you to open a TAC case for this: https://help.checkpoint.com